My drive supports C2 error correction and I have been using it always since it gives the fastest rips for me, while still no errors are reported and all track qualities are above 99.5%. Using this option, I get rip speeds of 18x and I was wondering whether C2 error correction is really that reliable? I mean, I never get error messages, the track quality is always reported to be over 99.5% and I cannot hear any audible difference. Is there any incentive NOT to rip at 18x under these conditions?! Btw, my drive is a LiteOn 48x CDRW (I can't remember the model name off the top of my head)

Compare the CRCs of your reads with and without C2. Once in a while there's a mismatch for my Lite-On 48246S which is a very reliable drive itself. That means, your drive makes mistakes even if you can't hear them. The only objective way is to compare the CRCs as to whether it's safe for you to turn on the C2.

This post has been edited by atici: May 29 2003, 23:05

--------------------

The object of mankind lies in its highest individuals.One must have chaos in oneself to be able to give birth to a dancing star.

This CRC method only works for tracks with errors detected, and all corrected, that is very uncommon.

The only way so far to test the C2 accuracy is the DAEquality kit : http://www.exactaudiocopy.de/eac13.htmlYou might first have a look at CDRinfo.com, they might have tested your drive for C2 accuracy already.

EDIT : I'm talking about the CRC method for checking secure mode, not for checking a rip (in the latter case, it nearly always work).

I could not find info on cdrinfo.com but thanks for the link anyway. My drive is the Lite-On 48246S - same as atici's. Are there any C2 error tests for this drive you know of? The DAE testing method looks interesting, but I would prefer it if there was already some info on this drive, after all, it was pretty popular not too long ago.

This is a bit off topic, but how much do you think processor speed affects burn-time? I just read some reviews of the same drive I have and they reported getting burn-times of around 2.5 minutes for a full audio CD (785MB) - I usually get about 3.75 minutes for the same amount of audio data. I have a Pentium III 550MHz. Do you think it is my processor or what?

This CRC method only works for tracks with errors detected, and all corrected, that is very uncommon.(The only way so far to test the C2 accuracy is the DAEquality kit)EDIT : I'm talking about the CRC method for checking secure mode, not for checking a rip (in the latter case, it nearly always works).

Could you explain this a little bit further? (not sure what you mean). I'd expect Atici's method works quite well.

Lite-On LTR-48246S is a very reliable ripper and has superb C2 accuracy. But my experience is that it does mistakes with C2 on, once in a long while. I ripped my CDs twice for archiving and compared the logs and CRCs with a visual diff tool. I used to rely on C2 information before and in my recent rips I did not because it did not give me much of a speed advantage. Anyway there was CRC mismatches once in around 500 tracks when I compared the logs. Then I reripped those tracks a third time to make sure and it always (except for once ) matched with the CRC when C2 was off. I think Test&Copy is unnecessary because "C2 off" is perfect. I essentially did a test and copy manually because I reripped all my archive, and all the CRC mismatches happened with the rips when C2 was on except for once in 400 albums.

My suggestion is try without the C2, the speed I get is around the same. Drive caches audio data must be set, because it does and it needs to be flushed.

This post has been edited by atici: May 30 2003, 18:25

--------------------

The object of mankind lies in its highest individuals.One must have chaos in oneself to be able to give birth to a dancing star.

I meant that if you turn C2 on, then test and copy a CD, and get the same CRC, it doesn't prove anything. It is even likely to happen if your drive have no C2 support at all ! It is common to get a correct extraction with a good CD, thus CRC OK.So you can't say that if you get CRC OK on a C2 rip, your drive have perfect C2 support.

On the other hand, if you manage to get a "copy OK" with a lot of error correction, there will probably be 10,000 C2 detected errors, for example. Then if you get CRC OK, it means that all of the 10,000 errors were detected, thus that your drive have 99.99 % C2 accuracy.

Atici, Tigre's recent tests proves that the no C2 setting doesn't give perfect results either.Of course you get CRC mismatches only when C2 is on, because a "no C2 mode" failure means a consistent error, that is twice the same wrong CRC !thus the CRC method can't be used to test the secure mode accuracy, since CRC comparison is the same as readig twice. Either they both succeed, either they both fail.

Yes, you're right! I knew that. But that's just beyond me. There's no way for me to make sure whether it was a correct rip. I play with the settings of EAC as much as I could to guarantee the best rip. And Test&Copy would be meaningless if the drive would actually fail twice.

Now what do you suggest I do, set the C2 or not, if the drive is known to be almost 100% accurate reporting C2 errors (I read it somewhere that this drive is)?

--------------------

The object of mankind lies in its highest individuals.One must have chaos in oneself to be able to give birth to a dancing star.

I don't know, I still must verify Tigre's results in order to understand exactly how far they must be trusted. I personally test and copy with C2 on (with a drive not very accurate in C2 detection : 99 %)

But wasn't it you who said when you unset "Drive is capable of retrieving C2", it does not mean EAC is disregarding C2 error reports drive produces. It just does not rely on the C2 error reports blindly. When a C2 error happens even if "Drive is capable of retrieving C2 info" is unset, I'd assume EAC takes this into consideration and does multiple reads to ensure. So that would mean C2 unset is always more reliable.

--------------------

The object of mankind lies in its highest individuals.One must have chaos in oneself to be able to give birth to a dancing star.

When C2 is unset, the drive doesn't take C2 into account at all. It just rereads everything.

The only clue about the reliability of this method was BobHere's statistics : two, then three pairs of CRC OK different from rip to rip, among about 1000 CD. This was considered as the frequency of repeatable errors in CDs.On the other hand we had numerous reports of CRC mistmatches with C2 on.

So we concluded that reading twice was more reliable than C2.

However, as Andre Wiethoff said from the beginning that an error never occurs twice the same way, we didn't pay much attention to an obvious flaw in this method : an byte permanently turned into another would be undetectable by CRC nor by reread, and would be an error never showing up in the statistics. It was a common misconception that any defect on the CD (especially scratches) would affect the optical tracking, and that the recovery would generate random data, never the same.

Now we can see that the probability for a byte to be permanently turned into another is the same order of magnitude as the probability for it to be wrong and not detected by the C2 stage.

I meant that if you turn C2 on, then test and copy a CD, and get the same CRC, it doesn't prove anything. It is even likely to happen if your drive have no C2 support at all ! It is common to get a correct extraction with a good CD, thus CRC OK.So you can't say that if you get CRC OK on a C2 rip, your drive have perfect C2 support.

Thank you for the explanation. I didn't know how to interpret that post...

Next:

QUOTE

Of course you get CRC mismatches only when C2 is on, because a "no C2 mode" failure means a consistent error, that is twice the same wrong CRC !thus the CRC method can't be used to test the secure mode accuracy, since CRC comparison is the same as readig twice. Either they both succeed, either they both fail.

Note that Atici compared CRCs of "C2 on" versus "C2 off". This is something different and does certainly make sense. And therefore I am a bit surprised to see Atici give in so quickly However I am not able to estimate the accuracy of this way of testing, compared to Andre Wiethoff's way (the one you linked to).

@liekloo : I think you're too much of a stickler for * ripping guide Sometimes you sound like that guide could not include some information that is not completely valid. However, I think those rules should be reviewed in the light of reasoning. Sorry, maybe I interpreted incorrectly. But the kind of approach I see too often these days, i.e. regarding * guide as some kind of bible and any other rips other than * ones as inferior, is pissing me off. Maybe I started to project that to everyone whose signature involves *

@Pio2001 : Thanks. That was one of the most fruitful EAC discussions I had.

I trust "No C2" because (implicitly assuming "an error, in most of the cases, do not occur the same way, and is random by nature") my CRCs are reproducable. Wheras on the tracks I have a mismatch with the CRC of "C2 on" and "C2 off", the "C2 on" could not produce the same CRC repeatedly. And considering in 99.9% of the tracks the CRCs of "C2 on" and "C2 off" coincide and "C2 on" mode produced the same CRC with "C2 off" in the problematic tracks in some of the rips makes me think that the most accurate rip is attained with "No C2". However, it might have been the case that "a byte altered state permanently" which leaves me no option but to read that byte in the altered state.

However I wonder what kind of errors C2 report. Or what exactly C2 system is. How does a drive realize it made a mistake if there's no error detection mechanism in audio CDs? I think in the mass production phase some CDs are produced with flaws. I have a couple of them: very rarely used, no scratches but I get many C2 errors (no copy protection). In the same manner I'm sure there're other errors in some of my CDs, which C2 system could not realize because there's no indication that the byte has a flaw and the byte in question returns the same value consistently (but possibly with a glitch in the waveform). For those, I have no option but to have an inaccurate rip.

But if there were a real time deglitch system built in EAC, maybe we could correct those errors. Was the experimental switch related to "C2 error correction" that is removed from newest prebetas coded for that purpose?

MOD:* No links to or names of ripping groups please.

This post has been edited by Jan S.: Apr 18 2004, 15:22

--------------------

The object of mankind lies in its highest individuals.One must have chaos in oneself to be able to give birth to a dancing star.

I trust "No C2" because (implicitly assuming "an error, in most of the cases, do not occur the same way, and is random by nature") my CRCs are reproducable. Wheras on the tracks I have a mismatch with the CRC of "C2 on" and "C2 off", the "C2 on" could not produce the same CRC repeatedly.

Wow, this is getting complicated...

You are right, getting different CRC with C2 and same without C2 means that no C2 detects, and corrects errors that C2 doesn't. On the other hand, I just realized that permanent errors, that can only be detected by C2, can never be corrected anyway, because EAC corrects by rereading. It will even not report any of them at the end.

Say that we've got 1000 light errors on a CD.

a) 990 not consistent and detected by C2. B) 5 consistent and detected by C2, c) 5 not consistent and not detected by C2.

Reading with C2 : the 990 a) errors are detected and correctedThe 5 B) errors are detected, but not corrected, though EAC believes they areThe 5 c) errors are not detected.Result : 10 errors, zero reported.Reading again, same thing, but different CRC because of the 5 c) errors.

Now reading without C2, we get the 990 a) errors detected and correctedThe 5 B) errors are not detected at all.The 5 c) errors are detected and corrected.Result : 5 errors, zero reportedReading again, same thing, same CRC, because the 5 errors are consistent.

But in fact, the extra errors detected with C2 might or might not be corrected (they can repeat twice by chance).In conclusion, it is very probable if we consider that the C2 undetection is not related to the repeataibility of the error, that the extra errors detected without C2 will be corrected, if we assume that we are ripping a CD with correctable errors, while this is not sure at all for extra errors detected with C2, since they repeat themselves to begin with.

QUOTE (atici @ Jun 1 2003 - 01:03 AM)

How does a drive realize it made a mistake if there's no error detection mechanism in audio CDs?

In the same manner I'm sure there're other errors in some of my CDs, which C2 system could not realize because there's no indication that the byte has a flaw

This goes back to the question : are errors undetected because of CIRC or because of buggy drives ? (question originally debated here : http://www.digital-inn.de/showthread.php?t...?threadid=15921 )The most recent opinion I made about it is that I think that relaxing the C2 accuracy allows to correct much more errors than enforcing an exhaustive detection. Explanation on a CD Freaks thread (sorry but CD Freaks is offline for the time being).

QUOTE (atici @ Jun 1 2003 - 01:03 AM)

But if there were a real time deglitch system built in EAC, maybe we could correct those errors. Was the experimental switch related to "C2 error correction" that is removed from newest prebetas coded for that purpose?

Yes it was. It turned out not very efficient, and completely unuseful since most drives do deglitch errors themselves (interpolating C2 detected errors).

a) 990 not repeatable and detected by C2. b ) 5 repeatable and detected by C2, c) 5 not repeatable and not detected by C2.

I think terminologywise "consistent" is a better term here than "repeatable". There're also "D) consistent (repeating) errors that C2 could not detect" that I was referring to. I think they've just become a part of the CD.

QUOTE

The 5 b ) errors are detected, but not corrected, though EAC believes they are

I don't understand this. If EAC gets constant C2 errors no matter how many times it reads, wouldn't it go on indefinitely? Or does it just give up even though C2 tells something is wrong after sufficiently many multiple reads?

With your logic applied to all sorts of errors, we come to the conclusion that "C2 off" should give a better, though sometimes inaccurate result. Because C2 does not help when it comes to errors of type B in which "C2 off" is totally blind but "C2 off" helps errors of type C. But wait isn't C2 also an error correction mechanism? Is there some B type errors that could be corrected with the help of C2 information?

QUOTE

There is an error detection, and correction, mechanism in audio CDs

Hmm, I've naively believed so far that as opposed to Data CDs, Audio CDs have no error detection/correction mechanism. That's why we had accurate rip problems. So what's the difference then? Is there more redundancy for error correction purposes in a Data CD (because it's always secure unless there're major errors)? I'll read the thread you gave, it seems very infomative but rather long

--------------------

The object of mankind lies in its highest individuals.One must have chaos in oneself to be able to give birth to a dancing star.

If someone was to test the C2 info of their CD-ROM drive with a tool like DAE Quality, had positive results & still the * people said "no C2 allowed" I think that would prove they don't think for themselves & really don't do any scientific testing in regards to DAE just rely on what they may read on a forum like HA or a guide like *.

Something like: "no C2 unless tested".

& really because the * standard uses T&C as a must, when using C2 on an inefficient drive CRC mismatches would be high enough so it would be clear if the drive supports C2 accurately or not.

the kind of approach I see too often these days, i.e. regarding * guide as some kind of bible and any other rips other than * ones as inferior, is pissing me off. Maybe I started to project that to everyone whose signature involves *

This is completely out of context.

The thread is about estimating C2 error correction secureness, which has nothing to do with any ripping guides. Although no 'new' conclusions have been made in this thread so far, it doesn't harm to put things in the light of reasoning, as you call it

I agree with you that people generally think too much in rules, dogmas, (e.g. I remember someone stating that MP3 aps is equal quality to MPC quality x...)

but associating me with similar acting goes a bit far.

If I happen to say on this forum 'this or that is better' as advice, then it means that my statement is considered to be the truth by most people on the scene. And that is the reason why a complete argumenation can be left out in these cases.

There're also "D) consistent (repeating) errors that C2 could not detect" that I was referring to.

I included them at the beginning, then I thought that if errors are randomly distributed among the 1000 ones. If we choose 5 of them not to be C2 detected, and 5 other to be consistent, we'll likely get none at the same place, thus statistically 0 consistent and not C2 detected

QUOTE (atici @ Jun 1 2003 - 08:22 AM)

I don't understand this. If EAC gets constant C2 errors no matter how many times it reads, wouldn't it go on indefinitely?Or does it just give up even though C2 tells something is wrong after sufficiently many multiple reads?

Only Plextools acts like this. EAC uses C2 for detection only, then gives it up and starts it's classic set of 16 rereadings : you can see the red lines flashing.

QUOTE (atici @ Jun 1 2003 - 08:22 AM)

isn't C2 also an error correction mechanism? Is there some B type errors that could be corrected with the help of C2 information?

As I explained I don't remember where (maybe the "secure mode FAQ" thread, anyway I'm abstracting here), the data starts from the CD's surface. In the chips of the drive, errors get detected and if possible corrected at the C1 stage, then the errors left are detected (or flagged) and if possible corrected at the C2 stage. Then the errors left are interpolated (glitch removal), and a C2 flag is returned with them. Then the corrected and deglitched audio data, as well as the C2 flags, get out of the drive.Thus B errors are not correctable by C2, by definition. Otherwise, then would not be part of the 1000 errors of the CD. They would be just valid data.

CD ROMs are like audio CD with error recovery files included. An audio CDR has a capacity of 740, or 800 MB. A CD ROM records 650 or 700 MB of data and 90 or 100 MB of error recovery data. In order to benefit from them in audio, just burn wav files on data CDs.

Spath doesn't give very detailed answers, though he's got a deep knowledge about the matter, because he's not got the time to write long explanations, and maybe because, working as a engineer in CD drives, there are things about the drive conception that he must not tell outside of his job.

CD ROMs are designed so as to get a bit perfect reading, while audio CDs have the interpolation mechanism kicking in in case of problems. Thus the bit exact reading have not been enforced as strictly as for data CDs.

If i rip with c2, i rip the data twice, and compare the crc's, because i think, if there were unhandled errors, and the poor c2 implementation "masked" them, the probability of reproducing the same data for the damaged sectors twice is very low. (it is almost impossible that the drive reads the disk so precisely, that it "guesses" the same bitstream e.g. on the edges of a massive scratch)

However, if i use no c2, i think it is unnecessary to make a crc test, because if there are poorly defined blocks (e.g. caused by the disk's dirty surface), EAC reports "suspicious position at XX:XX.XX" and i know that the rip won't be proper.

1) It is not almost impossible to get the same error twice. There are plenty of examples of this happening posted to this forum. For this to happen and coincide with a C2 information that causes EAC to skip the error does lower the chances, however.

2) Without C2 pointers, a CRC test can demonstrate an error without there also being a suspicious position and the chances of this happening may increase when the number of allowed sets of re-reads (the Error recovery quality setting) is increased. Examples of CRCs that don't match when ripping without C2 pointers and no errors reported are also available on the forum.

This post has been edited by greynol: Feb 6 2008, 22:14

--------------------

Breath is found in waveform and spectral plots;DR figures too, of course.

Hello! "CD ROMs are like audio CD with error recovery files included. An audio CDR has a capacity of 740, or 800 MB. A CD ROM records 650 or 700 MB of data and 90 or 100 MB of error recovery data. In order to benefit from them in audio, just burn wav files on data CDs"

Hello! "CD ROMs are like audio CD with error recovery files included. An audio CDR has a capacity of 740, or 800 MB. A CD ROM records 650 or 700 MB of data and 90 or 100 MB of error recovery data. In order to benefit from them in audio, just burn wav files on data CDs"

How can i do this correctly? I mean burning wav files?

What is your objective here? Is it to archive your music, or do you want to be able to play the CDs that you create?

If you want to archive your music then you should use lossless encoding. This makes the files smaller and provides much more useful tagging.

If you want to be able to play the CDs then the only thing that can play wav files on a CD is a computer, and again you should use lossless compression.

OTOH there are many devices that can play lossy files on a CD, and some can also play lossless files.

Did you really want to resurrect a 3 year old resurrection of a 4.5 year old thread?

The first revival of the thread was on topic and more or less justified. There's no excuse for Shamray's revival of the thread to ask general questions about ripping; it's a TOS#5 violation. Any chance these recent posts can be moved to another thread by an admin?