EAC secure mode test proposal, Testing its real accuracy Options

[tigre]

Edit : this discussion is splitted from this thread : http://www.hydrogenaudio.org/forums/index....=ST&f=20&t=8849

Well, actually errors 'always' (99.99...%) return different data for every new read.

How do you know that? it might be 60%, or 10%, because it cannot detect when the data is the same you cannot put a % on it. When AccurateRip makes its way onto EAC then you could put a percentage on it.

A. I haven't read anything about a "validated" percentage like this anywhere (wrong_samples_noticed_by_EAC_due_to_non-matching_results_on_re-read / total_number_of_wrong_samples).


B. This could be tested (volunteers appreciated) like this:

1. You need a (set of) reference .wav file(s). For this either rip a CD in perfect condition, EAC secure mode, ideally compare the CRC to a identical disk's ripped by someone else (cheers to AccurateRip ) or choose some .wav files, burn them to CD-R and make sure you keep them unchanged on your HDD.

2. Take the CD(-R), damage it (e.g. different kind of scratches, caused by screwdrivers, sandig paper, ...; dirty fingerprints; draw lines with a thin marker on the data side; ...). Start carefully and try what happens in the next steps. If the disk turns unreadable and causes timing problems/sync errors in burst mode this won't work ...

3. Extract the damaged disk two times in burst mode resulting in a.wav and b.wav.

4. Do wave substractions (Cool Edit: mix paste - overlap - invert checked) r-a.wav=reference.wav - a.wav and r-b.wav = reference.wav - b.wav and a-b.wav = a.wav - b.wav using Cool Edit or another wave editor capable of that - make sure that dither is disabled in this and the next steps.

5. We want to know how many samples have been turned "wrong" by damaging the disk, so we create a Cool Edit boolean operation™ like this: if a sample has been read correctly in a.wav, the corresponding sample in r-a.wav will be 0, otherwise something =|= 0. To find samples that are wrong in a OR b, we add r-a.wav and r-b.wav. To prevent errors here we multiply both files with themselves (Cool Edit: mix paste -> modulate), so all values are 0 (correct) or >0 (wrong). To prevent errors here (Cool Edit devides by 32768 after multiplying, so values -182<y<182 will turn 0 due to rounding) we amplify both .wavs by 100dB before. This will lead to 0 values = correct and 32767 values = incorrect (-> amplification by 100 dB makes all samples =|= 0 clip in 16 bit resolution). So the steps are:

5.1. Amplifying: r-a_100.wav = r-a + 100dB; r-b_100.wav = r-a + 100dB
5.2. Copy r-a_100.wav to clipboard and mix paste - modulate r-a_100.wav with data from clipboard, result: r-a_100m.wav; do the same with r-b_100.wav => r-b_100m.wav
5.3. Add (= Cool Edit mix paste - overlap) r-a_100m.wav + r-b_100m.wav = wrong_samples.wav

In the file wrong_samples.wav. we have now all 0 samples stand for correctly extracted samples in both EAC burst mode runs while =|= 0 samples (32767) stand for extraction errors.

6. Now first interesting thing to do IMO would be to have a look at the error postitions. Are there isolated wrong samples or do they occur as blocks / "bursts"?

7. Now we want to know how many of the wrong samples have gotten different values in the two burst mode runs so EAC secure mode would have detected them. For this we
7.1. apply steps 5.1 and 5.2 to a-b.wav resulting in a-b_100m.wav
Step 7.2.
7.2.1. Take a-b_100m.wav and apply Channel Mixer -> Full mix (L = L+R; R = L+R). -> detected_errors.wav
7.2.2.: multiply wrong_samples.wav with detected_errors.wav (Mix Paste Modulate) and substract the result from detected_errors.wav, resulting in the corrected undetected_errors.wav.

The result will contain 0 samples for correct samples and detected errors and 32767 samples for undetected errors.

8. Counting the Number of 32767 samples in wrong_samples.wav (W) and in undetected_errors.wav (O) will enable you to calculate a percentage of correctly detected errors: P=(W-O)/W

Have fun

edit:
Additionally we could rip 3 or 4 times in burst mode instead of 2 times to find out if and how often Test & Copy in secure mode without C2 detects addtional errors.

And we could rip in secure mode, C2 enabled (if drive capable) to find out the "P" value for the drive's C2 detection.

edit2: changed some "?" to "=|=" which means "un-eaqual"

edit3:
I missed one thing: If in the 1st 2 reads an error occurs, the sample is re-read in both channels, no matter if the error was detected in one or both channels. So "undetected" errors in one channel are in fact detected if there's a detected error at the same postion on the other channel.

To take this into account in the test, step 7 is modified (see above).

This post has been edited by tigre: May 6 2003, 10:28

[Pio2001]

Tigre, your result is interesting. How does look like the difference between the reference and the rip ? It seems that errors come by bursts, which is not surprising, granted your CD is dirty and scratched.
In my calculus, I've found that an elementary burst error (in drives correcting E42 errors without the help of EFM pointers) spreads into a range of 543 samples after de-interleaving, thus reading a +/- 600 range would allow to correct an elementary burst error when one sample (out of 60) is detected in them.
Getting stronger errors doesn't increase the width very much : 6 samples each lost frame (the elementary burst error being 17 lost frames spread into 91 after de interleaving).

The first problem will be drives not using EFM pointers for error correction, with them, there is no such thing as an elementary error. You can have isolated wrong samples.
But the main problem will be non-burst errors, such as those that occur when, instead of a damaged CD, you try to read a decaying CDR, or with a poor drive that tries to read a CD faster than it should. The result of your test might then look completely different.

Here are, in pink, the distribution of burst errors I get on the Memorex DVDMaxx 1648 drive, on the black mark of the DAE quality test CD, in number of errors.



Each pink square stands for a burst error. Their height is the number of errors they are made of. They are just sorted horizontally by ascendant number of errors. Actually, each square is the number of errors recorded in a 44100 sample range, thus some of the intermediate points might just be 60 samples burst errors overlapping into two contiguous ranges. The blue dots are not to be taken into acount.

Here is the same thing, in blue dots instead of pink, but with a decaying CDR instead of the DAEquality test CD, thus givin random errors instead of burst errors :



In this situation, the errors don't gather in clusters, and reading a range around them shouldn't help in any way. Not anymore than reading any other part chosen at random.