Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
Re: Audio recording bitdepth
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Audio recording bitdepth




On Dec 9, 2009, at 9:02 PM, Brian Willoughby wrote:

The problem with this whole thread is that there is no downgrade in fidelity with the conversion method used by CoreAudio. All the rest of the comments assume that there is a superior method when there really isn't one.


Bjorn proposes in his blog that there are two good choices for conversion methods. I'll call them A and B. Method A is used by Apple in CoreAudio. Method B is the 'asymmetrical' option. Bjorn claims that they are both good, with each method having specific benefits and drawbacks. The problem is that Bjorn's hypothesis has not been peer-reviewed, and does not stand up to basic mathematical principles. Bjorn's own tests do not reveal the flaws in method B because his tests are incomplete and do not have a solid basis.

It's true I didn't have my BLOG ENTRY pear reviewed, LoL.

As for not having a solid basis, I admit I did not concern myself with the mathematical details which are complex, and not really worth my time for a blog entry. They have been covered in academia, I believe and I'll see if I can find a reference. I did, however, address the apparent asymmetry of 'Method B', as you call it, in passing.

In a nutshell, Bjorn's asymmetrical conversion introduces non-linear distortion by processing positive values differently than negative values.

Depends on what you mean by linear. I am talking about dynamic systems and that's what I tested. Would you consider a 1-bit converter non- linear? It is only linear because of dither, after all, and in the same way Method B is linear.


Ross' comments about CPU efficiency are a diversion from the fact that all processing on the distorted waveforms would make this distortion irreversible.

Agreed.

Bjorn's tests only happen to reverse this non-linear distortion for the one special case where no processing is done on the audio, which is clearly not an option for someone using Logic, or even for someone combining music and system sounds on the same interface.

This is a best-case, actually. There is no sense in measuring distortion after DSP.


Thus, asymmetrical conversion would not work for most application, and since you can't use different conversions for different applications you much use the CoreAudio conversion (or equivalent). That's the trouble with designing your own tests, because your assumptions are masked by the implementation of your tests.

Now I am being flamed for running tests! I have to admit I didn't see that one coming! :)


[snip]

For anyone interested in the other flaws in Bjorn's blog entries:

* Bjorn claims that when A/D converters clip around -.5 dBFS, that it's equivalent to (2^n)-.5, which is completely false. This clipping happens entirely in the analog domain, before quantization to digital codes, so it is not equivalent to (2^n)-.5 because the converter is still based on 2^n. What happens before the A/D conversion cannot be precisely equated to binary math. These comments show a lack of understanding of the A/D process as well as mathematics.

Wow, that wasn't my claim at all. My claim, perhaps poorly written, was that full-scale positive less 1 is less than .5 dBFS on most converters and that experience has shown that many converters happen to clip around .5 dBFS. Meaning that there may not be much point in optimizing the heck out of +1 anyway, which is actually a point in the 2^N (your) camp's favor. I admit this could have been better written.


* Bjorn claims that +1 occurs in the real world, but that's not true. The only real world is the analog world, and no A/D converter allows the +1 value. In the virtual world of VST synths, +1 is certainly possible, but only a problem for developers who try to get closer to the 24-bit maximum than the 16-bit maximum. In contrast, hardware DSP chips have embedded sine wave ROM tables which e.g. only span +/- 32766. No attempt is made to reach +32767, and certainly not -32768, because 2 LSBs of headroom is immaterial. 32766 is only 0.00053 dB below full scale, and nobody really cares to risk clipping for such a miniscule gain in signal level. A 24- bit variant would just synthesize waveforms without getting so close to clipping. 24-bit codes could be a tiny fraction louder than 16- bit codes, but not enough to warrant the risk of clipping with 16- bit audio interfaces. In other words, Bjorn is actually looking at a real issue worthy of discussion, but the suggested solution is entirely wrong.

Actually, that was an answer to a question. The question was "The question is whether or not this matters.... My Opinion?". So you admit I was looking at a real issue worthy of discussion (presumably, whether or not +1 matters), and I think it's pretty clear I was stating an opinion (that it does matter) rather than stating fact. So we disagree. I don't think stating my opinion makes the entry factually "flawed" if it is labeled as such.


* Bjorn synthesizes sine waves and then tests distortion outputs, all without specifying the source for the sine data. The standard C math library sin() and cos() functions use linear interpolation to produce the values, and so Bjorn's original data has distortion from the start. In other words, those are not pure sine waves! Thus, the tests that are cited are nothing more than fun and pretty pictures, and they are certainly not mathematical proofs of the bad assumptions made about asymmetrical conversions.

Look at the diagrams. I show the original sine waves in the FFT plots subject to the exact same analysis. You have to look closely because they are just spikes. No noise. This is a standard analysis methodology used, for example, when analyzing dither.


	bjorn

-----------------------------
Bjorn Roche
XO Wave
Digital Audio Production and Post-Production Software
http://www.xowave.com
http://blog.bjornroche.com
http://myspace.com/xowave


_______________________________________________ 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
References: 
 >Re: Audio recording bitdepth (From: Doug Wyatt <email@hidden>)
 >Re: Audio recording bitdepth (From: Bjorn Roche <email@hidden>)
 >Re: Audio recording bitdepth (From: Bjorn Roche <email@hidden>)
 >Re: Audio recording bitdepth (From: Bjorn Roche <email@hidden>)
 >Re: Audio recording bitdepth (From: Paul Davis <email@hidden>)
 >Re: Audio recording bitdepth (From: Bjorn Roche <email@hidden>)
 >Re: Audio recording bitdepth (From: "Ross Bencina" <email@hidden>)
 >Re: Audio recording bitdepth (From: Brian Willoughby <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2011 Apple Inc. All rights reserved.