Ripping Issues - Music CRC + Actual Music CRC Different Options

[ellisdee]

Hey all

I've been ripping a bunch of my cds so that I can listen to them on my computer, and have been noticing something odd. I am using the latest stable version of EAC (not sure the version # off the top of my head, not on this computer) and LAME v3.98.4. My settings to rip V0 mp3s in LAME are as follows:

-V 0 --vbr-new --add-id3v2 --ignore-tag-errors --ta "%a" --tt "%t" --tg "%m" --tl "%g" --ty "%y" --tn "%n" %s %d

My issue is this: when cds rip fine, and are reported to be accurate rips, I check them using Audio Identifier 0.7 beta 3, and find that the music CRC and actual music CRC values are different!

An example is this - Music CRC: CD96, Actual Music CRC: 8F31

These cds sound fine on the computer, their average bitrates are where they should be, and file sizes seem proper. I've read that this difference in CRC values has something to do with tagging or changes in gain, or SOMETHING, but I do not know if this is a serious issue.

Any thoughts? I've included the full LAME Tag as shown by AI 0.7 for the CRC example given above, if it helps.

Thanks!
-EllisDee

Tag revision: 0
Version string: 3.98r
Quality: 100 (V0 and q0)
Encoding method: vbr new / vbr mtrh
Lowpass: 19,500Hz
RG track peak: <not stored>
RG track gain: -10.2dB (determined automatically)
RG album gain: <not stored>
nspsytune: yes
nssafejoint: yes
nogap continued: no
nogap continuation: no
ATH type: 4
Bitrate: minimal (-b) bitrate 32
Encoder delay: 576 samples
Padded at end: 1,212 samples
Noise shaping: 1
Stereo mode: joint
Unwise settings: no
Source sample freq: 44.1kHz
MP3Gain change: <none>
Preset: V0: preset extreme (fast mode)
Surround info: none
Music length: 5,168,787 bytes
Music CRC: CD96
Actual Music CRC: 8F31
Info tag CRC: 9D1E
Actual Info Tag CRC: 9D1E

[evereux]

Is the tool calculating the actual music CRC correctly? Have you tried any other tool to see if you get the same value?

[ellisdee]

I tried dBpoweramp's CRC identification tool, as well as an updated version of Audio Identifier - I can't find any other programs that check the CRC values for each track. Needless to say, I get different values from these sources.

Additionally, the example I gave has nothing to check against in the AccurateRip database, as it is the first time the results have been upped to the db.

dBpoweramp gives me these results:

CRC32: C4C90237
MD5: 2FC3BB7C52B6006DE4C5EB1F9D347E32
AccurateRip CRC: F379912D

while AI gives me:

Music CRC: CD96
Actual Music CRC: 8F31

I'm not even sure if they are calculating the same CRCs. As well, I don't know where that AccurateRip CRC came from, as I am the only one (to my knowledge) that has sent results.

Are there other tools that can compare the music CRC values?

As I have mentioned, the files ripped seem to have no problems, but this is somewhat worrisome.

[ellisdee]

More info:

I've checked the 25 or so rips that I've recently done and they all have similar issues. The Music CRC and Actual Music CRC values differ in every single track that I have ripped using the aforementioned grabber (EAC) and encoder (LAME).

The following info is from a log file created by the rip that I have previously posted information about.

-----------------------------------

Exact Audio Copy V1.0 beta 1 from 15. November 2010

EAC extraction logfile from 17. March 2011, 18:05

artist / cd title

Used drive : TSSTcorpCDDVDW SE-S084C Adapter: 1 ID: 1

Read mode : Secure
Utilize accurate stream : Yes
Defeat audio cache : Yes
Make use of C2 pointers : No

Read offset correction : 6
Overread into Lead-In and Lead-Out : No
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks : No
Null samples used in CRC calculations : Yes
Used interface : Native Win32 interface for Win NT & 2000
Gap handling : Appended to previous track

Used output format : User Defined Encoder
Selected bitrate : 128 kBit/s
Quality : High
Add ID3 tag : No
Command line compressor : C:\Program Files (x86)\Exact Audio Copy\lame.exe
Additional command line options : -V 0 --vbr-new --add-id3v2 --ignore-tag-errors --ta "%a" --tt "%t" --tg "%m" --tl "%g" --ty "%y" --tn "%n" %s %d

[Sebastian Mares]

I might be mistaken, but aren't music CRC and actual music CRC the checksums of the compressed MP3 (as written in the LAME header and as calculated) while the CRCs reported by EAC, AR and dBpoweramp are those of the uncompressed file?

[ellisdee]

I have no idea. I'm pretty much just a n00b looking to rip his music for digital listening pleasure.

[Zarggg]

If that's the case, I would suggest to trust EAC's values. If the test and rip give the same checksum, then it is probably accurate for your purposes.

[Aleron Ives]

The CRC you get depends on how much of the file is being analyzed. I believe EAC has options that allow you to change whether you count silence at the end of a track when generating the CRC, for example. If you perform a CRC on the actual WAV file, you're also including the 40-byte header that WAV files have in the CRC generation, even though it isn't part of the actual music. These kinds of things can cause you to receive different CRC values in different programs. If AccurateRip tells you that your track was ripped accurately, don't worry about the CRC.

[db1989]

My assumption is that Music CRC is the value stored by LAME, while Actual Music CRC is AI's own calculation (probably based on the entire file). Or maybe vice-versa.

[greynol]

I believe EAC has options that allow you to change whether you count silence at the end of a track when generating the CRC, for example.

This is not true. EAC provides the option of excluding any silent samples from the calculation. These samples may fall anywhere within the file. It should be well noted, however, it isn't that samples are excluded, but rather the data in either channel of a sample that is excluded (e.g.: the left channel of a sample has a value of zero and is discarded from the calculation while the right channel of the sample is non-zero and is therefore kept).

Anyway, this discussion of EAC logs, EAC configuration, EAC checksums, AR hashes and checksums of wave files whether it be for the container+data or just data is completely irrelevant. The OP is talking about Audio Identifier and mp3 files created by Lame.

@ellisdee: just listen to your music. There is a problem only if you hear it. For all we know, the software on which you're relying is buggy.

This post has been edited by greynol: Mar 26 2011, 22:49

[ellisdee]

Thanks all for the input, it is much appreciated.

For shits and giggles, I decided to rip the same cd with my desktop, rather than my laptop. My laptop was the one producing CRC / Actual CRC differences, where I was using an external USB CD writer.

Ripping on my desktop produced different and "proper" results - my desktop rip is identified as having the same music CRC and actual music CRC values. File sizes and bit rates are slightly (miniscule) different on the desktop vs laptop.

I'm thinking now that there is possibly an issue with having ripped from an external CD writer, relating either to the settings I am using in EAC or with the writer itself. I will experiment with this further.

[greynol]

MP3 encoding happens after the ripping, though EAC can be configured to tag after that, but you aren't having EAC tag so that's a moot point. Even if it was tagging your files, I seriously doubt EAC has anything to do with your problems.

[Zarggg]

Anyway, this discussion of EAC ... is completely irrelevant. The OP is talking about Audio Identifier and mp3 files created by Lame.

@ellisdee: ... For all we know, the software on which you're relying is buggy.

That is what I was attempting to drive at with my response.

[greynol]

I think the speculation/skepticism should be pointed at Audio Identifier and/or Lame. I think it is well within the realm of possibility that these 16-bit hash values are processor/compiler-dependent.