Re: AudioConverter gives non normalized samples?!
Re: AudioConverter gives non normalized samples?!
- Subject: Re: AudioConverter gives non normalized samples?!
- From: "Mike Kluev" <email@hidden>
- Date: Wed, 28 Jan 2009 17:21:11 +0300
On Tue, 27 Jan 2009 14:37:19 -0800
Brian Willoughby <email@hidden> wrote:
What kind of 'overflow' are you seeing, Mike?
Are the values clipped, or are they literally overflowing from
maximum to minimum (or past minimum to maximum)?
The latter. They overflow like this (i am making the values up,
the actual values differ):
+30000, +31000, +32000, -32500, +32000, +31000, +30000
where -32500 supposed to be +32767.
That's not only a picture that is wrong, the sound itself sounds
wrong (has additional "metal" in it).
However, this might not be related to AudioConverter, see below.
On Tue, 27 Jan 2009 11:56:48 Jeff Moore wrote:
On Jan 27, 2009, at 9:55 AM, Mike Kluev wrote:
Does AudioConverter correctly clips overflown samples when it
converts from floats to shorts? I do some mic recording +
postprocessing, putting the result into PCM file (samples are
shorts) and noticed that the wave form is not "nice" due to
overflow on the said out-of-bounds samples. If I manually
clip sample values to the -1 .. +1 range the wave form is ok.
Yes. The float-to-int converters all use saturation instructions during the conversion.
It turns out that the particular client code I was testing my driver
with
is based on the old Sound Manager's SndRecord. When I tried it with
my own code that implements recording with AUHAL this problem
disappears. Looks like there is no problem with float to short
conversion
in AudioConverter but there is such a problem in Sound Manager
that very likely doesn't use AudioConverter for it's conversions.
BTW, if you have out-of-range samples in the raw recording, after
analog-to-digital conversion, it is generally too late to do anything
about it. You need to watch your headroom on the signal feeding
into the ADC and keep it from clipping before it gets into the
computer. That's the only way to get a clean signal.
Well, my input signal was in the range -1 .. +1.
I only get out of this range after several sample rate conversions.
Now that you mentioned this, I wonder if [-1..+1] is really the
proper range...
After all, the whole range (in shorts):
-0x8000 .. 0 .. +0x7FFF should correspond to the whole range (in
floats):
-1.0 .. 0 .. +max
where -0x8000 maps to -1.0; 0 maps to 0.0 and +0x7FFF maps to +max
(and vice versa) preferably in the "even" manner (a "1" increment in
shorts
should correspond to some increment in floats and this unit float
increment
should be the same across the whole range.)
Given this, the max in floats should probably be 0x7FFF/0x8000, that
is 0.999969482, and the actual range of valid floating point samples
should be [-1 .. +0.999969482]. Isn't it?
The following "Clipping and Converting Samples" addresses this
differently
by using different factors for negatives and positives:
http://developer.apple.com/DOCUMENTATION/DeviceDrivers/Conceptual/WritingAudioDrivers/ImplementDriver/chapter_4_section_5.html
if (inSample >= 0) {
outputBuf[sampleIndex] = (SInt16) (inSample * 32767.0);
} else {
outputBuf[sampleIndex] = (SInt16) (inSample * 32768.0);
}
...
if (inputSample >= 0) {
*floatDestBuf = inputSample / 32767.0;
} else {
*floatDestBuf = inputSample / 32768.0;
}
But that adds compare per sample and besides that it doesn't look
quite correct, because of different factors for negatives and
positives
(e.g. the value 32767 is "louder" than the value of -32767 and is as
"loud" as the value of -32768).
Mike
_______________________________________________
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