(OOPS... I accidently removed the message. [I clicked too fast and wasn't paying attention.] Here it is, now out of order in the thread... sorry.)If you rip and encode simultaneously, depending on how slow the encoder is, you can effectively eliminate the "rip" time from the overall time.
In other words, while the encoder is busy doing its thing on one frame, MC is buffering up the next frame.
If you don't do it at the same time, then the total time is the time to rip (create the WAVE file) and the time to encode (convert WAVE to whatever).
Put mathematically,
Let X = time to rip,
Let Y = time to encode, and
Let Y >= X, then
If done separately, Time = X + Y,
If done in parallel, Time = Y.
Also, for the purists out there, this would only be strictly true if MC were running on a dual processor machine, and it intelligently allocated the tasks to both processors. But even on a uniprocessor setup, very little actual CPU time is needed to physically read a CD.
Admittedly, this is just an educated guess as to purpose of the option. I have never actually benchmarked it, so don't flame me if Matt comes along and tells you I'm an idiot.
(
Update #1[/color]) Also, the reverse wouldn't be true. If it took longer to rip than encode (say you have an old, old CD-Rom drive), then doing them in parallel would take longer since the encoder would be spinning idle most of the time.
This is probably why they provide it as an option rather than forcing the choice on the user.(
Update #2[/color]) Theoretically speaking, my update #1 is flawed logically in that no time penalty would be incurred even if ripping was slower:
Let X = time to rip,
Let Y = time to encode, and
Let
X >= Y, then
If done separately, Time = X + Y,
If done in parallel, Time =
X.
Omni