Hi,

I have just finished a test, but I'm not totally sure about the conclusion:


About the test

I wanted to find out, which one of my 4 drives I should use for DAE in order to rip my 500 CD-Collection on harddisk (and convert it to musepack).


1. Drives

PC No.1:

Plextor Premium (Firmware 1.06)
Toshiba 1912

PC No.2:

Toshiba 1612
Lite-On LTR 40125S


2. Software

EAC 0.95 beta 2 (without cdrdao)
cdda2wav 2.01.01a01 (in Linux)
Plextools Pro 2.25

OS1: Mandriva Linux 2005LE
OS2: Windows XP


3. CD

Guns'n'Roses - Appetite for destruction
Actually I wanted to take more than 1 CD, but after I ran in strange results I have finished testing so far.


4. EAC-Drive features (Windows)

Plextor Premium: Accurate Stream: YES, Cache Audio: YES, C2-Error-Correction: YES
Toshiba 1912: Accurate Stream: YES, Cache Audio: NO, C2-Error-Correction: YES
Toshiba 1612: Accurate Stream: YES, Cache Audio: NO, C2-Error-Correction: YES
Lite-On LTR 40125S: Accurate Stream: YES, Cache Audio: YES, C2-Error-Correction: YES


5. Options for Extraction




6. The results

In order to test the extracted wav-Files I generated md5sums of them. For that I used the md5summer in Windows and the command line in Linux (md5sum).

PC1:

1. cdda2wav in Linux:
PlexPremium wav's has different md5sums than the wav's extracted with Toshiba 1912. Paranoia option had no effect.

2. EAC in Windows XP:
PlexPremium wav's has different md5sums than the wav's extracted with Toshiba 1912.
BUT the md5sums with EAC of each drive are the same as with cdda2wav :!:

3. Plextools Pro in Windows XP:
The wav's from the PlexPremium are the same than with EAC or cdda2wav.

All these 3 steps I performed with my "main" PC called PC1. I still have an older one with Toshiba 1612 and Liteon 40125S. So, let's go on:

PC2:

4. EAC in Windows XP:

Toshiba 1612 wav's are totally different from the ones in PC1.
BUT all wav's extracted with Liteon drive match the md5sums of Toshiba 1912 from PC1 :!:


Conclusions

At this point I have stopped more testing as these results are really strange for me! Well, it seems that ONLY Toshiba 1912 and Liteon do correct ripping of audio?

Any comments?

First question: Did you use Offset correction?

Thats the point, the drives have different offsets (see http://www.accuraterip.com/driveoffsets.htm) and each drive creates a minor different WAV. Because of that md5sum compute different checksums.

Compare the rips with EACs buildin WAV-Compare (menu->tools->Compare WAVs "Ctrl-W"). EACs Compare ignores the 0-samples-silence part of the WAV (generaly CDs start/end with 0-Silence) and compares only the realworld-audio part.

To be able to compare md5 you should have ripped with proper "sample offset" correction for every drive.
Otherwise use EAC wav compare - if the rip is accurate you should only see a number of "missing samples" (offset) in the end or beginning of tracks.


Good. All these rips are likely accurate.


This is probably a coincidence - check if these two drives have exactly the same sample offset.


No. Conclusions should be:
1) you were lucky to rip a good clean CD - as the different software give you the same md5 for each drive.
2) all drives are suitable for ripping

You must carefully double-check the drive options in EAC - caching and C2.
To get secure rips on not-so-clean CDs these options must be set precisely correct for your drives.
Two great risks: to set caching "No" for a drive which does actually cache, and to set C2 "Yes" for a drive which does not reliably report C2.

If unsure, set C2 "No". Caching is usually detected well by EAC.
Also you can use AccurateRip plugin with EAC.

Paranoia mode will have no effect with the drives other than the Toshiba, as the paranoia routine comes from cd-paranoia i believe. Drive that cache audio don't work with cd-paranoia, as it has no workaround like EAC. This was the case a few years ago anyway, when i did testing and cdparanoia hasn't changed since then.

Kristian

Actually, caching and C2 should never be enabked when ripping if your after a secure rip. Just an example of what my log looks like:

If I use the same read mode setting and the correct offset on any other drive i have I get identical files, aside from the last track since my other drives cannot overread. While having C2 enabled doesn't mean your rip won't be accurate, i've noticed it often causes more errors than it corrects.

analyzing an md5 sum is useless compared to a wav compare utility that works like a diff (i.e. frank klemm's wavcmp) - i'm pretty sure EAC works in the same way.

and "disable cache" only works on drives that actually don't use a cache for audio - for ones that do (you guessed it) you need to enable cache so EAC can alter the rip.


later

That seems confused / backwards. If the drive caches, then the "Drive caches audio data" option should be checked (enabled). The log will say "disable cache". Checking the option effectively disables the rereading of sectors from the buffer/cache instead of from the actual disc.

Generating MD5 for WAV files is not a good idea - WAV files have RIFF header which can be different for every file even if audio data itself is the same - first you should extract raw audio data and then generate MD5.
Additionally to other's suggestions, if you compare EAC's CRCs for different drives, make sure that "Fill up missing offset samples with silence" & "No use of null samples for CRC calculations" options are ticked.

Thank you very much, guys! You are all a great help. I didnt believe that a missing offset correction would have such an influence on my results, as I have read many discussions in a newsgroup about the pros and cons of offset-correction. And I finally came to my conclusion to stop correcting it. But obviously, I'll change my mind.

Does anybody know if there is something like wavecompare in EAC for Linux? I have read the manpage of diff, but I'm not sure about the options to make.

Just enable 'EAC Options' --> 'No use of null samples for CRC calculations', and then compare CRC's. This option makes it possible to compare rips done with different drives, without the need of using offset correction...

-Martin.

MD5 hashing checks the file data, not the audio data. To compare the audio data you need to use something like foobar2000's bitcompare component. If you get identical MD5 hashes then your files are bit identical, however getting non-matching hashes does not necessarily mean that the audio data is not identical. If you are comparing them untouched from EAC is it likely that all metadata will be identical, but you should not use a file compare utility as a general tool for comparing different audio files.

Not for Audio CDs with audio data right up to the end of tracks, such as mix cds.

To confuse you even more:

I think that using offset correction is not really necessary in everyday ripping - it is just a nice extra - especially for "perfectionists".

But once you know your drive offset, there is no reason not to use correction (if your software supports it). It doesn't cost anything.

(By the way, a "perfectionist" would also want a drive which can overread lead-in/lead-out depending on the offset, or a drive with zero offset)

/Edit: I forgot: to benefit from AccurateRip one must use offset correction.

Oh, I'd say, I am a "perfectionist".




Of course. But as I remember the huge discussions the author of cdrecord Jörg Schilling and many others "experts" said that it is technically not possible to find the correct offset. Dont ask me about the details as it is a long time ago... about 3 years maybe or more. ( If you're interest check groups.google for de.comp.hardware.laufwerke.brenner --> offset)


P.S.
I have just checked all the wav-files with EAC and they are identical! There is for instance just the "error" 18 repeated samples at 00:00:00.149 at the beginning of track 1.

Bingo! Yes, you are right. Both have the same offset!