I did some testing over the weekend. Not really done yet as I appear to have opened a can of worms. Thoughts appreciated. Feel free to comment here and on the blog; I'd like to collect thoughts there but don't forgot to post here too.

I found some anomalies when ripping. I used J. River, EAC, 4 drives, and 6 rips. I found pitch variance in a sample from the ripped wav; filesize were the same down to the byte.

http://digitanalogue.blogspot.com/2008/08/...en-ripping.html

thanks
DC

Moderation: Fixed your broken link.

Regarding the comparison, I think there are some wrinkles that need to be smoothed out; with proper rips, you shouldn't be getting those kind of differences.

Regarding the "nice guy", I think he's been very misled.

All I can say is your method of measuring pitch is flawed.

Unless there was a ripping error, those pieces that you are looking at will be digitally identical. If there was a ripping error I can absolutely assure you with 100% confidence that it will not result in a change in pitch.

BTW there were multiple rereads (according to the logs, as far as I can see) so if those rereads were due to real errors, you're bound to get some high-frequency noise creeping in.

I think that's a bit misleading. Errors practically always result in a discontinuity in the waveform, even when there is interpolation going on.

Last time I looked at an impulse response in the frequency domain, it wasn't exactly high-frequency noise.

do an md5 hash on them

if the hash's are different then something messed up along the way, whether it was the drive or CD would require physical testing.

if they are the same then the pitch cannot be different as it is the exact same data

Thanks for replies and suggestions.

MD5 is a good idea. I have an app buried somewhere that I used in the past to check/verify disk transfers. Does EAC generate one as an option?

What I found most interesting was the 'errant' value reported by two different drives using two different programs.

I need to re-rip with EAC on LG and all other drives.

Regarding high frequency noise creeping in during re-reads or re-tries of sectors...what's different about this process than 'normal' ripping. Aren't sectors just being re-read?

dc

Better make sure they are offset corrected first.

That's correct, sectors are just being re-read.

I also can't believe there would be any differences between the rips. This would make the whole concept of the Accurate Rip Project obsolete.

I am pretty sure the raw audio data will be the same between same accurate rips.

I'm not using the Accurate Rip feature with EAC, but how does it handle different pressings? Are they accounted for?

I'm going to setup EAC correctly, and rip the disc again with all drives using both EAC and MC12.

I'm going to test ripping the first track too; as much as I'd dislike changing the test setup. I'm not sure it would make a difference at this point (testing the 305ms-1000ms section). It will save a lot of time.

dc

Precisely!

It is able to keep track of multiple sets of checksums for each disc ID. So yes, they are accounted for.


Exactly what are you trying to accomplish again?

did you read the data at the linked post?

dc



Alex B suggested this here:

"As I am not a drive engineer I am not sure if the output would be exactly "scrambled" when a read error occurs. It may also be averaged. However, I don't think it could possibly be anything that would change the perceivable audio quality over a longer period of time.


BTW, did you correct the read offset variences before checking the files?

According to the accurate rip database the drives have the following read offset values:
LITE-ON - DVDRW SOHW-1653S +12
LG Electronics - BDDVDRW GGC-H20 +667
PLEXTOR - DVDR PX-716AL +30

Though, these are samples -- 44100 samples in one second so they should not be able to cause a difference over a 500 ms time period. Also the Lite-On and Plextor drives are very close to each other and you said the Lite-On drive produced different results."

dc

Yes, I have read over the article presented in your first post.

Besides the rip logs, you've presented nothing worth getting excited about.

Well, there was no ripping error reported and there is a detected difference in pitch. I'm confused at your statements here.

Even with re-tries (sector re-reads) I'm getting secure rips (as reported by the software) but returning with different data.

dc

1) Just because there is no error reported does not mean there was no error. This is the like the first rule of DAE.

2) I don't trust your "detected difference in pitch" and in this regard think your methodology and conclusion are lacking.

I've compared hundreds of rips and can tell you that you're going about it in the wrong way. Both EAC and foobar2000 have a wave comparison feature. Personally I align the two rips in time using Adobe Audition's Multitrack View and subtract one from the other.

These are what errors tend to look like:



Click to view attachmentClick to view attachment

I commented on his post... it's largely repeating what greynol just said.

http://digitanalogue.blogspot.com/2008/08/...452582745173282



Just because your software reports a change in pitch doesn't necessarily mean a change in pitch actually occurred. Pitch detection algorithms are notoriously unreliable when fed non-tonal data... like perhaps what might result from a bad rip.

You've gotta learn how to interpret these results. The raw sample values are the core data and their differences represent intrinsic differences in the data. And analyses like inversion/downmixing etc that work right off of that data is similarly authoritative. Pitch analysis is a quite complicated algorithm and is going to fail sometimes. If you feed it the same data every time, it will most likely return the same result every time, but if you feed it different data, it might not always return a different result. The same goes for ripping.

Joncat,

If you were to use EAC's WAV comparison tool, it could help to figure out if you're actually comparing the correct data in the first place (like, not offset shifted). This tool reports exactly which samples are differing, which is much more useful in such an analysis.

Thanks all. Tons of great suggestions. I 've never done this before so I wasn't claiming to be right; quite the contrary as I was looking for responses to the methodology.


I agree with this and thought I expressed this but sorry if I wasn't clear.

I'll do new rips and try the new methods suggested here; if I can figure them out

best,
jc

I put the newly ripped wav files on my X61 laptop but EAC won't even startup properly on Vista; eventually just crashes. Possibly related to the fact that this laptop has no optical drive?

I saw this on the EAC froum Greynol; why wouldn't EAC pick up on a CRC error:

"I will be more than happy to point you to some log files showing different CRCs even though EAC reported no errors."

I'm trying to devise a round of tests. I'm going to rip track 1 of the "Hamiltonia" disc with every drive I have with both EAC and MC12 and start looking at the files with the tools suggested here.

jc

Errors don't in result random gibberish, as people often believe. When the damage giving rise to reading errors is only slight, it is possible for the same wrong data to come up repeatedly. These are known as consistent errors. In fact it's possible for more than one set of wrong data to come up repeatedly. If such an error passes EAC's threshold of acceptance, it will not be reported.

When using C2 pointers with EAC, things are slightly different. Data is no longer compared unless re-reads are performed. In order to detect an error, EAC relies entirely on the C2 pointers given by the drive. Since many drives don't provide these pointers in a way that works reliably with EAC, errors can also go unreported.

EDIT: Spelling/grammar/punctuation.