mp3rgain vs mp3gain, aacgain, rsgain & ffmpeg

Nearly every tool here is a ReplayGain tool — they all measure loudness the same way in principle. What actually separates them is where the correction ends up: in a tag the player reads, in the bitstream itself, or in re-encoded samples. This page starts there, then places each tool — including mp3rgain — on the resulting map.

One measurement, three destinations

1. Write ReplayGain tags. Measure loudness, store the result as metadata, and let the player apply it. Nothing about the audio changes. rsgain, loudgain, foobar2000 and ffmpeg -af replaygain all do this.
2. Re-encode the audio. Decode, apply gain to the samples, encode again. Works everywhere, at the cost of a generation of lossy quality on every pass. ffmpeg loudnorm is the usual example.
3. Rewrite the gain field inside the bitstream. MP3 and AAC frames carry a global_gain value that scales decoder output. Change it and the volume changes permanently, for every player, without decoding a single sample. mp3gain, aacgain, foobar2000 and mp3rgain do this.

Where each tool sits

Two rows deserve a footnote. foobar2000 is not just another entry here: the Hydrogenaudio community around it is where the ReplayGain 2.0 specification was worked out, and its scanner is the practical reference other implementations get checked against. If you want textbook-correct ReplayGain and you are on Windows, that is the answer, and mp3rgain's --rg2 mode exists to agree with it rather than to compete with it. And the three bitstream tools at the top are also taggers — the classic mp3gain lineage has always written ReplayGain tags next to the gain it bakes in.

Why the classic tools ran out

What went unmaintained was never ReplayGain itself — foobar2000 and rsgain carry the standard forward in better shape than ever. What lapsed was the specific lineage that pairs a ReplayGain analysis with a lossless bitstream rewrite on the command line. mp3gain's upstream development stopped around 2015 and aacgain's around 2009. aacgain is the harder loss: it is the tool people reach for when a library contains M4A files, and it has become difficult to build on current 64-bit toolchains. That left two practical options for lossless AAC gain: run an ancient binary, or sit at a Windows desktop with foobar2000 — which does the job well, but only from the GUI and without an undo path.

mp3rgain exists to cover the case neither one does: one memory-safe Rust binary for both MP3 and AAC, scriptable and headless, with undo on both — which is what makes it usable in a container or a cron job where a mistake needs to be reversible. If you are at a Windows desktop, foobar2000 remains an excellent answer.

Reference levels

A recurring source of confusion when comparing tools is that they normalise to different targets, so identical inputs legitimately produce different numbers:

mp3rgain defaults to ReplayGain 1.0 so re-scanning an mp3gain-processed library reproduces the same values instead of shifting everything. --rg2 and --r128 switch to ITU-R BS.1770 gated measurement when you would rather match the modern taggers — the target being foobar2000's numbers, not a separate dialect of them. In those modes mp3rgain also writes a REPLAYGAIN_ALGORITHM tag, so a library scanned in mixed modes stays legible.

Migrating from mp3gain or aacgain

The CLI flags, the TSV output layout, and the APEv2 mp3gain_undo tag are all mp3gain-compatible. For most setups migration is a single substitution:

sed -i 's/\bmp3gain\b/mp3rgain/g' your_script.sh

Existing undo tags written by mp3gain remain valid, so a library that mp3gain already processed can be rolled back with mp3rgain -u. The full flag-equivalence table, Dockerfile substitution patterns and the intentional behavioural differences are documented in the migration guide, and the bit-level verification against the original mp3gain is in the compatibility report.

When not to use mp3rgain

An honest boundary is more useful than a feature list:

• Your whole playback chain honours ReplayGain tags. Use rsgain. Tags are non-destructive and carry track and album values simultaneously.
• You want the most standards-faithful ReplayGain, and you are on Windows. Use foobar2000. It is the closest thing ReplayGain 2.0 has to a reference implementation: a full BS.1770 scanner, correct tags across far more formats than mp3rgain handles, and an "apply to file content" pass that bakes gain into MP3 and AAC bitstreams when you need that. Reach for mp3rgain instead when you need a command line, a non-Windows host, or an undo path.
• You need FLAC, Opus or Vorbis. Those formats have no equivalent in-bitstream gain field. Tag-based tools are the answer.
• You are producing a delivery master. Broadcast and streaming delivery usually wants a measured, documented loudness pass in a DAW or with ffmpeg loudnorm, not a gain-field rewrite.
• You want playback to switch between per-track and per-album loudness. mp3rgain writes both tag sets, but the gain baked into the bitstream is a single choice made at apply time; only a tag-driven player can flip between the two afterwards.

Next