Hi folks,
I just published the 3rd preview release of fre:ac with my SuperFast multi-threading technology. You can download it from GitHub (https://github.com/enzo1982/superfast#superfast-codecs).
This release adds support for multi-threaded LAME MP3 encoding. It scales very well with the number of CPU cores and can achieve a 3.5x speed-up on a quad core CPU. On my i7-6900K, I was able to measure up to 12x speed-up when running with all 16 threads (in most scenarios, however, either decoding or HDD/SSD speed will be a bottleneck before going to such speeds).
Two key points distinguish SuperFast LAME from previous attempts to build multi-threaded MP3 encoders:
- It keeps the bit-reservoir enabled in order to achieve the same quality as the original encoder.
- It uses an unmodified LAME encoder library, so the encoder can be swapped out for your own version.
Making it work while keeping the bit-reservoir enabled was actually the greatest challenge. Here is a technical article on how this is implemented: SuperFast LAME technical details (https://freac.org/developer-blog-mainmenu-9/14-freac/287-superfastlame)
I plan to implement this technology on top of the command line LAME frontend in the future. For now, my priority is on releasing fre:ac 1.1 beta and final versions, though.
Thanks in advance for trying the preview and posting your results and opinions!
Bravo! I shall try this out in the upcoming weeks and let you know of the results.
This topic didn't get much attention, and the Github repository was archived on December 11, 2020. Why,
@enzo?
As far as I understand, MP3 format, due to its design (the notorious reservoir of bits), does not favor multicore encoding, but you, describing the technical details (https://freac.org/developer-blog-mainmenu-9/14-freac/287-superfastlame), stated that it was possible without loss of quality. I encoded two WAV PCM files (44.1 kHz 16 bit stereo and 11025 Hz 16 bit mono) using SuperLame as follows:
freaccmd.exe in.wav -e superlame.
The latter one failed.