非公式標準 M. Nilsson 文書: id3v2.4.0-frames.txt   2000年11月 1日 日本語翻訳 水野 貴明 文書: id3v2.4.0-frames_j.txt 最終更新2000年11月21日 ID3 タグ バージョン 2.4.0 - ネイティブフレーム この文書の位置づけ この文書は非公式標準であり、ID3v2.3.0 標準文書 [ID3v2] を置き換えるも のである。公式標準は、もし内容が全く同一であったとしても、別の改訂番号 を振られたものとなるだろう。このドキュメントの内容は、文章をよりはっき りさせるために変更されることはあっても、機能が追加されたり、変更された りすることはない。 この文書の配布に関して制限はもうけられていない。 要約 この文書はID3v2 のバージョン2.3.0 の非公式標準の改訂版であるID3v2.4.0 が標準でサポートするフレームついて述べられたものである。ID3v2 は、オー ディオに関するメタ情報をオーディオファイル自身の中に埋め込むための自由 度の高い方法を提供する。保持できる情報は、タイトルや演奏者、著作権情報 等だけではなく、均一化カーヴのような技術情報も含まれる。 ID3v2.4.0は、実装の改訂を容易にするために、なるべくID3v2.3.0からの変更 が少なくなるように定められている。 1. 目次 2. 文書中の表記規則 3. フラグの初期値 4. 定義済みの ID3v2 フレーム 4.1. 一意的なファイル識別子 4.2. テキスト情報フレーム 4.2.1. 識別用フレーム 4.2.2. 関係者用フレーム 4.2.3. 派生的および主観的なフレーム 4.2.4. 権利とライセンスのフレーム 4.2.5. その他のテキストフレーム 4.2.6. ユーザー定義テキスト情報フレーム 4.3. URL リンクフレーム 4.3.1. URL リンクフレーム - 詳細 4.3.2. ユーザー定義 URL リンクフレーム 4.4. 音楽CD識別子 4.5. イベントタイミングコード 4.6. MPEG ロケーションルックアップテーブル 4.7. 同期 テンポコード 4.8. 非同期 歌詞/文書のコピー 4.9. 同期 歌詞/文書 4.10. コメント 4.11. 相対ボリューム調整 (2) 4.12. 均一化 (2) 4.13. リバーブ 4.14. 付属する画像 4.15. パッケージ化された一般的なオブジェクト 4.16. 演奏回数 4.17. 人気メーター 4.18. 推奨バッファサイズ 4.19. オーディオの暗号化 4.20. リンク情報 4.21. 位置同期用フレーム 4.22. 使用条件 4.23. 所有権フレーム 4.24. コマーシャルフレーム 4.25. 暗号化の手法の登録 4.26. グループ識別子の登録 4.27. プライベートフレーム 4.28. 署名フレーム 4.29. シークフレーム 4.30. オーディオシークポイントインデックス 5. 著作権 6. 参考文献 7. 付録 A. 付録 A - ID3v1 のジャンル一覧 8. 著者のアドレス 2. 文書中の表記規則 ダブルクォーテーション("")で囲まれた文字列は、ファイル中にそのまま文字 列が埋め込まれていることを意味する。先頭に$をつけてある数字は16進数、 %がつけてある数字は2進数であることを意味する。$xxは、未知の1バイトの データを意味する。%xは未知の1ビットのデータを意味する。最重要ビット (MSB : most significant bit)とはバイトデータの第7ビットを、最も重要で ないビット(LSB : least significant bit)は第0ビットを意味する。 「タグ」という言葉はID3v2の主な構造の文書 [ID3v2-strct] で述べられてい るタグ全体を示す。「フレーム」はタグ中の情報のブロックを示す。タグは、 ヘッダ、フレーム、そして残りの領域(Padding領域:無くても良い)で構成 されている。フィールドとはある値、もしくは文字列などの一つ一つの情報を さす。数字文字列(Numeric String)は "0123456789" の文字だけで構成された 文字列のことである。 「MUST(〜しなくてはいけない)」「 MUST NOT(してはならない)」 「 REQUIRED(必要である)」「SHALL(するべきである)」「SHALL NOT (するべきではない)」の各キーワードの解釈は、RFC 2119 [KEYWORDS] で定 義された意味に準じている。 3. フラグの初期値 この文書中で解説されているフレームの各フラグの初期値は以下のように分類 される。個々のソフトウエアがこれよりも適した設定があると考えた場合は、 この設定とは異なっている場合もあり得る。 1. タグに変更があった場合は削除される。 ファイルに変更があった場合も削除される。 なし。 2. タグに変更があった場合は削除される。 ファイルに変更があった場合は保存される。 なし。 3. タグに変更があった場合は保存される。 ファイルに変更があった場合は削除される。 ASPI, AENC, ETCO, EQU2, MLLT, POSS, SEEK, SYLT, SYTC, RVA2, TENC, TLEN 4. タグに変更があった場合は保存される。 ファイルに変更があった場合は保存される。 残りのフレーム。 4. 定義済みの ID3v2 フレーム この文書の中では以下のフレームが定義されている。 4.21 AENC オーディオの暗号化 4.15 APIC 付属する画像 4.30 ASPI オーディオシークポイントインデックス 4.11 COMM コメント 4.25 COMR コマーシャルフレーム 4.26 ENCR 暗号化の手法の登録 4.13 EQU2 均一化 (2) 4.6 ETCO イベントタイミングコード 4.16 GEOB パッケージ化された一般的なオブジェクト 4.27 GRID グループ識別子の登録 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 RVA2 相対ボリューム調整 (2) 4.14 RVRB リバーブ 4.30 SEEK シークフレーム 4.29 SIGN 署名フレーム 4.10 SYLT 同期 歌詞/文書 4.8 SYTC 同期テンポコード 4.2.1 TALB アルバム/映画/ショーのタイトル 4.2.3 TBPM BPM (beats per minute:一分間の拍数) 4.2.2 TCOM 作曲者 4.2.3 TCON 内容のタイプ 4.2.4 TCOP 著作権情報 4.2.5 TDEN エンコード日時 4.2.5 TDLY プレイリスト遅延時間 4.2.5 TDOR オリジナルのリリース日時 4.2.5 TDRC 録音日時 4.2.5 TDRL リリース日時 4.2.5 TDTG タグ付け日時 4.2.2 TENC エンコードした人 4.2.2 TEXT 作詞家/文書作成者 4.2.3 TFLT ファイルタイプ 4.2.2 TIPL かかわった人々の一覧 4.2.1 TIT1 内容の属するグループの説明 4.2.1 TIT2 タイトル/曲名/内容の説明 4.2.1 TIT3 サブタイトル/説明の追加情報 4.2.3 TKEY 初めの調 4.2.3 TLAN 言語 4.2.3 TLEN 長さ 4.2.2 TMCL ミュージシャン クレジットリスト 4.2.3 TMED メディアタイプ 4.2.3 TMOO ムード 4.2.1 TOAL オリジナルのアルバム/映画/ショーのタイトル 4.2.5 TOFN オリジナルファイル名 4.2.2 TOLY オリジナルの作詞家/文書作成者 4.2.2 TOPE オリジナルアーティスト/演奏者 4.2.4 TOWN ファイルの所有者/ライセンシー 4.2.2 TPE1 主な演奏者/ソリスト 4.2.2 TPE2 バンド/オーケストラ/伴奏 4.2.2 TPE3 指揮者/演奏者詳細情報 4.2.2 TPE4 翻訳者, リミックス, その他の修正を行った人物 4.2.1 TPOS セット中の位置 4.2.4 TPRO Produced notice 4.2.4 TPUB 出版社 4.2.1 TRCK トラックの番号/セット中の位置 4.2.4 TRSN インターネットラジオ局の名前 4.2.4 TRSO インターネットラジオ局のオーナー 4.2.5 TSOA アルバムのソートオーダー 4.2.5 TSOP 演奏者のソートオーダー 4.2.5 TSOT タイトルのソートオーダー 4.2.1 TSRC ISRC (international standard recording code: 国際標準レコーディングコード) 4.2.5 TSSE エンコードに使用したソフトウエア/ハードウエアとセッティング 4.2.1 TSST セットのサブタイトル 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. 一意的なファイル識別子 このフレームは、ファイルの内容に関連した情報を含むようなデータベースの 中で、それぞれのファイルを一意的に識別するためのものである。そのような データベースの標準化についてはこの文書の解説範囲を超えるので、すべての UFID フレームは「所有者識別子」フィールドで開始される。これは、ヌル文 字を最後に持つ文字列で、このデータベースの実装に責任を持つ組織の、対応 してくる窓口の電子メールアドレスを含んだ URL [URL] か、電子メールアド レスを調べることができる場所へのリンクを格納するフィールドである。それ らのデータベースに関する質問は、そこで指定されている電子メールアドレス へ送るべきである。この URL には実際のデータベースのクエリーを書き込む べきではない。「http://www.id3.org/dummy/ufid.html」という文字列をテス ト文字列として使用してもよい。「所有者識別子」は空欄にすることはできな い(終了を表すヌル文字以外に一字以上必要)。「所有者識別子」の後には実 際の識別子が続く。識別子は最大64文字になっている。一つのタグ中に複数の 「UFID」フレームを持たせることは可能だが、すべてのフレームは同じ「所有 者識別子」を持っていなければならない。 <「一意的なファイル識別子」のヘッダ, ID: "UFID"> 所有者識別子 <文字列> $00 識別子 <64バイトまでのバイナリデータ> 4.2. テキスト情報フレーム テキスト情報フレームとは、アーティスト名やアルバム名といった情報を格納 している、もっとも重要なフレーム群である。一つのタグ中には、それぞれの テキスト情報フレームはひとつずつしか格納出来ない。全てのテキスト情報フ レームは複数の文字列を格納できるようになっている。文字列が複数ある場合 は、ヌル文字で区切られたリストとして格納される。ヌル文字とは、それぞれ の文字コードの終端文字のことである。テキスト情報フレームのフレーム ID はすべて「T」で始まっている。「TXXX」をのぞけば、テキスト情報フレーム 以外のフレームが「T」で始まることはない。テキスト情報フレームはすべて 以下のフォーマットになっている。 <「テキスト情報フレーム」のヘッダ, ID: "T000" - "TZZZ", 4.2.6 で解説されている「TXXX」を除く> 文字コード $xx 情報 <エンコード指定文字列(リスト)> 4.2.1. 識別用フレーム TIT1 「内容の属するグループの説明」フレームはそのサウンドが大きな音楽・サウ ンドのカテゴリに属している場合に使用する。例えば、クラシック音楽はしば しば異なる音楽のセクションに分類される(例えば、「ピアノコンチェルト」 「天候-ハリケーン」)。 TIT2 「タイトル/曲名/内容の説明」フレームはそのファイルの中身の実際の名前で ある(たとえば「アダージョ」「ハリケーン・ドナ」)。 TIT3 「サブタイトル/説明の追加情報」フレームはタイトルに直接付随する情報 (「Op. 16」や「Wembleyでのライブパフォーマンス」など)を格納するもの である。 TALB 「アルバム/映画/ショーのタイトル」フレームは、そのオーディオファイルの 録音(もしくは音源)のタイトルを意味する。 TOAL 「オリジナルのアルバム/映画/ショーのタイトル」フレームは、オリジナルレ コーディング(もしくはその音源)のタイトルを格納するために使用する。こ れは、たとえばその曲が、以前にリリースされた曲のカヴァー曲だった場合な どに使用する。 TRCK 「トラックの番号/セット中の位置」フレームは、そのオーディオファイルが オリジナルの録音中で何番目になっているかを示す数字文字列である。このフ レームは「/」を用いて拡張し、そのあとにその録音の総トラック数を格納し てもよい(MAY)。たとえば「4/9」といった具合である。 TPOS 「セット中の位置」フレームには楽曲がセット中のどこに位置するものなのか を意味する数字文字列が格納される。このフレームは「TALB」フレームに格納 されている音源が複数のメディアに分割されている場合に使用する。たとえ ば、2枚組CDなどがこれにあたる。値は「/」を用いて拡張し、セット中の位置 とセットの総数を示す数字文字列を格納してもよい(MAY)。たとえば「1/2」 といった具合である。 TSST 「セットのサブタイトル」フレームには、そのトラックが属するセットのサブ タイトルを格納するのに使用する。 TSRC 「ISRC」フレームは国際標準レコーディングコード [ISRC](12文字)を格納 するためのものである。 4.2.2. 関係者用フレーム TPE1 「主なアーティスト/主な演奏者/ソリスト/演奏グループ」は主なアーティス トを格納するのに用いる。 TPE2 「バンド/オーケストラ/伴奏」フレームはレコーディングを行った演奏者の追 加情報を格納する。 TPE3 「指揮者」フレームは指揮者の名前を格納しておく。 TPE4 「翻訳者, リミックス, その他の修正を行った人物」フレームは、リミックス や既存の何かを翻訳した人々などの追加情報を格納する。 TOPE 「オリジナルのアーティスト/演奏者」フレームは、オリジナルレコーディン グの演奏者を格納するために使用される。これは、たとえばその曲が、以前に リリースされた曲のカヴァー曲だった場合などに使用する。 TEXT 「作詞家/文書作成者」フレームはレコーディングされたものの歌詞や文書の 作成者の名前を格納するためのものである。 TOLY 「オリジナルの作詞家/文書作成者」フレームはオリジナルレコーディングの 文書の作成者を格納するために使用される。これは、たとえばその曲が、以前 にリリースされた曲のカヴァー曲だった場合などに使用する。 TCOM 「作曲者」フレームは作曲者の名前を格納する。 TMCL 「ミュージシャン クレジットリスト」はミュージシャンと、演奏している楽 器を関連付けするために用いられる。奇数番目のフィールドには全て、楽器が 入り、偶数番目のフィールドはアーティスト名が入る。アーティスト名は複数 いるときは、コンマで区切られたリストにする。 TIPL 「かかわった人々の一覧」はミュージシャンクレジットリストと非常によく似 ている。しかし、楽器ではなく、その人の役割、たとえば "プロデューサー" と人名を関連付けるものである。 TENC 「エンコードした人」フレームには、そのオーディオファイルをエンコードし た個人もしくは組織の名前を格納する。オーディオファイルの著作権がエン コードした人にある場合、このフレームには著作権情報が含まれる可能性があ る。 4.2.3. 派生的および主観的なフレーム TBPM 「BPM」フレームには曲の主要部分での一分間の拍数が格納される。BPMは整数 値で、数字文字列として格納される。 TLEN 「長さ」フレームには、オーディオファイルの長さをミリ秒単位で格納する。 数字文字列を使用する。 TKEY 「初めの調」を表すこのフレームは、音楽が始まったときの、最初のキー (調)を格納しておく。このフレームは最大3文字の文字列として表現され る。基本となる調は"A" "B" "C" "D" "E" "F" "G"で表現され、半音 は "b" と "#" で表現する。マイナーの場合は "m" を付ける。たとえば "Dbm" $00 といった具合である。その曲が無調だったばあいは、ただ "o" と 入れればよい。 TLAN 「言語」フレームにはオーディオ中で話されている文章、もしくは歌われてい る歌詞の言語を格納している。言語の種類はISO-639-2 [ISO-639-2] で定義さ れた3文字の文字列であらわされる。文章中で2つ以上の言語が使われている 場合は、言語コードは言語の出現順に並べて記述される。 たとえば、 "eng" $00 "sve" $00 のようになる。 TCON 「内容のタイプ」、これはID3v1では1バイトの数値で格納されていたが、文字 列を使用することができるようになった。このフレームにはID3v1で定義され たジャンルを一つ、または複数格納することができるし、ID3v1のカテゴリリ ストは今後正確に更新していくことが不可能であるため、独自のジャンルを定 義することも可能である。 例:"21" $00 $00 "ユーロディスコ" $00 $00 また、以下のキーワードも使用することができる。 RX リミックス CR カバー TFLT 「ファイルタイプ」フレームはこのタグの付けられたオーディオの形式を示し ている。以下の形式と詳細事項が定義されている。 MIME MIME タイプ 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 Quantisation(TwinVQ) PCM Pulse Code Modulated audio しかし、上記以外の形式も使用可能である。その場合は既に定義されているの と同様に「TMED」中で指定することが出来る。しかし、その中で括弧を使うこ とは出来ない。もしタグ中にこのフレームがなかった場合は、そのファイルの オーディオタイプは「MPG」であるとみなされる。 TMED 「メディアタイプ」は、オーディオファイルの音源がどんなメディアであった かを意味する。このフレームは文字列か、以下のリストで示される定義済みの メディアタイプへの参照が入っている。例:"VID/PAL/VHS" $00 DIG その他のデジタルメディア /A アナログに変換されている ANA その他のアナログメディア /WAC ワックスシリンダ /8CA 8トラックテープカセット CD CD /A アナログに変換されている /DD DDD /AD ADD /AA AAD LD レーザーディスク 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 ビデオ /PAL PAL /NTSC NTSC /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 /I Type 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 カセット(メタル) TMOO 「ムード」フレームは、そのオーディオの雰囲気をいくつかのキーワードで説 明するものである。例:"ロマンチック" "悲しげ" など。 4.2.4. 権利とライセンスのフレーム TCOP 「著作権情報」フレームは年と1文字の空白文字で始まる(これで5文字にな る)。これはオリジナルの音源の著作権保有者(オーディオファイルの、では ない)を示す。このフレームが存在していないということは、著作権情報が公 開されていないか、削除されたことを意味する。その音源がパブリックドメイ ンであることを示すわけではない。このフィールドが表示される場合には、必 ずその前に「Copyright (C) 」という文字列をつけなくてはいけない。 「(c)」は実際にはCを丸で囲った文字1文字で表示される。 TPRO The 'Produced notice' frame, in which the string must begin with a year and a space character (making five characters), is intended for the production copyright holder of the original sound, not the audio file itself. The absence of this frame means only that the production copyright information is unavailable or has been removed, and must not be interpreted to mean that the audio is public domain. Every time this field is displayed the field must be preceded with "Produced " (P) " ", where (P) is one character showing a P in a circle. TPUB The 'Publisher' frame simply contains the name of the label or publisher. TOWN The 'File owner/licensee' frame contains the name of the owner or licensee of the file and it's contents. TRSN The 'Internet radio station name' frame contains the name of the internet radio station from which the audio is streamed. TRSO The 'Internet radio station owner' frame contains the name of the owner of the internet radio station from which the audio is streamed. 4.2.5. Other text frames TOFN The 'Original filename' frame contains the preferred filename for the file, since some media doesn't allow the desired length of the filename. The filename is case sensitive and includes its suffix. TDLY The 'Playlist delay' defines the numbers of milliseconds of silence that should be inserted before this audio. The value zero indicates that this is a part of a multifile audio track that should be played continuously. TDEN The 'Encoding time' frame contains a timestamp describing when the audio was encoded. Timestamp format is described in the ID3v2 structure document [ID3v2-strct]. TDOR The 'Original release time' frame contains a timestamp describing when the original recording of the audio was released. Timestamp format is described in the ID3v2 structure document [ID3v2-strct]. TDRC The 'Recording time' frame contains a timestamp describing when the audio was recorded. Timestamp format is described in the ID3v2 structure document [ID3v2-strct]. TDRL The 'Release time' frame contains a timestamp describing when the audio was first released. Timestamp format is described in the ID3v2 structure document [ID3v2-strct]. TDTG The 'Tagging time' frame contains a timestamp describing then the audio was tagged. Timestamp format is described in the ID3v2 structure document [ID3v2-strct]. TSSE The 'Software/Hardware and settings used for encoding' frame includes the used audio encoder and its settings when the file was encoded. Hardware refers to hardware encoders, not the computer on which a program was run. TSOA The 'Album sort order' frame defines a string which should be used instead of the album name (TALB) for sorting purposes. E.g. an album named "A Soundtrack" might preferably be sorted as "Soundtrack". TSOP The 'Performer sort order' frame defines a string which should be used instead of the performer (TPE2) for sorting purposes. TSOT The 'Title sort order' frame defines a string which should be used instead of the title (TIT2) for sorting purposes. 4.2.6. User defined text information frame This frame is intended for one-string text information concerning the audio file in a similar way to the other "T"-frames. The frame body consists of a description of the string, represented as a terminated string, followed by the actual string. There may be more than one "TXXX" frame in each tag, but only one with the same description.
Text encoding $xx Description $00 (00) Value 4.3. URL link frames With these frames dynamic data such as webpages with touring information, price information or plain ordinary news can be added to the tag. There may only be one URL [URL] link frame of its kind in an tag, except when stated otherwise in the frame description. If the text string is followed by a string termination, all the following information should be ignored and not be displayed. All URL link frame identifiers begins with "W". Only URL link frame identifiers begins with "W", except for "WXXX". All URL link frames have the following format:
URL 4.3.1. URL link frames - details WCOM The 'Commercial information' frame is a URL pointing at a webpage with information such as where the album can be bought. There may be more than one "WCOM" frame in a tag, but not with the same content. WCOP The 'Copyright/Legal information' frame is a URL pointing at a webpage where the terms of use and ownership of the file is described. WOAF The 'Official audio file webpage' frame is a URL pointing at a file specific webpage. WOAR The 'Official artist/performer webpage' frame is a URL pointing at the artists official webpage. There may be more than one "WOAR" frame in a tag if the audio contains more than one performer, but not with the same content. WOAS The 'Official audio source webpage' frame is a URL pointing at the official webpage for the source of the audio file, e.g. a movie. WORS The 'Official Internet radio station homepage' contains a URL pointing at the homepage of the internet radio station. WPAY The 'Payment' frame is a URL pointing at a webpage that will handle the process of paying for this file. WPUB The 'Publishers official webpage' frame is a URL pointing at the official webpage for the publisher. 4.3.2. User defined URL link frame This frame is intended for URL [URL] links concerning the audio file in a similar way to the other "W"-frames. The frame body consists of a description of the string, represented as a terminated string, followed by the actual URL. The URL is always encoded with ISO-8859-1 [ISO-8859-1]. There may be more than one "WXXX" frame in each tag, but only one with the same description.
Text encoding $xx Description $00 (00) URL 4.4. Music CD identifier This frame is intended for music that comes from a CD, so that the CD can be identified in databases such as the CDDB [CDDB]. The frame consists of a binary dump of the Table Of Contents, TOC, from the CD, which is a header of 4 bytes and then 8 bytes/track on the CD plus 8 bytes for the 'lead out', making a maximum of 804 bytes. The offset to the beginning of every track on the CD should be described with a four bytes absolute CD-frame address per track, and not with absolute time. When this frame is used the presence of a valid "TRCK" frame is REQUIRED, even if the CD's only got one track. It is recommended that this frame is always added to tags originating from CDs. There may only be one "MCDI" frame in each tag.
CD TOC 4.5. Event timing codes This frame allows synchronisation with key events in the audio. The header is:
Time stamp format $xx Where time stamp format is: $01 Absolute time, 32 bit sized, using MPEG [MPEG] frames as unit $02 Absolute time, 32 bit sized, using milliseconds as unit Absolute time means that every stamp contains the time from the beginning of the file. Followed by a list of key events in the following format: Type of event $xx Time stamp $xx (xx ...) The 'Time stamp' is set to zero if directly at the beginning of the sound or after the previous event. All events MUST be sorted in chronological order. The type of event is as follows: $00 padding (has no meaning) $01 end of initial silence $02 intro start $03 main part start $04 outro start $05 outro end $06 verse start $07 refrain start $08 interlude start $09 theme start $0A variation start $0B key change $0C time change $0D momentary unwanted noise (Snap, Crackle & Pop) $0E sustained noise $0F sustained noise end $10 intro end $11 main part end $12 verse end $13 refrain end $14 theme end $15 profanity $16 profanity end $17-$DF reserved for future use $E0-$EF not predefined synch 0-F $F0-$FC reserved for future use $FD audio end (start of silence) $FE audio file ends $FF one more byte of events follows (all the following bytes with the value $FF have the same function) Terminating the start events such as "intro start" is OPTIONAL. The 'Not predefined synch's ($E0-EF) are for user events. You might want to synchronise your music to something, like setting off an explosion on-stage, activating a screensaver etc. There may only be one "ETCO" frame in each tag. 4.6. MPEG location lookup table To increase performance and accuracy of jumps within a MPEG [MPEG] audio file, frames with time codes in different locations in the file might be useful. This ID3v2 frame includes references that the software can use to calculate positions in the file. After the frame header follows a descriptor of how much the 'frame counter' should be increased for every reference. If this value is two then the first reference points out the second frame, the 2nd reference the 4th frame, the 3rd reference the 6th frame etc. In a similar way the 'bytes between reference' and 'milliseconds between reference' points out bytes and milliseconds respectively. Each reference consists of two parts; a certain number of bits, as defined in 'bits for bytes deviation', that describes the difference between what is said in 'bytes between reference' and the reality and a certain number of bits, as defined in 'bits for milliseconds deviation', that describes the difference between what is said in 'milliseconds between reference' and the reality. The number of bits in every reference, i.e. 'bits for bytes deviation'+'bits for milliseconds deviation', must be a multiple of four. There may only be one "MLLT" frame in each tag.
MPEG frames between reference $xx xx Bytes between reference $xx xx xx Milliseconds between reference $xx xx xx Bits for bytes deviation $xx Bits for milliseconds dev. $xx Then for every reference the following data is included; Deviation in bytes %xxx.... Deviation in milliseconds %xxx.... 4.7. Synchronised tempo codes For a more accurate description of the tempo of a musical piece, this frame might be used. After the header follows one byte describing which time stamp format should be used. Then follows one or more tempo codes. Each tempo code consists of one tempo part and one time part. The tempo is in BPM described with one or two bytes. If the first byte has the value $FF, one more byte follows, which is added to the first giving a range from 2 - 510 BPM, since $00 and $01 is reserved. $00 is used to describe a beat-free time period, which is not the same as a music-free time period. $01 is used to indicate one single beat-stroke followed by a beat-free period. The tempo descriptor is followed by a time stamp. Every time the tempo in the music changes, a tempo descriptor may indicate this for the player. All tempo descriptors MUST be sorted in chronological order. The first beat-stroke in a time-period is at the same time as the beat description occurs. There may only be one "SYTC" frame in each tag.
Time stamp format $xx Tempo data Where time stamp format is: $01 Absolute time, 32 bit sized, using MPEG [MPEG] frames as unit $02 Absolute time, 32 bit sized, using milliseconds as unit Absolute time means that every stamp contains the time from the beginning of the file. 4.8. Unsynchronised lyrics/text transcription This frame contains the lyrics of the song or a text transcription of other vocal activities. The head includes an encoding descriptor and a content descriptor. The body consists of the actual text. The 'Content descriptor' is a terminated string. If no descriptor is entered, 'Content descriptor' is $00 (00) only. Newline characters are allowed in the text. There may be more than one 'Unsynchronised lyrics/text transcription' frame in each tag, but only one with the same language and content descriptor.
Text encoding $xx Language $xx xx xx Content descriptor $00 (00) Lyrics/text 4.9. Synchronised lyrics/text This is another way of incorporating the words, said or sung lyrics, in the audio file as text, this time, however, in sync with the audio. It might also be used to describing events e.g. occurring on a stage or on the screen in sync with the audio. The header includes a content descriptor, represented with as terminated text string. If no descriptor is entered, 'Content descriptor' is $00 (00) only.
Text encoding $xx Language $xx xx xx Time stamp format $xx Content type $xx Content descriptor $00 (00) Content type: $00 is other $01 is lyrics $02 is text transcription $03 is movement/part name (e.g. "Adagio") $04 is events (e.g. "Don Quijote enters the stage") $05 is chord (e.g. "Bb F Fsus") $06 is trivia/'pop up' information $07 is URLs to webpages $08 is URLs to images Time stamp format: $01 Absolute time, 32 bit sized, using MPEG [MPEG] frames as unit $02 Absolute time, 32 bit sized, using milliseconds as unit Absolute time means that every stamp contains the time from the beginning of the file. The text that follows the frame header differs from that of the unsynchronised lyrics/text transcription in one major way. Each syllable (or whatever size of text is considered to be convenient by the encoder) is a null terminated string followed by a time stamp denoting where in the sound file it belongs. Each sync thus has the following structure: Terminated text to be synced (typically a syllable) Sync identifier (terminator to above string) $00 (00) Time stamp $xx (xx ...) The 'time stamp' is set to zero or the whole sync is omitted if located directly at the beginning of the sound. All time stamps should be sorted in chronological order. The sync can be considered as a validator of the subsequent string. Newline characters are allowed in all "SYLT" frames and MUST be used after every entry (name, event etc.) in a frame with the content type $03 - $04. A few considerations regarding whitespace characters: Whitespace separating words should mark the beginning of a new word, thus occurring in front of the first syllable of a new word. This is also valid for new line characters. A syllable followed by a comma should not be broken apart with a sync (both the syllable and the comma should be before the sync). An example: The "USLT" passage "Strangers in the night" $0A "Exchanging glances" would be "SYLT" encoded as: "Strang" $00 xx xx "ers" $00 xx xx " in" $00 xx xx " the" $00 xx xx " night" $00 xx xx 0A "Ex" $00 xx xx "chang" $00 xx xx "ing" $00 xx xx "glan" $00 xx xx "ces" $00 xx xx There may be more than one "SYLT" frame in each tag, but only one with the same language and content descriptor. 4.10. Comments This frame is intended for any kind of full text information that does not fit in any other frame. It consists of a frame header followed by encoding, language and content descriptors and is ended with the actual comment as a text string. Newline characters are allowed in the comment text string. There may be more than one comment frame in each tag, but only one with the same language and content descriptor.
Text encoding $xx Language $xx xx xx Short content descrip. $00 (00) The actual text 4.11. Relative volume adjustment (2) This is a more subjective frame than the previous ones. It allows the user to say how much he wants to increase/decrease the volume on each channel when the file is played. The purpose is to be able to align all files to a reference volume, so that you don't have to change the volume constantly. This frame may also be used to balance adjust the audio. The volume adjustment is encoded as a fixed point decibel value, 16 bit signed integer representing (adjustment*512), giving +/- 64 dB with a precision of 0.001953125 dB. E.g. +2 dB is stored as $04 00 and -2 dB is $FC 00. There may be more than one "RVA2" frame in each tag, but only one with the same identification string.
Identification $00 The 'identification' string is used to identify the situation and/or device where this adjustment should apply. The following is then repeated for every channel Type of channel $xx Volume adjustment $xx xx Bits representing peak $xx Peak volume $xx (xx ...) Type of channel: $00 Other $01 Master volume $02 Front right $03 Front left $04 Back right $05 Back left $06 Front centre $07 Back centre $08 Subwoofer Bits representing peak can be any number between 0 and 255. 0 means that there is no peak volume field. The peak volume field is always padded to whole bytes, setting the most significant bits to zero. 4.12. Equalisation (2) This is another subjective, alignment frame. It allows the user to predefine an equalisation curve within the audio file. There may be more than one "EQU2" frame in each tag, but only one with the same identification string.
Interpolation method $xx Identification $00 The 'interpolation method' describes which method is preferred when an interpolation between the adjustment point that follows. The following methods are currently defined: $00 Band No interpolation is made. A jump from one adjustment level to another occurs in the middle between two adjustment points. $01 Linear Interpolation between adjustment points is linear. The 'identification' string is used to identify the situation and/or device where this adjustment should apply. The following is then repeated for every adjustment point Frequency $xx xx Volume adjustment $xx xx The frequency is stored in units of 1/2 Hz, giving it a range from 0 to 32767 Hz. The volume adjustment is encoded as a fixed point decibel value, 16 bit signed integer representing (adjustment*512), giving +/- 64 dB with a precision of 0.001953125 dB. E.g. +2 dB is stored as $04 00 and -2 dB is $FC 00. Adjustment points should be ordered by frequency and one frequency should only be described once in the frame. 4.13. Reverb Yet another subjective frame, with which you can adjust echoes of different kinds. Reverb left/right is the delay between every bounce in ms. Reverb bounces left/right is the number of bounces that should be made. $FF equals an infinite number of bounces. Feedback is the amount of volume that should be returned to the next echo bounce. $00 is 0%, $FF is 100%. If this value were $7F, there would be 50% volume reduction on the first bounce, 50% of that on the second and so on. Left to left means the sound from the left bounce to be played in the left speaker, while left to right means sound from the left bounce to be played in the right speaker. 'Premix left to right' is the amount of left sound to be mixed in the right before any reverb is applied, where $00 id 0% and $FF is 100%. 'Premix right to left' does the same thing, but right to left. Setting both premix to $FF would result in a mono output (if the reverb is applied symmetric). There may only be one "RVRB" frame in each tag.
Reverb left (ms) $xx xx Reverb right (ms) $xx xx Reverb bounces, left $xx Reverb bounces, right $xx Reverb feedback, left to left $xx Reverb feedback, left to right $xx Reverb feedback, right to right $xx Reverb feedback, right to left $xx Premix left to right $xx Premix right to left $xx 4.14. Attached picture This frame contains a picture directly related to the audio file. Image format is the MIME type and subtype [MIME] for the image. In the event that the MIME media type name is omitted, "image/" will be implied. The "image/png" [PNG] or "image/jpeg" [JFIF] picture format should be used when interoperability is wanted. Description is a short description of the picture, represented as a terminated text string. There may be several pictures attached to one file, each in their individual "APIC" frame, but only one with the same content descriptor. There may only be one picture with the picture type declared as picture type $01 and $02 respectively. There is the possibility to put only a link to the image file by using the 'MIME type' "-->" and having a complete URL [URL] instead of picture data. The use of linked files should however be used sparingly since there is the risk of separation of files.
Text encoding $xx MIME type $00 Picture type $xx Description $00 (00) Picture data Picture type: $00 Other $01 32x32 pixels 'file icon' (PNG only) $02 Other file icon $03 Cover (front) $04 Cover (back) $05 Leaflet page $06 Media (e.g. label side of CD) $07 Lead artist/lead performer/soloist $08 Artist/performer $09 Conductor $0A Band/Orchestra $0B Composer $0C Lyricist/text writer $0D Recording Location $0E During recording $0F During performance $10 Movie/video screen capture $11 A bright coloured fish $12 Illustration $13 Band/artist logotype $14 Publisher/Studio logotype 4.15. General encapsulated object In this frame any type of file can be encapsulated. After the header, 'Frame size' and 'Encoding' follows 'MIME type' [MIME] represented as as a terminated string encoded with ISO 8859-1 [ISO-8859-1]. The filename is case sensitive and is encoded as 'Encoding'. Then follows a content description as terminated string, encoded as 'Encoding'. The last thing in the frame is the actual object. The first two strings may be omitted, leaving only their terminations. MIME type is always an ISO-8859-1 text string. There may be more than one "GEOB" frame in each tag, but only one with the same content descriptor.
Text encoding $xx MIME type $00 Filename $00 (00) Content description $00 (00) Encapsulated object 4.16. Play counter This is simply a counter of the number of times a file has been played. The value is increased by one every time the file begins to play. There may only be one "PCNT" frame in each tag. When the counter reaches all one's, one byte is inserted in front of the counter thus making the counter eight bits bigger. The counter must be at least 32-bits long to begin with.
Counter $xx xx xx xx (xx ...) 4.17. Popularimeter The purpose of this frame is to specify how good an audio file is. Many interesting applications could be found to this frame such as a playlist that features better audio files more often than others or it could be used to profile a person's taste and find other 'good' files by comparing people's profiles. The frame contains the email address to the user, one rating byte and a four byte play counter, intended to be increased with one for every time the file is played. The email is a terminated string. The rating is 1-255 where 1 is worst and 255 is best. 0 is unknown. If no personal counter is wanted it may be omitted. When the counter reaches all one's, one byte is inserted in front of the counter thus making the counter eight bits bigger in the same away as the play counter ("PCNT"). There may be more than one "POPM" frame in each tag, but only one with the same email address.
Email to user $00 Rating $xx Counter $xx xx xx xx (xx ...) 4.18. Recommended buffer size Sometimes the server from which an audio file is streamed is aware of transmission or coding problems resulting in interruptions in the audio stream. In these cases, the size of the buffer can be recommended by the server using this frame. If the 'embedded info flag' is true (1) then this indicates that an ID3 tag with the maximum size described in 'Buffer size' may occur in the audio stream. In such case the tag should reside between two MPEG [MPEG] frames, if the audio is MPEG encoded. If the position of the next tag is known, 'offset to next tag' may be used. The offset is calculated from the end of tag in which this frame resides to the first byte of the header in the next. This field may be omitted. Embedded tags are generally not recommended since this could render unpredictable behaviour from present software/hardware. For applications like streaming audio it might be an idea to embed tags into the audio stream though. If the clients connects to individual connections like HTTP and there is a possibility to begin every transmission with a tag, then this tag should include a 'recommended buffer size' frame. If the client is connected to a arbitrary point in the stream, such as radio or multicast, then the 'recommended buffer size' frame SHOULD be included in every tag. The 'Buffer size' should be kept to a minimum. There may only be one "RBUF" frame in each tag.
Buffer size $xx xx xx Embedded info flag %0000000x Offset to next tag $xx xx xx xx 4.19. Audio encryption This frame indicates if the actual audio stream is encrypted, and by whom. Since standardisation of such encryption scheme is beyond this document, all "AENC" frames begin with a terminated string with a URL containing an email address, or a link to a location where an email address can be found, that belongs to the organisation responsible for this specific encrypted audio file. Questions regarding the encrypted audio should be sent to the email address specified. If a $00 is found directly after the 'Frame size' and the audio file indeed is encrypted, the whole file may be considered useless. After the 'Owner identifier', a pointer to an unencrypted part of the audio can be specified. The 'Preview start' and 'Preview length' is described in frames. If no part is unencrypted, these fields should be left zeroed. After the 'preview length' field follows optionally a data block required for decryption of the audio. There may be more than one "AENC" frames in a tag, but only one with the same 'Owner identifier'.
Owner identifier $00 Preview start $xx xx Preview length $xx xx Encryption info 4.20. Linked information To keep information duplication as low as possible this frame may be used to link information from another ID3v2 tag that might reside in another audio file or alone in a binary file. It is RECOMMENDED that this method is only used when the files are stored on a CD-ROM or other circumstances when the risk of file separation is low. The frame contains a frame identifier, which is the frame that should be linked into this tag, a URL [URL] field, where a reference to the file where the frame is given, and additional ID data, if needed. Data should be retrieved from the first tag found in the file to which this link points. There may be more than one "LINK" frame in a tag, but only one with the same contents. A linked frame is to be considered as part of the tag and has the same restrictions as if it was a physical part of the tag (i.e. only one "RVRB" frame allowed, whether it's linked or not).
Frame identifier $xx xx xx xx URL $00 ID and additional data Frames that may be linked and need no additional data are "ASPI", "ETCO", "EQU2", "MCID", "MLLT", "OWNE", "RVA2", "RVRB", "SYTC", the text information frames and the URL link frames. The "AENC", "APIC", "GEOB" and "TXXX" frames may be linked with the content descriptor as additional ID data. The "USER" frame may be linked with the language field as additional ID data. The "PRIV" frame may be linked with the owner identifier as additional ID data. The "COMM", "SYLT" and "USLT" frames may be linked with three bytes of language descriptor directly followed by a content descriptor as additional ID data. 4.21. Position synchronisation frame This frame delivers information to the listener of how far into the audio stream he picked up; in effect, it states the time offset from the first frame in the stream. The frame layout is: Time stamp format $xx Position $xx (xx ...) Where time stamp format is: $01 Absolute time, 32 bit sized, using MPEG frames as unit $02 Absolute time, 32 bit sized, using milliseconds as unit and position is where in the audio the listener starts to receive, i.e. the beginning of the next frame. If this frame is used in the beginning of a file the value is always 0. There may only be one "POSS" frame in each tag. 4.22. Terms of use frame This frame contains a brief description of the terms of use and ownership of the file. More detailed information concerning the legal terms might be available through the "WCOP" frame. Newlines are allowed in the text. There may be more than one 'Terms of use' frame in a tag, but only one with the same 'Language'.
Text encoding $xx Language $xx xx xx The actual text 4.23. Ownership frame The ownership frame might be used as a reminder of a made transaction or, if signed, as proof. Note that the "USER" and "TOWN" frames are good to use in conjunction with this one. The frame begins, after the frame ID, size and encoding fields, with a 'price paid' field. The first three characters of this field contains the currency used for the transaction, encoded according to ISO 4217 [ISO-4217] alphabetic currency code. Concatenated to this is the actual price paid, as a numerical string using "." as the decimal separator. Next is an 8 character date string (YYYYMMDD) followed by a string with the name of the seller as the last field in the frame. There may only be one "OWNE" frame in a tag.
Text encoding $xx Price paid $00 Date of purch. Seller 4.24. Commercial frame This frame enables several competing offers in the same tag by bundling all needed information. That makes this frame rather complex but it's an easier solution than if one tries to achieve the same result with several frames. The frame begins, after the frame ID, size and encoding fields, with a price string field. A price is constructed by one three character currency code, encoded according to ISO 4217 [ISO-4217] alphabetic currency code, followed by a numerical value where "." is used as decimal separator. In the price string several prices may be concatenated, separated by a "/" character, but there may only be one currency of each type. The price string is followed by an 8 character date string in the format YYYYMMDD, describing for how long the price is valid. After that is a contact URL, with which the user can contact the seller, followed by a one byte 'received as' field. It describes how the audio is delivered when bought according to the following list: $00 Other $01 Standard CD album with other songs $02 Compressed audio on CD $03 File over the Internet $04 Stream over the Internet $05 As note sheets $06 As note sheets in a book with other sheets $07 Music on other media $08 Non-musical merchandise Next follows a terminated string with the name of the seller followed by a terminated string with a short description of the product. The last thing is the ability to include a company logotype. The first of them is the 'Picture MIME type' field containing information about which picture format is used. In the event that the MIME media type name is omitted, "image/" will be implied. Currently only "image/png" and "image/jpeg" are allowed. This format string is followed by the binary picture data. This two last fields may be omitted if no picture is attached. There may be more than one 'commercial frame' in a tag, but no two may be identical.
Text encoding $xx Price string $00 Valid until Contact URL $00 Received as $xx Name of seller $00 (00) Description $00 (00) Picture MIME type $00 Seller logo 4.25. Encryption method registration To identify with which method a frame has been encrypted the encryption method must be registered in the tag with this frame. The 'Owner identifier' is a null-terminated string with a URL [URL] containing an email address, or a link to a location where an email address can be found, that belongs to the organisation responsible for this specific encryption method. Questions regarding the encryption method should be sent to the indicated email address. The 'Method symbol' contains a value that is associated with this method throughout the whole tag, in the range $80-F0. All other values are reserved. The 'Method symbol' may optionally be followed by encryption specific data. There may be several "ENCR" frames in a tag but only one containing the same symbol and only one containing the same owner identifier. The method must be used somewhere in the tag. See the description of the frame encryption flag in the ID3v2 structure document [ID3v2-strct] for more information.
Owner identifier $00 Method symbol $xx Encryption data 4.26. Group identification registration This frame enables grouping of otherwise unrelated frames. This can be used when some frames are to be signed. To identify which frames belongs to a set of frames a group identifier must be registered in the tag with this frame. The 'Owner identifier' is a null-terminated string with a URL [URL] containing an email address, or a link to a location where an email address can be found, that belongs to the organisation responsible for this grouping. Questions regarding the grouping should be sent to the indicated email address. The 'Group symbol' contains a value that associates the frame with this group throughout the whole tag, in the range $80-F0. All other values are reserved. The 'Group symbol' may optionally be followed by some group specific data, e.g. a digital signature. There may be several "GRID" frames in a tag but only one containing the same symbol and only one containing the same owner identifier. The group symbol must be used somewhere in the tag. See the description of the frame grouping flag in the ID3v2 structure document [ID3v2-strct] for more information.
Owner identifier $00 Group symbol $xx Group dependent data 4.27. Private frame This frame is used to contain information from a software producer that its program uses and does not fit into the other frames. The frame consists of an 'Owner identifier' string and the binary data. The 'Owner identifier' is a null-terminated string with a URL [URL] containing an email address, or a link to a location where an email address can be found, that belongs to the organisation responsible for the frame. Questions regarding the frame should be sent to the indicated email address. The tag may contain more than one "PRIV" frame but only with different contents.
Owner identifier $00 The private data 4.28. 署名フレーム This frame enables a group of frames, grouped with the 'Group identification registration', to be signed. Although signatures can reside inside the registration frame, it might be desired to store the signature elsewhere, e.g. in watermarks. There may be more than one 'signature frame' in a tag, but no two may be identical. <「署名フレーム」のヘッダ, ID: "SIGN"> グループシンボル $xx 署名 <バイナリデータ> 4.29. シークフレーム このフレームは、同じファイル/ストリーム中にある別のタグが、どこに位置 しているのかを示すためのものである。「次のタグへの最小オフセット値」は このフレームが含まれるタグの終わりと、次のタグの始まりの間の距離を算出 した値である。ひとつのタグ中に、シークフレームは一つしか含めることが出 来ない。 <「シークフレーム」のヘッダ, ID: "SEEK"> 次のタグへの最小オフセット値 $xx xx xx xx 4.30. オーディオシークポイントインデックス Audio files with variable bit rates are intrinsically difficult to deal with in the case of seeking within the file. The ASPI frame makes seeking easier by providing a list a seek points within the audio file. The seek points are a fractional offset within the audio data, providing a starting point from which to find an appropriate point to start decoding. The presence of an ASPI frame requires the existence of a TLEN frame, indicating the duration of the file in milliseconds. There may only be one 'audio seek point index' frame in a tag.
Indexed data start (S) $xx xx xx xx Indexed data length (L) $xx xx xx xx Number of index points (N) $xx xx Bits per index point (b) $xx Then for every index point the following data is included; Fraction at index (Fi) $xx (xx) 'Indexed data start' is a byte offset from the beginning of the file. 'Indexed data length' is the byte length of the audio data being indexed. 'Number of index points' is the number of index points, as the name implies. The recommended number is 100. 'Bits per index point' is 8 or 16, depending on the chosen precision. 8 bits works well for short files (less than 5 minutes of audio), while 16 bits is advantageous for long files. 'Fraction at index' is the numerator of the fraction representing a relative position in the data. The denominator is 2 to the power of b. Here are the algorithms to be used in the calculation. The known data must be the offset of the start of the indexed data (S), the offset of the end of the indexed data (E), the number of index points (N), the offset at index i (Oi). We calculate the fraction at index i (Fi). Oi is the offset of the frame whose start is soonest after the point for which the time offset is (i/N * duration). The frame data should be calculated as follows: Fi = Oi/L * 2^b (rounded down to the nearest integer) Offset calculation should be calculated as follows from data in the frame: Oi = (Fi/2^b)*L (rounded up to the nearest integer) 5. Copyright Copyright (C) Martin Nilsson 2000. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that a reference to this document is included on all such copies and derivative works. However, this document itself may not be modified in any way and reissued as the original document. The limited permissions granted above are perpetual and will not be revoked. This document and the information contained herein is provided on an "AS IS" basis and THE AUTHORS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 6. References [CDDB] Compact Disc Data Base [ID3v2.3.0] Martin Nilsson, "ID3v2 informal standard". [ID3v2-strct] Martin Nilsson, "ID3 tag version 2.4.0 - Main Structure" [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 [KEYWORDS] S. Bradner, 'Key words for use in RFCs to Indicate Requirement Levels', RFC 2119, March 1997. [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [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] T. Berners-Lee, L. Masinter & M. McCahill, "Uniform Resource Locators (URL).", RFC 1738, December 1994. [ZLIB] P. Deutsch, Aladdin Enterprises & J-L. Gailly, "ZLIB Compressed Data Format Specification version 3.3", RFC 1950, May 1996. 7. Appendix A. Appendix A - Genre List from ID3v1 The following genres is defined in ID3v1 0.Blues 1.Classic Rock 2.Country 3.Dance 4.Disco 5.Funk 6.Grunge 7.Hip-Hop 8.Jazz 9.Metal 10.New Age 11.Oldies 12.Other 13.Pop 14.R&B 15.Rap 16.Reggae 17.Rock 18.Techno 19.Industrial 20.Alternative 21.Ska 22.Death Metal 23.Pranks 24.Soundtrack 25.Euro-Techno 26.Ambient 27.Trip-Hop 28.Vocal 29.Jazz+Funk 30.Fusion 31.Trance 32.Classical 33.Instrumental 34.Acid 35.House 36.Game 37.Sound Clip 38.Gospel 39.Noise 40.AlternRock 41.Bass 42.Soul 43.Punk 44.Space 45.Meditative 46.Instrumental Pop 47.Instrumental Rock 48.Ethnic 49.Gothic 50.Darkwave 51.Techno-Industrial 52.Electronic 53.Pop-Folk 54.Eurodance 55.Dream 56.Southern Rock 57.Comedy 58.Cult 59.Gangsta 60.Top 40 61.Christian Rap 62.Pop/Funk 63.Jungle 64.Native American 65.Cabaret 66.New Wave 67.Psychadelic 68.Rave 69.Showtunes 70.Trailer 71.Lo-Fi 72.Tribal 73.Acid Punk 74.Acid Jazz 75.Polka 76.Retro 77.Musical 78.Rock & Roll 79.Hard Rock 8. Author's Address Written by Martin Nilsson Rydsv臠en 246 C. 30 SE-584 34 Linkping Sweden Email: nilsson@id3.org