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: Ripping Issues - Music CRC + Actual Music CRC Different (Read 5734 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Ripping Issues - Music CRC + Actual Music CRC Different

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

Ripping Issues - Music CRC + Actual Music CRC Different

Reply #1
Is the tool calculating the actual music CRC correctly? Have you tried any other tool to see if you get the same value?
daefeatures.co.uk

Ripping Issues - Music CRC + Actual Music CRC Different

Reply #2
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.

Ripping Issues - Music CRC + Actual Music CRC Different

Reply #3
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

Ripping Issues - Music CRC + Actual Music CRC Different

Reply #4
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?

Ripping Issues - Music CRC + Actual Music CRC Different

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

Ripping Issues - Music CRC + Actual Music CRC Different

Reply #6
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.

Ripping Issues - Music CRC + Actual Music CRC Different

Reply #7
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.

Ripping Issues - Music CRC + Actual Music CRC Different

Reply #8
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.

Ripping Issues - Music CRC + Actual Music CRC Different

Reply #9
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.

Ripping Issues - Music CRC + Actual Music CRC Different

Reply #10
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.

Ripping Issues - Music CRC + Actual Music CRC Different

Reply #11
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.

Ripping Issues - Music CRC + Actual Music CRC Different

Reply #12
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.

Ripping Issues - Music CRC + Actual Music CRC Different

Reply #13
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.