当我尝试通过HTML5播放器播放我的一些MP3时，播放器似乎返回两个不同的持续时间。当我用jQuery查询持续时间时，我得到了当前的持续时间，但在默认的Chrome播放器中，这首歌的播放时间比歌曲实际上要长得多。这在Safari（MacOSX上的7.0.1）中不是问题。某些MP3导致此问题的原因是什么？如何让Chrome（第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/
答案 0 :(得分：17)
这一切归结为具体的MP3文件。估计MP3文件的长度听起来像是一项简单的任务，但没有一种正确的方法可以做到这一点。有不同的标记标准在起作用，有时这样的标记存储长度，这可能是也可能不准确。另一种方法是确定MP3文件是否为常量与可变比特率文件，然后处理一些数字以确定长度。
我的猜测是Safari使用前者（使用标签估算）来查找126秒的真实长度，而Chrome执行后者（通过比特率和文件大小猜测）来猜测长度为227秒。进一步解释：
我下载了有问题的MP3进行分析（clown-car_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文件（并且可能考虑比MP3支持的最大比特率低于320千比特/秒，而不是互联网流媒体的比特率）。