Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: SuperFast LAME multi-threaded MP3 encoder (Read 9767 times) previous topic - next topic
0 Members and 2 Guests are viewing this topic.

SuperFast LAME multi-threaded MP3 encoder

Hi folks,

I just published the 3rd preview release of fre:ac with my SuperFast multi-threading technology. You can download it from GitHub.

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

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!

Re: SuperFast LAME multi-threaded MP3 encoder

Reply #1 –
Interesting!

Re: SuperFast LAME multi-threaded MP3 encoder

Reply #2 –
Bravo! I shall try this out in the upcoming weeks and let you know of the results.

Re: SuperFast LAME multi-threaded MP3 encoder

Reply #3 –
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, 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.
• Join our efforts to make Helix MP3 encoder great again
• Opus complexity & qAAC dependence on Apple is an aberration from Vorbis & Musepack breakthroughs
• Let's pray that D. Bryant improve WavPack hybrid, C. Helmrich update FSLAC, M. van Beurden teach FLAC to handle non-audio data

Re: SuperFast LAME multi-threaded MP3 encoder

Reply #4 –
Quote from: Kraeved on
This topic didn't get much attention, and the Github repository was archived on December 11, 2020. Why, @enzo?
The SuperFast code was integrated into official fre:ac/BoCA releases and development continued there, so there was no need for a separate repository anymore. The SuperFast LAME code is here now.

Quote from: Kraeved on
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, 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.
There were some bugs fixed in the BoCA repo after the original repo had been archived. Current fre:ac seems to encode this file correctly.

Re: SuperFast LAME multi-threaded MP3 encoder

Reply #5 –
Quote from: enzo on
There were some bugs fixed in the BoCA repo after the original repo had been archived. Current fre:ac seems to encode this file correctly.

I tried freac-1.1.7-windows-x64.zip (2023-05-05) and the previous command did not work. Oh, you removed SuperLame from the list of encoders in favor of a dedicated flag --superfast. I applied it and witnessed some obscure warning. It would be nice to get a more detailed report on the encoding settings used.

Code: [Select]
$ freaccmd.exe history.wav -e superlame
Encoder 'superlame' is not supported by fre:ac!

$ freaccmd.exe
...
Encoder <id> can be one of:
        ffmpeg-alac, fdkaac, flac, lame, meh, mac, mpc, vorbis,
        ofr, opus, speex, tak, wv, wma, sndfile-wave, sndfile

$ freaccmd.exe history.wav -e lame --superfast
Warning: APIC ID are not supported, core count can be wrong if SMT is disabled and cache instances count will not be available.
Processing file: history.wav...done.

• Join our efforts to make Helix MP3 encoder great again
• Opus complexity & qAAC dependence on Apple is an aberration from Vorbis & Musepack breakthroughs
• Let's pray that D. Bryant improve WavPack hybrid, C. Helmrich update FSLAC, M. van Beurden teach FLAC to handle non-audio data