Original ReplayGain specification - Revision history

Skamp at 20:27, 22 January 2026

2026-01-22T20:27:50Z

← Older revision		Revision as of 20:27, 22 January 2026
Line 139:		Line 139:
	The audio industry does not have a standard for playback system calibration, but in the movie industry a calibration standard has been defined by the Society of Motion Picture and Television Engineers (SMPTE).<ref>SMPTE RP 200:2002 – Relative and Absolute Sound Pressure Levels for Motion-Picture Multichannel Sound Systems – Applicable for Analog Photographic Film Audio, Digital Photographic Film Audio and D-Cinema</ref> The standard states that a single channel pink noise signal with an RMS level of -20 dB relative to a full-scale sinusoid<ref>"dB relative to a full-scale sinusoid" is preferred over "dBFS" as a unit of measure in this specification because there is some ambiguity whether the reference for dBFS is a full-scale square wave (peak reference) or a sine wave (RMS reference).</ref> should be reproduced at 83 dB SPL.<ref>Measured using a C-weighted, slow averaging SPL meter.</ref>		The audio industry does not have a standard for playback system calibration, but in the movie industry a calibration standard has been defined by the Society of Motion Picture and Television Engineers (SMPTE).<ref>SMPTE RP 200:2002 – Relative and Absolute Sound Pressure Levels for Motion-Picture Multichannel Sound Systems – Applicable for Analog Photographic Film Audio, Digital Photographic Film Audio and D-Cinema</ref> The standard states that a single channel pink noise signal with an RMS level of -20 dB relative to a full-scale sinusoid<ref>"dB relative to a full-scale sinusoid" is preferred over "dBFS" as a unit of measure in this specification because there is some ambiguity whether the reference for dBFS is a full-scale square wave (peak reference) or a sine wave (RMS reference).</ref> should be reproduced at 83 dB SPL.<ref>Measured using a C-weighted, slow averaging SPL meter.</ref>

	ReplayGain adapts the SMPTE calibration concept for music playback. Under ReplayGain, audio is played so that its loudness, as measured using the procedures described in [[#Loudness measurement\|Loudness measurement]] above, matches the loudness of a pink noise signal with an RMS level of -14 dB relative to a full-scale sinusoid,<ref>The initial ReplayGain proposal used the same -20 dB reference used by SMPTE. The reference was raised to -14 dB early on in ReplayGain development. This reference is used in all current ReplayGain implementations.</ref> also measured using the procedures described above.		ReplayGain adapts the SMPTE calibration concept for music playback. Under ReplayGain, audio is played so that its loudness, as measured using the procedures described in [[Original ReplayGain specification#Loudness measurement\|Loudness measurement]] above, matches the loudness of a pink noise signal with an RMS level of -14 dB relative to a full-scale sinusoid,<ref>The initial ReplayGain proposal used the same -20 dB reference used by SMPTE. The reference was raised to -14 dB early on in ReplayGain development. This reference is used in all current ReplayGain implementations.</ref> also measured using the procedures described above.

	In ReplayGain implementations, the reference level is described in terms of the SMPTE SPL playback level. By the SMPTE definition, the 83 dB SPL reference corresponds to -20FS dB system headroom. The -14 dB headroom used by ReplayGain therefore corresponds to an 89 dB SPL playback level on a SMPTE calibrated system and so is said to be operating with an 89 dB reference level.		In ReplayGain implementations, the reference level is described in terms of the SMPTE SPL playback level. By the SMPTE definition, the 83 dB SPL reference corresponds to -20FS dB system headroom. The -14 dB headroom used by ReplayGain therefore corresponds to an 89 dB SPL playback level on a SMPTE calibrated system and so is said to be operating with an 89 dB reference level.
Line 153:		Line 153:
	:<math>L</math> is the measured loudness of the audio file.		:<math>L</math> is the measured loudness of the audio file.

	Replay gain is positive if the loudness of the audio file is lower than the pink noise reference. The gain is negative (representing an attenuation) if the loudness of the audio file is higher than that of the reference. The gain is stored as metadata with the audio file as described below and is used by players to adjust output volume of tracks as they are played as described in [[#Player requirements\|Player requirements]] below.		Replay gain is positive if the loudness of the audio file is lower than the pink noise reference. The gain is negative (representing an attenuation) if the loudness of the audio file is higher than that of the reference. The gain is stored as metadata with the audio file as described below and is used by players to adjust output volume of tracks as they are played as described in [[Original ReplayGain specification#Player requirements\|Player requirements]] below.

	==Metadata==		==Metadata==
Line 197:		Line 197:
	The ID3v2 standard<ref>The ID3v2 format is explained at [http://www.id3.org/ www.id3.org]. The most useful document is the [http://www.id3.org/id3v2.3.0.html ID3v2 v2.3.0 standard]. Although this document has been superseded by v2.4.0, the earlier document is complete (rather than an update), and in indexed HTML form. As such, it represents a better technical introduction to ID3v2.</ref> defines a ''tag'' which is situated before the data in an MP3 file.<ref>The original ID3 (v1) tags resided at the end of the file, and contained a few fields of information. The ID3v1 tag is not extensible and therefore cannot support ReplayGain metadata.</ref> ID3 is used primarily with MP3 audio files but means of adapting the system to other file types have been developed.		The ID3v2 standard<ref>The ID3v2 format is explained at [http://www.id3.org/ www.id3.org]. The most useful document is the [http://www.id3.org/id3v2.3.0.html ID3v2 v2.3.0 standard]. Although this document has been superseded by v2.4.0, the earlier document is complete (rather than an update), and in indexed HTML form. As such, it represents a better technical introduction to ID3v2.</ref> defines a ''tag'' which is situated before the data in an MP3 file.<ref>The original ID3 (v1) tags resided at the end of the file, and contained a few fields of information. The ID3v1 tag is not extensible and therefore cannot support ReplayGain metadata.</ref> ID3 is used primarily with MP3 audio files but means of adapting the system to other file types have been developed.

	The ID3v2 tag is divided into ''frames''. The preferred means of storing ReplayGain metadata is use of ''TXXX'' key/value pair frames. Two other legacy schemes for storing ReplayGain metadata exist: [[~~ReplayGain_legacy_metadata_formats~~#~~ID3v2_RGAD~~\|RGAD]] and [[~~ReplayGain_legacy_metadata_formats~~#~~ID3v2_RVA2~~\|RVA2]]. These formats are documented in the [[ReplayGain legacy metadata formats\|appendix]]. Players may choose to look for these formats if metadata in the ''TXXX'' format is not found in the ID3v2 tag. New scanners may write these older formats in addition to the newer (TXXX) ones if they wish to remain backwards compatible with older players.		The ID3v2 tag is divided into ''frames''. The preferred means of storing ReplayGain metadata is use of ''TXXX'' key/value pair frames. Two other legacy schemes for storing ReplayGain metadata exist: [[ReplayGain legacy metadata formats#ID3v2 RGAD\|RGAD]] and [[ReplayGain legacy metadata formats#ID3v2 RVA2\|RVA2]]. These formats are documented in the [[ReplayGain legacy metadata formats\|appendix]]. Players may choose to look for these formats if metadata in the ''TXXX'' format is not found in the ID3v2 tag. New scanners may write these older formats in addition to the newer (TXXX) ones if they wish to remain backwards compatible with older players.

	ReplayGain uses four TXXX frames. The header of a TXXX frame is coded as follows:		ReplayGain uses four TXXX frames. The header of a TXXX frame is coded as follows:
Line 273:		Line 273:
	Although the calibration level used by ReplayGain suggests that the average level of an audio track should be 14 dB below full scale, some pop music is dynamically compressed to peak at 0 dB and average around 3 dB below full scale. This means that, when the replay gain is applied, the level of such tracks will be reduced by 11 dB! If users are listening to a mixture of highly compressed and more dynamic tracks, ReplayGain will make the listening experience more pleasurable by bringing the level of the compressed tracks down into line with that of the others. However, if users are only listening to highly compressed music, then they may complain that all their files are now too quiet.<ref>This problem can be especially noticeable on portable players with limited output or gain.</ref>		Although the calibration level used by ReplayGain suggests that the average level of an audio track should be 14 dB below full scale, some pop music is dynamically compressed to peak at 0 dB and average around 3 dB below full scale. This means that, when the replay gain is applied, the level of such tracks will be reduced by 11 dB! If users are listening to a mixture of highly compressed and more dynamic tracks, ReplayGain will make the listening experience more pleasurable by bringing the level of the compressed tracks down into line with that of the others. However, if users are only listening to highly compressed music, then they may complain that all their files are now too quiet.<ref>This problem can be especially noticeable on portable players with limited output or gain.</ref>

	To address this problem, a pre-amp feature should be incorporated into the player. A user-supplied pre-amp setting is an adjustment to the calculated replay gain. It should default to perform no adjustment. This means that casual users will experience a moderate reduction in the loudness of their compressed pop music. Less-compressed material can generally be played at the same loudness without clipping. Normalization of more dynamic material may cause clipping or invoke the [[#Clipping prevention\|clipping prevention]] mechanism (see below). Power users and audiophiles can reduce the pre-amp gain to enjoy the full dynamic range of all of their music.		To address this problem, a pre-amp feature should be incorporated into the player. A user-supplied pre-amp setting is an adjustment to the calculated replay gain. It should default to perform no adjustment. This means that casual users will experience a moderate reduction in the loudness of their compressed pop music. Less-compressed material can generally be played at the same loudness without clipping. Normalization of more dynamic material may cause clipping or invoke the [[Original ReplayGain specification#Clipping prevention\|clipping prevention]] mechanism (see below). Power users and audiophiles can reduce the pre-amp gain to enjoy the full dynamic range of all of their music.

	If enabled, the player should read the user selected pre-amp gain, and scale the audio signal by the appropriate amount. For example, a +6 dB gain requires a scale of 10<sup>6/20</sup>, which is approximately 2. The replay gain and pre-amp scale factors can be combined<ref>Scale factors in Decibel units are added to produce the same effect as multiplying scale factors in linear units.</ref> for simplicity and ease of processing.		If enabled, the player should read the user selected pre-amp gain, and scale the audio signal by the appropriate amount. For example, a +6 dB gain requires a scale of 10<sup>6/20</sup>, which is approximately 2. The replay gain and pre-amp scale factors can be combined<ref>Scale factors in Decibel units are added to produce the same effect as multiplying scale factors in linear units.</ref> for simplicity and ease of processing.
Line 319:		Line 319:
	== See also ==		== See also ==
	: ''This is not a normative part of the specification.''		: ''This is not a normative part of the specification.''
	* [[ReplayGain ~~2.0~~ specification]] (draft)		* [[Revised ReplayGain specification]] (draft)

Skamp: Skamp moved page ReplayGain 1.0 specification to Original ReplayGain specification: Confusion about having two distinct, numbered versions of ReplayGain

2026-01-22T19:29:14Z

Skamp moved page ReplayGain 1.0 specification to Original ReplayGain specification: Confusion about having two distinct, numbered versions of ReplayGain

← Older revision	Revision as of 19:29, 22 January 2026
(No difference)

Artoria2e5: link to ReplayGain 2.0 specification

2023-08-03T14:37:09Z

link to ReplayGain 2.0 specification

← Older revision		Revision as of 14:37, 3 August 2023
Line 316:		Line 316:
	==Notes==		==Notes==
	<references />		<references />

			== See also ==
			: ''This is not a normative part of the specification.''
			* [[ReplayGain 2.0 specification]] (draft)

Danlock: /* Vorbis comments */ inserted missing character; b -> be

2018-11-19T17:37:30Z

Vorbis comments: inserted missing character; b -> be

← Older revision		Revision as of 17:37, 19 November 2018
Line 251:		Line 251:

	===Vorbis comments===		===Vorbis comments===
	A Vorbis comment<ref>[http://www.xiph.org/vorbis/doc/v-comment.html Vorbis comment metadata format]. ReplayGain metadata is documented on the [http://wiki.xiph.org/VorbisComment#Replay_Gain Xiph Wiki].</ref> uses an ASCII <tt>key=value</tt> format. When Vorbis comments are used, the four ReplayGain metadata items are stored as separate comments. The ''keys'' and formatting for ''values'' is the same as specified for ID3v2. Keys and values are required by the Vorbis comment specification to b separated by '=' (equal character).		A Vorbis comment<ref>[http://www.xiph.org/vorbis/doc/v-comment.html Vorbis comment metadata format]. ReplayGain metadata is documented on the [http://wiki.xiph.org/VorbisComment#Replay_Gain Xiph Wiki].</ref> uses an ASCII <tt>key=value</tt> format. When Vorbis comments are used, the four ReplayGain metadata items are stored as separate comments. The ''keys'' and formatting for ''values'' is the same as specified for ID3v2. Keys and values are required by the Vorbis comment specification to be separated by '=' (equal character).

	===APEv2===		===APEv2===

24.9.121.93: /* Loudness normalization */

2017-12-19T04:09:45Z

Loudness normalization

← Older revision		Revision as of 04:09, 19 December 2017
Line 266:		Line 266:
	:<math>10^\frac{gain}{20}</math>		:<math>10^\frac{gain}{20}</math>

	Or, in words, ~~replay gain divided by 20 all~~ raised to the power of ~~ten~~.<ref> After any such operation, it's a good idea to dither the result. If this calculation and the pre-amp are implemented separately, then dither should only be added to the final result, just before the result is truncated back to 16 bits, or 24, or 8, as limited by the soundcard—not the file (i.e. after ReplayGain adjustment, an 8-bit file should be sent to a 16-bit soundcard at 16-bits).</ref>		Or, in words, ten raised to the power of one-twentieth of replay gain.<ref> After any such operation, it's a good idea to dither the result. If this calculation and the pre-amp are implemented separately, then dither should only be added to the final result, just before the result is truncated back to 16 bits, or 24, or 8, as limited by the soundcard—not the file (i.e. after ReplayGain adjustment, an 8-bit file should be sent to a 16-bit soundcard at 16-bits).</ref>

	If the file only contains one of the replay gain adjustments (e.g. Album) but the user has requested the other (Track), then the player should use the one that is available (in this case, Album). If neither (Track or Album) gain metadata is available, then the player needs to choose a suitable default gain. Potential choices include unity gain (0 dB) or an average of gains from other tracks in the album or playlist.		If the file only contains one of the replay gain adjustments (e.g. Album) but the user has requested the other (Track), then the player should use the one that is available (in this case, Album). If neither (Track or Album) gain metadata is available, then the player needs to choose a suitable default gain. Potential choices include unity gain (0 dB) or an average of gains from other tracks in the album or playlist.

24.9.121.93: /* Loudness normalization */

2017-12-19T04:08:49Z

Loudness normalization

← Older revision		Revision as of 04:08, 19 December 2017
Line 266:		Line 266:
	:<math>10^\frac{gain}{20}</math>		:<math>10^\frac{gain}{20}</math>

	Or, in words, replay gain divided by 20 all raised to the power of ten.<ref> ~~(Clarification needed: That's not what the above mathematical expression says.)~~ After any such operation, it's a good idea to dither the result. If this calculation and the pre-amp are implemented separately, then dither should only be added to the final result, just before the result is truncated back to 16 bits, or 24, or 8, as limited by the soundcard—not the file (i.e. after ReplayGain adjustment, an 8-bit file should be sent to a 16-bit soundcard at 16-bits).</ref>		Or, in words, replay gain divided by 20 all raised to the power of ten.<ref> After any such operation, it's a good idea to dither the result. If this calculation and the pre-amp are implemented separately, then dither should only be added to the final result, just before the result is truncated back to 16 bits, or 24, or 8, as limited by the soundcard—not the file (i.e. after ReplayGain adjustment, an 8-bit file should be sent to a 16-bit soundcard at 16-bits).</ref>

	If the file only contains one of the replay gain adjustments (e.g. Album) but the user has requested the other (Track), then the player should use the one that is available (in this case, Album). If neither (Track or Album) gain metadata is available, then the player needs to choose a suitable default gain. Potential choices include unity gain (0 dB) or an average of gains from other tracks in the album or playlist.		If the file only contains one of the replay gain adjustments (e.g. Album) but the user has requested the other (Track), then the player should use the one that is available (in this case, Album). If neither (Track or Album) gain metadata is available, then the player needs to choose a suitable default gain. Potential choices include unity gain (0 dB) or an average of gains from other tracks in the album or playlist.

24.9.121.93: /* Loudness normalization */

2017-12-19T03:30:14Z

Loudness normalization

← Older revision		Revision as of 03:30, 19 December 2017
Line 266:		Line 266:
	:<math>10^\frac{gain}{20}</math>		:<math>10^\frac{gain}{20}</math>

	Or, in words, replay gain divided by 20 all raised to the power of ten.<ref>After any such operation, it's a good idea to dither the result. If this calculation and the pre-amp are implemented separately, then dither should only be added to the final result, just before the result is truncated back to 16 bits, or 24, or 8, as limited by the soundcard—not the file (i.e. after ReplayGain adjustment, an 8-bit file should be sent to a 16-bit soundcard at 16-bits).</ref>		Or, in words, replay gain divided by 20 all raised to the power of ten.<ref> (Clarification needed: That's not what the above mathematical expression says.) After any such operation, it's a good idea to dither the result. If this calculation and the pre-amp are implemented separately, then dither should only be added to the final result, just before the result is truncated back to 16 bits, or 24, or 8, as limited by the soundcard—not the file (i.e. after ReplayGain adjustment, an 8-bit file should be sent to a 16-bit soundcard at 16-bits).</ref>

	If the file only contains one of the replay gain adjustments (e.g. Album) but the user has requested the other (Track), then the player should use the one that is available (in this case, Album). If neither (Track or Album) gain metadata is available, then the player needs to choose a suitable default gain. Potential choices include unity gain (0 dB) or an average of gains from other tracks in the album or playlist.		If the file only contains one of the replay gain adjustments (e.g. Album) but the user has requested the other (Track), then the player should use the one that is available (in this case, Album). If neither (Track or Album) gain metadata is available, then the player needs to choose a suitable default gain. Potential choices include unity gain (0 dB) or an average of gains from other tracks in the album or playlist.

Notat: /* Metadata format */ bold format for WMA

2014-05-27T00:20:31Z

Metadata format: bold format for WMA

← Older revision		Revision as of 00:20, 27 May 2014
Line 190:		Line 190:
	* .ogg (Ogg Vorbis) – '''Vorbis comments'''		* .ogg (Ogg Vorbis) – '''Vorbis comments'''
	* .tta (True Audio) – '''ID3v2''', '''APEv2'''		* .tta (True Audio) – '''ID3v2''', '''APEv2'''
	* .wma (Windows Media audio) - In Extended Content Description Object~~, Vorbis Comment ASCII values~~		* .wma (Windows Media audio) - '''Vorbis comments''' in Extended Content Description Object
	* .wav (Windows PCM) – No metadata support (use .bwf instead)		* .wav (Windows PCM) – No metadata support (use .bwf instead)
	* .wv (WavePak) – '''APEv2'''		* .wv (WavePak) – '''APEv2'''

Notat: revert some non-clarifying changes

2014-05-27T00:17:40Z

revert some non-clarifying changes

← Older revision		Revision as of 00:17, 27 May 2014
Line 17:		Line 17:
	[[File:RG_IIR-filter.png\|frame\|Figure 2: IIR filter topology used by "yulewalk" and Butterworth filter components]]		[[File:RG_IIR-filter.png\|frame\|Figure 2: IIR filter topology used by "yulewalk" and Butterworth filter components]]

	The ~~[http://en.wikipedia.org/wiki/Digital_filter Direct Form I~~ filter] topology is used for the components of the loudness filter as shown in figure 2. The filter coefficients for 48 and 44.1 kHz sample rates are given for the Butterworth and "yulewalk" components in tables 1 and 2 respectively. When using other sample rates, coefficients must be transformed to maintain the same filter response~~. Note: the values for the recursive terms, a(n), are shown in the table and diagram with the signs reversed relative to convention~~.		The filter topology used for the components of the loudness filter is shown in figure 2. The filter coefficients for 48 and 44.1 kHz sample rates are given for the Butterworth and "yulewalk" components in tables 1 and 2 respectively. When using other sample rates, coefficients must be transformed to maintain the same filter response.

	{\| class="wikitable" style="text-align:center"		{\| class="wikitable" style="text-align:center"
Line 185:		Line 185:
	* .bwf (Broadcast Wave Format) – '''ID3v2''' (in RIFF chunk)		* .bwf (Broadcast Wave Format) – '''ID3v2''' (in RIFF chunk)
	* .flac (Free Lossless Audio Codec) – '''Vorbis comments'''		* .flac (Free Lossless Audio Codec) – '''Vorbis comments'''
	* .mp3 (~~Motion or Moving Picture Expert Group)~~ MPEG audio layer 3 – '''ID3v2''', LAME VBR proposed tag specification		* .mp3 (MPEG audio layer 3) – '''ID3v2''', LAME VBR proposed tag specification
	* .mp4 also .m4a, .m4b, .m4p, m4r (MPEG-4 Part 14) – '''ID3v2''' (in "ID32" box)		* .mp4 also .m4a, .m4b, .m4p, m4r (MPEG-4 Part 14) – '''ID3v2''' (in "ID32" box)
	* .mpc (Musepack) – '''APEv2'''		* .mpc (Musepack) – '''APEv2'''

92.24.27.165: /* Metadata format */

2014-04-19T03:45:39Z

Metadata format

← Older revision		Revision as of 03:45, 19 April 2014
Line 185:		Line 185:
	* .bwf (Broadcast Wave Format) – '''ID3v2''' (in RIFF chunk)		* .bwf (Broadcast Wave Format) – '''ID3v2''' (in RIFF chunk)
	* .flac (Free Lossless Audio Codec) – '''Vorbis comments'''		* .flac (Free Lossless Audio Codec) – '''Vorbis comments'''
	* .mp3 (Motion Picture Expert Group) MPEG audio layer 3 – '''ID3v2''', LAME VBR proposed tag specification		* .mp3 (Motion or Moving Picture Expert Group) MPEG audio layer 3 – '''ID3v2''', LAME VBR proposed tag specification
	* .mp4 also .m4a, .m4b, .m4p, m4r (MPEG-4 Part 14) – '''ID3v2''' (in "ID32" box)		* .mp4 also .m4a, .m4b, .m4p, m4r (MPEG-4 Part 14) – '''ID3v2''' (in "ID32" box)
	* .mpc (Musepack) – '''APEv2'''		* .mpc (Musepack) – '''APEv2'''