Windows x64 · version 1.0.1.0
Translate FFmpeg libmp3lame commands to native LAME
FFmpeg LAME Shim is a small compatibility executable for MP3-only workflows. It acts as an FFmpeg-to-LAME command-line wrapper: an application launches the supplied ffmpeg.exe and passes familiar libmp3lame options; the shim translates the supported arguments and launches the real lame.exe beside it.
The result is deliberately narrower than FFmpeg. The shim exists for cases where a host is FFmpeg-oriented but the job itself is simply PCM/WAV or FLAC to MP3 through LAME.
What the shim actually does
Host application
↓
ffmpeg.exe -i input.wav -c:a libmp3lame -q:a 2 output.mp3
↓
FFmpeg LAME Shim translates the supported options
↓
lame.exe -V2 input.wav output.mp3
↓
MP3
The shim does not contain FFmpeg's codecs, filters, demuxers or video pipeline. Its job is argument translation and process hand-off.
Stable bundle
FFmpeg LAME Shim 1.0.1.0 x64
The bundle contains the shim, the current enhanced LAME 4.0 executable, optional FLAC runtime support and an example LAME configuration file.
Package
ffmpeg-lame-shim-1.0.1.0-x64-bundle.zip
Size
701.98 KB
Architecture
Windows x64 only
Bundle contents: ffmpeg.exe, lame.exe, libFLAC.dll, lame.ini.example and README.txt.
SHA-256: 2b1a67ae4d707cc7117f4dd7d694073501ed0447a0d31e1d70fcbf02c7c53c9c
Why use an FFmpeg-to-LAME shim?
FFmpeg-first applications
Some applications make FFmpeg the obvious external-encoder path, expose an ffmpeg.exe location, or generate FFmpeg-style MP3 commands even when the final codec is libmp3lame.
Native LAME extensions
The real lame.exe can apply its own lame.ini defaults after translation. This allows settings such as constrained VBR/cVBRb to be enabled even if the host only exposes standard FFmpeg controls.
Existing automation
Audio-only scripts and legacy integrations may already be written around ffmpeg.exe -c:a libmp3lame. The shim can preserve that command shape while moving MP3 encoding to native LAME.
Small MP3-only deployment
If a workflow genuinely needs only LAME MP3 encoding, a focused compatibility layer can be simpler than deploying a full FFmpeg distribution solely to reach libmp3lame.
Example workflow
Audacity and FFmpeg-shaped export workflows
Audacity provides an External Program export path that can launch a command-line encoder. Recent versions also use FFmpeg elsewhere in the import/export workflow. Audacity's own manual documents both lame and ffmpeg as external-program examples, so native LAME is not technically blocked.
The shim becomes relevant when an existing Audacity command, preset or surrounding workflow is already written in FFmpeg syntax and you want the final MP3 encoding to pass through the supplied native lame.exe. The same arrangement can also allow lame.ini to add LAME-specific defaults that are not represented by the FFmpeg-style options being passed.
ffmpeg.exe -i - -c:a libmp3lame -q:a 2 "%f"
For normal MP3 export, modern Audacity already includes LAME functionality and does not need this shim. The purpose here is compatibility with a specific FFmpeg-shaped external-command workflow, not replacing Audacity's built-in encoder.
Reference: Audacity Manual — Exporting using an external encoder program.
Applications and workflow patterns
The shim applies where a host calls ffmpeg.exe only for a narrow WAV/PCM-to-MP3 step. The examples below are based on published command lines.
Some of these applications use the same FFmpeg installation for AAC, Opus, ALAC, video processing or remuxing. The shim only covers the MP3/LAME subset. Where possible, point only the MP3 encoder profile at the shim or keep it in a dedicated folder; do not replace a full FFmpeg installation that other functions depend on.
x264guiEx / NVEnc-style external MP3 definition
The published configuration used by rigaya's tools is especially relevant because it explicitly names ffmpeg.exe, probes -h and -version, and defines an MP3 encoder around libmp3lame:
ffmpeg.exe -f wav -ignore_length 1 -i input.wav -y \
-c:a libmp3lame -vn -b:a 256000 output.mp3
For this pattern the shim treats the input-side -f wav and -ignore_length 1 as compatibility hints, translates the MP3 bitrate request and hands the WAV stream/file to native LAME.
References: x264guiEx encoder definitions and NVEnc encoder definitions.
AnimeWwise
AnimeWwise provides another concrete example: its MP3 conversion stage calls a bundled ffmpeg.exe with -acodec libmp3lame -b:a 192k. That command shape is already within the shim's supported subset when the input reaching this stage is WAV.
Reference: AnimeWwise extract.py.
Compatibility by workflow
The key question is not “does the application use FFmpeg?” but “what does it expect FFmpeg to do?”
Supported FFmpeg/libmp3lame mappings
The shim implements the MP3 controls most likely to be generated by a host application.
Common compatibility/no-op options including -y, -n, -vn, -sn, -dn, -hide_banner, -nostdin, -stats, -threads, -map, -map_metadata and -loglevel are accepted where appropriate. The explicit output format -f mp3 is accepted, while input-side -f wav and -ignore_length 1 are accepted for compatibility with WAV-pipe/file workflows.
FFmpeg itself documents the corresponding libmp3lame options and their LAME equivalents. See FFmpeg libmp3lame documentation.
Command examples
V0 VBR
ffmpeg.exe -i input.wav -c:a libmp3lame -q:a 0 output.mp3
Translated to the equivalent native LAME request:
lame.exe -V0 input.wav output.mp3
192 kbps ABR
ffmpeg.exe -i input.wav -c:a libmp3lame -abr 1 -b:a 192k output.mp3
lame.exe --abr 192 input.wav output.mp3
FLAC to MP3
ffmpeg.exe -i input.flac -c:a libmp3lame -q:a 2 output.mp3
lame.exe -V2 input.flac output.mp3
The shim does not decode FLAC; the bundled enhanced lame.exe loads libFLAC.dll when required.
Using lame.ini behind an FFmpeg-only interface
This is one supported use of the shim. The shim itself has no INI file. After it translates the host's FFmpeg options, the real LAME executable can apply its own optional lame.ini defaults.
[LAME]
Enabled=1
Arguments=-b 192 --vbr-min-strict --bitrate-boost=2
A host can continue to send a standard command such as:
ffmpeg.exe -i input.wav -c:a libmp3lame -q:a 0 output.mp3
while the bundled LAME build adds the native constrained-VBR settings. Explicit command-line options remain authoritative over conflicting INI defaults.
Validation
The 1.0.1.0 release was tested with V0/V2 VBR, 320 kbps CBR, 192 kbps ABR, algorithm-quality translation, mono conversion, 48 kHz resampling, FLAC input, lame.ini cVBRb settings, basic FFmpeg probe responses and error-code propagation.
For a direct equivalence check, the same V2 encode was run once through the shim and once through lame.exe -V2. The resulting MP3 files produced the same SHA-256 hash, confirming that the translated request reached the same native LAME encode path.
What not to use it for
Do not substitute this shim for FFmpeg when the application needs FFmpeg to decode or demux arbitrary media, inspect media with ffprobe, run filters, extract audio from video, perform trimming/mixing, write non-MP3 codecs, or provide the FFmpeg/libav DLL API.
If the host requires those functions, use a real FFmpeg build. See the FFmpeg + LAME guide for the normal FFmpeg/libmp3lame route.
Quick questions
Is this actually FFmpeg?
No. The executable is deliberately named ffmpeg.exe for compatibility, but it is CW-FFLAME/FFmpeg LAME Shim and implements only a focused MP3 translation layer.
Does it replace libmp3lame?
No. It translates FFmpeg-style options and launches the bundled native LAME executable.
Does it support Audacity?
It can be used with Audacity's External Program workflow when the command uses FFmpeg/libmp3lame syntax. Audacity can also invoke native LAME directly and modern Audacity already includes LAME for normal MP3 export.
What other applications may use it?
Examples include x264guiEx/NVEnc external MP3 profiles, MP3-only conversion stages such as AnimeWwise, and batch or automation scripts that call ffmpeg.exe only for libmp3lame. A full FFmpeg installation is still required for video, ffprobe, filters and other codecs.
Can it use cVBRb?
Yes through the bundled LAME build's optional lame.ini. The shim itself does not implement cVBRb.
Why is there no x86 build?
Version 1.0.1.0 is released for Windows x64 only.