我有来自 Twitter/x 的这个 m3u8 播放列表，其中有这个块：
#EXTINF:2.923,
chunk_1701372432609842942_707_a.aac
#EXT-X-PROGRAM-DATE-TIME:2023-11-30T19:27:21.236Z
正如您所见，该块的持续时间为2.923。
我尝试使用 ffprobe 检查持续时间：
ffprobe chunk_1701372432609842942_707_a.aac 2>&1 | grep "Duration"
输出：
Duration: 00:00:03.17, bitrate: 100 kb/s
我也尝试将其转换为 mp3，但它给出了不同的持续时间：
ffmpeg -i chunk_1701372432609842942_707_a.aac -acodec libmp3lame -b:a 192k output.mp3
mp3 文件的时长：
Duration: 00:00:02.95, start: 0.023021, bitrate: 197 kb/s
发生了什么事？哪个持续时间是真实的？
答案1
这bitrate: 100 kb/s表明它是一种可变比特率编码。
可变比特率编码有一个问题，那就是您必须 100% 解码整个文件才能获得真实时长，因为每个块的比特率可能与上一个不同。文件前面可能有标题描述有多少个数据块，但每个块的解码音频数据量（以及时长）在某种程度上是任意的。
结果是，通过解码可变比特率文件中的第一个块，您可以获得不反映音频文件真实持续时间的持续时间。
根据MP4 文件中的 AAC 流时长错误。如何修复？您可以使用以下方法完全解码文件以获取“真实”持续时间ffmpeg -i chunk_1701372432609842942_707_a.aac -f null -
MP3 还有一个其他格式可能存在或不存在的问题。
从如何使用 foobar2000 和 Audacity 手动修复 mp3 文件中的无缝信息：
Mp3 本身并不是一种无缝格式——文件的开头和结尾都有静默填充。为了解决这个问题，在文件中嵌入元数据来告诉 mp3 播放器填充的长度，以便它可以跳过播放静音部分。
还：LAME 技术常见问题解答（LAME 是一个 MP3 编码器）
文件开始时的解码器延迟：
我测试过的所有*解码器*都会引入 528 个样本的延迟。也就是说，解码 mp3 文件后，输出将在前面附加 528 个 0 样本。这是因为 ISO 使用的标准 MDCT/滤波器组例程具有 528 个样本延迟。可以编写一个具有 0 个样本延迟的 MDCT/滤波器组例程（请参阅下面 LAME 编码中使用的 Takehiro 的 MDCT/滤波器组例程的描述），但我不知道是否有人这样做过。
并且文件末尾也有相关的填充。
这两者都会再次影响文件显示的持续时间。
我首先会信任原始的 M3U 播放列表文件，然后如果有疑问，则使用可以解码整个文件的程序（例如 Audacity）检查实际音频数据。