Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: ADC -> integer PCM file -> signal processing (Read 6809 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

ADC -> integer PCM file -> signal processing

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

ADC -> integer PCM file -> signal processing

Reply #1 –
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

ADC -> integer PCM file -> signal processing

Reply #2 –
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.

ADC -> integer PCM file -> signal processing

Reply #3 –
Quote from: pdq on
You don't have to check for clipping if you do it right.

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!