Anyway down to business. Recently I've been re-ripping all my CDs (because I lost them all before due to a drive failure) into FLAC (v. 1.2.1b) and mp3 (using the lame 3.98 encoder) using EAC combined with MAREO. I've also been carrying this task out on two different machines in order to cut down the time it will take my to do it all. And before I went nuts and did the whole lot I decided to "benchmark" if that's the right word the computer and CD drive that I've not used before by ripping 10 CDs on both machines just to check that I was getting consistent results across both machines so that the results would be no different had I done it on just the 1 machine.
So I do all the rips and make an md5 checksum file using QuickSFV of all the files I've ripped and use this checksum file to see if the rips are the same from each machine.
Out of a total of 282 songs (141 of each mp3 and FLAC):
140 of the FLAC files are the same (1 difference)
40 of the mp3 files are the same (101 differences)
You may say this is unsurprising as there may be differences in the metadata/tags, but believe you me the tags are identical, right down to the number of bits in the padding.
The FLAC file in question is the last track from the album BodyRockers by BodyRockers (please don't now finish reading because of my poor taste in music
) and I've noticed something odd. I looked at the logs for extraction from both machines and the first looked like this:CODE
Track 11
Filename C:\Documents and Settings\Al\My Documents\My Music\EAC\BodyRockers\BodyRockers\11 Stuck In A Rut.wav
Pre-gap length 0:00:01.58
Peak level 98.8 %
Track quality 100.0 %
Test CRC 46A6DB81
Copy CRC 46A6DB81
Accurately ripped (confidence 7) [86104705]
Copy OK
Filename C:\Documents and Settings\Al\My Documents\My Music\EAC\BodyRockers\BodyRockers\11 Stuck In A Rut.wav
Pre-gap length 0:00:01.58
Peak level 98.8 %
Track quality 100.0 %
Test CRC 46A6DB81
Copy CRC 46A6DB81
Accurately ripped (confidence 7) [86104705]
Copy OK
and the second log like this:
CODE
Track 11
Filename E:\My Music\EAC\EAC\BodyRockers\BodyRockers\11 Stuck In A Rut.wav
Pre-gap length 0:00:01.58
Peak level 98.8 %
Track quality 99.9 %
Test CRC 9673D243
Copy CRC 9673D243
Accurately ripped (confidence 7) [86104705]
Copy OK
Filename E:\My Music\EAC\EAC\BodyRockers\BodyRockers\11 Stuck In A Rut.wav
Pre-gap length 0:00:01.58
Peak level 98.8 %
Track quality 99.9 %
Test CRC 9673D243
Copy CRC 9673D243
Accurately ripped (confidence 7) [86104705]
Copy OK
Did you see it? The test and copy CRCs don't match up, yet the AccurateRip CRC is the same. By the way, ignore the track quality i was using secure mode (yea I know test and copy in secure mode, paranoid or what
), but something fishy's going on. You may say this is because AccurateRip is actually 30 samples out as had been previously discovered, but I had a deeper look into the files using Notepad++. I couldn't use the compare plugin as the FLAC files that I was now looking at were too large and crashed the program so I did it manually, and found that there was a small difference (16 bytes) at the beginning of the file and another slightly larger one (1357 bytes) at the end. The difference at the end could possibly be explained by the 30 sample offset, but not the error at the beginning. Does anyone wish to have a go at explaining?I've also just compared the files using the bitcompare plugin in fb2k and this was the result:
CODE
differences found: 87 sample(s), starting at 226.1177098 second(s), peak: 0.0001831 at 226.1181180 second(s), 2ch
So not even the audio is the same. Is this also due to the AccurateRip discrepancy? And how am I meant to know which is the "correct" file?
Onto the mp3 files now.
I've done the same sort of thing with the mp3 files by checking them with the bitcompare plugin and checking the actual info inside the file in Notepad++ and I've seen (from the files I've checked) that there is a difference in some of the data which offsets a lot more data which by-and-large gets put back into the same place in the file by an extra lump of data later on in the file and this happens a couple of times. The thing that confuses me though is that I've been told before that the encoders will output different results on different machines which I could accept (I presume supposedly down to different instruction sets such as SSE and MMX), but the fact that 28% (40 of 141) of these files are identical down to the last bit makes me think that this is not the case. (Oh and if anyone is wondering the CPUs on the machines are totally different, one is a 5 year old P4 before hyperthreading came along and the other is a 1 year old AMD (I can't remember the model offhand).
So why are some of these files absolutely identical while others are not. I can't see any pattern linking the files. Every album has a different number of tracks and there is no link by virtue of song number as they appear randomly and different numbers of tracks with different albums.
Thanks for reading everyone and I hope that some of you have the ultimate guru knowledge to explain these phenomena. I look forward to reading the responses tomorrow as I'm off to sleep now. Night.
<-- sleep goggles
: