I have a problem .
EAC seems to have a problem reading cds with errors on 'em (that is 'errors' as in: "Step right up folks, *tap tap tap* come see the errors, an error for the fine lady Sir? You can never go wrong with an error my good lady, an error for every season and taste, an error a day keeps the sanity away is what I say"..., i.e. generic errors of any kind).
Just. So.
And how, then, can I be certain I've read the CD correctly? Notice the word 'certain', by the way. Sadly, few people seem to grasp the abstract meaning of the word, much the same way that the concepts 'accurate', 'precise', and 'reliable' seem to escape them.
So I throw my meager wits upon the mercy of the minds in this forum, in my pitifull plea for an injection of intelligible truth into my chaotic existence (ok, maybe the 'corny'-factor could be turned down a little, , but my verbosity is great because my plight is in blight. Or something. ).
www.accuraterip.com (http://www.accuraterip.com) providing that two other people have already ripped that CD and had agreement in the results, if your results match those two people, pretty safe to say you ripped it 100% correctly without error. It would be nice to have a combination of this and EAC's routines to make it easier to rip a problem disc, but with a disc that's in decent shape then EAC's method is unnecessary when you can verify your results against others'.
Excellent, could be exactly what I am looking for!
Thanks a bunch!
There is no known way to be sure that you have 100% accurately got the data from the CD correctly, especially if the CD is scratched.
There are several reasons for this and I'm sure Pio2001 will chime in later, but I'll just list some of the most fundamental reasons here:
1) CD Audio Reading is not a 100% repeatable process with identical results from one rip to another
2) If you have scratches that are beyond the error correction mechanism of CD-readers, then you are out of luck
3) Copy protected CDs add another layer of problem: is the original data on the master before the copy protection was applied (which destroyed some original data as it was applied) what you are after? Or is the copy protected, non-original (in terms of the studio master) data with erroneus C2 data, what you are after?
4) AccurateRip can only give you information that another people got the same result. It is statistically a good approach against random errors (such as scratches), but is not perhaps the optimal tool for copy protected discs. Why? Two erroneus rips will be the same if neither of them was able to circumvent the copy protection and there were no scratches. Now, if your rip matches this erroneus rip with AccurateRip, are you happy? Surely not. You got a rip with clicks/pops/mute points on the audio, which is different from the pre-copy protection cd master and different from what a normal hifi rack cd player would output (which would probably use higher order interpolation to fill in the erroneus parts induced by the copy protection).
regards,
Halcyon
I have a problem .
EAC seems to have a problem reading cds with errors on 'em (that is 'errors' as in: ............. )
What exacty do you mean by
"EAC has problems reading CDs with errors". Does it say
"there were errors" after extraction finished?
I assume your answer will be
"yes", since EAC is very accurate at reporting errors, but it often can't actually correct them).
( BTW, If your answer is
No, EAC claims to have a good rip, but I hear pops", then you have probably misconfigured EAC, or using it badly )
Yes? well, there are a few things you can do:
1. throw the CD out of the window
2. clean the CD. If this doesn't help, 'restore' the CD
(brasso/toothpaste/... have a search on the forum, there were some good threads about it). From my own experience I must say restoring can do wonders.
3. forget EAC and 1:1 copies, and use a less secure ripper. Feurio is your best choice (by far...)
(4. if you have a digital soundcard input, and a digital CD player output, you could also use these to get your CD copy...)
There is no known way to be sure that you have 100% accurately got the data from the CD correctly, especially if the CD is scratched.
I've read up on this a bit now, and I disagree with the above claim.
*) If you have a drive that reports C2 errors with a 100% reliability (oh please God, make it exist!)
*) And you get no C2 errors when reading the CD
*) GOTO ::ReadGoodCD
1) CD Audio Reading is not a 100% repeatable process with identical results from one rip to another
Why not, exactly? Is it not digital information?
2) If you have scratches that are beyond the error correction mechanism of CD-readers, then you are out of luck
If you do not have scratches that are beyond Outofluckia, you not bad CD have read can.
3) Copy protected CDs add another layer of problem: is the original data on the master before the copy protection was applied (which destroyed some original data as it was applied) what you are after? Or is the copy protected, non-original (in terms of the studio master) data with erroneus C2 data, what you are after?
Now why would anybody want to rip a copy-protected CD? Isn't there enough music in the world? And why, pray tell, would one want to rip it on a CD-ROM (as opposed to a real good audio cd player with SPDIF)?
4) AccurateRip can only give you information that another people got the same result.
Yes... well, damn the Bell-Curve, I say, damn it!
What exacty do you mean by "EAC has problems reading CDs with errors". Does it say "there were errors" after extraction finished?
No. It happily rips two different copies of the same CD. With a plextor w1210A firmware 1.10 at 14-32x CAV, mind. Haven't tried at 8x CLV yet... but maybe I should.
...since EAC is very accurate at reporting errors, but it often can't actually correct them
Isn't it the DRIVE's responsibility to report C2 errors? Hummmm?
( BTW, If your answer is No, EAC claims to have a good rip, but I hear pops", then you have probably misconfigured EAC, or using it badly )
Methinks not.
... well, there are a few things you can do:
Yes, well I think I'll try 2 and 4... in time.
Thanks!
4) AccurateRip can only give you information that another people got the same result. It is statistically a good approach against random errors (such as scratches), but is not perhaps the optimal tool for copy protected discs. Why? Two erroneus rips will be the same if neither of them was able to circumvent the copy protection and there were no scratches
Is that true?
(I am not so familiar with copy-protections...)
The example you might have in mind, is
(deliberately inserted)clicks/pops in the tracks when read by a CD-ROM drive, right?
Then, @ DrDoogie: it depends on how you define 'guaranteed correct'... 100% sure you'll never be, but yes we can come pretty close
For the rest: This seems to be thestory of the glass of beer.. . Is it half-full, or is it half-empty?
Then, @ DrDoogie: it depends on how you define 'guaranteed correct'... 100% sure you'll never be, but yes we can come pretty close
For the rest: This seems to be thestory of the glass of beer.. . Is it half-full, or is it half-empty?
I define "guaranteed correct" as in: 100% sure.
Whether one can be 100% sure or not may well be a philosophical question, but if there are no errors it is a
reasonable assumption that one has read correctly,
provided that one can be certain any possible errors would have been detected.
Hence the C2-error reporting has to be correct, or one might as well use SPDIF (digital audio out).
The glass of beer is an analog example though.
No. It happily rips two different copies of the same CD. With a plextor w1210A firmware 1.10 at 14-32x CAV, mind. Haven't tried at 8x CLV yet... but maybe I should.
Ripping in Test&Copy mode and getting a CRC mismatch, or WAV compare, are good (secure) ways to be sure of that. Assuming you have done something similar, my guess is the EAC drive options are not correctly set. This can be easily verified: Go to: EAC > Drive Options and set your drive's settings 'safe', i.e.:
* Accurate stream: No
* Caching: Yes
* C2: No
Now rip again & see if you get 2 identical rips...
...since EAC is very accurate at reporting errors, but it often can't actually correct them
Isn't it the DRIVE's responsibility to report C2 errors? Hummmm?
Yep, but we don't have to bother about that. More relevant is when the drive can't correct an error, and it reports so to EAC. If EAC can't solve things, it will warn you:
"there were errors"! Moreover, the drive sometimes overlooks errors, which EAC will pick up most of the time. If the drive reported all errors, we'd be using Audiograbber instead of EAC
DrDoogie,
Your flag says you are based in Iraq, and ripping a perfect CD is your biggest problem?
DUCK! For God's sake, DUCK!
*ROFL*
The other day on this forum, I came across another so-called "Iraqi" who spoke better english than any native Englishman/American - so to speak
And it wasn't just plain English, it was juicy British English!
Ripping in Test&Copy mode and getting a CRC mismatch, or WAV compare, are good (secure) ways to be sure of that. Assuming you have done something similar, my guess is the EAC drive options are not correctly set. This can be easily verified: Go to: EAC > Drive Options and set your drive's settings 'safe', i.e.:
* Accurate stream: No
* Caching: Yes
* C2: No
Now rip again & see if you get 2 identical rips...
Okay, maybe I am using the wrong settings after all... but why are they wrong (accurate stream, C2)?
Aren't you, with these settings,
DISABLING ALL (C2) ERROR CHECKS?
That would... reduce the question of accuracy to a
statistical chance that the drive returned a different audio stream (
with error hiding in it), each time, would it not? Which is less probable the worse the error hiding is, right?
My original question was not whether my CD-ROM drive knew best how to mess up the sound, oh no, it was:
"How do I make sure that the sound is correct?"I daresay it is you who are using the wrong settings, my good man...
DrDoogie,
Your flag says you are based in Iraq, and ripping a perfect CD is your biggest problem?
DUCK! For God's sake, DUCK!
Well, I have to use all the US grants for something, and there's a limit to how many chemical weapons they are willing to sell me, after all.
[span style='font-size:8pt;line-height:100%']Edit : fixing quotes[/span]
I daresay it is you who are using the wrong settings, my good man...
hehe
I am not claiming your settings are wrong... Wether they are wrong is something we need to find out. And if you use my advice, you'll know soon. Actually, you'd better
hope they are wrong, cuz then your problem is solved.
(@everyone:Don't panic if you are using different settings!). The settings I posted are the safest ones: they are 100% secure, but extraction will be very slow.
Depending on the drive type, you can change some of these settings, which will result in a higher extraction speed, while the rip will still be perfect. The configuration wizard usually tells correctly which settings can be 'adapted' safely. If you change settings that shouldn't be changed, you'll get bad rips)Aren't you, with these settings, DISABLING ALL (C2) ERROR CHECKS?
No, EAC is software, not firmware. It can't change your drive's working at all. Disabling C2 means: EAC will always read twice, even if your drive says it is not needed (C2 info says 'data ok')
note: i have to go now. i'll track the thread
[span style='font-size:8pt;line-height:100%']Edit : fixing quotes[/span]
Forgive my slowness, but...
Aren't you, with these settings, DISABLING ALL (C2) ERROR CHECKS?
No, EAC is software, not firmware. It can't change your drive's working at all. Disabling C2 means: EAC will always read twice, even if your drive says it is not needed (C2 info says 'data ok')
So it reads twice. Allrigh-tee-then.
And reading an audio stream twice... does
what exactly?
Does it guarantee you an error free rip? I cannot see that it does, given that there is the chance that the stream will be "wrong" both times.
Does it increase the probability that you have read the stream correctly? I don't see that it does, given that if there is an unrecoverable (C2) error, for all I know the drive may well choose to hide that error in an identical way each time it is encountered.
But perhaps I need to be brought to justice.
[span style='font-size:8pt;line-height:100%']Edit : fixing quotes[/span]
After reading twice
1. Drive report a C1 error n any of the reads - see 3.
2. The copies will match - proceed further
3. The copies don't match - try rereading until 8 identical results
(with High error correction quality)
There is no known way to be sure that you have 100% accurately got the data from the CD correctly, especially if the CD is scratched.
I've read up on this a bit now, and I disagree with the above claim.
*) If you have a drive that reports C2 errors with a 100% reliability (oh please God, make it exist!)
*) And you get no C2 errors when reading the CD
*) GOTO ::ReadGoodCD
...
[nitpicking mode]
I disagree with the above claim.
If you find errors in the following estimation feel free to correct meFor each chunk of audio data containing 24 bytes there's 4 bytes of C1 and 4 bytes of C2.
IIRC C1 as well as C2 information is capable of locating+correcting 1 error (not only of detecting if the chunk is unchanged or not), so there's redundancy in C1/C2 of at least 50% (maybe I'm wrong with this as I'm not very familiar with the mathematics of error detection/correction algorithms).
So there are (at most)
2^(2*4*8*50%) = 2^32 possible C1/C2 combinations that have to cover
2^(24*8)=2^192 possible data chunks.
So each C1/C2 combination gives correct checking results for 2^(192-32)=2^160 data chunks.
If you change a 24 byte chunk randomly, the probability to get correct C1/C2 checking results is ~1/1^32
Not taking into account all the mistakes made so far, to get a probability of 0.5 = 50% of getting an undetectable C1/C2 error you need on average N randomly changed 24 byte data chunks with (1-1/2^32)^N=0.5, so N=2977044471 which is 112.5 hours of audio if
every 24 byte chunk is randomly changed.
This is not 100% security, even with a drive that reports all detectable C2 errors (and corrects all correctable C1 errors)!!! But it's enough security for me to be satisfied with this faulty calculation. For you maybe ripping two copies of the same CD and comparing the results might give enough security.
[/nitpicking mode]
About the reading twice vs. use C2 information issue:
Usually, if an error that the drive can't correct using C1 info occurs there'll be
- maaaany more errors nearby and
- a random behaviour in extraction results of those errors.
So in 99.9xxx % of dirty/scratched/... CDs erroreous positions will be noticed by reading twice and comparing the results. This has been tested and is result of the experience of many EAC users.
If you believe testing yourself is better than trusting you can do it like this: Take a brand-new CD with perfect surface and ripp it - C2 on test & copy or use whatever method you trust most ATM (or a CD that you have burned yourself - make sure that you have the original .wav files stored at a safe place), Than scratch it, paint some lines on it with a thin marker, eat a hot dog and wipe your fingers on the data side afterwards, ... whatever you want. Then rip with EAC secure mode
A. C2 enabled, Test & Copy
B. C2 disabled, "Drive caches ..." checked, Test & Copy,
check if T & C CRCs match and compare the results to the original with some sound editor's wave substraction or EAC's wave compare.
If the result for a track is "no errors occured" and CRCs match there should be no differences compared to the original. If there are differences and/or CRCs don't match you know that you can't trust the settings you tested.
So it reads twice. Allrigh-tee-then.
And reading an audio stream twice... does what exactly?
Does it guarantee you an error free rip? I cannot see that it does, given that there is the chance that the stream will be "wrong" both times. Does it increase the probability that you have read the stream correctly? I don't see that it does, given that if there is an unrecoverable (C2) error
Reading twice is exactly the thing that makes EAC so good!
If there is an uncorrectable error, one of the following situations will occur :
1. the drive reports the uncorrected error, and EAC tries to correct (by rereading untill it gets 8/16 identical results etc...)
2. the drive 'hides' the error (as you call it), anyhow, let's say EAC doesn't know there the data is wrong. Well, actually errors 'always' (99.99...%) return different data for every new read. This is what is so typical for an error (this has to do with cicumventing the CD's correction codes), and EAC takes advantage from it: By reading every sector twice, EAC is 'sure' that the rip is a 1:1 copy.
And this is the point where we meet the 'danger' of C2:
C2 is used anyhow in your drive, but you can ADDITIONALLY set EAC to read only once (instead of twice) if C2 says the data is 'ok'. So what you do is telling to EAC:
'close your eyes & trust on C2'[/b]. This will of course increase speed, but can decrease quality (because C2 is bad for many drives, and if C2 skips an error, EAC will not notice).
ADDON (to be complete): This notorious C2 has an advantage though: In theory C2 can spot errors in the very rare case where EAC would fail (but I haven't heard of a single example so far. But in Plextools it works more accurately)
Hope you find this info useful, DroDoogie
More important: does EAC work perfectly now, do you get matching copies? Is your problem solved?
Well, actually errors 'always' (99.99...%) return different data for every new read.
How do you know that? it might be 60%, or 10%, because it cannot detect when the data is the same you cannot put a % on it. When AccurateRip makes its way onto EAC then you could put a percentage on it.
EAC presents such a number: (number of frames / number of wrong frames) * 100%
EDIT: and additionally decreases 0,01% for each reread.
It won't give 100% if there was even a single reread.
Well, actually errors 'always' (99.99...%) return different data for every new read.
How do you know that? it might be 60%, or 10%, because it cannot detect when the data is the same you cannot put a % on it. When AccurateRip makes its way onto EAC then you could put a percentage on it.
In theory you are right (cuz there is no reference), but in practise.... we can tell a lot. Quite a lot is known about EAC meanwhile ! If you say '10' or '60%', do you realize what that would mean? It would mean EAC gives very bad results anytime (CDs contain a huge lot of errors). Well that conclusion is not conform our findings: We just
know that EAC is a secure ripper. If I would say 'EAC sucks', everyone would just laugh at me
You are right that it is impossible to determine an exact %, or to know for SURE a rip is a perfect copy. But an en eductated guess can already be pretty accurate/credible : e.g. if I rip 10 CDs with different drives and perform a WAV compare afterwards, I am pretty confident the WAVs will be identical
(on condition EAC is used as well as it gets). Using a different good ripper (e.g. Plextools) will generally not result in deviant rips either. In times of doubt a WAV editor can also give an indication, to see if the extracted WAV is 'credible' to be a 1:1 copy. These are serious indications that EAC is secure. Are we 100% sure? No.
Finally, AccurateRip can increase the secureness of your %, but doesn't change anything
fundamentally to this (same method: comparing WAVs from different drives!).
Testing procedure by Tigre and further discussion split here : http://www.hydrogenaudio.org/forums/index....ST&f=20&t=9049& (http://www.hydrogenaudio.org/forums/index.php?act=ST&f=20&t=9049&)
In order to draw attention on the real topic of the discussion.
Well... no more news from Dr.Doogie?
Well... no more news from Dr.Doogie?
Duh... about what?
Currently I've been busy ripping all my CD's, with the following procedure:
* Read with EAC (Accurate stream, Caching [disabled], reports C2, adjust drive speed) at speed 8CLV.
* If an error lights up, put that CD away and look at it later.
I decided to do 8CLV since my drive (plextor 1210A) had a "perfect" error reporting at this speed (compared with other speeds as set by plextools).
I can post the graphs illustrating this (by DAEQuality's c2extract+analyse) sometime soon by flogging up a pitiful webpage somewhere, or
is there some central repository where we can post such data?
To summarize, I do not trust EAC's error <insert despising sneer here>"correction" facilities one bit, jolt, or - or - or something vastly smaller than some other really small thing.
I've seen - and can repeat, methinks - results where two identical CD's are being read, one CD having errors and the other not, and EAC fails to give an Exact result.
"Exact Audio Copy" my #!*.
But perhaps it's just my grapes. Would be good if Andre decided either to open source it or put in some effort into it.
* Read with EAC (Accurate stream, Caching [disabled], reports C2, adjust drive speed) at speed 8CLV.
Just to be sure: What do you mean with "Caching [disabled]".
Is the option checked or not?
If you don't check that option, that means that EAC will asume that your drive is not caching, and this may lead to that errors are being missed if your drive do cache.
The safe way is to check that option. The only negative thing with that is that the ripping speed may be lower.
I've seen - and can repeat, methinks - results where two identical CD's are being read, one CD having errors and the other not, and EAC fails to give an Exact result.
"Exact Audio Copy" my #!*.
But perhaps it's just my grapes. Would be good if Andre decided either to open source it or put in some effort into it.
WTF... I am speechless...
I can post the graphs illustrating this (by DAEQuality's c2extract+analyse) sometime soon by flogging up a pitiful webpage somewhere, or is there some central repository where we can post such data?
You can start a thread here, or in the EAC (http://www.digital-inn.de/forumdisplay.php?forumid=14) forum.
Would be good if Andre decided either to open source it or put in some effort into it.
I think he means lately & I agree.
* Read with EAC (Accurate stream, Caching [disabled], reports C2, adjust drive speed) at speed 8CLV.
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.
I've seen - and can repeat, methinks - results where two identical CD's are being read, one CD having errors and the other not, and EAC fails to give an Exact result.
"Exact Audio Copy" my #!*.
But perhaps it's just my grapes. Would be good if Andre decided either to open source it or put in some effort into it.
WTF... I am speechless...
By my arrogance or by my claim that the first letter in EAC is misleading?
The first I am reluctant to do anything about in this situation ("...y'all need a li'l con-tro-ver-sy...", etc.), the other I will post on later.
Would be good if Andre decided either to open source it or put in some effort into it.
I think he means lately & I agree.
Yes, *snigger*, exactly.
Sorry for mnot making that clear. My position is that you can't both spank your little ego by keeping your intellectual property
underdeveloped 'cause you want to reap all the praise for it yourself,
and at the same time claim that you want to code a good product for the community.
Don' get me wrong tho', ain't nuthin' wrong with a little ego-spanking, but let's all recognise what motivates people. Altruism ain't it.
Anyway, to return to the original topic, how do you ensure you're getting an exact rip if you're using the Copy Image & Create CUE Sheet option?
Since there isn't really a Test & Copy sort of thing ( which is largely what I've been using till recently ), do we have to do the comparision manually? Have EAC rip twice ( manually ) and then md5sum of diff the two resultant waves for differences before compressing?
Or is there any other better automated method?
well, it gives you a crc after the rip is finished already
One can conclude that CD's were not meant for accurate data transport. They were meant for end user playback. If you take two different drives, both rips will be different as far as CRC goes , even with offset correction. However I've found that the actual sound is 99.9% the same on a non scratched CD. With a brand new CD, I actually just use fast or burst mode. I get the same results as with secure mode. I only use secure mode with my older CD's that might have scratches. I don't own any copy protected CD's, so I don't know about them. If I have a CD that's more than lightly scratched, and I have been ripping for 12 hours and it's only into the 2nd minute on track 1, I'll try to use fast mode and if I notice a bunch of clicks, i'll just mark the folder as errored and get a new CD sometime in the future. Either that or I'll attempt to use scratch removal then do another secure rip. If it's still taking 120 hours and it's a CD that will be expensive to replace, and won't even play back on a regular CD player, I'll take more extreme measures, i.e. very high grit (1500-2500+) emery cloth. Luckily haven't had to use this method yet.
Anyway, to return to the original topic, how do you ensure you're getting an exact rip if you're using the Copy Image & Create CUE Sheet option?
Since there isn't really a Test & Copy sort of thing ( which is largely what I've been using till recently ), do we have to do the comparision manually? Have EAC rip twice ( manually ) and then md5sum of diff the two resultant waves for differences before compressing?
Or is there any other better automated method?
No, there isn't.
The reason is quite simple: EAC should (in theory) give a perfect rip in mere 'copy' mode (no test & copy needed).
Those who use Test & Copy (for separate tracks) will know that every now and then, the rip is not always perfect (sometimes CRC mismatch...).
But that's it. I think (or better: we know) EAC is very good, even without Test & copy.
The claims made in this thread (also the post preceeding this one) are mere claims, without decent argumentation or testing
Anyway, to return to the original topic, how do you ensure you're getting an exact rip if you're using the Copy Image & Create CUE Sheet option? ...
Or is there any other better automated method?
No, there isn't.
...
The claims made in this thread (also the post preceeding this one) are mere claims, without decent argumentation or testing
Um, was that aimed for me?
If so, yes I haven't bothered putting up my results anywhere... would you like me to mail them to you?
Anyway, my claims are:
1. My drive, a plextor1210 with firmware 1.10, detects errors most accurately when reading at a speed setting of 8CLV.
I can document this if desired, bu sending the *.bmp (well, gif'ed) and *c2.dat (zip'ed) files to whom may be interested.
2. Having ripped some 100 cd's in various states of deterioration with both EAC and plextools, I currently have the (approximate) results of:
20% have detectable errors
30% are in disagreement when using EAC to compare the two rips
50% (duh!) are in full agreement between EAC and plextools.
I have a hard time seeing how the 50% can possibly be wrong, so I will be sharing those.
The 20% I will not bother ripping, and the 30% I will
not share even though I cannot hear anything wrong with them.
This way I believe I am doing my part for the great and just cause of accurate ripping and reaming the music companies. If you pardon my american.
Um, was that aimed for me?
Zack not to forget
A lot of people work hard to test EAC thoroughly, that's why people with a different opinion could do a little more than just boasting with controversal claims (or rather: fragments of claims) without argumentation or even complete background.
It seems I'll have to take my words back though, since you (DrDoogie) started to be more concrete.
Actually, it does hardly matter who will turn out to be right about EAC, and who will be wrong... We'll try to get to a 'consensus' and hopefully this will be interesting for a lot of ppl.
If so, yes I haven't bothered putting up my results anywhere... would you like me to mail them to you?
Feel free to post them here
EDIT: we can add images (a link to them) to posts etc...
EDIT: Although this is getting more & more interesting, I'll be a bit 'slow' to follow the discussions on the forum - sorry in advance (lack of time, exams)
2. Having ripped some 100 cd's in various states of deterioration with both EAC and plextools, I currently have the (approximate) results of:
20% have detectable errors
30% are in disagreement when using EAC to compare the two rips
50% (duh!) are in full agreement between EAC and plextools.
Interesting. What (secure mode) settings have you used when getting these results? (C2, Caching)
What's the condition of your CDs?
I haven't tested with 100 cds (rather ~10 - the scratchiest I had) but I get > 90% (I can't tell exactly but I'd say >99%) full agreement between EAC and plextools - AND between plextor 121032A and lg DRD8120B.
Do you check "disagreemen when using EAC to compare the two rips" comparing CRCs or using compare WAVs?
Your numbers sound to me like your drive has ripped some CDs too much, your settings are not optimal (Drive caches audio data
unchecked) or there's a hardware problem like bad RAM that causes data corruption.
Um, was that aimed for me?
Zack not to forget
A lot of people work hard to test EAC thoroughly, that's why people with a different opinion could do a little more than just boasting with controversal claims (or rather: fragments of claims) without argumentation or even complete background.
It seems I'll have to take my words back though, since you (DrDoogie) started to be more concrete.
Actually, it does hardly matter who will turn out to be right about EAC, and who will be wrong... We'll try to get to a 'consensus' and hopefully this will be interesting for a lot of ppl.
If so, yes I haven't bothered putting up my results anywhere... would you like me to mail them to you?
Feel free to post them here
EDIT: we can add images (a link to them) to posts etc...
EDIT: Although this is getting more & more interesting, I'll be a bit 'slow' to follow the discussions on the forum - sorry in advance (lack of time, exams)
A lot of people work hard to test EAC thoroughly, that's why people with a different opinion could do a little more than just boasting with controversal claims (or rather: fragments of claims) without argumentation or even complete background.
True.
Actually, it does hardly matter who will turn out to be right about EAC, and who will be wrong... We'll try to get to a 'consensus' and hopefully this will be interesting for a lot of ppl.
Word.
...
Feel free to post them here
EDIT: we can add images (a link to them) to posts etc...
Eh. Link to images I haven't bothered putting up anywhere?
Interesting. What (secure mode) settings have you used when getting these results? (C2, Caching)
EAC: constant speed of 8, disable audio caching, use accurate stream feature and C2 error reporting feature, abort on read/sync errors
plextools: constant speed of 8C[doh!]LV, report errors only, abort on lowest number of errors (some 100+ I think)
What's the condition of your CDs?
From extremely poor (10 years old, played 100's of times and mishandled) to very good (less than a year old, hardly been handled, can shave yourself in 'em).
Do you check "disagreemen when using EAC to compare the two rips" comparing CRCs or using compare WAVs?
I don't trust EAC's CRC handling. So I compare the wavs.
Your numbers sound to me like your drive has ripped some CDs too much, your settings are not optimal (Drive caches audio data unchecked) or there's a hardware problem like bad RAM that causes data corruption.
"Bad RAM that causes data corruption". That's a good one.
You realize that there's CRC in RAM as well, of course?
But no, the drive is fine - or at least so I think, based on testing with daequality twice at a speed of 8 and getting 99.9% and 100.0% accurate error reporting. I jot the 0.01% down to sync / too high burst error count introduced to one of the test cd's during scratching.
The CD's are to blame, methinks. We're talking scratch'o'rama here.
@Doogie ...
You are right about RAM ... bad RAM will most likely cause a whole system crash with a nice and blue screen ...
EAC: constant speed of 8, disable audio caching, use accurate stream feature and C2 error reporting feature, abort on read/sync errors.
DrDoogie, according to this table (http://www.ping.be/satcp/eacoffsets01.htm#-), your drive (with your reported firmware version) caches audio. Therefor, you
MUST enable caching in EAC, otherwise you will get unreliable results.
Also, as westgroveg mentioned before, to be safe you should also disable C2 reporting.
Please don't diss EAC like that when you haven't even configured EAC properly in the first place.
"Bad RAM that causes data corruption". That's a good one.
You realize that there's CRC in RAM as well, of course?
So according to you the CRC in RAM is the "magical" solution to all RAM problems. If only that were true... (there wouldn't be any bad RAM anymore, would there ?)
Believe me, bad RAM
CAN cause data corruption (if the RAM is bad, how do you know the CRC calculation is correct ?).
Don't diss tigre's comments if you don't really know what you're talking about yourself.
DrDoogie, according to this table, your drive (with your reported firmware version) caches audio. Therefor, you MUST enable caching in EAC, otherwise you will get unreliable results.
Although I can barely understand what exaclty are the DrDoogie's claims in this thread, I think I can understand that his "caching" setting is ok.
(Of course, one can in fact neither disable nor enable drive cache.) So I understand his words "disable audio caching" as that he has the option "Drive caches audio data" checked, which is the correct setting for his drive.
@DrDoogie:
please let us know if that is indeed what you mean!
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...
@Doogie ...
You are right about RAM ... bad RAM will most likely cause a whole system crash with a nice and blue screen ...
'Bout RAM
Nope,
Defective RAM can very well introduce errors in wav files. The size of a wav file from a CD being 100 to 10,000 times bigger than an exe, it can introduce errors into any CD you rip without affecting much the system stability.
It occured to me twice already. The first time, it took me two monthes to realize that the RAM was responsible for corrupted VOB files ripped from DVD (I checked everything else, posted the problem to doom9.net forum without sucess...). The second time, I got a wav file that was read differently in SoundForge and in Samplitude. It was a CD image. There was only one different sample in the whole wav, always the same, and the values returned by Samplitude and SoundForge were both consistent. I suspected the RAM, and let things rest for a while (the computer running well), until I wanted in upgrade to Windows XP, which turned out impossible (errors, data corruption, process aborted etc), until I had the RAM changed.
However, if the CDs are scratched, and if you get a full error recovery in EAC (with the red lights never reaching the end), getting different wavs with no error occured is common (it's the fact itself of getting a whole wav with constant error correction and no error occured, that is very rare).
Anyway, to return to the original topic, how do you ensure you're getting an exact rip if you're using the Copy Image & Create CUE Sheet option?
Since there isn't really a Test & Copy sort of thing ( which is largely what I've been using till recently ), do we have to do the comparision manually? Have EAC rip twice ( manually ) and then md5sum of diff the two resultant waves for differences before compressing?
Or is there any other better automated method?
No, there isn't.
The reason is quite simple: EAC should (in theory) give a perfect rip in mere 'copy' mode (no test & copy needed).
Those who use Test & Copy (for separate tracks) will know that every now and then, the rip is not always perfect (sometimes CRC mismatch...).
But that's it. I think (or better: we know) EAC is very good, even without Test & copy.
The claims made in this thread (also the post preceeding this one) are mere claims, without decent argumentation or testing
Well.. for one, the CD I was ripping was a copy-protected CD. Despite having only given it a spin in my iRiver once, and being absolutely scratch-free, EAC reported a quality of ~ 97% ( can't remember the figure off the top of my head ) after taking like 3 hours to do the rip.
What would you do in such a case?
Naturally, I get concerned and wonder whether any errors were introduced during the ripping. So far, listening through, I didn't detect any, but I'm using a below-average soundcard ( SBLive ) and a crappy pair of headphones ( Philips SBC HP840. Anyone heard of this model before? ). Hence the question about whether a Test&Copy exists for image rips.
A suggestion/question though. There should be some of option in EAC that dumps a DETAILED logfile. By detailed, that means the approximate time/duration at which a read error occurred and re-reads were necessary. That would allow the user to quickly zoom in on trouble spots to listen for flaws.
DrDoogie, according to this table, your drive (with your reported firmware version) caches audio. Therefor, you MUST enable caching in EAC, otherwise you will get unreliable results.
No.
I must enable
disabling of the audio cache.
I'm sure you will agree, having thought about it a bit.
Also, as westgroveg mentioned before, to be safe you should also disable C2 reporting.
I don't really think so.
Please bear with me as I try to explain why.
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.])
Please don't diss EAC like that when you haven't even configured EAC properly in the first place.
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.
So according to you the CRC in RAM is the "magical" solution to all RAM problems. If only that were true... (there wouldn't be any bad RAM anymore, would there ?)
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.
Don't diss tigre's comments if you don't really know what you're talking about yourself
Pooh-poo on your comments.
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...
Um, chosen? No, I've been busy and forgot.
"Never attribute to malice what simple stupidity alone can explain".
But YOU want ME to "test" something for you, on the grounds of, as you say, "I do not think I understand...".
How 'bout YOU test what you want to test instead. It's YOUR hardware you're going to be using, after all, and you shouldn't trust anything I say just because I seem to have convinced myself of the validity of my views.
Defective RAM can very well introduce errors in wav files.
Yes, well, I could always test my ram
again, seeing as that 30% of my rips are in disagreement between EAC and PlexTools. If I find any errors, I'll amend that to this post.
Um, chosen? No, I've been busy and forgot.
I am very glad it is just a misunderstanding.
I have to say it did indeed look a bit strange to me that you were intensively testing EAC/C2 etc, but not even once tested it with the different C2 option. That would be the first thing I would do even if I didn't suspected anything wrong with that option. Just for the sake of it.
Hence, a bit exclamatory tone of that comment - Sorry about that.
How 'bout YOU test what you want to test instead. It's YOUR hardware you're going to be using
Yet again, this would be the first thing I would do - if I had a drive that reports C2.
By the way, I did make some (humble) testing with my drive, but the results were in accord with what was commonly known.
But YOU want ME to "test" something for you, on the grounds of, as you say, "I do not think I understand...".
Heh... Someone here had a signature "everything you say will be mis-quoted and used against you".
ahh, it's just hopeless...
P.S.
Indeed, sometimes people are having very peculiar problems with hardware, like this one (http://www.digital-inn.de/showthread.php?s=&threadid=17437), for instnace. Better double-check everything.
"Never attribute to malice what simple stupidity alone can explain".
So true ! I know some people in real life who should think about it
Yes, well, I could always test my ram again, seeing as that 30% of my rips are in disagreement between EAC and PlexTools. If I find any errors, I'll amend that to this post.
Personally, I never said that your results came from a defective RAM, I just said that errors in CD ripping is often the only visible manifestation of a defective RAM, the BSOD being mistaken for Microsoft Windows ones.
Anyway, this is easy to check. Target one wav file, about 100 to 200 MB, in the explorer. Make a copy of it (drag+drop+ctrl, or ctrl-C+ctrl-V, or what you want). Erase the copy, and copy again, repeat two or three times, until the copying is very fast (file cached in the RAM).
Then compare the two files. With a defective RAM, you'll get differences for sure.
Personally, I never said that your results came from a defective RAM, I just said that errors in CD ripping is often the only visible manifestation of a defective RAM...
Mm.
I think we will have to agree to disagree on that one.
Having used memcheck 3.0 with all the simple tests (1.5 hours) last night, I am firm in my belief that discrepancies between extractions wit plextools and EAC cannot be blamed on any "boogy-men" in the ram.
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.
@ 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 (http://www.digital-inn.de/showthread.php?threadid=15572).
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)
For the record, when the salesman tested my second defective RAM, he said "As soon as the test began, countless errors were reported".
Memtest86 (http://www.memtest86.com/) 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.
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...
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.
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 (http://www.hydrogenaudio.org/forums/index.php?act=ST&f=20&t=7278&hl=eac+findings) 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?
]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.
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.
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.
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.
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.
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.
I've posted the queston in EAC's forum and suggested that rereading should be done until no C2 occurs : http://www.digital-inn.de/showthread.php?postid=68078 (http://www.digital-inn.de/showthread.php?postid=68078)
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.
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.
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?
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.
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...
...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)
I don't know, I have no Plextor drive. (But I can send some tricky CDRs to anyone wanting to test).
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.
I forgot the somewhat long speculation I had written back home, so let me be brief:
I am splitting the discussion of differences between EAC- and plextool-rips to:
Speculation regarding between rips with EAC and Plextools (http://www.hydrogenaudio.org/forums/index.php?act=ST&f=20&t=10256)