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: 2 pressings, why do some CRCs w/o nulls match while others don't? (Read 5087 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

2 pressings, why do some CRCs w/o nulls match while others don't?

And as if different offsets for different pressings were not enough ...

Consider the following two CUETools outputs, from two different physical discs of the same release (that's Laibach's Opus Dei, BTW):
Code: [Select]
[Verification date: 03.01.2010 01:42:38]
[Disc ID: 0019c7f9-00f1122c-9f0dd60c]
Disk not present in database.

Track	[ CRC32  ]	[W/O NULL]	
 --	[076BC62A]	[874C9323]	
 01	[D4725F4C]	[F28567B1]	
 02	[1792D0E3]	[43DF8B8C]	
 03	[76321A52]	[3CAB0999]	
 04	[24C91315]	[B3561DAF]	
 05	[7B073797]	[1AD9DF64]	
 06	[0FB89D64]	[6D419E2D]	
 07	[12A0C65B]	[FD08593F]	
 08	[57E1EC7B]	[BA929190]	
 09	[7C34311C]	[534CA180]	
 10	[F4838802]	[BF2A72AA]	
 11	[572D26C6]	[4E2DD89C]	
 12	[B8143D2E]	[AE5F90C1]
Code: [Select]
[Verification date: 03.01.2010 01:41:09]
[Disc ID: 0019c7f9-00f1122c-9f0dd60c]
Disk not present in database.

Track	[ CRC32  ]	[W/O NULL]	
 --	[80EA40EB]	[874C9323]	
 01	[4C0468F0]	[C83598E4]	
 02	[F3CFD357]	[85E7580C]	
 03	[80EACF12]	[3CAB0999]	
 04	[ABA93D75]	[B3561DAF]	
 05	[3D8A4E89]	[1AD9DF64]	
 06	[A3BB9803]	[6D419E2D]	
 07	[0876EF1B]	[FD08593F]	
 08	[3F3501E9]	[BA929190]	
 09	[A27D5D65]	[534CA180]	
 10	[2683EA93]	[BF2A72AA]	
 11	[DF5E28B4]	[4E2DD89C]	
 12	[E2845E1C]	[AE5F90C1]

It is the W/O NULL column that is interesting -- I still presume that the first row is the entire image after having removed leading and trailing 0's, while the track numbers are as they are with this altered image cut up track by track without removing any zeroes in between tracks -- am I right about this?

Well, the --'s match: 874C9323. It is therefore totally unlikely that these two images are different, true?
And tracks 03 ff match. But tracks 01 and 02 do not. It seems like these two pressings (I) differ in offset, and (II) differ in the boundary between tracks 01 and 02.


Edit: So, if I am right, let me suggest yet another column, so in total
- Track #
- CRCs as they are
- CRCs with the image's leading and trailing nulls removed
- CRCs with each track's leading and trailing nulls removed.


Edit2: Or, the chance to use one folder's cue sheet to verify the other -- is that possible?

2 pressings, why do some CRCs w/o nulls match while others don't?

Reply #1 –
Quote from: Porcus on
am I right about this?

No.

CRC w/o null samples means just that.  They are removed anywhere within the audio stream.  Furthermore, what is removed is any null sample whether it be just in the left channel or in the right channel.

Quote from: Porcus on
It seems like these two pressings (I) differ in offset, and (II) differ in the boundary between tracks 01 and 02.

They differ in offset only* since their Disc ID is exactly the same.  You can verify this for yourself using a wave editor or some type of comparator software (EAC, foobar2000).

*EDIT: Well some of the tracks could be shifted or have additional null samples inserted in either channel.  They could even have their channels reversed, so yeah they can differ for more reasons than offset.  Comparing CRCs w/o null samples is usually a bad idea, which is why we strongly recommend that you not configure EAC this way.

2 pressings, why do some CRCs w/o nulls match while others don't?

Reply #3 –
It is calculated with ample precision (unlike freedb).

Rather than continuing to speculate, have you compared the TOC of the discs (or even the files: shntool len *.flac or with a wave editor, for example) to see if the track lengths differ?

2 pressings, why do some CRCs w/o nulls match while others don't?

Reply #4 –
Quote from: greynol on
Rather than continuing to speculate, have you compared the TOC of the discs (or even the files: shntool len *.flac or with a wave editor, for example) to see if the track lengths differ?

They seemed not to differ, with the precision I could read off in seconds, and I have now verified that they are the same measured in samples.

But what still puzzles me is that the "--" rows match in CRC W/O NULL, and so have most but not all of the tracks.

What I would wish for CUETools, is to check for tracks which match modulo offset. As of now it seems only possible to recover that information if the CD is found in the AccurateRip database. (Evidently, CRC W/O NULL is insufficient.)

2 pressings, why do some CRCs w/o nulls match while others don't?

Reply #5 –
Quote from: Porcus on
But what still puzzles me is that the "--" rows match in CRC W/O NULL, and so have most but not all of the tracks.

I thought I explained that already; oh well.  Rest assured, there is nothing peculiar going on here.

2 pressings, why do some CRCs w/o nulls match while others don't?

Reply #6 –
Quote from: greynol on
Quote from: Porcus on
But what still puzzles me is that the "--" rows match in CRC W/O NULL, and so have most but not all of the tracks.

I thought I explained that already

Well, you said that they differ in offset only, which I assumed to be a misconception given that the CRCs fail to match when the nulls are removed.

2 pressings, why do some CRCs w/o nulls match while others don't?

Reply #7 –
There is no law that says all tracks must begin and end with null samples.

All this time has passed and you haven't compared your files on a sample by sample basis as I suggested?

2 pressings, why do some CRCs w/o nulls match while others don't?

Reply #8 –
Foobar says they do differ, so I conjecture: for the CRC W/O nulls, the track TOC is applied before the removal of nulls?

If so, then for wishlist: a column for CRC W/O nulls calculated as if track 1 index 1 were offset to start at first non-zero (in index 1, since HTOAs are usually "long").

(That should solve it -- modulo nonzeroes at the shift between track 1 indices 0 and 1, or at the very end, all depending on pressings and drive offsets?)

2 pressings, why do some CRCs w/o nulls match while others don't?

Reply #9 –
The track CRC w/nulls or w/o nulls has nothing to do with the the TOC/Disc ID.

Forget the wish list, accept EAC's alternate method of CRC calculation for what it is and ignore checksums calculated this way.  Pay attention to the CRC w/nulls and AR hashes.

Use a wave editor to see what the differences are.  You will see that the transition between tracks 1 and 2 are not comprised of null samples for at least one of those pressings while the transitions between all the rest of the tracks are.  Your two pressings differ by only an offset.  Measure this offset and apply it to one of the pressings so it lines up with the other.  Check all the CRCs again and you will see that they match.

Sorry that I didn't say this earlier since we've wasted entirely too many posts on this for me to tell you that you have nothing to worry about and that there is absolutely no need for any changes in the program with regards to this non-issue.

EDIT: If you still think there should be changes, I recommend you tell the author of EAC since CUETools is only trying to mimic what might be found in an EAC log file.