I think that it would be much more convenient if thread count for the converter was selectable from the converter window. For example, when you convert some music to a slow external flash drive, it takes much less time when foobar2000 does it in just one thread. But when I convert from my SSD to SSD, it is faster when foobar2000 uses all the CPU cores. It would be nice to have an ability to control it without opening advanced settings.
The converting goes fastest if you always convert to proper device (HDD/SSD) and move from there to the slow flash target. But if you insist on converting there directly make a converter preset with encoder that has "Do not convert in multiple threads" checkbox ticked.
Oh, it seems that converting to a folder on an SSD and copying files from the folder to a flash drive is really much faster (maybe 5 times faster) than just single-threaded encoding to the flash drive. It would be nice if the converter was able to handle such cases automatically. As far as I understand the issue with low speed is caused by the reason that converter writes data using very small chunks of data. Probably, some buffering and writing bigger amounts of data at once will make it faster.
foobar2000 doesn't write files. The converter only sends data to an encoder (lame.exe, flac.exe, qaac.exe...) and the encoder itself writes data to a resulting file.
The method I suggested is faster for several reasons. Writes to non-removable devices are cached, encoding happens in multiple threads, and OS can use optimized writing since it knows the devices and file sizes.
And he is suggesting that foobar2000's converter automate the process of converting to a faster storage medium, then move the resulting file set to the destination. Sounds like a doable feature, maybe? Still needs a configuration option for where to store the converter output while operating, and what to do if the application crashes while conversion is happening. (Then it will also need to know what to do with partial or completely converted files in the configured directory on startup.)
Yeah, it would be very nice to automate it. It would be OK to use standard temp directory for this purpose.
Oh, it seems that converting to a folder on an SSD and copying files from the folder to a flash drive is really much faster (maybe 5 times faster) than just single-threaded encoding to the flash drive. It would be nice if the converter was able to handle such cases automatically.(...)
How could or should fb2k find out what the directory you are writing to likes best? One could argue that even for an old moving-head-harddisk parallel writes are suboptimal, but to me it always was surprisingly fast. Writing in small chunks to a flash medium will be inefficient. Maybe disable the optimization for fast device removal (but then you'll have to eject the drive before unplugging).
I think more choice in thread count would be nice, but not just when converting. I'm running a pair of hard drives as RAID-0 and an old CPU with only four cores, but often when running a ReplayGain scan on a bunch of files, the scanning speed drops to a quarter of the initial speed as scanning progresses, especially for large lossless files. If I'm sitting in front of the computer it can be faster to do them one at a time.
As you can't create an encoder preset for converting to wave, there's no way to limit the thread count to one, yet writing large wave files is an example of when it'd likely be the most handy. To work around that, I've created an encoder preset that uses ffmpeg to convert to wave, as then I can specify a single thread.
Edit: I just re-read the opening post. I didn't realise there was an option for setting the thread count under Preferences/Advanced/Tools/Converter. Is that somewhat new? I've set it to 2 now, so I'll see how that works out. Now if I could limit the ReplayGain scanner in a similar way.....
Converter: advanced-preferences option to encode to temp folder and move encoded-and-tagged files to the intended destination.
The feature is already implemented in the latest beta =) Thanks to the author of the fb2k.