当我尝试通过HTML5播放器播放我的一些MP3时,播放器似乎返回两个不同的持续时间.当我用jQuery查询持续时间时,我得到了当前的持续时间,但在默认的Chrome播放器中,这首歌的播放时间比歌曲实际上要长得多.这在Safari(MacOSX上的7.0.1)中不是问题.某些MP3导致此问题的原因是什么?如何让Chrome(第31版)使用正确的时间?
这是代码:
这是音频文件的JSFiddle:
http://jsfiddle.net/spKqh/5/
这一切都归结为具体的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千比特/秒,而不是通常用于互联网流媒体).