Re: recording in 32 bit - interface and plugins

[Rainer Straschill <moinsound@googlemail.com>]

rune fagereng schrieb:
> Hi!
>
> I have one question. I read about recording and bits. Some books and 
> dvds, recommand the use of 32 bit. This avoid clipping and is suppose 
> to sound better then 24 bit. And its good choice because many 
> softwares uses this as internal architecture (Izhaki, Tischmeyer). I 
> uses Ableton, Motu Traveller, and Oxford plugins.  
>
> Whats the relation between the interface, software and bits? Is there 
> any point of me choosing 32 bit in my Abelton software, if my Motu 
> interface preamps is 24 bit? 
>
I believe this hasn't been brought up yet, so I'll mention it myself:
The important item is that while the data you get from a (standard) A/D 
converter or from typical (non-computer) digital audio sources like CD, 
SACD, DVD, DAT etc. are integer number formats, the 32bit format used by 
most audio applications is an IEEE-754 floating point format with a 
23-bit mantissa (plus 1 bit sign for the mantissa - similar to normal 
24bit audio) and 8 bit for the exponent (including sign). 
(http://en.wikipedia.org/wiki/IEEE_754)

(Short excursion about exponential float numbers):
Basically, there's two ways to write a number, with and without exponent 
(I stick with float examples here, because it makes the discussion 
simpler).
With exponent, you first normalize the number, so it only has one digit 
left of the comma, and then compensate for that by multiplying with the 
base to the power of the number of positions you've shifted your number 
while normalizing. Practical example: let's say we're using normal 
(decimal) numbers and we'd like to write 103525,33 - that would be:

Step one: move the comma until it's just right to the leftmost non-zero 
number and keep track of how many places you've shifted it:
1,0352533 (shifted by five steps to the left)
Step two: your exponent is equal to the number of steps you've shifted, 
and positive for shifts to the left and negative for shifts to the right 
(and zero for no shift at all).
1,0352533EXP5 is your number.

(note that that notation does mean 1,0352533*10^5, NOT 1,0352533^5).

This gets really interesting if you only have a limited number of digits 
available for storing your numbers - like with computers. So with 32bit 
(integer) you can go from -2*2^31 to 2 *2^31 or roughly -2*10^9 to 
2*10^9. However, the smallest nonzero absolute value is 1. With IEEE754 
notation, you'd go from -2*2^(2^7) to 2*2^(2^7), which is (-)2*2^127 or 
roughly 2*10^38. Conversely, the smallest nonzero absolute value is 
something in the 10^-38 region, so indeed extremely small.

So, while 32bit integer gives you a dynamic range of roughly 192dB, 
32bit float gives you a range of 1530dB (which is awfully huge).
There's another important item: with an integer format, the precision is 
dependent on the actual maximum value you're using. That means, that 
with a 24bit signal, if (for some reason) you recorded with a headroom 
of 42dB in a specific passage of the music, then the effective bit depth 
is only 17bit, while with the 32bit float format, it's still the whole 
mantissa of 24bit.

Ok, back to the question of interest:
There is no practical application to use more than 24bit (integer) for 
an audio signal which is e.g. recorded somehow from the analog world and 
going into your computer, for two reasons: reason one is that the 
dynamic range and SNR of high-end (not-individually lab-tuned) analog 
gear is below the ~144dB of 24bit data format. The second one is that 
the dynamic range of the human ear is below that, too.
There are however reasons why an application (like Ableton, or Cubase, 
or whatever) would use 32bit float internally, and that has to do with 
the gain structure of your DAW. Let's say you're doing a mix where you 
have numerous tracks set to levels between -24 and -6dB, then send it to 
the 2bus, on which you place a limiter set closely to 0dB (e.g. -0.5dB). 
Now if you used a 24bit int format for that, two things would happen. 
First, of the channel turned down to -24dB, 4bits would get "lost" as 
resolution. Second, everything going above the limiter threshold would 
internally clip (because, in int format, unlike the float format, 
there's no sample value above 0dBFS).

There's another thing, and that refers mostly to processing, especially 
filters and convolution reverbs: while their output signal will of 
course be in a "proper" range sonically, some internal signals used for 
the calculation of the effects algorithm may reach some extremely low or 
high values, and there may be very low or high gains applied. To avoid 
that leading to clipping, quality loss and/or accumulation of rounding 
errors, 32bit float is the way to go.

(In a similar discussion on the Möbius forum, I was pointed to 
applications using a 64bit float format throughoutly. I can't find any 
reason to do that for a host application. This may however make sense 
for specific processing plugins (see above)).

So what could you make of it?

You best not change the way the application processes audio internally 
(if you're even able to do that, that is). As for files you're recording 
to, the only reason I could think of is if you work on a project that's 
going to a 24bit destination, doing a final mix and don't want to check 
levels before you render the file that's going to mastering. Or if 
you're working on a project that's using 32bit float entirely (meaning 
your clients demand that).

Yours,

             Rainer

ps: And, as someone said, this doesn't have anything to do with your OS 
and your application being 64bit native code.

-- 
http://moinlabs.de
Follow me on twitter: http://twitter.com/moinlabs