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 19876 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

The ONLY way to be guaranteed correct ripping?

Reply #25
Quote
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.

The ONLY way to be guaranteed correct ripping?

Reply #26
Quote
* 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.

The ONLY way to be guaranteed correct ripping?

Reply #27
Quote
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...

The ONLY way to be guaranteed correct ripping?

Reply #28
Quote
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 forum.

The ONLY way to be guaranteed correct ripping?

Reply #29
Quote
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.

Quote
* 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.

The ONLY way to be guaranteed correct ripping?

Reply #30
Quote
Quote
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.

The ONLY way to be guaranteed correct ripping?

Reply #31
Quote
Quote
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.

The ONLY way to be guaranteed correct ripping?

Reply #32
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?

The ONLY way to be guaranteed correct ripping?

Reply #33
well, it gives you a crc after the rip is finished already

The ONLY way to be guaranteed correct ripping?

Reply #34
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.

The ONLY way to be guaranteed correct ripping?

Reply #35
Quote
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 

The ONLY way to be guaranteed correct ripping?

Reply #36
Quote
Quote
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. 

 

The ONLY way to be guaranteed correct ripping?

Reply #37
Quote
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.
Code: [Select]
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)

The ONLY way to be guaranteed correct ripping?

Reply #38
Quote
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.
Let's suppose that rain washes out a picnic. Who is feeling negative? The rain? Or YOU? What's causing the negative feeling? The rain or your reaction? - Anthony De Mello

The ONLY way to be guaranteed correct ripping?

Reply #39
Quote
Quote
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.
Code: [Select]
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)

Quote
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.

Quote
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.

Quote
...
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?

Quote
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)

Quote
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).

Quote
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.

Quote
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.

The ONLY way to be guaranteed correct ripping?

Reply #40
@Doogie ...

You are right about RAM ... bad RAM will most likely cause a whole system crash with a nice and blue screen ...
The name was Plex The Ripper, not Jack The Ripper

The ONLY way to be guaranteed correct ripping?

Reply #41
Quote
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, 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.

Quote
"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.
Over thinking, over analyzing separates the body from the mind.

The ONLY way to be guaranteed correct ripping?

Reply #42
Quote
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...

The ONLY way to be guaranteed correct ripping?

Reply #43
Quote
@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).

The ONLY way to be guaranteed correct ripping?

Reply #44
Quote
Quote
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.

The ONLY way to be guaranteed correct ripping?

Reply #45
Quote
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.

Quote
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.])

Quote
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.

Quote
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.

Quote
Don't diss tigre's comments if you don't really know what you're talking about yourself


Pooh-poo on your comments.

The ONLY way to be guaranteed correct ripping?

Reply #46
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...


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.

Quote
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.

The ONLY way to be guaranteed correct ripping?

Reply #47
Quote
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.

Quote
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.

Quote
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, for instnace. Better double-check everything.

The ONLY way to be guaranteed correct ripping?

Reply #48
Quote
"Never attribute to malice what simple stupidity alone can explain".


So true ! I know some people in real life who should think about it 

Quote
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.

The ONLY way to be guaranteed correct ripping?

Reply #49
Quote
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.