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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/flac-dev/attachments/20200617/c6d448d1/attachment.html>
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 <mvanb1 at 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 at xiph.org > http://lists.xiph.org/mailman/listinfo/flac-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/flac-dev/attachments/20200619/e43cf6a2/attachment.html>
Yes, this is such a case. However, implementing this in a future encoder/decoder would break compatibility with most (likely all) existing decoders, and only in some very, very rare cases where the material is such that the encoder chooses to use negative shifts, which makes it even harder to troubleshoot. Furthermore, as this can only be used in very rare cases, there is no benefit from allowing this. Op vr 19 jun. 2020 om 18:03 schreef Stephen F. Booth <me at sbooth.org>:> 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 <mvanb1 at 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 at xiph.org >> http://lists.xiph.org/mailman/listinfo/flac-dev >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/flac-dev/attachments/20200622/f9a8e1c9/attachment.html>