QUOTE(UrbanVoyeur @ Feb 11 2007, 20:23)

QUOTE(bhoar @ Feb 11 2007, 19:30)

My one caution is this: a lot of USB 2.0<->ATAPI bridge chipsets have difficulty with the proper handling of disc errors being reported back to the PC. Because of this, I recommend firewire instead of USB when planning to rip CDs and DVDs using an external optical drive, especially if you believe you may end up feeding the drive scratched/damaged discs.
I did not test external USB vs Firewire, but I did test external USB (toshiba) vs internal IDE (samsung), on several problem discs - bad pressings, and lightly and heavily scratched. The lightly scratched discs raised the red error flags on both, but in the end ripped fine on USB and IDE.
To respond to both the above and Fandango in one post:
The above tests were with a single brand of enclosure, yes?
The issue I have with USB bridges is that the reliability and stability of the USB Mass Storage API <-> ATAPI translation varies significantly among USB chipsets. In addition, the USB Mass Storage class is rather limited in the way it can talk to devices.
Also, since ATAPI itself is a not quite linear way to encapsulate SCSI CDB commands, in all their varied insanity, over ATA's DMA/PIO modes, I expect the following things to happen much more often over USB vs. other connection methods (though this can vary per chipset):
1. SCSI CDB requests that work via IDE/PATA/SATA can error out or silently fail with the same device when connected via a USB bridge chipset. I still haven't found a single USB chipset that can report the hard drive serial number to me in response to the standard CDB query for one.
2. Repeatedly performing some operations that were considered unlikely to be encountered often by the bridge developers, and therefore were less tested, will cause the bridge to lock up and the device to disappear. I've seen reports of USB-connected drives that disappear off the USB bus when attempting to handle scratched discs, where the user pulled the drive, connected it directly via an 80-conductor IDE cable and stopped having that problem.
My understanding with firewire, which was based on SCSI to begin with, is that the translation is somewhat less complex and therefore both issues above are significantly less likely to happen. I believe, but have no proof, that this is one reason manufacturers of duplication equipment have moved from SCSI directly to firewire for their mainboard -> drive connectivity, even though the use of USB 2.0 would keep their manufacturing costs down.
My own ranking of optical drive connection types by hardware behavior/reliability is as follows:
1. SATA/eSATA
2. Firewire
3. PATA
4. USB 2.0
You can reverse 2 and 3 if you aren't using Microsoft's IDE controller drivers that automatically (and permanently) reduce the IO method from DMA -> PIO when detecting a lot of errors, a problem that crops up often when dealing with scratched discs.
-brendan