[Flac-dev] floating point

Sat Aug 15 05:34:24 PDT 2009

Note: the reason 32bit float was a requirement for me was for use in FL 
Studio.
I'd be the first to say that no one needs to store audio in more than 16bit, 
but if the user has 24 or 32bit audio (32bit float would be to get unlimited 
headroom, while with 24 you'd have to set it up yourself or normalize), I 
wanna compress that transparently.

My 2 goals were
-to compress our demo songs for our online installer (even though we also 
use ogg where it's ok, and of course we don't go above 16bit here)
-to let the user compress all of the audio files his project uses, to share 
online (even if he recorded 12bit worth of noisy audio in a 32bit float wav, 
it's still his problem and I wanna compress this losslessly)
..so both are related to internet sharing.

We also got users asking for FLAC support to spare space on their HD, but 
IMHO that's not a valid reason as these days $100 buy a terabyte. The 
loading times for long tracks is certainly not neglectable.

I've finished implementing WavPack support, we will add FLAC as read-only 
later I think.

I agree that FLAC or WavPack wouldn't be nice for audio track streaming, but 
that's mainly because there's no CPU to waste unpacking several compressed 
streams, if room on the HD isn't a problem anymore.
That reminds me of a similar lossless format that was optimized for realtime 
decoding, for use in samplers. Why not, afterall it's soundbanks that are 
the most RAM eaters in a plugin host. But with compression around 50%, it 
doesn't help that much, you would still eventually need disk streaming. 
However, to -download- such big soundbanks from the internet, it's perfect.

Side note: so far we had been using the Vorbis ACM codec (made by Freddie 
Fish) to compress our demo songs. It worked, aside from several bugs. So we 
recently got a developper "fixing" and enhancing it.
My main problem was: a sample designed to be loop-sliced or sampler-looped 
may not survive lossy compression. So the idea was: I tell the codec where 
my "special" points (markers & loop points) are, and it preserves the 
original audio around it. That worked, but for drumloops that contain lots 
of such markers, the resulting audio file grew enough and it started to be 
less interesting (still better than lossless compression, but not THAT much 
better anymore).
I still believe that such a dream (for us) codec can be made, using FLAC (or 
WavPack) to store the original bits of audio. But now I'm realizing the 
other problems
-apparently the Windows audio compression manager doesn't "thunk" 32bit 
codec, thus it's not very future-proof to rely on a 32bit codec while things 
are changing
-apparently the ACM doesn't seem to make it possible to pass floating point 
audio to a codec (because it doesn't pass WaveFormatExtensible, but I may be 
wrong on this one)
-not many audio editors use the ACM perfectly, so not many can read such 
compressed wavs, defeating the point of storing them in a popular format
-of course it's not portable, as it requires the codec on the target 
platform
So now I think we're gonna stop using the codec & focus on OGG/WavPack 
formats. But the drawback is that the format/extension is different, meaning 
that if a project uses WAV files, it needs to be adapted to use the other 
format, which is not always possible. While the beauty of using the ACM 
codec was that it didn't change anything to the file's header.
I think the best would have been Microsoft enhancing their ACM instead of 
letting it die. Because what's a better standard than WAV to store audio 
even today?

> On Aug 14, 2009, at 14:24, Paul Davis wrote:
>> 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.
>
> You have successfully described why the music production industry has
> settled on float for processing, but this has nothing to do with
> storage formats for analog-to-digital audio recording and playback.
> Programs like Logic Pro will transparently convert from 24-bit source
> files to 32-bit float internally, to avoid the headroom issues you
> speak of.  There is no requirement that the files be stored as 32-bit
> float because you can still do all processing in 32-bit float even
> with 24-bit file sources.
>
> When the ADC source and the DAC destination are both limited to 24-
> bit fixed point integers, it makes absolutely no sense to store
> recordings or final mixes in 32-bit floating point representation.
> The headroom you speak of is completely unavailable when storing the
> output of an ADC into a file.  Likewise, headroom is wasted when
> playing back a fully mastered piece of audio to a 24-bit DAC.
> Headroom is only an issue when you want to work on the audio and
> change it, which is something that 99% of audio consumers do not
> bother with or even understand.
>
>
>>> 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 :)
>
> Audiophiles are still consumers, in that they do not produce music,
> they merely consume it.  You are correct that audiophiles tend to
> live in the gray area between typical consumers and professionals,
> but they still don't need 32-bit float.
>
> Users of Ardour are beyond audiophiles, because they're actually
> producing music.  There would be two different sets of needs for
> storage formats.  For final mixes and delivery of finished audio, 24-
> bit file formats like FLAC are perfect.  These files are in a format
> ready to send to a 24-bit DAC for listening.  Any headroom beyond 24-
> bit is pointless for a delivery format.  For one thing, a 32-bit
> file, compressed or not, would need to be dithered before playing on
> a 24-bit DAC.
>
> Ardour users would have a different set of needs for intermediate mix
> files such as stems and "frozen" tracks.  These would indeed be best
> as 32-bit float, and an optimized format like FLAC would be
> inappropriate.  It would be quite interesting if someone were to
> create a lossless format which can handle 32-bit float, but I don't
> believe it has been done yet.  In most respects, this would mostly be
> a tradeoff between storage space and processing power, since
> processing a compressed file is usually too expensive for most DAW
> software, and so they always uncompress source files before using
> their data.  Thus, even a space-saving format like FLAC would be
> pointless for Ardour, since you'd still need to take up disk space
> for an uncompressed copy of the data (like Ableton Live, which
> supports FLAC).  About the only positive use for lossless compression
> of 32-bit float would be sending stems from digital mixing houses to
> digital mastering houses, while saving on disk space.  Generally,
> saving space is not critical at that professional level, since
> there's usually enough of a budget to cover the cost of increased
> storage space.
>
> I suggest that you tell your users to select FLAC only for final mix
> bounces, and direct them to another format for intermediate storage
> of audio which will be processed further.
>
> Brian Willoughby
> Sound Consulting
>
> _______________________________________________
> Flac-dev mailing list
> Flac-dev at xiph.org
> http://lists.xiph.org/mailman/listinfo/flac-dev

--------------------------------------------------------------------------------

No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.392 / Virus Database: 270.13.58/2304 - Release Date: 08/15/09 
06:10:00