Informal standard Document: id3v2-00.html

M. Nilsson Latest change: 9th June 1998

Status of this document

This document is an Informal standard and is released so that implementors could have a set standard before the formal standard is set. The formal standard will use another version number if not identical to what is described in this document. The contents in this document may change for clarifications but never for added or altered functionallity.

The comments in this file is copyright © 1998 Martin Nilsson. This document may not be freely distributed.

Abstract

The recent gain of popularity for MPEG layer III audio files on the internet forced a standardised way of storing information about an audio file within itself to determinate its origin and contents.

Today the most accepted way to do this is with the so called ID3 tag, which is simple but very limited and in some cases very unsuitable. The ID3 tag has very limited space in every field, very limited numbers of fields, not expandable or upgradeable and is placed at the end of a the file, which is unsuitable for streaming audio. This draft is an attempt to answer these issues with a new version of the ID3 tag.

1. Table of contents

2. Conventions in this document

In the examples, text within "" is a text string exactly as it appears in a file. Numbers preceded with $ are hexadecimal and numbers preceded with % are binary. $xx is used to indicate a byte with unknown content. %x is used to indicate a bit with unknown content. The most significant bit (MSB) of a byte is called 'bit 7' and the least significant bit (LSB) is called 'bit 0'.
It does show that I have programmed the 68000, doesn't it?

A tag is the whole tag described in this document. A frame is a block of information in the tag. The tag consists of a header, frames and optional padding. A field is a piece of information; one value, a string etc. A numeric string is a string that consists of the characters 0-9 only.

3. 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 expandable.

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' described in section 5.

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's 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 to files encoded with MPEG-2 layer I, MPEG-2 layer II, MPEG-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.

Padding is good as it increases the write speed when there is already a tag present in a file. If the new tag is one byte longer than the previous tag, than the extra byte can be taken from the padding, instead of having to shift the entire file one byte. Padding is of course bad in that it increases the size of the file, but if the amount of padding is wisely chosen (with clustersize in mind), the impact on filesystems will be virtually none. As the contents is $00, it is also easy for modems and other transmission devices/protocols to compress the padding. Having a $00 filled padding also increases the ability to recover erroneous tags.

3.1. ID3v2 header

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

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

In the first draft of ID3v2 the identifier was "TAG", just as in ID3v1. It was later changed to "MP3" as I thought of the ID3v2 as the fileheader MP3 had always been missing. When it became appearant than ID3v2 was going towards a general purpose audio header the identifier was changed to "ID3".

The first bit (bit 7) in the 'ID3 flags' is indicating whether or not unsynchronisation is used; a set bit indicates usage.

The second bit (bit 6) is indicating whether or not compression is used; a set bit indicates usage. Since no compression scheme has been decided yet, the ID3 decoder (for now) should just ignore the entire tag if the compression bit is set.

Currently, zlib compression is being considered for the compression, in an effort to stay out of the all-too-common marsh of patent trouble. Have a look at the additions draft for the latest developments.

The ID3 tag size is encoded with four bytes where the first 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.

We really gave it a second thought several times before we introduced these awkward size descriptions. The reason is that we thought it would be even worse to have a file header with no set size (as we wanted to unsynchronise the header if there were any false synchronisations in it). An easy way of calculating the tag size is A*2^21+B*2^14+C*2^7+D = A*2097152+B*16384+C*128+D, where A is the first byte, B the second, C the third and D the fourth byte.

The ID3 tag size is the size of the complete tag after unsychronisation, including padding, excluding the header (total tag size - 10). The reason to use 28 bits (representing up to 256MB) for size description is that we don't want to run out of space here.

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.2. ID3v2 frames overview

The headers of the frames are similar in their construction. They consist of one three character identifier (capital A-Z and 0-9) and one three byte size field, making a total of six bytes. The header is excluded from the size. Identifiers beginning with "X", "Y" and "Z" are for experimental use and free for everyone to use. 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. This gives us 46656 combinations of frame identifiers.

The three character frame identifier is followed by a three byte size descriptor, making a total header size of six bytes in every frame. The size is calculated as framesize excluding frame identifier and size descriptor (frame size - 6).

The decision to have a 6 byte frame header was taken in an attempt to balance big frames against little overhead. One might think that it's stupid to optimize away a few bytes when the entire MP3-file is soo huge. On the other hand I thought it was really cool that most ID3v1 tags, when converted to ID3v2 was smaller than before. Size does matter.

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. The reason for this is to make it faster to search for a specific file by scanning the ID3v2 tags; an intelligent parser wouldn't have to keep reading the entire tag after having found that the file isn't the one being looked for. An example of such order: UFI, MCI, TT2 ...

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

If nothing else is said, a string is represented as ISO-8859-1 characters in the range $20 - $FF. All unicode strings use 16-bit unicode 2.0 (ISO/IEC 10646-1:1993, UCS-2). All numeric strings 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 characters are 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.

The three byte language field is used to describe the language of the frame's content, according to ISO-639-2.
ISO-639-1 is not used since its supported languages are just a subset of those in 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 ID3 standard. This is reflected by the revision number in the header of the tag.
This allows us to fix our mistakes as well as introducing new features in the already existing frames.

4. Declared ID3v2 frames

The following frames are declared in this draft.

4.1. Unique file identifier

This frame's purpose is to be able to identify the audio file in a database that may contain more information relevant to the content. Since standardisation of such a database is beyond this document, all frames begin with a null-terminated string with a URL containing an email address, or a link to a location where an email address can be found, that belongs to the organisation responsible for this specific database implementation. Questions regarding the database should be sent to the indicated email address. The URL should not be used for the actual database queries. If a $00 is found directly after the 'Frame size' the whole frame should be ignored, and preferably be removed. The 'Owner identifier' is then followed by the actual identifier, which may be up to 64 bytes. As it is desired to identify a file as quickly as possible, it is therefore in our interest to limit the size of frames without information value for everyone. Besides, with 64 bytes you can have 1.34E154 combinations. That's many combinations. There may be more than one "UFI" frame in a tag, but only one with the same 'Owner identifier'.

4.2. Text information frames

The text information frames are the most important frames, containing information like artist, album and more. There may only be one text information frame of its kind in an tag. If the textstring is followed by a termination ($00 (00)) all the following information should be ignored and not be displayed. This could be used to implement new features in the future. All the text information frames have the following format:

Initially there was only one text information frame called "TID" (Text Information Data or somthing equally boring). It begun with three bytes of flags, indicating which strings were present and which weren't. Then all the indicated present strings would follow as null terminated string in the same order as the flags.

4.2.1. Text information frames - details

This does not however mean that there always is numbers or RX or CR in the paranthesis. It might very well be a new format for genres in the future, e.g. "(/rock/hard)"

Combinations like "5/3" is of course not allowed. This goes for both "TRK" and "TPA" frames.

4.2.2. User defined text information frame

This frame is intended for one-string text information concerning the audiofile in a similar way to the other "T"xx frames. The frame body consists of a description of the string, represented as a terminated string, followed by the actual string. There may be more than one "TXX" frame in each tag, but only one with the same description.

4.3. URL link frames

With these frames dynamic data such as webpages with touring information, price information or plain ordinary news can be added to the tag. There may only be one URL link frame of its kind in an tag, except when stated otherwise in the frame description. If the textstring is followed by a termination ($00 (00)) all the following information should be ignored and not be displayed. All URL link frames have the following format:

4.3.1. URL link frames - details

4.3.2. User defined URL link frame

This frame is intended for URL links concerning the audiofile in a similar way to the other "W"xx frames. The frame body consists of a description of the string, represented as a terminated string, followed by the actual URL. The URL is always encoded with ISO-8859-1. There may be more than one "WXX" frame in each tag, but only one with the same description.

4.4. Involved people list

Since there might be a lot of people contributing to an audio file in various ways, such as musicians and technicians, the 'Text information frames' are often insufficient to list everyone involved in a project. The 'Involved people list' is a frame containing the names of those involved, and how they were involved. The body simply contains a terminated string with the involvement directly followed by a terminated string with the involvee followed by a new involvement and so on. There may only be one "IPL" frame in each tag.

4.5. Music CD Identifier

This frame is intended for music that comes from a CD, so that the CD can be identified in databases such as the CDDB. The frame consists of a binary dump of the Table Of Contents, TOC, from the CD, which is a header of 4 bytes and then 8 bytes/track on the CD making a maximum of 804 bytes. This frame requires a present and valid "TRK" frame. There may only be one "MCI" frame in each tag.

4.6. Event timing codes

This frame allows synchronisation with key events in a song or sound. The head is:

Where time stamp format is:

Abolute time means that every stamp contains the time from the beginning of the file.

Followed by a list of key events in the following format:

The 'Time stamp' is set to zero if directly at the beginning of the sound or after the previous event. All events should be sorted in chronological order. The type of event is as follows:

The 'Not predefined sync's ($E0-EF) are for user events. You might want to synchronise your music to something, like setting of an explosion on-stage, turning on your screensaver etc.

There may only be one "ETC" frame in each tag.

4.7. MPEG location lookup table

The author of NAD once planned to make a mp3 encoder of his own, ARCAM. He would at the same time introduce a new file format were all the major problems with MP3 was built away, eg. the lack of ability to jump precisely within the audio. Thanks for the idea.

To increase performance and accuracy of jumps within a MPEG audio file, frames with timecodes in different locations in the file might be useful. The ID3 frame includes references that the software can use to calculate positions in the file. After the frame header is a descriptor of how much the 'frame counter' should increase for every reference. If this value is two then the first reference points out the second frame, the 2nd reference the 4th frame, the 3rd reference the 6th frame etc. In a similar way the 'bytes between reference' and 'milliseconds between reference' points out bytes and milliseconds respectively.

Each reference consists of two parts; a certain number of bits, as defined in 'bits for bytes deviation', that describes the difference between what is said in 'bytes between reference' and the reality and a certain number of bits, as defined in 'bits for milliseconds deviation', that describes the difference between what is said in 'milliseconds between reference' and the reality. The number of bits in every reference, i.e. 'bits for bytes deviation'+'bits for milliseconds deviation', must be a multiple of four. There may only be one "MLL" frame in each tag.

Then for every reference the following data is included;

4.8. Synced tempo codes

For a more accurate description of the tempo of a musical piece this frame might be used. After the header follows one byte describing which time stamp format should be used. Then follows one or more tempo codes. Each tempo code consists of one tempo part and one time part. The tempo is in BPM described with one or two bytes. If the first byte has the value $FF, one more byte follows, which is added to the first giving a range from 2 - 510 BPM, since $00 and $01 is reserved. $00 is used to describe a beat-free time period, which is not the same as a music-free time period. $01 is used to indicate one single beat-stroke followed by a beat-free period.

The tempo descriptor is followed by a time stamp. Every time the tempo in the music changes, a tempo descriptor may indicate this for the player. All tempo descriptors should be sorted in chronological order. The first beat-stroke in a time-period is at the same time as the beat description occurs. There may only be one "STC" frame in each tag.

Where time stamp format is:

Abolute time means that every stamp contains the time from the beginning of the file.

4.9. Unsychronised lyrics/text transcription

This frame contains the lyrics of the song or a text transcription of other vocal activities. The head includes an encoding descriptor and a content descriptor. The body consists of the actual text. The 'Content descriptor' is a terminated string. If no descriptor is entered, 'Content descriptor' is $00 (00) only. Newline characters are allowed in the text. Maximum length for the descriptor is 64 bytes. There may be more than one lyrics/text frame in each tag, but only one with the same language and content descriptor.

4.10. Synchronised lyrics/text

This is another way of incorporating the words, said or sung lyrics, in the audio file as text, this time, however, in sync with the audio. It might also be used to describing events e.g. occurring on a stage or on the screen in sync with the audio. The header includes a content descriptor, represented with as terminated textstring. If no descriptor is entered, 'Content descriptor' is $00 (00) only.

Time stamp format is:

$01   Absolute time, 32 bit sized, using MPEG frames as unit
$02   Absolute time, 32 bit sized, using milliseconds as unit

Different time stamp formats were introduced very late in the ID3v2 draft. Initially the time stamp was relative, containing the number of MPEG frames from the previous stamp. This was changed for two different reasons. One was that some developers didn't want the "SLT" frame to store its timestamps in a chronological order, making relative time stamps unsuitable. After some discussion it was agreed that the order should remain chronological, but that the timestamps should be absolute. Agree is perhaps not the best word since Alon Gingold made his own lyrics format (as a successor to lyrics3). I wanted the possibility to increase the amount of bits used for the absolute time stamp (in case one should encounter an MP3 file longer than 1500 days) so I added a byte telling that. By now Dave Walton begun to push his idea that the ID3v2 should be more of a multi purpose audio format so a new non MP3 based timestamp was introduced (increasing accuracy to 1/1000 second, but limiting the maximal length of an MP3 file to 49 days). The 'used bit' field was redesigned to become a time stamp indicator field. All timestamps in the draft were then replaced with this general-purpose solution.

Abolute time means that every stamp contains the time from the beginning of the file.

The text that follows the frame header differs from that of the unsynchronised lyrics/text transcription in one major way. Each syllable (or whatever size of text is considered to be convenient by the encoder) is a null terminated string followed by a time stamp denoting where in the sound file it belongs. Each sync thus has the following structure:

The 'time stamp' is set to zero or the whole sync is omitted if located directly at the beginning of the sound. All time stamps should be sorted in chronological order. The sync can be considered as a validator of the subsequent string.

Newline characters are allowed in all "SLT" frames and should be used after every entry (name, event etc.) in a frame with the content type $03 - $04.

A few considerations regarding whitespace characters: Whitespace separating words should mark the beginning of a new word, thus occurring in front of the first syllable of a new word. This is also valid for new line characters. A syllable followed by a comma should not be broken apart with a sync (both the syllable and the comma should be before the sync).

An example: The "ULT" passage

"Strangers in the night" $0A "Exchanging glances"

would be "SLT" encoded as:

"Strang" $00 xx xx "ers" $00 xx xx " in" $00 xx xx " the" $00 xx xx " night" $00 xx xx 0A "Ex" $00 xx xx "chang" $00 xx xx "ing" $00 xx xx "glan" $00 xx xx "ces" $00 xx xx

There may be more than one "SLT" frame in each tag, but only one with the same language and content descriptor.

4.11. Comments

This frame replaces the old 30-character comment field in ID3v1. It consists of a frame head followed by encoding, language and content descriptors and is ended with the actual comment as a text string. Newline characters are allowed in the comment text string. There may be more than one comment frame in each tag, but only one with the same language and content descriptor.

I'm a bit annoyed that this frame turned out almost identical to the "ULT" frame, but I guess that this is the best solution after all. Feel free to use the fact that the "COM" and "ULT" frames have the same structure when optimizing your code.
This frame is often the right answear to all the mails I get asking "Where should I put information xxxxx?" questions. No, there will not be a biography frame. It's too hard to keep it up to date.

4.12. Relative volume adjustment

This is a more subjective function than the previous ones. It allows the user to say how much he wants to increase/decrease the volume on each channel while the file is played. The purpose is to be able to align all files to a reference volume, so that you don't have to change the volume constantly. This frame may also be used to balance adjust the audio. If the volume peak levels are known then this could be described with the 'Peak volume right' and 'Peak volume left' field. If Peakvolume is not known these fields could be left zeroed or completely omitted. There may only be one "RVA" frame in each tag.

In the increment/decrement field bit 0 is used to indicate the right channel and bit 1 is used to indicate the left channel. 1 is increment and 0 is decrement.

The 'bits used for volume description' field is normally $10 (16 bits) for MPEG 2 layer I, II and III and MPEG 2.5. This value may not be $00. The volume is always represented with whole bytes, padded in the beginning (highest bits) when 'bits used for volume description' is not a multiple of eight.

4.13. Equalisation

This is another subjective, alignment frame. It allows the user to predefine an equalisation curve within the audio file. There may only be one "EQU" frame in each tag.

The 'adjustment bits' field defines the number of bits used for representation of the adjustment. This is normally $10 (16 bits) for MPEG 2 layer I, II and III and MPEG 2.5. This value may not be $00.

This is followed by 2 bytes + ('adjustment bits' rounded up to the nearest byte) for every equalisation band in the following format, giving a frequency range of 0 - 32767Hz. Brian Stucker is the mind behind this data format. It's way better then the fix frequencies that the first draft had.

The increment/decrement bit is 1 for increment and 0 for decrement. The equalisation bands should be ordered increasingly with reference to frequency. All frequencies don't have to be declared. Adjustments with the value $00 should be omitted. A frequency should only be described once in the frame.

4.14. Reverb

Yet another subjective one. You may here adjust echoes of different kinds. Reverb left/right is the delay between every bounce in ms. Reverb bounces left/right is the number of bounces that should be made. $FF equals an infinite number of bounces. Feedback is the amount of volume that should be returned to the next echo bounce. $00 is 0%, $FF is 100%. If this value were $7F, there would be 50% volume reduction on the first bounce, yet 50% on the second and so on. Left to left means the sound from the left bounce to be played in the left speaker, while left to right means sound from the left bounce to be played in the right speaker.

'Premix left to right' is the amount of left sound to be mixed in the right before any reverb is applied, where $00 id 0% and $FF is 100%. 'Premix right to left' does the same thing, but right to left. Setting both premix to $FF would result in a mono output (if the reverb is applied symmetric). There may only be one "REV" frame in each tag.

While it says here that the "REV" frame is $00000C big, it might be bigger when encountered. If this frame is updated in a later version of ID3v2, that information will be put at the end of the frame and the length updated.

4.15. Attached picture

This frame contains a picture directly related to the audio file. Image format is preferably "PNG" or "JPG". Since JPG has the best lossy compression and PNG the best lossless compression and both are free I don't see much room for other formats. I didn't want to forbid other formats though, since there might pop up better ones in the future. Some people will probably think it is neat with ICO pictures as well. Description is a short description of the picture, represented as a terminated textstring. The description has a maximum length of 64 characters, but may be empty. There may be several pictures attached to one file, each in their individual "PIC" frame, but only one with the same content descriptor. There may only be one picture with the picture type declared as picture type $01 and $02 respectively. There is a possibility to put only a link to the image file by using the 'image format' "-->" and having a complete URL instead of picture data. The use of linked files should however be used restrictively since there is the risk of separation of files.

4.16. General encapsulated object

In this frame any type of file can be encapsulated. After the header, 'Frame size' and 'Encoding' follows 'MIME type' and 'Filename' for the encapsulated object, both represented as terminated strings encoded with ISO 8859-1. The filename is case sensitive. Then follows a content description as terminated string, encoded as 'Encoding'. The last thing in the frame is the actual object. The first two strings may be omitted, leaving only their terminations. MIME type is always an ISO-8859-1 text string. There may be more than one "GEO" frame in each tag, but only one with the same content descriptor.

4.17. Play counter

This is simply a counter of the number of times a file has been played. The value is increased by one every time the file begins to play. There may only be one "CNT" frame in each tag. When the counter reaches all one's, one byte is inserted in front of the counter thus making the counter eight bits bigger. The counter must be at least 32-bits long to begin with. Dirk Mahoney and I once had a debate whether or not the counter should be virtually infinite. He said that a simple 32 bit word was big enough and easy enough to implement while I said it wasn't cool enough. He's now using the same bat against me when I say that there is no need for two bytes to describe how many channels a PCM sample has.

4.18. Popularimeter

The purpose of this frame is to specify how good an audio file is. Many interesting applications could be found to this frame such as a playlist that features better audiofiles more often than others or it could be used to profile a persons taste and find other 'good' files by comparing people's profiles. The frame is very simple. It contains the email address to the user, one rating byte and a four byte play counter, intended to be increased with one for every time the file is played. The email is a terminated string. The rating is 1-255 where 1 is worst and 255 is best. 0 is unknown. If no personal counter is wanted it may be omitted. When the counter reaches all one's, one byte is inserted in front of the counter thus making the counter eight bits bigger in the same away as the play counter. There may be more than one "POP" frame in each tag, but only one with the same email address.

This is defenitly my personal favorite frame. Support it a lot.

4.19. Recommended buffer size

Sometimes the server from which a audio file is streamed is aware of transmission or coding problems resulting in interruptions in the audio stream. In these cases, the size of the buffer can be recommended by the server using this frame. If the 'embedded info flag' is true (1) then this indicates that an ID3 tag with the maximum size described in 'Buffer size' may occur in the audiostream. In such case the tag should reside between two MPEG frames, if the audio is MPEG encoded. If the position of the next tag is known, 'offset to next tag' may be used. The offset is calculated from the end of tag in which this frame resides to the first byte of the header in the next. This field may be omitted. Embedded tags is currently not recommended since this could render unpredictable behaviour from present software/hardware. The 'Buffer size' should be kept to a minimum. There may only be one "BUF" frame in each tag.

This frame was really designed to make it possible to include ID3v2 tags in the audio stream. In order to get the player to play without interruptions when the tag is coming instead of audio data there must be a way to tell the maximum size of the tag. A good practice might be to set the recommended buffer size to at least the size of the largest tag occurring in the rest of the mpeg stream.

4.20. Encrypted meta frame

This frame contains one or more encrypted frames. This enables protection of copyrighted information such as pictures and text, that people might want to pay extra for. Since standardisation of such an encryption scheme is beyond this document, all "CRM" frames begin with a terminated string with a URL containing an email address, or a link to a location where an email adress can be found, that belongs to the organisation responsible for this specific encrypted meta frame.

Questions regarding the encrypted frame should be sent to the indicated email address. If a $00 is found directly after the 'Frame size', the whole frame should be ignored, and preferably be removed. The 'Owner identifier' is then followed by a short content description and explanation as to why it's encrypted. After the 'content/explanation' description, the actual encrypted block follows.

When an ID3v2 decoder encounters a "CRM" frame, it should send the datablock to the 'plugin' with the corresponding 'owner identifier' and expect to receive either a datablock with one or several ID3v2 frames after each other or an error. There may be more than one "CRM" frames in a tag, but only one with the same 'owner identifier'.

4.21. Audio encryption

This frame indicates if the actual audio stream is encrypted, and by whom. Since standardisation of such encrypion scheme is beyond this document, all "CRA" frames begin with a terminated string with a URL containing an email address, or a link to a location where an email address can be found, that belongs to the organisation responsible for this specific encrypted audio file. Questions regarding the encrypted audio should be sent to the email address specified. If a $00 is found directly after the 'Frame size' and the audiofile indeed is encrypted, the whole file may be considered useless.

After the 'Owner identifier', a pointer to an unencrypted part of the audio can be specified. The 'Preview start' and 'Preview length' is described in frames. If no part is unencrypted, these fields should be left zeroed. After the 'preview length' field follows optionally a datablock required for decryption of the audio. There may be more than one "CRA" frames in a tag, but only one with the same 'Owner identifier'.

This frame is my response to the MMP protocol from Fraunhofer, which I think is cra... not so good.

4.22. Linked information

To keep space waste as low as possible this frame may be used to link information from another ID3v2 tag that might reside in another audio file or alone in a binary file. It is recommended that this method is only used when the files are stored on a CD-ROM or other circumstances when the risk of file seperation is low. The frame contains a frame identifier, which is the frame that should be linked into this tag, a URL [URL] field, where a reference to the file where the frame is given, and additional ID data, if needed. Data should be retrieved from the first tag found in the file to which this link points. There may be more than one "LNK" frame in a tag, but only one with the same contents. A linked frame is to be considered as part of the tag and has the same restrictions as if it was a physical part of the tag (i.e. only one "REV" frame allowed, whether it's linked or not).

This is a very nice frame when dealing with tag streaming since it allows the reciever to decide if he/she wants to download the frame or not. Since the file is being streamed, it is most likely that the user will be able to get the resource, should he/she want to.

Frames that may be linked and need no additional data are "IPL", "MCI", "ETC", "LLT", "STC", "RVA", "EQU", "REV", "BUF", the text information frames and the URL link frames.

The "TXX", "PIC", "GEO", "CRM" and "CRA" frames may be linked with the content descriptor as additional ID data.

The "COM", "SLT" and "ULT" frames may be linked with three bytes of language descriptor directly followed by a content descriptor as additional ID data.

5. The 'unsynchronisation scheme'

The unsynchronisation scheme was initially very, very complex (and had another name, since it didn't unsynchronise) and was done very late compared to the other key components of ID3v2. The idea was that all data falsely recognized as an MPEG frame (i e the ID3v2 tag) that a player found should have an incorrect CRC and thus be skipped. At first, this sounded simple to implement since the CRC would most likely not be correct anyhow. The problem was that the correct bit must be cleared so that the player really believed that there should be a CRC. If, when unsynchronising, it turns out that the CRC was valid after all, the data had to be manipulated to render the CRC erroneous again. The real trick was to reverse the process so that a tag with several MPEG frames with unvalid CRC:s should become a normal tag again. By now I made a simple test and found out that most players don't care about whether the CRC is correct or not; they play the data anyway.

The only purpose of the 'unsychronisation 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 unsynchonisation.

To indicate usage of the unsynchronisation, the first bit in 'ID3 flags' should be set. This bit should only be set if the tag contained 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 unsyncronisation scheme should be applied afterwards. When decoding a compressed, 'unsyncronised' file, the 'unsyncronisation scheme' should be parsed first, compression afterwards.

6. Copyright

Copyright (C) Martin Nilsson 1998. All Rights Reserved.

This document and the information contained herein is provided on an "AS IS" basis and THE AUTHORS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

The comments on this page, enclosed within <i>, is intended for your information and entertainment and may only be used for your personal use. You may not redistribute this information in any way on any media. If the comments are removed the following applies to this document:

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that a reference to this document is included on all such copies and derivative works. However, this document itself may not be modified in any way and reissued as the original document.

The limited permissions granted above are perpetual and will not be revoked.

7. References

[CDDB] Compact Disc Data Base

<url:http://www.cddb.com>

[ISO-639-2] ISO/FDIS 639-2. Codes for the representation of names of languages, Part 2: Alpha-3 code. Technical committee / subcommittee: TC 37 / SC 2

[ISO-8859-1] ISO/IEC DIS 8859-1. 8-bit single-byte coded graphic character sets, Part 1: Latin alphabet No. 1. Technical committee / subcommittee: JTC 1 / SC 2

[ISRC] ISO 3901:1986 International Standard Recording Code (ISRC). Technical committee / subcommittee: TC 46 / SC 9

[JFIF] JPEG File Interchange Format, version 1.02

<url:http://www.w3.org/Graphics/JPEG/jfif.txt>

[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.

<url:ftp://ftp.isi.edu/in-notes/rfc2045.txt>

[MPEG] ISO/IEC 11172-3:1993. Coding of moving pictures and associated audio for digital storage media at up to about 1,5 Mbit/s, Part 3: Audio. Technical committee / subcommittee: JTC 1 / SC 29
and
ISO/IEC 13818-3:1995 Generic coding of moving pictures and associated audio information, Part 3: Audio. Technical committee / subcommittee: JTC 1 / SC 29
and
ISO/IEC DIS 13818-3 Generic coding of moving pictures and associated audio information, Part 3: Audio (Revision of ISO/IEC 13818-3:1995)

[PNG] Portable Network Graphics, version 1.0

<url:http://www.w3.org/TR/REC-png-multi.html>

[UNICODE] ISO/IEC 10646-1:1993. Universal Multiple-Octet Coded Character Set (UCS), Part 1: Architecture and Basic Multilingual Plane. Technical committee / subcommittee: JTC 1 / SC 2

<url:http://www.unicode.org>

[URL] T. Berners-Lee, L. Masinter & M. McCahill, "Uniform Resource Locators (URL).", RFC 1738, December 1994.

<url:ftp://ftp.isi.edu/in-notes/rfc1738.txt>

8. Appendix

A. Appendix A - ID3-Tag Specification V1.1

ID3-Tag Specification V1.1 (12 dec 1997) by Michael Mutschler, edited for space and clarity reasons.

This section is of little or no concern to ID3v2 implementions, it is here mainly for historical reference. The genre section (A.3.) is used bye the "TCO" frame though.

A.1. Overview

The ID3-Tag is an information field for MPEG Layer 3 audio files. Since a standalone MP3 doesn't provide a method of storing other information than those directly needed for replay reasons, the ID3-tag was invented by Eric Kemp in 1996.

A revision from ID3v1 to ID3v1.1 was made by Michael Mutschler to support track number information.

A.2. ID3v1 Implementation

The Information is stored in the last 128 bytes of an MP3. The Tag has got the following fields, and the offsets given here, are from 0-127.

The string-fields contain ASCII-data, coded in ISO-Latin 1 codepage. Strings which are smaller than the field length are padded with zero-bytes.

A.3. Genre List

  0.Blues
  1.Classic Rock
  2.Country
  3.Dance
  4.Disco
  5.Funk
  6.Grunge
  7.Hip-Hop
  8.Jazz
  9.Metal
 10.New Age
 11.Oldies
 12.Other
 13.Pop
 14.R&B
 15.Rap
 16.Reggae
 17.Rock
 18.Techno
 19.Industrial
 20.Alternative
 21.Ska
 22.Death Metal
 23.Pranks
 24.Soundtrack
 25.Euro-Techno
 26.Ambient
 27.Trip-Hop
 28.Vocal
 29.Jazz+Funk
 30.Fusion
 31.Trance
 32.Classical
 33.Instrumental
 34.Acid
 35.House
 36.Game
 37.Sound Clip
 38.Gospel
 39.Noise
 40.AlternRock
 41.Bass
 42.Soul
 43.Punk
 44.Space
 45.Meditative
 46.Instrumental Pop
 47.Instrumental Rock
 48.Ethnic
 49.Gothic
 50.Darkwave
 51.Techno-Industrial
 52.Electronic
 53.Pop-Folk
 54.Eurodance
 55.Dream
 56.Southern Rock
 57.Comedy
 58.Cult
 59.Gangsta
 60.Top 40
 61.Christian Rap
 62.Pop/Funk
 63.Jungle
 64.Native American
 65.Cabaret
 66.New Wave
 67.Psychadelic
 68.Rave
 69.Showtunes
 70.Trailer
 71.Lo-Fi
 72.Tribal
 73.Acid Punk
 74.Acid Jazz
 75.Polka
 76.Retro
 77.Musical
 78.Rock & Roll
 79.Hard Rock

 80.Folk
 81.Folk-Rock
 82.National Folk
 83.Swing
 84.Fast Fusion
 85.Bebob
 86.Latin
 87.Revival
 88.Celtic
 89.Bluegrass
 90.Avantgarde
 91.Gothic Rock
 92.Progressive Rock
 93.Psychedelic Rock
 94.Symphonic Rock
 95.Slow Rock
 96.Big Band
 97.Chorus
 98.Easy Listening
 99.Acoustic
100.Humour
101.Speech
102.Chanson
103.Opera
104.Chamber Music
105.Sonata
106.Symphony
107.Booty Bass
108.Primus
109.Porn Groove
110.Satire
111.Slow Jam
112.Club
113.Tango
114.Samba
115.Folklore
116.Ballad
117.Power Ballad
118.Rhythmic Soul
119.Freestyle
120.Duet
121.Punk Rock
122.Drum Solo
123.A capella
124.Euro-House
125.Dance Hall

A.4. Track addition - ID3v1.1

In ID3v1.1, Michael Mutschler revised the specification of the comment field in order to implement the track number. The new format of the comment field is a 28 character string followed by a mandatory null ($00) character and the original album tracknumber stored as an unsigned byte-size integer. In such cases where the 29th byte is not the null character or when the 30th is a null character, the tracknumber is to be considered undefined.

9. Author's Address

Martin Nilsson
Rydsvägen 246 C. 30
S-584 34 Linköping
Sweden

Email: nilsson@id3.org

Co-author:

Johan Sundström Email: johan@id3.org