JohnT:
I will try explaining in detail:
I have two drives (D, H). And I am currently running two instances of EAC. Each of it is assigned to a specific drive. Both EACs-instances rip the CD with digital secure ripping and when a track is finished, it is send to a "sub-instance lame". So if a track is finished ripping, the lame process gets going without interrupting the rip of the next song. I assigned EAC a maximum of 2 simultanious lame-instances in one session (this is a custom limit, it might be many more, if Intel would produce more powerfull CPUs), so there are at the max 4 lame processes and 2 EACs-instances running.
And yes, you are right: The ripping goes to a wave file and this one is processed by the next "free" lame-instance _of one EAC-process_. So if the first EAC process has a lame-instance "doing nothing", it can encode the next wave _from this EAC-session only_ (which I personally don't like -> MJs chance!).
MJ could be improved, if it supports ripping from more than one source and sending the ripped waves to lame-processes which run parallel to the normal work. MJ might be notified, if a lame process finished work (think about it as a subtask and remember the tasknumber windows assigns) and can automatically include the encoded file into the library (and tag it, including track#).
The speed improvement is quite a bit, if you have a powerfull CPU and some good space on your harddisc. I usually throw in the CDs to rip as fast as I could and the lame-instances run for many hours after this (without me sitting in front of the machine). After they finished, I usually import the encoded (and tagged, because EAC does this quite good during ripping (after encoding)) files into the MJ database and analyze them and move them to where they belong.
HTH,
Mirko