[LAD] Ardour session archiver (Was: new lossless/lossy audio compressor)

Phil Frost indigo at bitglue.com
Thu Aug 2 13:28:56 UTC 2007

The reason for using floats is as you said, it's huge dynamic range does
far exceed human hearing or any reproduction hardware, but it is handy
for internal computations. Floats are practically impossible to clip, and
even very quiet signals get at least 24 significant bits. Many filters
and effects can have internal stages at a level very different than the

 The reason ardour uses floats is because it's what jackd uses, so it's
the most straightforward way to record losslessly. Jackd uses it because
it assumes there may be several processing stages between the input and
output. For example, a given channel may be recorded from a microphone,
go through a compressor, some reverb, a gain stage, then be mixed with
several other channels. It makes more sense to perform the integer ->
float conversion once at the A->D, and once again at the D->A, than to
perform it between each linked stage. The conversion is not necessarily
lossless, so each conversion has some cost in noise and distortion.

Jack isn't the only software using floats; I know at least Apple's Core
Audio uses floats end-to-end too. LADSPA plugins use floats on inputs
and outputs by specification, which I think predates jack. I imagine
floats are used internally for a good many effects that have integer
inputs and outputs, and I seem to recall some DAW softwares touting
their (sometimes double precision) floatiness as a feature.

On Wed, Aug 01, 2007 at 02:18:14PM -0700, Gregory Alan Hildstrom wrote:
> Yes, I understand that any single 32-bit floating point number occupies 32 bits. I am specifically
> talking about sets of numbers and the number of bits actually used to represent the set. My basic
> thought is summarized in this example:
> If you limit your range of possible values to positive numbers, the sign bit is useless to you
> because it is always 0. This is true because of how you are using the variable; not because of the
> variable's implementation. The sign bit will still be stored in the float variable, but it is
> wasted space and precision if you do not use it. Your data could be represented with 31 bits
> instead of 32. Obviously wav data is signed, but this illustrates my point.
> I saved a 32-bit 44.1kHz 2-channel wav file using Audacity. The left channel was a full-amplitude
> sine wave sweep from 20Hz to 20kHz. The right channel was a full-amplitude square wave sweep from
> 20kHz to 20Hz. The exponent portion of a float variable is 8 bits, which can represent 0-255 if
> treated as an unsigned integer. I added a line of code to j2kaudio to print out the exponents of
> each float sample while reading the wav file, which I redirected to a file and plotted with
> gnuplot. The exponents ranged from 106 to 127, which is a range of 21. The 21 exponent values can
> be represented with 5 bits (2^5=32).
> I would argue that my wav file, saved with Audacity and ranging from -1 to +1 could be saved with
> a 5-bit exponent instead of an 8-bit exponent. Each 32-bit float value occupies 32 bits, but at
> most only 32-8+5=29 bits needed to be flipped in my wav file; I did not examine the mantissa.
> I then tried to create another 32-bit wav file with a greater dynamic range. I created a 1Hz sine
> wave at full amplitude. I then used the amplify tool (-50dB) to reduce its peak amplitude to
> -600dB, which is an incredibly tiny signal. I then added a second channel with a full amplitude
> sine wav. The small signal would be totally inaudible next to the normal signal. The exponent
> range was 0-10 for the incredibly small sine wave values near 0. The exponent range was 106-128
> for the full amplitude sine wave. The total range I was able to create with Audacity was 0-127,
> still 1-bit shy of an 8-bit exponent, but those additional exponent values I manufactured were
> only used to define incredibly tiny numbers near the zero crossing.
> I guess I do not understand why I would use such a high-dynamic-range variable (32-bit float) and
> artificially limit its range to +/-1 (31 bits). I also do not understand why such a
> high-dynamic-range variable is necessary for audio reproduction given the limits of human hearing.
> I do understand why you might want to use it for various computations. I do not know if this is an
> Audacity-specific limitation or standard industry practice.
> These are just a couple of my hangups that I did not do a very good job of explaining before.
> Please clue me in if I am missing something.
> Thanks. -Greg

More information about the Linux-audio-dev mailing list