Is this a case where something allowed by the specification isn't implemented by the reference encoder/decoder (such as 25-32 bits per sample) but could be in a different implementation? If so, I am not sure whether it makes sense to change the specification based on the reference implementation.
Stephen On Wed, Jun 17, 2020 at 3:22 PM Martijn van Beurden <mva...@gmail.com> wrote: > Hi all, > > When trying to better understand the way LPC exactly works, I stumbled > upon something which, after some digging, was already reported and (partly) > fixed: https://sourceforge.net/p/flac/bugs/424/ > > Apparently, the FLAC specification has a LPC shift that can be both > positive and negative, but the encoder specifically makes sure that only > positive shifts are encoded and the decoder only accepts positive shifts. > The ffmpeg FLAC encoder and decoder show the same behaviour. > > Now, the documentation in the source code is fixed, the documentation on > the website (which I was looking at) isn't yet. The website format.html > states: "Quantized linear predictor coefficient shift needed in bits (NOTE: > this number is signed two's-complement)." The source code format.html says > "Quantized linear predictor coefficient shift needed in bits (NOTE: this > number is signed two's-complement; but, due to implementation details, must > be non-negative)." > > I was thinking of submitting a patch to the FLAC website git to get the > website format.html up-to-date (there have been more changes than just this > one), but I feel the line above isn't clear enough. Maybe change it to > something like this, to make the wording more similar to the rest of the > specification > > Quantized linear predictor coefficient shift needed in bits (NOTE: these > bits must be 00000-01111. Originally this was a signed integer, but > negative shifts were never implemented). > > Or perhaps: > > Quantized linear predictor coefficient shift needed in bits (NOTE: First > bit must be zero. Originally this was a signed integer, but negative shifts > were never implemented). > > Any thoughts? > > Kind regards, Martijn van Beurden > _______________________________________________ > flac-dev mailing list > flac-dev@xiph.org > http://lists.xiph.org/mailman/listinfo/flac-dev >
_______________________________________________ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev