我正在嘗試使用命令列工具提取音訊片段。我得到了一致的、意想不到的結果，我相信這是由於音訊檔案的創建/編碼方式造成的。
注意：我意識到還有其他方法來分享內容，我這樣做是為了與不太懂電腦或無法存取原始內容的使用者分享內容。
問題描述/重現步驟：
我首先使用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 毫秒開始。
無論如何，我試圖將其重置為零，嘗試各種變化這個答案，我沒有成功。
我正在尋找了解提取的片段中錯誤的根本原因並進行更正。
答案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在這種情況下您根本不需要開始。