Hydrogenaudio Forums > EAC, AccurateRip and CRCs

Hydrogenaudio Forums > CD-R and Audio Hardware > CD Hardware/Software

Never_Again

Jun 7 2006, 14:07

I suppose it is possible in certain cases for EAC's CRCs match erroneously, while AccurateRip flags an error. But I have run twice into the opposite scenario: EAC's CRCs don't match, yet AccurateRip says accurately ripped. The first time I saw it, it somehow didn't strike me as important. Yesterday it happened again, with a different CD; and this time my curiosity was piqued.

I saved both the EAC and the AccurateRip logs this time, and attach the relevant portions thereof below . This was with EAC v0.95 beta 3 on a CD I submitted a few months ago, having ripped it with a Plextor Premium. Check out track 2.

CODE

Used drive  : _NEC    DVD_RW ND-3520A   Adapter: 0  ID: 0
Read mode   : Burst
Read offset correction : 48
Overread into Lead-In and Lead-Out : No

Used output format : flac.exe   (User Defined Encoder)

Other options      :
    Fill up missing offset samples with silence : Yes
    Delete leading and trailing silent blocks : No
    No use of null samples for CRC calculations: No
    Native Win32 interface for Win NT & 2000

Track  1
     Filename 01_Boonoonoonoos.wav

     Pre-gap length  0:00:02.00

     Peak level 99.0 %
     Test CRC 750A0618
     Copy CRC 750A0618
     Copy OK

Track  2
     Filename 02_That's Boonoonoonoos+Train To Skaville+I Shall Sing.wav

     Peak level 99.0 %
     Test CRC 0B43FAE7
     Copy CRC 679A9633
     Copy OK

Track  3
     Filename 03_Silly Confusion.wav

     Peak level 99.0 %
     Test CRC E4A7D711
     Copy CRC E4A7D711
     Copy OK

<snip>

No errors occured

End of status report

Track    Ripping Status        [Disc ID: 003364de-f512b011]

1    Accurately Ripped    (confidence 1)     [935cb787]
2    Accurately Ripped    (confidence 1)     [5c273318]
3    Accurately Ripped    (confidence 1)     [c2547282]
<snip>
_______________________

All Tracks Accurately Ripped.

I haven't been able to reproduce it.
<edit: font size (where is the Codebox tag?>)

greynol

Jun 7 2006, 14:27

It seems you should take your own advice and ignore the logs and go with the AccurateRip results.

"I guess this paints the ND-3520A in a rather unfavorable light, doesn't it?"

Thanks for the good belly-laugh. This was priceless!

Duble0Syx

Jun 7 2006, 14:31

QUOTE(greynol @ Jun 7 2006, 12:27)

It seems you should take your own advice and ignore the logs and go with the AccurateRip results.

"I guess this paints the ND-3520A in a rather unfavorable light, doesn't it?"

Thanks for the good belly-laugh. This was priceless!

More than likely it could simply be on the Test portion it screwed up, and when it actually copied the audio it got it right. Even so I'm odd enough the CRC's have to match, even if accuraterip says it's good. Especially since I get a lot of rips where it says some tracks were not accurately ripped when the offset is right and has matching CRC's and 100% track quality. So using both can be handy. I'd listen to EAC over accurate rip honestly.

Also, ripping in Burst mode could easily be the cause of mismatching CRC's.

greynol

Jun 7 2006, 14:31

Ok, ok. I'm more composed now.

AccurateRip only checks the C part of T&C, and it appears that the C part of track 2 was done correctly.

spoon

Jun 7 2006, 15:03

In EAC you have 2 rips:

Test CRC 0B43FAE7
Copy CRC 679A9633

One of the rips was wrong as the CRCs are different, yet for AccurateRip I only see 1 log, not 2 logs. Perhaps EAC only uses accuraterip on the copy rip? not test? The 2nd rip could be the one in AccurateRip and by chance it was without error where the first test rip had the error. If 2 rips passed data onto AccurateRip then you would expect to see 2 AccurateRip logs.

greynol

Jun 7 2006, 15:08

QUOTE(Duble0Syx @ Jun 7 2006, 13:31)

Especially since I get a lot of rips where it says some tracks were not accurately ripped when the offset is right and has matching CRC's and 100% track quality.

1. Matching CRCs can still represent a track that was ripped in error
2. Your pressing might not be in the database even if some of the tracks were reported as being ripped accurately.

I've seen both but #2 much more often.

So long as you aren't testing against your own submission, AccurateRip can always be trusted when it says a rip was done accurately (unless it's something you downloaded, since CD-R submissions of pirated copies do occur).

When AccurateRip says a track was ripped in error but EAC clearly had no trouble with it and subsequent tries gave the same result with no trouble, then I'd say the rip was good. This pretty much paraphrases what you already said.

QUOTE(Duble0Syx @ Jun 7 2006, 13:31)

Even so I'm odd enough the CRC's have to match, ...

CRCs don't have to match. This example pretty much proves that.

QUOTE(Duble0Syx @ Jun 7 2006, 13:31)

...Burst mode could easily be the cause of mismatching CRC's

I'm thinking that the cause is "decades-old BS," as Never_Again had once put it.

IOW, the test rip was probably affected by some type of load on his system.

QUOTE(spoon @ Jun 7 2006, 14:03)

Well it sure would be easier if you would use the standard CRC algorithm in your program, dammit.

How do you calculate CRCs anyway?

Never_Again

Jun 7 2006, 15:39

I just had the same occur on yet another disc. Upon closer examination of the CRCs, I can confirm DoubleOSyx's and greynol's idea.

In both cases on the tracks whose T&C CRCs didn't match (but AccurateRip reported accurately ripped) it was the Test CRC that was bad. In the latest case, T&C CRCs mismatched on two tracks, of which the first was flagged as an error by AccurateRip. Now the first track had the correct Test CRC and a bad Copy one. That corroborates the hypothesis that EAC doesn't activate the AccurateRip function for the Test part of Test & Copy.

@greynol: I never said the 3520A was a ripping monster; I just don't want to abuse its neighbor, the PX-712A, overmuch. But I'm glad if I managed to brighten up a gray rainy day for someone. <g>

@DoubleOSyx: no doubt that AC is to be trusted over EAC when AC reports accurately ripped. Other cases may be attributed to different pressings or EAC misconfiguration. Could you paraphrase the "so I'm odd enough the CRC's have to match" bit, BTW? It came out garbled.

greynol

Jun 7 2006, 16:13

@Never_Again: I doubt your drive is the problem here, refer to the "decades-old BS" comment. <bg>

Never_Again

Jun 7 2006, 16:54

Well, then why it doesn't affect the PX-712? If the CRCs don't match in Burst mode with the Plex, you can bet your Kook Fcuknut badge <weg> that terminating all other programs will not make them match no matter how many times you re-rip, unless you switch to Secure mode. With the NEC, they just might on the very next try, without changing a thing.

The system/IDE load may be a factor, but not the reason.

greynol

Jun 7 2006, 17:32

What makes you so sure that this can't happen with your PX-712?

I don't know what you're on about this badge thing but by the looks of this thread it appears as though you are projecting.

Never_Again

Jun 7 2006, 18:29

greynol
>What makes you so sure that this can't happen with your PX-712?

I didn't say it cannot, but the theoretical possiblility doesn't worry me.

This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.