rsgain: ReplayGain 2.0 tagging without touching the audio stream

Tags, not normalisation: what rsgain actually changes

rsgain, which stands for really simple gain, is a ReplayGain 2.0 command line utility for Windows, macOS, Linux, BSD and Android.

The mechanism is the important part. rsgain applies loudness metadata tags to your files while leaving the audio stream untouched, and a ReplayGain-compatible player will then dynamically adjust the volume of your tagged files during playback. Nothing is re-encoded, and no file is louder or quieter than it was. The information is written alongside the audio and the player acts on it.

That distinction is the whole reason the tool exists in this form. A loudness normalisation tool that re-encodes your library destroys bit-perfect playback, loses the original encoder's headroom decisions and takes hours on a large collection. A metadata tagger is a fast, lossless pass over the files, and the volume adjustment happens at playback time on whatever device you are listening on.

The audience is therefore music collectors and library maintainers, and the project describes itself as designed with a batteries included philosophy, allowing a user to scan their entire music library without requiring external scripts or other tools. It aims to strike a balance between power and simplicity by offering multiple user interfaces.

It is also the backend for the MusicBrainz Picard ReplayGain 2.0 plugin, and the readme suggests the plugin to users who are not comfortable with command line interfaces.

Easy mode, custom mode, and the Picard plugin as three front ends

The readme's usage section is organised around three ways in, and the choice of interface is really a choice of how much control you want.

Easy mode is the one the project leads with. The Docker example shows the shape of it: rsgain easy -m MAX /mnt, where the -m argument sets the mode. Easy mode is the batteries-included path, the one that scans a library and tags files without you describing the details.

Custom mode is for the cases where easy mode's defaults are wrong for you, for example a library where you want different treatment for different albums, and the readme points at the documentation for the options rather than enumerating them in the summary.

The third front end is the MusicBrainz Picard plugin, which is described as providing a GUI frontend to rsgain. Picard is a music tagger, so the audience for a tagging backend and the audience for Picard are the same people, which makes that a natural pairing rather than an arbitrary integration.

The one output caveat the readme gives is about Docker, not about the tags: the docker log to stdout updates too slowly for the scan progress bar, and if you are not using multithreaded mode you should consider passing -q to silence the output. That is a small detail, and it is also a hint that the progress reporting is tied to the threading model rather than to a separate progress mechanism.

Installing on macOS, Linux, FreeBSD and Android, package by package

The installation section is long because the tool is packaged widely, and the differences matter more than usual here because the audio libraries underneath are the source of most of the trouble.

On macOS there are separate builds for Apple Silicon and Intel, both requiring macOS 12 Monterey or later, and they are not codesigned, so Gatekeeper will most likely block execution. The documented workaround is to remove the quarantine bit:

xattr -d com.apple.quarantine /path/to/rsgain

On Linux the distribution story is long. Debian and Ubuntu have an official package starting in Debian 13 Trixie and Ubuntu 24.04 noble:

sudo apt install rsgain

There is also a .deb for Debian Bookworm on the release page:

wget https://github.com/complexlogic/rsgain/releases/download/v3.8/rsgain_3.8-1_amd64.deb
sudo apt install ./rsgain_3.8-1_amd64.deb

And here is the warning that shows the age of the tool: the Bookworm package will not work on recent Ubuntu releases due to an FFmpeg ABI break. That is the real cost of the library dependency, and it is the kind of thing that a static build exists to solve. An x86_64 static build is available that should run on recent releases of most GNU-based Linux distros, meaning any distro shipping GCC 10 or later, and it is distributed as a portable TAR.

Arch and Manjaro are in the AUR, Fedora packages it, and Nix has it in nixpkgs with three documented ways to use it, running it without installing, installing it into a Nix environment, or adding it to a NixOS configuration. FreeBSD has it in the ports tree and as a package from 2023Q1, and Android users can install it through Termux.

Windows: a portable ZIP, a Scoop bucket, and the Path dance

On Windows, rsgain is distributed as a portable ZIP that you extract to a folder of your choice, with a separate download for the x64 build of version 3.8.

The readme then spends four numbered steps on adding that folder to the Path system environment variable so you can invoke the program as rsgain rather than by full path to the .exe file. The steps are the classic Windows route: open the run box with the Windows key plus R, type sysdm.cpl, press enter, move to the Advanced tab, click the Environment variables button, select Path under System variables, press Edit, and add the folder you extracted rsgain.exe to.

That manual procedure is exactly what Scoop removes. rsgain is available in the Scoop extras bucket, and the readme is explicit about the benefit: installing via Scoop enables you to receive automatic upgrades to future versions, unlike the manual installation method described above.

scoop install extras/rsgain

The compatibility note is also specific. rsgain should be run on Windows 10 or later for full compatibility, but it can run on versions as early as Vista with some caveats, and the readme points at a Windows Notes section for the details.

The repeated pattern across platforms is a portable binary plus a package manager entry, with the package manager preferred because upgrades are the thing you will actually want.

The Docker path, and the mount that you have to remember

The repository contains a Dockerfile that builds a container based on the current Debian Stable release, and the README gives a one-line build:

docker build -t rsgain https://github.com/complexlogic/rsgain.git

The Dockerfile itself is worth a glance, because it explains the shape of the image. It starts from debian:trixie, takes a version and architecture argument, installs curl, ca-certificates and openssl, downloads the matching .deb from the GitHub releases, installs it with apt, cleans the apt lists and the downloaded file, and sets the entrypoint to the rsgain binary.

The reasoning for the container is stated plainly: rsgain requires a relatively up-to-date operating system, so this method can be used to run rsgain on an older system if necessary. Given the FFmpeg ABI break that breaks the Bookworm package on recent Ubuntu, that is a genuine use rather than a container enthusiast's justification.

The part people get wrong is the filesystem. A Docker container does not have access to the host filesystem by default, so to use rsgain in a container you need to mount your music library to a mount point, using the -v option followed by the path to your library and the mount point, separated by a colon:

docker run -v /path/to/library:/mnt rsgain easy -m MAX /mnt

The command inside the container is the easy mode invocation, and the path it operates on is the mount point, not the host path. Getting that pairing wrong is the classic container mistake here, and it fails in a confusing way, because the tool runs happily against an empty directory.

Licence, formats and what the documentation does not settle

The repository carries a LICENSE file and a separate LICENSE-CRCpp, which suggests the project's own terms alongside terms for the bundled CRC++ library. The project listing records the licence as a custom one that GitHub cannot classify, so the file in the repository is the one to read rather than any badge. This is a description of how the licensing is arranged and not legal advice.

On formats, the readme has a Supported File Formats section whose contents are not visible in the excerpt, but the topic tags name the ones the tool cares about: audio, flac, mp3, loudness and replaygain. The file formats are where the FFmpeg dependency earns its keep, and the same dependency is what breaks on a distribution upgrade.

Two things a reader will want that the visible documentation does not give. The first is the exact set of tags written, and whether rsgain writes ReplayGain 2.0 metadata only or also the older ReplayGain 1.0 fields that some players still read. The second is what happens to files it cannot tag: whether it skips them, reports them, or fails the run. Neither is answered in the visible text, and both matter before you point the tool at a few thousand files.

The design philosophy section is listed in the readme's table of contents but its text is not in the excerpt either, which is a shame, because for a utility whose main design decision is what it refuses to do, the philosophy is usually the interesting part. The CHANGELOG in the repository root and the docs/ directory, which holds BUILDING.md among others, are where the remaining detail lives.

Editorial conclusion

rsgain fits a collector with a mixed loudness library who wants per-track volume normalisation at playback time, and it does not fit someone who wants the files themselves levelled, since the audio stream is deliberately left untouched. Before running it over a library, copy it first and keep a backup, because writing tags into files is not something you can undo by re-running the tool, and check the supported format list and the custom mode options in the documentation before you point it at a folder.

Frequently asked questions

Official sources

1. complexlogic/rsgain on GitHub
2. Issues
3. README
4. Releases