我正在尝试使用 HTML5 <audio>标签，我注意到一些与 currentTime 有关的奇怪行为属性。
我想播放本地音频文件并让 timeupdate通过比较 currentTime 来检测事件何时完成属性为 duration属性。
如果我让歌曲从头到尾播放，这实际上工作得很好 - 歌曲的结尾被正确确定。
但是，更改 currentTime手动(直接通过 JavaScript 或使用基于浏览器的音频控件)导致 API 无法返回 currentTime 的正确值不再但似乎将其设置在实际播放的位置之前几秒钟。
(这些“几秒钟”是基于 Chrome，Firefox 似乎完全疯狂，导致差异更大。)
一个关于问题的 jsFiddle 小例子:http://jsfiddle.net/yp3o8cyw/2/
谁能告诉我为什么会发生这种情况 - 或者我只是没有正确理解 API 应该做什么？
P.S.:我刚刚注意到这实际上只发生在 MP3 编码文件中，OGG 文件完全没问题。
最佳答案
在与这个神秘问题作斗争几个小时后，我相信我已经弄清楚这里发生了什么。这不是 .ogg 与 .mp3 的问题，这是 mp3(可能还有其他文件类型)上的可变比特率编码与恒定比特率编码的问题。
我不能把发现这个归功于我，只是为了搜索互联网。 Terrill Thompson，一位绅士和学者，写了一篇 detailed article关于这个问题早在 2015 年 2 月 1 日，其中包括以下摘录:
Variable Bit Rate (VBR) uses an algorithm to efficiently compress the media, varying between low and high bitrates depending on the complexity of the data at a given moment. Constant Bit Rate (CBR), in contrast, compresses the file using the same bit rate throughout. VBR is more efficient than CBR, and can therefore deliver content of comparable quality in a smaller file size, which sounds attractive, yes?
Unfortunately, there’s a tradeoff if the media is being streamed (including progressive download), especially if timed text is involved. As I’ve learned, VBR-encoded MP3 files do not play back with dependable timing if the user scrubs ahead or back.
我是为遇到此同步问题(这使得音频和文本的精确同步变得不可能)的任何其他人写这篇文章，因为如果你这样做，弄清楚发生了什么真的是一场噩梦。
我的下一步是做更多的测试，并最终找到一种有效的方法将我所有的 .mp3 文件转换为恒定比特率。我认为 FFMPEG 可能会有所帮助，但我将在另一个线程中探讨它。还要感谢 Loilo 最初发布了有关此问题的帖子，感谢 Brad 分享的信息。
关于javascript - HTML5 音频 - currentTime 属性不准确？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/25468063/