我正在玩一些HTML5 <audio>标签，我注意到一些奇怪的行为，与currentTime属性有关。
我想有一个本地音频文件播放，让timeupdate事件检测，当它完成比较currentTime属性到duration属性。
如果我让歌曲从头到尾播放，这实际上工作得很好-歌曲的结尾是正确确定的。
然而，手动更改currentTime(直接通过JavaScript或使用基于浏览器的音频控件)导致API不再给出currentTime的正确值，但似乎将其设置在实际播放的位置之前几秒钟。
(这些"几秒钟"是基于Chrome的，Firefox似乎完全疯了，这导致差异更大。)
关于这个问题的一个小jsFiddle示例:http://jsfiddle.net/yp3o8cyw/2/
谁能告诉我为什么会发生这种情况-或者我只是没有得到正确的API应该做什么?
注::我只是注意到这实际上只发生在mp3编码的文件，OGG文件完全做得很好。
在与这个神秘的问题斗争了几个小时之后，我相信我已经弄清楚了这里发生了什么。这不是。ogg和。mp3的问题，这是一个在mp3(也许还有其他文件类型)上可变和恒定比特率编码的问题。
我不能把发现这个的功劳揽在自己身上，我只是在网上搜索了一下。2015年2月1日，绅士兼学者Terrill Thompson写了一篇关于这个问题的详细文章，其中包括以下摘录:
可变比特率(VBR)使用一种算法来有效地压缩数据媒体，在高比特率和低比特率之间变化给定时刻数据的复杂性。恒定比特率(CBR)， in相反，使用相同的比特率压缩文件。研究设计比CBR更有效，因此可以提供同样的质量，更小的文件大小，听起来很有吸引力，是吗?
不幸的是，如果媒体正在流式传输，则存在权衡(包括渐进式下载)，特别是如果限时文本是参与。据我所知，vbr编码的MP3文件不能用
我写这篇文章是为了那些遇到这种同步问题的人(这使得音频和文本无法精确同步)，因为如果你这样做了，弄清楚发生了什么真的是一场噩梦。
我的下一步是做一些更多的测试，最后找出一个有效的方法来转换我所有的。mp3恒定的比特率。我认为FFMPEG可能会有所帮助，但我将在另一个线程中探索。也要感谢Loilo最初发表的关于这个问题的文章，以及Brad分享的信息。
首先，我实际上无法在我的机器上重现您的问题，但目前我手边只有一个简短的MP3文件，所以这可能是问题所在。无论如何，我想我能解释这一切。
MP3文件(MPEG)是非常简单的流，其中没有绝对的位置数据。通过读取文件的第一部分来知道某个任意帧开始的字节偏移量是不可能的。媒体播放器在文件中查找针滴。也就是说，它知道整个轨道的大小，以及你的时间偏移在轨道上的大致位置。它猜测并开始解码，一旦与下一个帧报头同步就开始解码。这是一个不精确的过程。Ogg是一个更健壮的容器，在它的帧头中内置了时间偏移。在Ogg文件中查找要简单得多。
另一个问题是，大多数浏览器支持MP3只是因为编解码器在您的系统上已经可用。播放Ogg Vorbis和MP3通常是完全不同的库，具有不同的api。虽然web标准做了很多工作来提供一个共同的抽象，但小的实现细节会导致像你看到的那样的怪癖。