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: EAC - not as "safe" as we think? (Read 13351 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

EAC - not as "safe" as we think?

Yesterday I ripped (EAC Secure Mode) and encoded ( aoTUV r1 Q8) a CD (Tool - Lateralus) twice (don't ask me why - it's a long and boring story). Same CD - same equipement - same software - same results? You should think so.

The WAV`s from the two rips look like there are no differences:



So I compared the WAV`s using EAC and learnd that they are not the same:



A look at the encoded vorbis-files shows just how big the difference is:



So the question is: How can EAC, known for "perfect" rips in secure-mode, provide such different results on two rips, claiming at both rips that "no errors accured" (even the track quality was exactly the same on both rips)??

EAC - not as "safe" as we think?

Reply #1
Do you use the accuraterip plug-in in EAC? (www.accuraterip.com)

If not, you shoul install it, and compare your ripping results with those of other users, that's pretty safe (it compares the CRCs of every ripped track with the ones other users had).

But I've no idea why your rips are different, sorry. You don't use C2, do you? Do the rips sound different to you? Maybe wrong read command?

EAC - not as "safe" as we think?

Reply #2
Do you use the accuraterip plug-in in EAC? (www.accuraterip.com)

No I don't, but I'll take a look.


Quote
You don't use C2, do you? Do the rips sound different to you? Maybe wrong read command?

No, I don't use C2, since my drive doesn't support it (and even if it would, I think I wouldn't use it). I haven't compared the sound, but they even look slightly different in the EAC spectral analyzer:




Since I didn't change any settings between the two rips, read command shouldn't be the problem, could it?

EAC - not as "safe" as we think?

Reply #3
Did you push the "Detect read command" button? I don't know if it could make problems, but it was the only thing which could disturb the ripping progress, I think..

EAC - not as "safe" as we think?

Reply #4
So the question is: How can EAC, known for "perfect" rips in secure-mode, provide such different results on two rips, claiming at both rips that "no errors accured" (even the track quality was exactly the same on both rips)??

It's not known for "perfect" rips in secure mode. It doesn't help much if the drive being used for the extraction process is too stupid to read and therefore unable to create a bit-identical copy of the CD audio track. This is commonly caused either by too many intentional errors on the disc, which serve as copy-protection mechanisms, or quality flaws of the reading unit. Secure mode does nothing but reading suspect sectors over and over, until it receives a result which is deemed being ok, based on statistical analyses. Improving the hardware's limitations is beyond its skills.

A good example for a crappy and therefore unusable device is an NEC DVD burner of mine. Before I began using REACT2 in image mode I had utilised regular EAC's track mode in conjunction with AccurateRip for copying my CDs. The NEC burner had often been reported having created inaccurate rips of certain tracks in secure mode, while ripping the same CDs in the Pioneer DVD drive had led to accurate results. Especially interesting 'bout this is the fact that the latter is run in burst mode instead of the secure one, thanks to some annoying bug which causes Windows to run the drive at a maximum speed of 16x, though it's specified for 40x. In secure mode it runs at around 4x, a fact which I don't put up with, hence the burst solution. Too bad that neither Windows updates nor firmware ones have ever resolved this problem, attempting to workaround it with Nero's drive speed application to set a fixed speed doesn't function as well. Quite annoying to be the "proud" owner of two faulty DVD drives - the Pioneer thing is a slow snorer, the NEC one is a half illiterate.

Edit: Typ-O-Mania

EAC - not as "safe" as we think?

Reply #5
Especially interesting 'bout this is the fact that the latter is run in burst mode instead of the secure one, thanks to some annoying bug which causes Windows to run the drive at a maximum speed of 16x, though it's specified for 40x.
DAE* has a different "max rated speed" than data in almost every drive I came across. And it's always slower than data.

Some drives I had:

A Lite-On DVD-ROM: Data at 52x, DAE at 32x
A Sony CD-RW: Data at 48x, DAE at 28x
A NEC DVD-RW: Data 48x, DAE at 32x

*Digital Audio Extraction

EAC - not as "safe" as we think?

Reply #6
DAE* has a different "max rated speed" than data in almost every drive I came across. And it's always slower than data.

The slow speed isn't a problem related to this fact, since this also applies to reading of data. The Pioneer drive's possible maximum speed for reading CDs is reported being 16x by any available software which is able to identify the hardware configuration. For testing purposes I already copied large amounts of files to harddisk using both drives, which clearly revealed that the NEC thing is a lot faster than the other drive. This shouldn't be the case since in CD mode they're both specced to be 40x ones. DVDs are another thing, reading these doesn't cause any noticeable issues concerning the reading speed, hence I'm pretty sure the Pioneer drive is actually suffering from some buggy firmware which causes these serious slowdowns. If the hardware itself was at fault, then reading DVDs should cause troubles as well. And as you already stated yourself, it's very uncommon that it reads data and audio at the same speed.

EAC - not as "safe" as we think?

Reply #7
Now that dBpoweramp's R12 secure ripper is out, I expect people will -- and should -- begin migrating over to it from EAC.

Besides the fact that test results confirm that it's more reliable than EAC, it also has a faster, more user-friendly display of results that makes it much easier to spot suspect tracks and rerip them on another drive to confirm results.

Since the program's release in February, I've ripped about 800 discs. I've had amazing results and highly recommend this program. As somone who loved EAC but never really felt "safe" with it, I can say that dBpoweramp is providing a whole new level of security.

EAC - not as "safe" as we think?

Reply #8
I'm guessing all of you who say dBpowerAMP is much faster than EAC are aren't using EAC in burst mode.  FWIW, all of dBpowerAMP's passes prior to re-reads are done in burst mode.

As for dBpowerAMP's ability to check the first pass with AccurateRip, this can be done using EAC as well.

Test and Copy doesn't have to be done via F6.  You can copy first (F5), check AccurateRip and then test via F8 if it is necessary; and it is safe to do this in burst mode.  Provided AccurateRip says the rips are ok or the checksums match and aside from dBpowerAMP's automation, EAC is not slower than dBpowerAMP.

But I agree, if your drive provides C2 pointers, dBpowerAMP is much more secure than EAC and for drives that cache audio data and don't properly support EAC's -usefua switch, dBpowerAMP will be faster.  It will also be able to rip some tracks accurately that EAC can't.  How many really depends on the condition of your discs and is likely to only be a small percentage.

Regarding the original poster, far too little information has been given to make any sense about exactly what went wrong.  From the spectral graphs, it looks like the channels have been reversed, though spectral graphs aren't intended to be used in this way.  I'd compare them side by side in a wave editor that allows you to zoom in and view multiple tracks at the same time like Audition.  I'd also subtract one track from the other (though I'd swap channels in one of them first) to see how they differ.  You need to synchronize them if there's any offset.  Just guessing at this point, but I wouldn't be surprised if you found a 6-sample offset somewhere between the two files.

EAC - not as "safe" as we think?

Reply #9
Did you push the "Detect read command" button? I don't know if it could make problems, but it was the only thing which could disturb the ripping progress, I think..

No, I didn't push it. Read command is set to "auto detect read command"

It's not known for "perfect" rips in secure mode. It doesn't help much if the drive being used for the extraction process is too stupid to read and therefore unable to create a bit-identical copy of the CD audio track. This is commonly caused either by too many intentional errors on the disc, which serve as copy-protection mechanisms, or quality flaws of the reading unit. Secure mode does nothing but reading suspect sectors over and over, until it receives a result which is deemed being ok, based on statistical analyses. Improving the hardware's limitations is beyond its skills.

A Hardware problem? Maybe. But to be honest, I don't think so. I use a LG GSA-4164B, which is known for good performance, and never had any problems with it, at least not at reading CDs (there was a problem with some DVDs though, but a firmware-upgrade solved this problem).

Regarding the original poster, far too little information has been given to make any sense about exactly what went wrong.

What kind of additional information do you need?

Quote
From the spectral graphs, it looks like the channels have been reversed....

 
How could they? As I said, I didn't change any settings.

Quote
though spectral graphs aren't intended to be used in this way. I'd compare them side by side in a wave editor that allows you to zoom in and view multiple tracks at the same time like Audition. I'd also subtract one track from the other (though I'd swap channels in one of them first) to see how they differ. You need to synchronize them if there's any offset. Just guessing at this point, but I wouldn't be surprised if you found a 6-sample offset somewhere between the two files.

Sorry, I'm no expert in analysing soundfiles and I don`t own a programm like "Audition". Just used the spectral view from EAC to see if there's any visual difference. And about the offset: When I compare the files using the compare-feature from CDex, it really says, that some files (but not all) have an offset. Again: How can that be?

 

EAC - not as "safe" as we think?

Reply #10
OK, now I installed AccurateRip, re-ripped the CD and guess what?:

[a href="http://img402.imageshack.us/my.php?image=artrw6.png" target="_blank"]

EAC - not as "safe" as we think?

Reply #11
You probably have a different pressing than what's in the database.  This is quite common.

Perhaps you should provide some screenshots of EAC's settings, namely the first two tabs of the EAC options and the first three tabs of the Drive options.

EAC - not as "safe" as we think?

Reply #12
Perhaps you should provide some screenshots of EAC's settings, namely the first two tabs of the EAC options and the first three tabs of the Drive options.

No problem:


 

   

EAC - not as "safe" as we think?

Reply #13
Thanks.

I take it you've determined your drive settings based on the "Detect read freatures" routine and that you've performed this a couple of times using a disc that's in excellent condition and then unchecked the C2 setting (edit: in the event that EAC detected your drive provides C2 pointers)?

Are you also performing a test pass when ripping these tracks and checking to make sure the CRCs match?

I recommend that you do the following:
First, uncheck "No use of null samples for CRC calcualtions" and leave it unchecked.
Second, rip the tracks again using F5.
Third, switch to burst mode and test the tracks using F8.

It would be nice to be able to analyze first-hand the rips that do not match which you presented in your initial post, but HA prohibits this regardless of the fact that I already own the album.  I suppose a screenshot of EAC indicating the track times down to the exact frame and lossless samples of the first 30 seconds of each differing version of the same track might be adequate and not violate any rules.

EAC - not as "safe" as we think?

Reply #14
Are you sure your drive doesn't cache?  If it does you should also select the 'drive caches audio data' under the Extraction Method tab of your drive settings.

I also noticed that you haven't selected a drive read command;  Drive settings drive tab.  Just hit the autodetect read command now button and save.
JXL

EAC - not as "safe" as we think?

Reply #15
The OP hasn't told us anything about the disc condition.  Is the disc clean and scratch-free?

EAC - not as "safe" as we think?

Reply #16
Now that dBpoweramp's R12 secure ripper is out, I expect people will -- and should -- begin migrating over to it from EAC.

Besides the fact that test results confirm that it's more reliable than EAC, it also has a faster, more user-friendly display of results that makes it much easier to spot suspect tracks and rerip them on another drive to confirm results.

Since the program's release in February, I've ripped about 800 discs. I've had amazing results and highly recommend this program. As somone who loved EAC but never really felt "safe" with it, I can say that dBpoweramp is providing a whole new level of security.


Is the regular version pretty secure or are you talking about the reference version of dbpoweramp?

EAC - not as "safe" as we think?

Reply #17
The reference version. (It's well worth the money.)