flac dev - Mar 2022 - 64-bit residuals

On Tue, Mar 29, 2022 at 04:57:10PM +0200, Martijn van Beurden
wrote:
> Op di 29 mrt. 2022 om 11:43 schreef Miroslav Lichvar <mlichvar at
redhat.com>:
> > The third option makes most sense to me. I don't think we should
> > complicate decoders by requiring them to support 64-bit residuals only
> > because it's technically possible to encode such a stream.
> 
> Would you argue this limitation is imposed on all possible FLAC
> streams, or just for PCM inputs with a bit depth up to and including
> 24? Or should this also apply to 32-bit streams?
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.
> A similar problem in the spec represents itself with 32-bit PCM
> inputs. When applying stereo decorrelation, a transformation to side a
> subframe bps of 33, which is very inconvenient. Should stereo
> decorrelation be forbidden for 32 bps inputs?
No, that doesn't seem acceptable to me.
> While these distinctions might seem unimportant and 32-bit streams
> folly, there is currently an effort underway to make FLAC and IETF RFC
> standard. I think that the decoder of the reference implementation
> (libFLAC) should support all features the format has before the
> standard becomes final. As the FLAC format has always supported 32 bps
> streams but no encoder for these exists, I think this requires some
> extra care.
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?

-- 
Miroslav Lichvar

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.