Okay, what about one of these lines in the specification? <5> Quantized linear predictor coefficient shift needed in bits (NOTE: this number is signed two's-complement, but should be positive, as no known encoders or decoders have support for negative shifts) <5> Quantized linear predictor coefficient shift needed in bits (NOTE: this number is signed two's-complement, but should be positive, as many decoders only support a positive value here) <5> Quantized linear predictor coefficient shift needed in bits (NOTE: this number is signed two's-complement, however many decoders only support a positive value) <5> Quantized linear predictor coefficient shift needed in bits (NOTE: this number is signed two's-complement, though all known decoders only support a positive value)
I just did a quick search to find open-source decoders and check them. All of them either throw an error or produce an incorrect result. libFLAC, throws error: https://github.com/xiph/flac/blob/master/src/libFLAC/stream_decoder.c#L2663 ffmpeg, throws error: https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/flacdec.c#L380 Rockbox firmware, throws error: https://github.com/Rockbox/rockbox/blob/master/lib/rbcodec/codecs/libffmpegFLAC/decoder.c#L248 Flac.js, throws error: https://github.com/audiocogs/flac.js/blob/master/src/decoder.js#L323 DrFlac, assumes positive shift: https://github.com/mackron/dr_libs/blob/master/dr_flac.h#L2958 Decoder found at https://www.nayuki.io/page/simple-flac-implementation assumes positive shift Flac-library-java, throws error: https://github.com/nayuki/FLAC-library-Java/blob/master/src/io/nayuki/flac/decode/FrameDecoder.java#L300 jflac, assumes positive shift: https://github.com/nguillaumin/jflac/blob/master/jflac-codec/src/main/java/org/jflac/frame/ChannelLPC.java#L77 Claxon, throws error: https://github.com/ruuda/claxon/blob/aaaf40bcbfea01b6243e4699358b25b991e0727e/src/subframe.rs#L529 Kind regards, Martijn van Beurden Op vr 26 jun. 2020 om 08:57 schreef Thomas Zander < thomas.e.zan...@googlemail.com>: > On Fri, 26 Jun 2020 at 05:15, Brian Willoughby <bri...@audiobanshee.com> > wrote: > > > That said, there's nothing wrong with adding a note to the specification > about the common implementations, particularly the reference library. Then, > future developers will know both the precise specification and still have > the warning that they risk incompatibility by deviating from the reference > implementation. > > This sounds reasonable to me. The wording of this note should be very > clear, though. > > Thomas > _______________________________________________ > 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
