ReplayGain legacy metadata formats: Difference between revisions

From Hydrogenaudio Knowledgebase
(CUE Sheets)
(→‎Binary format: endianess)
 
(One intermediate revision by one other user not shown)
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====
Line 122: Line 123:
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>

Latest revision as of 16:18, 20 September 2013

LAME tags

ReplayGain metadata is stored in bytes 167 through 175 of the MP3 Info Tag created by the LAME encoder.

Start Length Description Format
167 4 Track peak amplitude Floating point
171 2 Track gain adjustment As defined in #Binary format
173 2 Album gain adjustment As defined in #Binary format

ID3v2 RGAD

In the language of the ID3v2 standard document, the Replay Gain tag is thus:[1]

<Header for 'Replay Gain Adjustment', ID: "RGAD">
Peak Amplitude				$xx $xx $xx $xx
Track Replay Gain Adjustment		$xx $xx
Album Replay Gain Adjustment		$xx $xx

Header consists of:

Frame ID		$52 $47 $41 $44	= "RGAD"
Size			$00 $00 $00 $08
Flags			$40 $00		(%01000000 %00000000)

In the RGAD frame, the above specified flags value states that the frame should be preserved if the ID3v2 tag is altered, but discarded if the audio data is altered.

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. Values are stored as Big-Endian.

Range

The replay gain adjustment must be between -51.0 dB and +51.0 dB. Values outside this range must be limited to be within the range, though they are certainly in error, and should probably be re-calculated, or stored as "not set". For example, trying to cause a silent 24-bit file to play at 83 dB will yield a replay gain adjustment of +57 dB.

In practice, adjustment values from -23 dB to +17 dB are the likely extremes, and values from -18 dB to +2 dB are more usual.

Bit format

Each Replay Gain value should be stored in a Replay Gain Adjustment field consisting of two bytes (16 bits). Here are two example Replay Gain Adjustment fields:

Track gain adjustment

0 0 1 0 1 1 1 0 0 1 1 1 1 1 0 1
\___/ \___/ | \_______________/
  |     |   |         |        
name    |  sign       |        
code    |  bit        |        
        |             |        
   originator         |        
      code            |        
                 Replay Gain   
                  Adjustment   

Album gain adjustment

0 1 0 0 1 0 0 0 0 0 0 1 0 1 0 0
\___/ \___/ | \_______________/
  |     |   |         |
name    |  sign       |
code    |  bit        |
        |             |
   originator         |
      code            |
                 Replay Gain
                  Adjustment

In the above example, the Track Gain Adjustment is -12.5 dB, and was calculated automatically. The Album Gain Adjustment is +2.0 dB, and was set by the user.

Name code
000 = not set
001 = Track Gain Adjustment
010 = Album Gain Adjustment
other = reserved for future use

If space has been reserved for the Replay Gain in the file header, but no replay gain calculation has been carried out, then all bits (including the Name code) may be zero.

For each Replay Gain Adjustment field, if the name code = 000 (not set), then players should ignore the rest of that individual field.

For each Replay Gain Adjustment field, if the name code is an unrecognised value (i.e. not 001-Track or 010-Album), then players should ignore the rest of that individual field.

If no valid Replay Gain Adjustment fields are found (i.e. all name codes are either 000 or unknown), then the player should proceed as if the file contained no Replay Gain Adjustment information (see player requirements).

Originator code
000 = Replay Gain unspecified
001 = Replay Gain pre-set by artist/producer/mastering engineer
010 = Replay Gain set by user
011 = Replay Gain determined automatically, as described in Calculating (above)
other = reserved for future use

For each Replay Gain Adjustment field, if the name code is valid, but the Originator code is 000 (Replay Gain unspecified), then the player should ignore that Replay Gain adjustment field.

For each Replay Gain Adjustment field, if the name code is valid, but the Originator code is unknown, then the player should still use the information within that Replay Gain Adjustment field. This is because, even if we are unsure as to how the adjustment was determined, any valid Replay Gain adjustment is more useful than none at all.

If no valid Replay Gain Adjustment fields are found (i.e. all originator codes are 000), then the player should proceed as if the file contained no Replay Gain Adjustment information (see player requirements).

Sign bit
0 = positive gain (boost)
1 = negative gain (attenuation)
Replay Gain Adjustment

The value, multiplied by ten, stripped of its sign (since the + or - is stored in the "sign" bit), is represented in 9 bits. e.g. -3.1 dB becomes 31 = 000011111.

Default Value

$00 $00 (0000000000000000) should be used where no Replay Gain has been calculated or set. This value will be interpreted by players in the same manner as a file without a Replay Gain field in the header (see player requirements).

The values of xxxyyy0000000000 (where xxx is any name code, and yyy is any originator code) are all valid, but indicate that the Replay Gain is to be left at 83 dB (0 dB Replay Gain Adjustment). These are not default values, and should only be used where appropriate (e.g. where the user, producer, or Replay Gain calculation has indicated that the correct Replay Gain is 83 dB).

Illegal Values

The values xxxyyy1000000000 are all illegal. If enountered, players should treat them in the same manner as $00 $00 (the default value).

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.

Cue sheets

Foobar2000 writes ReplayGain metadata as "REM" statements in cue sheets.

REM GENRE Electronic
REM DATE 2012
PERFORMER "Somebody"
TITLE "AlbumName"
REM REPLAYGAIN_ALBUM_GAIN -7.48 dB
REM REPLAYGAIN_ALBUM_PEAK 0.979682
FILE "test.wav" WAVE
  TRACK 01 AUDIO
    TITLE "intro"
    REM REPLAYGAIN_TRACK_GAIN -6.54 dB
    REM REPLAYGAIN_TRACK_PEAK 0.711406
    INDEX 01 00:00:00
  TRACK 02 AUDIO
    TITLE "outro"
    REM REPLAYGAIN_TRACK_GAIN -7.84 dB
    REM REPLAYGAIN_TRACK_PEAK 0.979682
    INDEX 01 00:30:50

Notes

  1. This tag specification is not part of any version of the ID3 specification but is acknowledged as an "in the wild" tag by the ID3 standards organization.