Op wo 30 mrt. 2022 om 11:03 schreef Miroslav Lichvar <mlichvar at redhat.com>:> I think that should apply only to <=24 bits. If I understand it > correctly, with 32 bits it would be a real limitation, not hit only > with specifically crafted encodings. > > [...] > > No, that doesn't seem acceptable to me. >One added advantage of setting both limits for 32-bit encodings (not allowing stereo decorrelation and limiting residuals to 32-bit) is that libFLAC from 1.2.1 onwards and ffmpeg since May 2015 are "forward-compatible". ffmpeg actually needs limiting the residual to 31-bits for that to work. A working patch for the ffmpeg FLAC encoder can be found here: https://patchwork.ffmpeg.org/project/ffmpeg/patch/20220108142437.756529-1-mvanb1 at gmail.com/ In fact, the files generated with this patch play on a few hardware devices I tested them with that use a libFLAC-derived decoder. Granted, it won't provide the best possible compression, but 32-bit PCM is itself already an extremely inefficient format. So I think the choice here is between slightly better compression and a simpler encoder versus backward compatibility with a lot of decoders and no added decoder complexity.> The intended status of the current FLAC draft is informational, so > there doesn't have to be any existing implementation that supports all > bit depths, right?Actually, the intended status was indeed information in the last few drafts, but this will be changed back to standards track, as it was in the first few drafts.
On Wed, Mar 30, 2022 at 04:02:11PM +0200, Martijn van Beurden wrote:> Granted, it won't provide the best possible compression, but 32-bit > PCM is itself already an extremely inefficient format. So I think the > choice here is between slightly better compression and a simpler > encoder versus backward compatibility with a lot of decoders and no > added decoder complexity.Can you post some examples of the impact on compression ratio? Do the samples actually use all of the 32 bits? I have no experince with this. If compression of 16-bit audio was limited to 16-bit residuals, I suspect that would have a significant impact, so I'm wondering how it is different with 32-bit audio. -- Miroslav Lichvar
Op wo 30 mrt. 2022 om 16:02 schreef Martijn van Beurden <mvanb1 at gmail.com>:> One added advantage of setting both limits for 32-bit encodings (not > allowing stereo decorrelation and limiting residuals to 32-bit) is > that libFLAC from 1.2.1 onwards and ffmpeg since May 2015 are > "forward-compatible". ffmpeg actually needs limiting the residual to > 31-bits for that to work. A working patch for the ffmpeg FLAC encoder > can be found here: > https://patchwork.ffmpeg.org/project/ffmpeg/patch/20220108142437.756529-1-mvanb1 at gmail.com/ > In fact, the files generated with this patch play on a few hardware > devices I tested them with that use a libFLAC-derived decoder.I just realised I forgot to mention one additional constraint this patch imposes for backwards-compatibility: those files also cannot include fixed predictors. So there are four constraints for backward-compatible 32-bit streams: no fixed subframes, no stereo decorrelation, no predictions exceeding a 32-bit int and no residuals exceeding a "31-bit int". Summing this all up, this seems to be getting out of hand just for the sake of being compatible with software that was never meant to decode these streams in the first place I'll start working on a patch to include stereo decorrelation and handling fixed subframes for 32-bit FLAC in both decoder and encoder to do some more testing. It seems that those two changes are worth the extra encoding and decoding complexity, while adding handling for > 32-bit residuals (which need new bitreader and bitwriter functions) does not. Kind regards, Martijn van Beurden