Help - Search - Members - Calendar
Full Version: External drive and EAC - any disadvantages?
Hydrogenaudio Forums > CD-R and Audio Hardware > CD Hardware/Software
exec
Hi!

I just thought about archiving my CD collection with EAC and FLAC. Most important thing: quality.

So I took a look on my PCs/notebooks: which of these would do the best job/which drive I should use. First, I think that the drives in a notebook perhaps aren't that accurate. The DVD-ROM in my PC is pretty old and I think it got a slight glitch over the years (btw it's a Toshiba SD-M1612).

The idea to buy a good drive for ripping (e.g. PX-230A) and to assemble it in an external (USB 2.0) case got on my mind. So I also can rip with my notebook and I'm not bound to my PC.


Now the question(s): are there any disadvantages when doing so, especially things which would result in a less quality?
And how this might work from a technical point of view? EAC uses an ASPI interface to communicate with the drive, what happens when the drive is connected via USB? Isn't there some kind of "intermediate interface" to control the USB-stuff?


Any advice would be much appreciated!
Fandango
There should be no problems. But be sure to buy a "Hi-Speed" USB adapter, it's the only USB transfer mode that provides reasonable bandwidth of 480MBit/s (60MByte/s) which should be more than enough. However the real maximum transfer rate also depends on the USB<->IDE controller chip and on your motherboard's USB host adapter. For example I can't get more than 18MByte/s (I think!) with my adapter, but that's still enough for CD and even most DVD speeds. (52x CD-ROM 52x is ~7.8 MByte/s)

Anyway I wouldn't worry unless you don't have a Hi-Speed USB2IDE-adapter and/or notebook. Because USB Full-Speed is only 1.5MByte/s max. I think there are products out there that say they are "USB 2.0" but they don't support USB 2.0's new Hi-Speed mode, so beware! What you need to look out for is the Hi-Speed logo.

I'm using an USB adapter myself so I can easily connect various optical drives I used to keep and use them on heavily scratched discs, in order to recover more damaged sectors. And so far the USB adapter never made any difficulties, a conntected drive can be accessed via ASPI and is recognised by EAC just like a real IDE drive.
UrbanVoyeur
QUOTE(exec @ Feb 11 2007, 15:47) *
The idea to buy a good drive for ripping (e.g. PX-230A) and to assemble it in an external (USB 2.0) case got on my mind. So I also can rip with my notebook and I'm not bound to my PC.

Now the question(s): are there any disadvantages when doing so, especially things which would result in a less quality?
And how this might work from a technical point of view? EAC uses an ASPI interface to communicate with the drive, what happens when the drive is connected via USB? Isn't there some kind of "intermediate interface" to control the USB-stuff?


As long as you use USB 2.0 it should work fine. You will need to put the "wnaspi32.dll" from Nero ( I think?) in your EAC folder so it can see the USB drive.

I did hundreds of rips with on 2 PC's with 4 different, older, Toshiba CD & DVD drives and Okgear enclosures from NewEgg. All secure, with AccurateRip. No problems whatsoever. The motherboard USB 2.0 worked fine.

I don't want to dissuade you from a Plextor, but lately people here have complained about quality control and the fact that the recent models seemed to be a re branded model from a cheaper manufacturer. Samsungs are less expensive and worked just fine for me as did the Toshiba's. But I have no direct comparisons to the Plextors.
exec
QUOTE(UrbanVoyeur @ Feb 11 2007, 23:20) *

I don't want to dissuade you from a Plextor, but lately people here have complained about quality control and the fact that the recent models seemed to be a re branded model from a cheaper manufacturer. Samsungs are less expensive and worked just fine for me as did the Toshiba's. But I have no direct comparisons to the Plextors.


Yes, I just read about that. And I ask myself if there is something like the _best_ drive for ripping CDs. I mean, as long as EAC can handle the drive, you use secure options (secure mode: accurate stream on, caching on, C2 off) and you don't get errors while ripping, everything seems to be ok. Won't the results of the ripping process be the same then, no matter what drive you use? Ok, perhaps it will take a longer time on some drives, but that's all, ain't it?
bhoar
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.

-brendan
Fandango
QUOTE(bhoar @ Feb 12 2007, 01: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.

ROFL, yeah right. dry.gif
Honestly, what you're saying sounds like FUD in favor of Firewire to me!

Can you actually proof that what you say is possible? I can't believe that some USB chipsets monitor what's actually transported over the bus and hand pick certain data packets that include error codes and rewrite them so the software believes there was no read error.
UrbanVoyeur
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.

The heavily scratched discs were more problematic. Some ripped well only in burst mode.

But on all discs, the log files were identical - read and sync errors where they occurred, happened in the same places in both USB and IDE.

This may not be enough to put this issue to rest, but I can say that all 4 external drives worked perfectly and produced rips which were identical to internal IDE's.

Also note: Ripping was no slower (or faster) on the USB drives. I could rip full speed on the USB if I wanted to, but since tended to slow the drives way down to (hopefully) lead to more reliable rips on problem discs.

Edit: I was also able to fully enable AccurateRip on all the USB drives, which meant they were reporting the same checksums on key discs.
Martin H
QUOTE(exec @ Feb 12 2007, 00:03) *

And I ask myself if there is something like the _best_ drive for ripping CDs. I mean, as long as EAC can handle the drive, you use secure options (secure mode: accurate stream on, caching on, C2 off) and you don't get errors while ripping, everything seems to be ok. Won't the results of the ripping process be the same then, no matter what drive you use? Ok, perhaps it will take a longer time on some drives, but that's all, ain't it?

Yes, if you use a correctly configured secure ripping mode and get a confirmation from the app at the end of the rip about the rip was fine, then it dosen't matter what drive you use or if it's cheap or expensive, but the advantages that drives with good error correction capabilities have over drives with bad error correction capabilities, is among the bad discs, where you maybe can't get a rip that reports that the rip is fine with the bad drive, but with the better drive you can, or they maybe both report errors in the rip, but the bad drive actually sounds bad also, but the better drive then maybe sounds perfect.

Edit: When i say "a correctly configured secure ripping mode", then i of course mean that e.g. C2 pointers only is to be enabled if the drive a) supports it and b) has that feature correctly implemented(delivers accurate results with a high degree of percentige, like e.g. 99.9%).
bhoar
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
UrbanVoyeur
QUOTE(bhoar @ Feb 12 2007, 08:59) *
The above tests were with a single brand of enclosure, yes?


Yes. Four Okgear 5.25 Silver USB 2.0 enclosures purchased 4-6 months ago from NewEgg. Stock cables. The only mod was to remove the fan - unneeded noise.

During hundreds of rips, there were no occasions where the USB drive unexpectedly disappeared or became unresponsive. However, bad disks sometimes caused EAC to become unresponsive with both IDE and USB. The solution was hit the eject button until EAC responded.

Even when I accidentally unplugged the power or the USB cable in the middle of a rip, plugging it back in brought the drive back up immediately without re-boot. I sometimes, but not always, had to restart EAC.

I have no experience with these drives and firewire, but every indication is that they performed well with USB in my case.

I have no complaints about the enclosures, USB or the drives. They even look nice. smile.gif
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2008 Invision Power Services, Inc.