Jump to content

ReplayGain: Difference between revisions

From Hydrogenaudio Knowledgebase
← Older edit
VisualWikitext
Skamp (talk | contribs)
24 edits
Added a paragraph to alleviate the confusion between reference tools using the classic RG algorithm, versus newer tools that use the newer algorithm.
Case (talk | contribs)
disabled_user
15 edits
 
(9 intermediate revisions by 2 users not shown)
Line 6: Line 6:


==Target loudness==
==Target loudness==
The target loudness of almost all ReplayGain utilities is 89&nbsp;dB SPL when replayed in an SMPTE RP 200 calibrated system (an early departure from the proposal, endorsed by its author<ref>[http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=83397&view=findpost&p=721854 Does Replay gain work differtly in Media monkey]</ref>) &mdash; the ReplayGain proposal and SMPTE recommendation are 6&nbsp;dB lower.<ref>[http://www.mars.org/mailman/public/mad-dev/2004-February/000993.html ReplayGain discussion at mad-dev]</ref> The target loudness may be more commonly known and understood as '''-18'''&nbsp;'''[https://en.wikipedia.org/wiki/LUFS LUFS]''' (''Loudness Units relative to Full Scale'').
The target loudness of ReplayGain is [https://wiki.hydrogenaudio.org/index.php?title=Original_ReplayGain_specification#Reference_level '''89'''&nbsp;'''dB SPL'''] / '''-18'''&nbsp;'''[https://en.wikipedia.org/wiki/LUFS LUFS]''' (''Loudness Units relative to Full Scale'').


Some utilities have realized the inadequacies of the classic ReplayGain loudness calculation, switching to a more modern algorithm ([https://www.itu.int/rec/R-REC-BS.1770-5-202311-I/en ITU-R BS.1770]). However, the way it was integrated was extremely ''ad hoc'', at least until a draft of a [[ReplayGain 2.0 specification|revised specification]] started being written.
Some utilities have realized the inadequacies of the classic ReplayGain loudness calculation, switching to a more modern algorithm ([https://www.itu.int/rec/R-REC-BS.1770-5-202311-I/en ITU-R BS.1770]). However, the way it was integrated was extremely ''ad hoc'', at least until a draft of a [[ReplayGain 2.0 specification|revised specification]] started being written.
Line 15: Line 15:
Implementations deal with the risk of clipping in different ways. Some have a "pre-amp" feature which reduces (or boosts) the original audio's level by a certain amount before doing whatever is needed for ReplayGain. Some have a "prevent clipping" feature to reduce the amount of ReplayGain adjustment to whatever amount would keep clipping from occurring, based on peak info stored in the file's metadata (thus reducing the effectiveness of ReplayGain). Some recommend using a compressor/limiter DSP to prevent or reduce clipping, regardless of whether it was caused by ReplayGain.
Implementations deal with the risk of clipping in different ways. Some have a "pre-amp" feature which reduces (or boosts) the original audio's level by a certain amount before doing whatever is needed for ReplayGain. Some have a "prevent clipping" feature to reduce the amount of ReplayGain adjustment to whatever amount would keep clipping from occurring, based on peak info stored in the file's metadata (thus reducing the effectiveness of ReplayGain). Some recommend using a compressor/limiter DSP to prevent or reduce clipping, regardless of whether it was caused by ReplayGain.


An alternative that may reduce the risk of clipping is the [https://tech.ebu.ch/docs/r/r128.pdf EBU R 128] recommendation of a '''-23'''&nbsp;'''LUFS''' target, although some may find the additional reduction in volume excessive, particularly if it leads to maxing out volume on user hardware. [[Opus]] in particular has adopted that recommendation.
An alternative that may reduce the risk of clipping is the [https://tech.ebu.ch/docs/r/r128.pdf EBU R 128] recommendation of a -23&nbsp;LUFS target, but that's a different standard, and some may find the additional reduction in volume excessive, particularly if it leads to maxing out volume on user hardware. [[Opus]] in particular has adopted that standard, using a global gain as well as <code>R128_TRACK_GAIN</code> / <code>R128_ALBUM_GAIN</code> tags. With ReplayGain, a simple (though somewhat radical) solution is to lower the preamp value by 5&nbsp;dB (or whatever one feels comfortable with) in the playback software. The RG target will always be -18&nbsp;LUFS, regardless of a user's volume or preamp settings.


== Implementations ==
== Implementations ==
Line 26: Line 26:
=== Old versus new algorithms ===
=== Old versus new algorithms ===
Since the ReplayGain standard does not define tags to specify which algorithm was used (classic or ITU-R BS.1770) or what target was set (RG's -18&nbsp;LUFS, EBU R 128's -23&nbsp;LUFS, or any other target set by the user or some piece of software), there may be confusion as to how the results were produced. Typically, utilities that ship with reference encoders (FLAC / metaflac, Vorbis / vorbisgain, WavPack / wvgain, Musepack / mpcgain…) use the original RG algorithm, which can produce values that differ from newer tools by several decibels in certain cases. Generally speaking, it is recommended to run other utilities or players that implement the ITU-R BS.1770 algorithm, although it may not be obvious which algorithm they use at first glance. Their documentation may provide that information.
Since the ReplayGain standard does not define tags to specify which algorithm was used (classic or ITU-R BS.1770) or what target was set (RG's -18&nbsp;LUFS, EBU R 128's -23&nbsp;LUFS, or any other target set by the user or some piece of software), there may be confusion as to how the results were produced. Typically, utilities that ship with reference encoders (FLAC / metaflac, Vorbis / vorbisgain, WavPack / wvgain, Musepack / mpcgain…) use the original RG algorithm, which can produce values that differ from newer tools by several decibels in certain cases. Generally speaking, it is recommended to run other utilities or players that implement the ITU-R BS.1770 algorithm, although it may not be obvious which algorithm they use at first glance. Their documentation may provide that information.
==== RG1, RG2 ====
Although there are many references online, and within ReplayGain scanners, about version 1 vs. version 2 of the ReplayGain standard, at the time of writing this, there is (admittedly) only one ReplayGain standard. The core principle, as well as the 4 tags from the original specification, have not changed. More tags have been proposed but they are still subject to debate. As a rule of thumb, tools that advertise "ReplayGain&nbsp;2" compliance employ the newer, more accurate ITU-R BS.1770 algorithm. [[foobar2000]] labels it "EBU R128" but it essentially means the same thing. Should a better algorithm be developed in the future, it will still work towards fulfilling ReplayGain's original goals, and probably write the same tags.


=== MP3Gain ===
=== MP3Gain ===
Line 92: Line 95:


=== MusicPlayer ===
=== MusicPlayer ===
* Custom implementation, not derived from the original MP3Gain one (but inspired from). As far as I know, all other implementations are directly derived from the MP3Gain (gain_analysis.c, which is GPL) source.
* Custom implementation, inspired by MP3Gain.
* Format: any that FFmpeg supports
* Format: any that FFmpeg supports
* Method: Audio
* Method: Audio
Line 101: Line 104:
* Since v1.1.6, defaults to ITU-R BS.1770 analysis (although it labels it EBU R128), but can be configured to use the "Classic ReplayGain" algorithm instead. The ITU-R BS.1770 implementation uses a reference level of -18&nbsp;LUFS instead of -23, in order to retain compatibility with the ReplayGain standard.
* Since v1.1.6, defaults to ITU-R BS.1770 analysis (although it labels it EBU R128), but can be configured to use the "Classic ReplayGain" algorithm instead. The ITU-R BS.1770 implementation uses a reference level of -18&nbsp;LUFS instead of -23, in order to retain compatibility with the ReplayGain standard.
* Format:
* Format:
** [[MP3]]: Values written to [[ID3v2]] (default) or [[APEv2]] tags. A separate function can be invoked to apply the tagged Track or Album Gain to the MP3 global gain fields (as MP3Gain does), and rewrite any existing tags to account for the peak change and compensate for the difference from 89&nbsp;dB. The 89&nbsp;dB reference level for tags isn't configurable, but the reference level applied to the global gain fields is (it's under Preferences > Advanced > Tools > ReplayGain Scanner > Target MP3 alteration volume level).
** [[MP3]]: Values written to [[ID3v2]] (default) or [[APEv2]] tags.
** [[Musepack]]: Values written to header.
** [[Musepack]]: Values written to header.
** (Ogg) [[Vorbis]]: Values written to [[Vorbis comment]].
** (Ogg) [[Vorbis]]: Values written to [[Vorbis comment]].
** [[Opus]]: Values written to [[Vorbis comment]] and/or file header.
** [[WavPack]]: Values written to [[APEv2]] tags.
** [[WavPack]]: Values written to [[APEv2]] tags.
** [[AAC]]: Values written to [[APEv2]] tags. As with MP3, it is also an option to apply gain via a separate function.
** [[AAC]]: Values written to [[APEv2]] tags
** [[MP4]]: Uses its own iTunes-compatible tagging system (though iTunes does not support ReplayGain).
** [[MP4]] (AAC, ALAC, MP3): Uses its own iTunes-compatible tagging system (though iTunes does not support ReplayGain).
** [[Free Lossless Audio Codec|FLAC]]: Values written to [[Vorbis comment]].
** [[Free Lossless Audio Codec|FLAC]]: Values written to [[Vorbis comment]].
** [[APE]]: Values written to [[APEv2]] tags.
** [[APE]]: Values written to [[APEv2]] tags.
** [[TAK]]: Values written to [[APEv2]] tags.
** [[TTA]]: Values written to [[APEv2]] or [[ID3v2]] tags.
** [[WMA]]: Values written to WMA tags.
** [[WAV]]: Values written to ID3 chunk.
** [[AIFF]]: Values written to ID3 chunk.
** [[Matroska]]: Values written to container tags.
** Modules ([[MOD]] etc.): Optionally saved into [[APEv2]] tags.
** Modules ([[MOD]] etc.): Optionally saved into [[APEv2]] tags.
** Any non-taggable format or format supported by FFmpeg can store RG values in a database or external tag with a component.
** A separate function can be invoked to apply the tagged Track or Album Gain to the global gain fields in MP3, AAC (in container), or Opus files, and rewrite any existing tags to account for the peak change and compensate for the difference from 89&nbsp;dB. The 89&nbsp;dB reference level for tags isn't configurable, but the reference level applied to the global gain fields is.
** Can automatically copy Track or Album gain values to Apple's SoundCheck tag in MP4 files or any format that supports ID3v2 to effectively add ReplayGain support to Apple's players.
* https://foobar2000.org/
* https://foobar2000.org/


Latest revision as of 13:31, 23 January 2026

ReplayGain is the name of a technique invented to achieve the same perceived playback loudness of audio files. It defines an algorithm to measure the perceived loudness of audio data.

ReplayGain allows the loudness of each song within a collection of songs to be consistent. This is called 'Track Gain' (or 'Radio Gain' in earlier parlance). It also allows the loudness of a specific sub-collection (an "album") to be consistent with the rest of the collection, while allowing the dynamics from song to song on the album to remain intact. This is called 'Album Gain' (or 'Audiophile Gain' in earlier parlance). This is especially important when listening to classical music albums, because quiet tracks need to remain a certain degree quieter than the louder ones.

ReplayGain is different from peak normalization. Peak normalization merely ensures that the peak amplitude reaches a certain level. This does not ensure equal loudness. The ReplayGain technique measures the effective power of the waveform (i.e. the RMS power after applying an "equal loudness contour"), and then adjusts the amplitude of the waveform accordingly. The result is that Replay Gained waveforms are usually more uniformly amplified than peak-normalized waveforms.

Target loudness

The target loudness of ReplayGain is 89 dB SPL / -18 LUFS (Loudness Units relative to Full Scale).

Some utilities have realized the inadequacies of the classic ReplayGain loudness calculation, switching to a more modern algorithm (ITU-R BS.1770). However, the way it was integrated was extremely ad hoc, at least until a draft of a revised specification started being written.

Clipping

Audio is generally recorded such that the loudest sounds don't clip, but the use of ReplayGain can cause clipping if the average volume of a song is below the target level. That is, upon playback, the volume of a quiet song is increased, so the parts of the song with above-average loudness, especially in the bass frequencies, will exceed the limits of the format and will be distorted. Whether this distortion is audible depends on the sounds in question, and the listener's sensitivity.

Implementations deal with the risk of clipping in different ways. Some have a "pre-amp" feature which reduces (or boosts) the original audio's level by a certain amount before doing whatever is needed for ReplayGain. Some have a "prevent clipping" feature to reduce the amount of ReplayGain adjustment to whatever amount would keep clipping from occurring, based on peak info stored in the file's metadata (thus reducing the effectiveness of ReplayGain). Some recommend using a compressor/limiter DSP to prevent or reduce clipping, regardless of whether it was caused by ReplayGain.

An alternative that may reduce the risk of clipping is the EBU R 128 recommendation of a -23 LUFS target, but that's a different standard, and some may find the additional reduction in volume excessive, particularly if it leads to maxing out volume on user hardware. Opus in particular has adopted that standard, using a global gain as well as R128_TRACK_GAIN / R128_ALBUM_GAIN tags. With ReplayGain, a simple (though somewhat radical) solution is to lower the preamp value by 5 dB (or whatever one feels comfortable with) in the playback software. The RG target will always be -18 LUFS, regardless of a user's volume or preamp settings.

Implementations

There are different ReplayGain implementations, each with its own uses and strength. Most use metadata to indicate the level of the volume change that the player should make. Some modify the audio data itself, and optionally use metadata as well. There are advantages and disadvantages to both methods.

In the metadata method, information on both types of ReplayGain (Track Gain and Album Gain) can be stored. The volume-change information can be very precise. If audio data was also changed, the metadata can contain "undo" info. Not all audio players/decoders know how to read and use ReplayGain information stored in metadata. And there's no standard for where and how ReplayGain info is stored; each implementation uses different formats and puts the info in different locations.

In the audio data method, the file's actual audio data is modified so that its natural/default playback volume is at the target level. In this scenario, only one type of ReplayGain (Track Gain or Album Gain) can be applied. If no "undo" info is saved somewhere, it may not be possible to restore the original audio data. Limitations of the audio file format may prevent precise (finely tuned) gain adjustments with this method. For example, MP3 and AAC files can only be losslessly modified in 1.5 dB steps. Depending on the audio file format, the process may also be lossy in the sense that it could irreversibly push a signal above the format's maximum amplitude (resulting in clipping) or below the minimum (resulting in silence).

Old versus new algorithms

Since the ReplayGain standard does not define tags to specify which algorithm was used (classic or ITU-R BS.1770) or what target was set (RG's -18 LUFS, EBU R 128's -23 LUFS, or any other target set by the user or some piece of software), there may be confusion as to how the results were produced. Typically, utilities that ship with reference encoders (FLAC / metaflac, Vorbis / vorbisgain, WavPack / wvgain, Musepack / mpcgain…) use the original RG algorithm, which can produce values that differ from newer tools by several decibels in certain cases. Generally speaking, it is recommended to run other utilities or players that implement the ITU-R BS.1770 algorithm, although it may not be obvious which algorithm they use at first glance. Their documentation may provide that information.

RG1, RG2

Although there are many references online, and within ReplayGain scanners, about version 1 vs. version 2 of the ReplayGain standard, at the time of writing this, there is (admittedly) only one ReplayGain standard. The core principle, as well as the 4 tags from the original specification, have not changed. More tags have been proposed but they are still subject to debate. As a rule of thumb, tools that advertise "ReplayGain 2" compliance employ the newer, more accurate ITU-R BS.1770 algorithm. foobar2000 labels it "EBU R128" but it essentially means the same thing. Should a better algorithm be developed in the future, it will still work towards fulfilling ReplayGain's original goals, and probably write the same tags.

MP3Gain

MP3Gain is an implementation of classic ReplayGain. It can be used to just analyze files & recommend changes or to also modify the gain. If modifying the gain, it always modifies the global gain fields in the MP3 audio data. It can add somewhat precise metadata, including undo info. The gain can be modified to any target dB, or it can be changed by a specified amount. For balance correction, user-specified changes can even be made on just one channel in simple L/R stereo-mode files (not joint stereo).

  • Format: MP3
  • Method: Audio + Meta (in APE tag), or Audio only
  • APE tag fields (ASCII bytes):
    • MP3GAIN_MINMAX ###,### - minimum & maximum global gain values for this file. 3 digits, zero-padded if necessary.
    • MP3GAIN_ALBUM_MINMAX ###,### - minimum & maximum global gain values across a set of files scanned as an album. Optional.
    • MP3GAIN_UNDO +###,+###,N - the global gain adjustment to restore the original values in the left and right channels, respectively, followed by an indicator of whether to wrap at the extremes (N means no, W means yes). The adjustment values are 3 digits, zero-padded, preceded by a sign (+ or -).
    • REPLAYGAIN_TRACK_GAIN +#.###### dB - The value is always 9 characters including the sign and decimal point. Examples: +0.424046 and -10.38500
    • REPLAYGAIN_TRACK_PEAK #.###### dB - The value is always 8 characters including the decimal point. Example: 0.149923
    • REPLAYGAIN_ALBUM_GAIN +#.###### dB - The value is always 9 characters including the sign and decimal point. Optional.
    • REPLAYGAIN_ALBUM_PEAK #.###### dB - The value is always 8 characters including the decimal point. Optional.
  • Limitations: Although the metadata, if written, contains precise adjustment & peak values, the audio data modifications are limited to 1.5dB steps and may become irreversible (however, that's a very rare condition; see the "mp3gain is NOT lossless" forum thread)
  • http://mp3gain.sourceforge.net/

AACGain

AACGain is a modified version of MP3Gain that works on both MP3 and AAC files.

  • Format: MP3, AAC (with or without MP4 container)
  • Method: Audio + Meta, or Audio only
  • Limitations: Limited to 1.5dB steps mode, may become irreversible (same caveat as for MP3Gain)
  • http://aacgain.altosdesign.com/

LAME

Musepack ReplayGain

  • Method: Header (similar to Meta data method)
  • Notes: Uses the classic RG algorithm. ReplayGain values are stored in the header and ReplayGain is part of the Musepack specifications; therefore any Musepack decoder that does not support ReplayGain can be considered broken.
  • http://www.musepack.net/

VorbisGain

Note: Andavari has provided a very useful script to integrate VorbisGain, which is a CLI tool, into Windows Explorer. Please (Ogg) check this section.

FLAC / METAFLAC

WavPack / WVGAIN

Wavegain

MusicPlayer

  • Custom implementation, inspired by MP3Gain.
  • Format: any that FFmpeg supports
  • Method: Audio
  • Limitations: Doesn't modify the files at all. Stores the value in own database. Used only for playback.
  • https://github.com/albertz/music-player

foobar2000 ReplayGain scanner

  • Since v1.1.6, defaults to ITU-R BS.1770 analysis (although it labels it EBU R128), but can be configured to use the "Classic ReplayGain" algorithm instead. The ITU-R BS.1770 implementation uses a reference level of -18 LUFS instead of -23, in order to retain compatibility with the ReplayGain standard.
  • Format:
    • MP3: Values written to ID3v2 (default) or APEv2 tags.
    • Musepack: Values written to header.
    • (Ogg) Vorbis: Values written to Vorbis comment.
    • Opus: Values written to Vorbis comment and/or file header.
    • WavPack: Values written to APEv2 tags.
    • AAC: Values written to APEv2 tags
    • MP4 (AAC, ALAC, MP3): Uses its own iTunes-compatible tagging system (though iTunes does not support ReplayGain).
    • FLAC: Values written to Vorbis comment.
    • APE: Values written to APEv2 tags.
    • TAK: Values written to APEv2 tags.
    • TTA: Values written to APEv2 or ID3v2 tags.
    • WMA: Values written to WMA tags.
    • WAV: Values written to ID3 chunk.
    • AIFF: Values written to ID3 chunk.
    • Matroska: Values written to container tags.
    • Modules (MOD etc.): Optionally saved into APEv2 tags.
    • Any non-taggable format or format supported by FFmpeg can store RG values in a database or external tag with a component.
    • A separate function can be invoked to apply the tagged Track or Album Gain to the global gain fields in MP3, AAC (in container), or Opus files, and rewrite any existing tags to account for the peak change and compensate for the difference from 89 dB. The 89 dB reference level for tags isn't configurable, but the reference level applied to the global gain fields is.
    • Can automatically copy Track or Album gain values to Apple's SoundCheck tag in MP4 files or any format that supports ID3v2 to effectively add ReplayGain support to Apple's players.
  • https://foobar2000.org/

MediaMonkey

  • Format:
  • In addition to tags, all ReplayGain values are also stored in MediaMonkey's MDB database
  • Album/Audiophile ReplayGain not supported until v3.0 (Dec 2007); support during burning & ripping added in 3.1 (Jun 2009)
  • Also capable of (irreversibly) changing the volume of MP3 tracks, similar to MP3Gain
  • http://www.mediamonkey.com/

Winamp ReplayGain scanner

loudgain

  • Format:
    • FLAC: Values written to Vorbis comment.
    • MP2, MP3: Values written to ID3v2 tags (ID3v2.3/ID3v2.4 selectable).
    • (Ogg) Vorbis: Values written to Vorbis comment.
    • (Ogg) FLAC: Values written to Vorbis comment.
    • (Ogg) Speex: Values written to Vorbis comment.
    • Opus: Values written to Vorbis comment, based on -23 LUFS Opus standard. Only R128_TRACK_GAIN and R128_ALBUM_GAIN are written, but the calculated true peak value can still be used to reduce the gain values (Clipping prevention).
    • MP4, M4A: Uses its own iTunes-compatible tagging system (though iTunes does not support ReplayGain). ReplayGain values are stored under ----:com.apple.iTunes:…. This is for AAC and ALAC in MPEG-4 containers.
    • ASF, WMA: Values written to WMA tags, no prefix.
    • WAV: Values written to the ID3 chunk, in ID3v2 (ID3v2.3/ID3v2.4 selectable) format. Using the bext chunk (for BWF v2) isn’t (yet) supported, but won’t be destroyed on writing.
    • AIFF: Values written to the ID3 chunk, in ID3v2 format.
    • WavPack: Values written to APEv2 tags.
    • Monkey's Audio (APE): Values written to APEv2 tags.
  • Follows EBU R128, ITU BS.1770 and the revised ReplayGain specification.
  • Never touches the actual audio data but only writes RG2 tags.
  • Uses true peak values calculated by oversampling to 192 kHz, using a custom polyphase FIR interpolator that will oversample 4x for sample rates < 96 kHz, 2x for sample rates < 192 kHz and leave the signal unchanged for 192 kHz.
  • Clipping prevention can be used to lower the ReplayGain values to a safe margin (default -1 dBTP, can be changed).
  • Many options for special cases: force RG tags upper-/lowercase, add extra tags (LRA, Reference loudness), strip unwanted tag types (APEv2 from MP2/MP3, ID3 from WavPack), tab-delimited table output for analysis with CSV file.
  • Linux Free and Open Source software, can be installed on MacOS using HomeBrew, on Windows 10 using the Linux bash.
  • Also installs a rgbpm bash script for mass-tagging, which can be adapted to the user’s needs.
  • Warning: Loudgain relies on standard libraries like TagLib. Linux distros (except rolling releases) sometimes deliver outdated libraries, so be sure you use the latest version of TagLib. Version 1.11.1 had a nasty bug for a while that could corrupt Ogg Vorbis files. This has been fixed in the meantime but the TagLib version not updated. Loudgain comes with a (slower) static version called loudgain.static in the repo’s /bin folder that doesn’t expose the bug and can also be used on older Linux versions (like Ubuntu 14.04, Linux Mint 17).
  • https://github.com/Moonbase59/loudgain
  • Bug tracker: https://github.com/Moonbase59/loudgain/issues

rsgain

rsgain is a newer ReplayGain command line utility designed with a "batteries included" philosophy, use the newer ITU-R BS.1770 algorithm.

Features:

  • Cross-platform Windows / macOS / Linux
  • Supports all popular audio formats
  • Simplified "Easy Mode" command line syntax supports recursive, directory-based scanning
  • Multithreaded scanning option that provides significant speed improvement with full library scans
  • Option to skip files with existing ReplayGain metadata
  • Scan presets allow the user to save advanced settings for consistent use

Players support

ReplayGain being present in the specs of the FLAC, Musepack, and APE formats, any player that support those formats usually supports ReplayGain.

The situation with MP3 is rather different, as it was not part of the MP3 specs. The APEv2 tags metadata implementation is somewhat becoming the de-facto standard.

Windows

  • foobar2000 supports ReplayGain in all possible aspects.
  • Winamp supports ReplayGain in album or track mode.
  • MediaMonkey supports ReplayGain, with many configuration options.
  • XMPlay recently implemented ReplayGain
  • MusicBrainz Picard is a tagger (and player) that tags using metadata from the MusicBrainz.org database. Picard supports ReplayGain tags for files tagged with APE, ASF, ID3, MP4 and Vorbis tags. There is a ReplayGain plugin that can be used to calculate the ReplayGain values for both Albums and Tracks.

...and probably others.

Linux

For MP3, use the CVS version of the xmms-mad mp3 plugin (it's not yet released as binary, furthermore not available in distribs' versions for now. Meanwhile binaries are available here: custom binaries)
And possibly others, since TagLib added support for APEv2 tags in MP3 files, players using this library (like amaroK and JuK) might support that kind of ReplayGain tags in the near future.
Requires support to be enabled (via the appropriate python bindings and libraries) for the above formats. Does not support ReplayGain values stored in APEv2 tags in MP3s. ReplayGain values are stored in RVA2 id3v2.4 frames. See the Quod Libet RVA2 / ReplayGain notes.
foobar2000-style TXXX frames in MP3s are also supported in the latest development releases.
  • MPlayer. Mplayer support for ReplayGain is codec dependent.
Codecs that are known to support ReplayGain: vorbis
Because of this, you need to prioritize the codecs that support it, or choose it individually on the command line. To add it to the command line, add an -ac [codec] option after each file that you want to choose the codec for, or at the beginning to make it apply to all files listed. To prioritize the codecs by default, list them in a line in mplayer.conf:
ac=[codec],[othercodec],vorbis,mad,
  • IDJC (Internet DJ Console) reads ReplayGain from FLAC, (Ogg) FLAC, (Ogg) Vorbis, MP2 (audio), MP3, Opus, but only the lowercase tags. There is a ticket open to handle tags case-insensitively.
  • MusicBrainz Picard is a tagger (and player) that tags using metadata from the MusicBrainz.org database. Picard supports ReplayGain tags for files tagged with APE, ASF, ID3, MP4 and Vorbis tags. There is a ReplayGain plugin that can be used to calculate the ReplayGain values for both Albums and Tracks.
  • VLC supports ReplayGain in many file formats, but usually only the uppercase variant of the tags.
  • KODI reads ReplayGain from nearly all formats, but usually only the lowercase variant of the tags.

Portable devices

Rockbox supports ReplayGain (in album or track mode) for most formats, including WMA, MP1/2/3, AAC, ALAC, Musepack, Monkey's Audio, Wavpack, FLAC and Vorbis.
Note that ReplayGain is only supported when using the respective codec's native tagging format. For example: ReplayGain stored in APEv2 tags is not supported for MP3, rather ID3v2.x tags are expected.

Sandisk Sansa Fuze with firmware 1.02.26 and 2.02.26

Sandisk Sansa Clip+

The iPod features Soundcheck, which seems to produce roughly the same normalization gains as ReplayGain, but doesn't provide an Album Gain.

Hi-Fi

Slim Devices, a company owned by Logitech Inc, supports ReplayGain on both of their hi-end audiophile players, known as the Transporter and the Squeezebox.

BluOS also supports ReplayGain with the selection of album- or track-gain and a so called Smart option that decides between the two by itself. NAD devices that use BluOS consequently also support ReplayGain.

Notes

See also


index.php?title=Category:Technical index.php?title=Category:Metadata

Retrieved from "https://wiki.hydrogenaudio.org/index.php?title=ReplayGain&oldid=38811"