I've got two drives on my computer--wonder if it's a bad idea to rip with both at the same time?

I just tried it, and both CDs ripped without errors, so quality-wise it's not a problem (it seems). I just wonder whether it actually gets the job done any faster? Seeing as the two drives are both on one IDE channel, and there's only so much CPU time available and all...

I've done this....same config, two drives on the same IDE channel (both UDMA 33). I never really had any problems with this in secure mode, but as for faster ripping (burst mode) I'm not sure of the effect on the hard disk, which really sounds as though it's trying to "keep up" while ripping w/ two drives simultaneously (since both of my drives hit 40x DAE in burst-mode). I just play it safe and do 1 CD at a time, since I'm not all about speed anyway. If you have Windows XP or 2000, I think you can go into the system manager and see how much cpu load this causes.....I would venture to guess that it's a lot.

If I start a second EAC session, it seems to slow down the first one considerably (I have a DVD and a CD-RW on the same channel). I'm running Windows XP, and all IDE channels are UDMA.

My old computer had four IDE channels, so every drive could have its own channel. The drives didn't slow down under that configuration (iirc), but back then I didn't have enough processing power to encode that much audio. You just can't win

If you do the math, and two drives are going at ~6x ripping speed (or whatever), that's only 2MB/s transferring to the hard drive, which for any modern HD is a breeze. The only possible problem would be increased data fragmentation, but I don't know enough about how the software writes to the HD to speculate how much of an issue that is. But if the stopwatch says it's faster, go for dual-drive ripping, I say.

Well, in my case it turns out I can't win because one of my drives is so old and creaky, it starts spewing errors after ripping one or two CDs in succession, even with CDs in perfect condition. So I guess it's one drive only for me too

SometimesWarrior, I think that EAC should completely slow down the extraction in another EAC session at least at startup, because it will try to read the CD TOC. The two sessions asking the reading of a different part of the same CD, the drive will chatter for a little while.
To avoid this open the two sessions before starting ripping.

I have a dual 933MHz PIII here w/ 2 drives. I'll see if W2k puts each instance of EAC on each processor. May have some interesting results.

Xenno

As far as I can see here the CPU is not the bottleneck... not even 50% utilization even with 2 drives ripping.

In theory, EAC crashes on dual processor systems if your don't force it on the first CPU only.

Pio,

>>In theory, EAC crashes on dual processor systems if your don't force it on the first CPU only.

I'll check that.

Xenno

I meant the extraction speeds for both drives slow down once the drives are ripping CD's, not just when the second EAC instance is starting up. My whole system slows down when EAC reads the TOC's for my drives

Example: one rips at 4.0x, one at 5.0x when they are standalone. When they are both ripping, one goes to 3.0x and the other to 2.5x. Cancelling one ripping job speeds up the other. It's most likely due to both drives being on the same IDE channel.


I've never had that problem on my system, running 0.9pb11 or 0.9b4. Running XP, I can force one EAC to operate only on Proc#0 and the other only on Proc#1, and no problems occur (although I usually just let WinXP automatically figure out the division of work).

>>It's most likely due to both drives being on the same IDE channel

For sure, brother. IDE doesn't multitask well because it sure isn't maxing out the channel's capacity (ie ATA66, 100, 133). SCSI & it's serial variant FireWire are much better at this. It would be interesting to see what kind of results you get moving one of the drives to the 2nd IDE channel.

Xenno