私は最近ID3v2.4.0で作業しています。 2.4.0のドキュメントを読んで、私が理解できない特定の部分、同期安全な整数が見つかりました。 ID3v2でこの方法が使用されるのはなぜですか？なぜシンクセーフな整数ですか？
もちろん、私はID3v2がMPEG同期データとしてID3タグを考慮しないようにするために使用される非同期スキームを使用する理由を知っています。 しかし、私が理解できなかったのは、非同期化スキーム（= $ 00を挿入する）ではなく、同期可能な整数なのです。
$ 00を挿入するのではなくタグサイズを表現するときに、同期安全な整数を採用する理由はありますか？ これらの2つの方法は全く同じ効果をもたらします。
ID3v2ドキュメントでは、同期されていないデータのサイズは事前にわかっていません。 しかし、この文は意味をなさない。 タグデータがバッファに格納されている場合、問題のある文字を$ FF 00に置き換えた後、非同期データのサイズを知ることができます。
私を助けることができる人はいますか？
私はシンプルさを前提にしていますが、非同期/同期方式はmpegファイルで使用すると意味があります。
4つのバイトを読み込み、通常の整数に変換するために簡単です：
// pseudo code
uint32_t size;
file.read(&size, sizeof(uint32_t));
size = (size & 0x0000007F) |
((size & 0x00007F00) >> 1) |
((size & 0x007F0000) >> 2) |
((size & 0x7F000000) >> 3);
彼らはフレームデータと同じunsynchスキームを使用した場合、あなたが探して、個別に各バイトを読み取るために必要があるだろうFF00パターンに変換し、バイト単位で整数を再構成する。また、ヘッダの 'size'フィールドが可変バイト数である場合、非同期バイトが挿入されるため、ヘッダ全体が可変バイト数になります。 'というヘッダーは常に10バイトのサイズで、これは...'と言っても簡単です。
ID3v2ドキュメントでは、同期化されていないデータのサイズは事前にわかっていません。しかし、その声明は意味をなさない。タグデータがバッファに格納されている場合は、問題のある文字を$ FF 00に置き換えただけで、非同期データのサイズを知ることができます。
正しいですが、意味がありません。 id3v2ヘッダーとフレームヘッダーに書かれたサイズは、の非同期化が適用された後のサイズです。しかし、unsync/synchの概念が意味を成さないmp3以外のファイルをタグ付けするためにid3v2を使用できるので、非同期処理なしでフレームデータを書き込むことは許されます。 I と思うこれはmp3ファイルであるかどうかに関わらず、6.2セクションが言っているところでは、です。フレームはunsynched/synchedと書かれています。フレームサイズは常にmpegと同期して書き換えます。 '
ID3v2.4フレームは、フレームヘッダーに 'データ長さインジケータ'フラグを設定することができます。この場合、同期後にバッファの大きさがわかります。仕様のセクション4.1.2を参照してください。
私を助けることができる人はいますか？
準拠したid3v2タグリーダーを書いた人からの助言：仕様を理解しようとしないでください。それは確かに狂人とサディストによって書かれたものです。もう一度それを見て、私に悪夢を与えている。