Thread: Reproducing CRC's

Does anybody know how to reproduce the CRC values that EAC reports? Sometimes I have to re-rip a track, and usually I only keep the last ripped WAV file. However, with WAVs filling up my HDD so quickly I sometimes lose track of what I did! It would be nice if I could check the WAV's CRC against the CRC values (Test & Copy) in the EAC log file to be sure I'm dealing with the correct WAV. Windows Commander can create CRC checksums but these do not match those of EAC. Also, I noticed that the CRC's that AccurateRIp calculates differ from those calculated by EAC. I thought CRCs were a "unique" fingerprint, but this does not seem to be true.

maybe you have enabled the "null sample CRC calculation" or you haven't set the offset correction.

I have set the offset correction for my drive (Lite-On LTR 48246S) to +6 samples. I would expect the null samples to affect the last track only since the drive can't read into the lead-out.

Hello Zennon. The effect of the option "No use of null samples for crc calculation" Does not only reply to the last track. If you have that option enabled, then the silence before and after a track isn´t calculated into the crc value. So the crc values you get, is only reffering to the actual music, and therefore are not totally precise. That is why your crc values differ from the ones of AccurateRip.

Martin, thanks for the explanation - I wasn't aware of that. However, "no use of null samples for CRC calculations" is not ticked in my EAC options screen. What other reasons could there be for the difference in CRC values (EAC, AccurateRip, WinCMD)?

Hello Zennon. With your drive offset, then If your drive cannot overread into the lead-out, or if it can, but you haven´t enabled that option, then the last track of your cd will be missing some samples, and therefore have an incorrect crc value. But if you have set the offset correction value correct, then all other track´s should be perfect.(Including the last track, if you can overread into the lead-out)

Martin, I'm pretty sure all settings are correct. I use AccurateRip, which on many discs (thanks to the database update) reports "All Tracks Accurately Ripped.". So I really don't know why the EAC and AccurateRip CRC's differ. Perhaps Andre can shed some light on this issue?

In my last post i have given some false information, that i will just clear op, so that other reader´s won´t be misguided...-Even if your drive can overread into the lead-in or lead-out, and you use offset correction, then your EAC crc values vill differ from AccurateRip´s crc values on the first and last track. That is because that when AccurateRip calculates crc values, then it will cut 4 sector´s from the beginning of the first track, and also 4 sectors from the end of the last track which will not be included in the calculated crc value.(About 10000 samples.) In this way user´s with or without overreading capabilities will still have the same crc values for the first and last track´s anyway.(If ripped propperly offcourse..) So the first and last track´s crc values of AccurateRip, will always differ from EAC´s crc values for those track´s. But if you haven´t enabled the option "No use of null samples for crc calculation" then i would think that all track´s crc values except the first and last would be the same for both EAC and AccurateRip, because i would imagine that they use the same standard crc32 algorythme, but i have just checked my self, and nonne of them match ? -Why it is, i have absolutely no clue...(AccurateRip said all tracks where accurate..)

Hi Matin, I still can't figure out why the EAC and AccurateRip CRC's differ. I'm pretty sure my EAC settings (offset correction, no use of null samples, etc) are correct. Here's an example of a recently ripped CD:

== 1. EAC LOG ==
Used drive : LITE-ON LTR-48246S Adapter: 2 ID: 1
Read mode : Burst
Read offset correction : 6
Overread into Lead-In and Lead-Out : No

Other options :
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks : No
Installed external ASPI interface

Track 1 Test CRC EA83D781 Copy CRC EA83D781 Copy OK
Track 2 Test CRC D6417148 Copy CRC D6417148 Copy OK
Track 3 Test CRC 82C17CF7 Copy CRC 82C17CF7 Copy OK
Track 4 Test CRC 9C7C8ECF Copy CRC 9C7C8ECF Copy OK
Track 5 Test CRC D338209C Copy CRC D338209C Copy OK
Track 6 Test CRC 95856B64 Copy CRC 95856B64 Copy OK
Track 7 Test CRC 63D5A553 Copy CRC 63D5A553 Copy OK
Track 8 Test CRC 303017C9 Copy CRC 303017C9 Copy OK
Track 9 Test CRC 50B8F28A Copy CRC 50B8F28A Copy OK
Track 10 Test CRC 0185395D Copy CRC 0185395D Copy OK
Track 11 Test CRC AFCD58A0 Copy CRC AFCD58A0 Copy OK
==

== 2. ACCURATE RIP RESULTS ==
Track Ripping Status [Disc ID: 0012909a-890a730b]

1 Accurately Ripped (confidence 1) [796773ff]
2 Accurately Ripped (confidence 1) [c1346591]
3 Accurately Ripped (confidence 1) [571b0ca8]
4 Accurately Ripped (confidence 1) [d97d00cc]
5 Accurately Ripped (confidence 1) [0b7d2948]
6 Accurately Ripped (confidence 1) [040f339d]
7 Accurately Ripped (confidence 1) [4dee24c8]
8 Accurately Ripped (confidence 1) [269b0cb1]
9 Accurately Ripped (confidence 1) [56733e07]
10 Accurately Ripped (confidence 1) [14dcd6fc]
11 Accurately Ripped (confidence 1) [67899766]

_______________________

All Tracks Accurately Ripped.
==

== 3. WINDOWS COMMANDER CRC'S ==
; Generated by WIN-SFV32 v1.0
; (Compatible: Windows Commander 5.0)
01 A41DA01D
02 A864FCA8
03 A8164A59
04 648D58A3
05 C336C5AA
06 8156BD39
07 54970F2B
08 344B879D
09 511672EF
10 9376F434
11 57732D05
==

Hello Zennon. Over at the AccurateRip forum, there was someone who asked the same thing, and someone answered that the crc values from EAC have absolutely nothing to do with AccurateRip´s values...Howcome, i dont know, and he didn´t explain anything further...

Well, I'm confused because I thought a CRC checksum is a fingerprint, i.e., unique to a file. Perhaps Andre can add a feature to the next EAC version that allows CRC calculations for previously ripped WAVs?

EAC calculates the CRC values for each track that you rip. You are saving these CRC calculations with the wav files on your hard disc, and you want to check them every so often to make sure the wav files are still exactly the same as when you copied them?
I had this problem too. The solution is:
1. Rip your tracks with EAC, save the log of the CRC values.
2. A month later, start EAC, Tools>Process wav.

This will analyse your wav and include the CRC value that you are after. You MUST have the same settings in EAC when processing a wav to when you ripped it - e.g. no use of null samples on or off etc.

I'm not sure what EAC takes into account for the CRC. It is certainly different to any third party crc calculation. I rip the wavs, create an md5 checksum for each wav, process each wav against the original CD, and then store them. The md5 is a faster way for me to check if any have become corrupted, and if I'm feeling neurotic, I can still check the individual wavs slowly with EACs wav processor.

I have been reading up a little bit about CRC calculation and i have found out that even though that a CRC32 value is an exact fingerprint of a file then there is different ways to calculate the CRCs(i dont mean null samples or not). So i guess that we dont need to worry about different programs having different CRC values for the same files since the individual program just uses its own implemantation of the CRC algorythme...-Martin.

Skyjon, thanks for the tip - I overlooked the "Process WAVs" feature in EAC. My current protocol is to rip a disc in TCB mode, check CRC's (re-rip disc in TCS mode if CRC's don't match), create a md5 checksum file for all WAVs, encode to FLAC, and store the results on my external HDD. This seems similar to your ripping sequence. What exactly do you mean by "process each wav against the original CD"?