我正在尝试使用HTML5的<audio>标签，并注意到一些与currentTime属性有关的奇怪行为。
我想播放本地音频文件，并让timeupdate事件通过比较currentTime属性和duration属性来检测它何时完成。
如果我让歌曲从开始到结束播放，这实际上相当好用 - 歌曲的结尾被正确确定。
但是，手动更改currentTime（直接通过JavaScript或使用基于浏览器的音频控件）会导致API不再返回正确的currentTime值，而似乎将其设置在实际播放位置之前的几秒钟。
（这些“几秒钟”的提前量基于Chrome，Firefox似乎完全疯狂，导致差异要大得多。）
这是一个关于问题的小jsFiddle示例：http://jsfiddle.net/yp3o8cyw/2/
有人能告诉我为什么会发生这种情况吗？还是我没有理解API应该做什么？
P.S.：我刚刚注意到，这实际上只发生在MP3编码文件中，OGG文件完全没问题。
可变比特率（VBR）使用算法对媒体进行高效压缩，根据给定时刻数据的复杂性在低和高比特率之间变化。相反，恒定比特率（CBR）使用相同的比特率压缩文件。 VBR比CBR更有效，因此可以以更小的文件大小提供与CBR相当质量的内容，这听起来很有吸引力，是吗？
不幸的是，如果媒体正在流式传输（包括渐进式下载），特别是涉及定时文本，则存在折衷。正如我所了解的那样，如果用户向前或向后快进，VBR编码的MP3文件无法进行可靠的定时播放。
我为任何遇到此同步问题的人编写此文（这使得音频和文本的精确同步成为不可能），因为如果您遇到此问题，要弄清楚发生了什么真是一场噩梦。
我的下一步是进行更多测试，最终找出将所有.mp3转换为恒定比特率的高效方法。 我想FFMPEG可能能够帮助，但我将在另一个线程中探讨这个问题。 还要感谢Loilo最初发布此问题以及Brad分享的信息。
首先，我无法在我的机器上复现您的问题，但是我目前只有一个很短的MP3文件，所以可能是这个问题的原因。不管怎样，我认为我可以解释一下发生了什么。
MP3文件（MPEG）是非常简单的流，它们没有绝对位置数据。从文件的开头读取并不可能知道任意帧开始的字节偏移量。媒体播放器通过needle dropping在文件中查找。也就是说，它知道整个音轨的大小和您的时间偏移量大致在哪里。它会猜测并开始解码，一旦同步到下一个帧头，就会立即恢复。这是一个不精确的过程。
Ogg是一个更强大的容器，并且在其帧头中内置了时间偏移量。在Ogg文件中搜索要简单得多。
另一个问题是，大多数支持MP3的浏览器之所以支持是因为编解码器已经在您的系统上可用。播放Ogg Vorbis和MP3通常需要使用完全不同的库和不同的API。虽然Web标准提供了共同的抽象，但是像您看到的那样，小的实现细节会导致问题。
