[Flac-dev] Re: FLAC: same features as WavPack

[Brian Willoughby]

On Mar 29, 2007, at 12:44, Harry Sack wrote:
> 2007/3/29, Josh Green <josh at 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