ReplayGain legacy metadata formats - Revision history

130.89.165.24: /* Binary format */ endianess

2013-09-20T16:18:42Z

Binary format: endianess

← Older revision		Revision as of 16:18, 20 September 2013
Line 36:		Line 36:
	==Binary format==		==Binary format==
	To allow for future expansion: If more than three values are stored, players should ignore those they do not recognise, but process those that they do. If additional Replay Gain adjustments other than Track and Album are stored, they should come after Track and Album. The Peak Amplitude must always occupy the first 4 bytes of the Replay Gain header frame. The three values listed above (or at least fields to hold the three values, should the values themselves be unknown) are required in all Replay Gain headers.		To allow for future expansion: If more than three values are stored, players should ignore those they do not recognise, but process those that they do. If additional Replay Gain adjustments other than Track and Album are stored, they should come after Track and Album. The Peak Amplitude must always occupy the first 4 bytes of the Replay Gain header frame. The three values listed above (or at least fields to hold the three values, should the values themselves be unknown) are required in all Replay Gain headers.
			Values are stored as Big-Endian.

	====Range====		====Range====

Mjb: /* CUE Sheets */ There is no need to capitalize CUE. It's not an acronym. It really does mean cue. Sheets uncapitalized for heading consistency.

2011-02-01T01:12:03Z

CUE Sheets: There is no need to capitalize CUE. It's not an acronym. It really does mean cue. Sheets uncapitalized for heading consistency.

← Older revision		Revision as of 01:12, 1 February 2011
Line 122:		Line 122:
	Current software which supports RVA2 looks for a string "track" or "album" in the RVA2 description field (mp3gain, Quod Libet, Audacious, Mpg123). So in practice RVA2 does support a full Replay Gain implementation.		Current software which supports RVA2 looks for a string "track" or "album" in the RVA2 description field (mp3gain, Quod Libet, Audacious, Mpg123). So in practice RVA2 does support a full Replay Gain implementation.

	==~~CUE Sheets~~==		==Cue sheets==
	Foobar2000 writes ReplayGain metadata as "REM" statements in ~~CUE~~ sheets.		Foobar2000 writes ReplayGain metadata as "REM" statements in cue sheets.

	<tt>		<tt>

Notat: CUE Sheets

2011-01-31T04:01:33Z

CUE Sheets

@@ Line 121: / Line 121: @@
 ==ID3v2 RVA2==
 Current software which supports RVA2 looks for a string "track" or "album" in the RVA2 description field (mp3gain, Quod Libet, Audacious, Mpg123). So in practice RVA2 does support a full Replay Gain implementation.
 ==Notes==
 <references />

Notat: RVA2 stub

2011-01-31T03:53:24Z

RVA2 stub

← Older revision		Revision as of 03:53, 31 January 2011
Line 118:		Line 118:

	The value $xx $ff is not illegal, but it would give a false synch value within an mp3 file. The problems this may cause should be investigated, and a solution (e.g. unsychronisation) sought. Maybe this is a use for negative zero?		The value $xx $ff is not illegal, but it would give a false synch value within an mp3 file. The problems this may cause should be investigated, and a solution (e.g. unsychronisation) sought. Maybe this is a use for negative zero?

			==ID3v2 RVA2==
			Current software which supports RVA2 looks for a string "track" or "album" in the RVA2 description field (mp3gain, Quod Libet, Audacious, Mpg123). So in practice RVA2 does support a full Replay Gain implementation.

	==Notes==		==Notes==
	<references />		<references />

Notat: /* LAME tags */ correct names for #Binary format reference

2011-01-20T04:37:50Z

LAME tags: correct names for #Binary format reference

← Older revision		Revision as of 04:37, 20 January 2011
Line 8:		Line 8:
	\| 167 \|\| 4 \|\| Track peak amplitude \|\| Floating point		\| 167 \|\| 4 \|\| Track peak amplitude \|\| Floating point
	\|-		\|-
	\| 171 \|\| 2 \|\| Track ~~replay~~ gain \|\| As defined in [[#Binary format]]		\| 171 \|\| 2 \|\| Track gain adjustment \|\| As defined in [[#Binary format]]
	\|-		\|-
	\| 173 \|\| 2 \|\| Album ~~replay~~ gain \|\| As defined in [[#Binary format]]		\| 173 \|\| 2 \|\| Album gain adjustment \|\| As defined in [[#Binary format]]
	\|-		\|-
	\|}		\|}

Notat: archive

2011-01-20T04:36:54Z

Notat: add LAME tags

2011-01-20T04:34:48Z

add LAME tags

← Older revision		Revision as of 04:34, 20 January 2011
Line 1:		Line 1:
			==LAME tags==
			ReplayGain metadata is stored in bytes 167 through 175 of the [http://gabriel.mp3-tech.org/mp3infotag.html MP3 Info Tag] created by the LAME encoder.

			{\| class="wikitable"
			\|-
			! Start \|\| Length \|\| Description \|\| Format
			\|-
			\| 167 \|\| 4 \|\| Track peak amplitude \|\| Floating point
			\|-
			\| 171 \|\| 2 \|\| Track replay gain \|\| As defined in [[#Binary format]]
			\|-
			\| 173 \|\| 2 \|\| Album replay gain \|\| As defined in [[#Binary format]]
			\|-
			\|}

	==ID3v2 RGAD==		==ID3v2 RGAD==
	In the language of the ID3v2 standard document, the Replay Gain tag is thus:<ref>This tag specification is not part of any version of the ID3 specification but is [http://www.id3.org/Replay_Gain_Adjustment acknowledged] as an "in the wild" tag by the ID3 standards organization.</ref>		In the language of the ID3v2 standard document, the Replay Gain tag is thus:<ref>This tag specification is not part of any version of the ID3 specification but is [http://www.id3.org/Replay_Gain_Adjustment acknowledged] as an "in the wild" tag by the ID3 standards organization.</ref>

Notat: move RGAD

2011-01-19T03:45:55Z

move RGAD

@@ Line 1: / Line 1: @@
 ==Binary format==
 To allow for future expansion: If more than three values are stored, players should ignore those they do not recognise, but process those that they do. If additional Replay Gain adjustments other than Track and Album are stored, they should come after Track and Album. The Peak Amplitude must always occupy the first 4 bytes of the Replay Gain header frame. The three values listed above (or at least fields to hold the three values, should the values themselves be unknown) are required in all Replay Gain headers.
@@ Line 83: / Line 103: @@
 The value $xx $ff is not illegal, but it would give a false synch value within an mp3 file. The problems this may cause should be investigated, and a solution (e.g. unsychronisation) sought. Maybe this is a use for negative zero?

Notat at 03:19, 19 January 2011

2011-01-19T03:19:10Z

← Older revision		Revision as of 03:19, 19 January 2011
Line 1:		Line 1:
			==Binary format==
	To allow for future expansion: If more than three values are stored, players should ignore those they do not recognise, but process those that they do. If additional Replay Gain adjustments other than Track and Album are stored, they should come after Track and Album. The Peak Amplitude must always occupy the first 4 bytes of the Replay Gain header frame. The three values listed above (or at least fields to hold the three values, should the values themselves be unknown) are required in all Replay Gain headers.		To allow for future expansion: If more than three values are stored, players should ignore those they do not recognise, but process those that they do. If additional Replay Gain adjustments other than Track and Album are stored, they should come after Track and Album. The Peak Amplitude must always occupy the first 4 bytes of the Replay Gain header frame. The three values listed above (or at least fields to hold the three values, should the values themselves be unknown) are required in all Replay Gain headers.

Notat: stuff not meant to come over

2011-01-19T03:18:38Z

stuff not meant to come over

← Older revision		Revision as of 03:18, 19 January 2011
Line 82:		Line 82:

	The value $xx $ff is not illegal, but it would give a false synch value within an mp3 file. The problems this may cause should be investigated, and a solution (e.g. unsychronisation) sought. Maybe this is a use for negative zero?		The value $xx $ff is not illegal, but it would give a false synch value within an mp3 file. The problems this may cause should be investigated, and a solution (e.g. unsychronisation) sought. Maybe this is a use for negative zero?

	~~===Peak amplitude data format===~~
	Scanning the file for the peak amplitude can be a time-consuming process. Therefore, it's helpful if this single value is stored within the file header. This can be used to check if the required replay gain adjustment will cause the file to clip.

	~~====Data Format====~~
	~~The maximum peak amplitude (a single value) should be stored as a 32-bit floating point number, where 1=digital full scale.~~

	~~====Uncompressed Files====~~
	Simply store the maximum absolute sample value held in the file (on any channel). The single sample value should be converted to a 32-bit float, such that digital full scale is equivalent to a value of 1.

	~~====Compressed files====~~
	Compressed audio does not exist as a waveform until it is decoded. Unfortunately, psychoacoustic coding of a heavily limited file can lead to sample values larger than digital full scale upon decoding. However, it is likely that such values will be brought back within range after scaling by the replay level. Even so, it is necessary to store the peak value of a compressed file as a 32-bit floating-point representation, where +/-1 represent digital full scale, and values outside this range would usually clip.

	~~====Implementation====~~
	For uncompressed files, the maximum values must be found and stored. For compressed files, the files must be decoded using a fully compliant decoder that allows peak overflows (i.e. has headroom), and the maximum value stored.

← Older revision		Revision as of 04:36, 20 January 2011
Line 1:		Line 1:
	==LAME tags==		==LAME tags==
	ReplayGain metadata is stored in bytes 167 through 175 of the [http://gabriel.mp3-tech.org/mp3infotag.html MP3 Info Tag] created by the LAME encoder.		ReplayGain metadata is stored in bytes 167 through 175 of the [http://gabriel.mp3-tech.org/mp3infotag.html MP3 Info Tag]<!--Archive: http://www.webcitation.org/5vryCdtDv--> created by the LAME encoder.

	{\| class="wikitable"		{\| class="wikitable"