我正在使用 Android 媒体播放器播放 mp3 文件。 但是当我使用 seekTo(msec) 函数寻找一些随机时间时，每个 android 设备中的每个播放器都会显示出细微的差异。时间上的差异大约是 1 秒。
我很好奇的是 Mp3 MPEG1 音频编解码器也有 I 帧/p 帧的东西吗？我知道它是视频编解码器的属性，但我想知道音频编解码器是否也有类似的属性，所以它需要跳转到某个位置以获取 I 帧来解码音频。如果是这样，这样的属性可以产生寻找时间的差异是合理的，因为每个玩家开始的时间并不完全相同。
【问题讨论】：
您可能会遇到三个不同的问题。
第一个是 MP3 帧大小。 （这与视频“帧”不同......在这种情况下，只需将帧视为编码为 MP3 的一大块样本。） 该帧大小通常为 1,152 个样本。您可以在该级别以下进行搜索，但需要先在该级别以下进行解码，并且并非所有玩家都会这样做。
第二个问题是位库。帧并不总是需要整个空间，编码器可以返回并用其他帧的数据填充它们，在需要时有效地使用更多带宽，同时保持恒定比特率。一个天真的播放器通常会寻找下一个 MP3 同步字 (11111111 111xxxxx) 并从那里将数据发送到编解码器。由于缺少位存储信息，编解码器并不总是具有当时需要解码的信息。它可以播放一些故障声音，也可以保持沉默，直到获得足够的信息。这两种行为在野外都存在。
最后，第三个问题是普通的 MP3 文件/流中没有时间戳数据。寻找文件而不解码到所需的寻找点只是猜测。为了提高效率，玩家通常会做的是通过猜测他们应该从哪里开始“针落”到流中。如果播放器知道你有一个 320 kbit/s 的 CBR 流，并且它知道文件大小有多大，它可以及时估计文件的时间长度，并简单地平均划分以获得所需查找时间的字节偏移量。正如您可以想象的那样，即使使用 CBR，这也是不精确的。对于 VBR，一些玩家会使用他们迄今为止看到的平均比特率。其他人根本不允许寻求。其他人将查看第一帧，假设 CBR，并将整个文件视为与第一帧相同的比特率。 （有时播放一个 VBR 文件，并观察文件前几秒的结束时间戳变化。那是因为播放器在猜测长度是多少。）
【讨论】：