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.