我正在尝试使用命令行工具提取音频片段。我得到了一致的、意想不到的结果，我相信这是由于音频文件的创建/编码方式造成的。
注意：我意识到还有其他方法可以共享内容，我这样做是为了与不太懂计算机或无法从原始内容中获得地理限制的用户共享内容。
问题描述/复现步骤：
我首先使用yt-dlp下载播客，例如这个使用以下命令：
yt-dlp -x --audio-format mp3 -o GQT_2012-10-14.mp3 https://www.bbc.co.uk/programmes/b01n6vnh文件已下载并正确播放。我想提取一段从 20:48 开始、持续 03:58 的片段，以便它在 24:46 结束
我首先尝试使用FFmpeg（Ubuntu 20.04 上的版本 4.2.7-0ubuntu0.1），使用以下命令：
ffmpeg -i "/home/user/GQT_2012-10-14.mp3" -ss 00:20:48 -t 00:03:58 GQT_2012-10-12_Snippet1.mp3
这将生成一个长 3 分 58 秒的文件，但开始时间对应于原始文件中的 20:28。然后我尝试使用Mp3Splt（同一操作系统上的版本 2.6.2。我知道这是一个旧版本），使用以下命令：
mp3splt "/home/user/GQT_2012-10-14.mp3" -o GQT_2012-10-12_Snippet1 20.48.00 24.46.00
这将生成相同的输出，即一个长度正确但比预期开始时间提前 20 秒的文件。
如果两个命令行工具的结果相同，则表明问题出在输入文件上。我尝试使用 对其进行检查ffprobe。在输出中，我看到了以下内容：
Duration: 00:43:00.09, start: 0.025057, bitrate: 141 kb/s我将其解释为文件被“标记”为从 25 毫秒开始。当然不是 20 秒。
我尝试将其重置为零，尝试了各种方法这个答案，我没有成功。
我正在寻找以了解提取的片段中错误的根本原因并进行纠正。
答案1
我对您提供的文件做了一些测试，我相信您的 ffmpeg 命令实际上会在您要求的确切位置剪切文件。
我认为实际问题是玩家在定位时显示错误的时间戳（我尝试了vlc和mplayer，它们的行为似乎相似）：如果我让vlc文件从头开始播放而不向前定位（实际上我让它在后台运行 20 分钟！），当它到达 20:48 时，它恰好位于 ffmpeg 生成的文件的开始位置！如果我改为从 开始播放vlc，然后向前跳过，那么该位置将显示为 20:28！我的猜测是，在这些播放器上定位只是跳到下一个关键帧（或类似的东西？不太熟悉 mp3 格式的内部结构）并且仅根据比特率（变量）估计经过的时间。您可以通过运行 vlc 并在接近结尾时定位并查看 vlc 继续播放超过 43 分钟（我尝试在 42:42 定位，它播放到 43:08）来很好地演示这种效果。
总之，要获取 mp3 中的准确时间，使用播放器（如vlc或 ）显示的时间戳mplayer似乎不是一个好选择。相反，您可以使用一些音频编辑程序，如audacity，它在开始时解码整个文件，因此时间应该是准确的。当然，您也可以将其用于剪切部分，因此ffmpeg在这种情况下您根本不需要它。