Monday, October 25, 2010

Audio Codec – MP3 –ID3v2.3

MP3 Codec - ID3 tag version 2.3.0

 

1

ID3v2 Overview

   

The two biggest design goals were to be able to implement ID3v2 without disturbing old software too much and that ID3v2 should be as flexible and expandable as possible.

The first criterion is met by the simple fact that the MPEG decoding software uses a syncsignal, embedded in the audiostream, to 'lock on to' the audio. Since the ID3v2 tag doesn't contain a valid syncsignal, no software will attempt to play the tag. If, for any reason, coincidence make a syncsignal appear within the tag it will be taken care of by the 'unsynchronisation scheme'.

The second criterion has made a more noticeable impact on the design of the ID3v2 tag. It is constructed as a container for several information blocks, called frames, whose format need not be known to the software that encounters them. At the start of every frame there is an identifier that explains the frames' format and content, and a size descriptor that allows software to skip unknown frames.

If a total revision of the ID3v2 tag should be needed, there is a version number and a size descriptor in the ID3v2 header.

The ID3 tag described in this document is mainly targeted at files encoded with MPEG-1/2 layer I, MPEG-1/2 layer II, MPEG-1/2 layer III and MPEG-2.5, but may work with other types of encoded audio.

The bitorder in ID3v2 is most significant bit first (MSB). The byteorder in multibyte numbers is most significant byte first (e.g. $12345678 would be encoded $12 34 56 78).

It is permitted to include padding after all the final frame (at the end of the ID3 tag), making the size of all the frames together smaller than the size given in the head of the tag. A possible purpose of this padding is to allow for adding a few additional frames or enlarge existing frames within the tag without having to rewrite the entire file. The value of the padding bytes must be $00.

 

2

ID3v2 header

   

The ID3v2 tag header, which should be the first information in the file, is 10 bytes as follows:

ID3v2/file identifier

"ID3"

ID3v2 version

$03 00

ID3v2 flags

%abc00000

ID3v2 size

4 * %0xxxxxxx

The first three bytes of the tag are always "ID3" to indicate that this is an ID3v2 tag, directly followed by the two version bytes. The first byte of ID3v2 version is it's major version, while the second byte is its revision number. In this case this is ID3v2.3.0. All revisions are backwards compatible while major versions are not. If software with ID3v2.2.0 and below support should encounter version three or higher it should simply ignore the whole tag. Version and revision will never be $FF.

The version is followed by one the ID3v2 flags field, of which currently only three flags are used.

a

- Unsynchronisation

 

Bit 7 in the 'ID3v2 flags' indicates whether or not unsynchronisation is used; a set bit indicates usage.

b

- Extended header

 

The second bit (bit 6) indicates whether or not the header is followed by an extended header.

c

- Experimental indicator

 

The third bit (bit 5) should be used as an 'experimental indicator'. This flag should always be set when the tag is in an experimental stage.

All the other flags should be cleared. If one of these undefined flags are set that might mean that the tag is not readable for a parser that does not know the flags function.

The ID3v2 tag size is encoded with four bytes where the most significant bit (bit 7) is set to zero in every byte, making a total of 28 bits. The zeroed bits are ignored, so a 257 bytes long tag is represented as $00 00 02 01.

The ID3v2 tag size is the size of the complete tag after unsychronisation, including padding, excluding the header but not excluding the extended header (total tag size - 10). Only 28 bits (representing up to 256MB) are used in the size description to avoid the introducuction of 'false syncsignals'.

An ID3v2 tag can be detected with the following pattern:

 

$49 44 33 yy yy xx zz zz zz zz

Where yy is less than $FF, xx is the 'flags' byte and zz is less than $80.

 

3

ID3v2 extended header

   

The extended header contains information that is not vital to the correct parsing of the tag information; hence the extended header is optional.

Extended header size

$xx xx xx xx

Extended Flags

$xx xx

Size of padding

$xx xx xx xx

Where the 'Extended header size', currently 6 or 10 bytes, excludes itself. The 'Size of padding' is simply the total tag size excluding the frames and the headers, in other words the padding. The extended header is considered separate from the header proper, and as such is subject to unsynchronisation.

The extended flags are a secondary flag set which describes further attributes of the tag. These attributes are currently defined as follows:

 

%x0000000 00000000

 

x

- CRC data present

  

If this flag is set four bytes of CRC-32 data is appended to the extended header. The CRC should be calculated before unsynchronisation on the data between the extended header and the padding, i.e. the frames and only the frames.

  

Total frame CRC $xx xx xx xx

 

4

ID3v2 frame overview

   

As the tag consists of a tag header and a tag body with one or more frames, all the frames consists of a frame header followed by one or more fields containing the actual information. The layout of the frame header:

 

Frame ID

$xx xx xx xx (four characters)

 

Size

$xx xx xx xx

 

Flags

$xx xx

The frame ID made out of the characters capital A-Z and 0-9. Identifiers beginning with "X", "Y" and "Z" are for experimental use and free for everyone to use, without the need to set the experimental bit in the tag header. Have in mind that someone else might have used the same identifier as you. All other identifiers are either used or reserved for future use.

The frame ID is followed by a size descriptor, making a total header size of ten bytes in every frame. The size is calculated as frame size excluding frame header (frame size - 10).

In the frame header the size descriptor is followed by two flags bytes.

There is no fixed order of the frames' appearance in the tag, although it is desired that the frames are arranged in order of significance concerning the recognition of the file. An example of such order: UFID, TIT2, MCDI, TRCK ...

A tag must contain at least one frame. A frame must be at least 1 byte big, excluding the header.

If nothing else is said a string is represented as ISO-8859-1 characters in the range $20 - $FF. Such strings are represented as <text string>, or <full text string> if newlines are allowed, in the frame descriptions. All Unicode strings use 16-bit unicode 2.0 (ISO/IEC 10646-1:1993, UCS-2). Unicode strings must begin with the Unicode BOM ($FF FE or $FE FF) to identify the byte order.

All numeric strings and URLs are always encoded as ISO-8859-1. Terminated strings are terminated with $00 if encoded with ISO-8859-1 and $00 00 if encoded as unicode. If nothing else is said newline character is forbidden. In ISO-8859-1 a new line is represented, when allowed, with $0A only. Frames that allow different types of text encoding have a text encoding description byte directly after the frame size. If ISO-8859-1 is used this byte should be $00, if Unicode is used it should be $01. Strings dependent on encoding is represented as <text string according to encoding>, or <full text string according to encoding> if newlines are allowed. Any empty Unicode strings which are NULL-terminated may have the Unicode BOM followed by a Unicode NULL ($FF FE 00 00 or $FE FF 00 00).

The three byte language field is used to describe the language of the frame's content, according to ISO-639-2.

All URLs may be relative, e.g. "picture.png", "../doc.txt".

If a frame is longer than it should be, e.g. having more fields than specified in this

document, that indicates that additions to the frame have been made in a later version of the ID3v2 standard. This is reflected by the revision number in the header of the tag.

  

4.1

Frame header flags

    

In the frame header the size descriptor is followed by two flags bytes. All unused flags must be cleared. The first byte is for 'status messages' and the second byte is for encoding purposes. If an unknown flag is set in the first byte the frame may not be changed without the bit cleared. If an unknown flag is set in the second byte it is likely to not be readable. The flags field is defined as follows.

 

%abc00000 %ijk00000

 

a

- Tag alter preservation

  

This flag tells the software what to do with this frame if it is unknown and the tag is altered in any way. This applies to all kinds of alterations, including adding more padding and reordering the frames.

   

0

- Frame should be preserved.

   

1

- Frame should be discarded.

 

b

- File alter preservation

  

This flag tells the software what to do with this frame if it is unknown and the file, excluding the tag, is altered. This does not apply when the audio is completely replaced with other audio data.

   

0

- Frame should be preserved.

   

1

- Frame should be discarded.

 

c

- Read only

  

This flag, if set, tells the software that the contents of this frame is intended to be read only. Changing the contents might break something, e.g. a signature. If the contents are changed, without knowledge in why the frame was flagged read only and without taking the proper means to compensate, e.g. recalculating the signature, the bit should be cleared.

 

i

- Compression

  

This flag indicates whether or not the frame is compressed.

   

0

Frame is not compressed.

   

1

Frame is compressed using [#ZLIB zlib] with 4 bytes for 'decompressed size' appended to the frame header.

 

j

- Encryption

  

This flag indicates wether or not the frame is enrypted. If set one byte indicating with which method it was encrypted will be appended to the frame header.

   

0

- Frame is not encrypted.

   

1

- Frame is encrypted.

 

k

- Grouping identity

  

This flag indicates whether or not this frame belongs in a group with other frames. If set a group identifier byte is added to the frame header. Every frame with the same group identifier belongs to the same group.

   

0

- Frame does not contain group information

   

1

- Frame contains group information

Some flags indicates that the frame header is extended with additional information. This information will be added to the frame header in the same order as the flags indicating the additions. I.e. the four bytes of decompressed size will preceed the encryption method byte. These additions to the frame header, while not included in the frame header size but are included in the 'frame size' field, are not subject to encryption or compression.

 

5

Default flags

   

The default settings for the frames described in this document can be divided into the following classes. The flags may be set differently if found more suitable by the software.

 

Discarded if tag is altered, discarded if file is altered.

  

None.

 

Discarded if tag is altered, preserved if file is altered.

  

None.

 

Preserved if tag is altered, discarded if file is altered.

  

AENC, ETCO, EQUA, MLLT, POSS, SYLT, SYTC, RVAD, TENC, TLEN, TSIZ

 

Preserved if tag is altered, preserved if file is altered.

  

The rest of the frames.

 

6

Declared ID3v2 frames

   

The following frames are declared in this draft.

 

AENC

Audio encryption

 

APIC

Attached picture

 

COMM

Comments

 

COMR

Commercial frame

 

ENCR

Encryption method registration

 

EQUA

Equalization

 

ETCO

Event timing codes

 

GEOB

General encapsulated object

 

GRID

Group identification registration

 

IPLS

Involved people list

 

LINK

Linked information

 

MCDI

Music CD identifier

 

MLLT

MPEG location lookup table

 

OWNE

Ownership frame

 

PRIV

Private frame

 

PCNT

Play counter

 

POPM

Popularimeter

 

POSS

Position synchronisation frame

 

RBUF

Recommended buffer size

 

RVAD

Relative volume adjustment

 

RVRB

Reverb

 

SYLT

Synchronized lyric/text

 

SYTC

Synchronized tempo codes

 

TALB

Album/Movie/Show title

 

TBPM

BPM (beats per minute)

 

TCOM

Composer

 

TCON

Content type

 

TCOP

Copyright message

 

TDAT

Date

 

TDLY

Playlist delay

 

TENC

Encoded by

 

TEXT

Lyricist/Text writer

 

TFLT

File type

 

TIME

Time

 

TIT1

Content group description

 

TIT2

Title/songname/content description

 

TIT3

Subtitle/Description refinement

 

TKEY

Initial key

 

TLAN

Language(s)

 

TLEN

Length

 

TMED

Media type

 

TOAL

Original album/movie/show title

 

TOFN

Original filename

 

TOLY

Original lyricist(s)/text writer(s)

 

TOPE

Original artist(s)/performer(s)

 

TORY

Original release year

 

TOWN

File owner/licensee

 

TPE1

Lead performer(s)/Soloist(s)

 

TPE2

Band/orchestra/accompaniment

 

TPE3

Conductor/performer refinement

 

TPE4

Interpreted, remixed, or otherwise modified by

 

TPOS

Part of a set

 

TPUB

Publisher

 

TRCK

Track number/Position in set

 

TRDA

Recording dates

 

TRSN

Internet radio station name

 

TRSO

Internet radio station owner

 

TSIZ

Size

 

TSRC

ISRC (international standard recording code)

 

TSSE

Software/Hardware and settings used for encoding

 

TYER

Year

 

TXXX

User defined text information frame

 

UFID

Unique file identifier

 

USER

Terms of use

 

USLT

Unsychronized lyric/text transcription

 

WCOM

Commercial information

 

WCOP

Copyright/Legal information

 

WOAF

Official audio file webpage

 

WOAR

Official artist/performer webpage

 

WOAS

Official audio source webpage

 

WORS

Official internet radio station homepage

 

WPAY

Payment

 

WPUB

Publishers official webpage

 

WXXX

User defined URL link frame

 

7

The unsynchronisation scheme

   

The only purpose of the 'unsynchronisation scheme' is to make the ID3v2 tag as compatible as possible with existing software. There is no use in 'unsynchronising' tags if the file is only to be processed by new software. Unsynchronisation may only be made with MPEG 2 layer I, II and III and MPEG 2.5 files.

Whenever a false synchronisation is found within the tag, one zeroed byte is inserted after the first false synchronisation byte. The format of a correct sync that should be altered by ID3 encoders is as follows:

 

%11111111 111xxxxx

And should be replaced with:

 

%11111111 00000000 111xxxxx

This has the side effect that all $FF 00 combinations have to be altered, so they won't be affected by the decoding process. Therefore all the $FF 00 combinations have to be replaced with the $FF 00 00 combination during the unsynchronisation.

To indicate usage of the unsynchronisation, the first bit in 'ID3 flags' should be set. This bit should only be set if the tag contains a, now corrected, false synchronisation. The bit should only be clear if the tag does not contain any false synchronisations.

Do bear in mind, that if a compression scheme is used by the encoder, the unsynchronisation scheme should be applied *afterwards*. When decoding a compressed, 'unsynchronised' file, the 'unsynchronization scheme' should be parsed first, decompression afterwards.

If the last byte in the tag is $FF, and there is a need to eliminate false synchronizations in the tag, at least one byte of padding should be added.


 

In the next blog let us see the encoding method.

.