Re: Asymmetry in CoreAudio representation?
Re: Asymmetry in CoreAudio representation?
- Subject: Re: Asymmetry in CoreAudio representation?
- From: Doug Wyatt <email@hidden>
- Date: Thu, 4 Apr 2002 18:31:35 -0800
Yeah, I don't believe Daisy is doing this correctly.
What we do in the AudioConverter is always multiply and divide by a
power of 2 (32768 for 16-bit samples). While this results in a float of
+1.0 being clipped from its perfect theoretical representation of 32768
to 32767, that seems to me to be the least of the possible evils:
- having precisely one of the 2^x sample values clipped to (2^x)-1 (what
we're doing, and only happens when you get to an amplitude where it's
likely that more clipping than that is going to happen anyhow)
- multiplying and dividing positive/negative numbers asymmetrically and
distorting the waveform
- multiplying and dividing by 32767 which would introduce rounding error
(IEEE floating point numbers are base-2 fractions and so integers of up
to 24 bits can be converted to and from 32-bit floats perfectly by
multiplying/dividing by the appropriate integral power of 2)
Multiplying and dividing by a power of 2 also makes possible some
significant optimizations in the conversion. For example, one can clip
a floating point value to any number of integral bits by multiplying the
float by 1<<31 (in the floating point domain), converting to integer,
then shifting right 32-destBitDepth -- no branches required.
The only other place in the audio stack where int/float conversions
happen is in the audio drivers; I'm not speaking from having looked at
the code, but I believe they're also scaling by powers of 2.
Doug
On Thursday, April 4, 2002, at 05:25 , Brian Willoughby wrote:
My comment below is in response to a rather old question and answer
session...
[ Subject: Re: Basic question
[ From: Laurent Cerveau <email@hidden>
[ Date: Wed, 27 Mar 2002 14:59:19 +0100
[
[ If you deal with 16 bits data, then it is possible to represent
[ 65536 different values with this number of bits : as you want to
[ represents data that can be either positive or negative (the sound
[ wave corresponds namely to a variation of pressure around an
[ "average" value in the air), these 65536 will be representing half
[ positive and half negative value. In fact this is not exactly
[ true, as 0 is one of these values and needs to be represented. So
[ there is a little non symetric place in the system. The driver is
[ then mapping these values to the floating range of [-1, 1].
I understand the inherent asymmetry in binary twos-complement numbers
(i.e.
there is always one extra negative value that does not have a
corresponding
positive value with the same absolute value because 0 is positive).
Therefore,
16-bit and 24-bit audio cannot represent the exact same excursion in the
positive range as the negative. This is fine, because each sample
value is the
same voltage difference from the next, and audio mostly doesn't care
about DC
biasing.
But I noticed in the Daisy source code the following algorithm:
utility.c
/* Convert16BitIntegerTo32Float() */
if (*outDataPtr > 0)
*outDataPtr /= 32767.0;
else
*outDataPtr /= 32768.0;
This looks incorrect to me, because it would distort the waveform.
While
16-bit values are stepped such that each increment represents a constant
increase in voltage, the floating result of the above conversion would
be
expanded by 0.00305185% in the positive range only. Yes, that is a
very small
distortion, but any calculations which invert the waveform or add or
subtract
some DC bias would result in those distortions becoming irreversible.
I guess my real question is not whether Daisy should be changed, but
whether
the entire CoreAudio system is expecting this distorted float
representation,
or a more even translation from fixed-point as follows:
*outDataPtr /= 32768.0;
Obviously, the above algorithm would never result in an output of
exactly
+1.0, unless 0.999969482421 gets rounded up to 1.0 (I haven't
checked). But
this technique allows for further processing to be more accurate.
Any comments would be welcome.
Brian Willoughby
Sound Consulting
_______________________________________________
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.
--
Doug Wyatt
work: email@hidden (CoreAudio)
personal: email@hidden
http://www.sonosphere.com
"Live to learn to live."
-- Sign at Wat Chedi Luang, Chiang Mai, Thailand
_______________________________________________
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.