RFC: support for deco algorith and parameter fields

[wrob311 at gmail.com]

On Fri Oct 17 2014 09:15:07 GMT+0100 (IST), Jef Driesen wrote:
> On 2014-10-16 20:16, Dirk Hohndel wrote:
> > On Thu, Oct 16, 2014 at 05:09:06PM +0200, Jef Driesen wrote:
[...] 
> > VPMGFS also has one GF. In the other mail the sat/desat factor was
> > mentioned. I don't know what else is out there.
> 
> I guess only the GF's are a (defacto) standard. Everything is more or 
> less some manufacturer specific tweak of the algorithm. So I think it's 
> not unreasonable if we don't support those. 

It is very interesting to see the last sentence, because similar opinion is quite often seen on this mailing list and leads to a conclusion that some other design has to be chosen because there is no info from manufacturer or some reverse enigineering is needed to support something. And indeed, this project has reverse engineering imprinted in its bones. But maybe sometimes it is OK to simply tell people - if you get info from manufacturer then we will support this piece of information, otherwise you have to live with this or buy something else.

So I would support VPM variants fully. To know if it was VPM-B or VPM-B/E is as important as to know if it was VPM-GFS (both B/E and GFS introduce more conservatism or simply fix original VPM problems). If it is unknown then stick unknown and let the users to do their job with manufacturer support call line. 

Regards,

w