這個圖表顯示的是

FFmpeg 在 單一線程(某些audio codec先天限制)下 比 PAT(你的多線程轉碼程式)慢

有損codec 大概慢了 5.7x~6.1x
無損codec 大概慢了 1.68x~1.83x

如果這樣來看的話， PAT的單執行緒效率其實是落後於FFmpeg的



以FFmpeg多核心的轉碼方法來測試的話，結果應該是FFmpeg反超PAT一截

（以有損code為例）

1、取得wav檔時間總長 9031秒，分成15段的話每段約602秒

2、用FFmpeg 的切塊指令 把原檔切成15個wave檔，然後用腳本一次叫出15個ffmpeg對個別切片檔作平行轉檔

3、這時 16核的cpu使用率應該都吃滿了

4、腳本監測 15個 task 都成功執行完畢後，把15個結果檔 用FFmpeg 依序 join成一個輸出檔

5、源檔、15個切片檔、15個轉碼檔、最終輸出檔 全都丟在 tmpfs(記憶體中)，所有的讀寫都以接近記憶體寬的速率操作

根據以往的經驗，這種作法雖然達不到15倍速，但至少會有13x~14x的速度

您可以抽時間 測試看看



另外，這種方法很早就有了，但為什麼各大影音轉檔論壇現在幾乎都比較少見這類 多核平行編碼的作法，是有原因的…


因為，速度上來了沒錯，但會有產生「接縫瑕疵（Gapless Playback ）」的問題…

有損音訊格式（如 MP3、AAC）在編碼時會因為演算法特性產生 Padding（填充無聲資料） 與 Encoder Delay（編碼延遲）：

如果你切成多段轉檔後再組回一個大檔，連接處可能會出現 微小的咔噠聲（Click/Pop）或極短的無聲音訊。

在連續播放（如交響樂、演唱會錄音）時，這種無縫接軌如果發生失敗的話，會非常明顯。

推測 PAT的內部作法，一樣是把切成多個stream來讓多個CPU核心平行編碼來達到加速，只要是這類作法，就很難避開上面提到的問題…