[Flac-dev] Re: FLAC support for floating point

Josh Green josh at resonance.org
Sat Mar 31 07:41:58 PDT 2007


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




More information about the Flac-dev mailing list