[Flac-dev] floating point

[Didier Dambrin]

You may be right.
I haven't managed to test yet, as right now I'm prospecting options, haven't 
started coding yet.

I've tried FLACing a 32bit integer wav but the binary wouldn't read it. But 
I'm not sure if it's the right format, I actually saved it using an old 
CoolEdit Pro that had an option to save 32bit float in a 32bit integer 
format (for compatibility reasons), so it normally had the same wave format 
as a 32bit integer wav.
And indeed, loading that sample into Audacity, so interpreted as integer, 
was very saturated but still a little audible, so not white noise.

It's hard to decide which encoder to pick because, on one hand it's very 
possible to use FLAC to store this in a lossy way but with zero audible 
difference. And let's be honnest, even 16bit is more than adequate for this.
On the other hand, it wouldn't be acceptable to do that for, say an undo 
system in an audio editor - the undo should restore exactly the original 
data.
I like FLAC on the paper because of its metadata preservation, in that riff 
tag, which is critical for my needs.


Up to now I've always tried to stay away from other file formats, to prefer 
codecs & keep with WAV files. But the ACM in Windows has aged, isn't much 
supported anymore, and from what I understand it's not very 
WaveFormatExtensible-ready, thus it would too have problem with floating 
point audio.
Many choices out there.





> Didier Dambrin wrote:
>> Hi,
>>
>> I've tried to find info about unofficial 32bit float support in FLAC, and 
>> found several conversations.
>> Most of them were talking about a 24bit limit, but from the manual I 
>> guess that this limitation is gone, as it supports up to 32bit integer.
>>
>> So my question is, what would be the best way, or what is a common way to 
>> FLAC-encode floating point audio?
>>
>>
>> The first idea is obvious, we have a 32bit float, FLAC supports 32bit 
>> integer, and it's lossless. So I'd just make it encode 32bit float, it's 
>> lossless afterall.
>> 2 problems, first I would suspect it wouldn't encode very well, since the 
>> data wouldn't be "audio" anymore, right? It would be like trying to 
>> FLAC-encode random data.
> I suspect FLAC may perform somewhat better doing this than it would
> compressing purely random data.  If you plot floating point numbers
> against their binary representation interpreted as a (big endian) signed
> integer, I believe the resulting line will vary monotonically, apart
> from a discontinuity at zero.  This should mean that the data still
> looks a bit like audio to FLAC, and that it will still compress
> reasonably well.
>
> Christopher Key