2007/3/29, Josh Green <josh@resonance.org>:> > Hello FLAC list.Hi Josh, 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. I also want to know if this is fixed. I agree that perhaps 32 bit float/pcm isn't> entirely necessary when it comes to storing different qualities. But > when wanting to preserve floating point audio, I would think it would be > a nice feature. 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).Is it possible to explain me a bit further what "less dynamic range" exactly means? Can this difference actually be heard and if yes, in what audio quality sources? I have just discovered FLAC and I'm not an audio professional, but I wanted to know what the "real" difference between 32 bit float and 24 bit int precission is when comparing audio quality. And I'm also guessing for reasons why WavPack actually uses 32 bit floats. Is it true then that FLAC is not completely lossless if you look at the encoder when using 24 bit int's vs. using 32 bit float's? Does this storage thing influences the audio quality of just regular Audio-CD quality (16 bits, 44.1kHz, stereo) after compression, because that's the main reason I use FLAC. thanks in advance! The conversion to 24 bit would be a> problem in that case. > > Best regards, > Josh Green > > > On Thu, 2007-03-29 at 12:07 -0700, Brian Willoughby wrote: > > Hi Henry, > > > > 32-bit float has exactly the same precision as 24-bit int. I'm not > > sure what the reference encoder does, but it would be possible to > > write an encoder based on the FLAC library which converts 32-bit > > float to 24-bit int when creating a FLAC-compressed file. You could > > also do the 32-bit float-to-24-bit int conversion with another tool > > before using the standard flac encoder. There would be no loss of > > data so long as the original audio does not exceed +-1.0 in floating > > point, in which case you'd need some way to handle clipping. 32-bit > > float really only has an advantage for intermediate stages of audio > > processing where it might not be a good thing to require clipping or > > peak limiting until a later stage. > > > > 32-bit int has more precision than 32-float, albeit less dynamic > > range. However, there are no 32-bit A/D converters out there, and we > > really only need about 18.5 bits in any listening environment, so 32- > > bit integer is not very useful. It shouldn't be difficult to write > > an encoder/decoder which supports 32-bit integer. There is at least > > one independent FLAC implementation, but I have no idea whether it is > > open-source or supports 32-bit. > > > > As it stands, FLAC is perfectly suited for compression and archival > > of all original recordings and all final masters of audio material. > > Only engineers and experimental researchers would need 32-bit for > > their intermediate storage, and I believe it is typical to not > > compress intermediate storage anyway. In other words, there's no > > real point for this support in FLAC, which is why it isn't there. > > > > Do you have a specific need? ... other than to see the support > > listed as a bullet item on the feature list? > > > > Brian Willoughby > > Sound Consulting > > > > > > On Mar 29, 2007, at 10:24, Harry Sack wrote: > > > > Hi, > > > > I have read this on a forum: > > > > 'FLAC supports 24-bit audio fine. My understanding is that the FLAC > > format also handles 32-bit ints, but the reference encoder does not > > implement it, and FLAC has no support for float data. WavPack handles > > all integer bitdepths up to 32-bit and also 32-bit floats. > > > > Both codecs handle all sampling rates.' > > > > I was wondering if there are plans to support 32-bit ints and float > > data in the future, like WavPack does. > > > > thanks in advance > > > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/flac-dev/attachments/20070329/901c1400/attachment.htm
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. I agree that perhaps 32 bit float/pcm isn't entirely necessary when it comes to storing different qualities. But when wanting to preserve floating point audio, I would think it would be a nice feature. 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). The conversion to 24 bit would be a problem in that case. Best regards, Josh Green On Thu, 2007-03-29 at 12:07 -0700, Brian Willoughby wrote:> Hi Henry, > > 32-bit float has exactly the same precision as 24-bit int. I'm not > sure what the reference encoder does, but it would be possible to > write an encoder based on the FLAC library which converts 32-bit > float to 24-bit int when creating a FLAC-compressed file. You could > also do the 32-bit float-to-24-bit int conversion with another tool > before using the standard flac encoder. There would be no loss of > data so long as the original audio does not exceed +-1.0 in floating > point, in which case you'd need some way to handle clipping. 32-bit > float really only has an advantage for intermediate stages of audio > processing where it might not be a good thing to require clipping or > peak limiting until a later stage. > > 32-bit int has more precision than 32-float, albeit less dynamic > range. However, there are no 32-bit A/D converters out there, and we > really only need about 18.5 bits in any listening environment, so 32- > bit integer is not very useful. It shouldn't be difficult to write > an encoder/decoder which supports 32-bit integer. There is at least > one independent FLAC implementation, but I have no idea whether it is > open-source or supports 32-bit. > > As it stands, FLAC is perfectly suited for compression and archival > of all original recordings and all final masters of audio material. > Only engineers and experimental researchers would need 32-bit for > their intermediate storage, and I believe it is typical to not > compress intermediate storage anyway. In other words, there's no > real point for this support in FLAC, which is why it isn't there. > > Do you have a specific need? ... other than to see the support > listed as a bullet item on the feature list? > > Brian Willoughby > Sound Consulting > > > On Mar 29, 2007, at 10:24, Harry Sack wrote: > > Hi, > > I have read this on a forum: > > 'FLAC supports 24-bit audio fine. My understanding is that the FLAC > format also handles 32-bit ints, but the reference encoder does not > implement it, and FLAC has no support for float data. WavPack handles > all integer bitdepths up to 32-bit and also 32-bit floats. > > Both codecs handle all sampling rates.' > > I was wondering if there are plans to support 32-bit ints and float > data in the future, like WavPack does. > > thanks in advance >
> 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. > I agree that perhaps 32 bit float/pcm isn't > entirely necessary when it comes to storing different qualities. But > when wanting to preserve floating point audio, I would think it would be > a nice feature. As I said, converting to 24-bit does preserve 32-bit float, unless standard audio practices are not followed and the data exceeds +/- 1.0 samples. > 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. > 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. Brian Willoughby Sound Consulting
On Mar 29, 2007, at 12:44, Harry Sack wrote:> 2007/3/29, Josh Green <josh@resonance.org>: > 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. > > I also want to know if this is fixed.Harry, your question doesn't make it clear as to whether you're actually having a problem, or just curious about the answer. Josh Green says he's having a problem where compression doesn't seem to work. Harry, are you actually seeing a problem with 24-bit? What is the problem you're seeing? Are you just writing in because you're curious about the status? There actually is no problem with 24-bit support, as I stated earlier. So before people start chiming in with "me too" - I'd like to request that you actually say what problem you're seeing, along with a few details. Let's not start a rumor fest here.> I agree that perhaps 32 bit float/pcm isn't > entirely necessary when it comes to storing different qualities. But > when wanting to preserve floating point audio, I would think it > would be > a nice feature. 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). > > Is it possible to explain me a bit further what "less dynamic > range" exactly means? Can this difference actually be heard and if > yes, in what audio quality sources? I have just discovered FLAC and > I'm not an audio professional, but I wanted to know what the "real" > difference between 32 bit float and 24 bit int precission is when > comparing audio quality.You cannot hear 32-bit audio because there is no such thing as a 32- bit digital-to-analog converter. And there is absolutely no floating- point D/A of any bit-depth. So you cannot compare the audio quality of 32-bit to anything. All digital audio must be converted to 24-bit or less before you can hear it. This conversion is not part of FLAC, so you probably should look elsewhere to learn about general digital audio technology. FLAC is lossless when compressing any audio that comes from an A/D. FLAC is lossless when compressing any audio that is properly prepared for D/A, and thus ready for listening. Any other format not supported by FLAC is an intermediate format used by audio engineers and not typically for distribution, except perhaps in scientific circles. Note: there are non-linear DACs for 8-bit codes, but those are not true floating point, even though the bit code has a mantissa and exponent.> And I'm also guessing for reasons why WavPack actually uses 32 bit > floats. Is it true then that FLAC is not completely lossless if you > look at the encoder when using 24 bit int's vs. using 32 bit > float's? Does this storage thing influences the audio quality of > just regular Audio-CD quality (16 bits, 44.1 kHz, stereo) after > compression, because that's the main reason I use FLAC. >Lossless means lossless. 16/44.1 CDDA audio quality is identical before and after FLAC. CDDA audio does not use 24-bit or 32-bit codes at any point. It is all 16-bit integers. FLAC does not support 32-bit float, so it is pointless to say whether it is completely lossless when storing 32-float as 24-bit int. If you convert 32-float to 24-bit outside FLAC, then the loss occurs elsewhere, not in FLAC. FLAC is completely lossless for all formats that it supports. I'm sorry that I confused things in my earlier message by pointing out that you can convert 32-bit float to a format that FLAC supports or that you can write your own encoder/decoder for 32-bit integer FLAC. You really need to understand floating point numbers and what kind of audio data you have before trying to analyze FLAC this way. Brian Willoughby Sound Consulting -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/flac-dev/attachments/20070329/14b0e9a7/attachment.html
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