原仕様書
https://id3.org/id3v2.3.0
元の日本語訳
http://web.archive.org/web/20080117222657/http://www1.cds.ne.jp/~takaaki/ID3/ID3v2.3.0J.html
非公式標準
文書:id3v2.3.0J.html
M. Nilsson
1999年2月3日

日本語翻訳水野 貴明
最終更新2000年6月24日

ID3 タグバージョン2.3.0

この文書の位置づけ

この文書は非公式標準であり、ID3v2.2.0標準文書を置き換えるものである。非公式標準とは公式標準が策定される前に策定者が標準仕様を決めるためのものである。公式標準という言葉は、今後この文書に書かれている仕様が更新された際に、別のバージョン、もしくは改訂番号を持った文書に対して使われるだろう。この文書の内容は将来的に、わかりやすくする目的で修正されることがあっても、機能的な追加変更が行われることはない[訳注:ID3v2.3.0としては、という意味]

この文書の配布に関して制限はもうけられていない。

要約

この文書はID3v2.3.0について述べられたものである。これはID3タグ付けシステムを進化させたものであったID3v2非公式標準(バージョン2.2.0)をさらに発展させたものである。ID3v2はそのファイルに入っているオーディオの音源と中身についての情報を保存しておく柔軟な方法を提供する。情報とは、タイトル、演奏者、著作権情報といったメタ情報だけでなく、イコライゼーションカーヴなどの技術的情報をも意味する。

1. 目次

2. 文書中の表記規則

ダブルクォーテーション("")で囲まれた文字列は、ファイル中にそのまま埋め込まれていることを意味する。先頭に$をつけてある数字は16進数、%がつけてある数字は2進数であることを意味する。$xxは、未知の1バイトのデータを意味する。%xは未知の1ビットのデータを意味する。最重要ビット(MSB : most significant bit)とはバイトデータの第7ビットを、最も重要でないビット(LSB : least significant bit)は第0ビットを意味する。

「タグ」という言葉は、この文書で扱われているタグ全体を示す。「フレーム」という言葉はタグの中のデータのブロックを示す。タグは、ヘッダ、フレーム、そして残りの領域(Padding領域:無くても良い)で構成されている。フィールドとはある値、もしくは文字列などの一つ一つの情報をさす。数字文字列(Numeric String)は0-9の文字だけで構成された文字列のことである。

3. ID3v2の概要

ID3v2を設計する上での2つの大きな目標は、ID3v2を認識できない古いソフトウエアの挙動になるべく影響を与えないことと、柔軟かつ拡張性に富んだ設計にすることであった。

1番目の目標(ID3v2を認識できない古いソフトウエアの挙動になるべく影響を与えないこと)はMPEG をデコードするソフトウエアが、オーディオデータの位置を「ロックオン」するために、オーディオファイルの中に含まれる同期信号を使用しているという単純な事実を利用している。タグ中に同期信号と同じ構造を作らないようにすることで、ID3v2を認識できないプレーヤーでもタグの中を演奏することはなくなる。何らかの理由で、タグ中に偶然にも同期信号の構造が作られてしまった場合は、セクション5で説明されている「非同期化スキーマ」によって処理される。

2番目の目標(柔軟かつ拡張性に富んだ設計にすること)は、ID3v2の設計に対してより大きな影響を与えている。ID3v2はフレームと呼ばれる情報を格納したコンテナの集合体として作られており、各フレームの内部構造については、タグを読み込むアプリケーションは必ずしも知る必要がない。各フレームの先頭にはそのフレームのフォーマットと中身を特定するための識別子とフレームサイズが格納されており、ソフトウエアは未知のフレームがあった場合にはそのフレームを無視することができるようになっている。

ID3v2の完全なバージョン(改訂番号を含む)が必要になる場合を考え、ID3v2ヘッダにはバージョンとタグ全体のサイズ情報が格納されている。

この文書に書かれているID3タグは、MPEG-1/2 layer I、MPEG-1/2 layer II、MPEG-1/2 layer III、MPEG-2.5でエンコードされたファイルを主な対象としているが、おそらくそれ以外の方法でエンコードされたオーディオファイルにおいても使用は可能である。

ID3v2でのビットの並び順は最重要ビット(MSB)が最初におかれるように配置される。複数バイトで構成されているデータは、最重要バイトが最初におかれるように配置される(例:$12345678 というデータは、$12 34 56 78という順番で格納される)。

フレームの先頭に格納されているタグサイズよりも、フレームデータの総合計サイズを小さくすることによって、フレームをすべて格納し終わった後(つまりID3タグの一番後ろ)に、Padding領域(残りの領域)を配置することができる。この領域は、後からフレームを追加したり、既存のフレームであっても今より大きなデータを格納したいと思った場合に、ファイル全体を書き直すことなくデータを更新するために用いることができる。この領域はすべて$00という値で埋められている。

3.1. ID3v2ヘッダ

ファイルの先頭に位置するID3v2タグヘッダは、以下のような10バイトの構造をしている。

ID3v2 ファイル識別子  "ID3"
ID3v2 バージョン      $03 00
ID3v2 フラグ          %abc00000
ID3v2 サイズ          4 * %0xxxxxxx

タグの先頭の3バイトは常に「ID3」という文字列が入っていて、このことがID3v2タグの存在の指標となっている。そのすぐ後には2バイトのバージョン情報が入っている。ID3v2バージョンのうちはじめの1バイトは、メジャーバージョンを示し、2バイト目は改訂番号を示す。上記の場合はタグのバージョンがID3v2.3.0であることを示している。メジャーバージョンに変化がなければ、改訂番号が変わっても古いバージョンとの互換性は保たれる。もしソフトウエアがID3v2.2.0かそれ以下のバージョンのタグしかサポートしていなくて、ID3v2.3.0かそれ以上のバージョンのタグに出会った場合、すべてのタグを無視するべきである。メジャーバージョンと改訂番号は$FFになることはない。

バージョン情報の次には、1バイトのID3v2フラグが入っている。その中に、現在は3つのフラグ情報が格納されている。

a - 非同期化
「ID3v2フラグ」の第7ビットは、非同期化が行われているかを示している(詳細はセクション5を参照のこと)。このビットが1である場合は、非同期化が行われている。
b - 拡張ヘッダ
左から2番目のビット(第6ビット)はヘッダの後に拡張ヘッダがつけられているかを示す。拡張ヘッダについてはセクション3.2で解説されている。
c - 実験中
左から3番目のビット(第5ビット)は「実験中」を示す識別子として使用される。このフラグが立っている場合、そのタグが現在実験段階にあることを示している。

これ以外のフラグビットはすべて0にしておくべきである。もし認識できないフラグがセットされていた場合は、そのフラグの機能が不明であるため、タグ全体が読み込み不可能である可能性のあることを意味する。

ID3v2タグサイズは、最重要(第7ビット)がすべて0になるようにエンコードされた4バイトのデータであり、全部で28ビットのデータである。0にセットしたビットは無視する。したがってタグのサイズが257バイトであった場合は、$00 00 02 01と表現される。

ID3v2タグサイズには、非同期化処理を終えた後のタグ全体のサイズを格納する。Padding領域と拡張ヘッダ領域は含めるが、ヘッダ領域は含めない(総タグサイズ-10ということになる)。サイズ情報として使えるのは28ビットであるので、「偽の同期信号」を含まないようにした最大256メガバイトまでのヘッダを使うことができる。

ID3v2タグヘッダは以下のような形になる。

$49 44 33 yy yy xx zz zz zz zz

yyは$FF以外の数、xxはフラグ、zzは$80未満の数を表す。

3.2.ID3v2 拡張ヘッダ

拡張ヘッダはタグを正しく解析する際において、絶対必要、というわけではない情報を格納している。したがって、拡張ヘッダは省略可能である。

拡張ヘッダサイズ     $xx xx xx xx
拡張フラグ           $xx xx
Padding領域のサイズ  $xx xx xx xx

「拡張ヘッダサイズ」には、それ自身の領域は含まれないので、現在は6バイト、もしくは10バイトを指定する。「Padding領域のサイズ」には、タグサイズからヘッダ領域サイズと全フレームのサイズの総計を引いたサイズ、すなわちPadding領域のサイズを格納する。拡張ヘッダはID3v2 ヘッダとは切り離されたものと考えられているので、非同期化を行う対象に含まれている。

拡張フラグはタグのさらなる属性を表現するための、二次的なフラグである。以下のような属性が現在定義されている。

%x0000000 00000000
x - CRC のデータが存在する
このフラグがセットされている場合は、拡張ヘッダの最後に4バイトのCRC-32データが追加されていることを示す。CRCは非同期化処理を行う前に、拡張ヘッダとPadding領域の間の領域、つまりフレームデータのみから算出される。
総フレームの CRC データ $xx xx xx xx

3.3. ID3v2 フレームの概要

タグはヘッダと本体から構成され、本体は一つ以上のフレームで構成されている。そしてすべてのフレームはフレームヘッダと、実際のデータを格納したフィールドで構成されている。以下にフレームヘッダの構造を示す。

Frame ID $xx xx xx xx (four characters)
Size      $xx xx xx xx
Flags     $xx xx

フレーム IDは0-9と大文字のA-Zで構成されている。「X」、「Y」、「Z」で始まるIDは、タグヘッダに「実験中」のフラグを立てなくても、実験的に用いたり、自由に定義して用いることができる。ただし、他の誰かが同じIDを別の意味に使う可能性もあることを忘れないようにしなくてはならない。それ以外のIDは、現在使われていないものでも将来の拡張のために予約されている。

すべてのフレームにおいて、フレームヘッダのサイズは10バイトに固定されており、フレームIDの次のはサイズ情報が格納されている。サイズ情報はフレームの総サイズからヘッダサイズを除いたものである(フレームサイズ-10)。

フレームサイズに続いて、フレームヘッダの最後に格納されているのはフレームフラグである。このフラグについてはセクション3.3.1で解説されている。

タグ中のフレームの出現順序には特に決まりは存在していないが、ファイル認識にとって重要なタグから順番に並べた方が好ましい。たとえば、以下のような順序である。

UFID, TIT2, MCDI, TRCK ... タグ中には少なくとも一つ以上のフレームが無くてはならず、フレームには、ヘッダ以外に少なくとも1バイトのデータが無くてはならない。

特に指定がされていない場合、文字列の文字コードは$20 - $FFの間のISO-8859-1である。このような文字列は<文字列>、改行コードを入れても良い場合は<全文字列>という名前で指定される。Unicode文字列は16ビットのunicode 2.0(ISO/IEC 10646-1:1993, UCS-2)を用いる。unicode文字列は、そのバイトオーダーを指定するために、必ずunicode BOM ($FF FE もしくは$FE FF) から始まらなくてはならない。

数字文字列とURLはすべて、必ずISO-8859-1でエンコードされる。ISO-8859-1でエンコードされている場合は$00、unicodeでエンコードされている場合は$00 00があると、文字列はそこで終わるものと見なされる。特に指定されていない場合、改行は使うことができない。もし改行が許されている場合は、ISO-8859-1では$0Aのみを使用することができる。複数の文字コードを使うことのできるフレームでは、フレームサイズの後に、文字コードの種類を指定するための1バイトのデータをつける。そこで指定されるのはISO-8859-1なら$00、unicodeなら$01である。文字コードが指定可能な文字列は<エンコード指定文字列>と呼ばれる。改行コードを入れても良い場合は<エンコード指定全文字列>という名前で指定される。unicode文字列において、空の文字列を指定する場合は、unicode BOMの後にすぐヌル文字を入れる ($FF FE 00 00 もしくは$FE FF 00 00)。

3バイトの言語フィールドは、フレームの内容がどういった言語で記述されているかを表す。そのフォーマットはISO-639-2に準じている。

すべてのURLは、例えば、"picture.png"、"../doc.txt"といったように、相対パスも指定することができる。

もしフレームがしかるべき長さよりも長かった場合、たとえば、この文書で記述されているよりも多くのフィールドが含まれていた場合、ID3v2の最新のバージョンでフレームの仕様が追加されたことを意味する。この改訂はタグヘッダの改訂番号に反映される。

3.3.1.フレームヘッダフラグ

フレームヘッダのサイズが格納されている次には、2バイトのフラグが格納されている。未使用のフラグビットはすべて0になっていなければならない。1バイト目はそのフレームの状態を表すためのフラグであり、2バイト目はエンコードに関するフラグである。1バイト目に認識できないフラグがセットされていた場合で、フレームに変更を加えた場合はそのフラグビットを0にしなくてはならない。もし2バイト目に認識できないフラグがセットされていた場合は、おそらくそのフレームは解析することができないであろう。フラグは以下のように定義されている。

%abc00000 %ijk00000
a - タグの変更で取り除かれる
このフラグは、そのフレームをアプリケーションが認識できない場合は、タグに変更が加えられたときに、そのフレームを削除しなくてはならないことを示す。このことはPadding領域の追加やフレームの順序の変更など、すべての種類の変更の際に適用される。
0 フレームは保持される
1 フレームは除去される
b - ファイルの変更で取り除かれる
このフラグは、そのフレームをアプリケーションが認識できない場合は、ファイル(タグ領域以外)に変更が加えられたときに、そのフレームを削除しなくてはならないことを示す。このことはオーディオファイルが他のオーディオファイルと完全に置き換えられた場合には適用されない。
0 フレームは保持される
1 フレームは除去される
c - 読み込み専用
このフラグがセットされていた場合は、このフレームが読み込み専用であることを示す。このフレームの中身を修正することは、何らかの情報(署名など)を破壊してしまう可能性がある。なぜそのフレームが読み込み専用になっているかを考慮せず、適当な代替処理をせずにそのフレームを修正してしまった場合(署名を再計算するなど)は、このビットは0にしなくてはならない。
i - 圧縮
このフラグはフレームが圧縮されているかを示す。
0 フレームは圧縮されていない。
1 フレームはzlib圧縮されており、フレームヘッダの後に4バイトの「伸張後のサイズ」が格納されている。
j - 暗号化
このフラグはフレームが暗号化されているかどうかを示す。もし、暗号化されている場合は、暗号化の手法を示す1バイトのデータが、フレームヘッダの後に格納されている。暗号化の手法の登録に関する詳細な説明はセクション4.26を参照せよ。
0 フレームは暗号化されていない。
1 フレームは暗号化されている。
k - グループ識別子
このフラグは、そのフレームが他のフレームとグループを形成しているかどうかを示す。もしこのフラグがセットされている場合はグループを識別するための1バイトのデータがフレームヘッダの後に格納されている。そこに同じデータが格納されているフレームはすべて同じグループに属するのだ。
0 フレームにはグループ情報がない。
1 フレームにはグループ情報が含まれている。

これらのフラグのうちのいくつかは、セットされることによってフラグが拡張され追加情報が付加される。これらの追加情報はフラグの順番と同じ順序でヘッダに追加される。たとえば4バイトの伸張後のサイズは暗号化の手法を示す1バイトのデータよりも前に置かれる。これらの追加情報のデータ長はフレームヘッダサイズには含められないが、フレームサイズ(このフィールドは圧縮や暗号化が行われることはない)には含められる。

3.3.2.フラグの初期値

各フラグの初期値は以下のように分類される。ソフトウエアがこれよりも適した設定があると考えた場合は、この設定とは異なっている場合もあり得る。

1.  タグに変更があった場合は削除される。ファイルに変更があった場合も削除される。
      なし。
2.  タグに変更があった場合は削除される。ファイルに変更があった場合は保存される。
      なし。
3.  タグに変更があった場合は保存される。ファイルに変更があった場合は削除される。
      ETCO, EQUA, MLLT, POSS, SYLT, SYTC, RVAD, TENC, TLEN, TSIZ
4. タグに変更があった場合は保存される。ファイルに変更があった場合は保存される。
      残りのフレーム。

4. ID3v2 フレームの定義

この文書の中では以下のフレームが解説されている。

4.20  ANEC オーディオの暗号化
4.15  APIC 付属する画像
4.11  COMM コメント
4.25  COMR コマーシャルフレーム
4.26  ENCR 暗号化の手法の登録
4.13  EQUA 均一化
4.6   ETCO イベントタイムコード
4.16  GEOB パッケージ化された一般的なオブジェクト
4.27  GRID グループ識別子の登録
4.4   IPLS 協力者
4.21  LINK リンク情報
4.5   MCDI 音楽CD識別子
4.7   MLLT MPEGロケーションルックアップテーブル
4.24  OWNE 所有権フレーム
4.28  PRIV プライベートフレームプライベートフレーム
4.17  PCNT 演奏回数
4.18  POPM 人気メーター
4.22  POSS 同期位置フレーム
4.19  RBUF おすすめバッファサイズ
4.12  RVAD 相対的ボリューム調整
4.14  RVRB リバーブ
4.10  SYLT 同期 歌詞/文書
4.8   SYTC 同期 テンポコード
4.2.1 TALB アルバム/映画/ショーのタイトル
4.2.1 TBPM BPM (beats per minute:一分間の拍数)
4.2.1 TCOM 作曲者
4.2.1 TCON 内容のタイプ
4.2.1 TCOP 著作権情報
4.2.1 TDAT 日付
4.2.1 TDLY プレイリスト遅延時間
4.2.1 TENC エンコードした人
4.2.1 TEXT 作詞家/文書作成者
4.2.1 TFLT ファイルタイプ
4.2.1 TIME 時間
4.2.1 TIT1 内容の属するグループの説明
4.2.1 TIT2 タイトル/曲名/内容の説明
4.2.1 TIT3 サブタイトル/説明の追加情報
4.2.1 TKEY 初めの調
4.2.1 TLAN 言語
4.2.1 TLEN 長さ
4.2.1 TMED メディアタイプ
4.2.1 TOAL オリジナルのアルバム/映画/ショーのタイトル
4.2.1 TOFN オリジナルファイル名
4.2.1 TOLY オリジナルの作詞家/文書作成者
4.2.1 TOPE オリジナルアーティスト/演奏者
4.2.1 TORY オリジナルのリリース年
4.2.1 TOWN ファイルの所有者/ライセンシー
4.2.1 TPE1 主な演奏者/ソリスト
4.2.1 TPE2 バンド/オーケストラ/伴奏
4.2.1 TPE3 指揮者/演奏者詳細情報
4.2.1 TPE4 翻訳者, リミックス, その他の修正
4.2.1 TPOS セット中の位置
4.2.1 TPUB 出版社
4.2.1 TRCK トラックの番号/セット中の位置
4.2.1 TRDA 録音日付
4.2.1 TRSN インターネットラジオ局の名前
4.2.1 TRSO インターネットラジオ局の所有者
4.2.1 TSIZ サイズ
4.2.1 TSRC ISRC (international standard recording code:国際標準レコーディングコード)
4.2.1 TSSE エンコードに使用したソフトウエア/ハードウエアとセッティング
4.2.1 TYER 年
4.2.2 TXXX ユーザー定義文字情報フレーム
4.1   UFID 一意的なファイル識別子
4.23  USER 使用条件
4.9   USLT 非同期 歌詞/文書のコピー
4.3.1 WCOM 商業上の情報
4.3.1 WCOP 著作権/法的情報
4.3.1 WOAF オーディオファイルの公式Webページ
4.3.1 WOARアーティスト/演奏者の公式Webページ
4.3.1 WOAS 音源の公式Webページ
4.3.1 WORS インターネットラジオ局の公式ホームページ
4.3.1 WPAY 支払い
4.3.1 WPUB 出版社の公式Webページ
4.3.2 WXXX ユーザー定義URLリンクフレーム

4.1.一意的なファイル識別子

このフレームは、その内容に関連したさらなる情報を含むデータベースの中で、そのファイルを一意的に識別するためのものである。そのようなデータベースの標準化についてはこの文書の範囲を超えるので、このフレームはe-mailアドレスそのものか、e-mailアドレスを調べるための場所を示したURLで始まる。このe-mailアドレスはこのデータベースの実装に責任を持つ組織のものである。データベースに関する質問はこのe-mailアドレスに送るべきである。このURLは実際のデータベースに関する質問に使用するべきではない。「http://www.id3.org/dummy/ufid.html」という文字列をテスト用に使うことが出来る。このフレームは、そのようなことを行わないソフトウエアが削除してしまっても安全である。「所有者識別子」は空欄にすることはできない(終了を表すヌル文字以外に一字以上必要)。「所有者識別子」の後には実際の識別子が続く。識別子は最大64文字になっている。一つのタグ中に複数の「UFID」フレームを持たせることは可能だが、すべてのフレームは同じ「所有者識別子」を持っていなければならない。

<「一意的なファイル識別子」のヘッダ、 ID: "UFID">
所有者識別子 <文字列> $00
識別子 <最大64バイトのバイナリデータ>

4.2.テキスト情報フレーム

テキスト情報フレームとは、アーティスト名やアルバム名といった情報を格納している、もっとも重要なフレーム群である。一つのタグ中には、同じ種類のテキスト情報フレームを複数含めることはできない。もし文字列情報中に終端文字($00 (00))が含まれていた場合は、それ以後の情報はすべて破棄され、表示されることはない。テキスト情報フレームのフレームIDはすべて「T」で始まっている。「TXXX」をのぞけば、テキスト情報フレーム以外のフレームが「T」で始まることはない。テキスト情報フレームはすべて以下のフォーマットになっている。

<「テキスト情報フレーム」のヘッダ、ID: "T000" - "TZZZ", ただしセクション4.2.2で解説されている"TXXX"を除く>
文字コード $xx
情報       <エンコード指定文字列>

4.2.1.テキスト情報フレーム - 詳細

TALB
「アルバム/映画/ショーのタイトル」フレームは、そのオーディオファイルの音源となった録音のタイトルを意味する。
TBPM
「BPM」フレームには曲の主要部分での一分間の拍数が格納される。BPMは整数値で、数字文字列として格納される。
TCOM
「作曲者」フレームは作曲者の名前を意味する。複数の作曲者がいる場合には「/(スラッシュ)」で区切る。
TCON

「内容のタイプ」、これはID3v1ではジャンル(Genre)と呼ばれていたもので、1バイトの数値で格納されていたが、ID3v2では数字文字列で格納するようになった。このフレームにはID3v1.1で定義されたジャンルを一つ、または複数格納することができるし、カテゴリリストを正確に更新していくことが不可能であるため、独自のジャンルを定義することも可能である。

ID3v1のジャンルコードへの参照を行う場合は、1バイト目に「(」を置き、続いてジャンルコード(付録A参照)を置き、最後に「)」を置く。参照の後にさらに追加情報をつけることもできる。たとえば、「(21)」や「(4)ユーロディスコ」といったようにである。「(51)(39)」といったように、複数の参照値を同じフレームに含めることもできる。もし、追加情報が「(」で始まってしまう場合は、「((」で置き換えることができる。「((どのジャンルにも分類できない)」や「(55)((だと思います...)」という感じである。以下に示す「(RX)」などのタイプはID3v2で新たに定義されたもので、数値で表される既存のジャンルと同じように扱うことができる。

RX リミックス
CR カバー
TCOP
「著作権情報」フレームは年と1文字の空白文字で始まる(これで5文字になる)。これはオリジナルの音源の著作権保有者(オーディオファイルの、ではない)を示す。このフレームが存在していないということは、著作権情報が公開されていないか、削除されたことを意味する。その音源がパブリックドメインであることを示すわけではない。このフィールドが表示される場合には、必ずその前に「Copyright © 」という文字列をつけなくてはいけない。
TDAT
「日付」フレームはDDMM(日2桁+月2桁)の数字文字列で格納され、録音の日付を意味する。このフィールドは常に長さが4文字である。
TDLY
「プレイリスト遅延時間」フレームはプレイリスト中のすべての曲の間にある無音時間をミリ秒単位で定義している。プレーヤーは「ETCO」フレームがもしあれば、それを用いて曲の始めと終わりの無音部分を「プレイリスト遅延時間」に合うようにスキップするべきである。この時間は数字文字列で表現される。
TENC
「エンコードした人」フレームには、そのオーディオファイルをエンコードした個人もしくは組織の名前を入れる。オーディオファイルの著作権がエンコードした人にある場合、このフレームには著作権情報が含まれるかもしれない。
TEXT
「作詞家/文書作成者」フレームは録音中の歌詞や文書の作成者の名前を格納するためのものである。複数いる場合は「/(スラッシュ)」で区切る。
TFLT
「ファイルタイプ」フレームはこのタグの付けられたオーディオの形式を示している。以下の形式と詳細事項が定義されている。
MPG   MPEG オーディオ
   /1  MPEG 1/2 レイヤーI
   /2  MPEG 1/2 レイヤーII
   /3  MPEG 1/2 レイヤーIII
 /2.5  MPEG 2.5
 /AAC  Advanced audio compression
VQF    Transform-domain Weighted Interleave Vector Quantization
PCM    Pulse Code Modulated audio
しかし、上記以外の形式が使われている可能性もあるだろう。その場合は既に定義されているのと同様に「TMED」中で指定することが出来る。しかし、その中で括弧を使うことは出来ない。もしタグ中にこのフレームがなかった場合は、そのファイルのオーディオタイプは「MPG」であるとみなされる。
TIME
「時間」フレームはHHMM(時間2桁分2桁)の数字文字列形式で、レコーディン グに要した時間を表す。このフレームは常に4文字長である。
TIT1
「内容の属するグループの説明」フレームはそのサウンドが大きな音楽・サウンドのカテゴリに属している場合に使用する。例えば、クラシック音楽はしばしば異なる音楽のセクションに分類される(例えば、「ピアノコンチェルト」「天候-ハリケーン」)。
TIT2
「タイトル/曲名/内容の説明」フレームはそのファイルの中身の実際の名前である(たとえば「アダージョ」「ハリケーン・ドナ」)。
TIT3
「サブタイトル/説明の追加情報」フレームはタイトルに直接付随する情報(「Op. 16」や「Wembleyでのライブパフォーマンス」など)を格納するものである。 TKEY 「初めの調」を表すこのフレームは、音楽が始まったときの、最初のキー(調)を格納しておく。このフレームは最大3文字の文字列として表現される。基本となる調は「A」「B」「C」「D」「E」「F」「G」で表現され、半音は「b」と「#」で表現する。マイナーの場合は「m」を付ける。たとえば「Cbm」といった具合である。その曲が無調だったばあいは、ただ「o」と入れればよい。
TLAN
「言語」フレームにはオーディオ中で話されている文章、もしくは歌われている歌詞の言語を格納している。言語の種類はISO-639-2で定義された3文字の文字列であらわされる。文章中で2つ以上の言語が使われている場合は、言語コードは言語の出現順に並べて記述される。
TLEN
「長さ」フレームには、オーディオファイルの長さがミリ秒単位で格納されている。数字文字列が使われる。
TMED
「メディアタイプ」は、オーディオファイルの音源がどんなメディアであったかを意味する。このフレームは文字列か、以下のリストで示される定義済みのメディアタイプへの参照が入っている。定義済みのメディアタイプへの参照の場合は、「(」と「)」で囲まれており、そのあとに文字列の追加情報がつくこともある。たとえば「(MC) 4チャンネル」といった具合である。もし追加情報を「(」で始めたい場合は、代わりに「TCON」フレームと同様に「((」を使う。定義済みの追加情報はメディアタイプのすぐあとに付ける。たとえば「(CD/A)」や「(VID/PAL/VHS)」といった具合である。
DIG その他のデジタルメディア
 /A アナログに変換されている

ANA    その他のアナログメディア
 /WAC  ワックスシリンダ
 /8CA  ワックスシリンダ

CD    CD
 /A   アナログに変換されている
 /DD  DDD
 /AD  ADD
 /AA  AAD

LD   レーザーディスク
 /A  アナログに変換されている

TT    ターンテーブルレコード
 /33  33.33 rpm
 /45  45 rpm
 /71  71.29 rpm
 /76  76.59 rpm
 /78  78.26 rpm
 /80  80 rpm

MD   ミニディスク
 /A  アナログに変換されている

DAT  DAT
 /A  アナログに変換されている
 /1  スタンダード, 48 kHz/16 ビット, リニア
 /2  モード 2, 32 kHz/16 ビット, リニア
 /3  モード 3, 32 kHz/12 ビット, ノンリニア, 低スピード
 /4  モード 4, 32 kHz/12 ビット, 4チャンネル
 /5  モード 5, 44.1 kHz/16 ビット, リニア
 /6  モード 6, 44.1 kHz/16 ビット, 'ワイドトラック' 再生

DCC  DCC
 /A アナログに変換されている

DVD  DVD
 /A アナログに変換されている

TV       テレビ
 /PAL    PAL
 /NTSC   NTSC
 /SECAM  SECAM

VID      ビデオ
 /PA     LPAL
 /NTS    CNTSC
 /SECAM  SECAM
 /VHS    VHS
 /SVHS   S-VHS
 /BETA   ベータマックス

RAD   ラジオ
 /FM  FM
 /AM  AM
 /LW  LW
 /MW  MW

TEL  電話
 /I  ISDN

MC     MC (普通のカセットテープ)
 /4    4.75 cm/s (両面カセットテープの通常のスピード))
 /9    9.5 cm/s /IType I カセット(ferric/ノーマル)
 /II   Type II カセット(クロム)
 /III  Type III カセット(ferric chrome)
 /IV   Type IV カセット(メタル) ]

REE    リール
 /9    9.5 cm/s
 /19   19 cm/s
 /38   38 cm/s
 /76   76 cm/s
 /I    Type I カセット(ferric/ノーマル)
 /II   Type II カセット(クロム)
 /III  Type III カセット(ferric chrome)
 /IV   Type IV カセット(メタル)
TOAL
「オリジナルのアルバム/映画/ショーのタイトル」フレームはオリジナルの録音(もしくは音源)のタイトルを格納することを目的とする。このフレームは、例えばファイルに入っている音楽が既にリリースされた曲のカバーだった場合などに利用する。
TOFN
「オリジナルファイル名」フレームはそのファイルに、(現在付けられているファイル名よりも)もっと適した名前が有る場合に格納しておく。メディアによってはファイル名に使える長さが制限されており、必要な長さの名前を付けられないことがあるからだ。格納するファイル名では大文字と小文字は区別され、接尾子(拡張子)も含まれる。
TOLY
「オリジナルの作詞家/文書作成者」フレームはオリジナル録音の文書作成者を格納することを目的としている。このフレームは、例えばファイルに入っている音楽が既にリリースされた曲のカバーだった場合などに利用する。文書作成者が複数いる場合は、「/」で区切る。 TOPE 「オリジナルアーティスト/演奏者」フレームはオリジナル録音の演奏者を格納することを目的としている。このフレームは、例えばファイルに入っている音楽が既にリリースされた曲のカバーだった場合などに利用する。演奏者が複数いる場合は、「/」で区切る。
TORY
「オリジナルのリリース年」フレームはオリジナル録音のリリース年を格納することを目的としている。このフレームは、例えばファイルに入っている音楽が既にリリースされた曲のカバーだった場合などに利用する。このフレームのフォーマットは「TYER」と同じである。
TOWN
「ファイルの所有者/ライセンシー」フレームにはファイルとその中身の所有者もしくはライセンシーの名前を格納する。
TPE1
「主なアーティスト/主な演奏者/ソリスト/演奏グループ」は主なアーティストを格納するのに用いる。複数いる場合は「/」で区切る。
TPE2
「バンド/オーケストラ/伴奏」フレームはレコーディングを行った演奏者の追加情報を格納する。
TPE3
「指揮者」フレームは指揮者の名前を格納しておく。
TPE4
「翻訳者, リミックス, その他の修正」フレームは、リミックスや既存の何かを翻訳した人々などの追加情報を記録する。
TPOS
「セット中の位置」フレームにはオーディオがセット中のどこに位置するものなのかを意味する数字文字列が格納される。このフレームは「TALB」フレームに格納されている音源が複数のメディアに分割されている場合に使用する。たとえば、2枚組CDなどがこれにあたる。値はセット中の位置とセットの総数を示す数字文字列を「/」で区切って格納する。たとえば「1/2」といった具合である。
TPUB
「出版社」フレームは出版社やレーベルの名前を格納するものである。
TRCK
「トラックの番号/セット中の位置」フレームは、そのオーディオファイルがオリジナルの録音中で何番目になっているかを示す数字文字列である。このフレームは「/」で区切られたあとにその録音の総トラック数を格納する。たとえば「4/9」といった具合である。
TRDA
「録音日付」フレームは「TYER」「TDAT」「TIME」フレームを補完する目的で使用される。たとえば、「6月 4日-7日、12日」は「TYER」フレームと同時に使うと良い。
TRSN
「インターネットラジオ局の名前」フレームはそのオーディオがストリーミングされたインターネットラジオ局の名前を格納する。
TRSO
「インターネットラジオ局の所有者」フレームはそのオーディオがストリーミングされたインターネットラジオ局の所有者名を格納する。
TSIZ
「サイズ」フレームはオーディオファイルの長さ(ID3v2タグをのぞいた長さ)をバイト数で、数字文字列で格納する。
TSRC
ISRC」フレームは国際標準レコーディングコード(ISRC)(12文字)を格納するためのものである。
TSSE
「エンコードに使用したソフトウエア/ハードウエアとセッティング」フレームはそのファイルのエンコード時に使用したエンコーダとその設定を格納する。プログラムが実行されたコンピュータの名前ではない。
TYER
「年」フレームはレコーディングされた年を数字文字列で格納する。このフレームは常に4文字である(10000年までの話である)。

4.2.2. ユーザー定義文字情報フレーム

このフレームはその他の「T」フレームと同様、オーディオファイルに関する文字列を格納するために用いられる。このフレームの中身は、ヌル文字で終わる文字列として格納される文字列の説明と、実際の文字列で構成されている。一つのタグに複数の「TXXX」フレームを持つことが可能だが、同じ文字列の説明を持つフレームを2つ以上作ることは出来ない。

<Header for 'User defined text information frame', ID: "TXXX">
文字コード  $xx
説明        <エンコード指定文字列> $00 (00)
値          <エンコード指定文字列>

4.3.URL リンクフレーム

このフレームでは、ツアー情報、価格情報や通常のニュースなどの時によって変化する情報を掲載したWeb Pageに関する情報をタグに追加したい場合に使用する。 URL リンクフレームは特にフレーム毎の説明に記述がない場合は、一つのタグ中に、一種類につき、一つずつしか入れることが出来ない。もし文字列情報中に終端文字($00 (00))が含まれていた場合は、それ以後の情報はすべて破棄され、表示されることはない。URL リンクフレームのフレームIDはすべて「W」で始まっている。URL リンクフレーム以外のフレームが「W」で始まることはない。URL リンクフレームはすべて以下のフォーマットになっている。

<Header for 'URL link frame', ID: "W000" - "WZZZ", excluding "WXXX" described in 4.3.2.>
URL  <文字列>

4.3.1. URL リンクフレーム- 詳細

WCOM
「商業上の情報」フレームはそのアルバムがどこで買えるか、といった情報を知ることの出来るWebページのURLを格納している。一つのタグの中には、異なったURLを格納した2個以上の「WCOM」フレームが存在することもあり得る。
WCOP
「著作権/法的情報」フレームは、そのファイルの使用条件や所有権に関する情報が掲載されているWebページのURLを格納している。
WOAF
「オーディオファイルの公式Webページ」フレームは、その名の意味する通りのURLを格納するフレームである。
WOAR
「アーティスト/演奏者の公式Webページ」はアーティストの公式WebページのURLを格納する。もし一人以上の演奏者がいた場合には、一つのタグの中に複数の「WOAR」フレームが存在することもあり得る。ただし、同じURLを持つ「WOAR」フレームが2つ以上あってはならない。
WOAS
「音源の公式Webページ」は例えば映画のWebページなど、オーディオファイルの音源の公式WebページのURLを格納する。
WORS
「インターネットラジオ局の公式ホームページ」はインターネットラジオ局のホームページのURLを格納する。 WPAY 「支払い」フレームは、そのファイルの支払いを取り扱うWebページのURLを格納する。
WPUB
「出版社の公式Webページ」は出版社の公式WebページのURLを格納する。

4.3.2. ユーザー定義URLリンクフレーム

このフレームは他の「W」で始まるフレームと同じように、そのオーディオファイルに関するURLリンクを格納するためのものである。このフレームは文字列によるそのURLの説明があり、ヌル文字列が来たあとに、実際のURLが続く。URLの文字コードは常にISO-8859-1でなければならない。一つのタグ中に複数の「WXXX」タグがあってもかまわないが、同一の「説明」を持つフレームが複数あってはならない。

<「ユーザー定義URLリンクフレーム」のヘッダ、ID: "WXXX">
文字コード $xx
説明       <エンコード指定文字列> $00 (00)
URL        <文字列>

4.4. 協力者一覧

音楽家や技術者など、オーディオファイルには数多くの人が貢献している可能性があるので、「テキスト情報フレーム」だけではそのすべての人を格納するのに不十分である。「協力者一覧」フレームはそれらの人々の名前と、その人たちがどういう関わり方をしたかを格納するためのフレームである。このフレームは単純なフレームで、関わり方と関わった人々、という組み合わせを複数格納したフレームである。一つのタグに複数の「IPLS」タグがあってはならない。

<「協力者一覧」のヘッダ、ID: "IPLS">
文字コード $xx
協力者一覧 <エンコード指定文字列>

4.5.音楽CD識別子

このフレームはそのファイルの曲がCDを音源とする場合に、CDDBの様なデータベースで、どのCDかを識別するために使用する。このフレームはCDの内容一覧(TOC:Table Of Contents)のバイナリダンプで構成されている。これは、4バイトのヘッダで始まり、8バイトの「CD中のトラック」がトラック数だけ続き、そして8バイトの「リードアウト領域」で終わる構成になっていて、最大は804バイトである。それぞれのCDのトラックの始まりの位置は4バイトのCDフレームの絶対アドレスで指定される(時間ではない)。このフレームを含めるためには、たとえCD中に1トラックしかないとしても、有効な「TRCK」フレームがタグ中に必要である。一つのタグに「MCDI」フレームが複数存在してはいけない。

<「音楽CD識別子」のヘッダ、ID: "MCDI">
CD TOC  <バイナリデータ>

4.6. イベントタイムコード

このフレームは楽曲のキーイベントの同期を実現するためのものである。ヘッダは以下のようになっている。

<「イベントタイムコード」のヘッダ、ID: "ETCO">
タイムスタンプフォーマット $xx

タイムスタンプフォーマットは以下の通りである。

$01  絶対時間、32ビットサイズ、単位はMPEGフレーム
$02  絶対時間、32ビットサイズ、単位はミリ秒

絶対時間とは、すべてのタイムスタンプがファイルの開始からの時間であらわされることを意味する。

ヘッダの後には、キーイベントが以下のようなフォーマットで列挙される。

イベントのタイプ  $xx
タイムスタンプ    $xx (xx ...)

曲の始まりの位置を指定するときや、一つ前のイベントの直後にイベントがある場合は、「タイムスタンプ」のゼロをセットする。すべてのイベントは、時系列にソートされている必要がある。イベントのタイプは以下の通りである。

$00 パディング (なんの意味も持たない)
$01 初期無音の終了
$02 イントロ開始
$03 メインパート開始
$04 アウトロ開始
$05 アウトロ終了
$06 歌詞開始
$07 リフレイン開始
$08 間奏開始
$09 主題開始
$0A 変奏開始
$0B 変調
$0C 速さ変化
$0D 瞬間的な不必要なノイズ (パチン、ピシッ、ポン)
$0E 長めのノイズ
$0F 長めのノイズ終了
$10 イントロ終了
$11 メインパート終了
$12 歌詞終了
$13 リフレイン終了
$14 主題終了

$15-$DF 将来使用するために予約
$E0-$EF 未定義の同期 0-F
$F0-$FC 将来使用するために予約

$FD 音楽終了 (無音部分の始まり)
$FE オーディオファイル終了
$FF さらに1バイトのイベントが後に続く(これ以降の$FFという値を持つバイトはすべて同じ意味を持つ)

「イントロ開始」のような何かを開始するイベントは必ず終了しなくてはならないわけではない。「未定義の同期($E0-EF)」はユーザーイベントに使用するものである。スクリーンセーバーの立ち上げ、ステージ上の爆発のセットといった何かを音楽と同期させたい場合があるだろう。

一つのタグの中に、「ETCO」フレームは一つしか含めることができない。

4.7. MPEG ロケーションルックアップテーブル

MPEG オーディオファイル内での移動の精度とパフォーマンスを向上させるために、ファイル内の位置とタイムコードとフレーム[訳注:MPEGフレーム]を対応させておくことは非常に有効である。このID3v2フレームはソフトウエアがファイル内での位置を計算するために使用できるリファレンスを保持する。フレームヘッダの次に格納されているのは、各リファレンス毎にどれだけのフレーム数を増加させるかを決定する「フレームカウンタ」である。もし、この値が2だったのであれば、最初のリファレンスは第2フレームの、2番目のリファレンスは第4フレームの、3番目のリファレンスは第6フレームの、タイムコードをそれぞれ意味する。同様に、「リファレンス間のバイト数」と「リファレンス間のミリ秒数」はバイト数とミリ秒数をそれぞれ格納している。

各リファレンスはそれぞれビット数をあらわしている、2つの部分で構成されている。一つ目は「バイト数のずれをあらわすビット」で、これは「リファレンス間のバイト数」と実際の値とのずれをあらわす値である。二つ目は「ミリ秒のずれをあらわすビット」で、これは「リファレンス間のミリ秒数」と実際の値とのずれをあらわす値である。すべてのリファレンスのでのそれらのビット数の和(「バイト数のずれをあらわすビット」+「ミリ秒のずれをあらわすビット」)は四の倍数でなければならない。一つのタグの中に、「MLLT」フレームは一つしか含めることができない。

<「ロケーションルックアップテーブル」のヘッダ、ID: "MLLT">
リファレンス間のMPEG フレーム数           $xx xx
リファレンス間のバイト数                  $xx xx xx
リファレンス間のミリ秒数                  $xx xx xx
バイト数のずれをあらわすビットのビット数  $xx
ミリ秒のずれをあらわすビットのビット数    $xx

それぞれのリファレンスは、以下のようなデータを格納している

バイト数のずれをあらわすビット %xxx....
ミリ秒のずれをあらわすビット   %xxx....

4.8.同期テンポコード

楽曲中の部分部分におけるテンポを正確に描写するために、このフレームを用いることが出来る。ヘッダの次に、タイムスタンプとしてどのようなフォーマットを用いるかを示すための1バイトのデータを格納する。その後に、一つ以上のテンポコードが続く。すべてのテンポコードは、テンポ部分と時間部分の2つから構成されている。テンポは1バイトか2バイトのBPMで表される。もし、1バイト目が$FFだった場合は、2バイトで構成されているという意味になる。テンポは2-510BPMの間の値をとることが出来る。$00と$01は予約済みである。$00はビートが存在していないことを意味する。これは、音楽ではないということと同じ意味ではない。$01はビートのない状態に続いて、一度だけビートが打たれたことを意味する。

テンポを表すデータの次には、タイムスタンプが続く。楽曲中でテンポが変化するたびに、テンポの変化をプレーヤーに知らせるためである。すべてのテンポデータは時系列に並べられている必要がある。タイムスタンプはテンポが変化した最初のビートが打たれた瞬間の時間を格納する。一つのタグの中に、「SYTC」フレームは一つしか含めることができない。

<「同期テンポコード」のヘッダ、ID: "SYTC">
タイムスタンプフォーマット  $xx
テンポデータ                <binary data>

タイムスタンプフォーマットは以下の通り。

$01 絶対時間、32ビットサイズ、単位はMPEGフレーム
$02 絶対時間、32ビットサイズ、単位はミリ秒

絶対時間とは、すべてのタイムスタンプがファイルの開始からの時間であらわされることを意味する。

4.9. 非同期の歌詞/文章のコピー

このフレームは、その歌の歌詞、もしくはその他の音声を文章に書き写したものを格納する。ヘッダは文字コードと内容に関する情報を格納する。フレームボディには実際のテキストを格納する。「内容に関する情報」とは、最後がヌル文字で終わっている文字列である。もし何の情報もなければ「内容に関する情報」は $00 (00)のみを格納することになる。タグ中には複数の「非同期の歌詞/文章のコピー」フレームを含めることが出来るが、同じ言語、同じ「内容に関する情報」を持ったフレームが複数あってはならない。

<「非同期の歌詞/文章のコピー」のヘッダ、 ID: "USLT">
文字コード        $xx
言語              $xx xx xx
内容に関する情報  <エンコード指定文字列> $00 (00)
歌詞/文章         <エンコード指定全文字列>

4.10.同期をとった歌詞/文章

これは歌われている歌詞や、話されている文章をオーディオファイルに文字列として取り込むためのもう一つの方法である。このフレームの場合は、オーディオと同期がとられている。このフレームは、ステージ上、または画面上で起こっている出来事とオーディオファイルとの同期をとるためにも使用される。ヘッダには「内容に関する情報」が文字列(最後がヌル文字で終わる)で格納される。もし何の情報もなければ「内容に関する情報」は $00 (00)のみを格納することになる。

<「同期をとった歌詞/文章」のヘッダ、 ID: "SYLT">
文字コード                 $xx
言語                       $xx xx xx
タイムスタンプフォーマット $xx
内容のタイプ               $xx
内容に関する情報           <エンコード指定文字列> $00 (00)

文字コード:

$00  ISO-8859-1を文字コードとして用いる => 同期識別子として$00を用いる
$01  Unicodeを文字コードとして用いる => 同期識別子として$00 00を用いる

内容のタイプ:

$00  はその他
$01  は歌詞
$02  は文書のコピー
$03  は動作/部分の名前(例:「アダージョ」)
$04  はイベント(例:「ドン・キホーテが舞台に登場」)
$05  はコード(例:「Bb F Fsus」)
$06  はひとくちメモ(ポップアップインフォメーション)

タイムスタンプフォーマットは以下の通り。

$01 絶対時間、32ビットサイズ、単位はMPEGフレーム
$02 絶対時間、32ビットサイズ、単位はミリ秒

絶対時間とは、すべてのタイムスタンプがファイルの開始からの時間であらわされることを意味する。

ヘッダの後に続く文字列は「非同期の歌詞/文章のコピー」と大きく異なる点が一つある。一つの音節(もしくはエンコードする人にとって便利なサイズ)ごとに文字列がヌル文字で区切られており、その後にはその文字列がファイル中のどこに存在しているかを示すタイムスタンプがついているのだ。おのおのの同期音節は以下のようなフォーマットで構成されている。

同期させる文字列(通常は音節)
同期識別子(文字列の終結を表すヌル文字) $00 (00)
タイムスタンプ                           $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 ($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.

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.11. Comments

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.

<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.12. Relative volume adjustment

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

<Header for 'Relative volume adjustment', ID: "RVAD">
Increment/decrement           %00xxxxxx
Bits used for volume descr.   $xx
Relative volume change, right $xx xx (xx ...)
Relative volume change, left  $xx xx (xx ...)
Peak volume right             $xx xx (xx ...)
Peak volume left              $xx xx (xx ...)

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

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

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.

Relative volume change, right back $xx xx (xx ...)
Relative volume change, left back  $xx xx (xx ...)
Peak volume right back             $xx xx (xx ...)
Peak volume left back              $xx xx (xx ...)

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.

Relative volume change, center $xx xx (xx ...)
Peak volume center             $xx xx (xx ...)

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.

Relative volume change, bass $xx xx (xx ...)
Peak volume bass             $xx xx (xx ...)

4.13.Equalisation

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

<Header of 'Equalisation', ID: "EQUA">
Adjustment bits $xx

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

This is followed by 2 bytes + ('adjustment bits' rounded up to the nearest byte) for every equalisation band in the following format, giving a frequency range of 0 - 32767Hz:

Increment/decrement  %x (MSB of the Frequency)
Frequency            (lower 15 bits)
Adjustment           $xx (xx ...)

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.

4.14.Reverb

Yet another subjective one. You may here adjust echoes of different kinds. Reverb left/right is the delay between every bounce in ms. Reverb bounces left/right is the number of bounces that should be made. $FF equals an infinite number of bounces. Feedback is the amount of volume that should be returned to the next echo bounce. $00 is 0%, $FF is 100%. If this value were $7F, there would be 50% volume reduction on the first bounce, 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.15. Attached picture

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.

<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. lable 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.16. General encapsulated object

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.

<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  $00 (00)
Encapsulated object  <binary data>

4.17. Play counter

This is simply a counter of the number of times a file has been played. The value is increased by one every time the file begins to play. There may only be one "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.18. Popularimeter

The purpose of this frame is to specify how good an audio file is. Many interesting applications could be found to this frame such as a playlist that features better audiofiles more often than others or it could be used to profile a 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.

<Header for 'Popularimeter', ID: "POPM">
Email to user  <text string> $00
Rating         $xx
Counter        $xx xx xx xx (xx ...)

4.19.Recommended buffer size

Sometimes the server from which a audio file is streamed is aware of transmission or coding problems resulting in interruptions in the audio stream. In these cases, the size of the buffer can be recommended by the server using this frame. If the 'embedded info flag' is true (1) then this indicates that an ID3 tag with the maximum size described in 'Buffer size' may occur in the audiostream. In such case the tag should reside between two MPEG frames, if the audio is MPEG encoded. If the position of the next tag is known, 'offset to next tag' may be used. The offset is calculated from the end of tag in which this frame resides to the first byte of the header in the next. This field may be omitted. Embedded tags 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. 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. 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.20. Audio encryption

This frame indicates if the actual audio stream is encrypted, and by whom. Since standardisation of such encrypion scheme is beyond this document, all "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.

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'.

<Header for 'Audio encryption', ID: "AENC">
Owner identifier  <text string> $00
Preview start     $xx xx
Preview length    $xx xx
Encryption info   <binary data>

4.21. Linked information

To keep space waste as low as possible this frame may be used to link information from another ID3v2 tag that might reside in another audio file or alone in a binary file. It is recommended that this method is only used when the files are stored on a CD-ROM or other circumstances when the risk of file seperation is low. The frame contains a frame identifier, which is the frame that should be linked into this tag, a URL 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
URL                     <text string> $00
ID and additional data  <text string(s)>

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. The "TXXX", "APIC", "GEOB" and "AENC" frames may be linked with the content descriptor 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.22. 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 of 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.23.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 only be one "USER" frame in a tag.

<Header for 'Terms of use frame', ID: "USER">
Text encoding    $xx
Language         $xx xx xx
The actual text  <text string according to encoding>

4.24. 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 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.

<Header for 'Ownership frame', ID: "OWNE">
Text encoding   $xx
Price payed     <text string>$00
Date of purch.  <text string>
Seller          <text string according to encoding>

4.25. 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 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.

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 to attach.

<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.26. 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 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.

<Header for 'Encryption method registration', ID: "ENCR">
Owner identifier    <text string> $00
Method symbol       $xx
Encryption data     <binary data>

4.27. 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 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 section 3.3.1, flag j for more information.

<eader for 'Group ID registration', ID: "GRID">
Owner identifier      <text string"> $00
Group symbol          $xx
Group dependent data  <binary data">

4.28. 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 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.

<Header for 'Private frame', ID: "PRIV">
Owner identifier  <text string> $00
The private data  <binary data>

5. The 'unsynchronisation scheme'

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

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

%11111111 111xxxxx

And should be replaced with:

%11111111 00000000 111xxxxx

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

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

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

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.

6. Copyright

Copyright ©Martin Nilsson 1998. 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.

7. References

[CDDB]
Compact Disc Data Base URL : http://www.cddb.com
[ID3v2]
Martin Nilsson, "ID3v2 informal standard". URL : http://www.id3.org/id3v2-00
[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
[MIME]
Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. URL : http://www.ring.gr.jp/archives/doc/RFC/rfc2045.txt
[MPEG]
ISO/IEC 11172-3:1993. Coding of moving pictures and associated audio for digital storage media at up to about 1,5 Mbit/s, Part 3: Audio. Technical committee / subcommittee: JTC 1 / SC 29  and ISO/IEC 13818-3:1995 Generic coding of moving pictures and associated audio information, Part 3: Audio. Technical committee / subcommittee: JTC 1 / SC 29  and ISO/IEC DIS 13818-3 Generic coding of moving pictures and associated audio information, Part 3: Audio (Revision of ISO/IEC 13818-3:1995)
[PNG]
Portable Network Graphics, version 1.0 URL : http://www.w3.org/TR/REC-png-multi.html
[UNICODE]
ISO/IEC 10646-1:1993. Universal Multiple-Octet Coded Character Set (UCS), Part 1: Architecture and Basic Multilingual Plane. Technical committee / subcommittee: JTC 1 / SC 2 URL : http://www.unicode.org/
[URL]
T. Berners-Lee, L. Masinter & M. McCahill, "Uniform Resource Locators (URL).", RFC 1738, December 1994. URL : http://www.ring.gr.jp/archives/doc/RFC/rfc1738.txt
[ZLIB]
P. Deutsch, Aladdin Enterprises & J-L. Gailly, "ZLIB Compressed Data Format Specification version 3.3", RFC 1950, May 1996.

8. 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

The following genres are Winamp extensions

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

9. Author's Address

Written by
Martin Nilsson
Rydsvägen 246 C. 30
S-584 34 Linköping
Sweden
Email: nilsson at id3.org
Edited by
Dirk Mahoney
57 Pechey Street
Chermside Q
Australia 4032
Email: dirk at id3.org
Johan Sundström
Alsättersgatan 5 A. 34
S-584 35 Linköping
Sweden
Email: johan at id3.org