[ffooky]

It occurred to me that all my previous tests were performed with an internal (ATAPI) drive and that I have no idea at what point point the audio data cached by the drive is flushed. Accordingly I repeated the tests using an external (Firewire) drive, 'LITE-ON ' Model 'LTR-24102B ' Revision '5S57' which was turned on and off between each rip, except the three named "LO_UNQUIT_...."

I ripped the track that produced problems in the first set of tests, multiple times with EAC, xACT, Toast 7.0.1 and by dragging to the Finder (OS X 10.3.9). Unfortunately I was unable to include cdparanoia as I could not get it to recognise my external drive.

With the EAC rips I shut down the virtual machine, closed Virtual PC and then deleted the Undo Drive file between rips as well as turning the CD drive on and off so there was absolutely no chance of anything being cached. Error correction lights were lit (one row) at varying points of all test and copy routines.

EAC extraction logfile from 3. October 2005, 22:41 for CD
Weezer / Buddy Holly (EP)

Used drive  : MS   Adapter: 1  ID: 0
Read mode   : Secure with NO C2, accurate stream, disable cache
Read offset correction : 0
Overread into Lead-In and Lead-Out : No

Used output format : Internal WAV Routines
                     44.100 Hz; 16 Bit; Stereo

Other options      :
    Fill up missing offset samples with silence : Yes
    Delete leading and trailing silent blocks : No
    Native Win32 interface for Win NT & 2000


Track  4
     Filename C:\Documents and Settings\Waldo Jeffers\My Documents\04 Jamie (Geffen Rarities LP Version).wav

     Peak level 81.7 %
     Track quality 99.9 %
     Test CRC 58D43EC9
     Copy CRC 58D43EC9
     Copy OK

No errors occured


End of status report

Now xACT. Four rips separated by ------------ (unnecessary output omitted)

There is no sound support configured!
Type: ROM, Vendor 'LITE-ON ' Model 'LTR-24102B      ' Revision '5S57' MMC+CDDA
176128 bytes buffer memory requested, 4 buffers, 13 sectors
#Cdda2wav version 2.01a32_darwin_7.4.0_power-macintosh_powerpc, libparanoia support

Track  4: 'Jamie (Geffen Rarities LP Version)'
samplefile size will be 45593564 bytes.
recording 258.4666 seconds stereo with 16 bits @ 44100.0 Hz ->'audio'...
using lib paranoia for reading.
percent_done:
100%  track  4 'Jamie (Geffen Rarities LP Version)' recorded successfully

100%  0 rderr, 0 skip, 0 atom, 0 edge, 0 drop, 0 dup, 0 drift

100%  258 overlap(0.5 .. 0.5)

----------------------------------------------
recording 258.4666 seconds stereo with 16 bits @ 44100.0 Hz ->'audio'...
using lib paranoia for reading.
percent_done:
 100%  track  4 'Jamie (Geffen Rarities LP Version)' recorded successfully

100%  0 rderr, 0 skip, 0 atom, 0 edge, 0 drop, 0 dup, 0 drift

100%  258 overlap(0.5 .. 0.5)

-----------------------------------
recording 258.4666 seconds stereo with 16 bits @ 44100.0 Hz ->'audio'...
using lib paranoia for reading.
percent_done:
 100%  track  4 'Jamie (Geffen Rarities LP Version)' recorded successfully

100%  0 rderr, 0 skip, 0 atom, 0 edge, 0 drop, 0 dup, 0 drift

100%  258 overlap(0.5 .. 0.5)

----------------------------------------
recording 258.4666 seconds stereo with 16 bits @ 44100.0 Hz ->'audio'...
using lib paranoia for reading.
percent_done:
100%  track  4 'Jamie (Geffen Rarities LP Version)' recorded successfully

100%  0 rderr, 0 skip, 0 atom, 0 edge, 0 drop, 0 dup, 0 drift

100%  258 overlap(0.5 .. 0.5)

As you can see, the output from the four rips was identical and no errors or problem sectors were reported.

The results

7931b23da6c5b8bf4ce71bee1448c327  [shntool]  LO_EAC1.wav
7931b23da6c5b8bf4ce71bee1448c327  [shntool]  LO_EAC2.wav
7931b23da6c5b8bf4ce71bee1448c327  [shntool]  LO_EAC3.wav
7931b23da6c5b8bf4ce71bee1448c327  [shntool]  LO_EAC4.wav
a5fdea1a598f2a68be6e55585107ebf2  [shntool]  LO_Finder1.aiff
7931b23da6c5b8bf4ce71bee1448c327  [shntool]  LO_Finder2.aiff
7b826dea52078c8cea25847fd361c985  [shntool]  LO_iTunes1.wav
4876a55f547c70f000ee8ace94ef2a27  [shntool]  LO_iTunes2.wav
f6a027fea6664bfec81e39deb61ea2b1  [shntool]  LO_iTunes3.wav
b9610ce44fadcc4da5bfef3271ce7d41  [shntool]  LO_Toast1.wav
7931b23da6c5b8bf4ce71bee1448c327  [shntool]  LO_Toast2.wav
7931b23da6c5b8bf4ce71bee1448c327  [shntool]  LO_UNQUIT_Finder.aiff
4fe6f039c146db5489b7ce10acfac10a  [shntool]  LO_UNQUIT_Toast.wav
bb580449b92e51764678c1d41f4f7df8  [shntool]  LO_UNQUIT_xACT.wav
92136c8a759964fe0b359f5607b8c717  [shntool]  LO_xACT1.wav
7931b23da6c5b8bf4ce71bee1448c327  [shntool]  LO_xACT2.wav
243eb0cae251aa05d00531e063fae24d  [shntool]  LO_xACT3.wav
bb580449b92e51764678c1d41f4f7df8  [shntool]  LO_xACT4.wav

The obvious and most important features of the results are firstly that EAC produced identical files from all rips and its accuracy under VPC should not be questioned. Secondly and most perturbingly, it's clear that a clean bill of health in an xACT output is absolutely no guarantee of an accurate rip. Four rips, four clean output logs and four non-matching checksums.

It surprised me that this drive produced error correction lights with EAC and no problem sectors with xACT whereas with the Pioneer, the results were reversed.

I'm afraid this appears to rule out xACT as a guaranteeable ripper, even with an unblemished output log. The only get-out clause may be that the LiteOn is just not compatible with cdda2wav and in the interests of exhaustiveness I ought to try multiple rips with xACT using the internal Pioneer, rebooting (maybe even shutting down completely and starting up) between each one to see if it will produce matching data w/a clean output log. Maybe another time