Solution 1:

The only thing you're encoding is audio, and most audio encoding libraries in existence are single-threaded. This is most likely because audio encoding is already blazing fast as a single-threaded application (when compared to video encoding anyway), and it doesn't use too much memory so it's actually feasible to encode each file using a single thread and just start up as many separate processes as necessary to fully saturate the CPU. Factor in the fact that multi-threading also doesn't necessarily result in linear performance improvements and you probably have the reason why the developers of most audio encoders don't think multi-threading is a high priority. I know only of two audio encoders that implement multi-threading - LAME MT for MP3 and pflac for FLAC - and both are separate modifications that aren't part of the main codebases of the projects they derived from.

As for your CPU usage, with hyper-threading you have 8 logical cores and one eight of 100% is 12.5% which isn't too far from your 15% utilisation figure. I'm not really sure why you system isn't showing a 100% load on any of the cores, perhaps the OS is moving the process between cores to even out the load or something like that.

If you need to encode a large number of files you might want to consider writing a script that spins up multiple FFmpeg processes to encode multiple files at the same time. I have very little scripting/programming experience but I know of an open source tool that applies the same logic for image optimisation: picopt. So if you need a pointer on how to do it in Python you could take a look at picopt's source code.