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: One set of rippers get same MD5—other set differs—how can this happen? (Read 2184 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

One set of rippers get same MD5—other set differs—how can this happen?

First of all, this is an amazing community, thanks for being so professional.

I have one simple question and since it's easier to show it...

This is what I get when I encode the same track from an original audio CD:

CRC32      MD5               Filename

F4658B95   4DD9BD15DA751BFDFC3C8BF7CD4A54C8   D:\Downloads\Test - CUERipper (2.1.2a).flac
F4658B95   4DD9BD15DA751BFDFC3C8BF7CD4A54C8   D:\Downloads\Test - dBpoweramp (Reference R14.2).flac
F4658B95   4DD9BD15DA751BFDFC3C8BF7CD4A54C8   D:\Downloads\Test - EAC (1.0 Beta 3).flac
F4658B95   4DD9BD15DA751BFDFC3C8BF7CD4A54C8   D:\Downloads\Test - foobar2000 (1.1.11).flac
F4658B95   4DD9BD15DA751BFDFC3C8BF7CD4A54C8   D:\Downloads\Test - MusicBee (1.4.4418 RC)

9DFC546A   6ACCFCDFC4169B096884D855A6D5A0AE   D:\Downloads\Test - CDex (1.70 Beta 4).flac
9DFC546A   6ACCFCDFC4169B096884D855A6D5A0AE   D:\Downloads\Test - Easy CD-DA Extractor (16.0.0.1).flac
9DFC546A   6ACCFCDFC4169B096884D855A6D5A0AE   D:\Downloads\Test - iTunes (10.5.3.3 x64).flac
9DFC546A   6ACCFCDFC4169B096884D855A6D5A0AE   D:\Downloads\Test - MediaMonkey (4.3 RC).flac
9DFC546A   6ACCFCDFC4169B096884D855A6D5A0AE   D:\Downloads\Test - fre:ac (1.0.19).flac
9DFC546A   6ACCFCDFC4169B096884D855A6D5A0AE   D:\Downloads\Test - Winamp (5.6.2.3199).flac

How can this be possible? Can they (AE) really be all "wrong"? They don't have some feature that EAC, dBpa and CUERipper enable in my drive (Pioneer DVR-219LBK)?

*The three (C8) rips have been tested with AccurateRip and they give the message 8, EAC also says 100% accurate.

Thanks,

edit: on MusicBee it changed the offset to +6 (when I clicked Lookup), C2 error check, verify with AccurateRip and secure rip and I'm happy with the CRC result. What is that I've changed and made the rip to result the same?
edit2: I got it, it's the CD Drive Offset, I just checked with this list (http://www.accuraterip.com/driveoffsets.htm) and it's the +6 that made the rip accurate. Now I want a list of every CD ripper software where you can't change that
edit3: Sorry guys, this post is a big fail! I know what the problem is and how to fix/change it, is there a list of software that allow you to change the CD Drive Offset?

One set of rippers get same MD5—other set differs—how can this happen?

Reply #1 –
Read this:
http://wiki.hydrogenaudio.org/index.php?title=AccurateRip

The AccurateRip database generally only contains info about offset-corrected rips. Your offset-corrected rips have the same audio as the uncorrected ones; it's just shifted slightly so that it can be compared to rips made with drives that have different offsets. It's not really that one rip is accurate and the other is not. One rip was checked against other rips and matched, and the other rip was not checked at all.

To slightly oversimplify: Imagine a book divided into chapters. Chapter 3 has 800 words. I ask a robot to tell me words 1 through 800 of chapter 3. Instead it tells me words 7 through 800, plus the first 6 words of chapter 4. I got 800 words, but they're offset. I want to know if other robots reading the same book got the same words as me for chapter 3, but every robot has a read offset, and they're all different. To compare our results for reading chapter 3, we need to all "correct" our offsets. So I tell the robot to tell me the last 6 words of chapter 2, knowing that it will actually give me the first 6 words of chapter 3. I put these words at the beginning of my file, and I chop off the last 6 words since they were from chapter 4. Now I have 800 words which represent chapter 3, and I can see if my chapter 3 matches the ones read by other robots that did the same kind of correction.

Instead of book, chapter, words, robot ... think CD, track, samples, drive. Make sense?

If you use CUETools to check your uncorrected rips, it will tell you that they match quite a few rips if the offset is corrected. So the rips are fine. We are talking about a fraction of a second of disagreement in the track boundaries. Also the standard for comparing rips is actually off by 30 samples, so even when a rip is "corrected", it's probably still offset. And then consider that batches of CDs are manufactured with different offsets, and regular CD players have the same issues...so the track boundaries are always approximate, and there isn't really a way to be "correct".

One set of rippers get same MD5—other set differs—how can this happen?

Reply #2 –
mjb2006, thank you.