Tír Na HiFi

ah I stand corrected. I was going from memory whereas I should have read the spec again! :-)

Does anyone know how music is stored on a CD [i.e. as a WAV file]. Does it use positive / negative values or does it use positive / two's-complement ?

Some info ..

http://www.delback.co.uk/pcaudiofaq.htm#wavfmt

".....
What's the format of a WAV file?
A WAV file is a particular type of RIFF file. The possible formats for RIFF files are quite extensive, but here I will describe a straightforward WAV file, which is a RIFF file containing just one WAV data chunk.
Header in C-speak:

struct WAV_format
{
char riff[4]; /* the characters "RIFF" */
unsigned long file_length; /* file length - 8 */
char wave[8]; /* the characters "WAVEfmt " */
unsigned long offset; /* position of "data"-20 (usually 16) */
unsigned short format; /* 1 = PCM */
unsigned short nchans; /* #channels (eg. 2=stereo) */
unsigned long sampsec; /* #samples/sec (eg. 44100 for CD rate) */
unsigned long bytesec; /* #bytes/sec (see note 1) */
unsigned short bytesamp; /* #bytes/sample (see note 1) */
unsigned short bitsamp; /* #bits/sample (see note 1) */
char otherstuff[N]; /* N = offset-16 (see note 5) */
char dataheader[4]; /* the characters "data" */
unsigned long datalen; /* #bytes of actual data */
};

Immediately following this header are the actual bytes of data, interleaved by channel. For example, in a 4-channel 16-bit WAV file, the first two bytes are the first sample of channel 1, the next two bytes are the first sample of channel 2, the next two are sample 1 of channel 3, then sample 1 of channel 4, then back to channel 1, etc.
Notes:

#bytes/sec should be set to the number of bytes for all channels (eg. for stereo 16-bit 44.1kHz, this should 176400); #bytes/samples should also be set for all channels (eg. for stereo 16-bit, this should be 4, not 2); #bits/samples should be set for a single channel (eg. for stereo 16-bit, this should be 16, not 32).
WAV format requires the samples to be stored as Intel format integers (ie. least significant byte first) rather than, for example, Sparc format (most significant byte first).
For stereo data, channel 1 is left, channel 2 is right. I don't know the assignment for multi-channel (or even if there is a standard).
Following the actual WAV data, extra descriptive text may be present, which should not be processed as audio data; applications may put in stuff for their own purposes at the end (eg. copyright notices).
"otherstuff" is extra header data that may be present in WAV files written by some utilities. Most utilities do not write anything here (so N=0), but be aware that it might be present.
....."

This does not say anything about two's-complement.

james

James

Audio on a CD is not WAV, but RedBookAudio. Both formats use PCM, but the 'file' structure is not equal.

The RedBook Audio standard says ( http://en.wikipedia.org/wiki/Red_Book_( ... _standard) ):
"the standard also specifies the form of digital audio encoding: 2-channel signed 16-bit Linear PCM sampled at 44,100 Hz. "

and

"Each audio sample is a signed 16-bit two's complement integer, with sample values ranging from −32768 to +32767. The source audio data is divided into frames, containing twelve samples each (six left and right samples, alternating), for a total of 192 bits (24 bytes) of audio data per frame."

Audio waveforms are both positive & negative i.e. above & below the zero voltage signal which is translated into the compression & decompression of the diaphragms of our speaker drivers.

Two's complement is the notation of choice to represent negative numbers in binary encoding & is widely used in computer processing. It assigns the first bit (most significant bit, MSB) as the sign value i.e a 1 in this bit means the number is negative; a 0 means the number is positive

The max positive value in 16 bits 2's complement is 0111 1111 1111 1111 which is +32767
The max negative value in 16bits 2's complement is 1000 0000 0000 0000 which is -32768

So immediately you can see that by using 2's complement we have n imbalance in negative max Vs positive max number. This is well known & the DAC chip manufacturers have taken it into account so as to avoid this imbalance when converting to positive/negative analogue voltages.

Now if you have to expand these 16 bit numbers to 24 bits because you are playing a 16bit file through a 24bits DAC- how do you do it correctly?

Here's what the I2S specification says that you should do - move the 16 bits into the leftmost position of the 24bits & add zeros to the end so we get
0111 1111 1111 1111 becomes 0111 1111 1111 1111 0000 0000 which converts back to decimal as +8388352
1000 0000 0000 0000 becomes 1000 0000 0000 0000 0000 0000 which converts back to decimal as -8388608

You can see that there is a greater imbalance between positive & negative numbers which is not compensated for in the DAC

If this is done correctly by using the sign MSB as the bit to pad out the 24bits you get:
- no change with the positive number
- 1000 0000 0000 0000 becomes 1000 0000 0000 0000 1111 1111 which converts to decimal as -8388353

Immediately you can see that the imbalance between pos & neg numbers is 256 (8388608 - 8388352). In effect what is happening in the 8 bit left shift is that the original 16bit number is being multiplied by 256 (2^8) & this causes the original imbalance of 1 to also be multiplied by 256 to give a 256 imbalance. Now if the DAC manufacturers thought it worth the bother of dealing with the 1 bit imbalance then surely a 256 imbalance should be addressed?

There are many ways to address this but adjusting it in the software player or driver seems to be the most appropriate.

As I said I would love to hear the audible or otherwise effect of this error but can only do so when it is fixed

BTW, good two's complement calculator/converter here http://www.exploringbinary.com/twos-com ... converter/

I am getting more and more confused. I am using the on-line calculator as suggested ..

Suppose we have 8 bits and look at +5 and -5 in binary [using two's complement]
+5 = 0000 0101
-5 = 1111 1011

Suppose we extend to 12 bytes so we add 0000 to both of these [equivalent to multiplying by 16]
and we expect to get +80 and -80 .. Check with the calculator ..

0000 0101 0000 = +80
1111 1011 0000 = -80

That seems to say that adding '0000' works in either case. But if I add '1111' I get

1111 1011 1111 = -65

I must be doing something wrong .. james

Yea, James, I shouldn't have used decimal conversions as it only ends up confusing the issue but I used it to illustrate the imbalance between pos & negative.
But, AFAIK, here's how I believe it works - the two's complement binary stream is generated by an ADC to accurately represent the analogue voltage levels at each sample. The job of the DAC is to accurately reverse this process.

So if we consider an easy to understand DAC - a DAC which uses a series of resistors (one for each bit) that maps to each bit in the word. In other words in a 8 bit DAC, starting from the left side - the MSB determines the sign of the voltage eventually output, next bit produces a voltage, the next bit half that voltage, the next half again & so on for all 7bits. The output sums these voltages to produce the voltage for this two's complement positive value. For negative values the reference voltage (or is it the supply voltage?) is subtracted from this generated voltage

So, forgetting about extending the length of the word for the moment, already we have a problem with using 2's complement - there are two representations for zero - in 8 bits 00000000 & 10000000 both represent zero (+0 & -0). As a result all positive numbers produce a voltage 1LSB less than the correct voltage (unless corrected - which most DAcs do). See this:

Forget about what lower DAC & Upper DAC code mean just note that they are adding 1LSB to all the positive numbers to deal with the above problem.

But that solution does not deal with extending the word length - In extending the word length from 8 bits to 12bits should we first add 1LSB to the positive numbers before we add the extra 4 bits at the end? It all gets complicated at the implementation level.
The negative values have to be actual reciprocals of the positive values - however that is achieved.

Therefore if we pad zero's in the positive values we should pad 1s in the negative values. Forget about converting to decimal, it's only confusing matters, sorry!

Here's a bit more info http://www.scientific-solutions.com/pro ... ions.shtml

Maybe DaceF can correct my errors as I'm sure he knows the area better than I?

This level of detail is beyond me, but I understand how it may be important to getting the last "n"th of sound quality of a dac.

It shows, very clearly, to me, that whilst digital audio maybe mathematically "perfect", there's leeway for interpretation during real world implementation. I'm gobsmacked at the hostility to this kind of discussion elsewhere.

Peter Stockwell wrote:This level of detail is beyond me, but I understand how it may be important to getting the last "n"th of sound quality of a dac.

It shows, very clearly, to me, that whilst digital audio maybe mathematically "perfect", there's leeway for interpretation during real world implementation. I'm gobsmacked at the hostility to this kind of discussion elsewhere.

I was Peter but noticed a post today where somebody newish pointed out a valuable piece of information about one of the ragers posts and immediately the response is hostile. It is just a standard method of operation for these guys. Really if you add them up there is a max of 4-6 people who are in that camp and they just destroy any thread that verges into CA. The same occurs on wigwam and life is too short to bother.
I learned my lesson just go to a forum where you can have a civilized discussion about these topics and be left in peace. You see John's posts here and jplay etc and none of that childish carry on happens but once he posts anything on PFM mayhem breaks out and often people including John and myself get dragged along into the mess. Secretly I think John enjoys goading them!

This 2's complement thing got me thinking about 24bit vs 16bit audio. I have some 24/96 files but haven't as yet heard an appreciable difference in my system. My position is that 16bits is adequate, and domestically, probably more than adequate. If you put 16 bit audio in a 24 bit packet it's getting "amplified" by 8 bits or 256, it would appear that this part of the dynamic range is hardly relevant ? Or am I missing something fundemental ?

The bits represent amplitude of a signal, do they not ? One of my dacs is a 16bit NOS/NDF (No OverSampling/No Digital Filter) dac, which uses paralleled dac chips to get "19bit" amplitude resolution, or so it says on the maker's website. Is this a mathematical artefact of "oversampling" ? It feeds the input signal at delayed time intervals to the chips as if the signal were oversampled. With 8 chips it claims the advantages of 384Khz sampling (for 48Khz input), that's 8 times oversampling, or 2³, and it's the power of 3 that's added to 16 to make 19.

I don't understand what this claim means, nor how it can relate to a signal that's being processed ?

I should really try to read the references about this .. I have an old program that converts numbers from one base to another and I should have a look at it and maybe modify it to do twos-complement. I still don't think I understand the problem ..

james