[flac-dev] Supporting 32 bit data

[Brian Willoughby]

On Oct 1, 2015, at 1:22 PM, Martijn van Beurden <mvanb1 at gmail.com> wrote:
> Op 01-10-15 om 18:14 schreef lvqcl:
>> Currently libFLAC stores residual signal as 32-bit signed int. And there
>> are the following comments in stream_encoder.c:
> 
> The residual is stored as a Golomb/Rice code. As far as I know, 
> that is not limited to 32-bit in the format itself, only in the 
> implementation.
> 
> However, there are two residual coding methods now: rice and 
> rice2. rice2 was added when it turned out rice (with a 4 bit 
> rice parameter) wasn't able to cope with the larger residuals 
> that 24-bit material. It looks like a 5-bit rice parameter is 
> enough for 32-bit material as well (highest divisor is 2^30, 
> whereas a 4-bit parameter is limited to 2^14), but maybe a rice 
> partition with 6 bits has to be added, who knows?
> 
> Anyway, I don't think the format is in any way unsupportive of 
> 32-bit int material, it's just the current implementation of the 
> codec.
I've been meaning to take a look at the header format to see whether 32-bit would confuse old decoders, and today's messages reminded me to do that.

METADATA_BLOCK_STREAMINFO allows "bits per sample" to range from 4 bits to 32 bits. That means it should be much less complicated to support 32-bit encoding without completely changing the format.

Decoders already have to check these headers to compare what they support against the specifics of a given file. I don't think that error reporting is very good on embedded FLAC implementations - they usually silently fail to play if given an encoded file that they can't handle. Adding 32-bit support should not make this any worse than it already is.

In contrast, attempting something crazy like support for 48-bit samples would either completely break the format for backwards compatibility, or at the very least would require using some of the "reserved" field values to extend the headers in one way or another. I don't recommend going down this route unless there is an extremely compelling reason.

A minor headache is that the FRAME_HEADER does not support 32-bit sample sizes on its short list, but there is an option to defer to the STREAMINFO for sample size. That might pose a challenge for 32-bit files. Not sure yet.

Brian Willoughby
Sound Consulting