【问题标题】:Why sync-safe integer?为什么同步安全整数?
【发布时间】:2011-10-26 05:26:22
【问题描述】:

我最近正在研究 ID3v2.4.0。 阅读 2.4.0 文档,我发现了一个我无法理解的特定部分 - 同步安全整数。 ID3v2为什么要用这种方式?

当然,我知道为什么 ID3v2 使用非同步方案,该方案用于防止 MPEG 解码器将 ID3 标签视为 MPEG 同步数据。 但我无法理解的是,为什么同步安全整数而不是非同步方案(= 插入 $00)。

在表达标签大小而不是插入 $00 时,他们有什么理由采用同步安全整数? 这两种方法产生完全相同的效果。

ID3v2 文档说未同步数据的大小是事先不知道的。 但这种说法没有意义。 如果标记数据存储在缓冲区中,只需将有问题的字符替换为 $FF 00 即可知道未同步数据的大小。

有没有人可以帮助我?

【问题讨论】:

    标签: c++ mp3 meta-tags id3 id3v2


    【解决方案1】:

    为了简单起见,我认为 unsynch/synch 方案仅在用于 mpeg 文件时才有意义。

    读取四个字节并将它们转换为常规整数是微不足道的:

    // pseudo code
    uint32_t size;
    file.read( &size, sizeof(uint32_t) );
    size =   (size & 0x0000007F) |
           ( (size & 0x00007F00) >> 1 ) |
           ( (size & 0x007F0000) >> 2 ) |
           ( (size & 0x7F000000) >> 3 );
    

    如果他们使用与帧数据相同的不同步方案,则需要分别读取每个字节,查找 FF00 模式,并逐字节重建整数。此外,如果标头中的“大小”字段可以是可变数量的字节,由于插入的不同步字节,整个标头将是可变数量的字节。他们更简单地说“标头的大小始终为 10 个字节,看起来像这样......”。

    ID3v2 文档说未同步数据的大小是事先不知道的。但这种说法没有意义。如果标记数据存储在缓冲区中,只需将有问题的字符替换为 $FF 00 即可知道未同步数据的大小。

    你是对的,这没有意义。 id3v2 标头和帧标头中写入的大小是应用 不同步(如果有)后的大小。但是,允许在不同步的情况下写入帧数据,因为 id3v2 可用于标记除 mp3 以外的文件,其中不同步/同步的概念没有意义。我认为第 6.2 节试图说的是'无论这是一个 mp3 文件,还是一个帧被写入不同步/同步,帧大小总是以 mpeg 同步写入 -安全的方式'。

    ID3v2.4 帧可以在帧头中设置“数据长度指示符”标志,在这种情况下,您可以在同步后找出缓冲区的大小。请参阅规范的第 4.1.2 节。

    有没有人可以帮助我?

    来自编写符合 id3v2 标签阅读器的人的一些有用建议:不要试图理解规范。它肯定是疯子和虐待狂写的。再看一遍就让我做噩梦了。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2012-01-19
      • 1970-01-01
      • 2019-10-27
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2019-02-15
      • 1970-01-01
      相关资源
      最近更新 更多