非公式標準 文書：id3v2.3.0J.html

M. Nilsson 1999年2月3日

日本語翻訳

水野 貴明 最終更新2000年6月24日

この文書の位置づけ

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

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

要約

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

1.目次

2.文書中の表記規則

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

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

3.ID3v2の概要

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

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

２番目の目標（柔軟かつ拡張性に富んだ設計にすること）は、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バイトの構造をしている。

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

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

a - 非同期化

「ID3v2フラグ」の第７ビットは、非同期化が行われているかを示している（詳細はセクション５を参照のこと）。このビットが１である場合は、非同期化が行われている。

b - 拡張ヘッダ

左から２番目のビット（第６ビット）はヘッダの後に拡張ヘッダがつけられているかを示す。拡張ヘッダについてはセクション3.2で解説されている。

c - 実験中

左から３番目のビット（第５ビット）は「実験中」を示す識別子として使用される。このフラグが立っている場合、そのタグが現在実験段階にあることを示している。

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

ID3v2タグサイズは、最重要（第７ビット）がすべて０になるようにエンコードされた４バイトのデータであり、全部で28ビットのデータである。０にセットしたビットは無視する。したがってタグのサイズが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 拡張ヘッダ

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

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

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

%x0000000 00000000

x - CRC のデータが存在する

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

3.3.ID3v2 フレームの概要

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

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

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

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

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

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

特に指定がされていない場合、文字列の文字コードは$20 - $FFの間のISO-8859-1である。このような文字列は＜文字列＞、改行コードを入れても良い場合は＜全文字列＞という名前で指定される。Unicode文字列は１６ビットの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のみを使用することができる。複数の文字コードを使うことのできるフレームでは、フレームサイズの後に、文字コードの種類を指定するための１バイトのデータをつける。そこで指定されるのはISO-8859-1なら$00、Unicodeなら$01である。文字コードが指定可能な文字列は＜エンコード指定文字列＞と呼ばれる。改行コードを入れても良い場合は＜エンコード指定全文字列＞という名前で指定される。Unicode文字列において、空の文字列を指定する場合は、Unicode BOMの後にすぐヌル文字を入れる ($FF FE 00 00 もしくは$FE FF 00 00)。

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

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

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

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

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

%abc00000 %ijk00000

a - タグの変更で取り除かれる

このフラグは、そのフレームをアプリケーションが認識できない場合は、タグに変更が加えられたときに、そのフレームを削除しなくてはならないことを示す。このことはPadding領域の追加やフレームの順序の変更など、すべての種類の変更の際に適用される。

b - ファイルの変更で取り除かれる

このフラグは、そのフレームをアプリケーションが認識できない場合は、ファイル（タグ領域以外）に変更が加えられたときに、そのフレームを削除しなくてはならないことを示す。このことはオーディオファイルが他のオーディオファイルと完全に置き換えられた場合には適用されない。

c - 読み込み専用

このフラグがセットされていた場合は、このフレームが読み込み専用であることを示す。このフレームの中身を修正することは、何らかの情報（署名など）を破壊してしまう可能性がある。なぜそのフレームが読み込み専用になっているかを考慮せず、適当な代替処理をせずにそのフレームを修正してしまった場合（署名を再計算するなど）は、このビットは０にしなくてはならない。

i - 圧縮

このフラグはフレームが圧縮されているかを示す。

j - 暗号化

このフラグはフレームが暗号化されているかどうかを示す。もし、暗号化されている場合は、暗号化の手法を示す１バイトのデータが、フレームヘッダの後に格納されている。暗号化の手法の登録に関する詳細な説明はセクション4.26を参照せよ。

k - グループ識別子

このフラグは、そのフレームが他のフレームとグループを形成しているかどうかを示す。もしこのフラグがセットされている場合はグループを識別するための１バイトのデータがフレームヘッダの後に格納されている。そこに同じデータが格納されているフレームはすべて同じグループに属するのだ。

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

3.3.2.フラグの初期値

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

1. タグに変更があった場合は削除される。ファイルに変更があった場合も削除される。

なし。

2. タグに変更があった場合は削除される。ファイルに変更があった場合は保存される。

なし。

3. タグに変更があった場合は保存される。ファイルに変更があった場合は削除される。

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

4. タグに変更があった場合は保存される。ファイルに変更があった場合は保存される。

残りのフレーム。

4.ID3v2 フレームの定義

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

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

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

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

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

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

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

4.3.URL リンクフレーム

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

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

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

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

4.4.協力者一覧

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

4.5.音楽ＣＤ識別子

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.8.同期テンポコード

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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.

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.

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.

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.

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.

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:

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.

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.

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.

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.

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.

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.

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

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

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:

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.

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.

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:

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.

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.

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.

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.

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

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

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

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

[PNG] Portable Network Graphics, version 1.0

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

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

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

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

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

[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>

8.Appendix

A.Appendix A - Genre List from ID3v1

9.Author's Address

Written by

Martin Nilsson
Rydsv臠en 246 C. 30
S-584 34 Link�ping
Sweden

Email: nilsson@id3.org

Edited by

Dirk Mahoney
57 Pechey Street
Chermside Q
Australia 4032

Email: dirk@id3.org

Johan Sundstr�m
Als舩tersgatan 5 A. 34
S-584 35 Link�ping
Sweden

Email: johan@id3.org