gpt4 book ai didi

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

转载 作者:太空狗 更新时间:2023-10-29 13:39:04 24 4
gpt4 key购买 nike

当我尝试通过 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/

最佳答案

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

我的猜测是 Safari 执行前者(用标签估计)来找到 126 秒的真实长度,而 Chrome 执行后者(根据比特率和文件大小猜测)来猜测 227 秒的长度。进一步解释:

我下载了有问题的MP3进行分析(clown-car_2.mp3)。它有 9096504 个字节长。根据播放实用程序,它以每秒 320 kb 的恒定比特率进行编码。假设 1 千位为 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 支持的最大值,但在互联网流媒体中并不常见)。

关于javascript - HTML5 音频标签在 Chrome 中显示错误的 MP3 持续时间,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/20711488/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com