You have a print that is in Dolby Digital. In one house it reads an error rate of "0" throughout the entire movie, never faltering to "1" or even "0." (zero and a half). Same exact print on a different reader reads the entire movie at an error rate of "7"... never dipping to "6" or "F".

Here's the question: Does this make any actual difference in the audio? I'm not necessarily asking if humans can hear the difference (I'm sure there are some "golden ears" out there who will say they can), but if the audio itself is actually different in any way. I know that due to digital redundancy the DA20 can fill in the gaps, but how accurate is it? Does the DA20 just decide "Yo G, I think I'll put a 0 here. A 1 would sound pretty fly after dat. 1's R da bomb. Dis iz gonna sound mad tight yo, so I'll put another 1 here 2 make it sound even more phiggidy phat. Word." (Note: The DA10 was an older unit, so it used language like "cool" and "awesome" instead of "phat" and "tight" etc). I am assuming that the Dolby Digital unit decompresses the AC3 into an uncompressed audio stream before converting it to analog and sending it out to the processor. How different would that uncompressed audio be in the two scenarios I attempt to describe?

 |  IP: Logged

The end signal will stay the same, The number being displayed is the amount of correction being made to the video signal from the reader. This correction is taken from other parts of the video signal.

I think that is like Audio Cd's: the system is able to correct many errors but the quality will be not the same.

If the number really is just the amount of error correction that is going on then there is no way to tell the difference in sound.

The reason is that if the error correction is successful, then the digital word is recreated EXACTLY...not a close approximation therefore that which goes to the D/A converter is the same for an 0 as for an 8. The way error correction works is to not "guess" but actually know what the bit should really be. The parity system allows this such that the digital word is check a precise intervals with the parity bits such that only a unique word fits with the parity bits that are interspersed thoughout the digital word.

If the digital word cannot be fixed with the error correction then it fails.

I'm not saying that Dolby is using a basic error correction scheme but the parity part is a pretty basic part of digital storage and transmission and it doesn't approximate...it either gets it right or fails.

Steve

 |  IP: Logged

In data communications (like over the internet,) the transmitting computer takes a set amount of data, does a mathematical sumation (called a "checksum") and adds it to the end of the data. So a block of data is really the original data plus a checksum. The receiving computer takes in the data and also does it's own checksum. It then compares it's own checksum to the one that came with the block. If the two checksums agree, OK. If not, the receiving computer can use the checksum to "backward compute" what the original data must have been. This checksum is technically called a CRC (cyclic redundancy check) and there are several different types.

With data transmission over computers, the transmitting computer will hold several blocks of data at a time (usually up to seven.) The receiving computer can ask for a block "re-transmit" (and even ask for a particular block,) if it can't correct or otherwise figure out what it should be. But having the receiving computer figure it out is perfered, because it's much faster.

Ok, dolby digital soundtrack has ridundant data to correct read errors. But what about when the system is not able to have the backup data because... it is not in the redundant data?
Can the system, with higher error rate, start to "guess" the data?
I don't mean to copy exaclty the previous one but, between 1 and 3, choose "2"
I had these informations from Mr Savina, Italian dolby tech consultant. Hoever I had few "rumours" that tell me that perhaps what I wrote is not the truth...

If the data can't be verified...it fails at which time you have a block error and the block is repeated...this not error correction so much as concealment. It takes advantage of psycoacoustic properties that we won't hear a repeated block unless it happens in rapid succession. However, this is NOT error correction and should not be represented in the error thermometer...instead a great big ol "F" is displaced during a block failure (not in Joe's hypothetical situation).

As an example, if you ever get dust on the CCD imager you will get a higher error number all the time since where the dust is will often result an incorrect bit or bits since it will force a "0" for the bits it covers. The system will actually deal with this surprisingly well and it WILL show up if you use an O'scope. It isn't too uncommon to have dust on the CCD too. In order to reduce light reflections in the lens pipe, they are normally roughed up on the inside (honed) this process can generate stray debries that may, over time, fall onto the CCD (or the solar cell in analog readers). I noted that on the new CE 40 series readers, they used a blackened cardboard tube..no doubt a low cost option that achieved similar results without the dusting side effects.

Steve

Dolby Digital uses Reed-Solomon Codes to perform error correction. This is a very much more complex technique than simple parity bits or checksums. A form of Reed-Solomon Code known as CIRC (cross-interleaved Reed-Solomon Code) is used for error correction on audio CD's. This enables CD's to play, even though they are scratched or dirty (up to a point).

I should correct Steve on one point though. "Parity" is a simple method of determining that something is different in the received data as opposed to the original data. It does not encompass a method to reconstruct the data and therefore can only be regarded as an error "checking" mechanism as opposed to an error "correction" system. Even a checksum cannot tell you where the error is, only that there is indeed an error. There are some rather complex checksum systems including CRC (Cyclic Redundancy Checking) which are designed to accurately determine errors over long strings of data, but even these do not enable the reconstruction of defective data.

------------------
Ray Derrick
President
Panalogic Corporation Pty Limited
44 Carrington Road
Castle Hill NSW 2154
Australia
Phone: 61 (0)2 9894 6655
Fax: 61 (0)2 9894 6935

 |  IP: Logged

I don't have to take this from someone that looks like a monkey!

It's been awhile since I worked on this stuff so I will defer to you but....

I seem to recall something called a "Hamming Code" such that one intersperced parity bits within the word (I believe they fell on the 2^n bits) such that one could not only tell if the word was corrupted but depending on the severity of the corruption one could uniquely reconstruct the correct word by complimentary procedures.

Doth my memory fail me? (perhaps I need error correction!)

Steve

------------------
"Old projectionists never die, they just changeover!"

You are correct about "Hamming Code" which was introduced by Richard Hamming in the late 40's. But this was a simple approach and very limited in capability. What I can say, is that it takes quite a bit of mathematical effort and complexity to send data in a form that can be reconstructed without adding too much overhead to the data stream. Parity is a single bit that can be added to the end of each byte (8 bits) in a serial data transmission. It tends not to be used these days because it is very inefficient at accually detecting errors.

It is more common to use checksums which add or subtract the value of each successive byte in a string and append the checksum to the end of the string. When the string is received, the checksum is calculated again and checked against the one received. If they match, it can be reasonably assumed that the data is correct.

For very high accuracy you cannot go past CRC, which has a probability of about 1 in 4 billion of missing an error. This is still a form of checksum but it is calculated by dividing a 16 or 32 bit polynomial by each sucessive byte in a string. As math divisions take a lot of processing in computer systems it can also slow things down.

The only way that I am aware of to actually "correct" errors, short of repeating everything, is to use special coding like Reed-Solomon which provides a reverse calculation path to the original data. Parity and checksums do not have this capability.

Take it from a monkey!

------------------
Ray Derrick
President
Panalogic Corporation Pty Limited
44 Carrington Road
Castle Hill NSW 2154
Australia
Phone: 61 (0)2 9894 6655
Fax: 61 (0)2 9894 6935