音頻編解碼器原理：由 PCM、MP3、Opus 到 FLAC 與神經網絡壓縮

PCM（Pulse Code Modulation，脈衝編碼調變）以數值表示不同取樣時刻的振幅。CD 使用的線性 PCM每秒有 44,100 個樣本，每個樣本佔 16 位元，合共兩個聲道：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〉試聽，都是開發歷程的一部分；MP3 並不是一個人獨力創造的技術。

編碼器透過濾波器組及 MDCT 等轉換分析聲音，並考慮聽覺掩蔽效應，調整量化誤差和位元分配。這不只是把「聽不到的聲音刪掉」，而是在有限的位元預算內，令編碼誤差較不易被察覺。

128 kbps 約為 1,411.2 kbps 的十一分之一，但這只是位元率比例。實際音質取決於編碼器、設定、音源及聆聽條件，不能保證所有情況下都與 CD 難以分辨。

AAC（Advanced Audio Coding）是 MPEG 標準化的一系列音頻編碼技術。不能用「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 差。官方把 Vorbis 描述為可自由實作的格式，但分發軟件時，仍須另外核對所用實作的授權條款。

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」的通用換算，也不能斷言 Opus 在所有用途下都是最佳選擇。

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 建立採用 Opus 的 WebM 檔案的功能，不能把舊相容性表套用到所有現有環境。

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，輕鬆儲存任何格式。

先按用途決定重點：保存素材看無損性，通話看延遲及抵抗封包遺失的能力，分發看播放相容性和容量。然後以相同輸入及評估條件比較，才不會單憑較低位元率作選擇。