2

ID3 v2.3.0 でフレーム サイズ バイトをどのようにコーディング/デコードするかについて、いくつかの混乱があります。(非公式の) ID3 v2.3.0 仕様によると、各フレームのサイズは 4 バイトにコード化する必要があり、各バイトの最上位ビットは未使用です。サイズを計算するには、次の式を使用します。

byte MASK = (byte)0x7F;

int size = 0;

for (int = 0; i < 4; i++) {
   size = size * 128 + (b[i] & MASK);
}

しかし、パーサーを使用していくつかの MP3 ファイルを解析したところ、かなりの数のファイルに GEOB (一般的なカプセル化されたオブジェクト タグ) フレームがあり、そのサイズのバイトはあたかもビッグ エンディアンの 32 ビット整数であるかのようにコード化されていました。

適切なアルゴリズムを使用して再コーディングしてこれらのバイトを修正した後、Windows 7 や Winamp などの商用ソフトウェアは、後続のタグを適切に表示できませんでした (いくつかの例では、TIT2 は GEOB の直後だったので、曲のタイトルは表示されませんでしたが、ファイルにありました）。

MCDI (音楽 CD 識別子) と TALB ('Album/Movie/Show title') タグにも同様の問題が見つかりました。

v2.3 仕様を読み、Google も検索しましたが、これらのフレームのサイズ メタデータとして 32 ビット整数を使用することに関する情報を見つけることができませんでした。しかし、さまざまな商用ソフトウェアの一般的な動作は、そのようなフィールドに対して、0x7F でマスクされた 4 バイトではなく、32 ビット整数をサイズとして使用する必要があることを示唆しているようです。

ですから、ID3 v2.3 に取り組んでいて、これを明確にしてくれる人がここにいるかどうか疑問に思っています。

4

2 に答える 2

1

私は答えを見つけたと信じています。ID3 v2.3 は、(v2.4 とは対照的に) より一般的にサポートされているにもかかわらず、適切に記述された (非公式な) 仕様ではありません。そのヘッダー サイズは 4 0x7F バイトを使用しますが、フレーム サイズは実際には 32 ビット整数であり、明確に綴られることはありません。

私が GEOB を扱うときに通常問題に遭遇する理由は、フレーム サイズが 0x7F よりも大きくなるまで問題が発生しないためです。通常、GEOB はそうです。

于 2013-01-07T13:43:56.137 に答える