HTML5 音频标签在 Chrome 中显示错误的 MP3 持续时间

Question

当我尝试通过 HTML5 播放器播放我的一些 MP3 时，播放器似乎返回了两个不同的持续时间。当我使用 jQuery 查询持续时间时，我得到了当前的持续时间，但在默认的 Chrome 播放器中，歌曲尝试播放的时间比歌曲实际播放时间要长得多。这在 Safari（MacOSX 上为 7.0.1）中不是问题。是什么导致某些 MP3 出现此问题，如何让 Chrome (v. 31) 使用正确的时间？

代码如下：

<audio controls="" autoplay="" name="media"><source src="http://musicalfamilytree.com/_private/c/cowboys_the/clown-car_2.mp3" type="audio/mpeg"></audio>
<input type="button" onclick='alert($("audio")[0].duration);' value="check duration" />

这是音频文件的 JSFiddle： http://jsfiddle.net/spKqh/5/

Answer 1

这一切都归结为特定的 MP3 文件。估计 MP3 文件的长度听起来像是一项简单的任务，但没有一种正确的方法可以做到这一点。有不同的标签标准在起作用，有时这些标签会存储一个长度，这可能准确也可能不准确。另一种方法是确定 MP3 文件是恒定还是可变比特率文件，然后计算一些数字来确定长度。

我的猜测是 Safari 使用前者（使用标签估计）来找到 126 秒的真实长度，而 Chrome 使用后者（根据比特率和文件大小猜测）猜测 227 秒的长度。进一步解释：

我下载了有问题的 MP3 进行分析（小丑车_2.mp3）。它长 9096504 字节。根据播放实用程序，它以每秒 320 千比特的恒定比特率进行编码。假设千位是 1000 位：

320000 bits per second / 8 bits per byte = 40000 bytes per second
9096504 bytes / 40000 bytes per second = ~227 seconds

这里发生了什么？ MP3 文件以额外元数据的形式承载了大量的包袱。 FFmpeg 将其识别为具有动态 JPEG 视频轨道（可能是静态封面图像）。这可能会影响长度计算。

我在清理元数据时使用 FFmpeg 重新编码 MP3：

ffmpeg -i clown-car_2.mp3 -vn -acodec copy clown-car_2.scrubbed.mp3

此命令忽略视频轨道 (-vn) 并无损地对编码音频进行转码（不会导致音频质量损失）。 FFmpeg 将此文件标识为 126 秒（之前声称为 227 秒）。请注意，这个新文件是 5043953 字节：

5043953 bytes / 40000 bytes per second = ~126 seconds

因此，您可能希望通过丢失庞大的图像元数据来收紧这些 MP3 文件（并且可能考虑低于 320 kbits/sec 的比特率，这是 MP3 支持的最大值，而对于互联网流媒体来说并不常见）。