HTML5音频标签显示在Chrome MP3的时间错误 [英] HTML5 Audio Tag Showing Wrong Duration of MP3 in Chrome

问题描述

当我试图通过HTML5播放器来播放一些自己的MP3，播放器似乎返回两个不同的持续时间。当我查询与jQuery的时间，我得到的电流持续时间，但在默认浏览器的球员，这首歌尝试了显著长于首歌其实是玩。这不是在Safari的问题（7.0.1 MacOSX上）。是什么造成了一定的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?

下面是code：

<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文件的长度听起来这将是一个简单的任务，但要做到这一点没有1正确的方法。有在播放不同标记的标准，有时这样的标签存储的长度，这可能会或可能不准确。另一种方法是，以确定是否对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的问题进行分析（小丑car_2.mp3）。它是9096504字节长。根据播放实用工具，它是连接以每秒320千比特的恒定比特率codeD。假设一个千位是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重新code中的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 ）和无损跨codeS的EN codeD音频（即被无音频质量损失）。 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千比特较低的比特率/秒这是最大的MP3支持，而不是互联网流媒体的普遍）。

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的时间错误的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！