Firstly on my old XP desktop it is burning at a speed of about 3 times - this seems a bit slow?
This won't help you, but might put things in some perspective :
Sidenote : when you see EAC at each next track looking for 5-10 secs to the beginning of the track, you must calibrate your drive. Also note that the 10 secs this scanning for the track might take, is much on 20 secs the rip takes. So this is one good reason why it can take long.
Then, to my findings, all further settings you change for the better of speed, must be wrong (!!). I mean, all would incur for less accurate reading, less rechecking, or whatever it it is that may make the result worse. This IOW : don't try to change settings for better speed. You'll loose on that in the end by (my) guarantee.
Another sidenote :
I have written a couple of "glitch detection" programs, just because now *I* spent a weekend at ripping with poor result. This program tells me what's wrong and where, anticipating on what I see in the files itself (as you know Chris, I dive into the files when my ears tell me something is wrong ... which usually happens when some of you come up with great sounding tracks ... hehe). So ...
So I can measure (afterwards) what EAC was actually doing and can compare it with what it told me.
First of all, the track quality as presented by EAC says nothing. Oh, maybe it does, but what it is must be known by the author only.
DO NOT listen to whatever is shouted around this on the net, because everybody copies words from others, and nobody knows it really. I can at least tell *that* because I can see what it does or does not tell ... just nothing with logic sense.
When the quality is presented as 98% my program may see nothing. Mind you, this says nothing again, because my program looks for some specifics only.
When the quality is presented as 100%, 100% sure this does not tell that the copy was good. I can show you, or you can look for yourselves when I built the program in XX (which I will).
I have the examples, emerged by pure accident, that a track can be full of glitches without EAC knowing it, or ever trying to reread or whatever it takes normally to detect and recheck for errors read. Looking at the data, I'm talking about 1000ths of subsequent samples, containing the same data (a glitch), again, EAC never having seen that. The scary thing is : *this* is an example which is audible (these glitches last a tenth of a second or so), but I can also show you over 1000 detected separate glitches which are not audible (oh they must be, but I don't notice it).
I can show you files with waayyyy too less resolution, which is similar to glitching, but then consistently. So, repeating a sample 10 times before the "voltage" is switched to the next.
Actually ... when I look at a file for whatever reason, there is always something going on. I would even be as ignorant that EAC s*cks so much, that it's time for a better one ...
Btw, do note I'm talking about anomalies you can get rid of. So, rip'm again, and the problem has gone. Or is somewhere else now.
All together you might take this for the next coming future :
There is so unbelieveably much wrong with this digital sh*t, that at least I don't know where it all ends and will lead to. There can be so much wrong without absolute notice, that I'm sure we all don't know what we are actually listening to.
Okay, back to the topic : Chris, my good old ripping drive wasn't faster either. My poorly (!!) rippers are faster, without reason. The one I use now (a 52x reader) also reads about 2-3 x. But it reads good ! So at least I actually don't know what is achieveable together with good reading.
And for those who obtain a clearly higher speed ... better watch it closely.
Peter