On Thu, 2007-03-29 at 12:53 -0700, Brian Willoughby wrote:> > Hello FLAC list. > > > > As far as I know 24 bit FLAC support is broken. It often doesn't > > compress the audio at all, but instead stores the chunks as verbatim > > type (although the FLAC format supports 24 bit). Perhaps this is > fixed? > > If so, do let me know. > > Hi Josh Green, > > 24-bit FLAC works perfectly, and has done so for years. I regularly > make live recordings in 24-bit and back them up after compressing > with FLAC. I sometimes files as small as 30% of the original because > I record at conservative levels to avoid. Also, if you screw up and > put 16-bit audio samples in a 24-bit file, FLAC will still compress > this to within 1% or 2% of what you get when compressing the 16-bit > file. FLAC 1.1.2 is what I have tested the most, and I'm not sure > how long I've been running 1.1.4 so far. >Hmm, well I'm not trying to start any rumors. Here is the beginning of the thread in which this was discussed. Admittedly I have not tested the latest in this regard. Will do so at some point soon. http://lists.xiph.org/pipermail/flac-dev/2006-August/001935.html And the resulting response from Josh Coalson: http://lists.xiph.org/pipermail/flac-dev/2006-August/001937.html> > I believe 32 bit floats have a precision of 23 bits > > when the audio is +/- 1.0, so in theory that would mean that 24 bit > > would have more precision but less dynamic range (if the floating > point > > range is outside of +/- 1.0). > > No. Floating point values are always normalized so that the most > significant "1" bit is always in the same position. Thus this bit is > not stored. So the 23 bits that are stored , plus the 1 bit that is > assumed, both add up to 24 bits total. 32-bit float has the same > precision as 24-bit integer. >Ok. I was aware of the "1" being implicit, but I suppose I wasn't taking that into account. I imagine if FLAC was designed for floating point audio it might do better than converting it to 24 bit audio though before hand, since floating point isn't a linear range and perhaps the waveform predictors wouldn't be ideal (just speculating here!). But if this conversion makes sense, why not have support for it built into FLAC? You'd get 24 bit out, which wouldn't exactly be preserving the format, but it would at least make it possible. At a minimum its a nice "buzz" word (weeee 32 bit float support!). Perhaps that isn't really the scope of FLAC though.> > The conversion to 24 bit would be a > > problem in that case. > > Well, yes, clipping is a problem whether you're playing the audio so > you can listen to it, or you're converting to integer for any other > reason. That's why 32-bit is important for intermediate stages of > modern DAW software. >Floating point sound card anyone? I suppose not, point taken.> Brian Willoughby > Sound Consulting >Best regards, Josh Green
When you say "why not have support for it build into FLAC," you're really just talking about the reference implementation of FLAC. Nothing is stopping you from writing your own software to do this. You just can't change the FLAC format itself. I think it would be very interesting to have an independent tool which reads 32-bit float format files when encoding FLAC, and possibly even produces 32-bit float when decoding. It would not be bit-accurate if you used the reference libFLAC implementation because it is currently limited to 24-bit, and thus you would probably need some kind of dithering during the float-to-in conversion for best results. But if you were willing to take on the task of writing a full encoder, you could cram 32-bit float samples into 32-bit integer FLAC. There would still be losses under certain circumstances, but probably not for audio which sticks to the +/- 1.0 standard reference levels. Trouble with all of this theoretical stuff is that these files might not play with standard FLAC decoders. Brian Willoughby Sound Consulting On Mar 29, 2007, at 16:05, Josh Green wrote:> On Thu, 2007-03-29 at 12:53 -0700, Brian Willoughby wrote: >>> I believe 32 bit floats have a precision of 23 bits >>> when the audio is +/- 1.0, so in theory that would mean that 24 bit >>> would have more precision but less dynamic range (if the floating >>> range is outside of +/- 1.0). >> >> No. Floating point values are always normalized so that the most >> significant "1" bit is always in the same position. Thus this bit is >> not stored. So the 23 bits that are stored , plus the 1 bit that is >> assumed, both add up to 24 bits total. 32-bit float has the same >> precision as 24-bit integer. > > Ok. I was aware of the "1" being implicit, but I suppose I wasn't > taking that into account. I imagine if FLAC was designed for floating > point audio it might do better than converting it to 24 bit audio > though > before hand, since floating point isn't a linear range and perhaps the > waveform predictors wouldn't be ideal (just speculating here!). > But if > this conversion makes sense, why not have support for it built into > FLAC? You'd get 24 bit out, which wouldn't exactly be preserving the > format, but it would at least make it possible. At a minimum its a > nice > "buzz" word (weeee 32 bit float support!). Perhaps that isn't really > the scope of FLAC though.
Re-ordered the reply, since it is easier to follow the thread when the replies are at the bottom. On Fri, 2007-03-30 at 17:15 -0700, Brian Willoughby wrote:> On Mar 29, 2007, at 16:05, Josh Green wrote: > > On Thu, 2007-03-29 at 12:53 -0700, Brian Willoughby wrote: > >>> I believe 32 bit floats have a precision of 23 bits > >>> when the audio is +/- 1.0, so in theory that would mean that 24 bit > >>> would have more precision but less dynamic range (if the floating > >>> range is outside of +/- 1.0). > >> > >> No. Floating point values are always normalized so that the most > >> significant "1" bit is always in the same position. Thus this bit is > >> not stored. So the 23 bits that are stored , plus the 1 bit that is > >> assumed, both add up to 24 bits total. 32-bit float has the same > >> precision as 24-bit integer. > > > > Ok. I was aware of the "1" being implicit, but I suppose I wasn't > > taking that into account. I imagine if FLAC was designed for floating > > point audio it might do better than converting it to 24 bit audio > > though > > before hand, since floating point isn't a linear range and perhaps the > > waveform predictors wouldn't be ideal (just speculating here!). > > But if > > this conversion makes sense, why not have support for it built into > > FLAC? You'd get 24 bit out, which wouldn't exactly be preserving the > > format, but it would at least make it possible. At a minimum its a > > nice > > "buzz" word (weeee 32 bit float support!). Perhaps that isn't really > > the scope of FLAC though.> When you say "why not have support for it build into FLAC," you're > really just talking about the reference implementation of FLAC. > Nothing is stopping you from writing your own software to do this. > You just can't change the FLAC format itself. > > I think it would be very interesting to have an independent tool > which reads 32-bit float format files when encoding FLAC, and > possibly even produces 32-bit float when decoding. It would not be > bit-accurate if you used the reference libFLAC implementation because > it is currently limited to 24-bit, and thus you would probably need > some kind of dithering during the float-to-in conversion for best > results. But if you were willing to take on the task of writing a > full encoder, you could cram 32-bit float samples into 32-bit integer > FLAC. There would still be losses under certain circumstances, but > probably not for audio which sticks to the +/- 1.0 standard reference > levels. > > Trouble with all of this theoretical stuff is that these files might > not play with standard FLAC decoders. > > Brian Willoughby > Sound Consulting >Yes, of course I meant "support built into" the reference implementation. The point was also that 32 bit float data can be stored in 24 bit without loss of precision, provided that the audio is between +/- 1.0 since the mantissa of 32 bit float data is 23 bits plus the implicit 1 digit. Now that I think about it though, while indeed the range of floating point numbers could be stored in 24 bit integer, perhaps the scale would be wrong when assuming its 24 bit integers. As long as the decoding side understood that, it could be reproduced as floating point again, but that would require a special decoder or change to the FLAC format, as you mentioned. Just kicking around ideas. Regards, Josh Green