] [Thread Prev
Re: recording in 32 bit - interface and plugins
rune fagereng schrieb:
> 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).
(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
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).
ps: And, as someone said, this doesn't have anything to do with your OS
and your application being 64bit native code.
Follow me on twitter: http://twitter.com/moinlabs