Re: 64bit processing - Why?
Re: 64bit processing - Why?
- Subject: Re: 64bit processing - Why?
- From: Brian Willoughby <email@hidden>
- Date: Fri, 31 Jul 2009 02:40:43 -0700
On Jul 31, 2009, at 01:38, Richard Dobson wrote:
Brian Willoughby wrote:
Dither is most certainly additive. You want to avoid it as much
as possible, postponing until the final stage.
Strange thing is that summing should not involve anything that
would require increased precision, and yet some people claim to
hear better results from summing at 80 bits rather than at 32.
The reason I'm surprised by these claims is that pure summing is
only addition, and you can sum large numbers of channels without
adding too many bits, certainly far less than double.
I have an opposite view - summing needs lots of space. The issue is
limited floating-point precision when adding a small number to a
large one. In 32bit floats, if you add 99999.0 to 0.009, you don't
get 99999.009, you get 99999.007812. A 32bit float only offers
around 7 decimal digits of precision. Change that small number to
0.0009 and it simply disappears - result is still 99999.00000. This
is without either number actually being even close to denormal.
When adding numbers of disparate sizes, the exponent of one or
other number (I forget which) has to be adjusted, which all too
easily results in possibly severe truncation of the mantissa,
leading to the arithmetic problems shown above. The order in which
values are summed can make a difference (e.g., sum all the small
values together before adding to the large one). So summing can
have an effect akin to (probably not very good) dither. It would
therefore not surprise me at all to learn that summing at 80bits
sounds better. Summing at 48bits would probably sound as good (as
you might get using a dsp chip for example); but that size is not
readily available in a general purpose CPU.
I basically disagree, although perhaps you can find a flaw in my
description of why.
Audio samples are expected to be in the range where all values are
less than 1.0, with few exceptions. This fact alone generally avoids
exactly what you described. Digital audio is not exactly the
broadest use of float.
Your example of 99999.0 represents a bus that is in the red by +100
dB, while the bus sending 0.009 is below -40 dB. If you think it
makes a difference when you distort a signal that is 140 dB below
another signal, then perhaps you need to work with more than 32-bit
float for more than just summing. Your example of the completely
lost 0.0009 input represents -60 dB, so of course you're going to
lose that sum when dealing with 24-bit samples which can only hold a
range of 144 dB. 99999.0+0.0009 spans over 160 dB!
I can't think of any audio engineer in their right mind who would mix
multiple busses together where their gain staging differed by 160 dB
or even just 140 dB between each input. If they did, it's no
surprise that things would get lost when working in a 24 bit transport.
The key is that if your 80-bit summing stage outputs at 32 bits, then
there is no difference between the result of summing at 80 bits or 24
bits. The only way to maintain the theoretical advantage of an 80-
bit summing bus is to interconnect to the next stage at 80 bits,
which no known product does. Dithering can preserve these faint
signals, but at the cost of increased dithering noise.
At any rate, all I was saying is that e.g. summing requires 25 bits
to sum two 24-bit busses, 26 bits to sum four, 27 to sum eight, et
cetera. That's not a doubling of the required bits, but just a few
extra. Multiplication increases the required bit depth from 24 to 48
bits. So any gain stage is going to be several times worse without
double precision, while summing suffers the least of any class of
processing. If you have limited resource and are going to allocate
80-bit processing, do it first with gain stages - i.e. faders -
before doing it with summing - i.e. busses.
Brian Willoughby
Sound Consulting
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden