我正在和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文件并在文件的前几秒观察结束时间戳。这是因为播放器正在猜测长度是多少。）