由於沒有3.5毫米音訊插孔的智慧型手機的大量生產，無線藍牙耳機已成為許多人以耳機模式聆聽音樂和交流的主要方式。
無線設備的製造商並不總是編寫詳細的產品規格，並且互聯網上有關藍牙音頻的文章相互矛盾，有時不正確，沒有談論所有功能，並且經常複製與現實不符的相同信息。
讓我們試著了解協定、藍牙作業系統堆疊、耳機和揚聲器的功能、用於音樂和語音的藍牙編解碼器，找出影響傳輸聲音品質和延遲的因素，了解如何收集和解碼有關支援的編解碼器和其他設備的資訊能力。

TL博士:

• SBC-- 普通編解碼器
• 耳機對每個編解碼器都有自己的均衡器和後處理
• aptX 並不像宣傳的那麼好
• LDAC是行銷廢話
• 通話品質仍然很差
• 您可以透過 emscripten 將 C 音訊編碼器編譯到 WebAssembly 中，從而將它們嵌入到瀏覽器中，它們不會減慢太多。

透過藍牙播放音樂

藍牙的功能組件由設定檔（特定功能的規格）決定。 藍牙音樂串流使用高品質 A2DP 單向音訊傳輸設定檔。 A2DP 標準於 2003 年採用，此後沒有發生重大變化。
在該設定檔中，專為藍牙建立的 1 個低計算複雜度 SBC 強制編解碼器和 3 個附加編解碼器已標準化。 也可以使用您自己實作的未記錄的編解碼器。

截至 2019 年 XNUMX 月，我們 在xkcd漫畫中 具有 14 個 A2DP 編解碼器：

• SBC ← A2DP 標準化，所有設備都支援
• MPEG-1/2 Layer 1/2/3 ← A2DP 標準化：眾所周知 MP3，用於數位電視 MP2，且未知 MP1
• MPEG-2/4 AAC ← A2DP 標準化
• 澳大利亞航空運輸協會 ← 索尼的舊編解碼器，在 A2DP 中標準化
• 數模轉換器 ← 索尼的新編解碼器
• APTX ← 1988 年的編解碼器
• aptX高清 ← 與 aptX 相同，只是編碼選項不同
• aptX低延遲 ← 完全不同的編解碼器，沒有軟體實現
• aptX 自適應 ← 高通的另一個編解碼器
• 快流 ← 偽編解碼器，雙向SBC修改
• 華華LHDC ← 華為的新編解碼器
• 三星高畫質 ← 支援 2 台設備
• 三星可擴充 ← 支援 2 台設備
• 三星UHQ-BT ← 支援 3 台設備

您會問，當藍牙具有EDR 時，我們為什麼還需要編解碼器，它允許您以2 和3 Mbit/s 的速度傳輸數據，而對於未壓縮的兩通道16 位元PCM，1.4 Mbit/s 就足夠了？

透過藍牙傳輸數據

藍牙中有兩種類型的資料傳輸：非同步連接較少（ACL），用於非同步傳輸，無需建立連接；同步連接導向（SCO），用於透過初步連接協商進行同步傳輸。
使用時分方案進行傳輸，並為每個資料包單獨選擇傳輸通道（跳頻/時分雙工，FH/TDD），其中時間被劃分為稱為時隙的 625 微秒間隔。 其中一個設備在偶數時隙中傳輸，另一個設備在奇數時隙中傳輸。 傳輸的資料包可以佔用1、3 或5 個時隙，具體取決於資料的大小和設定的傳輸類型，在這種情況下，一台裝置的傳輸將在偶數和奇數時隙中進行，直到傳輸結束。 如果每個資料包佔用 1600 個時隙，並且兩台裝置不間斷地傳輸和接收數據，那麼每秒最多可以接收和發送 1 個資料包。

EDR的2和3Mbit/s，可以在公告和藍牙網站上找到，是兩個方向上所有資料總計（包括必須封裝資料的所有協定的技術標頭）的最大通道傳輸速率同時地。 實際資料傳輸速度會有很大差異。

傳輸音樂採用非同步方式，幾乎都是使用2-DH5、3-DH5這樣的資料包，EDR模式下最大資料量分別為2Mbit/s、3Mbit/s，佔用5時間- 共享插槽。

一台裝置使用 5 個插槽，另一台裝置使用 1 個插槽 (DH5/DH1) 進行傳輸的示意圖：


由於電波的時分原理，如果第二個裝置沒有向我們傳輸任何內容或傳輸小資料包，則在傳輸資料包後我們將被迫等待625 微秒的時隙，如果第二個裝置傳輸，則需要等待更多時間大包。 如果不只一台裝置連接到手機（例如耳機、手錶和健身手環），則傳輸時間將在所有裝置之間共用。

將音訊封裝在特殊傳輸協定 L2CAP 和 AVDTP 中的需要從可能的最大傳輸音訊負載量中佔用 16 個位元組。

包裝類型
插槽數量
最大限度。 封包中的位元組數
最大限度。 A2DP 有效負載位元組數
最大限度。 A2DP 負載比特率

2-DH3
3
367
351
936kbps

3-DH3
3
552
536
1429kbps

2-DH5
5
679
663
1414kbps

3-DH5
5
1021
1005
2143kbps

1414 和 1429 kbps 絕對不足以在實際條件下傳輸未壓縮的音頻，因為 2.4 GHz 範圍存在噪音並且需要傳輸服務資料。 EDR 3 Mbit/s 對傳輸功率和空中噪音的要求很高，因此，即使在3-DH5 模式下，舒適的PCM 傳輸也是不可能的，總是會出現短暫的中斷，並且一切只能在一定距離內工作。幾米。
實際上，即使是 990 kbit/s 的音訊串流（LDAC 990 kbit/s）也很難傳輸。

讓我們回到編解碼器。

SBC

所有支援 A2DP 標準的設備都需要編解碼器。 同時是最好和最差的編解碼器。

Частотадискретизации
位深
位元率
編碼支持
解碼支持

16、32、44.1、48 kHz
16位
10-1500kbps
所有設備
所有設備

SBC 是一種簡單且計算快速的編解碼器，具有原始心理聲學模型（僅應用安靜聲音的掩蔽），使用自適應脈衝編碼調製 (APCM)。
A2DP 規格建議使用兩種設定檔：中品質和高品質。


編解碼器有許多設置，可讓您控制演算法延遲、區塊中的樣本數、位元分佈演算法，但幾乎所有地方都使用規範中推薦的相同參數：聯合立體聲、8 個頻段、16 個區塊音訊幀，響度位元分配方法。
SBC支援動態改變Bitpool參數，這直接影響位元率。 如果電波堵塞、資料包遺失或設備距離較遠，音訊來源可能會減少位元池，直到通訊恢復正常。

大多數耳機製造商將最大 Bitpool 值設為 53，這將使用建議設定檔時的位元率限制為 328 kbit/s。
即使耳機製造商將最大Bitpool 值設定為高於53（此類型號也有，例如：Beats Solo³、JBL Everest Elite 750NC、Apple AirPods，在某些接收器和車載主機上也有），那麼大多數作業系統都不允許由於藍牙堆疊中設定的內部值限製而使用增加的位元率。
此外，一些製造商將某些裝置的最大 Bitpool 值設定為較低。 例如，Bluedio T 的值為 39，Samsung Gear IconX 的值為 37，音質較差。

藍牙堆疊開發人員的人為限制很可能是由於某些具有較大 Bitpool 值或非典型設定檔的裝置不相容（即使他們報告了對它們的支援）以及認證期間的測試不足而引起的。 對於藍牙堆疊的作者來說，更容易限制自己同意推薦的配置文件，而不是創建不正確設備的資料庫（儘管現在他們對其他不正確工作的功能這樣做）。

SBC按照從低到高的基礎，以不同的權重動態地將量化位元分配給頻帶。 如果所有位元率都用於低頻和中頻，則高頻將被「切斷」（反而會出現靜音）。

範例 SBC 328 kbps。 頂部是原始的，底部是 SBC，週期性地在軌道之間切換。 視訊檔案中的音訊使用FLAC無損壓縮編解碼器。 在 mp4 容器中使用 FLAC 尚未正式標準化，因此不能保證您的瀏覽器能夠播放它，但它應該可以在最新版本的桌面 Chrome 和 Firefox 中運行。 如果沒有聲音，您可以下載該檔案並在功能齊全的視訊播放器中開啟它。
ZZ 上衣 - 衣著講究的男士

頻譜圖顯示了切換時刻：SBC 定期消除 17.5 kHz 以上的安靜聲音，並且根本不為 20 kHz 以上的頻段分配任何位元。 點選 (1.7 MB) 可以獲得完整的頻譜圖。

在這首曲目中，我聽不出原版和 SBC 之間有任何區別。

讓我們採用一些更新的東西，模擬使用帶有 Bitpool 37 的 Samsung Gear IconX 耳機獲得的音訊（上圖 - 原始訊號，下圖 - SBC 239 kbps，FLAC 音訊）。
無意識的自我放縱 - 見證

我在人聲的高頻處聽到劈啪聲、較少的立體聲效果和令人不快的「沉悶」聲。

儘管SBC 是一種非常靈活的編解碼器，但它可以配置為低延遲，在高比特率(452+ kbps) 下提供出色的音頻質量，並且對於大多數人來說在標準高質量(328 kbps ) 下方相當不錯，因為A2DP標準沒有指定固定的設定檔（只是給了建議），堆疊開發人員對Bitpool設定了人為限制，傳輸音訊的參數不會顯示在使用者介面中，耳機製造商可以自由設定自己的設定並且永遠不會在產品的技術規格中標明了 Bitpool 值，編解碼器因其低音質而聞名，儘管這不是編解碼器本身的問題。
Bitpool 參數僅直接影響一個設定檔內的位元率。 相同的Bitpool 53 值可以在推薦的高品質設定檔下提供328 kbps 的位元率，在雙通道和1212 個頻段下提供4 kbps 的位元率，這就是為什麼作業系統作者除了對Bitpool 的限制之外，還設定了限制和比特率。 在我看來，這種情況的出現是由於 A2DP 標準的缺陷：需要協商位元率，而不是 Bitpool。

不同作業系統中SBC功能支援表：

操作系統
支援的取樣率
限制最大值位元池
限制最大值位元率
典型比特率
Bitpool動態調整

窗戶10
44.1кГц
53
512kbps
328kbps
✓*

Linux（BlueZ + PulseAudio）
16、32、44.1、48 kHz
64（用於傳入連線）、53（用於傳出連線）
沒有限制
328kbps
✓*

MacOS的海伊謝拉
44.1кГц
64，預設53***
不明
328kbps
✗

Android 4.4-9
44.1/48 kHz**
53
328kbps
328kbps
✗

Android 4.1-4.3.1
44.1、48 kHz**
53
229kbps
229kbps
✗

黑莓OS 10
48кГц
53
沒有限制
328kbps
✗

* 如果傳輸條件改善，位元池只會減少，但不會自動增加。 要恢復 Bitpool，您需要停止播放，等待幾秒鐘，然後再次啟動音訊。
** 預設值取決於編譯韌體時指定的堆疊設定。 在 Android 8/8.1 中，頻率僅為 44.1 kHz 或 48 kHz，取決於編譯期間的設置，在其他版本中同時支援 44.1 kHz 和 48 kHz。
*** 可以在Bluetooth Explorer 程式中增加Bitpool 值。

aptX 和 aptX HD

aptX 是一種簡單且計算快速的編解碼器，無需心理聲學，使用自適應差分脈衝編碼調製（數碼PCM）。 1988年左右出現（申請日期 專利 日期為 1988 年 2014 月），在藍牙之前，它主要用於專業無線音訊設備。 目前由高通公司擁有，需要許可和特許權使用費。 截至 6000 年：一次性 1 美元，每台設備 約 10000 美元，批量最多 XNUMX 台設備（源，第16頁）。
aptX 和 aptX HD 是相同的編解碼器，具有不同的編碼設定檔。

編解碼器只有一個參數－選擇取樣頻率。 然而，可以選擇通道的數量/模式，但在我所知的所有設備（70 多個）中，僅支援立體聲。

編解碼器
Частотадискретизации
位深
位元率
編碼支持
解碼支持

APTX
16、32、44.1、48 kHz
16位
128 / 256 / 352 / 384 kbps（取決於取樣率）
Windows 10（桌面版和行動版）、macOS、Android 4.4+/7*、Blackberry OS 10
各種音頻設備（硬體）

* 7 之前的版本需要修改藍牙堆疊。 只有當 Android 裝置製造商已從 Qualcomm 獲得編解碼器許可（如果作業系統具有編碼庫）時，才支援該編解碼器。

aptX 將音訊分為 4 個頻段，並不斷地以相同的位數進行量化：8-0 kHz 5.5 位，4-5.5 kHz 11 位，2-11 kHz 16.5 位，2-16.5 kHz 22 位（取樣率44.1 kHz 的數位）。

aptX 音訊範例（頂部 - 原始訊號，底部 - aptX，僅左聲道的頻譜圖，FLAC 格式的聲音）：

高音變得有點紅，但你聽不出差別。

由於量化位的固定分佈，編解碼器無法將位元「移動」到最需要它們的頻率。 與 SBC 不同，aptX 不會「削減」頻率，而是會向頻率添加量化噪聲，從而降低音頻的動態範圍。

例如，不應假設每頻帶使用 2 位元會將動態範圍降低至 12 dB：即使使用 96 個量化位，ADPCM 也允許高達 2 dB 的動態範圍，但僅限於特定訊號。
ADPCM 儲存目前樣本和下一個樣本之間的數值差，而不是像 PCM 那樣儲存絕對值。 這使您可以減少儲存相同（無遺失）或幾乎相同（具有相對較小的捨入誤差）資訊所需的位數的要求。 為了減少捨入誤差，使用係數表。
在創建編解碼器時，作者計算了一組音樂音訊檔案的 ADPCM 係數。 音訊訊號越接近建立表格的音樂集，aptX 產生的量化誤差（雜訊）就越少。

正因為如此，綜合測驗總是會產生比音樂更糟糕的結果。 我做了一個特殊的合成範例，其中 aptX 顯示效果不佳 - 頻率為 12.4 kHz 的正弦波（上方 - 原始訊號，下方 - aptX。FLAC 格式的音訊。降低音量！）：

頻譜圖：


噪音清晰可聞。

但是，如果產生幅度較小的正弦波，使其更安靜，則雜訊也會變得更安靜，表示動態範圍很寬：

要聽出原始音樂曲目和壓縮音樂曲目之間的差異，您可以反轉其中一個訊號並逐通道添加曲目。 一般來說，這種方法是不正確的，對於更複雜的編解碼器不會給出合理的結果，但特別對於 ADPCM 它非常合適。
原版和aptX的差別
訊號的均方根差為-37.4 dB，這對於這種壓縮音樂來說並不算多。

aptX高清

aptX HD 不是獨立的編解碼器 - 它是 aptX 編解碼器的改進編碼設定檔。 這些變化影響了編碼頻率範圍分配的位數：10-0 kHz 為 5.5 位，6-5.5 kHz 為 11 位，4-11 kHz 為 16.5 位，4-16.5 kHz 為 22 位（44.1 kHz 為數字） 。

編解碼器
Частотадискретизации
位深
位元率
編碼支持
解碼支持

aptX高清
16、32、44.1、48 kHz
24位
192 / 384 / 529 / 576 kbps（取決於取樣率）
安卓 8+*
一些音訊設備（硬體）

* 7 之前的版本需要修改藍牙堆疊。 只有當 Android 裝置製造商已從 Qualcomm 獲得編解碼器許可（如果作業系統具有編碼庫）時，才支援該編解碼器。

比 aptX 不太常見：顯然需要高通的單獨許可以及單獨的許可費用。

讓我們用 12.4 kHz 的正弦波重複這個範例：


比 aptX 好很多，但還是有點吵。

aptX低延遲

從參與其開發的人員提供的有限資訊來看，高通的編解碼器與標準 aptX 和 aptX HD 沒有任何共同點。 專為互動式低延遲音訊傳輸（電影、遊戲）而設計，其中音訊延遲無法透過軟體調整。 編碼器和解碼器尚無已知的軟體實現；它們僅由發射器、接收器、耳機和揚聲器支持，但智慧型手機和電腦不支援。

Частотадискретизации
位元率
編碼支持
解碼支持

44.1кГц
276/420kbps
一些發射器（硬體）
一些音訊設備（硬體）

AAC格式

AAC，即高階音訊編碼，是一種計算複雜的編解碼器，具有嚴格的心理聲學模型。 廣泛用於互聯網上的音頻，其受歡迎程度僅次於 MP3。 需要許可和特許權使用費：一次性 15000 美元（員工少於 1000 名的公司為 15 美元）+ 前 0.98 台設備 500000 美元（源).
此編解碼器在 MPEG-2 和 MPEG-4 規範中標準化，與常見的誤解相反，它不屬於 Apple。

Частотадискретизации
位元率
編碼支持
解碼支持

8 - 96 kHz
8 - 576 kbps（立體聲），256 - 320 kbps（藍牙典型值）
macOS、Android 7+*、iOS
各種音頻設備（硬體）

* 僅適用於製造商已支付許可費的設備

iOS 和 macOS 使用 Apple 目前最好的 AAC 編碼器來提供盡可能高的音訊品質。 Android 使用最高品質的 Fraunhofer FDK AAC 編碼器，但可能使用平台 (SoC) 中內建的各種編碼品質未知的硬體。 根據 SoundGuys 網站最近的測試，不同Android手機的AAC編碼品質差異很大：

大多數無線音訊裝置的 AAC 最大位元率為 320 kbps，有些僅支援 256 kbps。 其他比特率極為罕見。
AAC 在 320 和 256 kbps 位元速率下提供出色的質量，但受制於 已壓縮內容的順序編碼遺失不過，即使採用多種順序編碼，在 256 kbps 的位元率下，在 iOS 上也很難聽出與原版的差異；對於單一編碼，例如 MP3 320 kbps 到 AAC 256 kbps，損失可以忽略不計。
與其他藍牙編解碼器一樣，任何音樂都首先由編解碼器解碼，然後進行編碼。 當聽AAC格式的音樂時，首先由作業系統解碼，然後再次編碼為AAC，以便透過藍牙傳輸。 這對於混合多個音訊串流（例如音樂和新訊息通知）是必要的。 iOS 也不例外。 在網路上你可以找到很多說法，在iOS上，AAC格式的音樂透過藍牙傳輸時不會轉碼，這是不正確的。

MP1/2/3

MPEG-1/2 Part 3 系列的編解碼器包括眾所周知且廣泛使用的 MP3、不太常見的 MP2（主要用於數位電視和廣播）以及完全未知的 MP1。

舊的 MP1 和 MP2 編解碼器根本不受支援：我找不到任何可以對它們進行編碼或解碼的耳機或藍牙堆疊。
某些耳機支援 MP3 解碼，但任何現代作業系統堆疊都不支援編碼。 如果您手動更改配置文件，Windows 的第三方 BlueSoleil 堆疊似乎可以編碼為 MP3，但對我來說，安裝它會導致 Windows 10 上的 BSoD。結論 - 該編解碼器實際上不能用於藍牙音訊。
先前，在 2006-2008 年，A2DP 標準在裝置中普及之前，人們透過 MSI BluePlayer 程式在諾基亞 BH-3 耳機上收聽 MP501 音樂，該程式可在 Symbian 和 Windows Mobile 上使用。 當時，智慧型手機的作業系統架構允許存取許多低階功能，在Windows Mobile上甚至可以安裝第三方藍牙堆疊。

MP3編解碼器的最後一項專利已到期；自23年2017月XNUMX日起使用此編解碼器不需要授權費用。

如果以上述參考文獻中提到的運行時間最長的專利作為衡量標準，那麼當由Technicolor 持有和管理的美國專利3 到期時，MP16 技術於2017 年6,009,399 月XNUMX 日在美國成為無專利的。

來源： www.iis.fraunhofer.de/en/ff/amm/prod/audiocodec/audiocodecs/mp3.html

Частотадискретизации
位元率
編碼支持
解碼支持

16 - 48 kHz
8 - 320 kbps
任何地方都不支持
一些音訊設備（硬體）

數模轉換器

索尼積極推廣的新型「Hi-Res」編解碼器，支援高達 96 kHz 的取樣率和 24 位元比特率，比特率高達 990 kbps。 它被宣傳為發燒級編解碼器，作為現有藍牙編解碼器的替代品。 它具有根據廣播條件自適應位元率調整的功能。

LDAC編碼器（利布達克）包含在標準 Android 套件中，因此從作業系統版本 8 開始的任何 Android 智慧型手機都支援編碼。 沒有免費的軟體解碼器，編解碼器規範不向公眾公開，但是，乍看之下編碼器，編解碼器的內部結構類似於 ATRAC9 - PlayStation 4 和 Vita 中使用的索尼編解碼器：兩者都在頻域中工作，使用改進的離散餘弦變換 (MDCT) 並使用霍夫曼演算法進行壓縮。

LDAC 支援幾乎完全由索尼耳機提供。 有時，其他製造商的耳機和 DAC 也具有解碼 LDAC 的功能，但這種情況很少見。

Частотадискретизации
位元率
編碼支持
解碼支持

44.1 - 96 kHz
303/606/909 kbit/s（適用於 44.1 和 88.2 kHz）、330/660/990 kbit/s（適用於 48 和 96 kHz）
Android 8的+
一些索尼耳機和一些其他製造商的設備（硬體）

將LDAC 作為高解析度編解碼器進行行銷會損害其技術組件：將位元率花費在傳輸人耳聽不見的頻率並增加位元深度上是愚蠢的，而在沒有損失的情況下傳輸CD 品質(44.1 /16) 是不夠的。 幸運的是，編解碼器有兩種工作模式：CD 音訊傳輸和 Hi-Res 音訊傳輸。 在第一種情況下，僅透過空中傳輸 44.1 kHz/16 位元。

由於軟體 LDAC 解碼器不是免費提供的，因此在沒有解碼 LDAC 的附加設備的情況下不可能測試編解碼器。 根據 LDAC 在其支援下的 DAC 測試結果，SoundGuys.com 工程師透過數位輸出連接並在測試訊號上記錄輸出聲音，CD 品質模式下的 LDAC 660 和 990 kbps 提供了訊號到訊號雜訊比比aptX HD略好。

來源： www.soundguys.com/ldac-ultimate-bluetooth-guide-20026

LDAC 也支援既定設定檔之外的動態位元率 - 從 138 kbps 到 990 kbps，但據我所知，Android 僅使用標準化設定檔 303/606/909 和 330/660/990 kbps。

其他編解碼器

其他 A2DP 編解碼器並未廣泛使用。 它們的支援要么幾乎完全不存在，要么僅在某些型號的耳機和智慧型手機上可用。
A2DP 中標準化的ATRAC 編解碼器甚至連索尼自己也從未用作藍牙編解碼器，Samsung HD、Samsung Scalable 和Samsung UHQ-BT 編解碼器對發送和接收設備的支援非常有限，而HWA LHDC 太新，僅支援三種（？） 設備。

音訊設備的編解碼器支持

並非所有製造商都會發布有關某些無線耳機、揚聲器、接收器或發射器支援的編解碼器的準確資訊。 有時，對某種編解碼器的支援僅適用於傳輸，而不適用於接收（與組合發射器-接收器相關），儘管製造商只是聲明“支援”，沒有註釋（我假設某些編碼器和解碼器的單獨許可編解碼器是造成這種情況的罪魁禍首）。 在最便宜的設備中，您可能根本找不到聲明的 aptX 支援。

不幸的是，大多數作業系統的介面不會顯示任何地方使用的編解碼器。 有關此資訊僅適用於 Android（從版本 8 開始）和 macOS。 但是，即使在這些作業系統中，也只會顯示手機/電腦和耳機都支援的編解碼器。

如何找出您的裝置支援哪些編解碼器？ 使用A2DP協商參數記錄並分析流量轉儲！
這可以在 Linux、macOS 和 Android 上完成。 在 Linux 上，您可以使用 Wireshark 或 hcidump，在 macOS 上，您可以使用藍牙資源管理器，在 Android 上，您可以使用標準藍牙 HCI 轉儲保存功能，該功能可在開發人員工具中使用。 您將收到 btsnoop 格式的轉儲，可以將其載入到 Wireshark 分析器中。
請注意：只有透過從手機/電腦連接到耳機/揚聲器才能獲得正確的轉儲（無論聽起來多麼有趣）！ 耳機可以獨立與手機建立連接，在這種情況下，它們將從手機請求編解碼器列表，反之亦然。 為了確保記錄正確的轉儲，請先取消裝置配對，然後在記錄轉儲時將手機與耳機配對。

使用以下顯示過濾器過濾掉不相關的流量：

btavdtp.signal_id

結果，您應該會看到與此類似的內容：

您可以點擊 GetCapability 命令中的每一項來查看編解碼器的詳細特性。

Wireshark 不知道所有編解碼器標識符，因此某些編解碼器必須手動解密，請查看下面的標識符表：

Mandatory:
0x00 - SBC

Optional:
0x01 - MPEG-1,2 (aka MP3)
0x02 - MPEG-2,4 (aka AAC)
0x04 - ATRAC

Vendor specific:
0xFF 0x004F 0x01   - aptX
0xFF 0x00D7 0x24   - aptX HD
0xFF 0x000A 0x02   - aptX Low Latency
0xFF 0x00D7 0x02   - aptX Low Latency
0xFF 0x000A 0x01   - FastStream
0xFF 0x012D 0xAA   - LDAC
0xFF 0x0075 0x0102 - Samsung HD
0xFF 0x0075 0x0103 - Samsung Scalable Codec
0xFF 0x053A 0x484C - Savitech LHDC

0xFF 0x000A 0x0104 - The CSR True Wireless Stereo v3 Codec ID for AAC
0xFF 0x000A 0x0105 - The CSR True Wireless Stereo v3 Codec ID for MP3
0xFF 0x000A 0x0106 - The CSR True Wireless Stereo v3 Codec ID for aptX

為了不手動分析轉儲，我創建了一個可以自動分析所有內容的服務： btcodecs.valdikss.org.ru

編解碼器的比較。 哪個編解碼器比較好？

每個編解碼器都有自己的優點和缺點。
aptX 和 aptX HD 使用硬編碼設定文件，如果不修改編碼器和解碼器就無法變更。 手機製造商和耳機製造商都無法更改位元率或 aptX 編碼係數。 編解碼器的擁有者 Qualcomm 以庫的形式提供參考編碼器。 這些事實是 aptX 的優勢 - 您提前知道您將獲得什麼音質，沒有任何“但是”。

相比之下，SBC 有許多可配置的參數、動態位元率（如果電波繁忙，編碼器可以減少位元池參數），並且沒有硬編碼配置文件，只有建議的「中等品質」和「高品質」。於2 年加入A2003DP 規範。 按照今天的標準，「高品質」不再那麼高，大多數藍牙堆疊不允許您使用比「高品質」設定檔更好的參數，儘管對此沒有技術限制。
藍牙 SIG 沒有參考 SBC 編碼器作為庫，由製造商自行實現。
這些是 SBC 的弱點 - 事先無法明確特定設備的音質。 SBC 可以產生低品質和非常高品質的音頻，但如果不停用或繞過藍牙堆疊的人為限制，後者是無法實現的。

AAC 的情況是不明確的：一方面，理論上編解碼器應該產生與原始編解碼器沒有區別的質量，但實際上，從SoundGuys 實驗室在不同Android 設備上的測試來看，這一點尚未得到證實。 最有可能的原因是各種手機晶片組中內建的低品質硬體音訊編碼器。 僅在 Apple 裝置上使用 AAC 才有意義，而在 Android 上則將其限制為 aptX 和 LDAC。

支援替代編解碼器的硬體往往具有更高的質量，僅僅是因為對於非常便宜、低品質的設備來說，支付許可費用來使用這些編解碼器是沒有意義的。 在我的測試中，SBC 在優質設備上聽起來非常好。

我製作了一個 Web 服務，可以在瀏覽器中即時將音訊編碼為 SBC、aptX 和 aptX HD。 有了它，您可以在任何有線耳機、揚聲器和您喜愛的音樂上測試這些音頻編解碼器，而無需通過藍牙實際傳輸音頻，還可以在播放音頻時直接更改編碼參數：
btcodecs.valdikss.org.ru/sbc-encoder
該服務使用 BlueZ 專案中的 SBC 編碼庫和 ffmpeg 中的 libopenaptx，這些程式庫透過 emscripten 從 C 編譯為 WebAssembly 和 JavaScript，以便在瀏覽器中運行。 誰能夢想這樣的未來！

這是它的樣子：

請注意不同編解碼器的雜訊水準在 20 kHz 之後如何變化。 原始 MP3 檔案不包含 20 kHz 以上的頻率。

嘗試切換編解碼器，看看您是否聽到原始 SBC 53 Joint Stereo（標準和最常見的設定檔）和 aptX/aptX HD 之間的差異。

我可以聽出編解碼器之間的差異 附耳機!

在透過網路服務進行測試時沒有聽到編解碼器之間差異的人聲稱，他們在使用無線耳機聽音樂時聽到了這種差異。 唉，這不是玩笑，也不是安慰劑效應：差異確實是聽得見的，但並不是差異引起的 編解碼器.

無線接收設備中使用的絕大多數藍牙音訊晶片組都配備了數位訊號處理器 (DSP)，它實現了均衡器、壓縮擴展器、立體聲擴展器和其他旨在改善（或改變）聲音的功能。 藍牙設備製造商可以配置DSP 分別針對每個編解碼器，並且在編解碼器之間切換時，聽眾會認為他們聽到的是編解碼器操作的差異，而實際上他們聽到的是不同的 DSP 設定。

CSR/Qualcomm 製造的晶片中的 DSP Kalimba 音訊處理管道

為每個編解碼器啟動不同的DSP功能並分別輸出

一些高級設備附帶的軟體可讓您自訂 DSP 設置，但大多數便宜的耳機沒有，且用戶無法手動關閉音訊後處理。

設備功能特點

A2DP 標準的現代版本具有 “絕對音量控制”功能 — 使用 AVRCP 協定的特殊指令控制裝置音量，該指令可調整輸出級的增益，而不是以程式方式降低音訊串流的音量。 如果您變更耳機音量時，變更與手機音量不同步，則您的耳機或手機不支援此功能。 在這種情況下，最好總是在手機上以最大音量聽音樂，用耳機按鈕調整實際音量 - 這樣的話，信噪比會更好，音質也更好 應該是 更高。
事實上，也有令人悲傷的情況。 在我的 SBC 的 RealForce OverDrive D1 耳機上，開啟了強壓縮擴展器，增加音量會導致安靜聲音的音量增加，而響亮聲音的音量不會改變（訊號被壓縮）。 因此，您必須將計算機上的音量設置為一半左右，在這種情況下幾乎沒有壓縮效果。
據我觀察，所有附加編解碼器的耳機都支援絕對音量控制功能，顯然這是編解碼器認證的要求之一。

部分耳機支援 同時連接兩個設備。 例如，您可以透過電腦收聽音樂並透過手機接聽電話。 但是，您應該注意，在此模式下，替代編解碼器已停用，並且僅使用 SBC。

AVDTP 1.3 延遲報告功能 允許耳機將延遲傳達給實際播放聲音的傳輸裝置。 這允許您在觀看視頻文件時調整音頻與視頻的同步：如果無線電傳輸出現問題，音頻不會落後於視頻，但相反，視頻會被視頻播放器減慢，直到音頻和視頻再次同步。
許多耳機、Android 9+ 和具有 PulseAudio 12.0+ 的 Linux 都支援該功能。 我不知道其他平台是否支援此功能。

透過藍牙進行雙向通訊。 語音傳輸。

對於藍牙中的語音傳輸，使用以同步連線為導向（SCO）－透過連線的初步協商進行同步傳輸。 此模式可讓您嚴格按順序傳輸聲音和語音，發送和接收速度對稱，無需等待傳輸確認和重新發送資料包。 這減少了無線電頻道上音訊傳輸的整體延遲，但對每單位時間傳輸的資料量施加了嚴格的限制，並對品質產生負面影響。
使用此模式時，語音和音訊都以相同的品質傳輸。
不幸的是，截至 2019 年，藍牙語音品質仍然很差，目前還不清楚為什麼藍牙 SIG 沒有採取任何措施。

心血管疾病診斷

基本的 CVSD 語音編解碼器於 2002 年標準化，所有雙向藍牙通訊設備均支援此編解碼器。 它提供取樣頻率為 8 kHz 的音訊傳輸，相當於傳統有線電話的品質。

此編解碼器中的錄音範例.

微控制器

附加的 mSBC 編解碼器於 2009 年標準化，2010 年使用它進行語音傳輸的晶片已經出現。 mSBC 被各種設備廣泛支援。
這不是一個獨立的編解碼器，而是來自 A2DP 標準的常規 SBC，具有固定的編碼設定檔：16 kHz、單聲道、位元池 26。

此編解碼器中的錄音範例.

不算出色，但比 CVSD 好得多，但用於線上交流仍然很煩人，尤其是當你在遊戲中使用耳機進行交流時 - 遊戲的音訊也會以 16 kHz 的取樣率傳輸。

FastStreamCSR公司決定開發利用SBC的想法。 為了繞過SCO 協議的限制並使用更高的比特率，CSR 走了一條不同的路線- 他們將對雙向SBC 音頻的支持引入到A2DP 單向音頻傳輸標準中，標準化編碼配置文件，並將其稱為“FastStream”。

FastStream 以 44.1 或 48 kHz、比特率為 212 kbps 向揚聲器傳輸立體聲音頻，而單聲道、16 kHz、比特率為 72 kbps 用於從麥克風傳輸音頻（比 mSBC 稍好）。 這些參數更適合線上遊戲中的交流 - 遊戲和對話者的聲音將是高品質的。

此編解碼器中的錄音範例 (+ 麥克風發出聲音，與 mSBC 相同).

該公司想出了一個有趣的拐杖，但由於它與 A2DP 標準相矛盾，因此僅在該公司的某些發射器（用作 USB 音訊卡，而不是藍牙設備）中支援它，但它並不支持獲得藍牙堆疊的支持，儘管支援FastStream 的耳機數量並不少。

目前，作業系統中僅支援 FastStream 作為 Linux PulseAudio 的補丁 來自開發人員 Pali Rohár，他不包含在該程式的主分支中。

aptX低延遲

令您驚訝的是，aptX Low Latency 還支援雙向音頻，實現與 FastStream 相同的原理。
不可能在任何地方使用編解碼器的此功能 - 在我所知的任何作業系統或任何藍牙堆疊中都不支援低延遲解碼。

藍牙 5，經典和低功耗

由於同一品牌下存在兩種不相容的標準，而這兩種標準都廣泛用於不同的目的，因此藍牙規範和版本存在著許多混亂。

有兩種不同且不相容的藍牙協定：經典藍牙和低功耗藍牙（LE，也稱為智慧藍牙）。 還有第三種協議，即高速藍牙，但它並不普遍，也沒有在家用設備中使用。

從藍牙 4.0 開始，規範的變化主要涉及藍牙低功耗，而經典版本僅獲得了較小的改進。

藍牙4.2和藍牙5之間的變化清單：

從 v9 到 4.2 的 5.0 項變更

9.1 新功能

藍牙核心規格 5.0 版本中引進了多項新功能。 需要改進的主要領域是：
• 時隙可用性遮罩 (SAM)
• 用於 LE 的 2 Msym/s PHY
•LE 長距離
• 高負載週期不可連線廣告
• LE 廣告擴展
• LE 頻道選擇演算法#2
9.1.1 CSA5 中新增的功能 - 整合在 v5.0 中
•更高的輸出功率

來源： www.bluetooth.org/docman/handlers/DownloadDoc.ashx?doc_id=421043 （第 291 頁）

在藍牙 5 規範框架內，只有一項變更影響了經典版本：增加了對時隙可用性遮罩 (SAM) 技術的支持，該技術旨在改善無線電廣播分離。 所有其他變更僅影響藍牙 LE（以及更高的輸出功率）。

所有 音訊設備僅使用經典藍牙。 無法透過低功耗藍牙連接耳機和揚聲器：沒有使用 LE 傳輸音訊的標準。 用於傳輸高品質音訊的 A2DP 標準只能透過經典藍牙工作，且 LE 中沒有類似的標準。

結論 - 僅僅因為新版本的協議而購買藍牙 5 的音訊設備是沒有意義的。 藍牙4.0/4.1/4.2在音訊傳輸方面的工作原理完全相同。
如果新耳機的發布提到藍牙 5 使工作範圍加倍並降低功耗，那麼您應該知道他們要么自己不理解，要么誤導您。 這也難怪，因為即使是藍牙晶片製造商在其公告中也對新版本標準之間的差異感到困惑，並且一些藍牙5晶片僅支援LE的第五版本，而使用4.2作為Classic。

音訊傳輸延遲

音訊延遲量取決於許多因素：音訊堆疊、藍牙堆疊和無線播放設備本身中的緩衝區大小，以及編解碼器的演算法延遲。

SBC、aptX 和 aptX HD 等簡單編解碼器的延遲非常小，為 3-6 毫秒，可以忽略不計，但 AAC 和 LDAC 等複雜編解碼器會導致明顯的延遲。 44.1 kHz 的 AAC 演算法延遲為 60 毫秒。 LDAC - 大約 30 毫秒（基於對原始程式碼的粗略分析。我可能是錯的，但不多。）

由此產生的延遲在很大程度上取決於播放設備、其晶片組和緩衝區。 在測試過程中，我在不同裝置（使用 SBC 編解碼器）上收到了 150 到 250 毫秒的延遲。 如果我們假設支援附加編解碼器 aptX、AAC 和 LDAC 的裝置使用高品質元件和較小的緩衝區大小，我們會得到以下典型延遲：

單闆卡：150-250ms
aptX：130-180 毫秒
AAC：190-240 毫秒
LDAC：160-210 毫秒

讓我提醒您：作業系統不支援 aptX Low Latency，這就是為什麼較低的延遲只能透過發射器+接收器或發射器+耳機/揚聲器組合來獲得，並且所有設備都必須支援此編解碼器。

藍牙裝置、認證和標誌問題

如何區分高品質音響設備和廉價工藝品？ 首先是外觀！

對於廉價的中國耳機、揚聲器和接收器：

1. 盒子和設備上缺少“藍牙”一詞，最常使用“無線”和“BT”
2. 藍牙標誌缺失 在盒子或裝置上
3. 無藍色 LED 閃爍

缺少這些元素表明該設備尚未經過認證，這意味著它可能品質低劣且有問題。 例如，Bluedio 耳機未經過藍牙認證，也不完全符合 A2DP 規範。 他們不會通過認證。

讓我們考慮其中的幾種設備和盒子：

這些都是未經認證的設備。 說明可能包含藍牙技術的標誌和名稱，但最重要的是它們位於包裝盒和/或設備本身上。

如果您的耳機或揚聲器顯示“Ze 藍牙 dewise 連接成功”，這也不表明其品質：

結論

藍牙能否完全取代有線耳機和耳麥？ 它是有能力的，但代價是通話品質差、遊戲中令人討厭的音訊延遲增加，以及需要許可費用並增加智慧型手機和耳機的最終成本的大量專有編解碼器。

替代編解碼器的行銷非常強勁：aptX 和 LDAC 被視為「過時且糟糕」的 SBC 的期待已久的替代品，而 SBC 並不像人們想像的那麼糟糕。

事實證明，藍牙堆疊對SBC位元率的人為限制是可以繞過的，這樣SBC就不會遜色於aptX HD。 我主動給LineageOS韌體打了補丁： 我們修改藍牙堆疊以改善不使用 AAC、aptX 和 LDAC 編解碼器的耳機的聲音

更多資訊可以在網站上找到 健全的傢伙 и 聲音專家.

獎金： SBC參考編碼器、A2DP位元流資訊和測試文件。 該文件曾經在藍牙網站上公開發布，但現在僅對藍牙 SIG 成員開放。

來源： www.habr.com