<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<font face="Courier New, Courier, monospace">Martin,</font><br>
<br>
<blockquote cite="mid:560658FB.6020903@gmail.com" type="cite"><font
face="Courier New, Courier, monospace">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. </font></blockquote>
<font face="Courier New, Courier, monospace"><br>
Very low impedance hardware might have 144 dB S/N ratio (full 24
bit) in some not so far future.<br>
<br>
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.<br>
<br>
However, what cannot likely improve in the near future is the
dynamic range of our ear!<br>
<br>
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) <br>
<br>
</font>
<blockquote cite="mid:560658FB.6020903@gmail.com" type="cite"><font
face="Courier New, Courier, monospace">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.</font></blockquote>
<font face="Courier New, Courier, monospace"><br>
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.<br>
<br>
Regards,<br>
<br>
Federico<br>
<br>
<br>
<br>
<br>
</font><br>
</body>
</html>