TVersityで文字化けが起きる理由がわかった。
…。
TVersityで特定の状況で文字化けが起きていたファイルのバイナリで見てみると、ID3タグの文字コードはUTF-8/16のはずなのにShift-JIS認識で日本語アーティスト名が読める部分があることに気づいた。
…。
調べてみるとそれは「TPE2」という領域で、下の仕様書によると『「バンド/オーケストラ/伴奏」フレームはレコーディングを行った演奏者の追加情報を格納する。』となっている。
「ID3v2 - Informal standard（ http://www1.cds.ne.jp/~takaaki/ID3/ID3v2.3.0J.html ）」
ちなみに、TPE1（「主なアーティスト/主な演奏者/ソリスト/演奏グループ」は主なアーティストを格納するのに用いる。複数いる場合は「/」で区切る。 ）という領域があり、通常はこちらだけ書いてあれば良く、編集に使っているSTEPではTPE1領域のみに対応しており、TPE2領域は処理できない。TPE2領域を無視するのは日本製のMP3ソフトの基本的な挙動らしい。
しかし、TVersityの方は内部のリストを作成するときにTPE1とTPE2の両方に記述がある場合、TPE2を優先して利用するようだ。コンピレーションやクラシックなどの管理を考えたときには有益な仕様だとは思うが、今回は見事にはまってしまった。
…。
まとめると、文字化けしていたファイルはSTEPで編集する前に何らかのカタチでShift-JISでTTE2領域にアーティスト名が書き込まれてしまい、STEPはShift-JISのTTE2領域を無視してその他の部分のみUnicodeに変換、TVersityはShift-JISで書かれたままのTTE2領域を優先して読み込んだ、ということ。
ややこしい話だが、TTE2領域にUnicodeでアーティスト名を書き込む、TTE2領域を削除する、のどちらかを行えば文字化けは解消される可能性が高い。
…。
原因はわかったのだが、どうやって弄ろうか…。
…。
STEPを使い、TPE2にあたるタグがなく文字数制限のないRIFF MP3形式に一回変換してID3v2に戻す、ってのはどうだろう。ID3v1は文字数の制限があるため変換すると一部情報が消えてしまうが、RIFF MP3なら文字数の制限はなく、僕が必要な情報が消えることはないはず。
ちょっと怖いのでバックアップは取っておきたいが、試してみる価値はありそうだ。
＜追記＞
一応「その３」と「その４」あたりが解決編になってますので、検索で来た方はそちらを読んでみてください。
その１（ http://d.hatena.ne.jp/saburahu/20071104/1194190268 ）
その２（ http://d.hatena.ne.jp/saburahu/20071105/1194276427 ）
その３（ http://d.hatena.ne.jp/saburahu/20071106/1194365038 ）
その４（ http://d.hatena.ne.jp/saburahu/20071108/1194531185 ）
