Re: AudioConverter gives non normalized samples?!
Re: AudioConverter gives non normalized samples?!
- Subject: Re: AudioConverter gives non normalized samples?!
- From: Brian Willoughby <email@hidden>
- Date: Thu, 29 Jan 2009 02:10:56 -0800
On Jan 29, 2009, at 00:42, Mike Kluev wrote:
Brian Willoughby <email@hidden> wrote:
Yes. I deleted Mike's asymmetrical conversion range,
that was not mine but Apple's :)
Sorry. I had no idea that Apple hadn't replaced all of that bad
sample code. It's hard to believe it's still there, after the number
of times it's been discussed on this list. Somebody file a bug report!
but I wanted to reinforce the fact that the mul/div factor should
always be the same for both positive and negative, and it should
be a nice power of 2. Anything else creates distortion,
especially in pass-through situations. Many programmers obsess
about reaching that last sample value for certain waveforms, but
the truth is that twos-complement integers are asymmetrical by
design, and you cannot fix this by using an asymmetrical
conversion - it just turns out worse.
I think the same. But still, do you guys know of any papers or
references
to internet pages, etc. that detail why the factor should be (1)
the same
and (2) a power of two -- to not cause distortions? I want to present
this information to our audio guys from a separate team that for some
reason use 0x7FFF instead of 0x8000 as the scaling factor in another
project.
This is a matter of basic mathematics and numerical representations.
If you multiply part of a waveform by one factor, and another part by
a different factor, then you have distorted the shape of the
waveform. That's more of a "by definition" kind of statement, rather
than something that needs to be backed up with an elaborate paper.
The power of two is also elementary, given that we are talking about
binary number representations in both the case of fixed and floating
point numbers.
One very convincing argument for 0x8000 is that CDDA data passed
through 32-bit float will come out the DAC undistorted. With 0x7fff
you end up with altered data in the simplest case. But there are
many other examples.
If you really need to convince someone who's not up to par with their
math skills, then maybe you can point them to the archives of this
mailing list where Apple engineers have backed their CoreAudio design
choices many times over.
Brian Willoughby
Sound Consulting
_______________________________________________
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