For a 16-bit ADC with a single rail V & input biased around V/2, the minimum and maximum read values (0 & 65535) represent (tiny ranges of) input voltages with the same magnitude (i.e. maximum magnitude); similarly, 32767 & 32768 represent input voltages with the same magnitude (minimum magnitude).

If such ADC values are stored in a 16-bit signed integer PCM file by subtracting 32768 (to convert from unsigned integer to signed integer), then 32767 & 32768 become -1 & 0.

Should signal processing applications treat -1 & 0 in a signed integer PCM file as having the same magnitude? E.g., in C:

short pcm_value; // [-32768, +32767]
float amplitude;
...
amplitude = (pcm_value + 0.5) / 32768; // (-1, +1)
or perhaps
amplitude = (pcm_value + 0.5) / 32767.5; // Normalised to [-1, +1]

Obviously, this could apply similarly for other bit depths and is potentially more of an issue for 8 bit.

If this reasoning is correct, does it also apply to wav, aiff, etc., or are these specified such that the PCM range is asymmetric?

TIA,
bandpass

I found the answer: it would seem that ADCs/DACs come in all shapes & sizes; some have a fixed half-bit offset, other can be configured with or without the offset. In any case, you can bias them up pretty much any way you like so with a raw ADC/DAC it has to be handled on a case-by-case basis.

With PCM file formats it would seem that asymmetry is king:

wav: http://msdn.microsoft.com/en-us/library/ms...audiodataformat

Data format Maximum value Minimum value Midpoint value
8-bit PCM 255 (0xFF) 0 128 (0x80)
16-bit PCM 32,767 (0x7FFF) - 32,768 (0x8000) 0

(of course, 0 isn't the midpoint, but I assume they mean the zero energy point)

au: http://docs.sun.com/app/docs/doc/817-3945/...a=view&q=au

All of the linear encoding formats are signed integers centered at zero.

aiff: http://developer.apple.com/DOCUMENTATION/q...mgr.6.htm#38753

For example, for 8-bit noncompressed sound data stored in a sound resource, each sample point is similar to a value in a wave-table description. These values are interpreted as offset values, where $80 represents an amplitude of 0. The value $00 is the most negative amplitude, and $FF is the largest positive amplitude.

All of which means that you can't perform even a simple operation like inversion on a PCM signal without having to check for clipping!
Oh well...

-bandpass

You don't have to check for clipping if you do it right. The key is that for every signal value there is a corresponding inverted signal value.

In the case of 8-bit audio, the inverse of 255 is 0 and vice versa. the inverse of 128 is 127. For 16-bit data, the inverse of 32767 is -32767, the inverse of 0 is -1, etc.

All this means is that the so-called midpoint is not really the midpoint, since its inverse is not iself, but one different. The true midpoint is halfway between these two values.

Yes, you don't have to check for clipping if you do it as you suggest; however it's not right to do so as it introduces a DC offset. According to the specs, 0 (for signed) not -0.5, is the value for zero amplitude.

Of course, if this were an engineering discussion, no one would be worried by the odd 1/2 a bit, but as it's a scientific discussion, we must insist on being precise!