Melog

MP3のタグ(ID3 tag)は、拡張に拡張を重ねて妙に混沌としてるので、自分でMP3ファイルを作る場合、設定をどう統一するのが一番いいのかがよく分からないので、困ってしまう。
設定とはこの場合、「バージョン (ID3 Version)」、「文字エンコード (Encode)」、「非同期化 (Unsync)」の3つ。
そこで、ちょっと考えてみたので、そのまとめ。

バージョン

1.0/1.1と2.2/2.3/2.4がある。1.xと2.xは併用できる。
1.xは1.1を使えばいいと思うけど、2.xの場合、2.4は仕様が柔軟だけど、その分色々と問題を孕んでいるらしく、サポートされてなかったり、サポートが杜撰だったりするプレイヤーもあり(Windows Media Playerも未対応)、互換性の面で問題があると聞く。例えば、画像を埋め込んだりするような使い方をしない限り、2.3で事足りる。2.2でもいいのかもしれない。でも、違いがよく分かりません(笑)。タグエディタのmp3infpやSTEPのデフォルトが2.3なので、とりあえず2.3で。

文字エンコード

ISO-8859-1、またはUTF-16。2.4ならUTF-8が使えるらしいけど、そもそも2.4を使わないので置いておく。日本での下位互換性を考えるとISO-8859-1。ただし、この場合日本語環境専用のタグになってしまい、海外のプレイヤーは対応してない場合がほとんど。UTF-16なら、UTF-16(Unicode)をサポートしたプレイヤーなら表示できるはず。そんなわけで、今後長く使おうと思うなら、UTF-16に統一した方が望ましいと考えられる。ただし、日本のプレイヤーの中には逆にUTF-16に対応してない物もそれなりにあるので、注意が必要。最近のは結構対応してるみたいだけどね。

非同期化

非同期化というのは、ID3タグのバージョンが1.xしか対応してないプレイヤーに対して、ID3タグ2.xを無視させるようにする処理の事。
これは、ファイルの中の音声ファイルの開始箇所を示す特定のパターンが、タグの中に出現しないように、本来の2.xタグのデータに対し加工を施す処理。こうする事で、1.xしか対応してないプレイヤーがタグを音声データと誤認識しないように誤魔化す。
iTunesが対応してなかったりするので、ID3タグ1.xにしか対応してないようなプレイヤーを使わないのであれば、非同期化をオフにした方がいいのかも。逆に、2.x対応で非同期化にしか対応してないプレイヤーってのは多分無いと思うし。
仮にタグの文字コードがISO-8859-1なら、普通に日本語を入力している限りは多分、問題となるような箇所は出現しないと思う（いや、きちんと調べたわけじゃないけど…）けど、UTF-16だと問題が起こる。
最近のプレイヤーはどれも2.xタグに対応してるから、iTunesのような非同期化に非対応のプレイヤーの存在を考慮すると、非同期化はオフにした方が安全なのかもしれない。
あ、でももしかしたら最近のiTunesは非同期化に対応してたりするのかな。

以上な感じ。
そんなわけで、自分の場合は以下のようになる。

バージョン：2.3
文字エンコード：UTF-16
非同期化：しない

ちなみに自分の場合、1.xタグは文字数制限があり、内容が中途半端になるので全部削除するようにしている。非同期化もしないので、結果として1.xタグにしか対応してないプレイヤーを一切無視している事になる。

以下は、タグエディタの設定を示した図。

STEP

[オプション] → [プラグイン] → SETP_mp3に合わせて[設定] → [その他]タブ

mp3infp

参考

にゃおでぃお – 日記 : Windows Media Player 10の ID3v2.4 対応について by nyaochi
mp3infp説明書
ID3 TagFormat
iTunesあるいはSoundJAMのID3タグにおける日本語の扱いの混乱について

追記

れにしても、MP3のタグの仕様ってのはどうしてこう、酷く歪になってるのかね…。
最近の、WMAとかOgg VorbisとかAACとかは、やはり後出しだけあってこういう問題とは無縁なんだけど。

さらに追記。こんなの見つけた。

製品情報 – H300シリーズ – iriver Japan

非同期化を行っていないID3v2.3のみタグ情報の取得に失敗した

非同期化しないのも安全じゃないのか。
…と思ったけど、でもこれ、2.2や2.4で問題ないみたいだら、ただの固有のバグっぽいので、あまり関係ないかも。2008-05-10 追記：コメントより、この問題はファームアップにより改善されるそうです。

10:42追記

もう少し技術的な話。
非同期化で問題になるのは、”0xFF 0xF*”あるいは”0xFF 0xE*”というバイト列。
ID3タグの文字エンコードにUTF-16を用いると、各タグの文字の先頭にBOM(=Byte Order Mark)という2バイトが付加される。ID3タグに用いられるUTF-16は普通、リトルエンディアンのようなので（mp3infpやSTEPも、リトルエンディアンのUTF-16を吐き出す）、BOMは”0xFF 0xFE”となる。このバイト列は、まさに非同期化問題に引っかかる。
また、仮にタグがビッグエンディアンだとした場合、BOMは”0xFE 0xFF”だけど、その後にコードが”0xF*”または”0xE*”で始まる文字全角の数字、英字、記号、または半角カナなど、かなり該当する。参考：Unicode一覧 F000-FFFF – Wikipedia）が来た場合、問題のバイト列が現れるので、同様の問題が起こる。また、全角の「￥（コードは”0xFF 0xF5″）」など、いくつか単体で問題が起こる文字もある。
これらに該当するmp3の場合、非同期化を行わずv2.xタグに対応してないプレイヤーで再生すると、該当箇所以降のタグの中身を音声と認識するため、その部分にノイズが乗るか、デコードできずに読み込めなくなる。
そんなわけで、非同期化を行わずに文字エンコードにUTF-16を使用した場合、v2.xタグに対応してないプレイヤーでそのmp3を再生すると、かなり問題を起こしやすい。

しかしこうしてみると、ID3タグというのは本当に継ぎ接ぎだらけだなぁ。色々と取り込もうとあれこれ塗り固めた結果、仕様が酷い事になっている様子がうかがえる。文字コードがUTF-16とUTF-8の両方使える事に、何か意味はあるのだろうか。