Re: [flac-dev] 64-bit residuals
Op di 29 mrt. 2022 om 11:43 schreef Miroslav Lichvar : > 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? 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? 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. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] 64-bit residuals
On Thu, Mar 24, 2022 at 05:05:02PM +0100, Martijn van Beurden wrote: > 3) Add a note to the FLAC spec that residuals should not exceed > 32-bit, and add a mechanism to the encoder to ascertain this. In case > the encoder finds a residual exceeding the 32-bit range, it defaults > to using a verbatim subframe. > > Any thoughts? 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. Decoders can produce wrong output or reject the stream as invalid, but they should not crash. -- Miroslav Lichvar ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
