Hello Everyone,
I was going through the HA KnowledgeBase Project and came across the Ripping Guide with EAC. I have noticed that while configuring EAC, we take EAC's C2 and cache detection to be accurate. However, it is well known that this is not the case. I think that in order to be absolutely certain of obtaining 100% accurate rips, we should disable C2 and the drive's cache for ANY drive-regardless of what EAC reports. I know that this will tremendously slow down the ripping process, but we will ultimately achieve what we want to achieve by using EAC-100% accurate rips. What do you folks think? Thanks.

It was me who started writing the EAC guide a month or so ago, I wrote the stuff before the "EAC Options" section. I haven't had enough time to finish the guide, unfortunately, so someone just embedded SatCP's tutorials in there for the meantime (I personally think it's a bad idea). I'm currently revamping my own webpage which is top priority for me at the moment, but as soon as that's done, I'll get on with that EAC tutorial. Anybody who feels inclined can improve it if they wish.

I personally would also recommend not using C2 - for one, I obviously don't know by heart which drives operate reliably with C2 enabled , and also, the issue would be a little complicated to explain in a newbie-friendly guide (perhaps that's just me though).

Perhaps if there were to be a separate guide about circumventing copy protections on audio CDs, one could present a more in-depth explanation of the whole C2 issue, since good C2 capability is a requirement to successfully defeat some of these copy protection schemes. I'm not competent enough to write such a guide, though.

It is important IMHO(*) to recall that C2 accuracy can be tested with the DAEquality package.
But actually, C2 accuracy, as quoted above, has nothing to do with protected CD reading. The best drive for protected CDs might very well not support C2 at all.

(*)I say IMHO, because so far I've seen a lot of people interested in C2 accuracy, and nearly no one interested in the DAE quality package ...

My statement was based on various claims I've repeatedly seen in the IRC channels that CDs protected with mechanisms like Cactus Data Shield, which operate by means of mastered C2 errors, are much easier to read correctly if the drive has good C2 capabilities. To be honest, I haven't read the related threads here in the forum, so I couldn't judge whether those claims are valid.

This is just a confusion between good C2 ability and good C2 ability .

To clear things up :

What is called "C2 error" in EAC is an "uncorrectable C2 error".
Drives can correct one, two, sometimes three or four C2 errors per frame (1 frame=6 samples) without reporting anything since all is perfectly 100 % corrected. This amount is one of the main features that will influence the presence of clicks in a successful CDS CD rip (after having passed through the corrupted TOC).

When the drive can't correct C2 errors, because there are more of 2, 3 or 4 in a single frame, it interpolates them. They are then called "CU errors". A CU error is eventually a wrong datum (or right by incredible luck). Some drives report it outside, as Feurio, CDSpeed, EAC etc can read. These softs then say that the "the drive have reported C2 errors", while it actually reported CU errors, that are uncorrectable C2 errors, and thus that the "data is incorrect".

If these drives miss some CU errors and report nothing, they are called "not C2 accurate". But this has nothing to do with their ability to correct 2, 3 or 4 C2 errors per frame, or to flag individual uncorrectable C1 errors (also appreciated for CDS200 ripping).

There have been a debate about the drives ability to really report regular C2 errors as well as CU, because Feurio's help files state that drives should actually report both corrected and uncorrected C2 errors.
There was no conclusive test. It seems logical to assume that drives report CU errors (useful info) and not correctable C2, and if the drives reported all C2 errors, as Feurio pretends, there should be lots of them in perfect rips.
I've not got Plextools nor K-Probe, but as far as I can see on the screens posted, they don't seem to distinguish between C2 and CU either.

A nice explanation Pio2001, thanks.

Information by Spath, that confirms what I once heard : http://forum.cdfreaks.com/showthread.php?s...=&postid=480032

Some drives report all C2, and some drives report just CU. Plextor Premium reports both to Plextools.

That's right, Pio.
Anyone with a Plextor drive can see in his PlexTools ripping logs that C2 and CU errors are reported separately.

When I rip with Feurio I can see all kind of C2 errors (C2+CU) reported as C2 errors, and most of them were corrected. This is the classic way of reporting C2 errors, basically because it's what Plextor has always done I guess, and it's good to know the condition of the discs. It's not so good if the software tries to correct all those positions that were already corrected by hardware.


Just to clarify, we can't disable drive's cache.
We just tell EAC that drive has a cache in order to flush it after every operation, which is what slows down the ripping speed (apart from reading twice).
Selecting "drive caches audio" is necessary if you have a drive like that.
Leaving C2 enabled is not that important.
Most errors will be corrected and the rest will be probably inaudible.

Thanks for the explanations, Pio and minix.

Looking for example at the 52x burners tested at CDRinfo, you can see as C2 accuracy : 20%, 87%, 99%, 5%, 26%, 100 %

This is the proportion of errors detected with C2 on.

Yes.
I mean that if you configure "drive caches audio" as disabled when your drive caches audio, then EAC will be totally useless.

With C2 errors enabled, you will probably lose some errors, but you would have seen that there were errors on the disc, and you have the chance to rip again with C2 disabled.

I don't really know, but I have the feeling that those accuracy percentages are representative when there are a lot of contiguous errors.
I mean that I think that drives can't accurately report C2 errors when there are consecutive C2 errors. But you'll get some of them at least, and you are aware that the disc is not perfect.

Exept if EAC corrects all of them, then the lost percentage is incorrect.

well, I always check the red lights to see if correction was needed.

That's something you can't do if you incorrectly set the "drive caches audio" option. That's what I wanted to say.

> Just to clarify, we can't disable drive's cache.
> We just tell EAC that drive has a cache in order to flush it after
> every operation, which is what slows down the ripping speed (apart from reading twice).

Just to clarify further

It is possible on most drives to disable the cache and make sure all data come
from the disc by using the FUA (Force Unit Access) bit with your read commands
(0xD8, READ(6), READ(10), etc). For instance CDParanoia provides this feature.

Since EAC doesn't use FUA and since there's no 'flush cache' command it tries to
page out the cached data by issuing multiple reads at other locations. Note that
disabling 'Drives caches audio data' makes EAC behave erratically so it should
definitely be avoided anyway.

interesting info, spath.

I'd always wondered why it was so slow to flush the cache...


well, I've always disabled that option with the Ultraplex40x because it doesn't cache audio data and it's faster.
what do you mean by erratic behaviour?

BTW, am I right to think that a unique C2 error produced when reading will be always reported?

Any chipset can correct a unique C2 error, or even two C2 errors in one frame. Thus in the final data, if the error correction failed, there must be at least three C2 errors. Two of them can be in the same sample, and the other one in the same sample of the other channel.

Since the C2 reporting of some drives can be unreliable, the only way to know is to find an isolated "minimal set" of C2 errors (for example a group of three) that was not reported by the drive (case false), or to show that on a drive with a C2 accuracy of N %, there are less than N unreported isolated C2 errors among 100 isolated C2 errors (case true).

EDIT : in short since we don't know why drives don't always report all wrong data, we can't assume that isolated C2 errors are always reported. For example if the chipsets are buggy, the bug can occur on any C2 error.

Yeah, there's no "flush cache" command for CD-ROMs. But Mandrake 9.2 ATE my LG CDROM drive just to discover that fact!!

http://www.mandrakelinux.com/en/lgerrata.php3

I know, I know, it's a bad joke. I just couldn't resist it....

Ciao.

> well, I've always disabled that option with the Ultraplex40x because it doesn't
> cache audio data and it's faster. what do you mean by erratic behaviour?

For instance with my Plex2410A and EAC0.95pb3 the detected best read method is D8.
When I disable 'Drive caches audio data' and rip a track in secure mode, I see that
EAC actually uses READ CD method and reads each sector only once, which is not what
I would have expected.

> BTW, am I right to think that a unique C2 error produced when reading will
> be always reported?

Yes and actually all correct implementations of CIRC are able to detect up to 4
errors in a single C2 frames with 100% accuracy. But then from theory to practice...

i use to test with DAEquality.


My Plextor 241040A is somewhat bad, though i've used it a lot up to now (but my Pioneer Slot In is used a lot too and brings better jitter) ...so i dont know


C2 Accuracy is 73%
After Testing 5 CD & DVD-Rom's it got the baddest overall score with 44 / 100

The Best came from Samsung 204B 57,3 points without C2 .... 60 points with it..BUT
i cannot give you the accuracy as the Analyse.exe with option extracts the name of the drive... actually the Samsung has a SLASH -> / in its name and so no filename can be created with it... i used a secure rip with C2 on.

i still need more Drives to test the accuracy ...my Plextor is too bad (however)
the other drives had no C2


ah and ... dont try to ...there are no 204B to buy anymore (as if it is made to rip it has no buffering of audio data and it is somewhat fast ...in secure mode 10X overall included the encoding process to GT3b1! )


still theres a need to discuss about different things within EAC
(did you know you can drag and drop 44,1 khz files to EAC get it to encode it to your compression format)

In this thread ( http://www.hydrogenaudio.org/forums/index....howtopic=15083& ) we concluded that the C2 results of DAEquality were only right if the qulity log shows zero skips.