[flac-dev] 64-bit residuals

[Miroslav Lichvar]

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