当前位置：文江博客话题详情

为什么 MP3 文件使用 Synchsafe 整数？

发布于 2024-10-20 11:30:08 字数 206 浏览 3 评论 0原文

我开始用 C++ 读取 mp3 文件。

一切都很顺利，直到我阅读了 ID3 标签的规格。 ID3v2-Header 中有一些关于其大小的信息存储在所谓的同步安全整数中。这是一个四字节整数，其中每个字节的最高有效位设置为零。

我找到了如何将其转换为普通整数，但我不停地问自己为什么整数值以如此不必要的复杂方式存储。

我希望有人能告诉我为什么要这样存储。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

墟烟 2024-10-27 11:30:08

要理解为什么使用同步安全整数，了解一点 MP3 数据的格式以及媒体播放器如何播放 MP3 文件会很有帮助。 MP3 数据作为一系列帧存储在文件中。每个帧都包含一小部分以 MP3 格式编码的数字音乐以及有关该帧本身的一些元数据。每个 MP3 帧的开头有 11 位（有时 12 位）全部设置为 1。这称为同步，它是媒体播放器在尝试播放 MP3 文件或流时寻找的模式。如果播放器找到这个 11 位序列，那么它就知道它找到了一个可以解码和播放的 MP3 帧。

请参阅：www.id3.org/mp3Frame

如您所知，ID3 标签包含有关整个曲目的数据。 ID3 标记（在版本 2.x 及更高版本中）位于文件的开头，甚至可以嵌入到 MP3 流中（尽管不经常这样做）。 ID3标签的标头包含一个32位大小的字段，该字段指示标签中有多少字节。无符号 32 位整数可以容纳的最大值为 0xFFFFFFFF。因此，如果我们将 0xFFFFFFFF 写入大小字段，我们就声明了一个非常大的标签（实际上太大）。当播放器尝试播放文件或流时，它会查找 MP3 数据帧的 11 位序列，但会在 ID3 标签标头中查找大小字段并尝试播放该标签，因为大小字段具有前 11 位位设置。这通常听起来不太好，具体取决于您的音乐品味。解决方案是创建一个不包含全 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;
}

希望这会有所帮助。

To understand why sync-safe integers are used, it's helpful to understand a little about the format of MP3 data as well as how an MP3 file is played by a 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 meta data about the frame itself. At the beginning of each MP3 frame are 11 bits (sometimes 12) all set to 1. This is called the sync, and it's the pattern a media player looks for when attempting to play an MP3 file or stream. If the player finds this 11 bit sequence, then it knows its found an MP3 frame which can be decoded and played back.

See: www.id3.org/mp3Frame

As you know an ID3 tag contains data about the track as a whole. An ID3 tag -- in version 2.x and later -- is located at the beginning of a file, or can even be embedded in an MP3 stream(though this is not often done). The header of an ID3 tag contains a 32 bit size field, which indicates how many bytes are in the tag. The max value an unsigned, 32 bit integer can hold is 0xFFFFFFFF. So if we write 0xFFFFFFFF into the size field, we're claiming a really big tag (pragmatically too big). When the player attempts to play the file or stream, it looks for the 11 bit sequence of an MP3 data frame, but instead finds the size field in the ID3 tag header and tries to play the tag, since the size field has the first 11 bits set. This usually doesn't sound as good, depending on your musical tastes. The solution is to create an integer format that contains no 11 bit sequences of all 1's. Hence the sync-safe integer format.

A sync-safe 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.

回复收藏 0 原文

追风人 2024-10-27 11:30:08

除了上述答案之外，我还想从我的博客添加一个页面： http:// /phaxis.org/2010/05/08/synch-safe/

回复收藏 0 原文

只为守护你 2024-10-27 11:30:08

6.2。同步安全整数
在标签的某些部分，使用非同步方案是不方便的，因为事先不知道非同步数据的大小，这对于大小描述符来说尤其成问题。 ID3v2 中的解决方案是使用同步安全整数，其中永远不会出现任何错误同步。
同步安全整数是将其最高位（位 7）保持为零的整数，从而使八位中的七位可用。因此，一个 32 位同步安全整数可以存储 28 位信息。

来自 http://www.id3.org/id3v2.4.0-struct

它是紧密的与给定文档中所谓的“不同步”相关，您应该阅读整个第 6 章。所有这些都与最大限度地提高与各种软件和硬件的兼容性有关。

回复收藏 0 原文

~没有更多了~