PCDVD數位科技討論區 - 花了兩天的時間用了GPT-6 Astra Ultra Level寫了一個音訊轉碼器

PCDVD數位科技討論區 (https://www.pcdvd.com.tw/index.php)

- 七嘴八舌異言堂 (https://www.pcdvd.com.tw/forumdisplay.php?f=12)

- - 花了兩天的時間用了GPT-6 Astra Ultra Level寫了一個音訊轉碼器 (https://www.pcdvd.com.tw/showthread.php?t=1219361)

引用:

作者a9607

這個圖表顯示的是

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倍...

對我而言，這個問題的重點是，當你把WAV切開，再編碼尤其是AAC及MP3時，會有兩個明顯的障礙：
1.你需要極大的RAM或硬碟空間，如果你的原始WAV是六聲道超高精度，32bits等等。
2.FFmpeg對音訊天生沒有多線程及綁定實體核心加速的編碼方式，因此縱使有你提到的Gapless問題，但他現在還是最快的。

gapless的問題，我在用AI寫這個轉碼器的時候就想過了。但是這是一個可以考慮改進的方向。
至於切塊轉碼沒有快過FFmpeg，這我還會再改進切塊的算法跟分配。

最後，我這個轉碼器會試著直接從AAC轉MP3，反之亦然。並沒有一定要靠WAV。
我是個懶人，有的人會說為什麼不做一個GUI的FFmpeg自動切塊多核心就好，是的，現在任何人都可以這樣做，我之所以做PAT是因為跟AI討論的時候，他自己就開始花我的token實作了，所以將錯就錯把它做完了。

附帶提到一件事：
關於gapless的問題，當你將MP3先轉成WAV的時候是會失真的，這時候再把WAV切塊然後轉成AAC時，又會失真一次，而且還是會產生gapless的問題。反之亦然。

PAT的做法是直接轉成PCM，這是唯一不會失真的方法，但是仍然可能會有gapless的問題。

請問你為什麼要實作這個音訊轉碼器 ?
通常使用的場景是 ?

引用:

作者che

請問你為什麼要實作這個音訊轉碼器 ?
通常使用的場景是 ?

沒有什麼特別的使用場景，主要是不想浪費電腦的硬體，有這麼多的核心，又有這麼大的RAM，但是卻只能單線程，再加上超大檔的轉碼速度在單線程下其實有點慢，至少我懶得等。
事實證明，如果真的能多線程配合超大的RAM，得到的速度是值得的，雖然有gapless的問題。

簡單測試

真的有比較快

一首 FLAC 轉成 MP3

Parallel Audio Transcoder GPU 只需要 5 秒

FreemakeAudioConverter 需要 17 秒

可惜沒有批次轉檔
或是沒找到哪邊可以設定

ffmpeg 要發揮多核心主要是靠單一指令對多檔案同時處理，這個就不限格式全都有效，也就會吃倍數的記憶體。其實音訊壓縮如果真有很多檔案的話，用 ffmpeg 那種就行了，也沒有分割會有的問題。音訊檔案處理已經很快了，再快也就那樣，除非你能想出什麼真的全新的功能來做。

程式在讀取多語系名稱檔案有點問題，支援的輸入格式也不夠多，加上gui裡面的一些bug，只能說再加油吧，但加油到最後也就還是那樣，一個嶄新的輪子。

引用:

作者bpoff

你好，對於很大的音檔，還是有價值。
我再考慮下一個版本，而且會嚴格要求gapless問題的減少。

gui的bug有哪些？

我到是沒想過用FFmpeg同時對多個檔案並行運算，這真是一個好思路。

另外還要再提一點，現在這個版本的MP3轉碼，其實已經嚴格限制gapless的發生。
不可能不會或永遠不發生gapless的問題，但是已經將問題減低到讓人聽不出來的程度。
至少是數學模型修正的合法容忍範圍內。一開始的時候，編碼器也修正改寫過，肯定不會時常發生gapless的問題，如果讓你遇上了，你應該去買樂透！

最後，說到嶄新的輪子這件事，或許對AI來說解決gapless是相對容易的事，但可惜的是人類最終在面對並行轉碼時選擇了單一線程這條路。這讓我想到三十年前，花一整晚去轉歌的日子。

gap 問題聽不出來是一回事，但如果已知可能的話一般人會直接避免，不會想要轉完還要檢查，檢查的時間比轉多上幾十倍可能都不只。gui 的問題例如恢復預設不會完全恢復預設，其他我沒認真看了，畢竟你的輸入格式太少，對我來說根本找不到用這個的理由。還有不需要用輸入格式來限制輸出格式，假如一個 flac 低壓縮想重新轉成高壓縮？這樣你限制就沒道理了。

像目前 libflac 已經有 multithread，也可以直接呼叫這個就好了。

引用:

作者bpoff

你希望再加入哪些格式？

如你只是自用的話那不用再問我了，我只是隨便提供一點意見而已，坦白說這軟體我用不到。我覺得你看起來也只像是寫好玩的，所以你自己沒問題就可以了。除非你真的想要精益求精，那樣的話你該先多研究其他常見軟體能做到什麼。