The ONLY way to be guaranteed correct ripping?
Reply #50 – 2003-06-06 13:56:25
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...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..." 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.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).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.Pooh-poo on your comments. No comment.