音訊編解碼器解析：從 PCM、MP3、Opus 到 FLAC 與神經網路壓縮

PCM（Pulse Code Modulation，脈衝編碼調變）以數值表示各個取樣時刻的振幅。CD 的線性 PCM每秒取樣 44,100 次，每個樣本為 16 位元，使用 2 個聲道，因此位元率為 44,100 × 16 × 2 = 1,411,200 bit/s。這些是經過量化的數位樣本，並不是以無限精度保存原始類比波形。

一分鐘的音訊資料為 1,411,200 × 60 ÷ 8 = 10,584,000 位元組，以十進位表示為 10.584 MB，不含標頭等額外資料。音樂 CD 與資料 CD 的磁區用途不同，不能直接把資料 CD 的「650 MB」容量代入這個公式，藉此解釋音樂 CD 的播放時間。

電話使用的 G.711 每秒取樣 8,000 次，每個樣本編成 8 位元的碼字，因此為 64 kbps。它採用 A-law 或 μ-law 非線性量化，量化特性與適用的音訊頻寬都不同於 CD 的 16 位元線性 PCM。只知道「PCM」這個名稱，還無法判斷音質或資料量。

MP3 的名稱來自 MPEG-1 Audio Layer III。ISO/IEC 11172-3 於 1993 年發布，Fraunhofer IIS 則在 1995 年 7 月 14 日透過內部投票選定「.mp3」副檔名。Karlheinz Brandenburg 等人的研究，以及使用 Suzanne Vega 難以編碼的無伴奏版〈Tom’s Diner〉進行試聽，都是這段發展史的一部分。這項技術並非由一個人獨力完成。

編碼器利用濾波器組與 MDCT 等轉換分析聲音，再依據聽覺遮蔽效應調整量化誤差與位元分配。這不只是「刪除聽不見的聲音」，而是在有限的位元預算內，讓編碼誤差較不容易被察覺。

128 kbps 約為 1,411.2 kbps 的 1/11，但這只是位元率的比例。音質仍取決於編碼器、設定、音源與聆聽條件，不能保證任何情況下都與 CD 聽不出差別。

AAC（Advanced Audio Coding）是由 MPEG 標準化的一系列音訊編碼技術。它與 MP3 之間不存在「AAC 128 kbps 等於 MP3 192 kbps」這類固定換算。比較時除了格式名稱，還要確認 Profile、編碼器、設定與音源等條件。

表格來源：Via Licensing Alliance: Advanced Audio Coding (AAC)。這是功能摘要，不是音質排名。

更有效率地表示高頻或立體聲資訊，不代表低位元率的輸出一定能與原音完全相同。也要確認解碼器與目標播放環境是否支援。專利與軟體授權則在文末分開討論。

Xiph.Org 的 Vorbis 是具備公開規格的通用有損音訊編解碼器。它與 MP3 一樣，透過轉換編碼及聽覺特性，在有限的資料量內維持聽感品質。

Vorbis 是編解碼器，Ogg 是容器。Ogg 檔案不一定使用 Vorbis，也可以容納 Opus 等編碼。同樣地，只看 WebM 或 MP4 這些名稱，也無法確定內部採用哪種音訊編碼。

不能永遠把 Vorbis 排在 MP3 之上、AAC 之下。官方將它描述為可自由實作的格式，但若要散布軟體，仍須另外確認所採用實作的授權條件。

Opus 由 2012 年 9 月的 RFC 6716 定義，結合採用預測編碼的 SILK 技術與採用 MDCT 的 CELT 技術。依設定與音訊頻寬，可以使用 SILK 單獨模式、混合模式或 CELT 單獨模式；並非每個封包都同時使用兩種方式。

表格來源：IETF Datatracker: RFC 6716 - Definition of the Opus Audio Codec。端到端延遲也取決於網路與播放條件。

最短音框或演算法延遲，不等於通話從發話端到接收端的總延遲。RFC 7874 要求 WebRTC 端點實作 Opus，以及 G.711 的 PCMA／PCMU，並不是只有 Opus 為必要項目。

官方比較資料除了試聽測試結果，也包含在缺乏資料之處以經驗性資訊補充的概略圖。官方並不建議從圖中讀取特定位元率的精確數值。因此不能推導出「Opus 64 kbps 等於 MP3 128 kbps」這種通用換算，也不能斷言它在所有用途下都最優。

FLAC（Free Lossless Audio Codec）是無損壓縮格式，解碼時能精確還原輸入的 PCM 樣本。它利用音訊中的規律，例如有效率地編碼預測樣本與實際樣本之間的差值。RFC 9639 也定義了這個格式。

「一個位元都不損失」指的是音訊樣本，不代表原始 WAV 檔案的所有中繼資料、區塊順序或整份檔案的位元組序列都完全相同。把 MP3 轉成 FLAC，也無法找回先前 MP3 編碼時已經丟失的資訊。

壓縮後的大小取決於音源與設定。靜音與雜訊的可預測程度不同，因此不保證永遠縮小到原來的 50–70%。保存原始素材或準備後續編輯時，除了容量，也應考慮無損特性。

神經網路編解碼器使用訓練後的編碼器，把波形轉成精簡的表示，再由解碼器根據量化資訊重建波形。SoundStream 的殘差向量量化（RVQ）使用多層碼本，後面的階段表示前一階段留下的誤差。這不是能與原始 PCM 完全一致的無損壓縮。

不要混淆 Lyra 與 SoundStream

Google 在 2021 年介紹的初代 Lyra 是面向通話語音的 3 kbps 編碼方式，與後來的 SoundStream 並非同一個模型。2022 年的 Lyra V2 以 SoundStream 為基礎，支援 3.2、6、9.2 kbps。把 V2 標成 3 kbps 並不正確。

SoundStream 的發表資料指出，其 3 kbps 配置在測試中優於 Opus 12 kbps，但這是當時模型、資料與評估條件下的結果，不能證明 CD 立體聲音樂能以同等品質壓到 3 kbps。訓練與推論的運算需求也要分開看，不能認為神經網路編碼一定需要 GPU。

EnCodec 的模型條件

2022 年的 EnCodec 論文涵蓋 24 kHz 單聲道與 48 kHz 立體聲配置。不能把各模型的低位元率選項合併成一個範圍，就認為每個模型在相同條件下都支援所有選項。透過語言模型進一步壓縮，是對學習得到的表示再進行編碼的階段。論文所說的「最高 40%」不是固定的節省比例。

以近似方式重建輸入，可能使人聲音色或背景聲音產生失真。評估時應使用符合用途的音源，一併考慮傳輸頻寬、語音清晰度、音樂重現品質與執行時間。

以下假設位元率固定，或使用平均位元率，僅計算音訊負載資料（payload）。採用十進位單位：1 kbps = 1,000 bit/s、1 kB = 1,000 位元組、1 MB = 1,000,000 位元組。將以 bit/s 表示的位元率乘以 60 秒，再除以 8，即為位元組數。不含容器、中繼資料、封包標頭、重傳與模型散布的額外資料。

表格計算：NanToo 編輯部，依上述 60 秒、十進位單位、僅計負載資料的公式計算。Lyra 設定值依據 Google Research: Lyra: A New Very Low-Bitrate Codec for Speech Compression 與 Google Open Source Blog: Lyra V2 - a better, faster, and more versatile speech codec。

同樣是 60 秒，音訊頻寬、聲道數與音源仍可能不同，這不是音質排名表。任意輸入的 FLAC 並沒有固定平均位元率，應測量實際編碼結果。使用可變位元率（VBR）時，也要區分設定值與實測平均值。

MediaRecorder 是錄製 MediaStream 的 API。WebM、MP4 等容器，與 Opus、AAC 等編解碼器是不同的要素。支援情況會隨作業系統、瀏覽器及版本而改變。

Safari 並非只能錄製 AAC。WebKit 已宣布在 Safari 18.4 加入透過 MediaRecorder 建立 WebM 並使用 Opus 的支援，不應把舊版相容性表套用到所有現有環境。

1. 先確認 MediaRecorder 是否存在。
2. 使用 MediaRecorder.isTypeSupported("audio/webm;codecs=opus") 等呼叫檢查候選格式。
3. 即使回傳 true，仍須處理錄製失敗，例如資源不足的情況。
4. 檢查 recorder.mimeType 與實際輸出，再選擇相符的副檔名與播放環境。

NanToo 的錄音工具（日文版）也會選擇支援的候選格式，並在錄音清單中顯示依輸出 MIME 類型判定的格式名稱。

編解碼規格公開、實作程式碼的使用授權、專利授權，以及訓練後模型的使用條件，是不同層面的事情。

表格來源：Fraunhofer IIS: mp3 / Via Licensing Alliance: Advanced Audio Coding (AAC) / Opus Codec: License – Opus Codec / GitHub / google: A Very Low-Bitrate Codec for Speech Compression / GitHub / facebookresearch: EnCodec: High Fidelity Neural Audio Compression。這些項目用來區分各項散布內容與授權條件。

瀏覽器也已有 WebCodecs 的 AudioEncoder／AudioDecoder 等較低階 API。不過 API 存在不代表特定編解碼器一定可用，把輸出封裝進容器也是另一項工作。它們不是能直接取代 MediaRecorder、輕鬆儲存任何格式的功能。

先確定用途：保存素材重視無損，通話重視延遲與封包遺失容忍度，散布則重視播放相容性與容量。再用相同輸入與評估條件比較，才不會只憑位元率較小就做決定。