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. So I tried FLACing white noise, and comp ratio was pretty poor, confirming this. Interestingly, it still did a better job than ZIP! The second problem would be that no other tool would read them correctly anyway. The second idea is to truncate & use it as a lossy encoder, which can be "audibly lossless" anyway. But what's a common practice here? I would be tempted to leave 1 bit of headroom above 0dB, or maybe 2 bits. Normalizing before encoding could be an option, but the gain would then have to be inserted in a tag. & finally, what bit depth? 24? 25, 26? 32? I know there's no right answer, just asking if there are common practices. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/flac-dev/attachments/20090807/9269a2e3/attachment.htm
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
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
I don't think there is a common practice for what you describe. 32-bit float only has 24 bits of accuracy at any one time. The tricky thing is that these 24 bits shift around in precision, based upon the value. Audio is normalized to +/-1, but samples below +/-0.5 would have 25 effective bits, and each halving of the sample value adds another bit. You could convert your 32-bit float audio file to 32-bit integer, but you would need to scale such that +/-1.0 takes the full range of the 32-bit integer (keeping in mind that -1.0 is valid but +1.0 is not, thanks to twos-complement coding). there would still be loss compared to the 32-bit float original, but only for samples very close to 0.0 in absolute value. One important question here is now to store a valid 32-bit integer sound file, and whether this is supported by the native flac command line. I kinda doubt that there is a standard for this. So you might need to write your own tools based on the FLAC libraries. If you were to read a valid 32-bit float audio file and convert each sample to 32-bit integer properly, then you should be able to hand off buffer of 32-bit integer samples to the FLAC library and create a valid flac file. Another consideration is that flac compresses quiet audio files more than loud audio files. By expanding the 32-bit float to 32-bit integer in the fashion I've described - which is the only way to preserve the maximum resolution - you will end up with a flac that is much larger than the equivalent 24-bit integer file. I suppose that is obvious, but I wanted to point it out anyway. It should be much better with 32-bit integer audio than it would be with pure noise, though. P.S. DTS Music Disc format put 5.1 surround into a 16-bit WAV. Normally, this would not compress very well with flac. However, the DTS guys realized that some users might play this WAV without a DTS decoder, and the white noise could destroy sound systems. So the DTS format drops two bits from every sample, making the white noise 12 dB quieter. An interesting side effect of this is that flac is able to compress this much more than regular white noise because of the 12 dB reduction. I only mention this because it is instructive about how the amplitude of the audio input affects flac's compression performance. Brian Willoughby Sound Consulting On Aug 7, 2009, at 07:42, Didier Dambrin wrote: 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. So I tried FLACing white noise, and comp ratio was pretty poor, confirming this. Interestingly, it still did a better job than ZIP! The second problem would be that no other tool would read them correctly anyway. The second idea is to truncate & use it as a lossy encoder, which can be "audibly lossless" anyway. But what's a common practice here? I would be tempted to leave 1 bit of headroom above 0dB, or maybe 2 bits. Normalizing before encoding could be an option, but the gain would then have to be inserted in a tag. & finally, what bit depth? 24? 25, 26? 32? I know there's no right answer, just asking if there are common practices.
--- On Fri, 8/7/09, Didier Dambrin <didid at skynet.be> 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?it's unlikely flac will ever support floating-point samples natively. the main application for it is audio engineering, which demands easy editing and very high speed for both encoding and decoding above everything else. flac is designed as a consumer audio format. it trades ease of editing for a featureful, robust transport layer more suited for playback, and encoding speed for more compression and faster decompression.
On Fri, Aug 14, 2009 at 5:05 PM, Josh Coalson<xflac at yahoo.com> wrote:> it's unlikely flac will ever support floating-point samples natively. ?the main application for it is audio engineering, which demands easy editing and very high speed for both encoding and decoding above everything else.thats not why floating point is used. the highest current feasible bit resolution for digital audio samples is 24 bits. most converters don't even fully provide that. 32 bit floating bit allows bit-for-bit storage of all 24 bits of the original sample as the mantissa, along with more bits available in the exponent. this provides astronomical "headroom" for use when summing multiple samples. if you only use 24 bits and add two values very close to the maximum 24 bit value, you will overflow. even if you use 32 bits, its not imposible to construct workflow scenarios where you would overflow. if you do this in float format, you lose a little precision in the answer, but you cannot overflow. this is why floating point is used.> flac is designed as a consumer audio format. ?it trades ease of editing for a featureful, robust transport layer more suited for playback, and encoding speed for more compression and faster decompression.flac seems more popular at present among high end audiophiles than mere consumers. its very regrettable that it doesn't support floating point natively. many of our users (http://ardour.org/) have asked about using FLAC as an option for recording format, but we have to explain that its not viable because of the lack of floating point support. and yes, that is audio engineering :) --p