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
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
--- On Fri, 8/14/09, Paul Davis <paul at linuxaudiosystems.com> 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.I'm not saying that, I'm saying float is mainly used in audio engineering which has different requirements and tradeoffs> > 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 :)for export it might be useful, but for recording and editing, a simple, fast codec and easily editable stream format is much more suited. you cannot easily snip an arbitrary section out of a flac or wavpack stream. a very simple float-only codec could be very fast and probably still get compression within 10% of say wavpack. if by audiophiles you are talking about people listening to the end product, properly mastered 16 bit material is mostly indistinguishable from even 24 bit. 32 bit int is beyond overkill. 32 bit float is not even necessary because the dynamic range is fixed in the end result.
On Fri, Aug 14, 2009 at 6:47 PM, Brian Willoughby<brianw at sounds.wa.com> wrote:> 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.You're assuming that you never store intermediate mixes that may actually have overflowed a 24 or 32 bit representation. I would agree that this might not be best practice, but its actually not as un-useful as it might at first appear.> 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.wavepak (pack?) does. ?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).its always a tradeoff between CPU cycles and disk space. you don't need an uncompressed copy if you're prepared to burn the CPU cycles. i'm not an advocate for Ardour using FLAC as a native format. i just don't like telling users "it can't be done".
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
Another point for floating point support: see how WinZip has started using WavPack, I think that was a smart move. It was already the case with RAR & its multimedia compression, I think modern packers need to be multimedia aware. This is very risky, though, and of course requires total lossless compression (assuming it won't try to encode wavs that use codecs). At the same time it's already too late for zip, it's already used too much to touch its format. But for installers (that come with their own decompressor anyway), it can be very interesting. Well, if our installer (nsis for now) had built-in multimedia compression, we wouldn't even need to bother.