IPB

Welcome Guest ( Log In | Register )

 
Reply to this topicStart new topic
EAC - not as "safe" as we think?, different results on multiple rips
Frankie
post Apr 12 2007, 20:59
Post #1





Group: Members
Posts: 69
Joined: 14-June 03
Member No.: 7175



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)??
Go to the top of the page
+Quote Post
Be Positive
post Apr 12 2007, 21:13
Post #2





Group: Members
Posts: 41
Joined: 9-October 06
Member No.: 36148



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?

This post has been edited by Be Positive: Apr 12 2007, 21:14
Go to the top of the page
+Quote Post
Frankie
post Apr 12 2007, 21:28
Post #3





Group: Members
Posts: 69
Joined: 14-June 03
Member No.: 7175



QUOTE (Be Positive @ Apr 12 2007, 12:13) *
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?
Go to the top of the page
+Quote Post
Be Positive
post Apr 12 2007, 21:49
Post #4





Group: Members
Posts: 41
Joined: 9-October 06
Member No.: 36148



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..
Go to the top of the page
+Quote Post
Junon
post Apr 12 2007, 22:03
Post #5





Group: Members
Posts: 520
Joined: 27-August 06
From: Germany
Member No.: 34518



QUOTE (Frankie @ Apr 12 2007, 21:59) *
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

This post has been edited by Junon: Apr 12 2007, 22:11
Go to the top of the page
+Quote Post
Nikaki
post Apr 13 2007, 10:44
Post #6





Group: Members
Posts: 100
Joined: 6-March 07
Member No.: 41226



QUOTE (Junon @ Apr 13 2007, 00:03) *
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
Go to the top of the page
+Quote Post
Junon
post Apr 13 2007, 15:51
Post #7





Group: Members
Posts: 520
Joined: 27-August 06
From: Germany
Member No.: 34518



QUOTE (Nikaki @ Apr 13 2007, 11:44) *
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.
Go to the top of the page
+Quote Post
csiron
post Apr 13 2007, 17:42
Post #8





Group: Members
Posts: 8
Joined: 19-February 07
Member No.: 40749



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.
Go to the top of the page
+Quote Post
greynol
post Apr 13 2007, 18:18
Post #9





Group: Super Moderator
Posts: 10000
Joined: 1-April 04
From: San Francisco
Member No.: 13167



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.

This post has been edited by greynol: Apr 13 2007, 19:29


--------------------
YOUR EYES CANNOT HEAR!!!!!!!!!!!
Go to the top of the page
+Quote Post
Frankie
post Apr 13 2007, 20:27
Post #10





Group: Members
Posts: 69
Joined: 14-June 03
Member No.: 7175



QUOTE (Be Positive @ Apr 12 2007, 12:49) *
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"

QUOTE (Junon @ Apr 12 2007, 13:03) *
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).

QUOTE (greynol @ Apr 13 2007, 09:18) *
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....

shock1.gif
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?
Go to the top of the page
+Quote Post
Frankie
post Apr 16 2007, 18:22
Post #11





Group: Members
Posts: 69
Joined: 14-June 03
Member No.: 7175



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



sad.gif
Go to the top of the page
+Quote Post
greynol
post Apr 16 2007, 18:44
Post #12





Group: Super Moderator
Posts: 10000
Joined: 1-April 04
From: San Francisco
Member No.: 13167



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.

This post has been edited by greynol: Apr 16 2007, 18:44


--------------------
YOUR EYES CANNOT HEAR!!!!!!!!!!!
Go to the top of the page
+Quote Post
Frankie
post Apr 16 2007, 20:20
Post #13





Group: Members
Posts: 69
Joined: 14-June 03
Member No.: 7175



QUOTE (greynol @ Apr 16 2007, 09:44) *
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:




Go to the top of the page
+Quote Post
greynol
post Apr 16 2007, 21:10
Post #14





Group: Super Moderator
Posts: 10000
Joined: 1-April 04
From: San Francisco
Member No.: 13167



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.

This post has been edited by greynol: Apr 16 2007, 21:50


--------------------
YOUR EYES CANNOT HEAR!!!!!!!!!!!
Go to the top of the page
+Quote Post
JunkieXL
post Apr 16 2007, 21:13
Post #15





Group: Members
Posts: 359
Joined: 3-April 05
Member No.: 21165



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
Go to the top of the page
+Quote Post
krabapple
post Apr 16 2007, 21:23
Post #16





Group: Members
Posts: 2181
Joined: 18-December 03
Member No.: 10538



The OP hasn't told us anything about the disc condition. Is the disc clean and scratch-free?
Go to the top of the page
+Quote Post
Donunus
post Apr 17 2007, 00:34
Post #17





Group: Members
Posts: 226
Joined: 8-July 05
Member No.: 23210



QUOTE (csiron @ Apr 14 2007, 00:42) *
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?
Go to the top of the page
+Quote Post
csiron
post Apr 17 2007, 08:04
Post #18





Group: Members
Posts: 8
Joined: 19-February 07
Member No.: 40749



The reference version. (It's well worth the money.)
Go to the top of the page
+Quote Post

Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 23rd July 2014 - 02:05