非公式標準 M. Nilsson 文書: id3v2.4.0-structure.txt 　 2000年11月 1日 日本語翻訳 水野 貴明 文書: id3v2.4.0-structure_j.txt 最終更新2000年11月 2日 ID3 タグ バージョン 2.4.0 - その主な構造 この文書の位置づけ この文書は非公式標準であり、ID3v2.3.0標準文書[ID3v2]を置き換えるもので ある。公式標準は、もし内容が全く同一であったとしても、別の改訂番号を振 られたものとなるだろう。このドキュメントの内容は、文章をよりはっきりさ せるために変更されることはあっても、機能が追加されたり、変更されたりす ることはない。 この文書の配布に関して制限はもうけられていない。 要約 この文書はID3v2のバージョン2.3.0の非公式標準の改訂版であるID3v2.4.0の 主な構造について述べられたものである。ID3v2は、オーディオに関するメタ 情報をオーディオファイル自身の中に埋め込むための自由度の高い方法を提供 する。保持できる情報は、タイトルや演奏者、著作権情報等だけではなく、均 一化カーヴのような技術情報も含まれる。 ID3v2.4.0は、実装の改訂を容易にするために、なるべくID3v2.3.0からの変更 が少なくなるように定められている。 1. 目次 この文書の位置づけ 要約 1. 目次 2. 文書中の表記規則 3. ID3v2の概要 3.1. ID3v2 ヘッダ 3.2. ID3v2 拡張ヘッダ 3.3. Padding領域 3.4. ID3v2 フッタ 4. ID3v2 フレームの概要 4.1. フレームヘッダフラグ 4.1.1. Frame status flags 4.1.2. Frame format flags 5. タグの位置 6. 非同期化 6.1. 非同期化スキーマ 6.2. Synchsafe 整数 7. 著作権 8. 参考文献 9. 著者のアドレス 2. 文書中の表記規則 ダブルクォーテーション("")で囲まれた文字列は、ファイル中にそのまま文字 列が埋め込まれていることを意味する。先頭に$をつけてある数字は16進数、 %がつけてある数字は２進数であることを意味する。$xxは、未知の１バイトの データを意味する。%xは未知の１ビットのデータを意味する。最重要ビット (MSB : most significant bit)とはバイトデータの第７ビットを、最も重要で ないビット(LSB : least significant bit)は第０ビットを意味する。 する。保持できる情報は、タイトルや演奏者、著作権情報等だけではなく、均 「タグ」という言葉は、この文書で扱われているタグ全体を示す。「フレーム」 という言葉はタグの中のデータのブロックを示す。タグは、ヘッダ、フレーム、 そして残りの領域（Padding領域：無くても良い）で構成されている。フィー ルドとはある値、もしくは文字列などの一つ一つの情報をさす。数字文字列 (Numeric String)は0-9の文字だけで構成された文字列のことである。 「MUST（〜しなくてはいけない）」「 MUST NOT（してはならない）」 「 REQUIRED（必要である）」「SHALL（するべきである）」「SHALL NOT （するべきではない）」の各キーワードの解釈は、RFC 2119 [KEYWORDS] で定 義された意味に準じている。 3. ID3v2の概要 ID3v2は、オーディオに関するメタ情報をオーディオファイル自身の中に埋め 込むことが出来る、オーディオファイルのための汎用的なタグつけフォーマッ トである。この文書に書かれているID3タグは、MPEG-1/2 layer I、MPEG-1/2 layer II、MPEG-1/2 layer III、MPEG-2.5でエンコードされたファイルを主な 対象としているが、おそらくそれ以外の方法でエンコードされたオーディオフ ァイルに対してや、単独で存在するオーディオメタデータとしても使用は可能 である。 ID3v2は新たな情報を追加しなければならなくなったときに備えて、柔軟かつ 拡張性に富んだ設計になっている。そのために、ID3v2はフレームと呼ばれる 情報を格納したコンテナの集合体として作られており、各フレームの内部構造 については、タグを読み込むアプリケーションは必ずしも知る必要がない。各 フレームの先頭にはそのフレームのフォーマットと中身を特定するための固有 な定義済みの識別子と、ソフトウエアが未知のフレームがあった場合にそのフ レーム全体を無視することができるようにするためのフレームサイズ、そして フレームフラグが格納されている。フレームフラグは、符号化に関する詳細情 報や、もしソフトウエアにとって未知ののフレームだった場合で、ファイルの 変更を行った際にそのフレームをタグに残すべきかどうか、といった情報を格 納している。 ID3v2でのビットの並び順は最重要ビット（MSB）が最初におかれるように配置 される。複数バイトで構成されているデータは、最重要バイトが最初におかれ るように配置される（例：$12345678 というデータは、$12 34 56 78という順 番で格納される）。 タグ全体の構造： +-----------------------------+ | ヘッダ（10バイト) | +-----------------------------+ | 拡張ヘッダ | | (可変長、省略可能) | +-----------------------------+ | フレーム (可変長) | +-----------------------------+ | Padding領域 | | (可変長、省略可能) | +-----------------------------+ | フッタ(10バイト、省略可能) | +-----------------------------+ 一般的に、Padding領域とフッタは排他制御されている（？）。詳細について はセクション３．３、３．４、５を参照のこと。 3.1. ID3v2 ヘッダ ファイルの先頭に位置するID3v2タグヘッダは、以下のような10バイトの構造 をしている。 ID3v2/ファイル識別子 "ID3" ID3v2 バージョン $04 00 ID3v2 フラグ %abcd0000 ID3v2 サイズ 4 * %0xxxxxxx タグの先頭の３バイトは常に「ID3」という文字列が入っていて、このことが ID3v2タグの存在の指標となっている。そのすぐ後には２バイトのバージョン 情報が入っている。ID3v2バージョンのうちはじめの１バイトは、メジャーバ ージョンを示し、２バイト目は改訂番号を示す。上記の場合はタグのバージョ ンがID3v2.4.0であることを示している。メジャーバージョンに変化がなけれ ば、改訂番号が変わっても古いバージョンとの互換性は保たれる。もしソフト ウエアがID3v2.4.0かそれ以下のバージョンのタグしかサポートしていなくて、 ID3v2.5.0かそれ以上のバージョンのタグに出会った場合、すべてのタグを無 視するべきである。メジャーバージョンと改訂番号は$FFになることはない。 バージョン番号の次には、ID3v2フラグフィールドが続く。その中に、現在は ４つのフラグ情報が格納されている。 a - 非同期化 ID3v2フラグの第７ビットは、全てのフレームに対して非同期化が行われて いるかを示している（詳細はセクション６．１を参照のこと）。このビット が１である場合は、非同期化が行われている。 b - 拡張ヘッダ 左から２番目のビット（第６ビット）はヘッダの後に拡張ヘッダがつけられ ているかを示す。拡張ヘッダについてはセクション3.2で解説されている。 このビットが１である場合は、拡張ヘッダが存在する。 c - 実験中 左から３番目のビット（第５ビット）は「実験中」を示す識別子として使用 される。そのタグが現在実験段階にある場合、このビットを立てることが推 奨される（SHALL）。 d - フッタ有り 左から４番目のビットはタグの一番最後にフッタがついていることを示す。 このビットが１である場合は、フッタが存在する。 これ以外のフラグビットはすべて０にしておかなければならない（MUST）。も し認識できないフラグがセットされていた場合は、そのフラグの機能が不明で あるため、タグ全体が読み込み不可能である可能性のあることを意味する。 ID3v2タグサイズは３２ビットのSynchsafe整数（セクション６．２）として保 管されている。したがって有効なのは２８ビットである（最大２５６メガバイ トまで表現が可能）。 ID3v2タグサイズは拡張ヘッダ、Padding領域、全てのフレームのバイト長を格 納している。フッタが存在している場合、この値は('全長' - 20)バイト、そ うでなければ('全長' - 10)バイトに等しい。 ID3v2タグヘッダは以下のような形になる。 $49 44 33 yy yy xx zz zz zz zz yyは$FF以外の数、xxはフラグバイト、zzは$80未満の数を表す。 3.2. 拡張ヘッダ 拡張ヘッダはタグの構造に関するさらに詳細な情報を保持している。しかし、 これらの情報はタグ情報の解析には必須ではない。したがって、拡張ヘッダは 省略可能である。 拡張ヘッダサイズ 4 * %0xxxxxxx フラグのバイト数 $01 拡張フラグ $xx 「拡張ヘッダサイズ」には、拡張ヘッダ全体のサイズを、３２ビットの Synchsafe整数として格納する。それゆえ、拡張ヘッダサイズは６よりも小さく なる事は決してない。 拡張ヘッダフラグは、サイズがフラグのバイト数で規定されており、以下のよ うに定義されている。 %0bcd0000 拡張ヘッダのフラグはすべて、セットされることで拡張ヘッダの後ろにデータ が追加されるようになる。追加されるフラグデータの順序は、フラグの現れる 順序と同じである（例えば、bのフラグデータはcのフラグデータよりも前に来 る）。フラグがセットされていない場合は、フラグデータは追加されない。タ グが修正された時に、全ての未知のフラグがあった場合は、必ずセットされて いない状態にして、フラグデータを削除しなければならない（MUST）。 フラグデータは全て、長さを示す１バイトのデータから始まる。ここには０か ら１２８（$00 - $7f）までの値が入っている。そして、続いてその長さのデ ータが入っている。もし、フラグが何の追加データも必要としない場合は、長 さを示すデータとして、$00が格納される。 b - タグは更新情報である このフラグがセットされていた場合、そのタグはファイルストリーム中でそ のタグよりも前に出てきているタグの更新情報であることを意味する。その タグに、ファイル中にひとつしか存在できないと定義されているフレームが あったば場合、その情報で古い情報を更新するためのものである。このフラ グはフレームデータを持たない。 フラグデータ長 $00 c - CRCのデータが存在する このフラグがセットされている場合、CRC-32 [ISO-3309]のデータが拡張ヘ ッダに含まれている。CRCはタグヘッダにおいてタグサイズとして定義され ている、ヘッダとフッタの間の領域から、拡張ヘッダ領域を除いた領域が計 算の対象範囲となる。この範囲が、Padding領域（もしあれば）を含み、フ ッタを含まないことに注意してほしい。CRC-32は上位4ビットが常に0になっ ている、35ビットのSynchsafe整数値として保存される。 フラグデータ長 $05 全フレームのCRC 5 * %0xxxxxxx d - タグの制限 ID3v2が定めるよりももっと多くの制限をタグに設けたいと考えるアプリケ ーションのためのものである。この制限が、単に書き込み前の制限を設ける だけで、タグの読み込み時には何の効力も無いことに注意してほしい。この フラグがセットされている場合、タグは以下のように制限される。 フラグデータ長 $01 制限情報 %ppqrrstt p - タグサイズの制限 00 128 フレーム以下でトータルタグサイズ 1 MB 以下 01 64 フレーム以下でトータルタグサイズ 128 KB 以下 10 32 フレーム以下でトータルタグサイズ 40 KB 以下 11 32 フレーム以下でトータルタグサイズ 4 KB 以下 q - 文字コードの制限 0 制限なし 1 ISO-8859-1 [ISO-8859-1] もしくはUTF-8 [UTF-8]のみ使用可 r - テキストフィールドサイズの制限 00 制限なし 01 文字列は 1024 文字以内 10 文字列は 128 文字以内 11 文字列は 30 文字以内 これらの文字制限では、文字のバイト数ではなく文字数に言及している点 に注意すること。最大バイト数は文字コードによって変動する。ひとつの テキストフレーム中に、複数の文字列が入っている場合は、それらの合計 値に対する制限となる。 s - 画像フォーマットの制限 0 制限なし 1 画像はPNG [PNG] もしくは JPEG [JFIF] フォーマットのみ t - 画像サイズの制限 00 制限なし 01 全ての画像は256x256 ピクセルかそれ以下 10 全ての画像は 64x64 ピクセルかそれ以下 11 特にサイズ指定の無い画像は全て 64x64 ピクセル固定 3.3. Padding領域 フレームの先頭に格納されているタグサイズよりも、フレームデータの総合計 サイズを小さくすることによって、フレームをすべて格納し終わった後（つま りID3タグの一番後ろ）に、Padding領域（残りの領域）を配置することもでき る。この領域は、後からフレームを追加したり、既存のフレームであっても今 より大きなデータを格納したいと思った場合に、ファイル全体を書き直すこと なくデータを更新するために用いることができる（OPTIONAL）。この領域はす べて$00という値で埋められている。フレームとフレームの間や、ヘッダとフ レームの間にPadding領域を作ることは許されていない（MUST NOT）。また、タ グにフッタがつけられている場合には、Padding領域をつけることは出来ない （MUST NOT）。 3.4. ID3v2 フッタ ファイルの後ろから検索した際に、ID3v2の位置を検出するプロセスをスピー ドアップするために、タグにフッタをつけることが出来る。オーディオデータ の後にタグをつけた場合などの、追加タグには必ずフッタをつけなければなら ない（REQUIRED）。フッタは、識別子以外、ヘッダをそのままコピーしたもの である。 ID3v2 識別子 "3DI" ID3v2 バージョン $04 00 ID3v2 フラグ %abcd0000 ID3v2 サイズ 4 * %0xxxxxxx 4. ID3v2 フレーム概要 すべてのID3v2フレームは、フレームヘッダと、実際の情報の入った一つ以上 のフィールドで構成されている。ヘッダは10バイトで、以下のような構成にな っている。 フレーム ID $xx xx xx xx (４文字) サイズ 4 * %0xxxxxxx フラグ $xx xx フレームIDは、大文字のAからZと、0から9までの文字で構成される。「X」 「Y」「Z」で始まるフレームIDは、実験的に用いることができるもので、タグ ヘッダの「実験中」フラグを立てないで用いることができ、だれでも自由に使 用可能である。しかし、ほかの誰かが、あなたと同じフレーム名を使用する可 能があることをわすれないようにすること。これ以外の全ての識別子は、将来 のために予約されている。 フレームIDの次には、フレームの、暗号化後、圧縮後、非同期化後の最終的な サイズが格納される。このサイズには、フレームヘッダは含まれず（「全フレ ーム長」 - 10バイト）、値は4バイトのSynchsafe 整数値として格納される。 フレームヘッダにおいて、サイズの後には、2バイトのフラグが格納される。 これらのフラグについてはセクション４．１で説明されている。 タグ中のフレームの並び順に決められた順番はないが、ファイルの認識に関し て、より重要な意味を持つフレームから順番に並べることが望ましい。例え ば、以下のような順番である。 UFID, TIT2, MCDI, TRCK ... 一つのタグには必ず一つ以上のフレームを含まねばならず、一つのフレームは ヘッダを除いて少なくとも1バイト以上大きい必要がある（MUST）。 特に何も指定されていない場合、数字文字列やURL [URL]を含むすべての文字 列の文字コードはISO-8859-1 [ISO-8859-1]を使用する。使用可能な範囲は$20 - $FF である。これらの文字列は、フレームの解説の中では<文字列>（text string）、改行が使用可能な場合は<全文字列> （full text string）という 名前で表現されている。特に何もかかれていない場合は、改行は使用すること ができない。ISO-8859-1の文字コードで、改行文字を含めることができる場 合、その文字コードは $0A のみである。 それ以外の文字コードが使用可能なフレームには、文字コード指定子が含まれ ている。以下に使用可能な文字コードを示す。 $00 ISO-8859-1 [ISO-8859-1]。終端文字は $00。 $01 UTF-16 [UTF-16] でエンコードされた Unicode [UNICODE]。BOM有 り。一つのフレームの内部では、すべて同じバイトオーダーであるべ きである（SHALL）。終端文字は $00 00。 $02 UTF-16BE [UTF-16] （ビッグエンディアン）でエンコードされた Unicode [UNICODE] 。BOMなし。終端文字は $00 00。 $03 UTF-8 [UTF-8] でエンコードされた Unicode [UNICODE]。終端文字は $00。 フレームの解説の中では、文字コードの指定できる文字列は<文字コード指定 文字列>（text string according to encoding）、改行が使用可能な場合は <文字コード指定全文字列>（full text string according to encoding）とい う名前で表現されている。タイプが $01 で、ヌル文字で終わる空文字列はす べて BOM の後にヌル文字がくる（$FF FE 00 00 もしくは $FE FF 00 00）。 タイムスタンプのフィールドの書式は ISO 8601 のサブセットの基づいてい る。できる限り正確に時間をあらわしたいとき、そのフォーマットは以下のよ うになる。 yyyy-MM-ddTHH:mm:ss（年、"-"、月、"-"、日、"T"、時間（２４時間表示）、 ":"、分、"-"、秒） しかし、これほどの正確さが必要でない場合、必要に応じて、各項目を省略す ることができる。したがって、有効なタイムスタンプは以下のようになる。 yyyy、yyyy-MM、yyyy-MM-dd、yyyy-MM-ddTHH、yyyy-MM-ddTHH:mm、 yyyy-MM-ddTHH:mm:ss すべての時間は、UTC（協定世界時）を用いる。時間の範囲を表す場合には、 ISO 8601で定義されているとおり、スラッシュを用いること。非連続的な複数 の日時を格納したい場合は、複数の文字列として格納する。それはもちろん、 複数の文字列を格納することが、フレームの形式で許されている場合に限られ る。 幾つかのフィールドの存在する３バイトの言語フィールドは、ISO-639-2 [ISO-639-2] に基づいた、言語フレーム定数を指定する。言語はすべて、小文 字であらわすべきである。言語が不明の場合は「XXX」を使用する。 すべてのURL [URL] は相対パスも可能である（MAY）。例を以下に示す。 "picture.png"、 "../doc.txt" もしフレームの長さが、決められた長さよりも長かった場合、例えば、このド キュメントで決められたよりもたくさんのフィールドが存在していた場合、こ のフレームには、ID3v2 のもっと新しいバージョンで仕様が追加されたことを 意味する。タグヘッダの改定番号を調べれば、そのことが確認できる。 4.1. フレームヘッダフラグ フレームヘッダにおいて、サイズデータの後には2バイトのフラグデータが続 く。未使用のフラグはすべて0にしておかなければならない（MUST）。1バイト 目は、「ステータスメッセージ」として、2バイト目はフォーマットの説明と して用いられる。もし1バイト目に未知のフラグがセットされていた場合は、 そのビットを0にしない限り、フレームの内容を変更してはならない （MUST NOT）。2バイト目に未知のフラグが立っていた場合は、おそらくその フレームの内容は解読ができないであろう。2バイト目のフラグのうちの幾つ かは、ヘッダに追加情報があることを意味する。これらの追加情報のフィール ドの並び順は、それらを示しているフラグの並び順と同じになる。フラグフィ ールドは以下のように定義されている（アルファベットの l と o は数字の０ と１に間違いやすいので使用していない）。 %0abc0000 %0h00kmnp 幾つかのフレームフォーマットフラグは、フレームに追加情報フィールドが存 在していることを意味するものである。これらの情報は、フレームヘッダとフ レームデータのあいだにそれらの存在を意味するフラグと同じ順序でおかれる ことになる。例えば、伸張後のサイズをあらわす4バイトは、暗号化の方法を 示す1バイトのデータよりも前におかれるのである。これらの追加されたフィ ールドのサイズは「フレームサイズ」の値に影響を与えるが、暗号化、及び圧 縮の対象にはならない。 各フレームのステータスフラグの初期状態は、特に他の場所で指定されていな い場合は、「タグの変更時に保存される」かつ「ファイルの変更時に保存され る」、つまり %00000000 になっている。 4.1.1. フレームステータスフラグ a - タグ変更時に保存されるか このフラグは、タグパーサがそのフレームを認識できない場合で、なおかつ 何らかの方法でタグのデータが変更された場合に、どうしたらよいかを示し ている。これは、タグの変更すべてに適応される。Padding領域の追加や、 フレームをならべ変えた場合も含まれる。 0 フレームは保存されるべきである。 1 フレームは破棄されるべきである。 b - ファイル変更時に保存されるか このフラグは、タグパーサがそのフレームを認識できない場合で、なおかつ 何らかの方法でファイルのタグ以外の部分が変更された場合に、どうしたら よいかを示している。これは、オーディオデータが他のオーディオデータに 完全に置き換えられてしまった場合は適用されない。 0 フレームは保存されるべきである。 1 フレームは破棄されるべきである。 c - 読み込み専用 このフラグがセットされていた場合、ソフトウエアにこのフレームの内容は 読み込み専用であることを示している。内容を変更することは、何らかのデ ータ、例えば署名などを破壊してしまうことになる。もし、なぜこのフレー ムが読み込み専用であるかということを考えずに、埋め合わせになる正しい データを格納したりせずに、データを変更してしまった場合、例えば署名を 再計算してしまった場合などは、このビットは必ず0にしなければならない （MUST）。 4.1.2. フレームフォーマットフラグ h - グルーピング このフラグはこのフレームが他のフレームとで形成されるグループに属して いるかを示すものである。もし、このフラグがセットされている場合は、フ レームに、グループを識別するための「グループ識別子」として1バイトが 追加される。同じグループ識別子をもつフレームはすべて、同じグループに 属していることになる。 0 このフレームにはグループ情報が存在しない。 1 このフレームにはグループ情報が存在する。 k - 圧縮 このフラグは、フレームが圧縮されているかどうかを示している。このフラ グがセットされているフレームは「データ長指定子」を必ずつけなければな らない（MUST）。 0 このフレームは圧縮されていない。 1 このフレームは zlib [zlib] のデフレート法を用いて圧縮されてい る。このフラグがセットされている場合は、「データ長指定子」フ ラグビットを必ずセットしなくてはならない。 m - 暗号化 このフラグは、フレームが暗号化されているかどうかを示すものである。こ のフラグがセットされている場合は、どのような方法で暗号化されているか を示す1バイトのデータがフレームに追加される。暗号化の方法の登録に関 する詳細は ENCR フレームの解説を参照のこと。暗号化は、圧縮よりも後に 行われる。このフラグがセットされることで、データ長指定子が必要となる かどうかは、暗号化の手法に依存する。 0 フレームは暗号化されていない。 1 フレームは暗号化されている。 n - 非同期化 このフラグは、フレームに非同期化が適用されているかどうかを示すもので ある。非同期化の詳細については、セクション６を参照のこと。もしこのフ ラグがセットされていた場合は、ヘッダの終わりから、このフレームの終わ りの部分までが、非同期化処理が行われている。データ長指定子は、あるこ とが望ましいが、非同期化によって、その存在が義務付けられることは無 い。 0 フレームは非同期化処理されていない。 1 フレームは非同期化処理されている。 p - データ長指定子 このフラグは、データ長指定子がフレームに追加されているかどうかを示 す。データ長指定子は、もしすべてのフラグが０であった場合の、フレーム の長さのことで、32ビットのSynchsafe 整数値として格納される。 0 データ長指定子はこのフレームに追加されていない。 1 このフレームにはデータ長指定子が追加されている。 5. タグの位置 ID3v2 タグの初期位置は、オーディオファイルの前であり、プレーヤーはデー タがストリーミングされているときでも、情報をきちんと得ることができる。 しかし、タグをファイルの最後に付加したり、オーディオファイルの前後にタ グを分割配置することもできる。組み込まれていないタグを、どの位置に配置 するか決定する場合は、以下のような順番で考えるべきである（SHOULD）。 1. オーディオデータの前にタグを置く 2. 重要な情報だけを格納したタグをオーディオデータの前に置き、残りを ファイルの最後、ただしほかのタグシステムのタグデータよりも前に置 く。この場合、最初のタグに、SEEK フレームが無ければならない。 3. 全てのタグデータをファイルの最後、ただしほかのタグシステムのタグ データよりも前に置く。 第2、第3のケースでは、ほかに既知のタグが付加されていなければ、単純に ファイルの後ろにタグを付加するだけでよい。ID3v2 タグの存在を調べるため の方法として推奨されるのは、以下のとおり。 1. セクション３．１に記されている方法を用いて、ファイルの先頭にある タグを調べる。 2. タグの中にSEEKフレームがあったら、その情報を元に、次のタグを検索 する。 3. ファイルの後ろから検索し、タグフッタを検出する。 新しいタグが検出された場合、そのタグの拡張ヘッダに「更新」フラグがセッ トされていなかったら、古いタグの情報はすべて破棄すべきである。 6. 非同期化 非同期化の唯一の目的は、ID3v2タグと既存のソフトウエアやハードウエアと の互換性を出来る限り持たせることである。もし、ファイルがID3v2対応のソ フトウエアやハードウエアのみで使用されるならば、「非同期化された」タグ を使う必要は無い。非同期化は、MPEG 1/2 レイヤI、 II 、 III、MPEG 2.5 および AAC においてのみ、使用する意味がある。 6.1. 非同期化のスキーム タグ中に存在したすべての偽の同期シグナルの、1バイト目と2バイト目の間に １バイトの０を挿入するものである。ID3 エンコーダによって非同期化処理が 行われなければならないのは、以下のようなデータである。 %11111111 111xxxxx そしてこれらは以下のように置き換えられる。 %11111111 00000000 111xxxxx この処理の影響で、$FF 00 という並びのデータも、非同期化処理の対象にな ってしまうが、それはデコードの過程では、何の影響も無い。したがって、す べての $FF 00 というデータは、非同期化の過程で $FF 00 00 に変換されな ければならない。 非同期化が行われているかどうかを示すために、フレームヘッダの非同期化フ ラグを立てておくべきである。非同期化によって、データに変更が加えられる 場合にだけ、このビットをセットすべきである（SHOULD）。もし、タグ中の全 てのフレームに対して非同期化処理が行われている場合は。タグヘッダの、非 同期化フラグをセットするべきである（SHOULD）。このフラグは、タグに非同 期化処理の行われたフレームが存在する場合は、セットしてはならない（MUST NOT）。 オーディオデータの先頭のデータが $FF であったと仮定する。もし、最後の フレームの最後の1バイトが $FF で、しかもPadding領域やフッタが無かった 場合には、偽の同期シグナルが出来てしまうことになる。この問題は、フッタ を追加するか、Padding領域を追加するか、フレームデータの最後に $00 をつ けたうえで、非同期化処理を行うことで、回避することが出来る。この非同期 化処理の場合は、通常の非同期化処理よりも1バイト多くフレームにデータを 追加してしまう。最後の方法は推奨はされないが、$FF で終わる全てのフレー ムに適用が可能である。 タグは、完全に非同期化処理がされた状態か、全く非同期化処理がされていな い状態かで存在することが好ましい。完全に非同期化されたタグ中には、これ までに述べてきた偽の同期シグナルは存在せず、タグの最後は$FFで終わらない ものである。全く非同期化処理が行われていないタグとは、非同期化されたフ レームがひとつも存在せず、それゆえ、全てのヘッダの非同期化フラグがセッ トされていない状態になっているものである。 もし、圧縮や暗号化が行われているのであれば、非同期化の処理は必ずそれら の処理よりも後に行わなければならない（MUST）ことを、わすれないようにす ること。逆に、デコード中には、まず最初に非同期化処理の対応をおこなわな ければならず、暗号化、圧縮は後に行う。 6.2. Synchsafe 整数値 タグ中の幾つかの部分では、非同期化されたデータのサイズを事前に知ること が出来ないために、非同期化に向かないことがある。それは特に、何かのサイ ズを指定する部分で問題となる。ID3v2 での解決策は、Synchsafe 整数値を用 いることである。これは決して偽の同期シグナルを作り出すことが無い。 Synchsafe 整数値は、8ビット中の7ビットを実際のデータとして使用し、最大 ビット（第7ビット）を必ず0にしてある整数である。それゆえ、32ビットの Synchsafe 整数は、28ビットの情報を格納することが出来る。 例： 255 (%11111111) を16ビットのSynchsafe 整数としてエンコードすると、 383 (%00000001 01111111) になる。 7. 著作権情報 Copyright (C) Martin Nilsson 2000. All Rights Reserved. この文書、およびこの文書の翻訳物のコピー、他への提供、その他派生する仕 事、例えばコメント付けや別の言い方での説明、実装への手助け、これらの一 部もしくは全部をコピーしたり、配布したり、出版したりといったことに対す る制限は一切無い。しかし、このドキュメントへのリファレンスを必ずつける こと。しかし、このドキュメント自身はいかなる方法によっても改変したり、 まるでオリジナルの文書として再発行したりしてはいけない。 これらの条件は永久に変化することは無い。 このドキュメントは、原則的に「そのまま」の状態で提供されるもので、著者 は明示的、および暗黙の全ての権利を放棄する。これはこの情報を使用しても、 いかなる権利や商業上の保証その他を侵害することはない。 [原文] This document and the information contained herein is provided on an 'as is' basis and the authors disclaims ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 8. 参考文献 [ID3v2] Martin Nilsson, 'ID3v2 informal standard'. [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' [KEYWORDS] S. Bradner, 'Key words for use in RFCs to Indicate Requirement Levels', RFC 2119, March 1997. [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' [UNICODE] The Unicode Consortium, 'The Unicode Standard Version 3.0', ISBN 0-201-61633-5. [URL] T. Berners-Lee, L. Masinter & M. McCahill, 'Uniform Resource Locators (URL)', RFC 1738, December 1994. [UTF-8] F. Yergeau, 'UTF-8, a transformation format of ISO 10646', RFC 2279, January 1998. [UTF-16] F. Yergeau, 'UTF-16, an encoding of ISO 10646', RFC 2781, February 2000. [ZLIB] P. Deutsch, Aladdin Enterprises & J-L. Gailly, 'ZLIB Compressed Data Format Specification version 3.3', RFC 1950, May 1996. 9. 著者のアドレス 著者 Martin Nilsson Rydsv臠en 246 C. 30 SE-584 34 Linkping Sweden Email: nilsson@id3.org 訳者 水野貴明（Takaaki Mizuno） Email: takaaki@cds.ne.jp