Re: Native Device Formats
Re: Native Device Formats
- Subject: Re: Native Device Formats
- From: "Mikael Hakman" <email@hidden>
- Date: Mon, 9 Jun 2008 12:38:20 +0200
- Organization: Datakonsulten AB
Richard, Brian - a very interesting topic, this one. I understand what you
are saying, I agree with some of it, and I disagree with other parts. In
particular I disagree with parts that are pure assertions and/or assumptions
without any rational explanation or proof, such as e.g. that using inclusive
[-1.0, +1.0] range mapping when working with CD data would cause distortion
and therefore we are forced to use [-1.0, +1.0) exclusive mapping. If you
use lossless mapping from signed integers stored on a CD to float, which
[-1.0, +1.0] mapping is, and you interpret the numbers in the same way as
they are meant to be processed by a DAC, then no distortion will occur.
Likewise the assertion that suitability or convenience of a particular
mapping depends on the source of digital audio is given without any rational
explanation, verifiable support or proof. It would be a good argument if it
was true, and this is the reason why you use it.
For most parts you are describing how thing are, not why they are this way,
which was my original question. The closest thing to an explanation is
Richard's assertion that this +1.0 exclusive mapping provides "a nice simple
mapping between the integer form and the mantissa of the float", meaning, I
suppose, that you can do the conversion by bit-twiddling (faster) instead of
division and multiplication (slower). This is true, but equally nice simple
mapping exists even when using inclusive +1.0 mapping.
However, my purpose here is not to argue but to have an enlightening
discussion from which we all can hopefully learn something. First of all, I've
been using ASIO in a large number of projects. ASIO allows you to output
(and input) the exact digital values (the bits) to (from) the digital wire.
Therefore you are free to work with any representation you want in your
application and then it is your responsibility to convert to (from) the
signed integer values of appropriate for your project bit-width before
outputting (after inputting). In all projects I used therefore inclusive
[-1.0, +1.0] range and then converted to/from 16-bit or 24-bit signed
integer representation just before (after) outputting (inputting). I didn't
notice any problems, whatsoever, with this. On the contrary, as I said
before, this is very convenient, and less error prone than this exclusive
+1.0 mapping.
My main business in this context is not creating music or other audio, but
precision testing of audio devices and audio algorithms (including DAC/ADC
devices). This is done by pumping specially designed signals through a
device or an algorithm under the test, recording the resulting signals, and
then analysing the signals. My tests give much more exhaustive information
about a device or an algorithm than the few simple numbers normally
published in the specs. For example, a THD+N of -100 dB at 1000 Hz during a
steady-state test don't tell you much. THD at 12 kHz during the first few
milliseconds or even less (attack time) after a saxophone starts playing
from a complete silence, is much more relevant. My test procedures go down
to about -320 dB (the theoretical but experimentally verified limit of
Float64 computations). If there where any problems with this inclusive +1.0
mapping then I would see it. I don't.
So, what is causing this exclusive +1.0 confusion, or as Richard express it,
"this marvellous old can of worms"? Consider a series of numbers consisting
of following values: +1.0, -1.0, +1.0, -1.0, etc. What signal does this
series represent? It represents a pure sine wave with a frequency of half
sample rate, sampled at ½ PI, ¾ PI etc. Also, its DC offset is exactly 0.
When storing these numbers in computer, the wave gets congested by -320 dB
THD if using Float64 and by THD -192 dB when using Float32. Whether this
distortion is harmonic or not is arguable.
Now, consider the following series of signed 24-bit binary integers:
0x7fffff, 0x800000, 0x7fffff, 0x800000, etc. The values are the maximum and
the minimum of a 24-bit number, and these are the values transmitted by
S/PDIF and processed by a DAC. What does this signal represent? Two answers
are possible.
If you say that this series represent the same wave as the above +1.0,-1.0
series then you must withstand that the binary integer value 0x0 is not
signal value 0. The signal value zero is half way between binary 0x0 and
0xffffff - i.e. it is not expressible as a bit combination. This doesn't
mean that you cannot output silence. A series of any constant numbers will
be interpreted as a silence with a corresponding DC offset. A series of
0x0:s will be interpreted as a silence with DC offset ½ bit out of 24.
If you, on the other hand, require the signal value 0 to be represented by
binary 0x0 then the consequence is that the above integer series doesn't
represent pure sine wave. This is because a pure sine wave is symmetrical
around 0 but the above series isn't - negative half is larger by 1 bit than
the positive half. It is a distorted sine wave but only if you persist that
binary 0x0 shall be signal value 0. There you have your distortion.
The interesting questions now are:
1. What would you like it to be?
2. What does current DAC semiconductor components do? How do they interpret
this series?
Depending on the answer to the above questions, you could arrive either to
conclusion that inclusive [-1.0, +1.0] mapping is very adequate, or that you
shouldn't use the most negative integer value at all in which case the
inclusive mapping is still ok.
Regards/Mikael
_______________________________________________
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