iTunes Sound Check vs MP3Gain: Tag-Based vs File-Based Volume Fixes

Both promise the same thing — no more lunging for the volume knob between songs — but they are built on opposite mechanics, and using them together on the same library is a classic way to make things worse. Sound Check stores a volume adjustment in each file’s metadata and lets Apple’s software apply it during playback. MP3Gain rewrites the gain fields inside the MP3 itself, so every player on earth plays it at the corrected level. Which one you should use depends entirely on where your listening happens.

How Sound Check actually works

When you enable Sound Check in iTunes or the Apple Music app, the software analyzes each track once and writes the result into the file’s tags — in MP3, AAC, AIFF, and Apple Lossless files this is the iTunNORM value. The audio data itself is not modified in any way. At playback, Apple software reads the stored adjustment and turns the track up or down to what it calculated as the common level. Turn Sound Check off, use a different player, or copy the file to a device that doesn’t speak Apple’s metadata, and the adjustment simply doesn’t exist — the file plays at its original volume everywhere else.

Two limitations follow from that design. First, Sound Check is track-by-track only: there is no album mode, so a quiet intro track gets leveled as aggressively as a single, dissolving the loudness relationships an album was mastered with. Second, Apple’s analysis is its own, simpler loudness estimate — long criticized by audio communities as cruder than ReplayGain, particularly on very dynamic material. The leveling you get is convenient, automatic, and entirely rented from Apple’s ecosystem rather than owned by your files.

How MP3Gain differs, in one table

The file-level mechanism is the same one examined in Is MP3Gain Lossless? — decoders have always applied the frame gain field as part of playback, so no cooperation from the player is required.

The trap: never run both systems on the same files

Here is the failure mode that fills forum threads. A user levels their MP3s with MP3Gain, then plays them in iTunes with Sound Check still on. Sound Check now applies its own stored adjustment on top of audio that was already corrected — tracks end up double-adjusted, some too quiet, some oddly loud, and the user concludes one of the tools is broken. Neither is; they simply stacked. Worse, the stored iTunNORM values were computed from the files’ original loudness, so after MP3Gain changes the audio they no longer describe the files at all until the library is re-analyzed. The rule is simple: pick one system per library. If you process files with MP3Gain, leave Sound Check off for them. If your listening is 100% inside Apple Music and iTunes, Sound Check alone is the zero-effort option and MP3Gain adds nothing — Apple devices will ignore your frame gains’ intent only in the sense that they don’t need them, since playback there is already leveled by the tag system. The moment files leave that garden — a car USB stick, a DJ laptop, an Android phone — file-based leveling is the only kind that survives the trip.

Checking which system your library is actually using

Untangling a mixed library starts with looking, not processing. In iTunes or the Music app, selecting a track and opening its info window shows the Sound Check adjustment Apple computed — a plain decibel figure on the file’s summary — which confirms the file carries an iTunNORM value and tells you how large a correction Apple thinks it needs. A file that was leveled with MP3Gain but still shows a hefty Sound Check adjustment is a file the two systems will fight over. The clean-up procedure is boring by design: decide the winning system for that library, then neutralize the other. To retire Sound Check, simply switch it off in playback settings on the computer and on each device — the tags become inert weight, harmless if ignored. To retire MP3Gain’s changes instead, use its undo (the gain information stored in the file makes reversal exact, as the lossless explainer covers) and let Apple’s analysis stand. What not to do is “fix” the fight by processing a second time with the other tool: whichever ran second computed its values from files the first had already changed, and the result pleases neither system.

One more practical caveat for the Apple-only household: the tag values travel with the files during sync, but the Sound Check setting does not — it has to be switched on in the playback preferences of the computer and separately on each iPhone, iPad, or iPod that plays the library. A library can be perfectly tagged and still play unleveled on the one device where the toggle was never touched, which is the most common reason Sound Check “doesn’t work” in an otherwise all-Apple setup.

The middle path for Apple loyalists: iVolume

One tool deserves mention for listeners who stay inside Apple’s world but distrust Sound Check’s math: iVolume, a long-running commercial utility from mani.de, whose site and user guide are still online. iVolume analyzes your Music/iTunes library with the ReplayGain algorithm — the same measurement MP3Gain uses — and then writes the results into the very same Sound Check field Apple uses, replacing Apple’s rougher values with better ones. You keep the tag-based convenience (nothing in the audio changes, Sound Check stays the playback mechanism, and it must remain switched on for the effect to appear) while upgrading the analysis underneath it. It is the right answer to a narrow question — “Sound Check, but accurate” — and the wrong one if your files ever need to carry their leveling outside Apple’s apps.

For everything outside that garden, the format support overview maps the file-level and tag-based options for MP3, AAC, FLAC, WAV, OGG and more.

How to Normalize OGG Vorbis Files with VorbisGain

MP3Gain refuses .ogg files, and there is a principled reason why: the OGG Vorbis world solved the loudness problem the opposite way. Where MP3Gain bakes the adjustment into the audio frames so that any player plays the file at the right volume, VorbisGain writes the ReplayGain values into the file’s comment tags and trusts the player to apply them at playback. Nothing in the audio is ever rewritten. This guide explains how VorbisGain works, how to run it for tracks and albums, and — crucially — where its tag-based approach succeeds and where it silently does nothing.

Two philosophies: change the file, or inform the player

The contrast is worth understanding before you tag a whole library, because it decides whether you hear any difference at all. MP3Gain’s file-level approach (explained in Is MP3Gain Lossless?) modifies a gain field that decoders must read, so the leveling is universal but the file is changed — reversibly, thanks to its undo tag. VorbisGain, originally written by Gian-Carlo Pascutto, never touches the encoded audio. It performs the same ReplayGain analysis, then stores the results as ordinary Vorbis comments inside each file — fields such as REPLAYGAIN_TRACK_GAIN, REPLAYGAIN_TRACK_PEAK, and their album counterparts. A player that supports ReplayGain reads those values and adjusts its output volume on the fly; a player that doesn’t, plays the file exactly as encoded, tags notwithstanding.

Neither philosophy is wrong. Tag-based leveling is non-destructive by construction — delete the comments and the file is bit-identical to the original — and it is the same design that FLAC normalization uses. File-level leveling is the only design that works on hardware and software you don’t control. Choose per library, per destination.

Running VorbisGain

VorbisGain is a small command-line tool; its project home is on sjeng.org, and Rarewares hosts more recent compiles for Windows. The everyday usage is simple:

• Single tracks: vorbisgain *.ogg analyzes each file in the folder and writes its track gain and peak tags.
• Albums: add the album switch — vorbisgain -a *.ogg — so the files are treated as one album: album gain is computed from the whole set, preserving the intended loudness differences between tracks while leveling the album against the rest of your collection.
• Folders: the recursive switch (-r) walks subdirectories, which is how you tag an existing artist/album folder tree in one pass.
• Undoing: because nothing but comments was written, removing the ReplayGain fields with any tag editor returns the files to their original state. There is nothing to reverse-engineer.

Graphical alternatives exist: foobar2000’s ReplayGain scanner writes the identical tags to OGG files (select files, right-click, ReplayGain), and newer multi-format scanners cover Vorbis alongside FLAC and Opus. The values are the standard ones regardless of which tool writes them — what matters is the player at the other end.

Verifying the tags, and two habits worth keeping

Because VorbisGain changes nothing audible in the file itself, verify its work by reading the tags, not by listening. Any tag viewer — or foobar2000’s properties dialog — should show the REPLAYGAIN_* fields after a run; if a file lacks them, it was skipped or the run targeted the wrong folder. Two habits prevent the common disappointments. First, decide track versus album before the big run: tagging a folder file-by-file and later wishing you had album values means rescanning, not editing, because album gain is computed from the set as a whole. Second, remember that the peak value VorbisGain stores is what allows a player to refuse a gain increase that would clip; if your player offers a “prevent clipping” style option alongside ReplayGain, leave it on — a track that stays a decibel shy of the target is a better outcome than a distorted one. Finally, a note on file hygiene: since the comments are ordinary metadata, careless tag editing with tools that rewrite the whole comment block can strip ReplayGain fields without warning. If a leveled album suddenly plays unevenly after a retagging session, check the fields before blaming the player.

Where it works — and where it silently doesn’t

Support in the open-source ecosystem is strong: foobar2000, most Linux desktop players, and many Android players read Vorbis ReplayGain tags and apply them faithfully, album mode included. The weak spots are the same as for every tag-based system — car head units, minimalist hardware players, and some streaming boxes ignore the tags entirely, with no warning and no error. If your tagged OGGs “didn’t normalize” in the car, the tags are almost certainly fine; the player simply never looked at them.

For those destinations there is no lossless rescue: a file-level adjustment for Vorbis would require decoding and re-encoding with the gain applied, costing a generation of lossy quality. The pragmatic answers are to keep the master library tagged and pristine, and to export converted copies — re-encoded at a fixed level, or converted to MP3 and run through MP3Gain — for the tag-blind device. That is a deliberate trade, made on copies, with the originals intact.

One more support nuance is worth knowing before you judge the results: partial support exists. Some players read track gain but not album gain, flattening albums even though both values are present — and they are present, because VorbisGain writes the track values alongside the album ones, so track-mode players behave sensibly too. Others apply the tags but ignore the stored peak, which can let a heavily boosted quiet track clip on playback; if your player exposes a preamp or clipping-prevention setting, a decibel or two of headroom there is cheap insurance. None of this is discoverable from the files themselves — it only shows up in listening — which is why the tag-based formats reward a ten-minute test on your actual playback chain before you commit the whole library to the workflow.

One family footnote: OGG containers carrying Opus audio use a sibling system

To sum up the working rule for Vorbis libraries: tag everything with VorbisGain (or your scanner of choice), album mode for albums, and trust the method exactly as far as your playback chain honors tags. The audio files themselves will still be the same pristine encodes you started with — which, for a format chosen by people who care about open standards and sound quality, is rather the point.

How to Normalize WAV Files: WaveGain and Editor Workflows

WAV is the awkward format in the ReplayGain family. It has no per-frame gain field for an MP3Gain-style tool to rewrite, and — unlike FLAC or OGG — no standardized place to store ReplayGain tags either. So leveling a WAV file means doing the one thing MP3Gain never does: actually changing the audio samples. Done with the right tool, that is a perfectly reasonable workflow, as long as you understand it is permanent. This guide covers WaveGain, the purpose-built tool for the job, and the editor-based alternative.

Why WAV normalization is necessarily destructive

The two painless mechanisms simply do not exist for WAV. MP3Gain’s file-level method needs a gain field inside the audio frames that every decoder obeys — WAV’s plain PCM stream has none. The tag-based method used for FLAC files needs an agreed metadata home for ReplayGain values, and as the ReplayGain documentation community has long noted, WAV offers no suitable standard chunk for gain tags, so tag-based leveling never took hold for the format. What remains is arithmetic: multiply every sample by a factor so the track lands at the target loudness. That rewritten file then plays at the new volume everywhere — no player support required — but the original samples are gone. Work on copies, and keep your masters untouched.

WaveGain: ReplayGain analysis, applied to the samples

WaveGain, written by John33 and distributed through Rarewares, was built to close exactly this gap. It runs the standard ReplayGain analysis on WAV files — the same perceptual loudness measurement that powers MP3Gain, against the same 89 dB reference level — and with its apply option (--apply, or -y) it writes the adjusted samples back into the file. Because the level is baked into the audio itself, any encoder or player that touches the file afterwards inherits the normalized volume, which is precisely why WaveGain earned its place in CD-ripping and encoding pipelines: normalize the WAV once, then encode, and the MP3 or FLAC you produce is already level.

Three options deserve attention before you run it across a folder:

• Analysis-only is the default mindset. Run WaveGain without the apply switch first and read the computed gains. If a track’s suggested change looks implausible, you want to know before anything is rewritten.
• Dithering. When gained samples are written back — particularly where bit depth is reduced or values are requantized — WaveGain offers dithering options, including noise-shaped variants. Dither trades a whisper of added noise for the removal of quantization distortion; for straightforward same-bit-depth gain changes it matters little, but it is the right tool when a workflow also steps a file down in bit depth.
• Extra gain and the hard limiter. Like MP3Gain, WaveGain lets you offset the 89 dB target. Push a quiet, dynamic recording upward and you risk clipping; its hard limiter option compresses peaks to buy loudness instead — a deliberate sound change, not a free lunch, and one to use knowingly.

And the warning that cannot be repeated too often: applied WaveGain changes are irreversible. There is no undo tag, because there is nowhere standard to keep one. Copy the folder, process the copy.

The editor route, and when it makes more sense

If you only have a handful of WAV files, an audio editor does the same job with more visibility. The disciplined version of the workflow is: measure first (a ReplayGain scan in a player, or the loudness readout your editor provides), then apply that specific gain figure in the editor — Audacity’s Amplify effect, or a full editor such as WavePad — and export to a new file rather than overwriting. Avoid the one-click “normalize” button unless you know it is loudness-based: classic peak normalization only guarantees the loudest sample hits full scale, which says almost nothing about how loud the track sounds, and is the single most common reason “normalized” WAVs still jump in volume. The editor route also suits WAVs that need other surgery anyway — trimming, fades, joining — since the file is being rewritten regardless.

One reassurance about what WaveGain does not change: it operates on the sample values only. A 44.1 kHz, 16-bit stereo file goes in and a 44.1 kHz, 16-bit stereo file comes out — same format parameters, same length, same compatibility with whatever consumes it next. The only thing that moved is how loud those samples say the music is.

A safe working pattern for irreplaceable WAVs

Because nothing in this workflow can be undone, process discipline matters more than tool choice. Work in a duplicated folder with a name that says what happened to it (album-normalized/ next to album-original/), never in place. Run the analysis pass first and eyeball the numbers before applying anything — a track that a scanner wants to move by an extreme amount is usually telling you something (a near-silent intro, a wrong file, a spoken segment) rather than asking for a heroic boost. After applying, run the analysis once more on the processed copies: the second scan is your receipt, confirming every file now sits at the intended level before the originals go back into the archive. If you are working in an editor rather than WaveGain, there is one refinement worth knowing: if the editor holds the audio as 32-bit float internally, gain reductions and increases are effectively non-destructive until the moment you export — so make all your level decisions first, audition the results inside the project, and only then commit to a 16-bit export, with dithering, as the final step. The WAV’s close cousin AIFF behaves identically throughout this guide: same PCM reality, same absence of a gain field, same editor and WaveGain-style options.

Often the better answer: normalize after you encode

Step back and ask why the WAVs need leveling at all. WAV is usually an intermediate — a rip, a recording, a render on its way to becoming something else. If the destination is MP3, normalize the MP3s with MP3Gain and keep the lossless, reversible workflow. If the destination is FLAC, tag the FLACs and keep the audio pristine. Reserve WaveGain for the cases where the WAV is the final deliverable: sample libraries, broadcast and telephony assets, game and software audio, or an encoder pipeline that consumes WAV directly. Choosing the stage at which to level is most of the craft; the format support overview lays out the options format by format.

How to Normalize FLAC Files: ReplayGain Tags, Done Right

Sooner or later every MP3Gain user asks the same question about their lossless shelf: can I do that to my FLAC files? The honest answer is not the same way — and that is fine. FLAC normalization works by writing ReplayGain tags into the files and letting the player apply the adjustment during playback. The audio is never rewritten at all, which makes the method perfectly reversible and completely safe — but it also means the leveling only exists in players that understand the tags. Here is how the mechanism differs, and how to do it properly with metaflac or foobar2000.

Why FLAC has no MP3Gain equivalent

MP3Gain works because the MP3 format gives it something to work with: every MP3 frame carries a global gain value that decoders apply as part of normal playback, so changing the file’s loudness is a matter of rewriting that field (the mechanism is explained in Is MP3Gain Lossless?). FLAC has no equivalent decoder-applied gain field in its frames. There is therefore no mainstream tool that changes a FLAC file’s actual loudness losslessly and reversibly the way MP3Gain changes an MP3’s — any process that alters FLAC audio data means decoding and re-encoding, which defeats the point of keeping FLAC.

Instead, the FLAC specification reserves space in the file’s Vorbis comment metadata for ReplayGain values. The standard workflow is: a scanner analyzes each track’s perceived loudness, computes the adjustment needed to reach the reference level, and stores that number — plus the track’s peak — as tags such as REPLAYGAIN_TRACK_GAIN and REPLAYGAIN_ALBUM_GAIN. A ReplayGain-aware player reads the tags and turns the volume up or down while playing. The file’s audio samples are never modified, so “undoing” normalization is as trivial as deleting the tags. This tag-based design is also why FLAC, Musepack, and APE players so consistently support ReplayGain: support for the values is written into the formats’ own specifications.

Method 1: metaflac (the official command-line tool)

metaflac ships with the FLAC project itself, and its --add-replay-gain option is the canonical way to tag FLAC files:

• Run metaflac --add-replay-gain *.flac in a folder to write track gain values for each file.
• For an album, pass all of the album’s files in a single invocation — metaflac treats one invocation’s file set as one album and computes the shared album gain from them together. Running it file-by-file silently gives you track gains only, which will flatten the intended loudness differences between songs on the same album.
• Remove the values just as easily with metaflac --remove-replay-gain if you ever want the tags gone.

Because only metadata changes, the operation is fast and risk-free — you do not even need backups, though a scanner bug can at worst cost you the tags, never the audio.

Method 2: foobar2000 (the graphical route)

If you would rather click than type, foobar2000’s built-in ReplayGain scanner does the same job and writes the same standard tags: select the files in a playlist, right-click, and choose ReplayGain → “Scan per-file track gain” for individual tracks or “Scan selection as a single album” for album gain. Our MP3Gain vs foobar2000 comparison covers the philosophical difference between the two tools in depth; for FLAC there is no contest, because foobar2000’s tag-writing is exactly what the format was designed for. Newer cross-format scanners such as rsgain write the same tags for FLAC as well, if you want one tool that covers a mixed library.

What actually gets written — and how to check

A properly tagged FLAC file carries up to five ReplayGain fields in its Vorbis comments: REPLAYGAIN_TRACK_GAIN and REPLAYGAIN_TRACK_PEAK for the file alone, REPLAYGAIN_ALBUM_GAIN and REPLAYGAIN_ALBUM_PEAK from the album pass, and a reference loudness marker recording the level the values were computed against. The peak fields are not decoration: they let a player cap its adjustment so that applying a large positive track gain cannot push the loudest sample into clipping, trading a little loudness for a clean signal — the tag-based world’s answer to MP3Gain’s clipping warnings. You can inspect what any scanner wrote with metaflac --list file.flac and a search for REPLAYGAIN among the comments, or in foobar2000’s properties panel. If the album fields are missing, the files were scanned one by one instead of as a set — rescan them together rather than living with flattened dynamics.

One playback setting matters as much as the tags themselves: most players let you choose whether ReplayGain is applied per track, per album, or not at all, and the wrong mode makes a correctly tagged library sound wrong. Album mode is the right default for album listening; track mode suits shuffled playlists of unrelated singles. And when you eventually convert FLACs for a portable device, note that good converters (foobar2000’s included) can read these same tags and apply the gain during conversion — so the tagging work you do once keeps paying off every time the files change shape.

One scanner per album, one reference for the library

A final consistency rule. ReplayGain values are stored relative to a recorded reference level, and mainstream scanners — metaflac, foobar2000, rsgain in its default ReplayGain mode — share the conventional reference that descends from the original specification, so tags written by different tools generally interoperate. Even so, rescan a whole album with a single tool in a single pass rather than patching individual files over the years with whatever is installed: album gain is only ever as coherent as the analysis set behind it. If you later switch tools or deliberately change the reference approach (some newer workflows write values derived from the EBU R128 loudness standard instead), retag the library wholesale rather than mixing vintages — your player applies all of these values blindly, and a library where half the albums answer to one reference and half to another reintroduces exactly the jumps you set out to remove.

The catch you must plan around: player support

Tag-based leveling is a promise the player has to keep. Desktop players with good FLAC support (foobar2000, MusicBee, most Linux players) honor ReplayGain tags; many car stereos, smart speakers, and cheap hardware players ignore them completely, in which case your carefully tagged FLACs play at their original, mismatched volumes — the same failure mode described for car USB playback in our tutorials. If the destination ignores tags, your realistic options are to convert a copy of the library for that device (accepting that the copy is a transcode) or to level at playback time on a player you control. Do not “fix” your archival FLACs by permanently re-encoding them at a normalized level: you would be trading an exact, lossless archive for a one-time convenience.

Working with other formats too? The format support overview shows which formats get file-level treatment (MP3, AAC via AACGain, WAV via WaveGain) and which are tag-only like FLAC.

AACGain: Normalize M4A and AAC Files the Lossless Way

MP3Gain stops at the edge of the MP3 format — but its engine has a sibling. AACGain, written by Dave Lasker, is a modified version of the MP3Gain command-line engine that applies the exact same lossless trick to AAC audio: the files inside your iTunes-era library, ending in .m4a or .mp4. It analyzes loudness with the ReplayGain algorithm, then rewrites the gain value stored inside each AAC frame — no decoding, no re-encoding, and the change can be undone. This guide covers how it relates to MP3Gain, how to actually run it (including through the familiar MP3Gain window), and the real limits you need to know first.

Same engine, different format

The relationship is literal, not marketing. AACGain began as a fork of the MP3Gain back-end code, coordinated with MP3Gain’s author Glen Sawyer and announced on the official MP3Gain site in January 2005. Where MP3Gain’s engine only understands MP3 frames, Lasker’s version parses AAC frames — both raw AAC streams and, far more commonly, AAC audio stored inside an MP4 container, which is what .m4a and .m4b files are. Everything upstream of the frame parsing is shared heritage: the same ReplayGain loudness analysis, the same 89.0 dB default target, the same Track Gain and Album Gain modes, and the same adjustment granularity of 1.5 dB steps, because AAC frames carry a per-frame gain field just as MP3 frames do.

That shared mechanism is why AACGain deserves the word “lossless” in the same qualified sense we use for MP3Gain itself — see Is MP3Gain Lossless? for the full explanation. The compressed audio data is never touched; only the per-frame gain instructions and the undo/analysis information change. If you apply a gain change and dislike the result, the undo data lets you roll the file back, exactly as with MP3Gain. What AACGain does not do is make an AAC file play louder in a player that ignores the frame gain — but unlike tag-only methods, every decoder reads frame gain as part of normal playback, so the adjustment travels with the file to any device.

How to run it: three realistic routes

Route 1 — the MP3Gain GUI trick (the officially documented one). AACGain is a command-line program, but Lasker wrote it specifically so it would work with the existing MP3Gain GUI without much trouble. The official MP3Gain site documents the procedure: download the latest MP3Gain, then download AACGain, unzip aacgain.exe, rename it to mp3gain.exe, and move it into the MP3Gain program folder, replacing the existing backend. From then on, the window you already know analyzes and adjusts AAC files (.m4a or .mp4) exactly as it did MP3s. Keep a copy of the original backend if you want to switch back.

Route 2 — a dedicated front-end. A small Windows front-end called iGain was written to wrap aacgain.exe in a simple graphical window, and the cross-platform QMP3Gain front-end (covered in our MP3Gain for Mac guide in the context of MP3) can also drive the MP3Gain-family backends, including AACGain. These are community tools from the same era as AACGain itself, so expect a functional, dated interface rather than a polished modern app.

Route 3 — the command line. Because AACGain shares MP3Gain’s engine, its switches mirror the ones in our MP3Gain command line guide: analyze first, apply Track or Album Gain, and use the undo switch if you change your mind. One practical wrinkle: because of AAC patent licensing, AACGain was distributed as source code through the MP3Gain project on SourceForge rather than as an official binary release, so the prebuilt aacgain.exe copies in circulation come from long-standing third-party mirrors and project builds. Download it from a source you trust, and — as with any file-level tool — run it on copies of your library first.

The limits, stated plainly

• DRM files are off-limits. The official MP3Gain site states it directly: AACGain will not work on DRM-encoded files — the protected .m4p purchases from the early iTunes Store era. Files you ripped or encoded yourself work fine, and modern iTunes/Apple Music purchases have been DRM-free for years, so this mainly affects genuinely old libraries.
• It is a legacy tool. Like MP3Gain, AACGain has not been actively developed in years. It remains widely used because the format problem it solves has not changed, but there is no support desk and no promise of updates for future operating systems.
• Apple’s own ecosystem plays by different rules. Inside Apple Music and iTunes, volume leveling is handled by Sound Check metadata, not by frame gain. If your listening happens entirely inside Apple’s apps, read iTunes Sound Check vs MP3Gain before processing anything — applying both systems to the same files double-adjusts them.
• 1.5 dB steps still apply. Adjustments land within 0.75 dB of the target rather than exactly on it, the same trade-off as MP3Gain, for the same structural reason.

Track Gain or Album Gain for AAC files?

The same judgment call applies as with MP3s, because it is the same analysis underneath. Use Album Gain for anything released as an album — it preserves the deliberate loudness differences between tracks while leveling the album against the rest of your library. Use Track Gain for singles, compilations you assembled yourself, podcasts, and audiobook files, where each file should stand at the reference level on its own. The reasoning, including the edge cases around classical music and gapless albums, is laid out in Track Gain vs Album Gain; every word of it applies to AACGain unchanged. Two AAC-specific notes: audiobooks in .m4b form are just AAC in an MP4 container, so they process like any other file, and because only frame gain values and analysis tags change, chapter markers and cover art stored in the container are left as they were. And if you are mixing AACGain-processed files into a library that also lives in Apple Music, re-read the limits section above about Sound Check before you sync anything.

Should you use it?

If your library is a mix of MP3 and M4A and you want one consistent, player-independent volume level baked into the files themselves, AACGain is the only tool that extends MP3Gain’s proven, reversible method to the AAC half of that library. If instead your AAC files live and die inside Apple Music, Sound Check (or simply leaving the files alone) is the less invasive answer. And if a file is in some other format entirely — FLAC, WAV, OGG — neither program applies; our format support overview maps each format to the tool that actually fits it.