HTML5 音频 - currentTime 属性不准确？

Question

我正在使用 HTML5 <audio> 标记，我注意到一些与 currentTime 属性有关的奇怪行为。

我想播放一个本地音频文件，并通过比较 currentTime 属性和 duration 属性让 timeupdate 事件检测它何时结束。

如果我让歌曲从头到尾播放，这实际上效果很好 - 歌曲的结尾是正确确定的。

但是，手动更改 currentTime（直接通过 JavaScript 或使用基于浏览器的音频控件）会导致 API 不再返回 currentTime 的正确值，但似乎提前几秒钟设置它实际发挥的位置。

（前面的“几秒钟”基于 Chrome，Firefox 似乎完全发疯了，这导致差异更大。）

关于这个问题的一个小 jsFiddle 例子：http://jsfiddle.net/yp3o8cyw/2/

谁能告诉我为什么会发生这种情况 - 还是我没有正确理解 API 应该做什么？

P.S.：我刚刚注意到这实际上只发生在 MP3 编码文件中，OGG 文件完全正常。

Answer 1

在与这个神秘问题作斗争数小时后，我相信我已经弄清楚这里发生了什么。这不是 .ogg 与 .mp3 的问题，而是 mp3（可能还有其他文件类型）上的可变比特率编码与恒定比特率编码的问题。

我不能把发现这一点归功于我，只是为了搜索互联网。早在 2015 年 2 月 1 日，绅士和学者 Terrill Thompson 就这个问题写了一封detailed article，其中包括以下摘录：

可变比特率 (VBR) 使用一种算法来有效地压缩 媒体，在低比特率和高比特率之间变化，具体取决于 给定时刻数据的复杂性。恒定比特率 (CBR)，在 相反，使用相同的比特率压缩文件。 VBR 比 CBR 更有效，因此可以传递 较小的文件大小具有可比的质量，这听起来很有吸引力， 是吗？

不幸的是，如果正在流式传输媒体，则需要进行权衡 （包括渐进式下载），特别是如果定时文本 涉及。据我所知，VBR 编码的 MP3 文件无法播放 如果用户向前或向后滑动，则可靠的时间。

我正在为遇到此同步问题（这使得音频和文本的精确同步变得不可能）的其他人写这篇文章，因为如果你这样做了，弄清楚发生了什么真是一场噩梦。

我的下一步是进行更多测试，最后找出一种将所有 .mp3 转换为恒定比特率的有效方法。我认为 FFMPEG 可能会有所帮助，但我将在另一个线程中进行探讨。还要感谢 Loilo 最初发布有关此问题的帖子，以及 Brad 分享的信息。

Answer 2

首先，我实际上无法在我的机器上重现您的问题，但我现在手边只有一个简短的 MP3 文件，所以这可能是问题所在。无论如何，我想我可以解释发生了什么。

MP3 文件 (MPEG) 是非常简单的流，其中没有绝对位置数据。不可能通过读取文件的第一部分来知道某个任意帧开始的字节偏移量。媒体播放器通过落针查找文件。也就是说，它知道整个轨道的大小以及您的时间偏移量在轨道中的大致距离。它猜测并开始解码，一旦与下一个帧头同步就开始解码。这是一个不精确的过程。

Ogg 是一个更强大的容器，并且在其帧头中内置了时间偏移。在 Ogg 文件中查找要简单得多。

另一个问题是大多数支持 MP3 的浏览器这样做只是因为编解码器已经在您的系统上可用。播放 Ogg Vorbis 和 MP3 通常是具有不同 API 的完全不同的库。虽然 Web 标准在提供通用抽象方面做了很多工作，但次要的实现细节会导致您看到的怪癖。