Re: 64bit processing - Why?
Re: 64bit processing - Why?
- Subject: Re: 64bit processing - Why?
- From: Roman Thilenius <email@hidden>
- Date: Fri, 31 Jul 2009 14:49:22 +0100
am 31.7.09 10:40 Uhr schrieb Brian Willoughby unter email@hidden:
> 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!
wooooo, finally a nerd thread on coreaudio :)
*jumps back in*
well i guess what richard means is that the difference between
99999.007812 and 99999.009 CAN matter.
in my opinion (really only an opinion) his example of "summing"
is already a valid one, though it is yet not the worst situation
i could imagine.
one might think that when multiplicating 100 32-float numbers those
errors get averaged somehow, but some samples can get a quite high
offset.
it is about a gaussian distribution how far those offsets goes,
say like ... every 100th samples error is 5-8 times bigger than the
one between 99999.007812 and 99999.009 because errors will sum up
in the same direction from time to time.
and this is exactly what produces noise.
no, you dont really hear that in a normal music mix, but its there.
and it is a bit more there, when all the 100 signals you are summing
only had an amplification around -70 db (0. - 0.001something?) before,
and you gain them up later.
then what about the range of 1.0 which you want to stay in?
there are several situations where you do more.
it starts with things like cos(input*2 pi) which some people do
on a daily basis, and whoops we´re at 3.4.
do fft, and you will need numbers of 1024 or 16000.
use counters or create ramps and you might use numbers up to 8 digits.
have you ever tried to play an audiofile driven by counting samples?
it starts to get inaccurate after 30 minutes or so (cant rember exactly)
and all only due to the 24 bits of accuracy system - which starts to
produce errors of more than 0.5 sooner or later.
do the same with 53 bits of precision and you can play audio sampleexact
for months if not years.
*jumps back out but lurks*
/roman
.
_______________________________________________
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