WOW! thanks a lot 4wd for doing this! It is really appreciated!

-techidave
No problem

Someone else told me that a "modern CPU" would make a bigger difference than more RAM will.
One of the Core CPUs with
Quick Syncw plus a HandBrake version with Quick Sync capability would tear through the encodes, (or if they finish the OpenCL versions of HandBrake then you can use a cheap AMD GPU).
the part that I don't understand is how did you know what the different parameters will do??
Magic, my son, magic

Or if you don't believe that, how about: I use
VidCoder a lot, which is a more user friendly version of HandBrake - all the GUI interface options have a CLI equivalent. Plus the default encoding options for HandBrake/VidCoder are pretty good for 95% of the usage cases.
HandBrakeCLI GuideJust as a note, the only time I use two pass encoding is when I want to hit a specific filesize, eg. 350MB, normally the default CQ setting, (20), is more than adequate for this type of stuff.
My test source video is sufficiently close enough to what I get from my PAL MiniDV camcorder, (which sadly lies unloved under a bed), so you should see a similar speed increase there, (hardware notwithstanding).
I noticed with the SuperFast sample I put up, (I chose that section because of the fast action brush strokes and contrast between black/white plus a few colour daubs), that it is slightly brighter which causes a very
slight loss of detail, (due to wash out effect), that you can see in some of the fine brush strokes he does.
Depending on your needs this may be acceptable, if not can you post a short section of some of your source video, (a reasonably complex section - fast movement, contrast, etc), somewhere, PM me a link, and I'll have a play with the settings.
EDIT: Just noticed I must have been dyslexic when I was copying and pasting from the command files I used - fixed parameters above.