Ok, to clarify, this would NOT make LAME use multiple cores simultaneously for encoding a single file. And neither would musicbee need to be multithreaded.
The title of the topic is currently "Multithreaded encoding". I think a better term for it would be "Encoding multiple files at once". (and I may change the topic title so it's less confusing)
This suggestion is to start multiple instances of LAME.exe, each encoding a different file.
For example, if you have four cores, you could have four LAME.exe's running at once:
Lame.exe #1: encoding file A, mainly on core 1
Lame.exe #2: encoding file B, mainly on core 2
Lame.exe #3: encoding file C, mainly on core 3
Lame.exe #4: encoding file D, mainly on core 4
Note that none of these individual instances are multi-threaded (i.e. they each still only use one thread), but the operating system automatically assigns cores to a process based on need, so they will all run on different cores naturally.
Lets say file C is short and finishes faster than the others and exits. Musicbee would automatically start another instance of Lame.exe that encodes file E, and then it would copy file C to wherever it needs to go. And so on and so forth until they're all encoded.
All other things aside, this would make encoding at least [YourNumberOfCores] times faster than it currently encodes. But even if you only have one core, the separation of starting LAME on the encoding process from the copying of the file to the device would still make it faster.