Frequently Asked Questions
Answers to the questions that come up most often about lossless volume normalization with mp3rgain — how the gain rewrite works, what is reversible, which formats are covered, and how it relates to the tools it replaces.
How does mp3rgain change volume without re-encoding?
MP3 and AAC frames carry a global_gain field that scales the decoded output. mp3rgain rewrites that field in every frame (1 step = 1.5 dB) — the compressed audio data itself is never touched, so quality is preserved bit-exactly and the change is permanent on any player or device.
Is mp3rgain a drop-in replacement for mp3gain?
Yes. The CLI flags, the TSV output format, and the APEv2 mp3gain_undo tag are all mp3gain-compatible, so existing scripts, Dockerfiles, and parsers (e.g. beets) keep working unchanged. For most setups migration is a one-line sed substitution.
Can I undo a gain change?
Yes. mp3rgain records the previous state in mp3gain-compatible undo tags, and mp3rgain -u restores the original file exactly — for both MP3 and AAC/M4A. This is a key difference from foobar2000's AAC gain feature, which has no undo path.
What replaced aacgain? Is there a maintained aacgain alternative?
aacgain has been unmaintained since ~2009 and rarely builds on modern 64-bit systems. mp3rgain is the only actively maintained CLI for lossless AAC/M4A bitstream gain adjustment — cross-platform, scriptable, and undoable, with the same CLI conventions as mp3gain/aacgain.
How is this different from ReplayGain tags written by rsgain, loudgain, or ffmpeg?
It is a superset, not an alternative. mp3rgain runs the same kind of ReplayGain analysis and writes the standard REPLAYGAIN_TRACK_GAIN / REPLAYGAIN_ALBUM_GAIN tags too — but it also applies the gain to the bitstream itself, so the corrected volume plays everywhere, including on the many hardware players, car stereos, and apps that ignore ReplayGain tags. By default it uses the ReplayGain 1.0 algorithm (89 dB reference) for full mp3gain compatibility; since v3.0, opt-in --rg2 and --r128 flags measure loudness with ITU-R BS.1770 (LUFS), consistent with those tools.
Why does mp3rgain report a higher peak than rsgain on my AAC files?
Because the two are measuring different signals, and both are right about their own input. Lossy AAC decodes to samples that can exceed full scale, and decoders disagree about what to do with them: symphonia (which mp3rgain uses) and ffmpeg's native decoder pass them through, while Apple's AudioToolbox decoder hard-limits at exactly 1.0. mp3rgain reports the decoded signal as it is, which is the headroom a float playback path actually needs. On the file this was investigated with, mp3rgain measured a true peak of 2.287768 and rsgain 1.307024 — and 1.3215 is exactly what an ideal band-limited interpolation of the clamped signal gives. The gain values agree to 0.01 dB throughout, and applying each track's gain brings the unclamped peak below full scale anyway, so no player attenuates differently. The bursts themselves come from the encoder: re-encoding the same source with Apple's encoder dropped that track from 1.790314 to 1.276827.
Does mp3rgain write ReplayGain tags?
Yes. When gain is applied, mp3rgain writes REPLAYGAIN_TRACK_GAIN and REPLAYGAIN_TRACK_PEAK — plus REPLAYGAIN_ALBUM_GAIN and REPLAYGAIN_ALBUM_PEAK in album mode — to ID3v2 TXXX, APEv2, or MP4 freeform tags depending on the format. Since 3.2.0 the MP3 default puts REPLAYGAIN_* in ID3v2, where players look — ffmpeg does not read APEv2 on MP3 at all — while MP3GAIN_UNDO stays in APEv2 for mp3gain interop. Use -s a for the old all-APEv2 layout or -s i to put everything in ID3v2. Following mp3gain's convention, the values describe the residual gain left after the bitstream rewrite, so ReplayGain-aware players and ReplayGain-blind ones arrive at the same loudness. In the --rg2 and --r128 modes a REPLAYGAIN_ALGORITHM tag records which measurement was used. Use -s s to skip tag writing.
Does mp3rgain support EBU R128 or ReplayGain 2.0 loudness?
Yes, since v3.0. ReplayGain 1.0 stays the default so re-scans match mp3gain exactly, and two opt-in flags select ITU-R BS.1770 gated loudness measurement: --rg2 normalizes to the ReplayGain 2.0 reference of -18 LUFS and --r128 to the EBU R128 broadcast target of -23 LUFS. Measurements agree with ffmpeg ebur128 and libebur128-based tools within 0.05 LU. The GUI has a matching analysis mode selector.
Does mp3rgain need ffmpeg or other dependencies?
No. mp3rgain is a single static binary with zero external dependencies — no ffmpeg, no mp3gain, no aacgain. Decoding for analysis is done by the pure-Rust Symphonia library built into the binary.
Does mp3rgain support FLAC, Opus or Vorbis?
Not for gain application. Those formats have no in-bitstream gain field equivalent to MP3/AAC global_gain, so there is nothing to rewrite losslessly. For those formats a tag-based tool such as rsgain is the right choice. The same applies to ALAC and DRM-protected M4P: mp3rgain recognises them and reports them as skipped, leaving the file alone without failing the rest of the run.
Does mp3rgain handle raw .aac files and video MP4s?
Yes, both since v3.7.0. A raw ADTS .aac stream — what ffmpeg -f adts, DVB and HLS captures and some rippers produce — gets the same lossless global_gain rewrite and undo as AAC in an M4A container; because a raw stream has no container for metadata, its undo and REPLAYGAIN_* values go into an ID3v2 tag instead of MP4 freeform atoms, so the -s a / -s i layout choice does not apply. For MP4 files carrying video, codec detection previously looked only at the first track in the moov box and so missed the audio track behind the video one; that is fixed, and the audio track of a video MP4 is now adjusted correctly.
Can I write ReplayGain tags without changing the audio?
Yes, with --tags-only since v3.5.0. It analyses as usual but stores the absolute REPLAYGAIN_* values and leaves every audio frame byte-identical, the way loudgain and rsgain work, so the listener keeps the choice of turning ReplayGain off in their player. It needs -r or -a, and writes no MP3GAIN_UNDO because nothing was changed to undo. The trade-off is the point of mp3rgain in reverse: no correction is baked in, so hardware that ignores ReplayGain tags plays the file at its original loudness.
Is there a GUI version?
Yes. mp3rgui is a native desktop app (macOS, Windows, Linux) with drag-and-drop loading, parallel Track/Album ReplayGain analysis, an options panel mirroring the CLI flags, and an undo menu. Install via brew install --cask M-Igashi/tap/mp3rgui, winget install M-Igashi.mp3rgui, or yay -S mp3rgui.
How do I install mp3rgain?
macOS: brew install M-Igashi/tap/mp3rgain. Windows: winget install M-Igashi.mp3rgain. Arch Linux: yay -S mp3rgain-bin. Ubuntu 26.04+: ppa:m-igashi/mp3rgain. Nix: nix profile install github:M-Igashi/mp3rgain. Docker: docker pull ghcr.io/m-igashi/mp3rgain:latest. Cargo: cargo install mp3rgain. Pre-built binaries for all platforms are on GitHub Releases.
Can I use mp3rgain in Docker or CI pipelines?
Yes. Official multi-arch images (linux/amd64, linux/arm64) are published to ghcr.io/m-igashi/mp3rgain. The image is FROM scratch with a fully static musl binary (~2 MB) and the binary as entrypoint, so all CLI flags work identically — a drop-in replacement for mp3gain in containerized batch jobs, e.g. Plex library maintenance.
Will rewriting files break my backups or sync?
Applying gain rewrites the file, which updates its modification time and makes rsync, Syncthing and most backup tools re-transfer it. Pass -p to preserve the original timestamp if that matters for your setup.
Next
Not covered here? Open an issue on GitHub, or browse the download statistics and project documentation.