+++ /dev/null
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
-<html><head>
-
-
-<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
-<meta name="robots" content="noindex,nofollow">
-
-<title>id3v2.3.0 - ID3.org</title>
-<script type="text/javascript" src="id3v2%20Files/common.js"></script>
-
-
-<link rel="stylesheet" type="text/css" charset="utf-8" media="all" href="id3v2%20Files/common.css">
-<link rel="stylesheet" type="text/css" charset="utf-8" media="all" href="id3v2%20Files/print.css">
-<link rel="alternate" title="ID3.org Recent Changes" href="http://www.id3.org/RecentChanges?action=rss_rc&ddiffs=1&unique=1" type="application/rss+xml">
-
-<link rel="Start" href="http://www.id3.org/Home">
-<link rel="Alternate" title="Wiki Markup" href="http://www.id3.org/id3v2.3.0?action=raw">
-<link rel="Alternate" media="print" title="Print View" href="http://www.id3.org/id3v2.3.0?action=print">
-<link rel="Search" href="http://www.id3.org/FindPage">
-<link rel="Index" href="http://www.id3.org/TitleIndex">
-<link rel="Glossary" href="http://www.id3.org/WordIndex">
-<link rel="Help" href="http://www.id3.org/HelpOnFormatting">
-</head><body dir="ltr" lang="en">
-<div id="page" dir="ltr" lang="en">
-
-<ul id="pagelocation">
-<li>id3v2.3.0</li>
-</ul>
-<div dir="ltr" id="content" lang="en"><span class="anchor" id="top"></span>
-<span class="anchor" id="line-3"></span><p class="line867"><span class="anchor" id="top"></span> <span class="anchor" id="line-4"></span>Informal Standard <br>
- <span class="anchor" id="line-5"></span>Document: id3v2.3 <br>
- <span class="anchor" id="line-6"></span>M. Nilsson<br>
-3rd February 1999 <span class="anchor" id="line-7"></span><span class="anchor" id="line-8"></span><span class="anchor" id="line-9"></span></p><p class="line867">
-</p><h1 id="head-0b2a9a0361388ae81f2ca83d66eaa02d4ea76d05">1. ID3 tag version 2.3.0</h1>
-<span class="anchor" id="line-10"></span><p class="line867"><span class="anchor" id="status"></span> <span class="anchor" id="line-11"></span>
-</p><h2 id="head-7d04f74ec3f80b6f8761bb601a3a0be9377162e5">1.1. Status of this document</h2>
-<span class="anchor" id="line-12"></span><p class="line862">This document is an informal standard and replaces the <a href="http://www.id3.org/id3v2-00"> id3v2.2.0</a> <span class="anchor" id="line-13"></span>standard.
-The informal standard is released so that implementors could have a set
-standard before a formal standard is set. The formal standard will use
-another version or revision 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. <span class="anchor" id="line-14"></span><span class="anchor" id="line-15"></span></p><p class="line874">Distribution of this document is unlimited. <span class="anchor" id="line-16"></span><span class="anchor" id="line-17"></span></p><p class="line867"><span class="anchor" id="abstract"></span> <span class="anchor" id="line-18"></span>
-</p><h2 id="head-23ac0ee64acc84a9f496e03b940d5701d6ac9e8f">1.2. Abstract</h2>
-<span class="anchor" id="line-19"></span><p class="line874">This document describes the ID3v2.3.0 standard, which is a more <span class="anchor" id="line-20"></span>developed version of the ID3v2 informal standard (version [:id3v2-00: <span class="anchor" id="line-21"></span>2.2.0]), evolved from the ID3 tagging system. The ID3v2 offers a flexible way <span class="anchor" id="line-22"></span>of storing information about an audio file within itself to determine <span class="anchor" id="line-23"></span>its origin and contents. The information may be technical information, <span class="anchor" id="line-24"></span>such as equalisation curves, as well as related meta information, such <span class="anchor" id="line-25"></span>as title, performer, copyright etc. <span class="anchor" id="line-26"></span><span class="anchor" id="line-27"></span></p><p class="line867"></p><div class="table-of-contents"><p class="table-of-contents-heading">Contents</p><ol><li><a href="#head-0b2a9a0361388ae81f2ca83d66eaa02d4ea76d05">ID3 tag version 2.3.0</a><ol><li><a href="#head-7d04f74ec3f80b6f8761bb601a3a0be9377162e5">Status of this document</a></li><li><a href="#head-23ac0ee64acc84a9f496e03b940d5701d6ac9e8f">Abstract</a></li></ol></li><li><a href="#head-2d62428ce142c0165419bd5c2a6d2d48e4f1fb56">Conventions in this document</a></li><li><a href="#head-0ef7011e13ae8b3678a676a65b64760b9cedf1de">ID3v2 overview</a><ol><li><a href="#head-697d09c50ed7fa96fb66c6b0a9d93585e2652b0b">ID3v2 header</a></li><li><a href="#head-237cdb2af1eb3a0b2a83dac400cac09f52afa939">ID3v2 extended header</a></li><li><a href="#head-1a37d4a15deafc294208ccfde950f77e47000bca">ID3v2 frame overview</a><ol><li><a href="#head-671e80857a8fbb3b050387a8bc439e8780a999e1">Frame header flags</a></li></ol></li><li><a href="#head-67925bcb6b2031594e0f1a4797488f62a64cb450">Default flags</a></li></ol></li><li><a href="#head-e4b3c63f836c3eb26a39be082065c21fba4e0acc">Declared ID3v2 frames</a><ol><li><a href="#head-86fc458c0f12976c6866d12610551218827dca80">Unique file identifier</a></li><li><a href="#head-05145d86196104464db40d63035e402ee3c504e7">Text information frames</a><ol><li><a href="#head-42b02d20fb8bf48e38ec5415e34909945dd849dc">Text information frames - details</a></li><li><a href="#head-29e37534e169ad913deb6a4fee345028f3db7c3f">User defined text information frame</a></li></ol></li><li><a href="#head-66afd8fc82926f98baa42eade0a5e96010a2d77f">URL link frames</a><ol><li><a href="#head-871541c0b67dfb4bf890d1a2c72e7b41595b36cc">URL link frames - details</a></li><li><a href="#head-b0e8086b6e51f25d126cd5f26d13696defb44aa9">User defined URL link frame</a></li></ol></li><li><a href="#head-a0ac5e01361fd414b67a39130716fea4c970e004">Involved people list</a></li><li><a href="#head-f56120ef5f24045436031b86131ce297b0e43f42">Music CD identifier</a></li><li><a href="#head-d302f218df2a0868b706d1525e9cc78ebcb86e16">Event timing codes</a></li><li><a href="#head-febc618121880ee751b0c2a87327b0e698213dc4">MPEG location lookup table</a></li><li><a href="#head-9804169dd0fc7e12a1050a02d3419e6b3dc4f5e9">Synchronised tempo codes</a></li><li><a href="#head-e76d4fb26268baf285bff899581cc284427a2789">Unsychronised lyrics/text transcription</a></li><li><a href="#head-792dcad788fe1b8bcd7f9d7e9eec7549e1864546">Synchronised lyrics/text</a></li><li><a href="#head-31c41e8642534f1854246708af84f7d2c8d39684">Comments</a></li><li><a href="#head-d3d2bfba9882a197c1b55a80f52bb676653d3604">Relative volume adjustment</a></li><li><a href="#head-3d14382e1cdc086bc43df0f0b0e63cf0c33f7c64">Equalisation</a></li><li><a href="#head-5f9be76d443047174b52f89243bbc671d7937fa3">Reverb</a></li><li><a href="#head-70a65d30522ef0d37642224c2a40517ae35b7155">Attached picture</a></li><li><a href="#head-060e0e68febc214cad81328a2baf7fd1ce17b59b">General encapsulated object</a></li><li><a href="#head-b31a15058cdc13a61e13ab109c25782bc3387075">Play counter</a></li><li><a href="#head-2452ec9cf8b42c5c117b518b69e129ff67970852">Popularimeter</a></li><li><a href="#head-85933b08aab499dc462e7c09752076c92e80f567">Recommended buffer size</a></li><li><a href="#head-64778eca1ee53ea0f439602809c142e312669eda">Audio encryption</a></li><li><a href="#head-1f5f3f280f04ce712a1d5a3531fb0dd396c6ea9f">Linked information</a></li><li><a href="#head-dfd851b017379ad18d434c1a1be6bfb98c16c4ed">Position synchronisation frame</a></li><li><a href="#head-d25b79fcb6f0d51c28301e2cd8a1750b061a5bef">Terms of use frame</a></li><li><a href="#head-3c67d23d7cfecadd0253293fada37fbba5c6f1e1">Ownership frame</a></li><li><a href="#head-5cd03d43fbc0db57aaaf42cd5a2150705f50eada">Commercial frame</a></li><li><a href="#head-104c980db64c9df28fbaa4ae87e365d50930534d">Encryption method registration</a></li><li><a href="#head-ba309170decab08b9bcb1ffb6d6974c0bfd1ead3">Group identification registration</a></li><li><a href="#head-6e58a3ef53dd199d9af3dd33d544a39a5343ab3c">Private frame</a></li></ol></li><li><a href="#head-c632e49403443283c464955b36911f949bbb2586">The unsynchronisation scheme</a></li><li><a href="#head-2e25d065aae179b2e61ebe76ded3ce201fd6764f">Copyright</a></li><li><a href="#head-090c9e5e624f843e946e467f0ad8a1c21aacaa01">References</a></li><li><a href="#head-50c2e666f19bdeb915260d8de35bcb5bc35330d6">Appendix</a><ol><li><a href="#head-129376727ebe5309c1de1888987d070288d7c7e7">Appendix A - Genre List from ID3v1</a></li></ol></li><li><a href="#head-ab9d99d0fd7edd520f035105d0b20ac9adebce85">Author's Address</a></li></ol></div> <span class="anchor" id="line-28"></span><span class="anchor" id="line-29"></span><span class="anchor" id="line-30"></span><p class="line867"><span class="anchor" id="sec2"></span> <span class="anchor" id="line-31"></span>
-</p><h1 id="head-2d62428ce142c0165419bd5c2a6d2d48e4f1fb56">2. Conventions in this document</h1>
-<span class="anchor" id="line-32"></span><p class="line874">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'. <span class="anchor" id="line-33"></span><span class="anchor" id="line-34"></span></p><p class="line874">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. <span class="anchor" id="line-35"></span><span class="anchor" id="line-36"></span></p><p class="line867"><span class="anchor" id="sec3"></span> <span class="anchor" id="line-37"></span>
-</p><h1 id="head-0ef7011e13ae8b3678a676a65b64760b9cedf1de">3. ID3v2 overview</h1>
-<span class="anchor" id="line-38"></span><p class="line874">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. <span class="anchor" id="line-39"></span><span class="anchor" id="line-40"></span></p><p class="line862">The first criterion is met by the simple fact that the <a href="#MPEG">MPEG</a>
-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 <a href="#sec5">section 5</a>. <span class="anchor" id="line-41"></span><span class="anchor" id="line-42"></span></p><p class="line874">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. <span class="anchor" id="line-43"></span><span class="anchor" id="line-44"></span></p><p class="line874">If a total revision of the ID3v2 tag should be needed, there is a version number and a size descriptor in the ID3v2 header. <span class="anchor" id="line-45"></span><span class="anchor" id="line-46"></span></p><p class="line862">The ID3 tag described in this document is mainly targeted at files encoded with <a href="#MPEG">MPEG</a>-1/2 layer I, <a href="#MPEG">MPEG</a>-1/2 layer II, <a href="#MPEG">MPEG</a>-1/2 layer III and <a href="#MPEG">MPEG</a>-2.5, but may work with other types of encoded audio. <span class="anchor" id="line-47"></span><span class="anchor" id="line-48"></span></p><p class="line874">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). <span class="anchor" id="line-49"></span><span class="anchor" id="line-50"></span></p><p class="line874">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. <span class="anchor" id="line-51"></span><span class="anchor" id="line-52"></span></p><p class="line867"><span class="anchor" id="sec3.1"></span> <span class="anchor" id="line-53"></span>
-</p><h2 id="head-697d09c50ed7fa96fb66c6b0a9d93585e2652b0b">3.1. ID3v2 header</h2>
-<span class="anchor" id="line-54"></span><p class="line874">The ID3v2 tag header, which should be the first information in the file, is 10 bytes as follows: <span class="anchor" id="line-55"></span></p><pre>ID3v2/file identifier "ID3"
-<span class="anchor" id="line-56"></span>ID3v2 version $03 00
-<span class="anchor" id="line-57"></span>ID3v2 flags %abc00000
-<span class="anchor" id="line-58"></span>ID3v2 size 4 * %0xxxxxxx
-<span class="anchor" id="line-59"></span></pre><span class="anchor" id="line-60"></span><p class="line874">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. <span class="anchor" id="line-61"></span><span class="anchor" id="line-62"></span></p><p class="line874">The version is followed by one the ID3v2 flags field, of which currently only three flags are used. <span class="anchor" id="line-63"></span><span class="anchor" id="line-64"></span><span class="anchor" id="line-65"></span></p><dl><dt>a - Unsynchronisation</dt><dd><p class="line862">Bit 7 in the 'ID3v2 flags' indicates whether or not unsynchronisation is used (see <a href="#sec5">section 5</a> for details); a set bit indicates usage. <span class="anchor" id="line-66"></span><span class="anchor" id="line-67"></span></p></dd><dt>b - Extended header</dt><dd><p class="line862">The
-second bit (bit 6) indicates whether or not the header is followed by
-an extended header. The extended header is described in <a href="#sec3.2">section 3.2</a>. <span class="anchor" id="line-68"></span><span class="anchor" id="line-69"></span></p></dd><dt>c - Experimental indicator</dt><dd>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. <span class="anchor" id="line-70"></span><span class="anchor" id="line-71"></span></dd></dl><p class="line874">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. <span class="anchor" id="line-72"></span><span class="anchor" id="line-73"></span></p><p class="line874">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. <span class="anchor" id="line-74"></span><span class="anchor" id="line-75"></span></p><p class="line874">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'. <span class="anchor" id="line-76"></span><span class="anchor" id="line-77"></span></p><p class="line874">An ID3v2 tag can be detected with the following pattern: <span class="anchor" id="line-78"></span></p><pre>$49 44 33 yy yy xx zz zz zz zz
-<span class="anchor" id="line-79"></span></pre><span class="anchor" id="line-80"></span><p class="line874">Where yy is less than $FF, xx is the 'flags' byte and zz is less than $80. <span class="anchor" id="line-81"></span><span class="anchor" id="line-82"></span></p><p class="line867"><span class="anchor" id="sec3.2"></span> <span class="anchor" id="line-83"></span>
-</p><h2 id="head-237cdb2af1eb3a0b2a83dac400cac09f52afa939">3.2. ID3v2 extended header</h2>
-<span class="anchor" id="line-84"></span><p class="line874">The
-extended header contains information that is not vital to the correct
-parsing of the tag information, hence the extended header is optional. <span class="anchor" id="line-85"></span></p><pre>Extended header size $xx xx xx xx
-<span class="anchor" id="line-86"></span>Extended Flags $xx xx
-<span class="anchor" id="line-87"></span>Size of padding $xx xx xx xx
-<span class="anchor" id="line-88"></span></pre><span class="anchor" id="line-89"></span><p class="line874">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. <span class="anchor" id="line-90"></span><span class="anchor" id="line-91"></span></p><p class="line874">The
-extended flags are a secondary flag set which describes further
-attributes of the tag. These attributes are currently defined as
-follows <span class="anchor" id="line-92"></span></p><pre>%x0000000 00000000
-<span class="anchor" id="line-93"></span></pre><span class="anchor" id="line-94"></span><span class="anchor" id="line-95"></span><dl><dt>x - CRC data present</dt><dd>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. <span class="anchor" id="line-96"></span><pre>Total frame CRC $xx xx xx xx
-<span class="anchor" id="line-97"></span></pre><span class="anchor" id="line-98"></span><span class="anchor" id="line-99"></span></dd></dl><p class="line867"><span class="anchor" id="sec3.3"></span> <span class="anchor" id="line-100"></span>
-</p><h2 id="head-1a37d4a15deafc294208ccfde950f77e47000bca">3.3. ID3v2 frame overview</h2>
-<span class="anchor" id="line-101"></span><p class="line874">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: <span class="anchor" id="line-102"></span></p><pre>Frame ID $xx xx xx xx (four characters)
-<span class="anchor" id="line-103"></span>Size $xx xx xx xx
-<span class="anchor" id="line-104"></span>Flags $xx xx
-<span class="anchor" id="line-105"></span></pre><span class="anchor" id="line-106"></span><p class="line874">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. <span class="anchor" id="line-107"></span><span class="anchor" id="line-108"></span></p><p class="line874">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). <span class="anchor" id="line-109"></span><span class="anchor" id="line-110"></span></p><p class="line862">In the frame header the size descriptor is followed by two flags bytes. These flags are described in <a href="#sec3.3.1">section 3.3.1</a>. <span class="anchor" id="line-111"></span><span class="anchor" id="line-112"></span></p><p class="line862">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: <a href="#sec4.1">UFID</a>, <a href="#TIT2">TIT2</a>, <a href="#sec4.5">MCDI</a>, <a href="#TRCK">TRCK</a> ... <span class="anchor" id="line-113"></span><span class="anchor" id="line-114"></span></p><p class="line874">A tag must contain at least one frame. A frame must be at least 1 byte big, excluding the header. <span class="anchor" id="line-115"></span><span class="anchor" id="line-116"></span></p><p class="line862">If nothing else is said a string is represented as <a href="#ISO-8859-1">ISO-8859-1</a>
-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 <a href="#UNICODE">Unicode</a>
-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. <span class="anchor" id="line-117"></span><span class="anchor" id="line-118"></span></p><p class="line862">All numeric strings and <a href="#URL">URLs</a> are always encoded as <a href="#ISO-8859-1">ISO-8859-1</a>. Terminated strings are terminated with $00 if encoded with <a href="#ISO-8859-1">ISO-8859-1</a> and $00 00 if encoded as unicode. If nothing else is said newline character is forbidden. In <a href="#ISO-8859-1">ISO-8859-1</a>
-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 <a href="#ISO-8859-1">ISO-8859-1</a>
-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 <a href="#UNICODE">Unicode</a> strings which are NULL-terminated may have the Unicode BOM followed by a Unicode NULL ($FF FE 00 00 or $FE FF 00 00). <span class="anchor" id="line-119"></span><span class="anchor" id="line-120"></span></p><p class="line862">The three byte language field is used to describe the language of the frame's content, according to <a href="#ISO-639-2">ISO-639-2</a>. <span class="anchor" id="line-121"></span><span class="anchor" id="line-122"></span></p><p class="line862">All <a href="#URL">URLs</a> may be relative, e.g. "picture.png", "../doc.txt". <span class="anchor" id="line-123"></span><span class="anchor" id="line-124"></span></p><p class="line874">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. <span class="anchor" id="line-125"></span><span class="anchor" id="line-126"></span></p><p class="line867"><span class="anchor" id="sec3.3.1"></span> <span class="anchor" id="line-127"></span>
-</p><h3 id="head-671e80857a8fbb3b050387a8bc439e8780a999e1">3.3.1. Frame header flags</h3>
-<span class="anchor" id="line-128"></span><p class="line874">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. <span class="anchor" id="line-129"></span></p><pre>%abc00000 %ijk00000
-<span class="anchor" id="line-130"></span></pre><span class="anchor" id="line-131"></span><span class="anchor" id="line-132"></span><dl><dt>a - Tag alter preservation</dt><dd>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. <span class="anchor" id="line-133"></span><pre>0 Frame should be preserved.
-<span class="anchor" id="line-134"></span>1 Frame should be discarded.
-<span class="anchor" id="line-135"></span></pre><span class="anchor" id="line-136"></span></dd><dt>b - File alter preservation</dt><dd>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. <span class="anchor" id="line-137"></span><span class="anchor" id="line-138"></span><pre>0 Frame should be preserved.
-<span class="anchor" id="line-139"></span>1 Frame should be discarded.
-<span class="anchor" id="line-140"></span></pre><span class="anchor" id="line-141"></span></dd><dt>c - Read only</dt><dd>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. <span class="anchor" id="line-142"></span></dd><dt>i - Compression</dt><dd>This flag indicates whether or not the frame is compressed. <span class="anchor" id="line-143"></span><pre>0 Frame is not compressed.
-<span class="anchor" id="line-144"></span>1 Frame is compressed using [#ZLIB zlib] with 4 bytes for 'decompressed size' appended to the frame header.
-<span class="anchor" id="line-145"></span></pre><span class="anchor" id="line-146"></span></dd><dt>j - Encryption</dt><dd><p class="line862">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. See <a href="#sec4.26">section 4.26</a>. for more information about encryption method registration. <span class="anchor" id="line-147"></span></p><pre>0 Frame is not encrypted.
-<span class="anchor" id="line-148"></span>1 Frame is encrypted.
-<span class="anchor" id="line-149"></span></pre><span class="anchor" id="line-150"></span></dd><dt>k - Grouping identity</dt><dd>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. <span class="anchor" id="line-151"></span><pre>0 Frame does not contain group information
-<span class="anchor" id="line-152"></span>1 Frame contains group information
-<span class="anchor" id="line-153"></span></pre><span class="anchor" id="line-154"></span><span class="anchor" id="line-155"></span></dd></dl><p class="line874">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. <span class="anchor" id="line-156"></span><span class="anchor" id="line-157"></span></p><p class="line867"><span class="anchor" id="sec3.3.2"></span> <span class="anchor" id="line-158"></span>
-</p><h2 id="head-67925bcb6b2031594e0f1a4797488f62a64cb450">3.4. Default flags</h2>
-<span class="anchor" id="line-159"></span><p class="line874">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. <span class="anchor" id="line-160"></span><span class="anchor" id="line-161"></span></p><ol type="1"><li>Discarded if tag is altered, discarded if file is altered. <span class="anchor" id="line-162"></span><ul><li style="list-style-type: none;">None. <span class="anchor" id="line-163"></span><span class="anchor" id="line-164"></span></li></ul></li><li class="gap">Discarded if tag is altered, preserved if file is altered. <span class="anchor" id="line-165"></span><ul><li style="list-style-type: none;">None. <span class="anchor" id="line-166"></span><span class="anchor" id="line-167"></span></li></ul></li><li class="gap">Preserved if tag is altered, discarded if file is altered. <span class="anchor" id="line-168"></span><ul><li style="list-style-type: none;"><p class="line891"><a href="#sec4.21">AENC</a>, <a href="#sec4.6">ETCO</a>, <a href="#sec4.13">EQUA</a>, <a href="#sec4.7">MLLT</a>, <a href="#sec4.22">POSS</a>, <a href="#sec4.10">SYLT</a>, <a href="#sec4.8">SYTC</a>, <a href="#sec4.12">RVAD</a>, <a href="#TENC">TENC</a>, <a href="#TLEN">TLEN</a>, <a href="#TSIZ">TSIZ</a> <span class="anchor" id="line-169"></span><span class="anchor" id="line-170"></span></p></li></ul></li><li class="gap">Preserved if tag is altered, preserved if file is altered. <span class="anchor" id="line-171"></span><ul><li style="list-style-type: none;">The rest of the frames. <span class="anchor" id="line-172"></span><span class="anchor" id="line-173"></span></li></ul></li></ol><p class="line867"><span class="anchor" id="sec4"></span> <span class="anchor" id="line-174"></span>
-</p><h1 id="head-e4b3c63f836c3eb26a39be082065c21fba4e0acc">4. Declared ID3v2 frames</h1>
-<span class="anchor" id="line-175"></span><p class="line874">The following frames are declared in this draft. <span class="anchor" id="line-176"></span></p><pre>4.20 AENC [#sec4.20 Audio encryption]
-<span class="anchor" id="line-177"></span>4.15 APIC [#sec4.15 Attached picture]
-<span class="anchor" id="line-178"></span>4.11 COMM [#sec4.11 Comments]
-<span class="anchor" id="line-179"></span>4.25 COMR [#sec4.25 Commercial frame]
-<span class="anchor" id="line-180"></span>4.26 ENCR [#sec4.26 Encryption method registration]
-<span class="anchor" id="line-181"></span>4.13 EQUA [#sec4.13 Equalization]
-<span class="anchor" id="line-182"></span>4.6 ETCO [#sec4.6 Event timing codes]
-<span class="anchor" id="line-183"></span>4.16 GEOB [#sec4.16 General encapsulated object]
-<span class="anchor" id="line-184"></span>4.27 GRID [#sec4.27 Group identification registration]
-<span class="anchor" id="line-185"></span>4.4 IPLS [#sec4.4 Involved people list]
-<span class="anchor" id="line-186"></span>4.21 LINK [#sec4.21 Linked information]
-<span class="anchor" id="line-187"></span>4.5 MCDI [#sec4.5 Music CD identifier]
-<span class="anchor" id="line-188"></span>4.7 MLLT [#sec4.7 MPEG location lookup table]
-<span class="anchor" id="line-189"></span>4.24 OWNE [#sec4.24 Ownership frame]
-<span class="anchor" id="line-190"></span>4.28 PRIV [#sec4.28 Private frame]
-<span class="anchor" id="line-191"></span>4.17 PCNT [#sec4.17 Play counter]
-<span class="anchor" id="line-192"></span>4.18 POPM [#sec4.18 Popularimeter]
-<span class="anchor" id="line-193"></span>4.22 POSS [#sec4.22 Position synchronisation frame]
-<span class="anchor" id="line-194"></span>4.19 RBUF [#sec4.19 Recommended buffer size]
-<span class="anchor" id="line-195"></span>4.12 RVAD [#sec4.12 Relative volume adjustment]
-<span class="anchor" id="line-196"></span>4.14 RVRB [#sec4.14 Reverb]
-<span class="anchor" id="line-197"></span>4.10 SYLT [#sec4.10 Synchronized lyric/text]
-<span class="anchor" id="line-198"></span>4.8 SYTC [#sec4.8 Synchronized tempo codes]
-<span class="anchor" id="line-199"></span>4.2.1 TALB [#TALB Album/Movie/Show title]
-<span class="anchor" id="line-200"></span>4.2.1 TBPM [#TBPM BPM (beats per minute)]
-<span class="anchor" id="line-201"></span>4.2.1 TCOM [#TCOM Composer]
-<span class="anchor" id="line-202"></span>4.2.1 TCON [#TCON Content type]
-<span class="anchor" id="line-203"></span>4.2.1 TCOP [#TCOP Copyright message]
-<span class="anchor" id="line-204"></span>4.2.1 TDAT [#TDAT Date]
-<span class="anchor" id="line-205"></span>4.2.1 TDLY [#TDLY Playlist delay]
-<span class="anchor" id="line-206"></span>4.2.1 TENC [#TENC Encoded by]
-<span class="anchor" id="line-207"></span>4.2.1 TEXT [#TEXT Lyricist/Text writer]
-<span class="anchor" id="line-208"></span>4.2.1 TFLT [#TFLT File type]
-<span class="anchor" id="line-209"></span>4.2.1 TIME [#TIME Time]
-<span class="anchor" id="line-210"></span>4.2.1 TIT1 [#TIT1 Content group description]
-<span class="anchor" id="line-211"></span>4.2.1 TIT2 [#TIT2 Title/songname/content description]
-<span class="anchor" id="line-212"></span>4.2.1 TIT3 [#TIT3 Subtitle/Description refinement]
-<span class="anchor" id="line-213"></span>4.2.1 TKEY [#TKEY Initial key]
-<span class="anchor" id="line-214"></span>4.2.1 TLAN [#TLAN Language(s)]
-<span class="anchor" id="line-215"></span>4.2.1 TLEN [#TLEN Length]
-<span class="anchor" id="line-216"></span>4.2.1 TMED [#TMED Media type]
-<span class="anchor" id="line-217"></span>4.2.1 TOAL [#TOAL Original album/movie/show title]
-<span class="anchor" id="line-218"></span>4.2.1 TOFN [#TOFN Original filename]
-<span class="anchor" id="line-219"></span>4.2.1 TOLY [#TOLY Original lyricist(s)/text writer(s)]
-<span class="anchor" id="line-220"></span>4.2.1 TOPE [#TOPE Original artist(s)/performer(s)]
-<span class="anchor" id="line-221"></span>4.2.1 TORY [#TORY Original release year]
-<span class="anchor" id="line-222"></span>4.2.1 TOWN [#TOWN File owner/licensee]
-<span class="anchor" id="line-223"></span>4.2.1 TPE1 [#TPE1 Lead performer(s)/Soloist(s)]
-<span class="anchor" id="line-224"></span>4.2.1 TPE2 [#TPE2 Band/orchestra/accompaniment]
-<span class="anchor" id="line-225"></span>4.2.1 TPE3 [#TPE3 Conductor/performer refinement]
-<span class="anchor" id="line-226"></span>4.2.1 TPE4 [#TPE4 Interpreted, remixed, or otherwise modified by]
-<span class="anchor" id="line-227"></span>4.2.1 TPOS [#TPOS Part of a set]
-<span class="anchor" id="line-228"></span>4.2.1 TPUB [#TPUB Publisher]
-<span class="anchor" id="line-229"></span>4.2.1 TRCK [#TRCK Track number/Position in set]
-<span class="anchor" id="line-230"></span>4.2.1 TRDA [#TRDA Recording dates]
-<span class="anchor" id="line-231"></span>4.2.1 TRSN [#TRSN Internet radio station name]
-<span class="anchor" id="line-232"></span>4.2.1 TRSO [#TRSO Internet radio station owner]
-<span class="anchor" id="line-233"></span>4.2.1 TSIZ [#TSIZ Size]
-<span class="anchor" id="line-234"></span>4.2.1 TSRC [#TSRC ISRC (international standard recording code)]
-<span class="anchor" id="line-235"></span>4.2.1 TSSE [#TSEE Software/Hardware and settings used for encoding]
-<span class="anchor" id="line-236"></span>4.2.1 TYER [#TYER Year]
-<span class="anchor" id="line-237"></span>4.2.2 TXXX [#TXXX User defined text information frame]
-<span class="anchor" id="line-238"></span>4.1 UFID [#sec4.1 Unique file identifier]
-<span class="anchor" id="line-239"></span>4.23 USER [#sec4.23 Terms of use]
-<span class="anchor" id="line-240"></span>4.9 USLT [#sec4.9 Unsychronized lyric/text transcription]
-<span class="anchor" id="line-241"></span>4.3.1 WCOM [#WCOM Commercial information]
-<span class="anchor" id="line-242"></span>4.3.1 WCOP [#WCOP Copyright/Legal information]
-<span class="anchor" id="line-243"></span>4.3.1 WOAF [#WOAF Official audio file webpage]
-<span class="anchor" id="line-244"></span>4.3.1 WOAR [#WOAR Official artist/performer webpage]
-<span class="anchor" id="line-245"></span>4.3.1 WOAS [#WOAS Official audio source webpage]
-<span class="anchor" id="line-246"></span>4.3.1 WORS [#WORS Official internet radio station homepage]
-<span class="anchor" id="line-247"></span>4.3.1 WPAY [#WPAY Payment]
-<span class="anchor" id="line-248"></span>4.3.1 WPUB [#WPUB Publishers official webpage]
-<span class="anchor" id="line-249"></span>4.3.2 WXXX [#WXXX User defined URL link frame]
-<span class="anchor" id="line-250"></span></pre><span class="anchor" id="line-251"></span><span class="anchor" id="line-252"></span><p class="line867"><span class="anchor" id="sec4.1"></span> <span class="anchor" id="line-253"></span>
-</p><h2 id="head-86fc458c0f12976c6866d12610551218827dca80">4.1. Unique file identifier</h2>
-<span class="anchor" id="line-254"></span><p class="line862">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. The string "<a class="http" href="http://www.id3.org/dummy/ufid.html">http://www.id3.org/dummy/ufid.html</a>"
-should be used for tests. Software that isn't told otherwise may safely
-remove such frames. The 'Owner identifier' must be non-empty (more than
-just a termination). The 'Owner identifier' is then followed by the
-actual identifier, which may be up to 64 bytes. There may be more than
-one "UFID" frame in a tag, but only one with the same 'Owner
-identifier'. <span class="anchor" id="line-255"></span></p><pre><Header for 'Unique file identifier', ID: "UFID">
-<span class="anchor" id="line-256"></span>Owner identifier <text string> $00
-<span class="anchor" id="line-257"></span>Identifier <up to 64 bytes binary data>
-<span class="anchor" id="line-258"></span></pre><span class="anchor" id="line-259"></span><span class="anchor" id="line-260"></span><p class="line867"><span class="anchor" id="sec4.2"></span> <span class="anchor" id="line-261"></span>
-</p><h2 id="head-05145d86196104464db40d63035e402ee3c504e7">4.2. Text information frames</h2>
-<span class="anchor" id="line-262"></span><p class="line874">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. All text frame identifiers begin with
-"T". Only text frame identifiers begin with "T", with the exception of
-the "TXXX" frame. All the text information frames have the following
-format: <span class="anchor" id="line-263"></span></p><pre><Header for 'Text information frame', ID: "T000" - "TZZZ", excluding "TXXX" described in 4.2.2.>
-<span class="anchor" id="line-264"></span>Text encoding $xx
-<span class="anchor" id="line-265"></span>Information <text string according to encoding>
-<span class="anchor" id="line-266"></span></pre><span class="anchor" id="line-267"></span><span class="anchor" id="line-268"></span><p class="line867"><span class="anchor" id="sec4.2.1"></span> <span class="anchor" id="line-269"></span>
-</p><h3 id="head-42b02d20fb8bf48e38ec5415e34909945dd849dc">4.2.1. Text information frames - details</h3>
-<span class="anchor" id="line-270"></span><p class="line867"><span class="anchor" id="TALB"></span> <span class="anchor" id="line-271"></span></p><dl><dt>TALB</dt><dd>The
-'Album/Movie/Show title' frame is intended for the title of the
-recording(/source of sound) which the audio in the file is taken from. <span class="anchor" id="line-272"></span><span class="anchor" id="line-273"></span></dd></dl><p class="line867"><span class="anchor" id="TBPM"></span> <span class="anchor" id="line-274"></span></p><dl><dt>TBPM</dt><dd>The
-'BPM' frame contains the number of beats per minute in the mainpart of
-the audio. The BPM is an integer and represented as a numerical string.
-<span class="anchor" id="line-275"></span><span class="anchor" id="line-276"></span></dd></dl><p class="line867"><span class="anchor" id="TCOM"></span> <span class="anchor" id="line-277"></span></p><dl><dt>TCOM</dt><dd>The 'Composer(s)' frame is intended for the name of the composer(s). They are seperated with the "/" character. <span class="anchor" id="line-278"></span><span class="anchor" id="line-279"></span></dd></dl><p class="line867"><span class="anchor" id="TCON"></span> <span class="anchor" id="line-280"></span></p><dl><dt>TCON</dt><dd><p class="line862">The
-'Content type', which previously was stored as a one byte numeric value
-only, is now a numeric string. You may use one or several of the types
-as ID3v1.1 did or, since the category list would be impossible to
-maintain with accurate and up to date categories, define your own. <br>
-<br>
-References to the ID3v1 genres can be made by, as first byte, enter "("
-followed by a number from the genres list (appendix A) and ended with a
-")" character. This is optionally followed by a refinement, e.g. "(21)"
-or "(4)Eurodisco". Several references can be made in the same frame,
-e.g. "(51)(39)". If the refinement should begin with a "(" character it
-should be replaced with "((", e.g. "((I can figure out any genre)" or
-"(55)((I think...)". The following new content types is defined in
-ID3v2 and is implemented in the same way as the numerig content types,
-e.g. "(RX)". <span class="anchor" id="line-281"></span></p><pre>RX Remix
-<span class="anchor" id="line-282"></span>CR Cover
-<span class="anchor" id="line-283"></span></pre><span class="anchor" id="line-284"></span><span class="anchor" id="line-285"></span></dd></dl><p class="line867"><span class="anchor" id="TCOP"></span> <span class="anchor" id="line-286"></span></p><dl><dt>TCOP</dt><dd>The
-'Copyright message' frame, which must begin with a year and a space
-character (making five characters), is intended for the copyright
-holder of the original sound, not the audio file itself. The absence of
-this frame means only that the copyright information is unavailable or
-has been removed, and must not be interpreted to mean that the sound is
-public domain. Every time this field is displayed the field must be
-preceded with "Copyright © ". <span class="anchor" id="line-287"></span><span class="anchor" id="line-288"></span></dd></dl><p class="line867"><span class="anchor" id="TDAT"></span> <span class="anchor" id="line-289"></span></p><dl><dt>TDAT</dt><dd>The
-'Date' frame is a numeric string in the DDMM format containing the date
-for the recording. This field is always four characters long. <span class="anchor" id="line-290"></span><span class="anchor" id="line-291"></span></dd></dl><p class="line867"><span class="anchor" id="TDLY"></span> <span class="anchor" id="line-292"></span></p><dl><dt>TDLY</dt><dd>The
-'Playlist delay' defines the numbers of milliseconds of silence between
-every song in a playlist. The player should use the "ETC" frame, if
-present, to skip initial silence and silence at the end of the audio to
-match the 'Playlist delay' time. The time is represented as a numeric
-string. <span class="anchor" id="line-293"></span><span class="anchor" id="line-294"></span></dd></dl><p class="line867"><span class="anchor" id="TENC"></span> <span class="anchor" id="line-295"></span></p><dl><dt>TENC</dt><dd>The
-'Encoded by' frame contains the name of the person or organisation that
-encoded the audio file. This field may contain a copyright message, if
-the audio file also is copyrighted by the encoder. <span class="anchor" id="line-296"></span><span class="anchor" id="line-297"></span></dd></dl><p class="line867"><span class="anchor" id="TEXT"></span> <span class="anchor" id="line-298"></span></p><dl><dt>TEXT</dt><dd>The
-'Lyricist(s)/Text writer(s)' frame is intended for the writer(s) of the
-text or lyrics in the recording. They are seperated with the "/"
-character. <span class="anchor" id="line-299"></span><span class="anchor" id="line-300"></span></dd></dl><p class="line867"><span class="anchor" id="TFLT"></span> <span class="anchor" id="line-301"></span></p><dl><dt>TFLT</dt><dd>The 'File type' frame indicates which type of audio this tag defines. The following type and refinements are defined: <span class="anchor" id="line-302"></span><pre>MPG MPEG Audio
-<span class="anchor" id="line-303"></span>/1 MPEG 1/2 layer I
-<span class="anchor" id="line-304"></span>/2 MPEG 1/2 layer II
-<span class="anchor" id="line-305"></span>/3 MPEG 1/2 layer III
-<span class="anchor" id="line-306"></span>/2.5 MPEG 2.5
-<span class="anchor" id="line-307"></span> /AAC Advanced audio compression
-<span class="anchor" id="line-308"></span>VQF Transform-domain Weighted Interleave Vector Quantization
-<span class="anchor" id="line-309"></span>PCM Pulse Code Modulated audio
-<span class="anchor" id="line-310"></span></pre><span class="anchor" id="line-311"></span></dd></dl><p class="line874">but
-other types may be used, not for these types though. This is used in a
-similar way to the predefined types in the "TMED" frame, but without
-parentheses. If this frame is not present audio type is assumed to be
-"MPG". <span class="anchor" id="line-312"></span><span class="anchor" id="line-313"></span></p><p class="line867"><span class="anchor" id="TIME"></span> <span class="anchor" id="line-314"></span></p><dl><dt>TIME</dt><dd>The
-'Time' frame is a numeric string in the HHMM format containing the time
-for the recording. This field is always four characters long. <span class="anchor" id="line-315"></span><span class="anchor" id="line-316"></span></dd></dl><p class="line867"><span class="anchor" id="TIT1"></span> <span class="anchor" id="line-317"></span></p><dl><dt>TIT1</dt><dd>The
-'Content group description' frame is used if the sound belongs to a
-larger category of sounds/music. For example, classical music is often
-sorted in different musical sections (e.g. "Piano Concerto", "Weather -
-Hurricane"). <span class="anchor" id="line-318"></span><span class="anchor" id="line-319"></span></dd></dl><p class="line867"><span class="anchor" id="TIT2"></span> <span class="anchor" id="line-320"></span></p><dl><dt>TIT2</dt><dd>The 'Title/Songname/Content description' frame is the actual name of the piece (e.g. "Adagio", "Hurricane Donna"). <span class="anchor" id="line-321"></span><span class="anchor" id="line-322"></span></dd></dl><p class="line867"><span class="anchor" id="TIT3"></span> <span class="anchor" id="line-323"></span></p><dl><dt>TIT3</dt><dd>The
-'Subtitle/Description refinement' frame is used for information
-directly related to the contents title (e.g. "Op. 16" or "Performed
-live at Wembley"). <span class="anchor" id="line-324"></span><span class="anchor" id="line-325"></span></dd></dl><p class="line867"><span class="anchor" id="TKEY"></span> <span class="anchor" id="line-326"></span></p><dl><dt>TKEY</dt><dd>The
-'Initial key' frame contains the musical key in which the sound starts.
-It is represented as a string with a maximum length of three
-characters. The ground keys are represented with "A","B","C","D","E",
-"F" and "G" and halfkeys represented with "b" and "#". Minor is
-represented as "m". Example "Cbm". Off key is represented with an "o"
-only. <span class="anchor" id="line-327"></span><span class="anchor" id="line-328"></span></dd></dl><p class="line867"><span class="anchor" id="TLAN"></span> <span class="anchor" id="line-329"></span></p><dl><dt>TLAN</dt><dd>The
-'Language(s)' frame should contain the languages of the text or lyrics
-spoken or sung in the audio. The language is represented with three
-characters according to ISO-639-2. If more than one language is used in
-the text their language codes should follow according to their usage. <span class="anchor" id="line-330"></span><span class="anchor" id="line-331"></span></dd></dl><p class="line867"><span class="anchor" id="TLEN"></span> <span class="anchor" id="line-332"></span></p><dl><dt>TLEN</dt><dd>The 'Length' frame contains the length of the audiofile in milliseconds, represented as a numeric string. <span class="anchor" id="line-333"></span><span class="anchor" id="line-334"></span></dd></dl><p class="line867"><span class="anchor" id="TMED"></span> <span class="anchor" id="line-335"></span></p><dl><dt>TMED</dt><dd>The
-'Media type' frame describes from which media the sound originated.
-This may be a text string or a reference to the predefined media types
-found in the list below. References are made within "(" and ")" and are
-optionally followed by a text refinement, e.g. "(MC) with four
-channels". If a text refinement should begin with a "(" character it
-should be replaced with "((" in the same way as in the "TCO" frame.
-Predefined refinements is appended after the media type, e.g. "(CD/A)"
-or "(VID/PAL/VHS)". <span class="anchor" id="line-336"></span><pre>DIG Other digital media
-<span class="anchor" id="line-337"></span> /A Analog transfer from media
-<span class="anchor" id="line-338"></span>
-<span class="anchor" id="line-339"></span>ANA Other analog media
-<span class="anchor" id="line-340"></span> /WAC Wax cylinder
-<span class="anchor" id="line-341"></span> /8CA 8-track tape cassette
-<span class="anchor" id="line-342"></span>
-<span class="anchor" id="line-343"></span>CD CD
-<span class="anchor" id="line-344"></span> /A Analog transfer from media
-<span class="anchor" id="line-345"></span> /DD DDD
-<span class="anchor" id="line-346"></span> /AD ADD
-<span class="anchor" id="line-347"></span> /AA AAD
-<span class="anchor" id="line-348"></span>
-<span class="anchor" id="line-349"></span>LD Laserdisc
-<span class="anchor" id="line-350"></span> /A Analog transfer from media
-<span class="anchor" id="line-351"></span>
-<span class="anchor" id="line-352"></span>TT Turntable records
-<span class="anchor" id="line-353"></span> /33 33.33 rpm
-<span class="anchor" id="line-354"></span> /45 45 rpm
-<span class="anchor" id="line-355"></span> /71 71.29 rpm
-<span class="anchor" id="line-356"></span> /76 76.59 rpm
-<span class="anchor" id="line-357"></span> /78 78.26 rpm
-<span class="anchor" id="line-358"></span> /80 80 rpm
-<span class="anchor" id="line-359"></span>
-<span class="anchor" id="line-360"></span>MD MiniDisc
-<span class="anchor" id="line-361"></span> /A Analog transfer from media
-<span class="anchor" id="line-362"></span>
-<span class="anchor" id="line-363"></span>DAT DAT
-<span class="anchor" id="line-364"></span> /A Analog transfer from media
-<span class="anchor" id="line-365"></span> /1 standard, 48 kHz/16 bits, linear
-<span class="anchor" id="line-366"></span> /2 mode 2, 32 kHz/16 bits, linear
-<span class="anchor" id="line-367"></span> /3 mode 3, 32 kHz/12 bits, nonlinear, low speed
-<span class="anchor" id="line-368"></span> /4 mode 4, 32 kHz/12 bits, 4 channels
-<span class="anchor" id="line-369"></span> /5 mode 5, 44.1 kHz/16 bits, linear
-<span class="anchor" id="line-370"></span> /6 mode 6, 44.1 kHz/16 bits, 'wide track' play
-<span class="anchor" id="line-371"></span>
-<span class="anchor" id="line-372"></span>DCC DCC
-<span class="anchor" id="line-373"></span> /A Analog transfer from media
-<span class="anchor" id="line-374"></span>
-<span class="anchor" id="line-375"></span>DVD DVD
-<span class="anchor" id="line-376"></span> /A Analog transfer from media
-<span class="anchor" id="line-377"></span>
-<span class="anchor" id="line-378"></span>TV Television
-<span class="anchor" id="line-379"></span> /PAL PAL
-<span class="anchor" id="line-380"></span> /NTSC NTSC
-<span class="anchor" id="line-381"></span> /SECAM SECAM
-<span class="anchor" id="line-382"></span>
-<span class="anchor" id="line-383"></span>VID Video
-<span class="anchor" id="line-384"></span> /PAL PAL
-<span class="anchor" id="line-385"></span> /NTSC NTSC
-<span class="anchor" id="line-386"></span> /SECAM SECAM
-<span class="anchor" id="line-387"></span> /VHS VHS
-<span class="anchor" id="line-388"></span> /SVHS S-VHS
-<span class="anchor" id="line-389"></span> /BETA BETAMAX
-<span class="anchor" id="line-390"></span>
-<span class="anchor" id="line-391"></span>RAD Radio
-<span class="anchor" id="line-392"></span> /FM FM
-<span class="anchor" id="line-393"></span> /AM AM
-<span class="anchor" id="line-394"></span> /LW LW
-<span class="anchor" id="line-395"></span> /MW MW
-<span class="anchor" id="line-396"></span>
-<span class="anchor" id="line-397"></span>TEL Telephone
-<span class="anchor" id="line-398"></span> /I ISDN
-<span class="anchor" id="line-399"></span>
-<span class="anchor" id="line-400"></span>MC MC (normal cassette)
-<span class="anchor" id="line-401"></span> /4 4.75 cm/s (normal speed for a two sided cassette)
-<span class="anchor" id="line-402"></span> /9 9.5 cm/s
-<span class="anchor" id="line-403"></span> /I Type I cassette (ferric/normal)
-<span class="anchor" id="line-404"></span> /II Type II cassette (chrome)
-<span class="anchor" id="line-405"></span> /III Type III cassette (ferric chrome)
-<span class="anchor" id="line-406"></span> /IV Type IV cassette (metal)
-<span class="anchor" id="line-407"></span>
-<span class="anchor" id="line-408"></span>REE Reel
-<span class="anchor" id="line-409"></span> /9 9.5 cm/s
-<span class="anchor" id="line-410"></span> /19 19 cm/s
-<span class="anchor" id="line-411"></span> /38 38 cm/s
-<span class="anchor" id="line-412"></span> /76 76 cm/s
-<span class="anchor" id="line-413"></span> /I Type I cassette (ferric/normal)
-<span class="anchor" id="line-414"></span> /II Type II cassette (chrome)
-<span class="anchor" id="line-415"></span> /III Type III cassette (ferric chrome)
-<span class="anchor" id="line-416"></span> /IV Type IV cassette (metal)
-<span class="anchor" id="line-417"></span></pre><span class="anchor" id="line-418"></span><span class="anchor" id="line-419"></span></dd></dl><p class="line867"><span class="anchor" id="TOAL"></span> <span class="anchor" id="line-420"></span></p><dl><dt>TOAL</dt><dd>The
-'Original album/movie/show title' frame is intended for the title of
-the original recording (or source of sound), if for example the music
-in the file should be a cover of a previously released song. <span class="anchor" id="line-421"></span><span class="anchor" id="line-422"></span></dd></dl><p class="line867"><span class="anchor" id="TOFN"></span> <span class="anchor" id="line-423"></span></p><dl><dt>TOFN</dt><dd>The
-'Original filename' frame contains the preferred filename for the file,
-since some media doesn't allow the desired length of the filename. The
-filename is case sensitive and includes its suffix. <span class="anchor" id="line-424"></span><span class="anchor" id="line-425"></span></dd></dl><p class="line867"><span class="anchor" id="TOLY"></span> <span class="anchor" id="line-426"></span></p><dl><dt>TOLY</dt><dd>The
-'Original lyricist(s)/text writer(s)' frame is intended for the text
-writer(s) of the original recording, if for example the music in the
-file should be a cover of a previously released song. The text writers
-are seperated with the "/" character. <span class="anchor" id="line-427"></span><span class="anchor" id="line-428"></span></dd></dl><p class="line867"><span class="anchor" id="TOPE"></span> <span class="anchor" id="line-429"></span></p><dl><dt>TOPE</dt><dd>The
-'Original artist(s)/performer(s)' frame is intended for the
-performer(s) of the original recording, if for example the music in the
-file should be a cover of a previously released song. The performers
-are seperated with the "/" character. <span class="anchor" id="line-430"></span><span class="anchor" id="line-431"></span></dd></dl><p class="line867"><span class="anchor" id="TORY"></span> <span class="anchor" id="line-432"></span></p><dl><dt>TORY</dt><dd>The
-'Original release year' frame is intended for the year when the
-original recording, if for example the music in the file should be a
-cover of a previously released song, was released. The field is
-formatted as in the "TYER" frame. <span class="anchor" id="line-433"></span><span class="anchor" id="line-434"></span></dd></dl><p class="line867"><span class="anchor" id="TOWN"></span> <span class="anchor" id="line-435"></span></p><dl><dt>TOWN</dt><dd>The 'File owner/licensee' frame contains the name of the owner or licensee of the file and it's contents. <span class="anchor" id="line-436"></span><span class="anchor" id="line-437"></span></dd></dl><p class="line867"><span class="anchor" id="TPE1"></span> <span class="anchor" id="line-438"></span></p><dl><dt>TPE1</dt><dd>The
-'Lead artist(s)/Lead performer(s)/Soloist(s)/Performing group' is used
-for the main artist(s). They are seperated with the "/" character. <span class="anchor" id="line-439"></span><span class="anchor" id="line-440"></span></dd></dl><p class="line867"><span class="anchor" id="TPE2"></span> <span class="anchor" id="line-441"></span></p><dl><dt>TPE2</dt><dd>The 'Band/Orchestra/Accompaniment' frame is used for additional information about the performers in the recording. <span class="anchor" id="line-442"></span><span class="anchor" id="line-443"></span></dd></dl><p class="line867"><span class="anchor" id="TPE3"></span> <span class="anchor" id="line-444"></span></p><dl><dt>TPE3</dt><dd>The 'Conductor' frame is used for the name of the conductor. <span class="anchor" id="line-445"></span><span class="anchor" id="line-446"></span></dd></dl><p class="line867"><span class="anchor" id="TPE4"></span> <span class="anchor" id="line-447"></span></p><dl><dt>TPE4</dt><dd>The
-'Interpreted, remixed, or otherwise modified by' frame contains more
-information about the people behind a remix and similar interpretations
-of another existing piece. <span class="anchor" id="line-448"></span><span class="anchor" id="line-449"></span></dd></dl><p class="line867"><span class="anchor" id="TPOS"></span> <span class="anchor" id="line-450"></span></p><dl><dt>TPOS</dt><dd>The
-'Part of a set' frame is a numeric string that describes which part of
-a set the audio came from. This frame is used if the source described
-in the "TALB" frame is divided into several mediums, e.g. a double CD.
-The value may be extended with a "/" character and a numeric string
-containing the total number of parts in the set. E.g. "1/2". <span class="anchor" id="line-451"></span><span class="anchor" id="line-452"></span></dd></dl><p class="line867"><span class="anchor" id="TPUB"></span> <span class="anchor" id="line-453"></span></p><dl><dt>TPUB</dt><dd>The 'Publisher' frame simply contains the name of the label or publisher. <span class="anchor" id="line-454"></span><span class="anchor" id="line-455"></span></dd></dl><p class="line867"><span class="anchor" id="TRCK"></span> <span class="anchor" id="line-456"></span></p><dl><dt>TRCK</dt><dd>The
-'Track number/Position in set' frame is a numeric string containing the
-order number of the audio-file on its original recording. This may be
-extended with a "/" character and a numeric string containing the total
-numer of tracks/elements on the original recording. E.g. "4/9". <span class="anchor" id="line-457"></span><span class="anchor" id="line-458"></span></dd></dl><p class="line867"><span class="anchor" id="TRDA"></span> <span class="anchor" id="line-459"></span></p><dl><dt>TRDA</dt><dd>The
-'Recording dates' frame is a intended to be used as complement to the
-"TYER", "TDAT" and "TIME" frames. E.g. "4th-7th June, 12th June" in
-combination with the "TYER" frame. <span class="anchor" id="line-460"></span><span class="anchor" id="line-461"></span></dd></dl><p class="line867"><span class="anchor" id="TRSN"></span> <span class="anchor" id="line-462"></span></p><dl><dt>TRSN</dt><dd>The 'Internet radio station name' frame contains the name of the internet radio station from which the audio is streamed. <span class="anchor" id="line-463"></span><span class="anchor" id="line-464"></span></dd></dl><p class="line867"><span class="anchor" id="TRSO"></span> <span class="anchor" id="line-465"></span></p><dl><dt>TRSO</dt><dd>The
-'Internet radio station owner' frame contains the name of the owner of
-the internet radio station from which the audio is streamed. <span class="anchor" id="line-466"></span><span class="anchor" id="line-467"></span></dd></dl><p class="line867"><span class="anchor" id="TSIZ"></span> <span class="anchor" id="line-468"></span></p><dl><dt>TSIZ</dt><dd>The 'Size' frame contains the size of the audiofile in bytes, excluding the ID3v2 tag, represented as a numeric string. <span class="anchor" id="line-469"></span><span class="anchor" id="line-470"></span></dd></dl><p class="line867"><span class="anchor" id="TSRC"></span> <span class="anchor" id="line-471"></span></p><dl><dt>TSRC</dt><dd>The 'ISRC' frame should contain the International Standard Recording Code (ISRC) (12 characters). <span class="anchor" id="line-472"></span><span class="anchor" id="line-473"></span></dd></dl><p class="line867"><span class="anchor" id="TSSE"></span> <span class="anchor" id="line-474"></span></p><dl><dt>TSSE</dt><dd>The
-'Software/Hardware and settings used for encoding' frame includes the
-used audio encoder and its settings when the file was encoded. Hardware
-refers to hardware encoders, not the computer on which a program was
-run. <span class="anchor" id="line-475"></span><span class="anchor" id="line-476"></span></dd></dl><p class="line867"><span class="anchor" id="TYER"></span> <span class="anchor" id="line-477"></span></p><dl><dt>TYER</dt><dd>The
-'Year' frame is a numeric string with a year of the recording. This
-frames is always four characters long (until the year 10000). <span class="anchor" id="line-478"></span><span class="anchor" id="line-479"></span></dd></dl><p class="line867">
-</p><h3 id="head-29e37534e169ad913deb6a4fee345028f3db7c3f">4.2.2. User defined text information frame</h3>
-<span class="anchor" id="line-480"></span><span class="anchor" id="line-481"></span><p class="line874">This
-frame is intended for one-string text information concerning the
-audiofile in a similar way to the other "T"-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
-"TXXX" frame in each tag, but only one with the same description. <span class="anchor" id="line-482"></span></p><pre><Header for 'User defined text information frame', ID: "TXXX">
-<span class="anchor" id="line-483"></span>Text encoding $xx
-<span class="anchor" id="line-484"></span>Description <text string according to encoding> $00 (00)
-<span class="anchor" id="line-485"></span>Value <text string according to encoding>
-<span class="anchor" id="line-486"></span></pre><span class="anchor" id="line-487"></span><span class="anchor" id="line-488"></span><p class="line867"><span class="anchor" id="sec4.3"></span> <span class="anchor" id="line-489"></span>
-</p><h2 id="head-66afd8fc82926f98baa42eade0a5e96010a2d77f">4.3. URL link frames</h2>
-<span class="anchor" id="line-490"></span><p class="line874">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 frame identifiers begins with "W".
-Only URL link frame identifiers begins with "W". All URL link frames
-have the following format: <span class="anchor" id="line-491"></span></p><pre><Header for 'URL link frame', ID: "W000" - "WZZZ", excluding "WXXX" described in 4.3.2.>
-<span class="anchor" id="line-492"></span>URL <text string>
-<span class="anchor" id="line-493"></span></pre><span class="anchor" id="line-494"></span><span class="anchor" id="line-495"></span><p class="line867"><span class="anchor" id="sec4.3.1"></span> <span class="anchor" id="line-496"></span>
-</p><h3 id="head-871541c0b67dfb4bf890d1a2c72e7b41595b36cc">4.3.1. URL link frames - details</h3>
-<span class="anchor" id="line-497"></span><span class="anchor" id="line-498"></span><p class="line867"><span class="anchor" id="WCOM"></span> <span class="anchor" id="line-499"></span></p><dl><dt>WCOM</dt><dd>The
-'Commercial information' frame is a URL pointing at a webpage with
-information such as where the album can be bought. There may be more
-than one "WCOM" frame in a tag, but not with the same content. <span class="anchor" id="line-500"></span><span class="anchor" id="line-501"></span></dd></dl><p class="line867"><span class="anchor" id="WCOP"></span> <span class="anchor" id="line-502"></span></p><dl><dt>WCOP</dt><dd>The
-'Copyright/Legal information' frame is a URL pointing at a webpage
-where the terms of use and ownership of the file is described. <span class="anchor" id="line-503"></span><span class="anchor" id="line-504"></span></dd></dl><p class="line867"><span class="anchor" id="WOAF"></span> <span class="anchor" id="line-505"></span></p><dl><dt>WOAF</dt><dd>The 'Official audio file webpage' frame is a URL pointing at a file specific webpage. <span class="anchor" id="line-506"></span><span class="anchor" id="line-507"></span></dd></dl><p class="line867"><span class="anchor" id="WOAR"></span> <span class="anchor" id="line-508"></span></p><dl><dt>WOAR</dt><dd>The
-'Official artist/performer webpage' frame is a URL pointing at the
-artists official webpage. There may be more than one "WOAR" frame in a
-tag if the audio contains more than one performer, but not with the
-same content. <span class="anchor" id="line-509"></span><span class="anchor" id="line-510"></span></dd></dl><p class="line867"><span class="anchor" id="WOAS"></span> <span class="anchor" id="line-511"></span></p><dl><dt>WOAS</dt><dd>The
-'Official audio source webpage' frame is a URL pointing at the official
-webpage for the source of the audio file, e.g. a movie. <span class="anchor" id="line-512"></span><span class="anchor" id="line-513"></span></dd></dl><p class="line867"><span class="anchor" id="WORS"></span> <span class="anchor" id="line-514"></span></p><dl><dt>WORS</dt><dd>The 'Official internet radio station homepage' contains a URL pointing at the homepage of the internet radio station. <span class="anchor" id="line-515"></span><span class="anchor" id="line-516"></span></dd></dl><p class="line867"><span class="anchor" id="WPAY"></span> <span class="anchor" id="line-517"></span></p><dl><dt>WPAY</dt><dd>The 'Payment' frame is a URL pointing at a webpage that will handle the process of paying for this file. <span class="anchor" id="line-518"></span><span class="anchor" id="line-519"></span></dd></dl><p class="line867"><span class="anchor" id="WPUB"></span> <span class="anchor" id="line-520"></span></p><dl><dt>WPUB</dt><dd>The 'Publishers official webpage' frame is a URL pointing at the official wepage for the publisher. <span class="anchor" id="line-521"></span><span class="anchor" id="line-522"></span></dd></dl><p class="line867"><span class="anchor" id="sec4.3.2"></span> <span class="anchor" id="line-523"></span>
-</p><h3 id="head-b0e8086b6e51f25d126cd5f26d13696defb44aa9">4.3.2. User defined URL link frame</h3>
-<span class="anchor" id="line-524"></span><span class="anchor" id="line-525"></span><p class="line874">This
-frame is intended for URL links concerning the audiofile in a similar
-way to the other "W"-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 "WXXX" frame in each tag, but only one with the same
-description. <span class="anchor" id="line-526"></span></p><pre><Header for 'User defined URL link frame', ID: "WXXX">
-<span class="anchor" id="line-527"></span>Text encoding $xx
-<span class="anchor" id="line-528"></span>Description <text string according to encoding> $00 (00)
-<span class="anchor" id="line-529"></span>URL <text string>
-<span class="anchor" id="line-530"></span></pre><span class="anchor" id="line-531"></span><p class="line867"><span class="anchor" id="sec4.4"></span> <span class="anchor" id="line-532"></span>
-</p><h2 id="head-a0ac5e01361fd414b67a39130716fea4c970e004">4.4. Involved people list</h2>
-<span class="anchor" id="line-533"></span><span class="anchor" id="line-534"></span><p class="line874">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 "IPLS" frame in each tag. <span class="anchor" id="line-535"></span></p><pre><Header for 'Involved people list', ID: "IPLS">
-<span class="anchor" id="line-536"></span>Text encoding $xx
-<span class="anchor" id="line-537"></span>People list strings <text strings according to encoding>
-<span class="anchor" id="line-538"></span></pre><span class="anchor" id="line-539"></span><span class="anchor" id="line-540"></span><p class="line867"><span class="anchor" id="sec4.5"></span> <span class="anchor" id="line-541"></span>
-</p><h2 id="head-f56120ef5f24045436031b86131ce297b0e43f42">4.5. Music CD identifier</h2>
-<span class="anchor" id="line-542"></span><span class="anchor" id="line-543"></span><p class="line874">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 plus 8 bytes for the
-'lead out' making a maximum of 804 bytes. The offset to the beginning
-of every track on the CD should be described with a four bytes absolute
-CD-frame address per track, and not with absolute time. This frame
-requires a present and valid "TRCK" frame, even if the CD's only got
-one track. There may only be one "MCDI" frame in each tag. <span class="anchor" id="line-544"></span></p><pre><Header for 'Music CD identifier', ID: "MCDI">
-<span class="anchor" id="line-545"></span>CD TOC <binary data>
-<span class="anchor" id="line-546"></span></pre><span class="anchor" id="line-547"></span><span class="anchor" id="line-548"></span><p class="line867"><span class="anchor" id="sec4.6"></span> <span class="anchor" id="line-549"></span>
-</p><h2 id="head-d302f218df2a0868b706d1525e9cc78ebcb86e16">4.6. Event timing codes</h2>
-<span class="anchor" id="line-550"></span><span class="anchor" id="line-551"></span><p class="line874">This frame allows synchronisation with key events in a song or sound. The header is: <span class="anchor" id="line-552"></span></p><pre><Header for 'Event timing codes', ID: "ETCO">
-<span class="anchor" id="line-553"></span>Time stamp format $xx
-<span class="anchor" id="line-554"></span></pre><span class="anchor" id="line-555"></span><span class="anchor" id="line-556"></span><p class="line874">Where time stamp format is: <span class="anchor" id="line-557"></span></p><pre>$01 Absolute time, 32 bit sized, using MPEG frames as unit
-<span class="anchor" id="line-558"></span>$02 Absolute time, 32 bit sized, using milliseconds as unit
-<span class="anchor" id="line-559"></span></pre><span class="anchor" id="line-560"></span><p class="line874">Abolute time means that every stamp contains the time from the beginning of the file. <span class="anchor" id="line-561"></span><span class="anchor" id="line-562"></span></p><p class="line874">Followed by a list of key events in the following format: <span class="anchor" id="line-563"></span></p><pre>Type of event $xx
-<span class="anchor" id="line-564"></span>Time stamp $xx (xx ...)
-<span class="anchor" id="line-565"></span></pre><span class="anchor" id="line-566"></span><p class="line874">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: <span class="anchor" id="line-567"></span></p><pre>$00 padding (has no meaning)
-<span class="anchor" id="line-568"></span>$01 end of initial silence
-<span class="anchor" id="line-569"></span>$02 intro start
-<span class="anchor" id="line-570"></span>$03 mainpart start
-<span class="anchor" id="line-571"></span>$04 outro start
-<span class="anchor" id="line-572"></span>$05 outro end
-<span class="anchor" id="line-573"></span>$06 verse start
-<span class="anchor" id="line-574"></span>$07 refrain start
-<span class="anchor" id="line-575"></span>$08 interlude start
-<span class="anchor" id="line-576"></span>$09 theme start
-<span class="anchor" id="line-577"></span>$0A variation start
-<span class="anchor" id="line-578"></span>$0B key change
-<span class="anchor" id="line-579"></span>$0C time change
-<span class="anchor" id="line-580"></span>$0D momentary unwanted noise (Snap, Crackle & Pop)
-<span class="anchor" id="line-581"></span>$0E sustained noise
-<span class="anchor" id="line-582"></span>$0F sustained noise end
-<span class="anchor" id="line-583"></span>$10 intro end
-<span class="anchor" id="line-584"></span>$11 mainpart end
-<span class="anchor" id="line-585"></span>$12 verse end
-<span class="anchor" id="line-586"></span>$13 refrain end
-<span class="anchor" id="line-587"></span>$14 theme end
-<span class="anchor" id="line-588"></span>$15-$DF reserved for future use
-<span class="anchor" id="line-589"></span>$E0-$EF not predefined sync 0-F
-<span class="anchor" id="line-590"></span>$F0-$FC reserved for future use
-<span class="anchor" id="line-591"></span>$FD audio end (start of silence)
-<span class="anchor" id="line-592"></span>$FE audio file ends
-<span class="anchor" id="line-593"></span>$FF one more byte of events follows (all the following bytes with the value $FF have the same function)
-<span class="anchor" id="line-594"></span></pre><span class="anchor" id="line-595"></span><p class="line874">Terminating
-the start events such as "intro start" is not required. 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. <span class="anchor" id="line-596"></span><span class="anchor" id="line-597"></span></p><p class="line874">There may only be one "ETCO" frame in each tag. <span class="anchor" id="line-598"></span><span class="anchor" id="line-599"></span></p><p class="line867"><span class="anchor" id="sec4.7"></span> <span class="anchor" id="line-600"></span>
-</p><h2 id="head-febc618121880ee751b0c2a87327b0e698213dc4">4.7. MPEG location lookup table</h2>
-<span class="anchor" id="line-601"></span><span class="anchor" id="line-602"></span><p class="line874">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 ID3v2 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. <span class="anchor" id="line-603"></span><span class="anchor" id="line-604"></span></p><p class="line874">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 "MLLT" frame in each tag. <span class="anchor" id="line-605"></span><span class="anchor" id="line-606"></span></p><p class="line867"></p><pre><Header for 'Location lookup table', ID: "MLLT">
-<span class="anchor" id="line-607"></span>MPEG frames between reference $xx xx
-<span class="anchor" id="line-608"></span>Bytes between reference $xx xx xx
-<span class="anchor" id="line-609"></span>Milliseconds between reference $xx xx xx
-<span class="anchor" id="line-610"></span>Bits for bytes deviation $xx
-<span class="anchor" id="line-611"></span>Bits for milliseconds dev. $xx
-<span class="anchor" id="line-612"></span></pre><span class="anchor" id="line-613"></span><p class="line874">Then for every reference the following data is included; <span class="anchor" id="line-614"></span><span class="anchor" id="line-615"></span></p><p class="line867"></p><pre>Deviation in bytes %xxx....
-<span class="anchor" id="line-616"></span>Deviation in milliseconds %xxx....
-<span class="anchor" id="line-617"></span></pre><span class="anchor" id="line-618"></span><span class="anchor" id="line-619"></span><p class="line867"><span class="anchor" id="sec4.8"></span> <span class="anchor" id="line-620"></span>
-</p><h2 id="head-9804169dd0fc7e12a1050a02d3419e6b3dc4f5e9">4.8. Synchronised tempo codes</h2>
-<span class="anchor" id="line-621"></span><span class="anchor" id="line-622"></span><p class="line874">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. <span class="anchor" id="line-623"></span><span class="anchor" id="line-624"></span></p><p class="line874">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 "SYTC" frame in each tag. <span class="anchor" id="line-625"></span><span class="anchor" id="line-626"></span></p><p class="line867"></p><pre><Header for 'Synchronised tempo codes', ID: "SYTC">
-<span class="anchor" id="line-627"></span>Time stamp format $xx
-<span class="anchor" id="line-628"></span>Tempo data <binary data>
-<span class="anchor" id="line-629"></span></pre><span class="anchor" id="line-630"></span><p class="line874">Where time stamp format is: <span class="anchor" id="line-631"></span><span class="anchor" id="line-632"></span></p><p class="line867"></p><pre>$01 Absolute time, 32 bit sized, using MPEG frames as unit
-<span class="anchor" id="line-633"></span>$02 Absolute time, 32 bit sized, using milliseconds as unit
-<span class="anchor" id="line-634"></span></pre><span class="anchor" id="line-635"></span><p class="line874">Abolute time means that every stamp contains the time from the beginning of the file. <span class="anchor" id="line-636"></span><span class="anchor" id="line-637"></span></p><p class="line867"><span class="anchor" id="sec4.9"></span> <span class="anchor" id="line-638"></span>
-</p><h2 id="head-e76d4fb26268baf285bff899581cc284427a2789">4.9. Unsychronised lyrics/text transcription</h2>
-<span class="anchor" id="line-639"></span><span class="anchor" id="line-640"></span><p class="line874">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. There may be more than one 'Unsynchronised lyrics/text
-transcription' frame in each tag, but only one with the same language
-and content descriptor. <span class="anchor" id="line-641"></span><span class="anchor" id="line-642"></span></p><p class="line867"></p><pre><Header for 'Unsynchronised lyrics/text transcription', ID: "USLT">
-<span class="anchor" id="line-643"></span>Text encoding $xx
-<span class="anchor" id="line-644"></span>Language $xx xx xx
-<span class="anchor" id="line-645"></span>Content descriptor <text string according to encoding> $00 (00)
-<span class="anchor" id="line-646"></span>Lyrics/text <full text string according to encoding>
-<span class="anchor" id="line-647"></span></pre><span class="anchor" id="line-648"></span><span class="anchor" id="line-649"></span><p class="line867"><span class="anchor" id="sec4.10"></span> <span class="anchor" id="line-650"></span>
-</p><h2 id="head-792dcad788fe1b8bcd7f9d7e9eec7549e1864546">4.10. Synchronised lyrics/text</h2>
-<span class="anchor" id="line-651"></span><span class="anchor" id="line-652"></span><p class="line874">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. <span class="anchor" id="line-653"></span><span class="anchor" id="line-654"></span></p><p class="line867"></p><pre><Header for 'Synchronised lyrics/text', ID: "SYLT">
-<span class="anchor" id="line-655"></span>Text encoding $xx
-<span class="anchor" id="line-656"></span>Language $xx xx xx
-<span class="anchor" id="line-657"></span>Time stamp format $xx
-<span class="anchor" id="line-658"></span>Content type $xx
-<span class="anchor" id="line-659"></span>Content descriptor <text string according to encoding> $00 (00)
-<span class="anchor" id="line-660"></span></pre><span class="anchor" id="line-661"></span><span class="anchor" id="line-662"></span><p class="line874">Encoding: <span class="anchor" id="line-663"></span></p><pre>$00 ISO-8859-1 character set is used => $00 is sync identifier.
-<span class="anchor" id="line-664"></span>$01 Unicode character set is used => $00 00 is sync identifier.
-<span class="anchor" id="line-665"></span></pre><span class="anchor" id="line-666"></span><span class="anchor" id="line-667"></span><p class="line874">Content type: <span class="anchor" id="line-668"></span></p><pre>$00 is other
-<span class="anchor" id="line-669"></span>$01 is lyrics
-<span class="anchor" id="line-670"></span>$02 is text transcription
-<span class="anchor" id="line-671"></span>$03 is movement/part name (e.g. "Adagio")
-<span class="anchor" id="line-672"></span>$04 is events (e.g. "Don Quijote enters the stage")
-<span class="anchor" id="line-673"></span>$05 is chord (e.g. "Bb F Fsus")
-<span class="anchor" id="line-674"></span>$06 is trivia/'pop up' information
-<span class="anchor" id="line-675"></span></pre><span class="anchor" id="line-676"></span><p class="line874">Time stamp format is: <span class="anchor" id="line-677"></span><span class="anchor" id="line-678"></span></p><pre>$01 Absolute time, 32 bit sized, using MPEG frames as unit
-<span class="anchor" id="line-679"></span>$02 Absolute time, 32 bit sized, using milliseconds as unit
-<span class="anchor" id="line-680"></span></pre><span class="anchor" id="line-681"></span><span class="anchor" id="line-682"></span><p class="line874">Abolute time means that every stamp contains the time from the beginning of the file. <span class="anchor" id="line-683"></span><span class="anchor" id="line-684"></span></p><p class="line874">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: <span class="anchor" id="line-685"></span><span class="anchor" id="line-686"></span></p><p class="line867"></p><pre>Terminated text to be synced (typically a syllable)
-<span class="anchor" id="line-687"></span>Sync identifier (terminator to above string) $00 (00)
-<span class="anchor" id="line-688"></span>Time stamp $xx (xx ...)
-<span class="anchor" id="line-689"></span></pre><span class="anchor" id="line-690"></span><span class="anchor" id="line-691"></span><p class="line874">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. <span class="anchor" id="line-692"></span><span class="anchor" id="line-693"></span></p><p class="line874">Newline
-($0A) characters are allowed in all "SYLT" frames and should be used
-after every entry (name, event etc.) in a frame with the content type
-$03 - $04. <span class="anchor" id="line-694"></span><span class="anchor" id="line-695"></span></p><p class="line874">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). <span class="anchor" id="line-696"></span><span class="anchor" id="line-697"></span></p><p class="line874">An example: The "USLT" passage <span class="anchor" id="line-698"></span><span class="anchor" id="line-699"></span></p><p class="line867"></p><pre>"Strangers in the night" $0A "Exchanging glances"
-<span class="anchor" id="line-700"></span></pre><span class="anchor" id="line-701"></span><span class="anchor" id="line-702"></span><p class="line874">would be "SYLT" encoded as: <span class="anchor" id="line-703"></span><span class="anchor" id="line-704"></span></p><p class="line867"></p><pre>"Strang" $00 xx xx "ers" $00 xx xx " in" $00 xx xx " the" $00
-<span class="anchor" id="line-705"></span>xx xx " night" $00 xx xx 0A "Ex" $00 xx xx "chang" $00 xx xx
-<span class="anchor" id="line-706"></span>"ing" $00 xx xx "glan" $00 xx xx "ces" $00 xx xx
-<span class="anchor" id="line-707"></span></pre><span class="anchor" id="line-708"></span><span class="anchor" id="line-709"></span><p class="line874">There may be more than one "SYLT" frame in each tag, but only one with the same language and content descriptor. <span class="anchor" id="line-710"></span><span class="anchor" id="line-711"></span></p><p class="line867"><span class="anchor" id="sec4.11"></span> <span class="anchor" id="line-712"></span>
-</p><h2 id="head-31c41e8642534f1854246708af84f7d2c8d39684">4.11. Comments</h2>
-<span class="anchor" id="line-713"></span><span class="anchor" id="line-714"></span><p class="line874">This
-frame is indended for any kind of full text information that does not
-fit in any other frame. It consists of a frame header 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. <span class="anchor" id="line-715"></span><span class="anchor" id="line-716"></span></p><p class="line867"></p><pre><Header for 'Comment', ID: "COMM">
-<span class="anchor" id="line-717"></span>Text encoding $xx
-<span class="anchor" id="line-718"></span>Language $xx xx xx
-<span class="anchor" id="line-719"></span>Short content descrip. <text string according to encoding> $00 (00)
-<span class="anchor" id="line-720"></span>The actual text <full text string according to encoding>
-<span class="anchor" id="line-721"></span></pre><span class="anchor" id="line-722"></span><span class="anchor" id="line-723"></span><p class="line867"><span class="anchor" id="sec4.12"></span> <span class="anchor" id="line-724"></span>
-</p><h2 id="head-d3d2bfba9882a197c1b55a80f52bb676653d3604">4.12. Relative volume adjustment</h2>
-<span class="anchor" id="line-725"></span><span class="anchor" id="line-726"></span><p class="line874">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, if no
-other data follows, be completely omitted. There may only be one "RVAD"
-frame in each tag. <span class="anchor" id="line-727"></span><span class="anchor" id="line-728"></span></p><p class="line867"></p><pre><Header for 'Relative volume adjustment', ID: "RVAD">
-<span class="anchor" id="line-729"></span>Increment/decrement %00xxxxxx
-<span class="anchor" id="line-730"></span>Bits used for volume descr. $xx
-<span class="anchor" id="line-731"></span>Relative volume change, right $xx xx (xx ...)
-<span class="anchor" id="line-732"></span>Relative volume change, left $xx xx (xx ...)
-<span class="anchor" id="line-733"></span>Peak volume right $xx xx (xx ...)
-<span class="anchor" id="line-734"></span>Peak volume left $xx xx (xx ...)
-<span class="anchor" id="line-735"></span></pre><span class="anchor" id="line-736"></span><span class="anchor" id="line-737"></span><p class="line874">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. <span class="anchor" id="line-738"></span><span class="anchor" id="line-739"></span></p><p class="line874">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. <span class="anchor" id="line-740"></span><span class="anchor" id="line-741"></span></p><p class="line874">This
-datablock is then optionally followed by a volume definition for the
-left and right back channels. If this information is appended to the
-frame the first two channels will be treated as front channels. In the
-increment/decrement field bit 2 is used to indicate the right back
-channel and bit 3 for the left back channel. <span class="anchor" id="line-742"></span><span class="anchor" id="line-743"></span></p><p class="line867"></p><pre>Relative volume change, right back $xx xx (xx ...)
-<span class="anchor" id="line-744"></span>Relative volume change, left back $xx xx (xx ...)
-<span class="anchor" id="line-745"></span>Peak volume right back $xx xx (xx ...)
-<span class="anchor" id="line-746"></span>Peak volume left back $xx xx (xx ...)
-<span class="anchor" id="line-747"></span></pre><span class="anchor" id="line-748"></span><p class="line874">If
-the center channel adjustment is present the following is appended to
-the existing frame, after the left and right back channels. The center
-channel is represented by bit 4 in the increase/decrease field. <span class="anchor" id="line-749"></span><span class="anchor" id="line-750"></span></p><p class="line867"></p><pre>Relative volume change, center $xx xx (xx ...)
-<span class="anchor" id="line-751"></span>Peak volume center $xx xx (xx ...)
-<span class="anchor" id="line-752"></span></pre><span class="anchor" id="line-753"></span><span class="anchor" id="line-754"></span><p class="line874">If
-the bass channel adjustment is present the following is appended to the
-existing frame, after the center channel. The bass channel is
-represented by bit 5 in the increase/decrease field. <span class="anchor" id="line-755"></span><span class="anchor" id="line-756"></span></p><p class="line867"></p><pre>Relative volume change, bass $xx xx (xx ...)
-<span class="anchor" id="line-757"></span>Peak volume bass $xx xx (xx ...)
-<span class="anchor" id="line-758"></span></pre><span class="anchor" id="line-759"></span><span class="anchor" id="line-760"></span><p class="line867"><span class="anchor" id="sec4.13"></span> <span class="anchor" id="line-761"></span>
-</p><h2 id="head-3d14382e1cdc086bc43df0f0b0e63cf0c33f7c64">4.13. Equalisation</h2>
-<span class="anchor" id="line-762"></span><span class="anchor" id="line-763"></span><p class="line874">This
-is another subjective, alignment frame. It allows the user to predefine
-an equalisation curve within the audio file. There may only be one
-"EQUA" frame in each tag. <span class="anchor" id="line-764"></span><span class="anchor" id="line-765"></span></p><p class="line867"></p><pre><Header of 'Equalisation', ID: "EQUA">
-<span class="anchor" id="line-766"></span>Adjustment bits $xx
-<span class="anchor" id="line-767"></span></pre><span class="anchor" id="line-768"></span><span class="anchor" id="line-769"></span><p class="line874">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. <span class="anchor" id="line-770"></span><span class="anchor" id="line-771"></span></p><p class="line874">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: <span class="anchor" id="line-772"></span></p><pre>Increment/decrement %x (MSB of the Frequency)
-<span class="anchor" id="line-773"></span>Frequency (lower 15 bits)
-<span class="anchor" id="line-774"></span>Adjustment $xx (xx ...)
-<span class="anchor" id="line-775"></span></pre><span class="anchor" id="line-776"></span><p class="line874">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. The equalisation
-curve in the reading software should be interpolated between the values
-in this frame. Three equal adjustments for three subsequent
-frequencies. A frequency should only be described once in the frame. <span class="anchor" id="line-777"></span><span class="anchor" id="line-778"></span></p><p class="line867">
-</p><h2 id="head-5f9be76d443047174b52f89243bbc671d7937fa3">4.14. Reverb</h2>
-<span class="anchor" id="line-779"></span><span class="anchor" id="line-780"></span><p class="line874">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, 50% of that 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. <span class="anchor" id="line-781"></span><span class="anchor" id="line-782"></span></p><p class="line874">'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 "RVRB" frame in each tag. <span class="anchor" id="line-783"></span><span class="anchor" id="line-784"></span></p><p class="line867"></p><pre><Header for 'Reverb', ID: "RVRB">
-<span class="anchor" id="line-785"></span>Reverb left (ms) $xx xx
-<span class="anchor" id="line-786"></span>Reverb right (ms) $xx xx
-<span class="anchor" id="line-787"></span>Reverb bounces, left $xx
-<span class="anchor" id="line-788"></span>Reverb bounces, right $xx
-<span class="anchor" id="line-789"></span>Reverb feedback, left to left $xx
-<span class="anchor" id="line-790"></span>Reverb feedback, left to right $xx
-<span class="anchor" id="line-791"></span>Reverb feedback, right to right $xx
-<span class="anchor" id="line-792"></span>Reverb feedback, right to left $xx
-<span class="anchor" id="line-793"></span>Premix left to right $xx
-<span class="anchor" id="line-794"></span>Premix right to left $xx
-<span class="anchor" id="line-795"></span></pre><span class="anchor" id="line-796"></span><span class="anchor" id="line-797"></span><p class="line867"><span class="anchor" id="sec4.15"></span> <span class="anchor" id="line-798"></span>
-</p><h2 id="head-70a65d30522ef0d37642224c2a40517ae35b7155">4.15. Attached picture</h2>
-<span class="anchor" id="line-799"></span><span class="anchor" id="line-800"></span><p class="line862">This
-frame contains a picture directly related to the audio file. Image
-format is the MIME type and subtype for the image. In the event that
-the MIME media type name is omitted, "image/" will be implied. The
-"image/png" or "image/jpeg" picture format should be used when
-interoperability is wanted. 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 "APIC" 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 the possibility to put only a link to the image
-file by using the 'MIME type' "-->" and having a complete URL
-instead of picture data. The use of linked files should however be used
-sparingly since there is the risk of separation of files. <span class="anchor" id="line-801"></span><span class="anchor" id="line-802"></span></p><p class="line867"></p><pre><Header for 'Attached picture', ID: "APIC">
-<span class="anchor" id="line-803"></span>Text encoding $xx
-<span class="anchor" id="line-804"></span>MIME type <text string> $00
-<span class="anchor" id="line-805"></span>Picture type $xx
-<span class="anchor" id="line-806"></span>Description <text string according to encoding> $00 (00)
-<span class="anchor" id="line-807"></span>Picture data <binary data>
-<span class="anchor" id="line-808"></span></pre><span class="anchor" id="line-809"></span><span class="anchor" id="line-810"></span><p class="line874">Picture type: <span class="anchor" id="line-811"></span></p><pre>$00 Other
-<span class="anchor" id="line-812"></span>$01 32x32 pixels 'file icon' (PNG only)
-<span class="anchor" id="line-813"></span>$02 Other file icon
-<span class="anchor" id="line-814"></span>$03 Cover (front)
-<span class="anchor" id="line-815"></span>$04 Cover (back)
-<span class="anchor" id="line-816"></span>$05 Leaflet page
-<span class="anchor" id="line-817"></span>$06 Media (e.g. lable side of CD)
-<span class="anchor" id="line-818"></span>$07 Lead artist/lead performer/soloist
-<span class="anchor" id="line-819"></span>$08 Artist/performer
-<span class="anchor" id="line-820"></span>$09 Conductor
-<span class="anchor" id="line-821"></span>$0A Band/Orchestra
-<span class="anchor" id="line-822"></span>$0B Composer
-<span class="anchor" id="line-823"></span>$0C Lyricist/text writer
-<span class="anchor" id="line-824"></span>$0D Recording Location
-<span class="anchor" id="line-825"></span>$0E During recording
-<span class="anchor" id="line-826"></span>$0F During performance
-<span class="anchor" id="line-827"></span>$10 Movie/video screen capture
-<span class="anchor" id="line-828"></span>$11 A bright coloured fish
-<span class="anchor" id="line-829"></span>$12 Illustration
-<span class="anchor" id="line-830"></span>$13 Band/artist logotype
-<span class="anchor" id="line-831"></span>$14 Publisher/Studio logotype
-<span class="anchor" id="line-832"></span></pre><span class="anchor" id="line-833"></span><span class="anchor" id="line-834"></span><p class="line867"><span class="anchor" id="sec4.16"></span> <span class="anchor" id="line-835"></span>
-</p><h2 id="head-060e0e68febc214cad81328a2baf7fd1ce17b59b">4.16. General encapsulated object</h2>
-<span class="anchor" id="line-836"></span><span class="anchor" id="line-837"></span><p class="line874">In
-this frame any type of file can be encapsulated. After the header,
-'Frame size' and 'Encoding' follows 'MIME type' represented as as a
-terminated string encoded with ISO-8859-1. The filename is case
-sensitive and is encoded as 'Encoding'. 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. There may be more than one
-"GEOB" frame in each tag, but only one with the same content
-descriptor. <span class="anchor" id="line-838"></span><span class="anchor" id="line-839"></span></p><p class="line867"></p><pre><Header for 'General encapsulated object', ID: "GEOB">
-<span class="anchor" id="line-840"></span>Text encoding $xx
-<span class="anchor" id="line-841"></span>MIME type <text string> $00
-<span class="anchor" id="line-842"></span>Filename <text string according to encoding> $00 (00)
-<span class="anchor" id="line-843"></span>Content description $00 (00)
-<span class="anchor" id="line-844"></span>Encapsulated object <binary data>
-<span class="anchor" id="line-845"></span></pre><span class="anchor" id="line-846"></span><span class="anchor" id="line-847"></span><p class="line867"><span class="anchor" id="sec4.17"></span> <span class="anchor" id="line-848"></span>
-</p><h2 id="head-b31a15058cdc13a61e13ab109c25782bc3387075">4.17. Play counter</h2>
-<span class="anchor" id="line-849"></span><span class="anchor" id="line-850"></span><p class="line874">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 "PCNT" 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. <span class="anchor" id="line-851"></span><span class="anchor" id="line-852"></span></p><p class="line867"></p><pre><Header for 'Play counter', ID: "PCNT">
-<span class="anchor" id="line-853"></span>Counter $xx xx xx xx (xx ...)
-<span class="anchor" id="line-854"></span></pre><span class="anchor" id="line-855"></span><span class="anchor" id="line-856"></span><p class="line867"><span class="anchor" id="sec4.18"></span> <span class="anchor" id="line-857"></span>
-</p><h2 id="head-2452ec9cf8b42c5c117b518b69e129ff67970852">4.18. Popularimeter</h2>
-<span class="anchor" id="line-858"></span><span class="anchor" id="line-859"></span><p class="line874">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 person's 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 ("PCNT"). There may be more
-than one "POPM" frame in each tag, but only one with the same email
-address. <span class="anchor" id="line-860"></span><span class="anchor" id="line-861"></span></p><p class="line867"></p><pre><Header for 'Popularimeter', ID: "POPM">
-<span class="anchor" id="line-862"></span>Email to user <text string> $00
-<span class="anchor" id="line-863"></span>Rating $xx
-<span class="anchor" id="line-864"></span>Counter $xx xx xx xx (xx ...)
-<span class="anchor" id="line-865"></span></pre><span class="anchor" id="line-866"></span><span class="anchor" id="line-867"></span><p class="line867"><span class="anchor" id="sec4.19"></span> <span class="anchor" id="line-868"></span>
-</p><h2 id="head-85933b08aab499dc462e7c09752076c92e80f567">4.19. Recommended buffer size</h2>
-<span class="anchor" id="line-869"></span><span class="anchor" id="line-870"></span><p class="line874">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 are generally not recommended since this could render
-unpredictable behaviour from present software/hardware. <span class="anchor" id="line-871"></span><span class="anchor" id="line-872"></span></p><p class="line874">For
-applications like streaming audio it might be an idea to embed tags
-into the audio stream though. If the clients connects to individual
-connections like HTTP and there is a possibility to begin every
-transmission with a tag, then this tag should include a 'recommended
-buffer size' frame. If the client is connected to a arbitrary point in
-the stream, such as radio or multicast, then the 'recommended buffer
-size' frame should be included in every tag. Every tag that is picked
-up after the initial/first tag is to be considered as an update of the
-previous one. E.g. if there is a "TIT2" frame in the first received tag
-and one in the second tag, then the first should be 'replaced' with the
-second. <span class="anchor" id="line-873"></span><span class="anchor" id="line-874"></span></p><p class="line874">The 'Buffer size' should be kept to a minimum. There may only be one "RBUF" frame in each tag. <span class="anchor" id="line-875"></span><span class="anchor" id="line-876"></span></p><p class="line867"></p><pre><Header for 'Recommended buffer size', ID: "RBUF">
-<span class="anchor" id="line-877"></span>Buffer size $xx xx xx
-<span class="anchor" id="line-878"></span>Embedded info flag %0000000x
-<span class="anchor" id="line-879"></span>Offset to next tag $xx xx xx xx
-<span class="anchor" id="line-880"></span></pre><span class="anchor" id="line-881"></span><span class="anchor" id="line-882"></span><p class="line867"><span class="anchor" id="sec4.20"></span> <span class="anchor" id="line-883"></span>
-</p><h2 id="head-64778eca1ee53ea0f439602809c142e312669eda">4.20. Audio encryption</h2>
-<span class="anchor" id="line-884"></span><span class="anchor" id="line-885"></span><p class="line874">This
-frame indicates if the actual audio stream is encrypted, and by whom.
-Since standardisation of such encrypion scheme is beyond this document,
-all "AENC" 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. <span class="anchor" id="line-886"></span><span class="anchor" id="line-887"></span></p><p class="line874">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 "AENC"
-frames in a tag, but only one with the same 'Owner identifier'. <span class="anchor" id="line-888"></span><span class="anchor" id="line-889"></span></p><p class="line867"></p><pre><Header for 'Audio encryption', ID: "AENC">
-<span class="anchor" id="line-890"></span>Owner identifier <text string> $00
-<span class="anchor" id="line-891"></span>Preview start $xx xx
-<span class="anchor" id="line-892"></span>Preview length $xx xx
-<span class="anchor" id="line-893"></span>Encryption info <binary data>
-<span class="anchor" id="line-894"></span></pre><span class="anchor" id="line-895"></span><span class="anchor" id="line-896"></span><p class="line867"><span class="anchor" id="sec4.21"></span> <span class="anchor" id="line-897"></span>
-</p><h2 id="head-1f5f3f280f04ce712a1d5a3531fb0dd396c6ea9f">4.21. Linked information</h2>
-<span class="anchor" id="line-898"></span><span class="anchor" id="line-899"></span><p class="line874">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 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 "LINK" 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
-"RVRB" frame allowed, whether it's linked or not). <span class="anchor" id="line-900"></span><span class="anchor" id="line-901"></span></p><p class="line867"></p><pre><Header for 'Linked information', ID: "LINK">
-<span class="anchor" id="line-902"></span>Frame identifier $xx xx xx
-<span class="anchor" id="line-903"></span>URL <text string> $00
-<span class="anchor" id="line-904"></span>ID and additional data <text string(s)>
-<span class="anchor" id="line-905"></span></pre><span class="anchor" id="line-906"></span><p class="line874">Frames
-that may be linked and need no additional data are "IPLS", "MCID",
-"ETCO", "MLLT", "SYTC", "RVAD", "EQUA", "RVRB", "RBUF", the text
-information frames and the URL link frames. <span class="anchor" id="line-907"></span><span class="anchor" id="line-908"></span></p><p class="line874">The "TXXX", "APIC", "GEOB" and "AENC" frames may be linked with the content descriptor as additional ID data. <span class="anchor" id="line-909"></span><span class="anchor" id="line-910"></span></p><p class="line874">The
-"COMM", "SYLT" and "USLT" frames may be linked with three bytes of
-language descriptor directly followed by a content descriptor as
-additional ID data. <span class="anchor" id="line-911"></span><span class="anchor" id="line-912"></span></p><p class="line867"><span class="anchor" id="sec4.22"></span> <span class="anchor" id="line-913"></span>
-</p><h2 id="head-dfd851b017379ad18d434c1a1be6bfb98c16c4ed">4.22. Position synchronisation frame</h2>
-<span class="anchor" id="line-914"></span><span class="anchor" id="line-915"></span><p class="line874">This
-frame delivers information to the listener of how far into the audio
-stream he picked up; in effect, it states the time offset of the first
-frame in the stream. The frame layout is: <span class="anchor" id="line-916"></span><span class="anchor" id="line-917"></span></p><p class="line867"></p><pre><Head for 'Position synchronisation', ID: "POSS">
-<span class="anchor" id="line-918"></span>Time stamp format $xx
-<span class="anchor" id="line-919"></span>Position $xx (xx ...)
-<span class="anchor" id="line-920"></span></pre><span class="anchor" id="line-921"></span><p class="line874">Where time stamp format is: <span class="anchor" id="line-922"></span></p><pre>$01 Absolute time, 32 bit sized, using MPEG frames as unit
-<span class="anchor" id="line-923"></span>$02 Absolute time, 32 bit sized, using milliseconds as unit
-<span class="anchor" id="line-924"></span></pre><span class="anchor" id="line-925"></span><p class="line874">and
-position is where in the audio the listener starts to receive, i.e. the
-beginning of the next frame. If this frame is used in the beginning of
-a file the value is always 0. There may only be one "POSS" frame in
-each tag. <span class="anchor" id="line-926"></span><span class="anchor" id="line-927"></span></p><p class="line867"><span class="anchor" id="sec4.23"></span> <span class="anchor" id="line-928"></span>
-</p><h2 id="head-d25b79fcb6f0d51c28301e2cd8a1750b061a5bef">4.23. Terms of use frame</h2>
-<span class="anchor" id="line-929"></span><span class="anchor" id="line-930"></span><p class="line874">This
-frame contains a brief description of the terms of use and ownership of
-the file. More detailed information concerning the legal terms might be
-available through the "WCOP" frame. Newlines are allowed in the text.
-There may only be one "USER" frame in a tag. <span class="anchor" id="line-931"></span><span class="anchor" id="line-932"></span></p><p class="line867"></p><pre><Header for 'Terms of use frame', ID: "USER">
-<span class="anchor" id="line-933"></span>Text encoding $xx
-<span class="anchor" id="line-934"></span>Language $xx xx xx
-<span class="anchor" id="line-935"></span>The actual text <text string according to encoding>
-<span class="anchor" id="line-936"></span></pre><span class="anchor" id="line-937"></span><span class="anchor" id="line-938"></span><p class="line867"><span class="anchor" id="sec4.24"></span> <span class="anchor" id="line-939"></span>
-</p><h2 id="head-3c67d23d7cfecadd0253293fada37fbba5c6f1e1">4.24. Ownership frame</h2>
-<span class="anchor" id="line-940"></span><span class="anchor" id="line-941"></span><p class="line874">The
-ownership frame might be used as a reminder of a made transaction or,
-if signed, as proof. Note that the "USER" and "TOWN" frames are good to
-use in conjunction with this one. The frame begins, after the frame ID,
-size and encoding fields, with a 'price payed' field. The first three
-characters of this field contains the currency used for the
-transaction, encoded according to ISO-4217 alphabetic currency code.
-Concatenated to this is the actual price payed, as a numerical string
-using "." as the decimal separator. Next is an 8 character date string
-(YYYYMMDD) followed by a string with the name of the seller as the last
-field in the frame. There may only be one "OWNE" frame in a tag. <span class="anchor" id="line-942"></span><span class="anchor" id="line-943"></span></p><p class="line867"></p><pre><Header for 'Ownership frame', ID: "OWNE">
-<span class="anchor" id="line-944"></span>Text encoding $xx
-<span class="anchor" id="line-945"></span>Price payed <text string> $00
-<span class="anchor" id="line-946"></span>Date of purch. <text string>
-<span class="anchor" id="line-947"></span>Seller <text string according to encoding>
-<span class="anchor" id="line-948"></span></pre><span class="anchor" id="line-949"></span><span class="anchor" id="line-950"></span><p class="line867"><span class="anchor" id="sec4.25"></span> <span class="anchor" id="line-951"></span>
-</p><h2 id="head-5cd03d43fbc0db57aaaf42cd5a2150705f50eada">4.25. Commercial frame</h2>
-<span class="anchor" id="line-952"></span><span class="anchor" id="line-953"></span><p class="line874">This
-frame enables several competing offers in the same tag by bundling all
-needed information. That makes this frame rather complex but it's an
-easier solution than if one tries to achieve the same result with
-several frames. The frame begins, after the frame ID, size and encoding
-fields, with a price string field. A price is constructed by one three
-character currency code, encoded according to ISO-4217 alphabetic
-currency code, followed by a numerical value where "." is used as
-decimal seperator. In the price string several prices may be
-concatenated, seperated by a "/" character, but there may only be one
-currency of each type. <span class="anchor" id="line-954"></span><span class="anchor" id="line-955"></span></p><p class="line874">The
-price string is followed by an 8 character date string in the format
-YYYYMMDD, describing for how long the price is valid. After that is a
-contact URL, with which the user can contact the seller, followed by a
-one byte 'received as' field. It describes how the audio is delivered
-when bought according to the following list: <span class="anchor" id="line-956"></span><span class="anchor" id="line-957"></span></p><p class="line867"></p><pre>$00 Other
-<span class="anchor" id="line-958"></span>$01 Standard CD album with other songs
-<span class="anchor" id="line-959"></span>$02 Compressed audio on CD
-<span class="anchor" id="line-960"></span>$03 File over the Internet
-<span class="anchor" id="line-961"></span>$04 Stream over the Internet
-<span class="anchor" id="line-962"></span>$05 As note sheets
-<span class="anchor" id="line-963"></span>$06 As note sheets in a book with other sheets
-<span class="anchor" id="line-964"></span>$07 Music on other media
-<span class="anchor" id="line-965"></span>$08 Non-musical merchandise
-<span class="anchor" id="line-966"></span></pre><span class="anchor" id="line-967"></span><span class="anchor" id="line-968"></span><p class="line874">Next
-follows a terminated string with the name of the seller followed by a
-terminated string with a short description of the product. The last
-thing is the ability to include a company logotype. The first of them
-is the 'Picture MIME type' field containing information about which
-picture format is used. In the event that the MIME media type name is
-omitted, "image/" will be implied. Currently only "image/png" and
-"image/jpeg" are allowed. This format string is followed by the binary
-picture data. This two last fields may be omitted if no picture is to
-attach. <span class="anchor" id="line-969"></span><span class="anchor" id="line-970"></span></p><p class="line867"></p><pre><Header for 'Commercial frame', ID: "COMR">
-<span class="anchor" id="line-971"></span>Text encoding $xx
-<span class="anchor" id="line-972"></span>Price string <text string> $00
-<span class="anchor" id="line-973"></span>Valid until <text string>
-<span class="anchor" id="line-974"></span>Contact URL <text string> $00
-<span class="anchor" id="line-975"></span>Received as $xx
-<span class="anchor" id="line-976"></span>Name of seller <text string according to encoding> $00 (00)
-<span class="anchor" id="line-977"></span>Description <text string according to encoding> $00 (00)
-<span class="anchor" id="line-978"></span>Picture MIME type <string> $00
-<span class="anchor" id="line-979"></span>Seller logo <binary data>
-<span class="anchor" id="line-980"></span></pre><span class="anchor" id="line-981"></span><span class="anchor" id="line-982"></span><p class="line867"><span class="anchor" id="sec4.26"></span> <span class="anchor" id="line-983"></span>
-</p><h2 id="head-104c980db64c9df28fbaa4ae87e365d50930534d">4.26. Encryption method registration</h2>
-<span class="anchor" id="line-984"></span><span class="anchor" id="line-985"></span><p class="line874">To
-identify with which method a frame has been encrypted the encryption
-method must be registered in the tag with this frame. The 'Owner
-identifier' is 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
-encryption method. Questions regarding the encryption method should be
-sent to the indicated email address. The 'Method symbol' contains a
-value that is associated with this method throughout the whole tag.
-Values below $80 are reserved. The 'Method symbol' may optionally be
-followed by encryption specific data. There may be several "ENCR"
-frames in a tag but only one containing the same symbol and only one
-containing the same owner identifier. The method must be used somewhere
-in the tag. See section 3.3.1, flag j for more information. <span class="anchor" id="line-986"></span><span class="anchor" id="line-987"></span></p><p class="line867"></p><pre><Header for 'Encryption method registration', ID: "ENCR">
-<span class="anchor" id="line-988"></span>Owner identifier <text string> $00
-<span class="anchor" id="line-989"></span>Method symbol $xx
-<span class="anchor" id="line-990"></span>Encryption data <binary data>
-<span class="anchor" id="line-991"></span></pre><span class="anchor" id="line-992"></span><span class="anchor" id="line-993"></span><p class="line867"><span class="anchor" id="sec4.27"></span> <span class="anchor" id="line-994"></span>
-</p><h2 id="head-ba309170decab08b9bcb1ffb6d6974c0bfd1ead3">4.27. Group identification registration</h2>
-<span class="anchor" id="line-995"></span><span class="anchor" id="line-996"></span><p class="line862">This
-frame enables grouping of otherwise unrelated frames. This can be used
-when some frames are to be signed. To identify which frames belongs to
-a set of frames a group identifier must be registered in the tag with
-this frame. The 'Owner identifier' is 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 grouping. Questions regarding the grouping should be sent to the
-indicated email address. The 'Group symbol' contains a value that
-associates the frame with this group throughout the whole tag. Values
-below $80 are reserved. The 'Group symbol' may optionally be followed
-by some group specific data, e.g. a digital signature. There may be
-several "GRID" frames in a tag but only one containing the same symbol
-and only one containing the same owner identifier. The group symbol
-must be used somewhere in the tag. See <a href="#sec3.3.1">section 3.3.1</a>, flag j for more information. <span class="anchor" id="line-997"></span><span class="anchor" id="line-998"></span></p><p class="line867"></p><pre><Header for 'Group ID registration', ID: "GRID">
-<span class="anchor" id="line-999"></span>Owner identifier <text string> $00
-<span class="anchor" id="line-1000"></span>Group symbol $xx
-<span class="anchor" id="line-1001"></span>Group dependent data <binary data>
-<span class="anchor" id="line-1002"></span></pre><span class="anchor" id="line-1003"></span><span class="anchor" id="line-1004"></span><p class="line867"><span class="anchor" id="sec4.28"></span> <span class="anchor" id="line-1005"></span>
-</p><h2 id="head-6e58a3ef53dd199d9af3dd33d544a39a5343ab3c">4.28. Private frame</h2>
-<span class="anchor" id="line-1006"></span><span class="anchor" id="line-1007"></span><p class="line874">This
-frame is used to contain information from a software producer that its
-program uses and does not fit into the other frames. The frame consists
-of an 'Owner identifier' string and the binary data. The 'Owner
-identifier' is 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 the frame. Questions
-regarding the frame should be sent to the indicated email address. The
-tag may contain more than one "PRIV" frame but only with different
-contents. It is recommended to keep the number of "PRIV" frames as low
-as possible. <span class="anchor" id="line-1008"></span><span class="anchor" id="line-1009"></span></p><p class="line867"></p><pre><Header for 'Private frame', ID: "PRIV">
-<span class="anchor" id="line-1010"></span>Owner identifier <text string> $00
-<span class="anchor" id="line-1011"></span>The private data <binary data>
-<span class="anchor" id="line-1012"></span></pre><span class="anchor" id="line-1013"></span><span class="anchor" id="line-1014"></span><p class="line867"><span class="anchor" id="sec5"></span> <span class="anchor" id="line-1015"></span>
-</p><h1 id="head-c632e49403443283c464955b36911f949bbb2586">5. The unsynchronisation scheme</h1>
-<span class="anchor" id="line-1016"></span><span class="anchor" id="line-1017"></span><p class="line874">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. <span class="anchor" id="line-1018"></span><span class="anchor" id="line-1019"></span></p><p class="line874">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: <span class="anchor" id="line-1020"></span><span class="anchor" id="line-1021"></span></p><p class="line867"></p><pre>%11111111 111xxxxx
-<span class="anchor" id="line-1022"></span></pre><span class="anchor" id="line-1023"></span><span class="anchor" id="line-1024"></span><p class="line874">And should be replaced with: <span class="anchor" id="line-1025"></span><span class="anchor" id="line-1026"></span></p><p class="line867"></p><pre>%11111111 00000000 111xxxxx
-<span class="anchor" id="line-1027"></span></pre><span class="anchor" id="line-1028"></span><span class="anchor" id="line-1029"></span><p class="line874">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. <span class="anchor" id="line-1030"></span><span class="anchor" id="line-1031"></span></p><p class="line874">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. <span class="anchor" id="line-1032"></span><span class="anchor" id="line-1033"></span></p><p class="line874">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 'unsynchronisation scheme'
-should be parsed first, decompression afterwards. <span class="anchor" id="line-1034"></span><span class="anchor" id="line-1035"></span></p><p class="line874">If
-the last byte in the tag is $FF, and there is a need to eliminate false
-synchronisations in the tag, at least one byte of padding should be
-added. <span class="anchor" id="line-1036"></span><span class="anchor" id="line-1037"></span></p><p class="line867"><span class="anchor" id="sec6"></span> <span class="anchor" id="line-1038"></span>
-</p><h1 id="head-2e25d065aae179b2e61ebe76ded3ce201fd6764f">6. Copyright</h1>
-<span class="anchor" id="line-1039"></span><span class="anchor" id="line-1040"></span><p class="line874">Copyright © Martin Nilsson 1998. All Rights Reserved. <span class="anchor" id="line-1041"></span><span class="anchor" id="line-1042"></span></p><p class="line874">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. <span class="anchor" id="line-1043"></span><span class="anchor" id="line-1044"></span></p><p class="line874">The limited permissions granted above are perpetual and will not be revoked. <span class="anchor" id="line-1045"></span><span class="anchor" id="line-1046"></span></p><p class="line874">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. <span class="anchor" id="line-1047"></span><span class="anchor" id="line-1048"></span></p><p class="line867"><span class="anchor" id="sec7"></span> <span class="anchor" id="line-1049"></span>
-</p><h1 id="head-090c9e5e624f843e946e467f0ad8a1c21aacaa01">7. References</h1>
-<span class="anchor" id="line-1050"></span><span class="anchor" id="line-1051"></span><p class="line867"><span class="anchor" id="CDDB"></span> <span class="anchor" id="line-1052"></span>[CDDB] Compact Disc Data Base <a class="http" href="http://www.cddb.com/">http://www.cddb.com</a> <br>
-<br>
- <span class="anchor" id="line-1053"></span>[ID3v2] Martin Nilsson, <a href="http://www.id3.org/id3v2-00">"ID3v2 informal standard".</a> <br>
-<br>
- <span class="anchor" id="line-1054"></span><span class="anchor" id="ISO-639-2"></span> <span class="anchor" id="line-1055"></span>[ISO-639-2] ISO/FDIS 639-2. <span class="anchor" id="line-1056"></span>Codes for the representation of names of languages, Part 2: Alpha-3 code. Technical committee / subcommittee: TC 37 / SC 2 <br>
-<br>
- <span class="anchor" id="line-1057"></span><span class="anchor" id="ISO-4217"></span> <span class="anchor" id="line-1058"></span>[ISO-4217] ISO 4217:1995. <span class="anchor" id="line-1059"></span>Codes for the representation of currencies and funds. Technical committee / subcommittee: TC 68 <br>
-<br>
- <span class="anchor" id="line-1060"></span><span class="anchor" id="ISO-8859-1"></span> <span class="anchor" id="line-1061"></span>[ISO-8859-1] ISO/IEC DIS 8859-1. <span class="anchor" id="line-1062"></span>8-bit single-byte coded graphic character sets, Part 1: Latin alphabet No. 1. Technical committee / subcommittee: JTC 1 / SC 2 <br>
-<br>
- <span class="anchor" id="line-1063"></span><span class="anchor" id="ISRC"></span> <span class="anchor" id="line-1064"></span>[ISRC] ISO 3901:1986 <span class="anchor" id="line-1065"></span>International Standard Recording Code (ISRC). Technical committee / subcommittee: TC 46 / SC 9 <br>
-<br>
- <span class="anchor" id="line-1066"></span><span class="anchor" id="JFIF"></span> <span class="anchor" id="line-1067"></span>[JFIF] JPEG File Interchange Format, version 1.02, <a class="http" href="http://www.w3.org/Graphics/JPEG/jfif.txt">http://www.w3.org/Graphics/JPEG/jfif.txt</a> <br>
-<br>
- <span class="anchor" id="line-1068"></span><span class="anchor" id="MIME"></span> <span class="anchor" id="line-1069"></span>[MIME]
-Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions
-(MIME) Part One: Format of Internet Message Bodies", RFC 2045, November
-1996., <a class="ftp" href="ftp://ftp.isi.edu/in-notes/rfc2045.txt">ftp://ftp.isi.edu/in-notes/rfc2045.txt</a> <br>
-<br>
- <span class="anchor" id="line-1070"></span><span class="anchor" id="MPEG"></span> <span class="anchor" id="line-1071"></span>[MPEG] ISO/IEC 11172-3:1993. <span class="anchor" id="line-1072"></span>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) <br>
-<br>
- <span class="anchor" id="line-1073"></span><span class="anchor" id="PNG"></span> <span class="anchor" id="line-1074"></span>[PNG] Portable Network Graphics, version 1.0, <a class="http" href="http://www.w3.org/TR/REC-png-multi.html">http://www.w3.org/TR/REC-png-multi.html</a> <br>
-<br>
- <span class="anchor" id="line-1075"></span><span class="anchor" id="UNICODE"></span> <span class="anchor" id="line-1076"></span>[UNICODE] ISO/IEC 10646-1:1993. <span class="anchor" id="line-1077"></span>Universal
-Multiple-Octet Coded Character Set (UCS), Part 1: Architecture and
-Basic Multilingual Plane. Technical committee / subcommittee: JTC 1 /
-SC 2, <a class="http" href="http://www.unicode.org/">http://www.unicode.org</a> <br>
-<br>
- <span class="anchor" id="line-1078"></span><span class="anchor" id="URL"></span> <span class="anchor" id="line-1079"></span>[URL] T. Berners-Lee, L. Masinter & M. <a class="nonexistent" href="http://www.id3.org/McCahill">McCahill</a>, "Uniform Resource Locators (URL).", RFC 1738, December 1994., <a class="ftp" href="ftp://ftp.isi.edu/in-notes/rfc1738.txt">ftp://ftp.isi.edu/in-notes/rfc1738.txt</a> <br>
-<br>
- <span class="anchor" id="line-1080"></span><span class="anchor" id="ZLIB"></span> <span class="anchor" id="line-1081"></span>[ZLIB]
-P. Deutsch, Aladdin Enterprises & J-L. Gailly, "ZLIB Compressed
-Data Format Specification version 3.3", RFC 1950, May 1996., url:<a class="ftp" href="ftp://ftp.isi.edu/in-notes/rfc1950.txt">ftp://ftp.isi.edu/in-notes/rfc1950.txt</a> <br>
-<br>
- <span class="anchor" id="line-1082"></span><span class="anchor" id="line-1083"></span></p><p class="line867"><span class="anchor" id="sec8"></span> <span class="anchor" id="line-1084"></span>
-</p><h1 id="head-50c2e666f19bdeb915260d8de35bcb5bc35330d6">8. Appendix</h1>
-<span class="anchor" id="line-1085"></span><span class="anchor" id="line-1086"></span><p class="line867">
-</p><h2 id="head-129376727ebe5309c1de1888987d070288d7c7e7">8.1. Appendix A - Genre List from ID3v1</h2>
-<span class="anchor" id="line-1087"></span><span class="anchor" id="line-1088"></span><p class="line874">The following genres is defined in ID3v1 <span class="anchor" id="line-1089"></span></p><pre> 0. Blues
-<span class="anchor" id="line-1090"></span> 1. Classic Rock
-<span class="anchor" id="line-1091"></span> 2. Country
-<span class="anchor" id="line-1092"></span> 3. Dance
-<span class="anchor" id="line-1093"></span> 4. Disco
-<span class="anchor" id="line-1094"></span> 5. Funk
-<span class="anchor" id="line-1095"></span> 6. Grunge
-<span class="anchor" id="line-1096"></span> 7. Hip-Hop
-<span class="anchor" id="line-1097"></span> 8. Jazz
-<span class="anchor" id="line-1098"></span> 9. Metal
-<span class="anchor" id="line-1099"></span> 10. New Age
-<span class="anchor" id="line-1100"></span> 11. Oldies
-<span class="anchor" id="line-1101"></span> 12. Other
-<span class="anchor" id="line-1102"></span> 13. Pop
-<span class="anchor" id="line-1103"></span> 14. R&B
-<span class="anchor" id="line-1104"></span> 15. Rap
-<span class="anchor" id="line-1105"></span> 16. Reggae
-<span class="anchor" id="line-1106"></span> 17. Rock
-<span class="anchor" id="line-1107"></span> 18. Techno
-<span class="anchor" id="line-1108"></span> 19. Industrial
-<span class="anchor" id="line-1109"></span> 20. Alternative
-<span class="anchor" id="line-1110"></span> 21. Ska
-<span class="anchor" id="line-1111"></span> 22. Death Metal
-<span class="anchor" id="line-1112"></span> 23. Pranks
-<span class="anchor" id="line-1113"></span> 24. Soundtrack
-<span class="anchor" id="line-1114"></span> 25. Euro-Techno
-<span class="anchor" id="line-1115"></span> 26. Ambient
-<span class="anchor" id="line-1116"></span> 27. Trip-Hop
-<span class="anchor" id="line-1117"></span> 28. Vocal
-<span class="anchor" id="line-1118"></span> 29. Jazz+Funk
-<span class="anchor" id="line-1119"></span> 30. Fusion
-<span class="anchor" id="line-1120"></span> 31. Trance
-<span class="anchor" id="line-1121"></span> 32. Classical
-<span class="anchor" id="line-1122"></span> 33. Instrumental
-<span class="anchor" id="line-1123"></span> 34. Acid
-<span class="anchor" id="line-1124"></span> 35. House
-<span class="anchor" id="line-1125"></span> 36. Game
-<span class="anchor" id="line-1126"></span> 37. Sound Clip
-<span class="anchor" id="line-1127"></span> 38. Gospel
-<span class="anchor" id="line-1128"></span> 39. Noise
-<span class="anchor" id="line-1129"></span> 40. AlternRock
-<span class="anchor" id="line-1130"></span> 41. Bass
-<span class="anchor" id="line-1131"></span> 42. Soul
-<span class="anchor" id="line-1132"></span> 43. Punk
-<span class="anchor" id="line-1133"></span> 44. Space
-<span class="anchor" id="line-1134"></span> 45. Meditative
-<span class="anchor" id="line-1135"></span> 46. Instrumental Pop
-<span class="anchor" id="line-1136"></span> 47. Instrumental Rock
-<span class="anchor" id="line-1137"></span> 48. Ethnic
-<span class="anchor" id="line-1138"></span> 49. Gothic
-<span class="anchor" id="line-1139"></span> 50. Darkwave
-<span class="anchor" id="line-1140"></span> 51. Techno-Industrial
-<span class="anchor" id="line-1141"></span> 52. Electronic
-<span class="anchor" id="line-1142"></span> 53. Pop-Folk
-<span class="anchor" id="line-1143"></span> 54. Eurodance
-<span class="anchor" id="line-1144"></span> 55. Dream
-<span class="anchor" id="line-1145"></span> 56. Southern Rock
-<span class="anchor" id="line-1146"></span> 57. Comedy
-<span class="anchor" id="line-1147"></span> 58. Cult
-<span class="anchor" id="line-1148"></span> 59. Gangsta
-<span class="anchor" id="line-1149"></span> 60. Top 40
-<span class="anchor" id="line-1150"></span> 61. Christian Rap
-<span class="anchor" id="line-1151"></span> 62. Pop/Funk
-<span class="anchor" id="line-1152"></span> 63. Jungle
-<span class="anchor" id="line-1153"></span> 64. Native American
-<span class="anchor" id="line-1154"></span> 65. Cabaret
-<span class="anchor" id="line-1155"></span> 66. New Wave
-<span class="anchor" id="line-1156"></span> 67. Psychadelic
-<span class="anchor" id="line-1157"></span> 68. Rave
-<span class="anchor" id="line-1158"></span> 69. Showtunes
-<span class="anchor" id="line-1159"></span> 70. Trailer
-<span class="anchor" id="line-1160"></span> 71. Lo-Fi
-<span class="anchor" id="line-1161"></span> 72. Tribal
-<span class="anchor" id="line-1162"></span> 73. Acid Punk
-<span class="anchor" id="line-1163"></span> 74. Acid Jazz
-<span class="anchor" id="line-1164"></span> 75. Polka
-<span class="anchor" id="line-1165"></span> 76. Retro
-<span class="anchor" id="line-1166"></span> 77. Musical
-<span class="anchor" id="line-1167"></span> 78. Rock & Roll
-<span class="anchor" id="line-1168"></span> 79. Hard Rock
-<span class="anchor" id="line-1169"></span></pre><span class="anchor" id="line-1170"></span><p class="line874">The following genres are Winamp extensions <span class="anchor" id="line-1171"></span><span class="anchor" id="line-1172"></span></p><pre> 80. Folk
-<span class="anchor" id="line-1173"></span> 81. Folk-Rock
-<span class="anchor" id="line-1174"></span> 82. National Folk
-<span class="anchor" id="line-1175"></span> 83. Swing
-<span class="anchor" id="line-1176"></span> 84. Fast Fusion
-<span class="anchor" id="line-1177"></span> 85. Bebob
-<span class="anchor" id="line-1178"></span> 86. Latin
-<span class="anchor" id="line-1179"></span> 87. Revival
-<span class="anchor" id="line-1180"></span> 88. Celtic
-<span class="anchor" id="line-1181"></span> 89. Bluegrass
-<span class="anchor" id="line-1182"></span> 90. Avantgarde
-<span class="anchor" id="line-1183"></span> 91. Gothic Rock
-<span class="anchor" id="line-1184"></span> 92. Progressive Rock
-<span class="anchor" id="line-1185"></span> 93. Psychedelic Rock
-<span class="anchor" id="line-1186"></span> 94. Symphonic Rock
-<span class="anchor" id="line-1187"></span> 95. Slow Rock
-<span class="anchor" id="line-1188"></span> 96. Big Band
-<span class="anchor" id="line-1189"></span> 97. Chorus
-<span class="anchor" id="line-1190"></span> 98. Easy Listening
-<span class="anchor" id="line-1191"></span> 99. Acoustic
-<span class="anchor" id="line-1192"></span>100. Humour
-<span class="anchor" id="line-1193"></span>101. Speech
-<span class="anchor" id="line-1194"></span>102. Chanson
-<span class="anchor" id="line-1195"></span>103. Opera
-<span class="anchor" id="line-1196"></span>104. Chamber Music
-<span class="anchor" id="line-1197"></span>105. Sonata
-<span class="anchor" id="line-1198"></span>106. Symphony
-<span class="anchor" id="line-1199"></span>107. Booty Bass
-<span class="anchor" id="line-1200"></span>108. Primus
-<span class="anchor" id="line-1201"></span>109. Porn Groove
-<span class="anchor" id="line-1202"></span>110. Satire
-<span class="anchor" id="line-1203"></span>111. Slow Jam
-<span class="anchor" id="line-1204"></span>112. Club
-<span class="anchor" id="line-1205"></span>113. Tango
-<span class="anchor" id="line-1206"></span>114. Samba
-<span class="anchor" id="line-1207"></span>115. Folklore
-<span class="anchor" id="line-1208"></span>116. Ballad
-<span class="anchor" id="line-1209"></span>117. Power Ballad
-<span class="anchor" id="line-1210"></span>118. Rhythmic Soul
-<span class="anchor" id="line-1211"></span>119. Freestyle
-<span class="anchor" id="line-1212"></span>120. Duet
-<span class="anchor" id="line-1213"></span>121. Punk Rock
-<span class="anchor" id="line-1214"></span>122. Drum Solo
-<span class="anchor" id="line-1215"></span>123. A capella
-<span class="anchor" id="line-1216"></span>124. Euro-House
-<span class="anchor" id="line-1217"></span>125. Dance Hall
-<span class="anchor" id="line-1218"></span></pre><span class="anchor" id="line-1219"></span><span class="anchor" id="line-1220"></span><p class="line867"><span class="anchor" id="sec9"></span> <span class="anchor" id="line-1221"></span>
-</p><h1 id="head-ab9d99d0fd7edd520f035105d0b20ac9adebce85">9. Author's Address</h1>
-<span class="anchor" id="line-1222"></span><span class="anchor" id="line-1223"></span><p class="line862">Written by <br>
- <span class="anchor" id="line-1224"></span><span class="anchor" id="line-1225"></span></p><p class="line862">Martin Nilsson <br>
- <span class="anchor" id="line-1226"></span>Rydsven 246 C. 30 <br>
- <span class="anchor" id="line-1227"></span>S-584 34 Linkoping <br>
- <span class="anchor" id="line-1228"></span>Sweden <br>
-<br>
- <span class="anchor" id="line-1229"></span>Email: nilsson at id3.org <br>
- <br>
- <span class="anchor" id="line-1230"></span><span class="anchor" id="line-1231"></span></p><p class="line862">Edited by <br>
- <span class="anchor" id="line-1232"></span><span class="anchor" id="line-1233"></span></p><p class="line862">Dirk Mahoney <br>
- <span class="anchor" id="line-1234"></span>57 Pechey Street <br>
- <span class="anchor" id="line-1235"></span>Chermside Q <br>
- <span class="anchor" id="line-1236"></span>Australia 4032 <br>
-<br>
- <span class="anchor" id="line-1237"></span>Email: dirk at id3.org <br>
- <br>
- <span class="anchor" id="line-1238"></span><span class="anchor" id="line-1239"></span></p><p class="line862">Johan Sundstrom <br>
- <span class="anchor" id="line-1240"></span>Alsttersgatan 5 A. 34 <br>
- <span class="anchor" id="line-1241"></span>S-584 35 Linkoping <br>
- <span class="anchor" id="line-1242"></span>Sweden <br>
-<br>
- <span class="anchor" id="line-1243"></span>Email: johan at id3.org <span class="anchor" id="line-1244"></span><span class="anchor" id="bottom"></span></p></div><p id="pageinfo" class="info" dir="ltr" lang="en">id3v2.3.0 (last edited 2006-12-18 06:25:16 by <span title="DanONeill"><a generated="True" href="http://www.id3.org/DanONeill" title="DanONeill">DanONeill</a></span>)</p>
-<div id="pagebottom"></div>
-</div>
-</body></html>
\ No newline at end of file
+++ /dev/null
-$Id$
-
-Informal standard M. Nilsson
-Document: id3v2.4.0-frames.txt 1st November 2000
-
-
- ID3 tag version 2.4.0 - Native Frames
-
-Status of this document
-
- This document is an informal standard and replaces the ID3v2.3.0
- standard [ID3v2]. A formal standard will use another revision number
- even if the content is identical to document. The contents in this
- document may change for clarifications but never for added or altered
- functionallity.
-
- Distribution of this document is unlimited.
-
-
-Abstract
-
- This document describes the frames natively supported by ID3v2.4.0,
- which is a revised version of the ID3v2 informal standard [ID3v2.3.0]
- version 2.3.0. The ID3v2 offers a flexible way of storing audio meta
- information within audio file itself. The information may be
- technical information, such as equalisation curves, as well as title,
- performer, copyright etc.
-
- ID3v2.4.0 is meant to be as close as possible to ID3v2.3.0 in order
- to allow for implementations to be revised as easily as possible.
-
-
-1. Table of contents
-
- 2. Conventions in this document
- 3. Default flags
- 4. Declared ID3v2 frames
- 4.1. Unique file identifier
- 4.2. Text information frames
- 4.2.1. Identification frames
- 4.2.2. Involved persons frames
- 4.2.3. Derived and subjective properties frames
- 4.2.4. Rights and license frames
- 4.2.5. Other text frames
- 4.2.6. User defined text information frame
- 4.3. URL link frames
- 4.3.1. URL link frames - details
- 4.3.2. User defined URL link frame
- 4.4. Music CD Identifier
- 4.5. Event timing codes
- 4.6. MPEG location lookup table
- 4.7. Synced tempo codes
- 4.8. Unsynchronised lyrics/text transcription
- 4.9. Synchronised lyrics/text
- 4.10. Comments
- 4.11. Relative volume adjustment (2)
- 4.12. Equalisation (2)
- 4.13. Reverb
- 4.14. Attached picture
- 4.15. General encapsulated object
- 4.16. Play counter
- 4.17. Popularimeter
- 4.18. Recommended buffer size
- 4.19. Audio encryption
- 4.20. Linked information
- 4.21. Position synchronisation frame
- 4.22. Terms of use
- 4.23. Ownership frame
- 4.24. Commercial frame
- 4.25. Encryption method registration
- 4.26. Group identification registration
- 4.27. Private frame
- 4.28. Signature frame
- 4.29. Seek frame
- 4.30. Audio seek point index
- 5. Copyright
- 6. References
- 7. Appendix
- A. Appendix A - Genre List from ID3v1
- 8. Author's Address
-
-
-2. Conventions in this document
-
- Text within "" is a text string exactly as it appears in a tag.
- 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'.
-
- A tag is the whole tag described the ID3v2 main structure document
- [ID3v2-strct]. 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 "0123456789" only.
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in RFC 2119 [KEYWORDS].
-
-
-3. 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.
-
- 1. Discarded if tag is altered, discarded if file is altered.
-
- None.
-
- 2. Discarded if tag is altered, preserved if file is altered.
-
- None.
-
- 3. Preserved if tag is altered, discarded if file is altered.
-
- ASPI, AENC, ETCO, EQU2, MLLT, POSS, SEEK, SYLT, SYTC, RVA2, TENC,
- TLEN
-
- 4. Preserved if tag is altered, preserved if file is altered.
-
- The rest of the frames.
-
-
-4. Declared ID3v2 frames
-
- The following frames are declared in this draft.
-
- 4.19 AENC Audio encryption
- 4.14 APIC Attached picture
- 4.30 ASPI Audio seek point index
-
- 4.10 COMM Comments
- 4.24 COMR Commercial frame
-
- 4.25 ENCR Encryption method registration
- 4.12 EQU2 Equalisation (2)
- 4.5 ETCO Event timing codes
-
- 4.15 GEOB General encapsulated object
- 4.26 GRID Group identification registration
-
- 4.20 LINK Linked information
-
- 4.4 MCDI Music CD identifier
- 4.6 MLLT MPEG location lookup table
-
- 4.23 OWNE Ownership frame
-
- 4.27 PRIV Private frame
- 4.16 PCNT Play counter
- 4.17 POPM Popularimeter
- 4.21 POSS Position synchronisation frame
-
- 4.18 RBUF Recommended buffer size
- 4.11 RVA2 Relative volume adjustment (2)
- 4.13 RVRB Reverb
-
- 4.29 SEEK Seek frame
- 4.28 SIGN Signature frame
- 4.9 SYLT Synchronised lyric/text
- 4.7 SYTC Synchronised tempo codes
-
- 4.2.1 TALB Album/Movie/Show title
- 4.2.3 TBPM BPM (beats per minute)
- 4.2.2 TCOM Composer
- 4.2.3 TCON Content type
- 4.2.4 TCOP Copyright message
- 4.2.5 TDEN Encoding time
- 4.2.5 TDLY Playlist delay
- 4.2.5 TDOR Original release time
- 4.2.5 TDRC Recording time
- 4.2.5 TDRL Release time
- 4.2.5 TDTG Tagging time
- 4.2.2 TENC Encoded by
- 4.2.2 TEXT Lyricist/Text writer
- 4.2.3 TFLT File type
- 4.2.2 TIPL Involved people list
- 4.2.1 TIT1 Content group description
- 4.2.1 TIT2 Title/songname/content description
- 4.2.1 TIT3 Subtitle/Description refinement
- 4.2.3 TKEY Initial key
- 4.2.3 TLAN Language(s)
- 4.2.3 TLEN Length
- 4.2.2 TMCL Musician credits list
- 4.2.3 TMED Media type
- 4.2.3 TMOO Mood
- 4.2.1 TOAL Original album/movie/show title
- 4.2.5 TOFN Original filename
- 4.2.2 TOLY Original lyricist(s)/text writer(s)
- 4.2.2 TOPE Original artist(s)/performer(s)
- 4.2.4 TOWN File owner/licensee
- 4.2.2 TPE1 Lead performer(s)/Soloist(s)
- 4.2.2 TPE2 Band/orchestra/accompaniment
- 4.2.2 TPE3 Conductor/performer refinement
- 4.2.2 TPE4 Interpreted, remixed, or otherwise modified by
- 4.2.1 TPOS Part of a set
- 4.2.4 TPRO Produced notice
- 4.2.4 TPUB Publisher
- 4.2.1 TRCK Track number/Position in set
- 4.2.4 TRSN Internet radio station name
- 4.2.4 TRSO Internet radio station owner
- 4.2.5 TSOA Album sort order
- 4.2.5 TSOP Performer sort order
- 4.2.5 TSOT Title sort order
- 4.2.1 TSRC ISRC (international standard recording code)
- 4.2.5 TSSE Software/Hardware and settings used for encoding
- 4.2.1 TSST Set subtitle
- 4.2.2 TXXX User defined text information frame
-
- 4.1 UFID Unique file identifier
- 4.22 USER Terms of use
- 4.8 USLT Unsynchronised lyric/text transcription
-
- 4.3.1 WCOM Commercial information
- 4.3.1 WCOP Copyright/Legal information
- 4.3.1 WOAF Official audio file webpage
- 4.3.1 WOAR Official artist/performer webpage
- 4.3.1 WOAS Official audio source webpage
- 4.3.1 WORS Official Internet radio station homepage
- 4.3.1 WPAY Payment
- 4.3.1 WPUB Publishers official webpage
- 4.3.2 WXXX User defined URL link frame
-
-
-4.1. Unique file identifier
-
- This frame's purpose is to be able to identify the audio file in a
- database, that may provide more information relevant to the content.
- Since standardisation of such a database is beyond this document, all
- UFID frames begin with an 'owner identifier' field. It is a null-
- terminated string with a URL [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. The string
- "http://www.id3.org/dummy/ufid.html" should be used for tests. The
- 'Owner identifier' must be non-empty (more than just a termination).
- The 'Owner identifier' is then followed by the actual identifier,
- which may be up to 64 bytes. There may be more than one "UFID" frame
- in a tag, but only one with the same 'Owner identifier'.
-
- <Header for 'Unique file identifier', ID: "UFID">
- Owner identifier <text string> $00
- Identifier <up to 64 bytes binary data>
-
-
-4.2. Text information frames
-
- The text information frames are often 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. All text
- information frames supports multiple strings, stored as a null
- separated list, where null is reperesented by the termination code
- for the charater encoding. All text frame identifiers begin with "T".
- Only text frame identifiers begin with "T", with the exception of the
- "TXXX" frame. All the text information frames have the following
- format:
-
- <Header for 'Text information frame', ID: "T000" - "TZZZ",
- excluding "TXXX" described in 4.2.6.>
- Text encoding $xx
- Information <text string(s) according to encoding>
-
-
-4.2.1. Identification frames
-
- TIT1
- The 'Content group description' frame is used if the sound belongs to
- a larger category of sounds/music. For example, classical music is
- often sorted in different musical sections (e.g. "Piano Concerto",
- "Weather - Hurricane").
-
- TIT2
- The 'Title/Songname/Content description' frame is the actual name of
- the piece (e.g. "Adagio", "Hurricane Donna").
-
- TIT3
- The 'Subtitle/Description refinement' frame is used for information
- directly related to the contents title (e.g. "Op. 16" or "Performed
- live at Wembley").
-
- TALB
- The 'Album/Movie/Show title' frame is intended for the title of the
- recording (or source of sound) from which the audio in the file is
- taken.
-
- TOAL
- The 'Original album/movie/show title' frame is intended for the title
- of the original recording (or source of sound), if for example the
- music in the file should be a cover of a previously released song.
-
- TRCK
- The 'Track number/Position in set' frame is a numeric string
- containing the order number of the audio-file on its original
- recording. This MAY be extended with a "/" character and a numeric
- string containing the total number of tracks/elements on the original
- recording. E.g. "4/9".
-
- TPOS
- The 'Part of a set' frame is a numeric string that describes which
- part of a set the audio came from. This frame is used if the source
- described in the "TALB" frame is divided into several mediums, e.g. a
- double CD. The value MAY be extended with a "/" character and a
- numeric string containing the total number of parts in the set. E.g.
- "1/2".
-
- TSST
- The 'Set subtitle' frame is intended for the subtitle of the part of
- a set this track belongs to.
-
- TSRC
- The 'ISRC' frame should contain the International Standard Recording
- Code [ISRC] (12 characters).
-
-
-4.2.2. Involved persons frames
-
- TPE1
- The 'Lead artist/Lead performer/Soloist/Performing group' is
- used for the main artist.
-
- TPE2
- The 'Band/Orchestra/Accompaniment' frame is used for additional
- information about the performers in the recording.
-
- TPE3
- The 'Conductor' frame is used for the name of the conductor.
-
- TPE4
- The 'Interpreted, remixed, or otherwise modified by' frame contains
- more information about the people behind a remix and similar
- interpretations of another existing piece.
-
- TOPE
- The 'Original artist/performer' frame is intended for the performer
- of the original recording, if for example the music in the file
- should be a cover of a previously released song.
-
- TEXT
- The 'Lyricist/Text writer' frame is intended for the writer of the
- text or lyrics in the recording.
-
- TOLY
- The 'Original lyricist/text writer' frame is intended for the
- text writer of the original recording, if for example the music in
- the file should be a cover of a previously released song.
-
- TCOM
- The 'Composer' frame is intended for the name of the composer.
-
- TMCL
- The 'Musician credits list' is intended as a mapping between
- instruments and the musician that played it. Every odd field is an
- instrument and every even is an artist or a comma delimited list of
- artists.
-
- TIPL
- The 'Involved people list' is very similar to the musician credits
- list, but maps between functions, like producer, and names.
-
- TENC
- The 'Encoded by' frame contains the name of the person or
- organisation that encoded the audio file. This field may contain a
- copyright message, if the audio file also is copyrighted by the
- encoder.
-
-
-4.2.3. Derived and subjective properties frames
-
- TBPM
- The 'BPM' frame contains the number of beats per minute in the
- main part of the audio. The BPM is an integer and represented as a
- numerical string.
-
- TLEN
- The 'Length' frame contains the length of the audio file in
- milliseconds, represented as a numeric string.
-
- TKEY
- The 'Initial key' frame contains the musical key in which the sound
- starts. It is represented as a string with a maximum length of three
- characters. The ground keys are represented with "A","B","C","D","E",
- "F" and "G" and halfkeys represented with "b" and "#". Minor is
- represented as "m", e.g. "Dbm" $00. Off key is represented with an
- "o" only.
-
- TLAN
- The 'Language' frame should contain the languages of the text or
- lyrics spoken or sung in the audio. The language is represented with
- three characters according to ISO-639-2 [ISO-639-2]. If more than one
- language is used in the text their language codes should follow
- according to the amount of their usage, e.g. "eng" $00 "sve" $00.
-
- TCON
- The 'Content type', which ID3v1 was stored as a one byte numeric
- value only, is now a string. You may use one or several of the ID3v1
- types as numerical strings, or, since the category list would be
- impossible to maintain with accurate and up to date categories,
- define your own. Example: "21" $00 "Eurodisco" $00
-
- You may also use any of the following keywords:
-
- RX Remix
- CR Cover
-
- TFLT
- The 'File type' frame indicates which type of audio this tag defines.
- The following types and refinements are defined:
-
- MIME MIME type follows
- MPG MPEG Audio
- /1 MPEG 1/2 layer I
- /2 MPEG 1/2 layer II
- /3 MPEG 1/2 layer III
- /2.5 MPEG 2.5
- /AAC Advanced audio compression
- VQF Transform-domain Weighted Interleave Vector Quantisation
- PCM Pulse Code Modulated audio
-
- but other types may be used, but not for these types though. This is
- used in a similar way to the predefined types in the "TMED" frame,
- but without parentheses. If this frame is not present audio type is
- assumed to be "MPG".
-
- TMED
- The 'Media type' frame describes from which media the sound
- originated. This may be a text string or a reference to the
- predefined media types found in the list below. Example:
- "VID/PAL/VHS" $00.
-
- DIG Other digital media
- /A Analogue transfer from media
-
- ANA Other analogue media
- /WAC Wax cylinder
- /8CA 8-track tape cassette
-
- CD CD
- /A Analogue transfer from media
- /DD DDD
- /AD ADD
- /AA AAD
-
- LD Laserdisc
-
- TT Turntable records
- /33 33.33 rpm
- /45 45 rpm
- /71 71.29 rpm
- /76 76.59 rpm
- /78 78.26 rpm
- /80 80 rpm
-
- MD MiniDisc
- /A Analogue transfer from media
-
- DAT DAT
- /A Analogue transfer from media
- /1 standard, 48 kHz/16 bits, linear
- /2 mode 2, 32 kHz/16 bits, linear
- /3 mode 3, 32 kHz/12 bits, non-linear, low speed
- /4 mode 4, 32 kHz/12 bits, 4 channels
- /5 mode 5, 44.1 kHz/16 bits, linear
- /6 mode 6, 44.1 kHz/16 bits, 'wide track' play
-
- DCC DCC
- /A Analogue transfer from media
-
- DVD DVD
- /A Analogue transfer from media
-
- TV Television
- /PAL PAL
- /NTSC NTSC
- /SECAM SECAM
-
- VID Video
- /PAL PAL
- /NTSC NTSC
- /SECAM SECAM
- /VHS VHS
- /SVHS S-VHS
- /BETA BETAMAX
-
- RAD Radio
- /FM FM
- /AM AM
- /LW LW
- /MW MW
-
- TEL Telephone
- /I ISDN
-
- MC MC (normal cassette)
- /4 4.75 cm/s (normal speed for a two sided cassette)
- /9 9.5 cm/s
- /I Type I cassette (ferric/normal)
- /II Type II cassette (chrome)
- /III Type III cassette (ferric chrome)
- /IV Type IV cassette (metal)
-
- REE Reel
- /9 9.5 cm/s
- /19 19 cm/s
- /38 38 cm/s
- /76 76 cm/s
- /I Type I cassette (ferric/normal)
- /II Type II cassette (chrome)
- /III Type III cassette (ferric chrome)
- /IV Type IV cassette (metal)
-
- TMOO
- The 'Mood' frame is intended to reflect the mood of the audio with a
- few keywords, e.g. "Romantic" or "Sad".
-
-
-4.2.4. Rights and license frames
-
- TCOP
- The 'Copyright message' frame, in which the string must begin with a
- year and a space character (making five characters), is intended for
- the copyright holder of the original sound, not the audio file
- itself. The absence of this frame means only that the copyright
- information is unavailable or has been removed, and must not be
- interpreted to mean that the audio is public domain. Every time this
- field is displayed the field must be preceded with "Copyright " (C) "
- ", where (C) is one character showing a C in a circle.
-
- TPRO
- The 'Produced notice' frame, in which the string must begin with a
- year and a space character (making five characters), is intended for
- the production copyright holder of the original sound, not the audio
- file itself. The absence of this frame means only that the production
- copyright information is unavailable or has been removed, and must
- not be interpreted to mean that the audio is public domain. Every
- time this field is displayed the field must be preceded with
- "Produced " (P) " ", where (P) is one character showing a P in a
- circle.
-
- TPUB
- The 'Publisher' frame simply contains the name of the label or
- publisher.
-
- TOWN
- The 'File owner/licensee' frame contains the name of the owner or
- licensee of the file and it's contents.
-
- TRSN
- The 'Internet radio station name' frame contains the name of the
- internet radio station from which the audio is streamed.
-
- TRSO
- The 'Internet radio station owner' frame contains the name of the
- owner of the internet radio station from which the audio is
- streamed.
-
-4.2.5. Other text frames
-
- TOFN
- The 'Original filename' frame contains the preferred filename for the
- file, since some media doesn't allow the desired length of the
- filename. The filename is case sensitive and includes its suffix.
-
- TDLY
- The 'Playlist delay' defines the numbers of milliseconds of silence
- that should be inserted before this audio. The value zero indicates
- that this is a part of a multifile audio track that should be played
- continuously.
-
- TDEN
- The 'Encoding time' frame contains a timestamp describing when the
- audio was encoded. Timestamp format is described in the ID3v2
- structure document [ID3v2-strct].
-
- TDOR
- The 'Original release time' frame contains a timestamp describing
- when the original recording of the audio was released. Timestamp
- format is described in the ID3v2 structure document [ID3v2-strct].
-
- TDRC
- The 'Recording time' frame contains a timestamp describing when the
- audio was recorded. Timestamp format is described in the ID3v2
- structure document [ID3v2-strct].
-
- TDRL
- The 'Release time' frame contains a timestamp describing when the
- audio was first released. Timestamp format is described in the ID3v2
- structure document [ID3v2-strct].
-
- TDTG
- The 'Tagging time' frame contains a timestamp describing then the
- audio was tagged. Timestamp format is described in the ID3v2
- structure document [ID3v2-strct].
-
- TSSE
- The 'Software/Hardware and settings used for encoding' frame
- includes the used audio encoder and its settings when the file was
- encoded. Hardware refers to hardware encoders, not the computer on
- which a program was run.
-
- TSOA
- The 'Album sort order' frame defines a string which should be used
- instead of the album name (TALB) for sorting purposes. E.g. an album
- named "A Soundtrack" might preferably be sorted as "Soundtrack".
-
- TSOP
- The 'Performer sort order' frame defines a string which should be
- used instead of the performer (TPE2) for sorting purposes.
-
- TSOT
- The 'Title sort order' frame defines a string which should be used
- instead of the title (TIT2) for sorting purposes.
-
-
-4.2.6. User defined text information frame
-
- This frame is intended for one-string text information concerning the
- audio file in a similar way to the other "T"-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
- "TXXX" frame in each tag, but only one with the same description.
-
- <Header for 'User defined text information frame', ID: "TXXX">
- Text encoding $xx
- Description <text string according to encoding> $00 (00)
- Value <text string according to encoding>
-
-
-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 [URL] link frame of its kind in an
- tag, except when stated otherwise in the frame description. If the
- text string is followed by a string termination, all the following
- information should be ignored and not be displayed. All URL link
- frame identifiers begins with "W". Only URL link frame identifiers
- begins with "W", except for "WXXX". All URL link frames have the
- following format:
-
- <Header for 'URL link frame', ID: "W000" - "WZZZ", excluding "WXXX"
- described in 4.3.2.>
- URL <text string>
-
-
-4.3.1. URL link frames - details
-
- WCOM
- The 'Commercial information' frame is a URL pointing at a webpage
- with information such as where the album can be bought. There may be
- more than one "WCOM" frame in a tag, but not with the same content.
-
- WCOP
- The 'Copyright/Legal information' frame is a URL pointing at a
- webpage where the terms of use and ownership of the file is
- described.
-
- WOAF
- The 'Official audio file webpage' frame is a URL pointing at a file
- specific webpage.
-
- WOAR
- The 'Official artist/performer webpage' frame is a URL pointing at
- the artists official webpage. There may be more than one "WOAR" frame
- in a tag if the audio contains more than one performer, but not with
- the same content.
-
- WOAS
- The 'Official audio source webpage' frame is a URL pointing at the
- official webpage for the source of the audio file, e.g. a movie.
-
- WORS
- The 'Official Internet radio station homepage' contains a URL
- pointing at the homepage of the internet radio station.
-
- WPAY
- The 'Payment' frame is a URL pointing at a webpage that will handle
- the process of paying for this file.
-
- WPUB
- The 'Publishers official webpage' frame is a URL pointing at the
- official webpage for the publisher.
-
-
-4.3.2. User defined URL link frame
-
- This frame is intended for URL [URL] links concerning the audio file
- in a similar way to the other "W"-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
- [ISO-8859-1]. There may be more than one "WXXX" frame in each tag,
- but only one with the same description.
-
- <Header for 'User defined URL link frame', ID: "WXXX">
- Text encoding $xx
- Description <text string according to encoding> $00 (00)
- URL <text string>
-
-
-4.4. 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 [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 plus 8
- bytes for the 'lead out', making a maximum of 804 bytes. The offset
- to the beginning of every track on the CD should be described with a
- four bytes absolute CD-frame address per track, and not with absolute
- time. When this frame is used the presence of a valid "TRCK" frame is
- REQUIRED, even if the CD's only got one track. It is recommended that
- this frame is always added to tags originating from CDs. There may
- only be one "MCDI" frame in each tag.
-
- <Header for 'Music CD identifier', ID: "MCDI">
- CD TOC <binary data>
-
-
-4.5. Event timing codes
-
- This frame allows synchronisation with key events in the audio. The
- header is:
-
- <Header for 'Event timing codes', ID: "ETCO">
- Time stamp format $xx
-
- Where time stamp format is:
-
- $01 Absolute time, 32 bit sized, using MPEG [MPEG] frames as unit
- $02 Absolute time, 32 bit sized, using milliseconds as unit
-
- Absolute 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:
-
- Type of event $xx
- Time stamp $xx (xx ...)
-
- The 'Time stamp' is set to zero if directly at the beginning of the
- sound or after the previous event. All events MUST be sorted in
- chronological order. The type of event is as follows:
-
- $00 padding (has no meaning)
- $01 end of initial silence
- $02 intro start
- $03 main part start
- $04 outro start
- $05 outro end
- $06 verse start
- $07 refrain start
- $08 interlude start
- $09 theme start
- $0A variation start
- $0B key change
- $0C time change
- $0D momentary unwanted noise (Snap, Crackle & Pop)
- $0E sustained noise
- $0F sustained noise end
- $10 intro end
- $11 main part end
- $12 verse end
- $13 refrain end
- $14 theme end
- $15 profanity
- $16 profanity end
-
- $17-$DF reserved for future use
-
- $E0-$EF not predefined synch 0-F
-
- $F0-$FC reserved for future use
-
- $FD audio end (start of silence)
- $FE audio file ends
- $FF one more byte of events follows (all the following bytes with
- the value $FF have the same function)
-
- Terminating the start events such as "intro start" is OPTIONAL. The
- 'Not predefined synch's ($E0-EF) are for user events. You might want
- to synchronise your music to something, like setting off an explosion
- on-stage, activating a screensaver etc.
-
- There may only be one "ETCO" frame in each tag.
-
-
-4.6. MPEG location lookup table
-
- To increase performance and accuracy of jumps within a MPEG [MPEG]
- audio file, frames with time codes in different locations in the file
- might be useful. This ID3v2 frame includes references that the
- software can use to calculate positions in the file. After the frame
- header follows a descriptor of how much the 'frame counter' should be
- increased 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 "MLLT" frame in each tag.
-
- <Header for 'Location lookup table', ID: "MLLT">
- MPEG frames between reference $xx xx
- Bytes between reference $xx xx xx
- Milliseconds between reference $xx xx xx
- Bits for bytes deviation $xx
- Bits for milliseconds dev. $xx
-
- Then for every reference the following data is included;
-
- Deviation in bytes %xxx....
- Deviation in milliseconds %xxx....
-
-
-4.7. Synchronised 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 MUST 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 "SYTC" frame in
- each tag.
-
- <Header for 'Synchronised tempo codes', ID: "SYTC">
- Time stamp format $xx
- Tempo data <binary data>
-
- Where time stamp format is:
-
- $01 Absolute time, 32 bit sized, using MPEG [MPEG] frames as unit
- $02 Absolute time, 32 bit sized, using milliseconds as unit
-
- Absolute time means that every stamp contains the time from the
- beginning of the file.
-
-
-4.8. Unsynchronised 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. There may be more than one 'Unsynchronised
- lyrics/text transcription' frame in each tag, but only one with the
- same language and content descriptor.
-
- <Header for 'Unsynchronised lyrics/text transcription', ID: "USLT">
- Text encoding $xx
- Language $xx xx xx
- Content descriptor <text string according to encoding> $00 (00)
- Lyrics/text <full text string according to encoding>
-
-
-4.9. 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 text string. If no
- descriptor is entered, 'Content descriptor' is $00 (00) only.
-
- <Header for 'Synchronised lyrics/text', ID: "SYLT">
- Text encoding $xx
- Language $xx xx xx
- Time stamp format $xx
- Content type $xx
- Content descriptor <text string according to encoding> $00 (00)
-
- Content type: $00 is other
- $01 is lyrics
- $02 is text transcription
- $03 is movement/part name (e.g. "Adagio")
- $04 is events (e.g. "Don Quijote enters the stage")
- $05 is chord (e.g. "Bb F Fsus")
- $06 is trivia/'pop up' information
- $07 is URLs to webpages
- $08 is URLs to images
-
- Time stamp format:
-
- $01 Absolute time, 32 bit sized, using MPEG [MPEG] frames as unit
- $02 Absolute time, 32 bit sized, using milliseconds as unit
-
- Absolute 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:
-
- Terminated text to be synced (typically a syllable)
- Sync identifier (terminator to above string) $00 (00)
- Time stamp $xx (xx ...)
-
- 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 "SYLT" frames and MUST 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 "USLT" passage
-
- "Strangers in the night" $0A "Exchanging glances"
-
- would be "SYLT" 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 "SYLT" frame in each tag, but only one
- with the same language and content descriptor.
-
-
-4.10. Comments
-
- This frame is intended for any kind of full text information that
- does not fit in any other frame. It consists of a frame header
- 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.
-
- <Header for 'Comment', ID: "COMM">
- Text encoding $xx
- Language $xx xx xx
- Short content descrip. <text string according to encoding> $00 (00)
- The actual text <full text string according to encoding>
-
-
-4.11. Relative volume adjustment (2)
-
- This is a more subjective frame than the previous ones. It allows the
- user to say how much he wants to increase/decrease the volume on each
- channel when 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. The volume adjustment is encoded as a fixed point decibel
- value, 16 bit signed integer representing (adjustment*512), giving
- +/- 64 dB with a precision of 0.001953125 dB. E.g. +2 dB is stored as
- $04 00 and -2 dB is $FC 00. There may be more than one "RVA2" frame
- in each tag, but only one with the same identification string.
-
- <Header for 'Relative volume adjustment (2)', ID: "RVA2">
- Identification <text string> $00
-
- The 'identification' string is used to identify the situation and/or
- device where this adjustment should apply. The following is then
- repeated for every channel
-
- Type of channel $xx
- Volume adjustment $xx xx
- Bits representing peak $xx
- Peak volume $xx (xx ...)
-
-
- Type of channel: $00 Other
- $01 Master volume
- $02 Front right
- $03 Front left
- $04 Back right
- $05 Back left
- $06 Front centre
- $07 Back centre
- $08 Subwoofer
-
- Bits representing peak can be any number between 0 and 255. 0 means
- that there is no peak volume field. The peak volume field is always
- padded to whole bytes, setting the most significant bits to zero.
-
-
-4.12. Equalisation (2)
-
- This is another subjective, alignment frame. It allows the user to
- predefine an equalisation curve within the audio file. There may be
- more than one "EQU2" frame in each tag, but only one with the same
- identification string.
-
- <Header of 'Equalisation (2)', ID: "EQU2">
- Interpolation method $xx
- Identification <text string> $00
-
- The 'interpolation method' describes which method is preferred when
- an interpolation between the adjustment point that follows. The
- following methods are currently defined:
-
- $00 Band
- No interpolation is made. A jump from one adjustment level to
- another occurs in the middle between two adjustment points.
- $01 Linear
- Interpolation between adjustment points is linear.
-
- The 'identification' string is used to identify the situation and/or
- device where this adjustment should apply. The following is then
- repeated for every adjustment point
-
- Frequency $xx xx
- Volume adjustment $xx xx
-
- The frequency is stored in units of 1/2 Hz, giving it a range from 0
- to 32767 Hz.
-
- The volume adjustment is encoded as a fixed point decibel value, 16
- bit signed integer representing (adjustment*512), giving +/- 64 dB
- with a precision of 0.001953125 dB. E.g. +2 dB is stored as $04 00
- and -2 dB is $FC 00.
-
- Adjustment points should be ordered by frequency and one frequency
- should only be described once in the frame.
-
-
-4.13. Reverb
-
- Yet another subjective frame, with which you can 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, 50% of that 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 "RVRB" frame in
- each tag.
-
- <Header for 'Reverb', ID: "RVRB">
- Reverb left (ms) $xx xx
- Reverb right (ms) $xx xx
- Reverb bounces, left $xx
- Reverb bounces, right $xx
- Reverb feedback, left to left $xx
- Reverb feedback, left to right $xx
- Reverb feedback, right to right $xx
- Reverb feedback, right to left $xx
- Premix left to right $xx
- Premix right to left $xx
-
-
-4.14. Attached picture
-
- This frame contains a picture directly related to the audio file.
- Image format is the MIME type and subtype [MIME] for the image. In
- the event that the MIME media type name is omitted, "image/" will be
- implied. The "image/png" [PNG] or "image/jpeg" [JFIF] picture format
- should be used when interoperability is wanted. Description is a
- short description of the picture, represented as a terminated
- text string. There may be several pictures attached to one file, each
- in their individual "APIC" 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 the
- possibility to put only a link to the image file by using the 'MIME
- type' "-->" and having a complete URL [URL] instead of picture data.
- The use of linked files should however be used sparingly since there
- is the risk of separation of files.
-
- <Header for 'Attached picture', ID: "APIC">
- Text encoding $xx
- MIME type <text string> $00
- Picture type $xx
- Description <text string according to encoding> $00 (00)
- Picture data <binary data>
-
-
- Picture type: $00 Other
- $01 32x32 pixels 'file icon' (PNG only)
- $02 Other file icon
- $03 Cover (front)
- $04 Cover (back)
- $05 Leaflet page
- $06 Media (e.g. label side of CD)
- $07 Lead artist/lead performer/soloist
- $08 Artist/performer
- $09 Conductor
- $0A Band/Orchestra
- $0B Composer
- $0C Lyricist/text writer
- $0D Recording Location
- $0E During recording
- $0F During performance
- $10 Movie/video screen capture
- $11 A bright coloured fish
- $12 Illustration
- $13 Band/artist logotype
- $14 Publisher/Studio logotype
-
-
-4.15. General encapsulated object
-
- In this frame any type of file can be encapsulated. After the header,
- 'Frame size' and 'Encoding' follows 'MIME type' [MIME] represented as
- as a terminated string encoded with ISO 8859-1 [ISO-8859-1]. The
- filename is case sensitive and is encoded as 'Encoding'. 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 "GEOB"
- frame in each tag, but only one with the same content descriptor.
-
- <Header for 'General encapsulated object', ID: "GEOB">
- Text encoding $xx
- MIME type <text string> $00
- Filename <text string according to encoding> $00 (00)
- Content description <text string according to encoding> $00 (00)
- Encapsulated object <binary data>
-
-
-4.16. 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 "PCNT" 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.
-
- <Header for 'Play counter', ID: "PCNT">
- Counter $xx xx xx xx (xx ...)
-
-
-4.17. 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 audio files more often than others or
- it could be used to profile a person's taste and find other 'good'
- files by comparing people's profiles. The frame 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 ("PCNT"). There may be
- more than one "POPM" frame in each tag, but only one with the same
- email address.
-
- <Header for 'Popularimeter', ID: "POPM">
- Email to user <text string> $00
- Rating $xx
- Counter $xx xx xx xx (xx ...)
-
-
-4.18. Recommended buffer size
-
- Sometimes the server from which an 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 audio
- stream. In such case the tag should reside between two MPEG [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 are
- generally not recommended since this could render unpredictable
- behaviour from present software/hardware.
-
- For applications like streaming audio it might be an idea to embed
- tags into the audio stream though. If the clients connects to
- individual connections like HTTP and there is a possibility to begin
- every transmission with a tag, then this tag should include a
- 'recommended buffer size' frame. If the client is connected to a
- arbitrary point in the stream, such as radio or multicast, then the
- 'recommended buffer size' frame SHOULD be included in every tag.
-
- The 'Buffer size' should be kept to a minimum. There may only be one
- "RBUF" frame in each tag.
-
- <Header for 'Recommended buffer size', ID: "RBUF">
- Buffer size $xx xx xx
- Embedded info flag %0000000x
- Offset to next tag $xx xx xx xx
-
-
-4.19. Audio encryption
-
- This frame indicates if the actual audio stream is encrypted, and by
- whom. Since standardisation of such encryption scheme is beyond this
- document, all "AENC" 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
- audio file 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
- data block required for decryption of the audio. There may be more
- than one "AENC" frames in a tag, but only one with the same 'Owner
- identifier'.
-
- <Header for 'Audio encryption', ID: "AENC">
- Owner identifier <text string> $00
- Preview start $xx xx
- Preview length $xx xx
- Encryption info <binary data>
-
-
-4.20. Linked information
-
- To keep information duplication 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 separation 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 "LINK" 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 "RVRB" frame allowed,
- whether it's linked or not).
-
- <Header for 'Linked information', ID: "LINK">
- Frame identifier $xx xx xx xx
- URL <text string> $00
- ID and additional data <text string(s)>
-
- Frames that may be linked and need no additional data are "ASPI",
- "ETCO", "EQU2", "MCID", "MLLT", "OWNE", "RVA2", "RVRB", "SYTC", the
- text information frames and the URL link frames.
-
- The "AENC", "APIC", "GEOB" and "TXXX" frames may be linked with
- the content descriptor as additional ID data.
-
- The "USER" frame may be linked with the language field as additional
- ID data.
-
- The "PRIV" frame may be linked with the owner identifier as
- additional ID data.
-
- The "COMM", "SYLT" and "USLT" frames may be linked with three bytes
- of language descriptor directly followed by a content descriptor as
- additional ID data.
-
-
-4.21. Position synchronisation frame
-
- This frame delivers information to the listener of how far into the
- audio stream he picked up; in effect, it states the time offset from
- the first frame in the stream. The frame layout is:
-
- <Head for 'Position synchronisation', ID: "POSS">
- Time stamp format $xx
- Position $xx (xx ...)
-
- Where 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
-
- and position is where in the audio the listener starts to receive,
- i.e. the beginning of the next frame. If this frame is used in the
- beginning of a file the value is always 0. There may only be one
- "POSS" frame in each tag.
-
-
-4.22. Terms of use frame
-
- This frame contains a brief description of the terms of use and
- ownership of the file. More detailed information concerning the legal
- terms might be available through the "WCOP" frame. Newlines are
- allowed in the text. There may be more than one 'Terms of use' frame
- in a tag, but only one with the same 'Language'.
-
- <Header for 'Terms of use frame', ID: "USER">
- Text encoding $xx
- Language $xx xx xx
- The actual text <text string according to encoding>
-
-
-4.23. Ownership frame
-
- The ownership frame might be used as a reminder of a made transaction
- or, if signed, as proof. Note that the "USER" and "TOWN" frames are
- good to use in conjunction with this one. The frame begins, after the
- frame ID, size and encoding fields, with a 'price paid' field. The
- first three characters of this field contains the currency used for
- the transaction, encoded according to ISO 4217 [ISO-4217] alphabetic
- currency code. Concatenated to this is the actual price paid, as a
- numerical string using "." as the decimal separator. Next is an 8
- character date string (YYYYMMDD) followed by a string with the name
- of the seller as the last field in the frame. There may only be one
- "OWNE" frame in a tag.
-
- <Header for 'Ownership frame', ID: "OWNE">
- Text encoding $xx
- Price paid <text string> $00
- Date of purch. <text string>
- Seller <text string according to encoding>
-
-
-4.24. Commercial frame
-
- This frame enables several competing offers in the same tag by
- bundling all needed information. That makes this frame rather complex
- but it's an easier solution than if one tries to achieve the same
- result with several frames. The frame begins, after the frame ID,
- size and encoding fields, with a price string field. A price is
- constructed by one three character currency code, encoded according
- to ISO 4217 [ISO-4217] alphabetic currency code, followed by a
- numerical value where "." is used as decimal separator. In the price
- string several prices may be concatenated, separated by a "/"
- character, but there may only be one currency of each type.
-
- The price string is followed by an 8 character date string in the
- format YYYYMMDD, describing for how long the price is valid. After
- that is a contact URL, with which the user can contact the seller,
- followed by a one byte 'received as' field. It describes how the
- audio is delivered when bought according to the following list:
-
- $00 Other
- $01 Standard CD album with other songs
- $02 Compressed audio on CD
- $03 File over the Internet
- $04 Stream over the Internet
- $05 As note sheets
- $06 As note sheets in a book with other sheets
- $07 Music on other media
- $08 Non-musical merchandise
-
- Next follows a terminated string with the name of the seller followed
- by a terminated string with a short description of the product. The
- last thing is the ability to include a company logotype. The first of
- them is the 'Picture MIME type' field containing information about
- which picture format is used. In the event that the MIME media type
- name is omitted, "image/" will be implied. Currently only "image/png"
- and "image/jpeg" are allowed. This format string is followed by the
- binary picture data. This two last fields may be omitted if no
- picture is attached. There may be more than one 'commercial frame' in
- a tag, but no two may be identical.
-
- <Header for 'Commercial frame', ID: "COMR">
- Text encoding $xx
- Price string <text string> $00
- Valid until <text string>
- Contact URL <text string> $00
- Received as $xx
- Name of seller <text string according to encoding> $00 (00)
- Description <text string according to encoding> $00 (00)
- Picture MIME type <string> $00
- Seller logo <binary data>
-
-
-4.25. Encryption method registration
-
- To identify with which method a frame has been encrypted the
- encryption method must be registered in the tag with this frame. The
- 'Owner identifier' is a null-terminated string with a URL [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 encryption method. Questions regarding the
- encryption method should be sent to the indicated email address. The
- 'Method symbol' contains a value that is associated with this method
- throughout the whole tag, in the range $80-F0. All other values are
- reserved. The 'Method symbol' may optionally be followed by
- encryption specific data. There may be several "ENCR" frames in a tag
- but only one containing the same symbol and only one containing the
- same owner identifier. The method must be used somewhere in the tag.
- See the description of the frame encryption flag in the ID3v2
- structure document [ID3v2-strct] for more information.
-
- <Header for 'Encryption method registration', ID: "ENCR">
- Owner identifier <text string> $00
- Method symbol $xx
- Encryption data <binary data>
-
-
-4.26. Group identification registration
-
- This frame enables grouping of otherwise unrelated frames. This can
- be used when some frames are to be signed. To identify which frames
- belongs to a set of frames a group identifier must be registered in
- the tag with this frame. The 'Owner identifier' is a null-terminated
- string with a URL [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 grouping. Questions regarding the
- grouping should be sent to the indicated email address. The 'Group
- symbol' contains a value that associates the frame with this group
- throughout the whole tag, in the range $80-F0. All other values are
- reserved. The 'Group symbol' may optionally be followed by some group
- specific data, e.g. a digital signature. There may be several "GRID"
- frames in a tag but only one containing the same symbol and only one
- containing the same owner identifier. The group symbol must be used
- somewhere in the tag. See the description of the frame grouping flag
- in the ID3v2 structure document [ID3v2-strct] for more information.
-
- <Header for 'Group ID registration', ID: "GRID">
- Owner identifier <text string> $00
- Group symbol $xx
- Group dependent data <binary data>
-
-
-4.27. Private frame
-
- This frame is used to contain information from a software producer
- that its program uses and does not fit into the other frames. The
- frame consists of an 'Owner identifier' string and the binary data.
- The 'Owner identifier' is a null-terminated string with a URL [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 the frame. Questions regarding the frame should be sent to the
- indicated email address. The tag may contain more than one "PRIV"
- frame but only with different contents.
-
- <Header for 'Private frame', ID: "PRIV">
- Owner identifier <text string> $00
- The private data <binary data>
-
-
-4.28. Signature frame
-
- This frame enables a group of frames, grouped with the 'Group
- identification registration', to be signed. Although signatures can
- reside inside the registration frame, it might be desired to store
- the signature elsewhere, e.g. in watermarks. There may be more than
- one 'signature frame' in a tag, but no two may be identical.
-
- <Header for 'Signature frame', ID: "SIGN">
- Group symbol $xx
- Signature <binary data>
-
-
-4.29. Seek frame
-
- This frame indicates where other tags in a file/stream can be found.
- The 'minimum offset to next tag' is calculated from the end of this
- tag to the beginning of the next. There may only be one 'seek frame'
- in a tag.
-
- <Header for 'Seek frame', ID: "SEEK">
- Minimum offset to next tag $xx xx xx xx
-
-
-4.30. Audio seek point index
-
- Audio files with variable bit rates are intrinsically difficult to
- deal with in the case of seeking within the file. The ASPI frame
- makes seeking easier by providing a list a seek points within the
- audio file. The seek points are a fractional offset within the audio
- data, providing a starting point from which to find an appropriate
- point to start decoding. The presence of an ASPI frame requires the
- existence of a TLEN frame, indicating the duration of the file in
- milliseconds. There may only be one 'audio seek point index' frame in
- a tag.
-
- <Header for 'Seek Point Index', ID: "ASPI">
- Indexed data start (S) $xx xx xx xx
- Indexed data length (L) $xx xx xx xx
- Number of index points (N) $xx xx
- Bits per index point (b) $xx
-
- Then for every index point the following data is included;
-
- Fraction at index (Fi) $xx (xx)
-
- 'Indexed data start' is a byte offset from the beginning of the file.
- 'Indexed data length' is the byte length of the audio data being
- indexed. 'Number of index points' is the number of index points, as
- the name implies. The recommended number is 100. 'Bits per index
- point' is 8 or 16, depending on the chosen precision. 8 bits works
- well for short files (less than 5 minutes of audio), while 16 bits is
- advantageous for long files. 'Fraction at index' is the numerator of
- the fraction representing a relative position in the data. The
- denominator is 2 to the power of b.
-
- Here are the algorithms to be used in the calculation. The known data
- must be the offset of the start of the indexed data (S), the offset
- of the end of the indexed data (E), the number of index points (N),
- the offset at index i (Oi). We calculate the fraction at index i
- (Fi).
-
- Oi is the offset of the frame whose start is soonest after the point
- for which the time offset is (i/N * duration).
-
- The frame data should be calculated as follows:
-
- Fi = Oi/L * 2^b (rounded down to the nearest integer)
-
- Offset calculation should be calculated as follows from data in the
- frame:
-
- Oi = (Fi/2^b)*L (rounded up to the nearest integer)
-
-
-5. Copyright
-
- Copyright (C) Martin Nilsson 2000. All Rights Reserved.
-
- 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.
-
- 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.
-
-
-6. References
-
- [CDDB] Compact Disc Data Base
-
- <url:http://www.cddb.com>
-
- [ID3v2.3.0] Martin Nilsson, "ID3v2 informal standard".
-
- <url:http://www.id3.org/id3v2.3.0.txt>
-
- [ID3v2-strct] Martin Nilsson,
- "ID3 tag version 2.4.0 - Main Structure"
-
- <url:http//www.id3.org/id3v2.4.0-structure.txt>
-
- [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-4217] ISO 4217:1995.
- Codes for the representation of currencies and funds.
- Technical committee / subcommittee: TC 68
-
- [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>
-
- [KEYWORDS] S. Bradner, 'Key words for use in RFCs to Indicate
- Requirement Levels', RFC 2119, March 1997.
-
- <url:ftp://ftp.isi.edu/in-notes/rfc2119.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>
-
- [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>
-
- [ZLIB] P. Deutsch, Aladdin Enterprises & J-L. Gailly, "ZLIB
- Compressed
- Data Format Specification version 3.3", RFC 1950, May 1996.
-
- <url:ftp://ftp.isi.edu/in-notes/rfc1950.txt>
-
-
-7. Appendix
-
-
-A. Appendix A - Genre List from ID3v1
-
- The following genres is defined in ID3v1
-
- 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
-
-
-8. Author's Address
-
- Written by
-
- Martin Nilsson
- Rydsvägen 246 C. 30
- SE-584 34 Linköping
- Sweden
-
- Email: nilsson@id3.org
+++ /dev/null
-
-Informal standard M. Nilsson
-Document: id3v2.4.0-structure.txt 16 September 2001
-
-
- ID3 tag version 2.4.0 - Main Structure
-
-Status of this document
-
- This document is an informal standard and replaces the ID3v2.3.0
- standard [ID3v2]. A formal standard will use another revision number
- even if the content is identical to document. The contents in this
- document may change for clarifications but never for added or altered
- functionallity.
-
- Distribution of this document is unlimited.
-
-
-Abstract
-
- This document describes the main structure of ID3v2.4.0, which is a
- revised version of the ID3v2 informal standard [ID3v2] version
- 2.3.0. The ID3v2 offers a flexible way of storing audio meta
- information within the audio file itself. The information may be
- technical information, such as equalisation curves, as well as
- title, performer, copyright etc.
-
- ID3v2.4.0 is meant to be as close as possible to ID3v2.3.0 in order
- to allow for implementations to be revised as easily as possible.
-
-
-1. Table of contents
-
- Status of this document
- Abstract
- 1. Table of contents
- 2. Conventions in this document
- 2. Standard overview
- 3. ID3v2 overview
- 3.1. ID3v2 header
- 3.2. ID3v2 extended header
- 3.3. Padding
- 3.4. ID3v2 footer
- 4. ID3v2 frames overview
- 4.1. Frame header flags
- 4.1.1. Frame status flags
- 4.1.2. Frame format flags
- 5. Tag location
- 6. Unsynchronisation
- 6.1. The unsynchronisation scheme
- 6.2. Synchsafe integers
- 7. Copyright
- 8. References
- 9. Author's Address
-
-
-2. Conventions in this document
-
- Text within "" is a text string exactly as it appears in a tag.
- 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'.
-
- 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 "0123456789" only.
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in RFC 2119 [KEYWORDS].
-
-
-3. ID3v2 overview
-
- ID3v2 is a general tagging format for audio, which makes it possible
- to store meta data about the audio inside the audio file itself. 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 or as a
- stand alone format for audio meta data.
-
- ID3v2 is designed to be as flexible and expandable as possible to
- meet new meta information needs that might arise. To achieve that
- ID3v2 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 is an unique and
- predefined identifier, a size descriptor that allows software to skip
- unknown frames and a flags field. The flags describes encoding
- details and if the frame should remain in the tag, should it be
- unknown to the software, if the file is altered.
-
- 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), also known as big endian
- and network byte order.
-
- Overall tag structure:
-
- +-----------------------------+
- | Header (10 bytes) |
- +-----------------------------+
- | Extended Header |
- | (variable length, OPTIONAL) |
- +-----------------------------+
- | Frames (variable length) |
- +-----------------------------+
- | Padding |
- | (variable length, OPTIONAL) |
- +-----------------------------+
- | Footer (10 bytes, OPTIONAL) |
- +-----------------------------+
-
- In general, padding and footer are mutually exclusive. See details in
- sections 3.3, 3.4 and 5.
-
-
-3.1. ID3v2 header
-
- The first part of the ID3v2 tag is the 10 byte tag header, laid out
- as follows:
-
- ID3v2/file identifier "ID3"
- ID3v2 version $04 00
- ID3v2 flags %abcd0000
- 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 its major version, while the second
- byte is its revision number. In this case this is ID3v2.4.0. All
- revisions are backwards compatible while major versions are not. If
- software with ID3v2.4.0 and below support should encounter version
- five or higher it should simply ignore the whole tag. Version or
- revision will never be $FF.
-
- The version is followed by the ID3v2 flags field, of which currently
- four flags are used.
-
-
- a - Unsynchronisation
-
- Bit 7 in the 'ID3v2 flags' indicates whether or not
- unsynchronisation is applied on all frames (see section 6.1 for
- details); 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. The extended header is described in
- section 3.2. A set bit indicates the presence of an extended
- header.
-
-
- c - Experimental indicator
-
- The third bit (bit 5) is used as an 'experimental indicator'. This
- flag SHALL always be set when the tag is in an experimental stage.
-
-
- d - Footer present
-
- Bit 4 indicates that a footer (section 3.4) is present at the very
- end of the tag. A set bit indicates the presence of a footer.
-
-
- All the other flags MUST be cleared. If one of these undefined flags
- are set, the tag might not be readable for a parser that does not
- know the flags function.
-
- The ID3v2 tag size is stored as a 32 bit synchsafe integer (section
- 6.2), making a total of 28 effective bits (representing up to 256MB).
-
- The ID3v2 tag size is the sum of the byte length of the extended
- header, the padding and the frames after unsynchronisation. If a
- footer is present this equals to ('total size' - 20) bytes, otherwise
- ('total size' - 10) bytes.
-
- 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. Extended header
-
- The extended header contains information that can provide further
- insight in the structure of the tag, but is not vital to the correct
- parsing of the tag information; hence the extended header is
- optional.
-
- Extended header size 4 * %0xxxxxxx
- Number of flag bytes $01
- Extended Flags $xx
-
- Where the 'Extended header size' is the size of the whole extended
- header, stored as a 32 bit synchsafe integer. An extended header can
- thus never have a size of fewer than six bytes.
-
- The extended flags field, with its size described by 'number of flag
- bytes', is defined as:
-
- %0bcd0000
-
- Each flag that is set in the extended header has data attached, which
- comes in the order in which the flags are encountered (i.e. the data
- for flag 'b' comes before the data for flag 'c'). Unset flags cannot
- have any attached data. All unknown flags MUST be unset and their
- corresponding data removed when a tag is modified.
-
- Every set flag's data starts with a length byte, which contains a
- value between 0 and 127 ($00 - $7f), followed by data that has the
- field length indicated by the length byte. If a flag has no attached
- data, the value $00 is used as length byte.
-
-
- b - Tag is an update
-
- If this flag is set, the present tag is an update of a tag found
- earlier in the present file or stream. If frames defined as unique
- are found in the present tag, they are to override any
- corresponding ones found in the earlier tag. This flag has no
- corresponding data.
-
- Flag data length $00
-
- c - CRC data present
-
- If this flag is set, a CRC-32 [ISO-3309] data is included in the
- extended header. The CRC is calculated on all the data between the
- header and footer as indicated by the header's tag length field,
- minus the extended header. Note that this includes the padding (if
- there is any), but excludes the footer. The CRC-32 is stored as an
- 35 bit synchsafe integer, leaving the upper four bits always
- zeroed.
-
- Flag data length $05
- Total frame CRC 5 * %0xxxxxxx
-
- d - Tag restrictions
-
- For some applications it might be desired to restrict a tag in more
- ways than imposed by the ID3v2 specification. Note that the
- presence of these restrictions does not affect how the tag is
- decoded, merely how it was restricted before encoding. If this flag
- is set the tag is restricted as follows:
-
- Flag data length $01
- Restrictions %ppqrrstt
-
- p - Tag size restrictions
-
- 00 No more than 128 frames and 1 MB total tag size.
- 01 No more than 64 frames and 128 KB total tag size.
- 10 No more than 32 frames and 40 KB total tag size.
- 11 No more than 32 frames and 4 KB total tag size.
-
- q - Text encoding restrictions
-
- 0 No restrictions
- 1 Strings are only encoded with ISO-8859-1 [ISO-8859-1] or
- UTF-8 [UTF-8].
-
- r - Text fields size restrictions
-
- 00 No restrictions
- 01 No string is longer than 1024 characters.
- 10 No string is longer than 128 characters.
- 11 No string is longer than 30 characters.
-
- Note that nothing is said about how many bytes is used to
- represent those characters, since it is encoding dependent. If a
- text frame consists of more than one string, the sum of the
- strungs is restricted as stated.
-
- s - Image encoding restrictions
-
- 0 No restrictions
- 1 Images are encoded only with PNG [PNG] or JPEG [JFIF].
-
- t - Image size restrictions
-
- 00 No restrictions
- 01 All images are 256x256 pixels or smaller.
- 10 All images are 64x64 pixels or smaller.
- 11 All images are exactly 64x64 pixels, unless required
- otherwise.
-
-
-3.3. Padding
-
- It is OPTIONAL to include padding after 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 tag header. 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. A tag MUST NOT have
- any padding between the frames or between the tag header and the
- frames. Furthermore it MUST NOT have any padding when a tag footer is
- added to the tag.
-
-
-3.4. ID3v2 footer
-
- To speed up the process of locating an ID3v2 tag when searching from
- the end of a file, a footer can be added to the tag. It is REQUIRED
- to add a footer to an appended tag, i.e. a tag located after all
- audio data. The footer is a copy of the header, but with a different
- identifier.
-
- ID3v2 identifier "3DI"
- ID3v2 version $04 00
- ID3v2 flags %abcd0000
- ID3v2 size 4 * %0xxxxxxx
-
-
-4. ID3v2 frame overview
-
- All ID3v2 frames consists of one frame header followed by one or more
- fields containing the actual information. The header is always 10
- bytes and laid out as follows:
-
- Frame ID $xx xx xx xx (four characters)
- Size 4 * %0xxxxxxx
- Flags $xx xx
-
- The frame ID is made out of the characters capital A-Z and 0-9.
- Identifiers beginning with "X", "Y" and "Z" are for experimental
- frames and free for everyone to use, without the need to set the
- experimental bit in the tag header. Bear 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 containing the size of
- the data in the final frame, after encryption, compression and
- unsynchronisation. The size is excluding the frame header ('total
- frame size' - 10 bytes) and stored as a 32 bit synchsafe integer.
-
- In the frame header the size descriptor is followed by two flag
- bytes. These flags are described in section 4.1.
-
- 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, strings, including numeric strings and URLs
- [URL], are represented as ISO-8859-1 [ISO-8859-1] characters in the
- range $20 - $FF. Such strings are represented in frame descriptions
- as <text string>, or <full text string> if newlines are allowed. If
- nothing else is said newline character is forbidden. In ISO-8859-1 a
- newline is represented, when allowed, with $0A only.
-
- Frames that allow different types of text encoding contains a text
- encoding description byte. Possible encodings:
-
- $00 ISO-8859-1 [ISO-8859-1]. Terminated with $00.
- $01 UTF-16 [UTF-16] encoded Unicode [UNICODE] with BOM. All
- strings in the same frame SHALL have the same byteorder.
- Terminated with $00 00.
- $02 UTF-16BE [UTF-16] encoded Unicode [UNICODE] without BOM.
- Terminated with $00 00.
- $03 UTF-8 [UTF-8] encoded Unicode [UNICODE]. Terminated with $00.
-
- Strings dependent on encoding are represented in frame descriptions
- as <text string according to encoding>, or <full text string
- according to encoding> if newlines are allowed. Any empty strings of
- type $01 which are NULL-terminated may have the Unicode BOM followed
- by a Unicode NULL ($FF FE 00 00 or $FE FF 00 00).
-
- The timestamp fields are based on a subset of ISO 8601. When being as
- precise as possible the format of a time string is
- yyyy-MM-ddTHH:mm:ss (year, "-", month, "-", day, "T", hour (out of
- 24), ":", minutes, ":", seconds), but the precision may be reduced by
- removing as many time indicators as wanted. Hence valid timestamps
- are
- yyyy, yyyy-MM, yyyy-MM-dd, yyyy-MM-ddTHH, yyyy-MM-ddTHH:mm and
- yyyy-MM-ddTHH:mm:ss. All time stamps are UTC. For durations, use
- the slash character as described in 8601, and for multiple non-
- contiguous dates, use multiple strings, if allowed by the frame
- definition.
-
- The three byte language field, present in several frames, is used to
- describe the language of the frame's content, according to ISO-639-2
- [ISO-639-2]. The language should be represented in lower case. If the
- language is not known the string "XXX" should be used.
-
- All URLs [URL] 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 flag
- bytes. All unused flags MUST be cleared. The first byte is for
- 'status messages' and the second byte is a format description. If an
- unknown flag is set in the first byte the frame MUST NOT be changed
- without that bit cleared. If an unknown flag is set in the second
- byte the frame is likely to not be readable. Some flags in the second
- byte indicates that extra information is added to the header. These
- fields of extra information is ordered as the flags that indicates
- them. The flags field is defined as follows (l and o left out because
- ther resemblence to one and zero):
-
- %0abc0000 %0h00kmnp
-
- Some frame format flags indicate that additional information fields
- are added to the frame. This information is added after the frame
- header and before the frame data in the same order as the flags that
- indicates them. I.e. the four bytes of decompressed size will precede
- the encryption method byte. These additions affects the 'frame size'
- field, but are not subject to encryption or compression.
-
- The default status flags setting for a frame is, unless stated
- otherwise, 'preserved if tag is altered' and 'preserved if file is
- altered', i.e. %00000000.
-
-
-4.1.1. Frame status flags
-
- a - Tag alter preservation
-
- This flag tells the tag parser 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 tag parser 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 are intended to be read only. Changing the contents might
- break something, e.g. a signature. If the contents are changed,
- without knowledge of why the frame was flagged read only and
- without taking the proper means to compensate, e.g. recalculating
- the signature, the bit MUST be cleared.
-
-
-4.1.2. Frame format flags
-
- h - 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. Every frame with the same group identifier belongs to the
- same group.
-
- 0 Frame does not contain group information
- 1 Frame contains group information
-
-
- k - Compression
-
- This flag indicates whether or not the frame is compressed.
- A 'Data Length Indicator' byte MUST be included in the frame.
-
- 0 Frame is not compressed.
- 1 Frame is compressed using zlib [zlib] deflate method.
- If set, this requires the 'Data Length Indicator' bit
- to be set as well.
-
-
- m - Encryption
-
- This flag indicates whether or not the frame is encrypted. If set,
- one byte indicating with which method it was encrypted will be
- added to the frame. See description of the ENCR frame for more
- information about encryption method registration. Encryption
- should be done after compression. Whether or not setting this flag
- requires the presence of a 'Data Length Indicator' depends on the
- specific algorithm used.
-
- 0 Frame is not encrypted.
- 1 Frame is encrypted.
-
- n - Unsynchronisation
-
- This flag indicates whether or not unsynchronisation was applied
- to this frame. See section 6 for details on unsynchronisation.
- If this flag is set all data from the end of this header to the
- end of this frame has been unsynchronised. Although desirable, the
- presence of a 'Data Length Indicator' is not made mandatory by
- unsynchronisation.
-
- 0 Frame has not been unsynchronised.
- 1 Frame has been unsyrchronised.
-
- p - Data length indicator
-
- This flag indicates that a data length indicator has been added to
- the frame. The data length indicator is the value one would write
- as the 'Frame length' if all of the frame format flags were
- zeroed, represented as a 32 bit synchsafe integer.
-
- 0 There is no Data Length Indicator.
- 1 A data length Indicator has been added to the frame.
-
-
-5. Tag location
-
- The default location of an ID3v2 tag is prepended to the audio so
- that players can benefit from the information when the data is
- streamed. It is however possible to append the tag, or make a
- prepend/append combination. When deciding upon where an unembedded
- tag should be located, the following order of preference SHOULD be
- considered.
-
- 1. Prepend the tag.
-
- 2. Prepend a tag with all vital information and add a second tag at
- the end of the file, before tags from other tagging systems. The
- first tag is required to have a SEEK frame.
-
- 3. Add a tag at the end of the file, before tags from other tagging
- systems.
-
- In case 2 and 3 the tag can simply be appended if no other known tags
- are present. The suggested method to find ID3v2 tags are:
-
- 1. Look for a prepended tag using the pattern found in section 3.1.
-
- 2. If a SEEK frame was found, use its values to guide further
- searching.
-
- 3. Look for a tag footer, scanning from the back of the file.
-
- For every new tag that is found, the old tag should be discarded
- unless the update flag in the extended header (section 3.2) is set.
-
-
-6. Unsynchronisation
-
- The only purpose of unsynchronisation is to make the ID3v2 tag as
- compatible as possible with existing software and hardware. There is
- no use in 'unsynchronising' tags if the file is only to be processed
- only by ID3v2 aware software and hardware. Unsynchronisation is only
- useful with tags in MPEG 1/2 layer I, II and III, MPEG 2.5 and AAC
- files.
-
-
-6.1. The unsynchronisation scheme
-
- Whenever a false synchronisation is found within the tag, one zeroed
- byte is inserted after the first false synchronisation byte. The
- format of synchronisations 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 will not 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 unsynchronisation
- flag in the frame header should be set. This bit MUST be set if the
- frame was altered by the unsynchronisation and SHOULD NOT be set if
- unaltered. If all frames in the tag are unsynchronised the
- unsynchronisation flag in the tag header SHOULD be set. It MUST NOT
- be set if the tag has a frame which is not unsynchronised.
-
- Assume the first byte of the audio to be $FF. The special case when
- the last byte of the last frame is $FF and no padding nor footer is
- used will then introduce a false synchronisation. This can be solved
- by adding a footer, adding padding or unsynchronising the frame and
- add $00 to the end of the frame data, thus adding more byte to the
- frame size than a normal unsynchronisation would. Although not
- preferred, it is allowed to apply the last method on all frames
- ending with $FF.
-
- It is preferred that the tag is either completely unsynchronised or
- not unsynchronised at all. A completely unsynchronised tag has no
- false synchonisations in it, as defined above, and does not end with
- $FF. A completely non-unsynchronised tag contains no unsynchronised
- frames, and thus the unsynchronisation flag in the header is cleared.
-
- Do bear in mind, that if compression or encryption is used, the
- unsynchronisation scheme MUST be applied afterwards. When decoding an
- unsynchronised frame, the unsynchronisation scheme MUST be reversed
- first, encryption and decompression afterwards.
-
-
-6.2. Synchsafe integers
-
- In some parts of the tag it is inconvenient to use the
- unsychronisation scheme because the size of unsynchronised data is
- not known in advance, which is particularly problematic with size
- descriptors. The solution in ID3v2 is to use synchsafe integers, in
- which there can never be any false synchs. Synchsafe integers are
- integers that keep its highest bit (bit 7) zeroed, making seven bits
- out of eight available. Thus a 32 bit synchsafe integer can store 28
- bits of information.
-
- Example:
-
- 255 (%11111111) encoded as a 16 bit synchsafe integer is 383
- (%00000001 01111111).
-
-
-7. Copyright
-
- Copyright (C) Martin Nilsson 2000. All Rights Reserved.
-
- 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.
-
- 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.
-
-
-8. References
-
- [ID3v2] Martin Nilsson, 'ID3v2 informal standard'.
-
- <url:http://www.id3.org/id3v2.3.0.txt>
-
- [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-3309] ISO 3309
- 'Information Processing Systems--Data Communication High-Level Data
- Link Control Procedure--Frame Structure', IS 3309, October 1984, 3rd
- Edition.
-
- [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
-
- [JFIF] 'JPEG File Interchange Format, version 1.02'
-
- <url:http://www.w3.org/Graphics/JPEG/jfif.txt>
-
- [KEYWORDS] S. Bradner, 'Key words for use in RFCs to Indicate
- Requirement Levels', RFC 2119, March 1997.
-
- <url:ftp://ftp.isi.edu/in-notes/rfc2119.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] The Unicode Consortium,
- 'The Unicode Standard Version 3.0', ISBN 0-201-61633-5.
-
- <url:http://www.unicode.org/unicode/standard/versions/Unicode3.0.htm>
-
- [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>
-
- [UTF-8] F. Yergeau, 'UTF-8, a transformation format of ISO 10646',
- RFC 2279, January 1998.
-
- <url:ftp://ftp.isi.edu/in-notes/rfc2279.txt>
-
- [UTF-16] F. Yergeau, 'UTF-16, an encoding of ISO 10646', RFC 2781,
- February 2000.
-
- <url:ftp://ftp.isi.edu/in-notes/rfc2781.txt>
-
- [ZLIB] P. Deutsch, Aladdin Enterprises & J-L. Gailly, 'ZLIB
- Compressed Data Format Specification version 3.3', RFC 1950,
- May 1996.
-
- <url:ftp://ftp.isi.edu/in-notes/rfc1950.txt>
-
-
-9. Author's Address
-
- Written by
-
- Martin Nilsson
- Rydsvägen 246 C. 30
- SE-584 34 Linköping
- Sweden
-
- Email: nilsson@id3.org
-
projects / platform / upstream / gstreamer.git / commitdiff