HTML5 音頻 - currentTime 屬性不准確？

Question

我正在嘗試使用 HTML5 <audio>標簽，我注意到一些與currentTime屬性有關的奇怪行為。

我想播放一個本地音頻文件，並讓timeupdate事件通過將currentTime屬性與duration屬性進行比較來檢測它何時完成。

如果我讓歌曲從頭到尾播放，這實際上效果很好——歌曲的結尾是正確確定的。

但是，手動更改currentTime （直接通過 JavaScript 或使用基於瀏覽器的音頻控件）會導致 API 不再返回正確的currentTime值，但似乎將其設置在實際播放位置之前幾秒鍾。

（前面的這些“幾秒鍾”是基於 Chrome 的，Firefox 似乎完全瘋了，這導致差異更大。）

關於這個問題的一個小 jsFiddle 例子： http : //jsfiddle.net/yp3o8cyw/2/

誰能告訴我為什么會發生這種情況 - 或者我只是沒有正確理解 API 應該做什么？

PS：我剛剛注意到這實際上只發生在 MP3 編碼的文件中，OGG 文件完全正常。

Answer 1

經過數小時與這個神秘問題的斗爭，我相信我已經弄清楚這里發生了什么。 這不是 .ogg 與 .mp3 的問題，這是 mp3（以及其他文件類型）上可變比特率編碼與恆定比特率編碼的問題。

我不能因為發現這一點而受到贊揚，只是因為搜索了互聯網。 紳士學者特里爾·湯普森 (Terrill Thompson) 早在 2015 年 2 月 1 日就針對這個問題寫了一篇詳細的文章，其中摘錄如下：

可變比特率 (VBR) 使用一種算法來有效地壓縮媒體，根據給定時刻數據的復雜性，在低比特率和高比特率之間變化。 相比之下，恆定比特率 (CBR) 始終使用相同的比特率壓縮文件。 VBR 比 CBR 更有效，因此可以以較小的文件大小提供相當質量的內容，這聽起來很有吸引力，是嗎？

不幸的是，如果正在流式傳輸媒體（包括漸進式下載），則需要權衡，尤其是在涉及定時文本時。 據我所知，如果用戶向前或向后擦洗，VBR 編碼的 MP3 文件不能以可靠的時間播放。

我正在為遇到此同步問題的任何其他人寫這篇文章（這使得音頻和文本的精確同步變得不可能），因為如果你這樣做，弄清楚發生了什么真的是一場噩夢。

我的下一步是做一些更多的測試，最后找出一種將我所有的 .mp3 轉換為恆定比特率的有效方法。 我認為 FFMPEG 可能會有所幫助，但我會在另一個線程中探討這一點。 還要感謝 Loilo 最初發布有關此問題的信息，並感謝 Brad 提供的信息。

Answer 2

首先，我實際上無法在我的機器上重現您的問題，但我目前只有一個簡短的 MP3 文件，所以這可能是問題所在。 無論如何，我想我可以解釋發生了什么。

MP3 文件 (MPEG) 是非常簡單的流，其中沒有絕對位置數據。 不可能通過讀取文件的第一部分來知道某個任意幀以什么字節偏移量開始。 媒體播放器通過落針在文件中查找。 也就是說，它知道整個軌道的大小以及您的時間偏移量在軌道上的大致大小。 它猜測並開始解碼，一旦與下一個幀頭同步就開始解碼。 這是一個不精確的過程。

Ogg 是一個更強大的容器，並且在其幀頭中內置了時間偏移。 在 Ogg 文件中查找要簡單得多。

另一個問題是，大多數支持 MP3 的瀏覽器之所以這樣做只是因為編解碼器已經在您的系統上可用。 播放 Ogg Vorbis 和 MP3 通常是完全不同的庫，具有不同的 API。 雖然 Web 標准在提供通用抽象方面做了很多工作，但次要的實現細節會導致您看到的怪癖。