我用来计算MP3文件服务器端的使用ffmpeg的时间 - 这似乎很好地工作。 今天，我发现了一些计算是错误的。 不知何故，由于某种原因，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然后返回正确的时间，但只作为一个整数，因为我在这里需要一个更准确的数字我不能使用。 这样做的原因是在下面留言说明的，通过用户blahdiblah - mp3info只是从文件中提取ID3信息，而不是实际执行任何计算。
我也试过用mplayer检索时间，但同样的ffmpeg，MPlayer是返回错误的值。
我终于找到了用袜这一问题的妥善解决 - 返回正确的信息。
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安静-stats
ffmpeg -v quiet -stats -i input.mp3 -f null -
更简单的方法是使用的ffmpeg的文件从一个在其ID3标签故障持续时间复制。 这将导致它写入正确的信息。
ffmpeg -i "audio.mp3" -acodec copy "audio_fixed.mp3"
由于它采用复制它需要的原始编码所花费的时间的一小部分。 这是一首难以察觉，但你真的有7小时有声读物欣赏它。 重新编码后，ID3“持续时间”标签现在有正确的信息。
文章来源: How to get the real, actual duration of an MP3 file (VBR or CBR) server-side
