bugmenot

I ripped several CDs to flac and always got the same CRCs on both drives.
Now I ripped another CD and noticed that I got different CRCs for each drive.
I ripped the CD 4 times, two times with the first drive, two times with the second and the CRCs are different for each drive.

I have no clue as to why this is happening.. And as I said, I did rip some CDs previously and got the same CRCs on both drives

Which rip should I take and which should I delete? Is this a issue with one of the drives?

Any ideas? =/

I attached the logs, let me know if I should upload some flac files too

Attached Files

	ASUS(1) - It's The Jackson 5.log.txt (5,4 KB, 14 views)
	ASUS(2) - It's The Jackson 5.log.txt (5,4 KB, 6 views)
	HL-DT-ST(1) - It's The Jackson 5.log.txt (5,5 KB, 15 views)
	HL-DT-ST(2) - It's The Jackson 5.log.txt (5,5 KB, 7 views)

greynol

Well, you used test and copy, so I'd say that you ripped the CD a total of eight times, but since you used secure mode without C2, EAC actually asked the drive to read the disc a total of sixteen times.

Performing a wave comparison really helps to figure out what went wrong. There's nothing in the log files that points to anything obvious.

Do the CRCs change and/or become the same when ripping in burst mode or when enabling C2 pointers (if either of your drives can provide them)?

bugmenot

I did a WAV Compare and this is what I got:

(1st Tracks Compared)
Error type: different samples
Position: 0:00:00.297 - 0:00:31.879

(2nd Tracks Compared)
Error type: different samples
Position: 0:00:00.167 - 0:02:14.480

(3rd Tracks Compared)
Error type: different samples
Position: 0:00:00.166 - 0:02:33.615

o_O

I uploaded the first tracks from both rips to rapidshare:
http://rapidshare.com/files/89020839...racks.zip.html

Okay, I'll rip it in Burst mode/enable C2 now and check the CRCs..

greynol

The channels are reversed and offset by a sample from one another between the two files. If you have a piece of a track that is predominantly in mono then I'd be able to tell you which is correct and which isn't.

It seems pretty clear to me that one of your drives has a problem and is not ripping properly.

Teller

Uncheck the ‘Swap Channels” option on both drives.

greynol

That will not work. The channels are offset from one another (as I said earlier).

This is something I've seen before, BTW.

Teller

Method #2
Plug the left speaker into the right output.
Plug the right speaker into the left output.

<laugh>

bugmenot

Hmm, I have some audio books, they are probably all in mono. Would it help if I ripped + uploaded some of those tracks ?

Is it really a bad drive? I don't like that idea...

Surfy

::

Try
"Null samples used in CRC calculations" No
(You have to tick the checkbox "No use of null samples in CRC calculations" in Extractions tab.)


best regards ...

::

greynol

That won't make a difference.

Furthermore, it's best for that setting to be unchecked...
http://www.hydrogenaudio.org/forums/...howtopic=57884

Surfy

::

That's wrong. He wants to compare drives with different read offsets. Move your mouse above the checkmark and read the hint, please.

I agree ...

::

greynol

If you agree, why would you want to suggest something that may produce the same CRC for two rips that are actually different. It would defeat the whole purpose.

Speaking of...
These are the stated wishes of the original poster:
EDIT: FWIW, switching the use of null samples setting will give the same CRC for this track: 3B0BA038. The reason is that the no use of null samples algorithm will skip over a null sample in either channel anywhere within the track.

When this type of error occurs, it's as if a single null sample is inserted at the beginning of the data stream which will be ignored by the no null samples version of the CRC calculation. This extra sample will appear in the left channel pushing the true first sample of the left channel into the right channel and so on. If the final sample (the right one) of the last stereo pair in the stream that got pushed out into the next track happens to be null, the CRCs will be the same for both versions. When it is not the CRCs will be different.

greynol

Now that I've been forced to recall all of this to a greater detail, I think can actually tell which of the drives produced the bad file: it's the Hitachi drive (HL-DT-ST).

If it turns out that it's as if the left sample of the first stereo pair was omitted and the stream began with what was supposed to be right sample then I'm wrong and the problem is with the other drive, so a more monaural portion of audio will still be very helpful. I can explain how a CRC that doesn't include null samples will still be the same in this situation, but it's largely academic.

A heart-felt thanks to Surfy!

bugmenot

I ripped the CD in Burst mode and still got the different CRCs (logs attached)


Okay, I then ripped a Audio book which seems to be recorded in mono and got matching CRCs on both drives, except for the last track (different samples at 0:09:02.103 - 0:09:02.117) [screenshot]

Let me know if I should rip a different (mono?) CD or upload some tracks of this one, provide more info, etc..


I'm a bit lost as to why this seems to happen on this particular (Jackson5) CD while I get matching CRCs on others

Attached Images

Image1.png (8,0 KB, 13 views)

Attached Files

	ASUS Burst - It's The Jackson 5.log.txt (5,0 KB, 6 views)
	HL-DT-ST Burst - It's The Jackson 5.log.txt (5,0 KB, 4 views)
	ASUS - audiobook.log.txt (4,4 KB, 3 views)
	HL-DT-ST - audiobook.log.txt (4,4 KB, 3 views)

greynol

This is due the non-null samples in the area that is the lead-out for one drive but not for the other.

I was hoping you would have uploaded a portion of a track from the Jackson 5. A "mono" CD is not necessary; just a portion of a track that is predominantly mono.

I don't know the exact reason why this happens either, just that one of your drives isn't providing correct data and I still believe it's the HL-DT-ST.