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 signal.
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 _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev
