Re: AudioConverter gives non normalized samples?!
Re: AudioConverter gives non normalized samples?!
- Subject: Re: AudioConverter gives non normalized samples?!
- From: Doug Wyatt <email@hidden>
- Date: Wed, 28 Jan 2009 08:42:14 -0800
On Jan 28, 2009, at 6:21 , Mike Kluev wrote:
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?
No. The valid range of floating point samples extends to the edges of
infinity. It's only when you try to collapse the infinite down into a
puny integer that you have to worry about bothersome concepts like
"validity." :-P
More seriously, you could think of the range of floating point samples
that will not clip when converted to integer as [-1, 1).
You don't know how close to 1 you can get on the positive side because
you don't know whether the eventual integer has 12, 16, 20 or 64 bits.
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).
That is incorrectly; it should always be multiplying and dividing by
32768. I've submitted feedback to that effect.
Doug
_______________________________________________
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