Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: The ONLY way to be guaranteed correct ripping? (Read 19894 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

The ONLY way to be guaranteed correct ripping?

Reply #50 –
DrDoogie,

First of all, I apologize for the tone of my previous post. Basically, I was put off by the attitude you displayed on your last couple of posts. Nevertheless, that doesn't justify some of my comments.

Now that we - hopefully - got that out of the way, let's look into the subject again...

Quote
I must enable disabling of the audio cache.
I'm sure you will agree, having thought about it a bit.

If that's what you meant, then I of course agree. As others in this thread already mentioned, it wasn't 100% clear from your previous posts.  Maybe if you wrote "enable caching in EAC to disable caching of drive..." 

Quote
If there is an unrecoverable, uncorrectable error(C2), the drive does two things, as I understand it (corrections to this understanding are welcome).
1. It reports the error.
2. It hiddes the error by pretending to perform a valid correction (muting, extrapolation etc.)

Not all drives report all errors, especially at high speeds and lots of errors (in my impression), which means that EAC can only (in my guess) compare results by reading several times, and assume that the result that rears its ugly head most often is most likely correct.
But there is, I believe the very real chance that the result will be "bogus-corrected" the same way lotsa times.
More to the point, when you have a C2 error you no longer have any way of finding out whether your result is correct or not ('cept by comparing with a known good rip, which I did for some CD's [and found that EAC can't do nuthin' 'bout the fact that there are errors encountered when reading: This is a claim which I will not bother documenting. I have experienced it, good enough for me.])

Hmmm... I would guess EAC should do something sensible with this. Basically, EAC has two checkboxes concerning C2: a first one to indicate that the drive reports C2 errors, and a second one to disable the use of C2 information. By checking the first box and unchecking the second, I assume you are saying to EAC "look, you will get C2 info from this drive, but don't trust it". If your statement that EAC will subsequently read "bogus-corrected" info multiple times is true (which it very well may be, I don't know enough about the subject to confirm or deny it), then you are correct in saying that this will decrease the reliability. But maybe EAC has some nifty "trick" built-in specifically to deal with this (as long as the source code or algorithms are not available, we can never be sure). Also, if this auto-correction by the drive is really happening, I'd like to hear from somebody "in the know" how good or how bad this really is.

Quote
I have no interest in dissing EAC, as such. Please excuse me if my frustration got vented a bit too much. On the other hand, please don't post out of a fanboy-ish attitude.

Sorry if I came across as an EAC fanboy. I'm not. If you can point me to another ripper that rips - at least - as reliable as EAC and has most of the features of EAC (especially creating non-compliant CUE sheets), I'd be happy to give it a try. The cdparanoia engine is probably pretty good as well, but several people have posted on this board that it is not reliable with drives that cache audio (although it was never confirmed nor denied by a cdparanoia developer).

Quote
I do not believe I was quite that general... but to answer so that you can understand, bad RAM does not just affect ripping. Furthermore, EAC uses some 4MB when running, which according to the other programs you run, can be physically located anywhere on the ram-stick. Having ripped 100 (well, 250) cd's almost twice, I do not think that... oh, toss it.

Yes, you were that general. 

Isn't this what happened ? Tigre wrote "maybe you have bad RAM that causes the data corruption", and you replied ""Bad RAM that causes data corruption". That's a good one. ". So basically, you laughed at him like he's some clueless newbie that wrote something very stupid. This line was the direct cause of the angry tone of my reply. If you just replied "I don't think I have any memory issues, I thoroughly tested my memory before" or maybe even "this particular problem is not caused by bad RAM because ...", I would have said nothing about it.

You sounded as if you were convinced that faulty memory can never cause data corruption, which is pretty general.

Quote
Pooh-poo on your comments.

No comment. 
Over thinking, over analyzing separates the body from the mind.

The ONLY way to be guaranteed correct ripping?

Reply #51 –
@ PoisonDan:

First, to clarify EAC and caching issue: EAC cannot enable caching of the drive, and it cannot disable it. (Only some firmware can do this, AFAIK.) What EAC can do is either ignore it (when checkbox is unchecked) or flush it before re-read (checkbox is checked). The second option - the flushing - does, of course, effectively "disable" the drive cache, although the cache is still in fact active all the time.

Second, it seems you are not quite right about the meaning of EAC C2 checkboxes.
Here it is explained by Pio.

Finally, the DrDoogie's description of C2 stuff looks fairly accurate to me.
However, BobHere at EAC forum reported the "repeatable error patterns", long time ago. So it's nothing new here.
What is rather surprising is the high percentage of non-matching rips that DrDoogie reported.
"30% are in disagreement when using EAC to compare the two rips".
This looks like an unusual, interesting result, and therefore it is worth more thorough testing.


(edit: deleted off-topic remark)

The ONLY way to be guaranteed correct ripping?

Reply #52 –
For the record, when the salesman tested my second defective RAM, he said "As soon as the test began, countless errors were reported".

The ONLY way to be guaranteed correct ripping?

Reply #53 –
Memtest86 for testing RAM.


But IMHO, its highly unlikely that its a problem with defective RAM. My experience with defective RAM was general system instability - sufficient to cause lockups, programs abruptly terminating... Heck, installing Windows would fail sometimes.

Oddly enough, the few rips I carried out while using a system w/ defective RAM were okay, but I guess there were too few samples to make a conclusion.

The ONLY way to be guaranteed correct ripping?

Reply #54 –
Quote
We would also be very grateful, if you could make some tests with EAC but this time not using the C2-report feature, i.e. with the first C2 checkbox unchecked.
Edit: and this is what Tigre suggested you to do nearly a month ago, in the beginning of this thread! But you have chosen to ignore it...


Quote
If you encounter an undetected error (#/CRC mismatch) please try without C2 enabled & report your drive, results. If you rip all your CD's without C2 the same thing may happen possibly on different CD's.


Quote
Um, chosen? No, I've been busy and forgot.
"Never attribute to malice what simple stupidity alone can explain".


Once again I ask you... you why not prove everyone here wrong? I would suggest you rip with T&C, NO C2 until you encounter a CRC mismatch without errors reported, save the log & then try again with C2 on, save that log & if you want you can upload the logs to my crappy little web space.

Here is a report of mine & I have also had my PX24/10/40A to report read errors with with C2 enabled & claim copy O.K without in a couple of cases, the opposite has yet to happened to me.

In real life ripping situations I believe EAC can be (with a decent drive) just as safe as non C2 if not better. When attempting to correct a read error, sync error CD that has already failed maybe a different matter.

Can anyone please link any tests (using decent C2 error reporting drives) that show the contrary to this?

The ONLY way to be guaranteed correct ripping?

Reply #55 –
Quote
]What is rather surprising is the high percentage of non-matching rips that DrDoogie reported.
"30% are in disagreement when using EAC to compare the two rips".
This looks like an unusual, interesting result, and therefore it is worth more thorough testing.


Yes, I struggle to understand this. My understanding of the differences between what plextools and EAC does, in which I assume plextools use more specific hardware calls, does not really help clarify this.

If anyone have any suggestions as to how one might be able to "test" which extraction would be correct and which is not, I'd be more than happy to carry out such "test".
Looking at the wavs in Cool Edit does seem to indicate that the plextools wavs have slightly higher amplitude in parts, and that they are "skewed" compared to the EAC wavs.

Quote
Once again I ask you... you why not prove everyone here wrong?


I don't know who "everyone" is, but if you assume to speak for him, let me summarize a couple of points you might want to tell him:

  • It has been reported that the "Test and Copy" feature of a certain program written by a student in his spare time is not always correct.
    As such, performing testing based on the assumption that this feature is trustworthy is a logical fallacy.

  • Ripping without error reporting, when your drive reports errors with an accuracy of ~100%, is pointless from the perspective of ascertaining the accuracy of the ripping. An error that is not reported may well be "bogus-corrected" the same way each and every time it is encountered.


Quote
Here is a report of mine & I have also had my PX24/10/40A to report read errors with with C2 enabled & claim copy O.K without in a couple of cases, the opposite has yet to happened to me.


Um... what exactly is it you want me to "test"? The accuracy of EAC? I have no interest in that. If you want to investigate how accurate EAC is, go for it. I am interested in testing the accuracy of ripping, not whether you should consider EAC accurate or not. 

Quote
In real life ripping situations I believe EAC can be (with a decent drive) just as safe as non C2 if not better. When attempting to correct a read error, sync error CD that has already failed maybe a different matter.


Mm.
This seems to me to be an excess of faith.

The ONLY way to be guaranteed correct ripping?

Reply #56 –
Quote
Um... what exactly is it you want me to "test"? The accuracy of EAC? I have no interest in that. If you want to investigate how accurate EAC is, go for it. I am interested in testing the accuracy of ripping, not whether you should consider EAC accurate or not.

I don't understand this. To test the accuracy of audio ripping you need to test various ripping programs, settings with various drives. I was asking for you to provide some results for using C2 vs. Non C2 in EAC for your drive, that's all.

The ONLY way to be guaranteed correct ripping?

Reply #57 –
Quote
I would suggest you rip with T&C, NO C2 until you encounter a CRC mismatch without errors reported, save the log & then try again with C2 on, save that log & if you want you can upload the logs to my crappy little web space.

If DrDoogie is right, this test will likely give no results, because whatever the numbers of errors you can get in a file, if EAC wrongly returns "no errors occured", it will likely give two identical wrong CRCs.
Now, if C2 is more accurate, even perfectly accurate, you can still get the same matching wrong CRCs, and the same errors in the resulting file, since C2 is used only to detect errors, not to correct them. In practice you should maybe get less errors, since they are all reread 8 times, vs two times only without C2.

To confirm this, I'm going to ask in EAC forum if the error correction with C2 does use C2 or not when C2 is ON. We must be sure of this.

The ONLY way to be guaranteed correct ripping?

Reply #59 –
Quote
If DrDoogie is right, this test will likely give no results, because whatever the numbers of errors you can get in a file, if EAC wrongly returns "no errors occured", it will likely give two identical wrong CRCs.

Testing with "EAC C2 off" and comparing all rips (both CRC OK and CRC #) could help (maybe) to answer question why DrDoogie got so many mis-matching rips with "EAC C2 on". Too bad he's made it clear he's not interested in EAC accuracy.

And generally, why leave to speculation and theorising something that can be "measured".

Personally I would not trust DrDoogie's results, just yet.
I would stay open-minded and just remember that he's got these results, but it should be verified by someone else. Too great risk something has gone wrong here.

The ONLY way to be guaranteed correct ripping?

Reply #60 –
I don't see any problem with DrDoogie's results, granted his CDs are sometimes in bad state. When I rip a CD with some errors, due to the CD being in bad state, with the Memorex DVDMAxx 1648 (99 % C2 accuracy), I can never get same CRCs, even when no errors occured. Thus any bad CD that I would manage to rip without errors would be in disagreement with Plextools.

The ONLY way to be guaranteed correct ripping?

Reply #61 –
Exactly, that is the whole point.



Rip in secure mode, no c2 (just to play safe), all drive settings either correct or 'safe', and verify that CRCs are matching.

If then there is still a disagreement between Plextools and EAC, then one of them is indeed "BAD", DrDoogie.

Only then



Question to Pio:
In your last post, were you talking about a fast or a secure read mode, Pio?

The ONLY way to be guaranteed correct ripping?

Reply #62 –
I'm talking about bad CDs (evenly scratched, or decaying CD), with a lot of C2 errors, thus a lot of error recovery in EAC, miraculously ripped without any unrecoverable error, in secure mode accurate stream, no cache, C2.

The ONLY way to be guaranteed correct ripping?

Reply #63 –
Quote
I don't see any problem with DrDoogie's results, granted his CDs are sometimes in bad state.

Yes, i agree it is one of the possible reasons.
Who knows...

Quote
...I can never get same CRCs, even when no errors occured. Thus any bad CD that I would manage to rip without errors would be in disagreement with Plextools


Yes, if plextools always rip the same (same CRC), and EAC rips different CRC.
Or perhaps plextools sometimes might rip different as well?

So, the big questions are:
Does plextools always rip the same CRC?
In those cases, does plextools report any C2 errors in the final results?
(I mean does it say that rip is 100% ok - no more C2 errors, or does it say the opposite)

The ONLY way to be guaranteed correct ripping?

Reply #64 –
I don't know, I have no Plextor drive. (But I can send some tricky CDRs to anyone wanting to test).

The ONLY way to be guaranteed correct ripping?

Reply #65 –
Quote
I don't know, I have no Plextor drive. (But I can send some tricky CDRs to anyone wanting to test).

I guess I could gather some results using my PX-W2410A for you pio & you could do a report on the findings. Would be good try a variety of drives though & little point in using older drives as Plextor Europe has already stated their inferior C2 error information give inaccurate results when using plextools.