问题描述
当我尝试通过 HTML5 播放器播放我的一些 MP3 时，播放器似乎返回两个不同的持续时间.当我使用 jQuery 查询持续时间时，我得到了当前的持续时间，但在默认的 Chrome 播放器中，这首歌尝试播放的时间比实际播放的时间长得多.这在 Safari(MacOSX 上的 7.0.1)中不是问题.是什么导致某些 MP3 出现此问题?如何让 Chrome(第 31 版)使用正确的时间?
When I try to play some of my MP3s through the HTML5 player, the player seems to return two different duration times. When I query the duration with jQuery, I get the current duration, but in the default Chrome player, the song tries to play for significantly longer than the song actually is. This is not an issue in Safari (7.0.1 on MacOSX). What is causing this issue with certain MP3s and how can I get Chrome (v. 31) to use the correct time?
代码如下:
<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/
Here is a JSFiddle of the audio file:
http://jsfiddle.net/spKqh/5/
推荐答案
这一切都归结为具体的 MP3 文件.估计 MP3 文件的长度听起来像是一项简单的任务，但没有一种正确的方法可以做到.有不同的标签标准在起作用，有时这些标签存储长度，这可能准确也可能不准确.另一种方法是确定 MP3 文件是恒定比特率文件还是可变比特率文件，然后处理一些数字以确定长度.
This all boils down to the specific MP3 file. Estimating the length of an MP3 file sounds like it would be a straightforward task, but there is no 1 correct way to do it. There are different tagging standards at play and sometimes such tags store a length, which may or may not be accurate. Another approach is to determine if the MP3 file is a constant vs. variable bit rate file and then crunch some numbers to determine the length.
我的猜测是 Safari 使用前者(用标签估计)来找到 126 秒的真实长度，而 Chrome 使用后者(通过比特率和文件大小猜测)来猜测 227 秒的长度.进一步解释:
My guess is that Safari does the former (estimate with tags) to find the true length of 126 seconds while Chrome does the latter (guess by bit rate and file size) to guess a length of 227 seconds. To explain further:
我下载了有问题的 MP3 进行分析 (clown-car_2.mp3).它是 9096504 字节长.根据播放实用程序，它以每秒 320 千比特的恒定比特率进行编码.假设千位是 1000 位:
I downloaded the MP3 in question for analysis (clown-car_2.mp3). It is 9096504 bytes long. According to playback utilities, it is encoded at a constant bit rate of 320 kilobits per second. Assuming a kilobit is 1000 bits:
320000 bits per second / 8 bits per byte = 40000 bytes per second
9096504 bytes / 40000 bytes per second = ~227 seconds
这是怎么回事?MP3 文件以额外元数据的形式携带着大量行李.FFmpeg 将其识别为具有动态 JPEG 视频轨道(可能是静态封面图片).这很可能会忽略长度计算.
What's going on here? The MP3 file is carrying a ton of baggage in the form of extra metadata. FFmpeg identifies it as having a motion JPEG video track (probably a static cover art image). This is likely throwing off the length calculation.
我在清理元数据时使用 FFmpeg 重新编码 MP3:
I used FFmpeg to re-code the MP3 while scrubbing the metadata:
ffmpeg -i clown-car_2.mp3 -vn -acodec copy clown-car_2.scrubbed.mp3
此命令忽略视频轨道 (-vn) 并无损地转码编码的音频(不会导致音频质量损失).FFmpeg 将此文件识别为 126 秒(而之前声称为 227 秒).请注意，这个新文件是 5043953 字节:
This command ignores the video track (-vn) and losslessly transcodes the encoded audio (incurs no audio quality loss). FFmpeg identifies this file as being 126 seconds (while claiming 227 seconds before). Note that this new file is 5043953 bytes:
5043953 bytes / 40000 bytes per second = ~126 seconds
因此，您可能希望通过丢失庞大的图像元数据来收紧这些 MP3 文件(并且可能考虑低于 320 kbits/sec 的比特率，这是 MP3 支持的最大值，并且在 Internet 流媒体中并不常见).
So, you might want to work on tightening up those MP3 files by losing the bulky image metadata (and perhaps consider a lower bitrate than 320 kbits/sec which is the max that MP3 supports and not that common for internet streaming).
这篇关于HTML5 音频标签在 Chrome 中显示错误的 MP3 时长的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，WP2