Why is there a Synchsafe Integer?

I started reading mp3 files in C ++.

Everything went well until I read the specifications of the ID3 tag. The ID3v2-Header has some information about this size stored in the so-called Synchsafe Integer. This is a four-byte integer where the high bit of each byte is set to zero.

I have learned how to convert it to an integer of ordinates, but I can’t stop asking myself why the integer value is stored in such an unnecessary complicated way.

I hope there is someone who can tell me why it is stored this way.

+7
source share
3 answers

To understand why synchronization-compatible integers are used, it’s useful to understand a little about the MP3 data format and how the MP3 file is played by the media player. MP3 data is stored in a file as a series of frames. Each frame contains a small bit of digital music encoded in MP3 format, as well as some metadata about the frame itself. At the beginning of each MP3 frame, 11 bits (sometimes 12) are all set to 1. This is called synchronization, and this is the template that the media player looks for when trying to play a file or MP3 stream. If a player finds this 11-bit sequence, then he knows that he has found an MP3 frame that can be decoded and played.

See: www.id3.org/mp3Frame

As you know, the ID3 tag contains data about the track as a whole. The ID3 tag - in version 2.x and later - is located at the beginning of the file or can be embedded in the MP3 stream (although this is not often done). The ID3 tag header contains a 32-bit field that indicates how many bytes are in the tag. The maximum value of an unsigned 32-bit integer may contain 0xFFFFFFFF. Therefore, if we write 0xFFFFFFFF in the size field, we pretend to be a really big tag (pragmatically too big). When the player tries to play a file or stream, it searches for the 11-bit sequence of the MP3 data frame, but instead finds the size field in the ID3 tag header and tries to play the tag because the size field has the first 11 bits. This usually doesn't sound so good, depending on your musical tastes. The solution is to create an integer format that does not contain 11 bit sequences of all 1. Therefore, an integer format with synchronization.

A suitable synchronized integer can be converted to an integer in C / C ++ using something like the following:

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; } 

Hope this helps.

+20
source

In addition to the answers above, I would like to add a page from my blog: http://phoxis.org/2010/05/08/synch-safe/

+3
source

6.2. Synchronous integers

In some parts of the tag, it is inconvenient to use a non-syncing scheme, since the size of unsynchronized data is not known in advance, which is especially problematic with size descriptors. The solution in ID3v2 is to use synchsafe integers in which there can never be any false synchronizations. Synchsafe integers are integers that store their most significant bit (bit 7) with a value of zero, making seven of the eight available. Thus, a 32-bit synchronization integer can store 28 bits of information.

From http://www.id3.org/id3v2.4.0-structure

This is closely related to what they call "Unsynchronization" in this document, you should read the entire chapter 6. All this is associated with maximum compatibility with a wide range of software and hardware.

0
source

All Articles