同期セーフな整数が使用される理由を理解するには、MP3データの形式と、メディアプレーヤーでMP3ファイルがどのように再生されるかについて少し理解しておくと役立ちます。MP3データは、一連のフレームとしてファイルに保存されます。各フレームには、MP3形式でエンコードされた小さなデジタル音楽と、フレーム自体に関するメタデータが含まれています。各MP3フレームの先頭には、11ビット（場合によっては12）がすべて1に設定されています。これは同期と呼ばれ、メディアプレーヤーがMP3ファイルまたはストリームを再生しようとするときに探すパターンです。プレーヤーがこの11ビットシーケンスを見つけた場合、デコードして再生できるMP3フレームが見つかったことを認識します。
ご存知のように、ID3タグにはトラック全体に関するデータが含まれています。ID3タグ（バージョン2.x以降）はファイルの先頭に配置されているか、MP3ストリームに埋め込むこともできます（これはあまり行われていませんが）。ID3タグのヘッダーには、タグのバイト数を示す32ビットサイズのフィールドが含まれています。符号なし32ビット整数が保持できる最大値は0xFFFFFFFFです。したがって、サイズフィールドに0xFFFFFFFFと書き込むと、非常に大きなタグ（実際には大きすぎる）を要求していることになります。プレーヤーがファイルまたはストリームを再生しようとすると、MP3データフレームの11ビットシーケンスを探しますが、サイズフィールドには最初の11が含まれているため、代わりにID3タグヘッダーでサイズフィールドを見つけてタグを再生しようとします。ビットセット。あなたの音楽の好みにもよりますが、これは通常それほど良く聞こえません。解決策は、すべて1の11ビットシーケンスを含まない整数形式を作成することです。したがって、同期セーフ整数形式です。
同期セーフ整数は、次のようなものを使用してC /C++で整数に変換できます。
int ID3_sync_safe_to_int( uint8_t* sync_safe )
{
uint32_t byte0 = sync_safe[0];
uint32_t byte1 = sync_safe[1];
uint32_t byte2 = sync_safe[2];
uint32_t byte3 = sync_safe[3];
return byte0 << 21 | byte1 << 14 | byte2 << 7 | byte3;
}
お役に立てれば。
上記の回答に加えて、ブログからページを追加したいと思います：http: //phoxis.org/2010/05/08/synch-safe/
6.2。同期安全整数
タグの一部では、非同期データのサイズが事前にわからないため、非同期スキームを使用するのは不便です。これは、サイズ記述子で特に問題になります。ID3v2の解決策は、同期セーフ整数を使用することです。この整数では、誤った同期が発生することはありません。Synchsafe整数は、最上位ビット（ビット7）をゼロに保ち、8ビットのうち7ビットを使用可能にする整数です。したがって、32ビットのsynchsafe整数は、28ビットの情報を格納できます。
http://www.id3.org/id3v2.4.0-structureから
これは、特定のドキュメントで「非同期化」と呼ばれるものと密接に関連しています。第6章全体を読む必要があります。これはすべて、さまざまなソフトウェアおよびハードウェアとの互換性を最大化するために関連しています。