bugmenot

Oh, well, as I'm not a pro, I'm not exactly sure how to find a part which is predominantly mono.. And I don't think you'd like to download 170 MB (x2) of Jackson 5 FLACs :p
But of course, I could upload them, if you wish.. else I could post the EAC waveforms of each file or try to find a mono part myself (if I knew how)

greynol

Look for sections that are heavy in bass or a single vocal track. Just use your ears.

Teller

The sample files you uploaded to rapidshare are identical except that one has been shifted
by 2 bytes making the left channel into the right channel and the right channel into the left channel.

greynol

Glad to see you've gotten caught up.

<laugh>

Teller

Light years ahead of those asking for mono samples.
<laugh>

greynol

http://www.digital-inn.de/131492-post4.html
http://www.digital-inn.de/131520-post12.html

Still think swapping channels will work?

<laugh>

Care to comment on which is the correct one and/or going about figuring out which?

Teller

Eliminating an incorrect or inconsistent setting is a diagnostic tool. Try it some time. And yes, swapping the speaker output jacks will put the correct channel in the correct position where an audio shift swapped channels. Which part of forum speak “<laugh>” don’t you understand?

@ bugmenot
Find any predominantly mono bassie sections for us?
<LAUGH>

greynol

You're in desperate need of a clue (still)...

CRC for ASUS rip: FDE10E0D
CRC for Hitachi rip: 07AA1B24

CRC for ASUS rip (channels reversed): E6AD2A58
CRC for Hitachi rip (channels reversed): E2C96E01

What part of "channels offset by a sample" don't you understand?

I misspoke earlier when I said you were caught up; you're still behind.

bugmenot

whoops. now I understand, monophony is what you're looking for. I was thinking of mono as in 'one channel' as opposed to stereo :p
I uploaded another track which I think is mono, the first part of the track is sung, without instruments, which, AFAIK, is monophonic..

http://rapidshare.com/files/89693979...racks.zip.html (45 MB)

I'll try to find other tracks if this doesn't help or isn't what you're looking for

greynol

That did the trick. The ASUS rip is the good one.

bugmenot

Thanks

I still wonder why this happened on this particular CD, but is this really a drive problem?
Good to know that the ASUS drive ripped correctly, though.

After reading your explanations and comparing the ASUS wav with the Hitachi wav with it's channels reversed, I did see how the channel is offset by one sample.. But I guess I still don't understand how the mono sample helped you see which drive did the incorrect rip..

___

I'm not sure if I should start a new thread for this, as it seems to be a somewhat different issue:
I just re-ripped another CD, and am getting different CRCs for each drive on this CD as well.
When I compare the files, there are several different sample errors (the channels are not switched like on the last CD)..
I'm not sure how to interpret this, but I can't decide which rip is the accurate one here either :/
(CD is protected with Copy Control BTW)
edit: also ripped the CD with burst mode, still different CRCs

I uploaded a sample track again: http://rapidshare.com/files/89958609...racks.zip.html

Attached Files

	ASUS - Never Forget.log.txt (7,0 KB, 2 views)
	HLDTST - Never Forget.log.txt (7,0 KB, 2 views)

greynol

Yes and I've seen this before with a different Hitachi drive.

I checked the phase difference between channels.

It would be better to post logs first before posting samples, but looks like neither is accurate in this case.

JackRipper

I have four drives: Plextor PX-40TS, Plextor PX-W4012A, Plextor PX-716A,
and TSSTcorp SH-S223Q. Apparently all of them are correctly configured with the appropriate read offsets, and I have observed that for a CD whose tracks are all accurately ripped, all the four drives show exactly the same CRC for the whole CD and exactly identical track codes for all the tracks.

I have a CD for which the Test/Copy CRC values are consistent for any one of the four drives, but each drive gets a different value. Moreover all the four drives give the same track code for each track, and no track is verified as "accurately ripped". Since the range quality is always 100%, and no error or suspicious position is reported, I am at a loss to understand why each drive finds a different CRC, and suspect that this has something to do with the fact that the tracks are not verified.

Attached Files

	00950-Solti - Mahler - Symphonies - CD5-PX-40TS.txt (2,1 KB, 2 views)
	00950-Solti - Mahler - Symphonies - CD5-PX-W4012A.txt (2,1 KB, 2 views)
	00950-Solti - Mahler - Symphonies - CD5-PX-716A.txt (2,1 KB, 1 views)
	00950-Solti - Mahler - Symphonies - CD5-TSST-SH-S223Q.txt (2,1 KB, 3 views)

greynol

Your disc probably ends in low level noise. Enable overreading with your Plextor drives and you'll probably get matching CRCs between the three of them.

AR results have absolutely no influence over the audio data returned by a drive. There is a very high likelihood that you have a different pressing; nothing more, nothing less. Create a cue sheet with gaps and load it into the newest version of CUE Tools and you'll probably see that the tracks can be verified.
http://www.hydrogenaudio.org/forums/...howtopic=66233

Next time, please save us the guesswork by comparing the wave files on a sample by sample basis. EAC even has a built-in tool which will allow you to do this.

JackRipper

Thanks, greynol. Everything worked out as you said: the three Plextors gave the same CRC (overread enabled), and the TSSTCorp drive gave a sync error at the end of the rip, which I undestand is its way of reporting it cannot overread.
Thanks also for the referral to CueTools, which I have found quite useful.