我正在使用HTML5 <audio>标记玩一下，我注意到一些与currentTime属性有关的奇怪行为。
我希望播放本地音频文件，并通过将timeupdate属性与currentTime属性进行比较，让duration事件在完成时检测到。
如果我让歌曲从开头到结尾播放，这实际上工作得很好 - 歌曲的结尾是正确的。
但是，手动更改currentTime（直接通过JavaScript或使用基于浏览器的音频控件）会导致API不再返回currentTime的正确值，但似乎已设置它比实际播放的位置提前几秒。
（这些“几秒钟”前面是基于Chrome，Firefox似乎完全疯了，导致差异变得更大。）
关于这个问题的一个小问题：http://jsfiddle.net/yp3o8cyw/2/
任何人都可以告诉我为什么会发生这种情况 - 或者我只是不知道API应该做什么？
P.S。：我刚注意到这实际上只发生在MP3编码文件中，OGG文件完全没问题。
答案 0 :(得分：11)
经过几个小时的斗争这个神秘的问题，我相信我已经弄明白这里发生了什么。这不是.ogg vs .mp3的问题，这是关于mp3（以及其他文件类型）的变量与恒定比特率编码的问题。
我不能因为发现这一点而受到赞誉，只是为了搜索互联网。 Terrill Thompson，一位绅士和学者，于2015年2月1日写了一篇关于这个问题的detailed article。
我正在为遇到此同步问题的任何其他人写这个（这使得音频和文字的精确同步变得不可能），因为如果你这样做，那么弄清楚发生了什么是一场真正的噩梦
我的下一步是进行更多测试，最后找出将所有.mp3转换为恒定比特率的有效方法。我认为FFMPEG可以提供帮助，但我会在另一个线程中探讨这个问题。还要感谢Loilo最初发布有关此问题的信息，感谢Brad分享的信息。
答案 1 :(得分：5)
首先，我实际上无法在我的机器上重现您的问题，但我现在只有一个简短的MP3文件，所以这可能是问题所在。无论如何，我想我可以解释发生了什么。
MP3文件（MPEG）是非常简单的流，并且其中没有绝对位置数据。读取文件的第一部分是不可能知道某个任意帧开始的字节偏移量。媒体播放器通过针头搜索在文件中寻找。也就是说，它知道整个轨道的大小以及大致距离轨道的距离。它猜测并开始解码，一旦与下一帧标题同步就立即拾取。这是一个不精确的过程。
Ogg是一个更健壮的容器，并且在其框架头中内置了时间偏移。在Ogg文件中查找要简单得多。
另一个问题是大多数支持MP3的浏览器都是这样做的，因为您的系统上已经有了编解码器。播放Ogg Vorbis和MP3通常是完全不同的具有不同API的库。虽然Web标准在提供通用抽象方面做了很多工作，但是细微的实现细节会引起您所看到的怪癖。