I apologize if this has been discussed before, but a search didn't turn up anything. I recently did some ripping using 2 copies of EAC running simultaneously, ripping from 2 different internal IDE drives. I was a bit disappointed to see that my ripping speed per-drive was significantly lower when ripping 2 drives at once. For example, one drive can do secure rip at about 8x if running by itself, but drops to about 4x if the other drive is also ripping. My system should have enough horsepower: WinXP, Athlon XP 2500, NForce2 Mobo, 1GB RAM, Pioneer DVR-105, LiteOn 48125W. The CPU shows hardly any load during the rip process, only during encoding (LAME).

Is this normal for EAC? One potential issue I thought of is that both CD drives are on a single IDE channel. But with my existing case and cables, it is not practical for me to put the CD drives on separate channels. Even if I did, then one of them would then have to share a channel with the HD.

Thanks in advance for any comments or suggestions.

Sounds like an IDE channel issue. I noticed a slight increase in simultaneous secure ripping speed when the CD-ROM's were on separate channels. The magnitude of the effect may depend on the model of your CD-ROM & motherboard. Make sure all your firmware is up to date.

In my setup, the number of EAC instances by itself has had no effect -I've run up to 4. But to preserve individual ripping queues in case EAC crashes, you should have a separate folder for each instance of EAC.

It's probably not worth the hassle but you could get a 2 port IDE card and move one or both of the CD-ROMs to it. I would not rec moving your CD-ROM to the HD channel - it will slow the HD way down.

My understanding is that the highest performance solution for using multiple IDE optical drives is one good IDE<->Firewire bridge per drive. If the drives are (the much rarer) SATA variety, however, the best is probably direct connection. Not sure if you need to disable the BIOS compatibility mode, though.

Also, if you're compressing, you'll want to check to ensure that your CPU isn't being maxed out when performing parallel rips. That can slow you down too.

-brendan

I have a system with a 3.0 GHz P4 processor. with hyper-threading. One instance of EAC will use 50% of the CPU, 100% with two instances of EAC running. Running two is equally as fast as a single copy of EAC. The two drives are on different IDE channels.

If possible, replace your existing cables with longer cables or use the round style IDE cables. (Example)

Longer cables? Why?
I could be wrong, but I always thought shorter was better, especially with IDE.

Round? Again why? I can see where *shielded* round cables might have a small positive effect, but why would shape matter?

Also, my EAC's never take up 50% proc. The encoders instances - LAME, FLAC, etc, may take up to 50%, but each EAC rarely takes more than 20-25%.

Skuzzle-butt: My CPU is slower than yours and my CPU usage is way less than 50%. If one instance of EAC consumes 50% or your CPU, then perhaps something is wrong with your system config. If you go into Device Manager, open your IDE controller, does it show that your CD drives are using DMA?

After further testing, I have some more concrete numbers for my system (see below). It appears that I was mistaken in my original post where I said ripping speed was cut in half when using 2 concurrent drives.

Single EAC instance:
LiteOn 48125W:
- burst mode test = 26x, cpu ~ 15%
- burst mode copy with LAME encoding = 25x, cpu = 100% during encoding, else ~15%
- secure mode test = 7x, cpu ~ 5%
Pioneer DVR-105:
- burst mode test = 20x, cpu ~ 15%
- burst mode copy with LAME encoding = 20x, cpu = 100% during encoding, else ~15%
- secure mode test = 5.5x, cpu ~ 5%

Two instances of EAC ripping from both drives in parallel:
Burst mode test:
- LiteOn 48125W: 20.5x
- Pioneer DVR-105: 21x
- cpu ~ 25%
Secure mode test:
- LiteOn 48125W: 5.3x
- Pioneer DVR-105: 5.3x
- cpu ~ 5%

Test details:
When I say "test" above, I mean selecting all tracks, right clicking, and choosing "Test selected tracks". Since I don't have 2 identical CDs, I used 2 different test discs for the parallel ripping tests. Both have about 45min of music and 11 tracks, and both rip individually at about the same speed. One test disc has 2 tracks at 99.9% quality in secure mode (i.e. some error correction is being done). The other disc has one track at 99.9%. This slows the secure ripping down a little. All other tracks are at 100%. Device Manager confirms that both CD drives are on the secondary channel, using Ultra DMA 2 (Ultra33). I have the NForce IDE drivers installed for my NForce2-based motherboard. I'm running WinXP SP2, EAC 0.95 beta 4. My CPU is an Athlon XP (Barton) @ 1.7GHz, with 1GB dual-channel RAM.

Conclusions:
CPU is not a bottleneck, even with parallel ripping. The LiteOn drives sees a ~20% rip speed reduction during parallel rip, in both burst and secure modes. Coincidentally(?) it drops to about the same performance level as the Pioneer drive. The Pioneer does not show any significant speed reduction due to parallel ripping. Perhaps the reduction on the LiteOn is due to the drives sharing an IDE channel? The reduction is small enough that I can live with it.

The real performance killer seems to be secure mode, which is only giving about 25% of the speed of burst mode. I expected more like 50% for discs not requiring much error correction. I was also surprised to see that the tracks which triggered error correction in secure mode still produced the same CRC in burst mode, and were still confirmed by AccurateRip. I did the burst mode rips several times in both drives and got the same result. From my experience, I'm a little suspicious of the error correction done in secure mode. After ripping over 50 discs, almost every time I saw secure mode doing error correction, it was at the very end of a track. That seems like more than coincidence. It would light up the first row in the error correction box and then move on. I only recall one example where secure mode seemed to find an error and attempt more extensive error correction. That was just due to a dirty disc, and once the disc was cleaned it ripped smoothly. In the future, I may consider use burst mode for discs that are in the AccurateRip database, and fall back to secure mode if my results disagree with AccurateRip or when the disc is not in AccurateRip. Any thoughts on that approach?

Thanks!

Duplicate submission deleted, sorry bout that.

I think you're right on with that. Accuraterip is a great tool (for those who rip to individual tracks, anyway) and there's no reason not to use it in conjunction with burst mode the majority of the time, especially when one's CDs are in good condition.