Web 音訊編解碼指南

下面的列表指出了 Web 上最常用的編解碼器以及支援它們的容器（檔案型別）。如果您只需要知道可以使用哪些編解碼器，那麼這就是適合您的內容。當然，各個瀏覽器可能選擇支援或不支援所有這些編解碼器，並且它們對哪些容器型別可以使用這些編解碼器的支援也可能有所不同。此外，瀏覽器可以選擇支援此列表中未包含的其他編解碼器。

影響音訊編解碼器編碼器輸出的編碼音訊的因素一般分為兩類：有關源音訊格式和內容的詳細資訊，以及編碼過程中的編解碼器及其配置。

對於每個影響編碼音訊的因素，都有一條几乎總是正確的簡單規則：因為數字音訊的保真度是由用於將其轉換為資料流的取樣樣本的粒度和精度決定的，所以用於表示音訊數字版本的資料越多，取樣聲音與源材料的匹配程度就越高。

由於編碼音訊本質上使用更少的位來表示每個樣本，因此源音訊格式實際上可能對編碼音訊大小的影響不如人們預期的那樣大。但是，許多因素仍然會影響編碼音訊的質量和大小。下表列出了許多關鍵的源音訊檔案格式因素及其對編碼音訊的影響。

當然，這些影響可以透過編碼音訊時做出的決定來改變。例如，如果編碼器配置為降低取樣率，則取樣率對輸出檔案的影響將相應降低。

有關音訊資料的這些和其他功能的更多資訊，請參閱音訊資料格式和結構。

音訊編解碼器通常採用巧妙設計且高度複雜的數學演算法來獲取源音訊資料並對其進行壓縮，以便在記憶體或網路頻寬中佔用更少的空間。除了選擇要使用的編碼器型別外，您還可以有機會使用引數調整編碼器，這些引數可以選擇特定的演算法、調整這些演算法並指定在編碼時應用多少次傳遞。

可用的引數（以及可能值的範圍）因編解碼器而異，甚至在同一編解碼器的不同編碼實用程式之間也存在差異，因此請閱讀您使用的編碼軟體附帶的文件以瞭解更多資訊。

幾個因素會影響編碼音訊的大小。其中一些是源音訊形式的問題；另一些則與編碼音訊時做出的決策有關。

無損編解碼器與有損編解碼器

音訊壓縮主要分為兩類。**無損**壓縮演算法在不影響聲音質量或保真度的情況下減小音訊的大小。解碼使用無損編解碼器（如FLAC或ALAC）壓縮的音訊後，結果在各個方面都與原始聲音相同，精確到每個位。

有損編解碼器則利用了人耳並非完美的音訊直譯器，以及人腦可以從不完美或嘈雜的音訊中提取重要資訊的事實。它們去除掉很少使用的音訊頻率，容忍解碼輸出的精度損失，並使用其他方法來損失音訊內容、質量和保真度，從而生成更小的編碼媒體。解碼後，輸出在不同程度上仍然可以理解。使用的特定編解碼器（以及選擇的壓縮配置）決定了人耳聽到的輸出與原始未壓縮音訊訊號的接近程度。

由於有損編解碼器的工作方式與無損編解碼器不同，尤其是無損編解碼器必須對其壓縮更加保守，因此有損編解碼器幾乎總是產生比無損編解碼器小得多的壓縮音訊。

一般來說，選擇無損音訊的最常見原因是需要檔案級儲存，或者音訊樣本將被重新混音和重新壓縮，並且希望避免由於重新壓縮導致音訊中出現偽影的放大。對於音訊的即時流傳輸，通常需要有損編解碼器，以確保資料流能夠跟上音訊播放速率，而不管網路效能如何。

提供給聲音系統中每個揚聲器的音訊由流中的一個音訊聲道提供。單聲道聲音是一個聲道。立體聲是兩個聲道。5.1環繞聲有五個音訊聲道，加上一個低頻增強（LFE）聲道。

LFE聲道專門設計用於儲存低頻音訊資料，並且通常用於提供例如低音炮的音訊資料。當您看到以X.Y形式（例如2.1或5.1）編寫的音訊聲道數時，小數點後的數字Y是LFE聲道的數量。例如，MP3支援一個LFE聲道，而AAC最多支援16個。

除了為聲音系統中的特定揚聲器提供音訊外，某些編解碼器還可以允許使用音訊聲道提供替代音訊，例如不同語言的語音或視障人士的描述性音訊。

編解碼器的音訊頻率頻寬指示可以使用該編解碼器表示的音訊頻率範圍。一些編解碼器專門透過消除落在給定頻率範圍之外的音訊來工作。取樣率與編解碼器表示的波形的最大聲音訊率之間存在相關性。在理論上，編解碼器可以表示的最大頻率是取樣率除以二；此頻率稱為奈奎斯特頻率。實際上，最大值略低，但非常接近。

當編解碼器設計或配置為表示人類語音而不是廣泛的聲音時，音訊頻率頻寬尤其明顯。人類語音通常位於300 Hz到18 kHz的音訊頻率範圍內。但是，絕大多數人類發聲存在於300 Hz到8 kHz的範圍內，並且您可以在500 Hz到3 kHz的頻率範圍內捕獲足夠的人類發聲，仍然可以理解。

因此，特定於語音的編解碼器通常首先丟棄落在設定範圍之外的聲音。該範圍是音訊頻率頻寬。例如，G.722 去除了 50 Hz 到 7 kHz 音訊頻率頻寬之外的聲音。這從一開始就減少了需要編碼的資料量。

下面我們將簡要介紹每個編解碼器，瞭解其基本功能和主要用例。

高階音訊編碼（AAC）編解碼器定義為MPEG-4（H.264）標準的一部分；具體來說，作為MPEG-4第3部分和MPEG-2第7部分的一部分。AAC旨在能夠以比MP3更高的音訊保真度提供更多壓縮，已成為一種流行的選擇，並且是許多型別媒體（包括藍光光碟和高畫質電視）中音訊的標準格式，以及從iTunes等線上供應商購買歌曲時使用的格式。

AAC有許多配置檔案，定義了針對特定用例壓縮音訊的方法，包括從高品質環繞聲到僅用於語音的低保真音訊等各種情況。

作為一種受專利保護的格式，AAC的支援在某種程度上是不確定的。例如，Firefox僅在作業系統或外部庫提供支援的情況下才支援AAC。

蘋果無損音訊編解碼器（ALAC或Apple Lossless）是由蘋果開發的一種無損編解碼器。在最初是一個封閉格式之後，蘋果將其在Apache許可下開放。

ALAC的跨平臺和瀏覽器支援並不強大，這使其成為不太理想的通用選擇。但是，如果您的目標主要是macOS和iOS使用者，則可能值得考慮，因為作業系統已整合對ALAC的支援。否則，如果您必須使用無損編解碼器，則FLAC可能是更好的選擇。

但是，請記住，無損編解碼器需要大量的頻寬和儲存容量，並且可能不是非常具體的用例之外的理想選擇。

自適應多速率音訊編解碼器針對有效編碼人類語音進行了最佳化。它於1999年作為用於GSM和UMTS蜂窩電話的3GPP音訊標準的一部分被標準化，並使用多速率窄帶演算法以大約7.4 kbps的電話級質量級別對音訊頻率進行編碼。除了用於即時電話外，AMR音訊還可以用於語音郵件和其他短音訊錄音。

儲存在檔案中的AMR音訊可以鍵入.amr，但也可以封裝在.3gp檔案中。

作為一種特定於語音的編解碼器，AMR對於任何其他內容（包括僅包含人聲的音訊）基本上都是無用的。此外，由於AMR旨在最大限度地降低容量要求，因此它僅捕獲理解所說內容絕對必要的完整人類語音音訊頻率頻寬的一部分，因此質量相應降低。如果您需要以最小的網路和/或儲存容量影響來錄製音訊的功能，則AMR可以是一個不錯的選擇。但是，如果您需要高保真地再現人類語音（甚至低質量的音樂再現），則需要選擇其他格式。

FLAC（免費無損音訊編解碼器）是由Xiph.org基金會釋出的一種無損音訊編解碼器。它提供良好的壓縮率，並且不會損失音訊保真度；也就是說，解壓縮的音訊與原始音訊相同。由於壓縮演算法專門針對音訊設計，因此它比使用通用壓縮演算法獲得的結果更好。

FLAC非常適合需要原始質量和音調準確性的較小的音訊效果檔案，以及音樂的存檔。

國際電信聯盟（ITU）釋出的G.711規範於1972年釋出，用於定義電話應用的標準音頻編碼。它支援覆蓋300到3400 Hz頻率的語音級音訊。它廣泛用於電話通訊和語音郵件，並且是可以透過公共電話網路傳輸的最高質量的音訊編碼。

G.711不是高保真編解碼器，而是針對支援各種語音級別（從耳語到喊叫）並在保持高畫質晰度和低計算複雜度的同時進行了最佳化。G.711使用對數壓縮擴充套件演算法，在8位樣本中提供14位的動態範圍。它使用8000樣本/秒的取樣率，對應於64000 bps的位元率。

G.711 有兩種變體，它們指示了演算法的精確數學公式：µ律（通常用於北美和日本）和A律（世界其他地區常用）。這兩種律之間在質量上沒有實質性差異，並且可以輕鬆地將音訊從一種轉換為另一種。然而，在任何回放應用程式或檔案格式中指定使用哪種律都很重要。如果錯誤地使用µ律演算法解壓縮A律音訊，則回放效果會很差，反之亦然。

所有WebRTC解決方案都必須支援此編解碼器，因為它簡單易於實現，並且廣泛用於所有現代計算平臺，並具有廣泛的相容性。

G.722 編解碼器由國際電信聯盟 (ITU) 釋出，專為語音壓縮而設計。其音訊編碼頻寬限制在 50 Hz 至 7,000 Hz 範圍內，涵蓋了典型人類發聲的大部分頻率範圍。這使得它不適合處理任何可能超出人類語音範圍的音訊，例如音樂。

G.722 音訊使用自適應差分脈衝編碼調製 (ADPCM) 進行編碼，其中每個樣本並非由其絕對值表示，而是由一個值表示新樣本與前一個樣本的差異。

G.722 主要用於 WebRTC 連線，因為它是由 WebRTC 規範規定的音訊編解碼器之一。

在 MPEG/MPEG-2 標準指定的音訊格式中，MPEG-1 音訊第 3 層——也稱為MP3——是迄今為止使用最廣泛、最知名的格式。MP3 編解碼器由MPEG-1 第 3 部分和MPEG-2 第 3 部分定義，並於 1991 年推出（並於 1992 年最終確定）。

當 MP3 格式音訊儲存在 MPEG 容器內時，生成的的檔案也被稱為“MP3 檔案”或“MP3”。具有普遍存在的 .mp3 副檔名的檔案儲存在可能是世界上分佈最廣泛的音訊檔案格式中，這在很大程度上推動了 20 世紀 90 年代末和 21 世紀初的數字音訊革命。

MPEG-1 MP3 音訊支援比 MPEG-2 檔案中的 MP3 音訊更高的位元率和更高的取樣率。MPEG-1 格式的 MP3 通常最適合音樂或其他複雜音訊，而 MPEG-2 模式 MP3 音訊可用於語音和其他更簡單的音訊。

MP3 背後的專利已過期，消除了在專案中使用 MP3 檔案的大多數或全部許可問題。這使得它們成為許多專案的良好選擇。

出於專利原因，Firefox 在 71 版之前沒有直接支援 MP3；而是使用平臺本機庫來支援 MP3。此功能是在每個平臺的不同 Firefox 版本中引入的。

Opus 音訊格式由 Xiph.org 基金會建立，是一個完全開放的音訊格式；它已由IETF 標準化為RFC 6716。它是一種用途廣泛的通用音訊編解碼器，可以有效地處理語音等低複雜度音訊以及音樂和其他高複雜度音訊。

Opus 支援多種壓縮演算法，甚至可以在同一個音訊檔案中使用多種演算法，因為編碼器可以為每一幀音訊選擇位元率、音訊頻寬、演算法和其他壓縮設定細節。

Opus 是一款適用於 Web 應用程式的全面音訊編解碼器，可用於您想到的任何音訊任務。

Vorbis 是 Xiph.org 基金會的一個開放格式，它支援各種聲道組合，包括單聲道、立體聲、複音、四聲道、5.1 環繞聲、全景聲或最多 255 個獨立的音訊聲道。根據編碼過程中使用的質量設定，生成的位元率可以從大約 45 kbps 到 500 kbps 不等。Vorbis 本身使用可變位元率編碼；位元率可以根據壓縮過程中的需要從一個樣本變化到下一個樣本。

通常，在類似質量水平下，Vorbis 在大小和位元率方面比 MP3 更有效率。這以及其免費和開放的許可證使其成為許多型別音訊資料的良好選擇，只要其高延遲不是問題。

通常，無論您使用什麼編解碼器，它通常都能完成工作，即使它不是理想的選擇，只要您選擇的編解碼器不是專門為完全不同的源音訊設計的。例如，選擇僅用於語音的編解碼器並嘗試將其用於音樂將無法獲得可用的結果。

但是，某些編解碼器可能會限制相容性，而其他編解碼器可能比其他編解碼器更適合您的需求。在這裡，我們將提供指導，以幫助您為您的用例選擇合適的編解碼器。

在選擇用於音訊的編解碼器時，您應該首先考慮以下問題

• 編碼後的音訊是否會被重新混音或重新壓縮？如果是，請避免使用有失真壓縮，因為這會因重新壓縮音訊而加劇；或者至少儘可能少地使用壓縮。
• 如果音訊需要進入特定檔案型別，請牢記這一點，因為媒體容器通常支援可用編解碼器的特定子集。
• 編解碼器將處理哪種音訊內容？某些編解碼器專門為僅用於語音的內容而設計（它們利用了人類語音所需的頻率範圍縮減）。其他編解碼器在編碼特定型別的音樂時，演算法上可能表現較差。
• 每個編解碼器具有哪些位元率和其他可配置屬性，這些屬性可能使其成為良好（或糟糕）的選擇？
• 延遲在您的需求中在多大程度上（如果有的話）很重要？如果您需要非常精確定時的音訊，則延遲越低越好。
• 您需要實現多少壓縮？

讓我們考慮一些常見場景，以瞭解決策過程。

對於流媒體音樂，您需要選擇一個編解碼器，最大程度地減少頻寬使用，同時儘可能少地透過壓縮將偽像引入音訊。這是必要的，因為音樂下載的速度不能大於網路上可用的頻寬量，並且理想情況下應該為網路速度波動和其他應用程式使用網路留出空間。

除非有對無失真壓縮的特定需求，或者網路頻寬保證足夠高以支援它，否則有失真壓縮方案是一個不錯的選擇。您選擇哪一個取決於瀏覽器相容性和您可能需要編解碼器支援的任何特殊功能的可用性。

通常，在流媒體音樂時，延遲並不特別重要。可能的例外包括迴圈音樂，您需要音樂能夠連續播放，或者當您需要能夠連續播放歌曲且歌曲之間沒有間隙時。這對於古典音樂、戲劇配樂以及遊戲中的背景音樂尤其重要。

對於一般的音樂播放，三個最可能的候選者是 MP3、AAC 和 Vorbis。

• MP4 容器中的 AAC 格式為所有主流瀏覽器所支援，這使其成為一個極佳的選擇。
• Vorbis 幾乎總是用於 Ogg 檔案，但 Ogg 容器並非所有瀏覽器都支援。即使是支援 Vorbis 的 Microsoft Edge，目前也不支援 Ogg 容器。
• MP3（MPEG-1 音訊層 III）為所有主流瀏覽器所支援。這些檔案是包含音訊層 III 軌道的 MPEG-1 檔案。

如果您需要在音樂播放過程中將延遲降到最低，則應重點考慮 Opus，它在通用編解碼器中擁有最低的延遲範圍（5 毫秒至 66.5 毫秒，而其他編解碼器的延遲至少為 100 毫秒）。

基於此，如果您只能支援一種音訊格式，那麼 AAC 可能是最佳選擇。當然，如果您能夠提供多種格式（例如，在您的 <source> 元素中使用 <audio> 和 <video> 元素），則可以避免許多或所有這些例外情況。

使用者下載的音樂可以壓縮到比流媒體音樂更大的總檔案大小，因為（與流媒體不同）下載速度是否低於媒體的播放速度並不重要。這意味著您可以考慮使用更高位元率的有失真壓縮，這會導致檔案更大，但保真度損失更小。或者，您可以選擇無損格式。選擇主要取決於您的應用程式需求和使用者偏好的結合。

對於實際的音樂下載服務，您可以根據使用者選擇的偏好，提供 128 Kbps MP3 檔案、256 kbps AAC 檔案（在 MP4 容器中）或 FLAC 檔案供使用者下載歌曲。如果您需要選擇一種格式，請選擇一種根據您的需求和正在下載的音訊內容型別有意義的格式。

當然，一般來說，MP3 是最常用的音樂格式；如果可能，請選擇至少 192 kbps 的位元率。另一方面，iTunes 商店以 256 kbps AAC 格式分發音樂。

人類語音的特定特徵允許特定於語音的編解碼器比大多數通用編解碼器更大幅度地壓縮音訊。這是因為，雖然人類可以聽到大約 20 Hz 至 20,000 Hz 的頻率範圍，人類語音的頻率範圍約為 300 Hz 至 18,000 Hz，但為了理解所說內容而需要的大部分語音聲音都位於大約 500 Hz 至 3,000 Hz 的頻率範圍內。這意味著僅用於語音的編解碼器可以丟棄所有其他頻率。

然而，特定於語音的編解碼器本質上都是有損的，任何在語音捕獲範圍之外的頻帶中包含重要資訊的聲音都將完全丟失。這使得這些編解碼器完全不適合除口語以外的任何用途。即使是僅包含語音但包含唱歌而不是說話的音訊，在這些格式中也可能無法達到可接受的質量。

語音錄製和播放通常需要低延遲，以便與影片軌道同步，或者為了避免串擾或其他問題。幸運的是，導致語音編解碼器在儲存空間方面如此高效的特性也使它們往往具有非常低的延遲。如果您正在使用 WebRTC，例如 G.722 的延遲為 4 毫秒（而 MP3 的延遲超過 100 毫秒），AMR 的延遲約為 25 毫秒。

網路上通常用於僅語音編碼的編解碼器是 G.722 和 AMR。AMR 是一種窄帶編解碼器，僅編碼 200 Hz 至 3,400 Hz 之間的頻率，位元率通常約為 7.4 kbps，而 G.722 是一種寬頻編解碼器，將音訊頻寬擴充套件到 50 Hz 至 7,000 Hz，位元率更高，通常為 64 kbps。

如果您有足夠的網路頻寬可以使用，並且合理地確定您的使用者也擁有足夠的頻寬，那麼 G.722 是更好的選擇。為了在受限環境中最大限度地提高儲存和網路效率，請選擇 AMR。

在壓縮將要進行混音或重新混音的音訊時，您通常希望保真度損失為零或接近零，這表明可能需要使用無損編解碼器。但是，由於無損編碼的壓縮級別自然比有損編碼低得多，因此您可能會發現，如果您的源音訊足夠大，您可能無論如何都必須選擇有損編碼器，尤其是在無法控制媒體下載速度的網路環境中。

假設無失真壓縮是這裡最好的選擇（通常情況下確實如此，只要音訊檔案足夠小），從編解碼器的角度來看，三個最強的候選者是 FLAC、Apple Lossless (ALA 和 MPEG-4 ALS。我們選擇哪一個將取決於瀏覽器支援和哪些媒體容器格式支援它們。

出於本示例的目的，我們假設所有瀏覽器都具有與 Firefox 相同的編解碼器和容器支援（儘管這遠非事實）。在做出決定時，請考慮編解碼器的實際支援範圍。

• Firefox 支援 FLAC 本機容器中的 FLAC，以及 Ogg 和 MPEG-4 (MP4) 檔案中的 FLAC。
• Firefox 僅透過其特定於平臺的 QuickTime 支援支援 Apple Lossless。
• Firefox 不支援 MP4 ALS。

在這種情況下，FLAC 看起來最可能是最佳編解碼器；ALAC 幾乎沒有直接的瀏覽器支援。

有許多工具可用於編碼音訊。最簡單的工具是那些用於提取 CD 或提取音訊檔案並快速自動將其轉換為 MP3 或 AAC 格式以儲存在庫中的工具，例如 iTunes。但在開發將音訊用作應用程式元件（例如遊戲）的 Web 應用程式時，您將需要更多地控制編碼過程，以及圍繞編碼音訊時使用的格式的更多選項。

一些流行的選項

FFmpeg

FFmpeg 可謂是最知名和最廣受認可的開源編解碼器軟體包，它支援大多數最流行的音訊格式，並提供用於編碼、解碼和執行音訊和影片格式轉換的命令列工具和庫。macOS、Linux 和 Windows 均提供二進位制檔案。

Handbrake

一個非常流行的 FFmpeg 開源前端，它添加了一個圖形使用者介面，使控制 FFmpeg 在編碼音訊和/或影片時提供的各種選項變得更加容易。macOS、Linux 和 Windows 均提供二進位制檔案。

Audacity

一個開源音訊編輯器，支援從許多不同的格式載入音訊、編輯、過濾和調整音訊，並以原始格式或新格式儲存迴音頻。macOS、Linux 和 Windows 均提供。

LAME

一個高質量的開源 MP3 編碼器，支援 CBR、ABR 和 VBR 編碼以及各種其他選項。僅由 LAME 專案以原始碼形式分發，但可以使用 Homebrew 或類似工具安裝。

• 媒體容器格式
• <audio> 和 <video> 元素
• WebRTC API
• Web 影片編解碼指南
• WebRTC 使用的編解碼器