[flac-dev] Supporting 32 bit data

[Federico Miyara]

Martin,

> Yes, this is nuts. First, 24-bit is already overkill, as there is no 
> hardware (ADC or DAC) that can handle more than 120dB of dynamic range 
> anyway. There probably never will be hardware that can handle the full 
> 24 bits, because at this point that hardware is already pushing the 
> boundary of thermal noise. 

Very low impedance hardware might have 144 dB S/N ratio (full 24 bit) in 
some not so far future.

A 10 ohm resistance has an audio band RMS noise voltage of about 57 nV, 
this means that with a 1 V signal you have a S/N ratio of 145 dB, so 
thermal noise isn't the bottlenecck. A good opamp may have about 100 nV 
at low gain. The electronic components may improve in the future so that 
they can attain this S/N even at higher gains.

However, what cannot likely improve in the near future is the dynamic 
range of our ear!

In any case, the applications of lossless coding not necessarily reduce 
to what can be converted or heard. For instance, collaborative internet 
audio processing may require sharing massive intermediate results at 
full 32-bit or even higher precision under some protocol to be developed 
(if it hasn't been developed yet)

> Second, most 32-bit material is 32-bit float, and that is something 
> the FLAC format can't handle. I really wonder why anyone would have 
> 32-bit integer material anyway.

Theoretically any 32-bit float can be converted to a 150 bit integer 
(roughly 127 + 23), so at least in theory the FLAC method could be 
applied. May be it wouldn't render any compression at all since we would 
be converting a sparse numeric format into a full 150 bit one, since in 
32 bit float most of the 150 bit numbers cannot be represented. But 
perhaps an adaptive version could do a decent job. The idea is that if 
one could use an intermediate format with more than 23 bit fraction 
precision, the exponent wouldn't change so often.

Regards,

Federico





-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.xiph.org/pipermail/flac-dev/attachments/20150926/6ea44363/attachment.htm