SuperLAME 1.1.0

SuperLAME 1.1.0

Multithreaded encoding is 1.8–1.9x faster at every thread count, a new
--bench mode gives honest, LAME-comparable timing numbers, and a
fuzzer-found FLAC robustness hole is closed. Frontend-only changes — the four
engine libraries (znver5/znver4/znver3/SSE2) are identical to the v1.0.1
build, and encoded output is byte-identical to v1.0.3 in every
configuration.

Faster multithreading (condition-variable handoffs)

Every dispatcher↔worker handoff used to wait in a 1 ms sleep-poll loop; on
Windows that sleep rounds up to the ~15.6 ms scheduler tick, taxing each of
the thousands of chunk handoffs. All six polling loops are now
condition-variable event waits (microsecond wakeups). Measured on a Ryzen 7
5800X3D encoding a 44-minute album at CBR 320:

Threads	v1.0.3	v1.1.0	Speedup
2	24.3 s	13.8 s	1.76x
4	12.8 s	7.1 s	1.80x
8	9.8 s	5.1 s	1.93x
16	7.2 s	3.9 s	1.87x

New: --bench[=N]

Encode fully in RAM, write nothing (give an output file anyway to keep the
result), and get numbers you can actually compare:

bench: stages  read=0.30s  resample=0.00s  encode=4.20s  total=4.50s
bench: frames=100920 wall=4.20 cpu=38.30 play/wall=628x play/cpu=68.8x kbps=320 threads=16 engine=znver3 par-eff=9.1x/16t (57%)

• play/wall — honest multithreaded throughput
• play/cpu — per-core figure, directly comparable to stock LAME's "x"
• par-eff — parallel efficiency (cpu/wall vs thread count)
• --bench=N repeats the encode on the in-RAM audio and reports wall
  min/median/mean (run 1 is warmup, discarded)
• Works from a pipe; read time is labeled n/a (pipe) because that stage
  would measure the upstream producer (e.g. FFmpeg), not the encoder

FLAC input hardening

A corrupt STREAMINFO header claiming billions of samples could demand a
multi-gigabyte allocation from a kilobyte-sized file (found by fuzzing; the
process thrashed instead of erroring — present in all prior releases).
Sample counts implausible for the file size (>512x — real FLAC maxes out
near ~420 samples/byte on pure silence) are now treated as unknown length
and decoded by the streaming path, which sizes buffers by what actually
decodes. Input fuzzer: 920/920 clean.

Docs

docs/FFMPEG-NOTES.md collects verified FFmpeg interop quirks. The one that
will bite you: ffmpeg ... -f wav - silently downconverts 24-bit/float
sources to 16-bit unless you pin -c:a pcm_s24le / -c:a pcm_f32le.

Validation

• Regression suite 42/42 (35 existing + 7 new --bench checks)
• SQAM: 350 encodes (70 tracks x 5 modes), 0 desyncs
• ODAQ: 132 encodes, worst ST-vs-MT diff −59.2 dB, FLAC==WAV input
• Input fuzzer: 920 malformed/truncated/random files, 0 crashes/hangs
• FFmpeg interop: pipe==file byte-identity across 16/24-bit, float, mono,
  hi-res resample, stdout chains and 3-stage round trips

SHA-256 (SuperLAME-1.1.0.exe):
20bcbbaa9b96b7d135ba04460c62755d140484310c85db23993638035891b8b3

SuperLAME 1.0.3 — stdout/piping fixes and honest CPU reporting

SuperLAME 1.0.3 — stdout/piping fixes and honest CPU reporting

A piping audit prompted by user reports. If you pipe SuperLAME — encode to
stdout, decode from stdin, or script it — you should update. Encoding
results are unchanged; frontend-only fixes, the four engine libraries are
untouched.

Fixed

• Encoding to stdout was completely silent. superlame -b 320 in.wav - > out.mp3 showed no banner, progress or summary. All run-time status output
  now goes to stderr (stock LAME's convention), so it stays visible and
  can never contaminate the piped MP3. Requested help/info commands
  (--help, --version, …) stay on stdout; the missing-argument error path
  prints usage to stderr.

• --decode from a piped stdin silently truncated the output.
  type in.mp3 | superlame --decode - out.wav wrote a fragment (~one frame)
  and exited 0. The reader sized its buffer by seeking — and on a Windows
  pipe that seek can appear to succeed with a bogus size. Stdin is now
  always read to EOF (audio input, --decode input, and --ti album art,
  which now also works from a pipe).

• The engine banner now identifies your CPU. Instead of the static
  znver4 (AVX-512, unverified) label, --version prints a cpu : line and
  verbose encodes print Engine: … CPU: … — e.g. AMD Zen 4 (family 0x19, AVX-512) or Intel (AVX-512). --longhelp now states the real mapping:
  Zen 5 → znver5, Zen 4 and other AVX-512 CPUs → znver4, Zen 1-3 / any
  AVX2+FMA+BMI2 → znver3, otherwise SSE2. (Engine selection was already
  correct; what was reported is fixed.)

• AVX-512 usability is now verified through XCR0 (xgetbv). Previously
  the CPUID feature bits were trusted with only an OSXSAVE check; under a
  hypervisor/OS that exposes the bits without saving ZMM state the AVX-512
  engines could fault. The probe now requires the YMM (0x06) and
  opmask+ZMM (0xE0) state bits.

Insights

• Because SuperLAME assembles the entire MP3 in memory before writing, the
  Xing/Info tag in piped output is complete (frame count, TOC, CRC) —
  something stock LAME cannot do on an unseekable stdout. Piped output is
  byte-identical to file output.
• Pipes and parallelism are fully independent here: stdin is read to EOF
  first, then the multithreaded FLAC decode, parallel r8brain resample and
  SuperFast chunk-split all run on in-memory buffers. Verified: a piped
  96 kHz/24-bit encode at -t16 is byte-identical to its file-mode encode.
• The flip side: output bytes appear only after the encode finishes, so
  SuperLAME is not suited to live/realtime streaming pipes.
• Windows note: legacy PowerShell 5.x corrupts binary > redirection of
  stdout. Use PowerShell 7+, cmd.exe, or a real output filename (see
  --longhelp, STDIN/STDOUT section).

Verified

• Regression suite: 35/35 pass
• Full pipe matrix byte-identical to file equivalents: WAV/AIFF/FLAC piped
  in, MP3 to stdout, decode from pipe/redirect/file, two-process
  encode→decode chain, piped hi-res through the parallel resampler
  (-t1/-t16), piped album art
• --quiet behavior unchanged

See CHANGELOG.md
for the full technical write-up.

Download

SuperLAME-1.0.3-win64.zip — the binary plus all license texts and source
pointer (GPL-complete). CPU engines (znver5 / znver4 / znver3 / SSE2) selected
at runtime; Intel CPUs supported. Built with clang/LLVM 21.

SHA-256 (SuperLAME-1.0.3.exe):
6e2cd75cd51ece54d9ab89da21d89b96579018d6a4a2dc5bddbd801cd119e9ec

Provided as-is, with NO WARRANTY (GPL §11–12). GPL v2 or later.

SuperLAME 1.0.2

SuperLAME 1.0.2 — bug-fix release

Three bugs found in a source audit are fixed — a crash, a silent resampling
quality fault, and a wrong sample-rate decision for mono files. If you
multithread-encode very short clips, use --resample across clock families
(44.1 kHz ↔ 48 kHz), use low CBR/ABR bitrates, or encode mono material, you
should update.

Fixed

• Multithreaded encoding of very short inputs crashed. An input holding
  fewer full MP3 frames than the chunk overlap (under ~0.1 s at 44.1 kHz, up
  to ~0.18 s at 22.05/24 kHz) corrupted the heap and crashed with -t ≥ 2.
  Such inputs now take a single-worker path; their output decodes to PCM
  bit-identical with a single-thread encode. Single-thread was never affected.

• The parallel resampler misaligned its chunk seams at non-integer rate
  ratios. Conversions like 44.1 kHz → 48 kHz (--resample 48) or the
  low-bitrate auto-downsamples to 32/24/16/12/8 kHz left every chunk shifted
  by a sub-sample offset — an error up to −13 dBFS below the signal, with a
  discontinuity at every seam. Clean integer conversions (88.2 → 44.1,
  96 → 48, 176.4 → 44.1, DXD) were always exact and are unchanged. After the
  fix all ratios measure at the double-precision floor (−297 dBFS vs the
  reference).

• Mono files got the stereo auto-downsample decision. At e.g. CBR 96 a
  mono file was needlessly cut to 32 kHz; LAME keeps mono at 44.1 kHz at that
  bitrate (mono has twice the per-channel bit budget). The rate decision now
  sees the true channel count and matches stock LAME for both mono and stereo.

Also hardened in this release: encoder teardown no longer aborts on
out-of-memory before printing its error; --decode reports disk-full write
failures and refuses >4 GB WAV output instead of writing a wrapped header;
inputs beyond 2³¹ samples are refused with a clear message; small-frame
Xing/Info tag patching stays in bounds.

See CHANGELOG.md
for the full technical write-up.

Verified

• Regression suite extended 28 → 35 cases (tiny-input MT robustness,
  resample seam integrity vs an independent reference, channel-aware rate
  decision): 35/35 pass
• Byte-identical output on all unaffected paths (normal-length MT encodes,
  single-thread encodes, integer-family resamples)
• ST vs MT equivalence and znver3-vs-SSE2 engine parity unchanged

Download

SuperLAME-1.0.2-win64.zip — the binary plus all license texts and source
pointer (GPL-complete). CPU engines (znver5 / znver4 / znver3 / SSE2) selected
at runtime; Intel CPUs supported. Built with clang/LLVM 21.

SHA-256 (SuperLAME-1.0.2.exe):
0c87ddb5bfc7d02a51a224404fb112ebcfab7802c10165f8305e8fc36654fb21

Provided as-is, with NO WARRANTY (GPL §11–12). GPL v2 or later.

SuperLAME 1.0.1

SuperLAME 1.0.1 — bug-fix release

Two MP3 correctness bugs are fixed. Both showed up on a FLAC → MP3 encode that
played "off-time" and skipped in some players. If you use -V7/-V8/-V9, low
CBR/ABR bitrates, --resample, or embed cover art, you should update.

Fixed

• Multithreaded encoding dropped ~6.6% of the audio whenever the output sample
  rate differed from the input. This affected the high VBR levels (-V7/-V8/-V9
  auto-drop to 32/24/22.05 kHz) and low CBR/ABR bitrates — a track could come out
  seconds shorter than the source. Single-thread was never affected. The frontend
  now pre-resamples with r8brain to exactly the rate LAME would have chosen (for
  VBR as well as CBR/ABR), and each worker is pinned so LAME's internal resampler
  can never run mid-encode. ST and MT now produce identical length + audio.

• ID3v2.4 cover art (APIC) used a non-synchsafe frame size. A large embedded
  cover (e.g. a ~736 KB JPEG) produced a frame size that strict parsers reject —
  which could make the whole tag be dropped and the decoder desync into the image
  data. Frame sizes are now written synchsafe in v2.4.

See CHANGELOG.md
for the full technical write-up.

Verified

• -V7/-V8/-V9: ST vs MT decode to identical length and byte-identical audio
• APIC size now synchsafe; libmpg123 decodes tagged files cleanly at full length
• Regression 28/28, ODAQ objective PASS (worst ST-vs-MT −59 dB), FLAC
  conformance unchanged (0 crashes)

Download

SuperLAME-1.0.1-win64.zip — the binary plus all license texts and source
pointer (GPL-complete). CPU engines (znver5 / znver4 / znver3 / SSE2) selected at
runtime; Intel CPUs supported. Built with clang/LLVM 21.

SHA-256 (SuperLAME-1.0.1.exe):
c3f0b5aa598e8cd2cba2a1b600e203e291e517e94dd3afce5a888d48b6ab0b1e

Provided as-is, with NO WARRANTY (GPL §11–12). GPL v2 or later.

SuperLAME 1.0

SuperFast multithreaded LAME MP3 encoder — parallel libmp3lame instances + bit-reservoir repacker, roughly 8× faster than stock single-threaded LAME at the same quality.

Features

• Encoder: LAME 3.101 beta 3 (r6531) + maikmerten q4 fix; CBR / ABR / VBR
• SuperFast MT: parallel encode + bit-reservoir-correct repacker (self-healing fallback)
• CPU dispatch: one binary, four CPUID-selected engines — znver5 / znver4 (AVX-512) / znver3 (AVX2) / x86-64 (SSE2)
• Input: WAV, AIFF, and FLAC (multithreaded decode, up to 24-bit); full-precision float pipeline
• Decode: MP3 → WAV via libmpg123 (--decode)
• Resampling: r8brain (linear-phase, ~207 dB), parallelized
• Tags: ID3v1/v2 UTF-8, album art (--ti, JPEG/PNG); FLAC tags + cover auto-imported

Downloads

• SuperLAME-1.0-win64.zip — the Windows x64 binary + licenses + source pointer
• SuperLAME-1.0-source.zip — complete corresponding source (GPL v2+)

Verify

SuperLAME-1.0.exe (SHA-256)          d3530cb6be74deb38ad61bbd3a4d33014834c5fcb8d35352fee3d45f7a3ccf81
SuperLAME-1.0-win64.zip (SHA-256)    f3f7c6121107781f9854a8d14e871a237995b7ed2b60078998587312e687d7ab
SuperLAME-1.0-source.zip (SHA-256)   ca5e0148d2aefb1b649db84514957b7385d6904d2ec9f118dbee47dde7501cba

Licensing

GPL v2 or later (combines LAME/mpg123 LGPL, r8brain MIT, dr_flac PD/MIT-0, fre:ac/BoCA SuperFast GPL). License texts are in licenses/. MP3 patents expired (~2017) — no royalty applies. See THIRD-PARTY.md.

Built with clang/LLVM. Provided with NO WARRANTY.