花了兩天的時間用了GPT-6 Astra Ultra Level寫了一個音訊轉碼器
 

真的太神奇了！

我的想法很簡單
1.能夠利用多核加速轉碼
2.能夠利用大容量的RAM提高轉碼速度。
3.把音訊拆成非常多小塊來轉碼。

結果是成功的！
而且如果你的音檔非常大的時候，是會變得非常快的。

我放我的程式上來給各位試用。
另外，這個程式有公有領域的授權等法律問題，所以我「單純」只是在這裡做功能性測試的分享！還沒有正式算發佈！所以不要找我算帳！

檔案下載

自已推一下…

因為一些原因，鏈結斷了，現在補上。
在超長的音檔「兩個小時以上」或超大的音檔「四到六GB以上」，我這個轉碼器有十足的速度優勢。
不過建議在至少有超過八核的CPU及至少64GB的記憶體來運行！

請問一下, 和 FFMPEG 比起來速度又如何?
我用不到轉碼, 但有對照表, 速度快了多少, 應該會更吸引有興趣的人才是

我自己用Fabelman的WAV音軌總長是兩小時三十分三十一秒，轉換成FLAC最多只要花三分鍾。

你的建議我聽到了，但是請你提供你想看到的比較方式，我再來看看能不能做成比較表給你看。

好強

五分奉上

若能教學 怎麼自己程式設計 就可以用在不同領域

感謝分享

希望你能提供你轉碼的心得，看看是否真的極大的改善轉碼的速度。謝謝！

我沒有你的專業, 不確定要比較到那個地步才會對你們同業的有吸引力. 不過就市井小民的話, 大楖是
1. 用同一個音源檔案, 去比較FFMPEG和你的程式轉檔時間
2. 來源音源檔, 可選幾個主流的 codec, 比如 aac. flac...等, 然後有高/低 bitrate
3. 轉出來的檔案也選幾個主流的 codec 和高/低 bitrate

這樣應該可以看出來
1. 高/低 bitrate aac/mp3 -> 轉成高/低 bitrate aac/mp3 的效能
2. 哪種 codec 效能較好, 你的程式較吃香, 比如有些 codec 吃 CPU 效能較好, 有些吃 GPU 效能較好

應該可以用 GPT 寫一個批次檔讓你去跑, 或叫 GPT 直接跑結果給你?
這是不專業鄉民的想法, 沒專業很粗淺, 所以就參考參考就好 :ase

我用Fabelman的WAV檔，全長是兩小時三十分三十一秒，大小是1.61GB，位元速率是1536kbps，雙聲道立體聲，音訊取樣率是48000Hz，取樣位元數是16位元，WAV容器格式是PCM S16LE。

PAT轉MP3的設定是，取樣率48000Hz，使用VBR變動位元速率，雙聲道立體聲，VBR品質是V0最高品質，重取樣品質用高品質，超幅處理是使用全檔一致，低通的頻寬是20000Hz，VBR最低位元率選自動，最高位元率也是自動。不啟用自動混音，不保留文字標籤，不保留封面，關閉額外驗證。


啟用GPU輔助，總共用時：三十五點八百四十一秒！總大小是兩百六十七MB。
不啟用GPU輔助，總共用時：二十七點四百七十秒！總大小是兩百六十七MB。

PAT轉AAC的設定是，取樣率48000Hz，使用AAC-LC編碼類型，用M4A檔案容器格式，使用VBR變動位元速率，VBR品質是5最高品質，雙聲道立體聲，啟用Afterburner品質強化，重取樣品質用高品質，超幅處理是使用全檔一致，低通的頻寬是20000Hz。不啟用自動混音，不保留文字標籤，不保留封面，關閉額外驗證。


啟用GPU輔助，總共用時：二十九點五百二十八秒！總大小是兩百一十一MB。
不啟用GPU輔助，總共用時：二十六點六百五十秒！總大小是兩百一十一MB。

PAT轉FLAC並用8192區塊的設定是，選用浮點量化，壓縮等級是8，整數位深是24bit整數PCM，取樣率48000Hz，雙聲道立體聲，重取樣品質用高品質，超幅處理是使用全檔一致，低通的頻寬是20000Hz。量化抖動是自動，不啟用自動混音，不保留文字標籤，不保留封面，索引間隔是每一秒一個，編碼區塊大小是8192，預測器用LPC，LPC階數是32階。關閉額外驗證。


啟用GPU輔助，總共用時：五十一點八百八十一秒！總大小是六百七十MB。
不啟用GPU輔助，總共用時：四十九點二百一十秒！總大小是六百七十MB。

PAT轉FLAC並用4096區塊的設定是，選用浮點量化，壓縮等級是8，整數位深是24bit整數PCM，取樣率48000Hz，雙聲道立體聲，重取樣品質用高品質，超幅處理是使用全檔一致，低通的頻寬是20000Hz。量化抖動是自動，不啟用自動混音，不保留文字標籤，不保留封面，索引間隔是每一秒一個，編碼區塊大小是4096，預測器用LPC，LPC階數是32階。關閉額外驗證。


啟用GPU輔助，總共用時：四十六點九百零二秒！總大小是六百七十MB。
不啟用GPU輔助，總共用時：四十六點五百二十四秒！總大小是六百七十MB。

以上設定，我全採用我所知的最高品質的設定，而且都是選用大部份人最常用的選項，不在乎轉碼後的檔案總大小，但是會最小化轉碼後每一秒的大小。

我的硬體是4070 12GB，PAT在運行時會啟用4GB的顯存。而我有64GB的DDR4四通道，PAT轉碼會保留約40GB內存給轉碼用，而運行的時候會佔用到約5GB的內存。
我的CPU是XEON E5-2697AV4，有十六個實體核心，實際在轉碼的實體核心有十五個，總是超頻到3GHz。

基本上我不建議所有的人都開GPU輔助，因為其實在我自已的測試中，雖然會再快一點點，但是，也就那麼一點點，絕大多數的時候並不會很明顯的更快，除非你用的是12GB以上的版本。
再加上，不是每一個會用到轉碼的人，他的電腦會裝這麼好的N卡。而且要靠GPU輔助，你還要有PCIE5.0或4.0才會產生有效的差別。

另外，我提供我用來測試的Fabelman WAV給大家下載，很大1.61GB。
測試用的Fabelman WAV檔

我也很想用FFmpeg來比較，但是我想來想去，因為已經多核轉碼了，這就要考慮你是用AMD或是Intel的CPU，因為AMD舊的Ryzen多核是對稱式的，Threadripper及EPYC更是，但是Intel就有大小核的問題。
這樣基本上沒辦法比較。
另外還要看你用的是DDR5或是DDR4，再看你有幾通道。
所以我實在沒想過要怎麼用FFmpeg做相對公平的比較。
PCIE5跟4，還有你用的是不是NVME SSD都會影響。
我用的是四個一組的SATA RAID0 HDD。

如果用我自已的電腦來比較FFmpeg我得到的答案是：
案例MP3-V0 平均時間160.258049 最短時間159.784606 最長時間160.89861
案例AAC-VBR5 平均時間164.810699 最短時間164.33422 最長時間165.569188
案例FLAC-8192 平均時間83.656338 最短時間83.126785 最長時間84.179587
案例FLAC-4096 平均時間86.011578 最短時間85.584775 最長時間86.538704

＋＝＝＝＝＝＝＝＝＝＝＝＝＋＝＝＝＝＝＝＝＝＝＝＋＝＝＝＝＝＝＝＝＝＝＋
｜　　　　轉碼設定　　　　｜　ＦＦｍｐｅｇ用時　｜　ＰＡＴ無顯卡用時　｜
＋＝＝＝＝＝＝＝＝＝＝＝＝＋＝＝＝＝＝＝＝＝＝＝＋＝＝＝＝＝＝＝＝＝＝＋
｜ＭＰ３品質Ｖ０　　　　　｜　　１５８．７１０秒｜　　　２７．４７０秒｜
｜ＡＡＣ品質５　　　　　　｜　　１６４．１９８秒｜　　　２６．６５０秒｜
｜ＦＬＡＣ區塊８１９２　　｜　　　８２．９５６秒｜　　　４９．２１０秒｜
｜ＦＬＡＣ區塊４０９６　　｜　　　８５．４０８秒｜　　　４６．５２４秒｜
＋＝＝＝＝＝＝＝＝＝＝＝＝＋＝＝＝＝＝＝＝＝＝＝＋＝＝＝＝＝＝＝＝＝＝＋
｜　　　　統計方式　　　　｜　五次單線程中位數　｜　一次多核心用時　　｜
＋＝＝＝＝＝＝＝＝＝＝＝＝＋＝＝＝＝＝＝＝＝＝＝＋＝＝＝＝＝＝＝＝＝＝＋

因為PAT跑五次取中位數是沒有意義的，所以只跑一次就取數了。
而且，已經很明顯看到，PAT的轉碼速度是遠快過FFmpeg的。

我還特別要求FFmpeg要啟用15個實體核心配上15個執行緒來轉碼，真正的問題在FFmpeg中以上三個codec只能以單線程的型式運行在一個實體核心，所以FFmpeg是無法跟PAT比轉碼速度的。

這樣大家應該明白，PAT在實體核心數多且RAM又大的電腦上會給大家多大的速度幫助。
如果你是DDR5雙通道，其實應該會非常快，因為我的DDR4四通道最多也只能跑2400MHz。
當然如果你有EPYC或Threadripper會超級快！

最後NVME SSD跟PCIE5理論上也可以非常明顯的加速。

這個圖表顯示的是

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

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

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

:ase

以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的速度

您可以抽時間 測試看看

:agree:

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


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

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

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

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

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

:ase