我曾经使用ffmpeg来计算服务器端MP3文件的持续时间 - 这似乎工作正常。今天我发现有些计算错了。不知何故，由于某种原因，ffmpeg将错误地计算持续时间，并且它似乎只发生在可变比特率mp3文件中。
在本地测试时，我注意到ffmpeg以绿色打印了两条额外的线条。
使用的命令：
ffmpeg -i song_9747c077aef8.mp3
ffmpeg说：
[mp3 @ 0x102052600] max_analyze_duration 5000000 reached at 5015510
[mp3 @ 0x102052600] Estimating duration from bitrate, this may be inaccurate
在一个不错的，温暖的谷歌会议之后，我发现了一些帖子，但没有找到解决方案。
然后我试着增加最长持续时间：
ffmpeg -analyzeduration 999999999 -i song_9747c077aef8.mp3
在此之后，ffmpeg仅返回第二行：
[mp3 @ 0x102052600] Estimating duration from bitrate, this may be inaccurate
但在任何一种情况下，计算的持续时间都是完全错误的。将其与VLC进行比较我注意到持续时间是正确的。
经过更多的研究，我偶然发现了mp3info - 我安装和使用了它。
mp3info -p "%S" song_9747c077aef8.mp3
然后mp3info返回CORRECT持续时间，但只作为一个整数，我不能使用，因为我需要一个更准确的数字。用户blahdiblah在下面的评论中解释了这一点的原因 - mp3info只是从文件中提取ID3信息而不是实际执行任何计算。
我也尝试使用mplayer来检索持续时间，但就像ffmpeg一样，mplayer返回错误的值。
我终于使用sox找到了解决这个问题的正确方法 - 它返回了正确的信息。
sox file.mp3 -n stat
Samples read: 19321344
Length (seconds): 219.062857
Scaled by: 2147483647.0
Maximum amplitude: 1.000000
Minimum amplitude: -1.000000
Midline amplitude: -0.000000
Mean norm: 0.141787
Mean amplitude: 0.000060
RMS amplitude: 0.191376
Maximum delta: 0.947598
Minimum delta: 0.000000
Mean delta: 0.086211
RMS delta: 0.115971
Rough frequency: 4253
Volume adjustment: 1.000
长度（秒）：219.062857
您可以完全解码文件以获得实际持续时间：
ffmpeg -i input.mp3 -f null -
控制台输出的第二行到最后一行将显示如下内容：
size=N/A time=00:03:49.12 bitrate=N/A
其中time是实际持续时间。在这个例子中，整个过程大约需要0.5秒。
从LordNeckbeard扩展解决方案。要获得统计数据，您可以添加标志-v quiet -stats
ffmpeg -v quiet -stats -i input.mp3 -f null -
更简单的方法是使用ffmpeg从ID3标记中具有错误持续时间的文件复制文件。这导致它写出正确的信息。
ffmpeg -i "audio.mp3" -acodec copy "audio_fixed.mp3"
因为它使用副本，所以只需要原始编码所花费的时间的一小部分。这首歌几乎不会引人注意，但是你真的很喜欢它有7小时的有声读物。重新编码后，ID3“持续时间”标签现在具有正确的信息。