Audio mp3编解码器也有I/p帧吗？

我正在用Android MediaPlayer播放mp3文件。 但当我使用seekTo（msec）函数寻找随机时间时，每个安卓设备中的每个播放器都显示出细微的差异。时间上的差异约为1秒

---

我好奇的是Mp3 MPEG1音频编解码器也有i帧/p帧的东西？我知道这是视频编解码器的属性，但我想知道音频编解码器是否也有类似的属性，所以它需要跳转到某个位置，以获得解码音频的I帧。如果是这样的话，这样的属性会造成寻找时间的差异，这是合理的，因为每个玩家开始的时间并不完全相同。

您可能会遇到三个不同的问题

第一个是MP3的帧大小。（这不同于视频“帧”…只需将本例中的帧想象为编码到MP3中的一块样本。） 该帧大小通常为1152个样本。你可以在该级别下搜索，但它需要先在该级别下进行解码，而不是所有玩家都会这样做

第二个问题是钻头储层。帧并不总是需要整个空间，编码器可以返回并用其他帧的数据填充它们，在需要时有效地使用更多带宽，同时保持恒定的比特率。一个天真的播放器通常会寻找下一个MP3同步字（

111111111xxxxx

），然后从那里向编解码器发送数据。由于丢失了位库信息，编解码器不一定总是有需要解码的信息。它可以播放一点小故障的声音，或者保持沉默，直到有足够的信息。这两种行为都存在于野外

最后，第三个问题是普通MP3文件/流中没有时间戳数据。搜索文件而不解码到所需的搜索点只是猜测。为了提高效率，玩家通常会做的是通过猜测他们应该从何处开始，将“针滴”到流中。如果播放机知道您有一个320 kbit/s的CBR流，并且它知道文件大小有多大，它可以猜测文件在时间上的长度，然后简单地等分以获得所需寻道时间的字节偏移量。可以想象，这是不精确的，即使使用CBR。对于VBR，一些玩家将使用到目前为止看到的平均比特率。其他人根本不允许寻找。其他人将查看第一帧，假设CBR，并将整个文件视为与第一帧相同的比特率。（有时播放一个VBR文件，并在文件的前几秒钟内观察结束时间戳的变化。这是因为玩家正在猜测文件的长度。）