I am not entirely sure where the current consensus lies with regard to the safety of enabling the C2 error detection with EAC. AFAIK, with many drives it is discouraged because their reporting cannot be trusted, but I thought that with e.g Plextor drives, the C2 (or to be more precise, CU) error reporting could be trusted, as also Plextools Pro relies on it for its supposedly safe extraction method. Well, I've been wrong:

Last weekend I bought a CD (EMI, Beethoven/ Brahms: Triple/Double Concerto) which seems to be a bad pressing, i.e. lots of C2 errors and some CU errors reported by a Plextools scan. It is definitely not copy protected and not scratched, so the fault must lie somewhere else.

EAC managed to extract it without errors (Cache disabled, C2 enabled) after lighting up up to 2 bars of error correction in the first track, the rest were ripped without problems. I was sceptical and tested the first track again (it used max. 1 bar of error correction this time) with the same settings, and got a different CRC despite EAC claiming it to be error free. A WAV compare revealed different samples at the position where the error correction was in work.

OK, I then used Plextools for the same track. On my first try it managed to extract it without problems, but the result was different again from the EAC results! Unfortunately, on all subsequent tries Plextools could not correct all errors and therefore so far I can't compare different Plextools results, but as far as EAC is concerned, enabling C2 does not seem to be secure at least with the Plextor 716A. What a pity!

So the question that remains is: how secure is Plextools Pro? Has anybody tested its safety?

- Strange result. Did you try EAC without C2 as well?

- I can't find back the thread in question, but in that thread it was found that after error detection & subsequent recovery, Plextools' report that "all errors have been recovered", is not to be trusted. When no errors are detected, Plextools hasn't been caught yet having overlooked errors, AFAIK. Anyway, many Plextools users rip twice and compare results to be sure about the quality of the rip.

> how secure is Plextools Pro?

It has been highlighted before, no matter what the drive statistically errors can creep thoughthe use of c2 (if you wanted a very secure crc algorithm it would have to be 2x the original data length - ie duplicate the data 3 times, not a few bytes per 2352).

Anyhow AccurateRip should be your friend to inform which of your rips was correct.

How does this prove that C2 reporting is to blame?

If EAC didn't have to do any re-reads and Test & Copy CRCs didn't match then I'd be more inclined to agree with you in that incorrect C2 reporting would be the most likely culprit.

EAC can easily rip a disc inaccurately and report that there were no errors with or without C2.

Have you tried reducing the ripping speed? This might help in ripping the track accurately. Hopefully the disc is in Spoon's database so you can determine if the rip is right or not.

I haven't tried EAC without C2 on this disc yet, but I suppose it would be secure.
However, I managed to get another Plextools rip of the first track without errors, and it is identical to the first Plextools rip. Of course this does not prove that Plextools is to be trusted, but at least it does not screw up everytime
BTW, here's a scan of the disc in question:



How is this possible? I always thought it to be at least extremely, extremely unlikely to get matching wrong read results if a sector is read twice. Can you point out examples/threads that deal with this issue?

It isn't extremely unlikely at all, I have seen it happen quite often with discs that are flawed.

Here's the example that I posted not too long ago:
http://www.hydrogenaudio.org/forums/index....post&pid=397734

Precision does not mean accuracy.

10450 C2 errors and 6 C2 errors. You are exactly in the configuration where you can get "no errors occured" with a bad rip. Even without C2.

If you have got 100,000 CU errors, it is unlikely that they are all exactly the same when you read twice.
But with 6 CU errors, it is likely that you have 6 samples damaged by one read error. If this read error occurs twice, EAC won't detect the problem.

With C2 enabled, EAC detects the error. Then it rereads, but no luck, the error occurs more often than the correct data. EAC then believes that this is the correct data and stops the correction process.
This is a case where C2 is more secure than reading twice.

Unfortunately, EAC only uses C2 to detect errors, not to correct them.

So in effect this means that neither C2 enabled nor disabled is secure. Even burst mode test&copy would probably not be secure in this scenario, right? What an annoyance. So the only really safe way would be Accuraterip, I suppose.

Edit: But doesn't EAC rely on the C2 error pointer also during the re-reads? If the drive reports the same error every time, it still reports an error and EAC should not take this to be the correct data. Or am i missing something?

I don't believe that you are using the term "secure" correctly. IMO, a secure rip is not necessarily an accurate one.

As far as safe, positive matches with AccurateRip can be trusted. When AccurateRip says that a track wasn't ripped correctly, it could still be that the disc isn't in the database.

As far as I know, EAC doesn't take C2 into account at all during error correction. So the drive still reports the error, but EAC doesn't listen.
There was one version of EAC which implemented the use of C2 during error correction, like Plextools. But it didn't work when I tested it, and it was abandonned in the next version.



Not if they are the CRC that you yourself submitted one week before from the same defective CD

PS : and AccurateRip will also overlook errors caused by bugged drives, like some old Toshiba (error in the middle of the CD), Samsung (audio muted near the end of every track), or Teac (consistent synch errors), that can be reproduced bit for bit by different owners of the same drives.

This is my understanding also.
D'oh!!
Smart-ass!
Thanks Pio!

Indeed, EAC uses C2 pointers for the first read only (which doesn't make much sense already),
then it stops requesting them from the drive during the re-reads. A funny experiment regarding
these is to use a drive which caches and uncheck 'Drive caches audio data' : after the initial read,
all blocks of 27 sectors are read from the cache, so you would expect EAC to stop at the second
read. Nope, it keeps re-reading the same sectors with the same values 10, 20, 50 times from
the cache ; then suddenly EAC decides it had enough and it reads the next sectors from the
cache, again and again, but a different number of times. And so on and so on. Another brilliant
undocumented algorithm from Andre I guess

Sometimes it will stop after one set of re-reads. Either one row will light or all rows will light has been my experience.