Re: Calculating peak level in db
Re: Calculating peak level in db
- Subject: Re: Calculating peak level in db
- From: Doug Wyatt <email@hidden>
- Date: Tue, 15 Oct 2002 13:15:35 -0400
On Tuesday, Oct 15, 2002, at 10:57 America/New_York, Richard Dobson
wrote:
[Trying to pull this thread to some sort of conclusion!]
I'm not writing drivers, just soundfile format stuff (user-level
processes). But I think the issues are more or less the same. Of
course, a driver is expected to deliver unmodified values to the user,
but if the driver has to convert to normalised floats, what is it
expected to do with the range?
Programmers everywhere complain about having to clip ~somewhere~, when
converting between 16bit and floats, because it puts conditional tests
on every sample. In my own stuff I have to clip floatsam outputs
anyway (composer stuff, experimental, over-range samples are de
rigueur), so I am happy to convert 16bit to float by scaling by
1/32767, and getting -32768 converted to -1.00003; which I will be
clipping later on anyway. Or, I can treat it as overrange, and clip it
on input.
The alternative is to scale by 1/32768, which ensures a full range of
normalized floats, but means you have to map 1.0 (which is ~within
range~ for floats) to 32767 on output, clipped from 32768. And of
course samples remaim identical, as you require.
The issue is really: is -32768 the anomalous value, or is +32768 a
'missing but legitimate' value?
The latter. We scale by 32768 in both directions.
My radical speculation was to scale by 32767/32768, and as noted
elsewhere it does or course amount to a very small drop in level,
which indeed does become noticeable on changes to high-level samples
(which I should have checked before commenting - I tend to avoid
running signals above -6dB), but means that the complete path from ADC
to DAC could in principle be conducted without clipping. Either way,
the input driver would scale by 1/32768; the question is how does the
system convert +-1.0 back to 16bit?
0x7FFF - as one previous poster mentioned, the distortion is
thousandths of a dB; if you don't like it, reduce your gain by that
miniscule amount.
On the PowerPC you can clip without an if by multiplying by 2^32 and
then converting to int. The result will be clipped to the range of a
32-bit int. (Caution: ANSI C says this is undefined behavior). For
bit depths less than 32 you can then just shift right.
And to go from int to float, there's a cool trick involving bit-banging
according to the format of a IEEE float...
Or you can just use AudioConverter.
Re convergent rounding - this is widely used in DSP chips such as the
Motorola 56K series, in their MACR instruction. It is an operation of
"round to nearest", and on Intel involves only three ~asm instructions
- it is a lot cheaper than a C cast. Maybe it is more expensive on PPC
(and is certainly expensive if coded in C).
we set the FPU's rounding mode ... (speaking for AudioConverter)
But it is an important process, especially in the absence of dither.
For a straight i/o copy, it is transparent, but minimizes quantisation
errors while keeping them symmetrical, which will in principle be an
issue as soon as the signal is modified in any way.
The scale factor 32767/32768 is so small that it in effect falls
inside the 16bit quantisation distance, except, as noted elsewhere,
for signals above -6dB. So um, well, a lot of the samples are
unchanged! I need to make more tests, but initial experiments indicate
that the same method applied to 24bit samples does give identity
output, as the (32bit) scale factor is within the quantisation range
even at peak values.
So no worries, I am not about to release any pathological drivers (I
have no plans indeed to develop any!); there are several ways of doing
16bit/float mapping, and I remain curious as to what the canonical
approach is in CoreAudio.
scaling factor is 2^N in both directions.
Doug
--
Doug Wyatt
work: email@hidden (CoreAudio)
personal: email@hidden
http://www.sonosphere.com
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.