更新Tweetmp3ファイルに、曲タイトルやアーティスト名などの付加情報を記録するためのメタデータ規格の一つ。拡張ヘッダーフレーム2.22.3フレームID文字列MPEGフレームID3v1概要ID3と名が付いているが、それまで使われていたID3とは全く異なる仕様である。元々のID3(以降、ID3v1とする)はファイルの末尾に128バイト固定長の構造体を付加しただけであったが、ID3v2はファイルの先頭にチャンク形式のデータを付加している。このためID3v1とは異なり、対応プレイヤーでなければ肝心の音楽データを再生することすらできないが、現在のプレーヤーの殆どはID3v2に対応している。特徴バージョン現在までに登場したID3v2のバージョンは、次のとおりである。バージョン4.0)なお、ID3v2.2と、ID3v2.3/ID3v2.4の間には、何一つ互換性がない。その上、ID3v2.3とID3v2.4の間にさえ、非互換な仕様差がある。仕様書において、バージョン間の互換性は保証されない旨記載があり、このように後方互換を一切考慮していないため、新バージョンが登場するたびに新規に対応する必要が生じる。バージョンの考え方は、ID3v2のバージョン2や3や4であって、ID3のバージョン2.2や2.3や2.4などではない、とする論説もある。2.4」という記述があるため、以前は不明だが、現在ではID3のバージョン2.3などと考えても差し支えはないと思われる。ID3v2.4にも対応したようである。iTunesは以前はID3v2.2、現在はID3v2.4に対応しているようである。機能ID3v1の問題だった文字数の制限を撤廃し、更に様々な情報の付加を可能とした。Unicodeに対応し、画像や歌詞情報などの格納も可能となっている。MP3)というものもある。rmpはRIFF形式にした仕様だったが、デジュリスタンダードを目指したID3v2には普及数では勝てず、対応するソフトウェアはあまり存在しない。日本製のソフトウェアでは、双方に対応するものもある。ID3v1とIDv2、あるいはID3v1とrmpは共存できるが、ID3v2とrmpは共存できない。構造ID3v1のメタデータは末尾だったが、ID3v2は先頭に情報が付加される。全体として、概ね次の順序でデータは格納される。以降、ID3v2ヘッダー内の数値は全てビッグエンディアンである。各バイトの最上位ビットは無効で、4×7ビットで計28ビットとなる)サイズの表現が特殊で、synchsafe整数値である。万が一8ビットを通さない処理系に入ったとしても安全なように配慮したためと思われる。フラグの機能は次の通り。0ID3v2サイズは、ID3v2ヘッダーのサイズを除く、それ以降の全体長を表わす。拡張ヘッダーID3v2ヘッダー内フラグのビット6=1の場合、拡張ヘッダーが存在する。パディング領域のサイズ(4バイト)サイズは、ID3v2.3では普通の整数だが、ID3v2.4ではsynchsafe整数であり互換性がない。拡張フラグの機能は次の通り。(未定義)ビット15=1の場合、この後にCRC-32データ4バイトが付加される。フレームID3v2では、各データはフレームと呼ばれるチャンク形式で格納される。2.2と2.3以降で互換性がない。[24ビット整数]サイズは、実データサイズのみで、フレームヘッダー長は含まない。フレームデータ(可変長)フレームIDはASCIIで大文字のA‐Zと0‐9の文字を用いて命名する。先頭の文字がX/Y/Zは、特殊な用途に使う。サイズは、実データサイズのみで、フレームヘッダー長は含まない。ID3v2.3では普通の整数だが、ID3v2.4ではsynchsafe整数であり互換性がない。フレームIDよく使われるフレームIDは次の通り。ID3v2.2は3バイト、ID3v2.3(ID3v2.4も同じ)は4バイトである。以下、ID3v2.3とID3v2.4の仕様書に存在する全てのフレームIDである(ABC順)。ID3v2.4で削除されたものを表わす。frame文字列フレームのうち、文字列を格納するものは、最初の1バイトでエンコーディングを指定する。文字、ID3v2.4で対応)このバイトに続いて実際の文字列が格納される。各符号におけるNUL末端で終端できるが、フレームヘッダーで長さは明確なので、NULは書かなくてもよい。してシフトJISを格納するものが多く見られたが、これはフォーマット違反である。MPEGフレームID3v2の直後に、実際のMPEGフレームが続く。ID3v1ID3v2とID3v1は併用可能なため、必要に応じて末尾にID3v1を付けることもできる。参加の案内ダウンロード↑本の。