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

Question

我正在使用Android Media Player播放mp3文件。
但是当我确实使用seekTo(msec)函数寻求某个随机时间时，每个android设备中的每个播放器都显示出细微的差异。时间差约为1秒。

我很好奇的是Mp3 MPEG1音频编解码器也有I frame / p frame的东西吗？我知道这是视频编解码器的属性，但是我想知道音频编解码器是否也具有类似的属性，因此它需要跳到某个位置以获取I帧来解码音频。如果是这样，则这种属性可以使搜寻时间有所不同是合理的，因为每个玩家的开始时间都不完全相同。

Answer 1

您可能会遇到三个独立的问题。

第一个是MP3帧大小。 (这与视频“帧”不同...在这种情况下，只需将帧视为编码为MP3的大量样本即可。)
该帧大小通常为1,152个样本。您可以在该级别以下进行搜索，但是它需要先在该级别以下进行解码，并且并非所有玩家都愿意这样做。

第二个问题是钻头储层。帧并不总是需要整个空间，编码器可以返回并用其他帧的数据填充它们，从而有效地在需要时使用更多带宽，同时保持恒定的比特率。天真的播放器通常会寻找下一个MP3同步字(11111111 111xxxxx)，然后从那里将数据发送到编解码器。由于缺少位存储库信息，因此编解码器将不会始终具有此时需要解码的信息。它可以播放一点故障声音，也可以保持沉默直到获得足够的信息。两种行为都存在于野外。

最后，第三个问题是普通的MP3文件/流中没有时间戳数据。在不解码到所需寻道点的情况下搜索文件只是猜测。为了提高效率，玩家通常会通过猜测应该从哪里开始而“落针”。如果播放器知道您有一个320 kbit / s的CBR流，并且知道文件的大小，则它可以估算出文件的时间长度，并简单地平均分配以获得所需寻道时间的字节偏移量。可以想象，即使使用CBR，这也是不精确的。对于VBR，某些播放器将使用到目前为止所见的平均比特率。其他人则根本不允许寻求。其他人将查看第一帧，并采用CBR，并将整个文件视为与第一帧相同的比特率。 (有时播放VBR文件，并在文件的前几秒内观看结束时间戳的更改。这是因为播放器正在猜测长度是多少。)