藍牙AAC音頻編解碼是缺陷還是偷懶?
Soomal 于 2018.10.25 19:30:49 | 源自:www.soomal.com | 版權:原創 | 平均/總評分:09.53/162

在我們使用藍牙耳機或者藍牙喇叭時,常常會聽到關于apt-X、SBC、AAC等規格的說明,對于發燒友來說它們的意思不用多說。但對于普通用戶來說,可能還不太清楚。我們今天要討論的是藍牙音頻傳輸中的AAC編碼相關測試。而在開篇,我們為入門用戶做一點點小小科普,這個科普會相當入門,可能技術上不那么具體和嚴謹。

藍牙音頻的發射端如手機和接收端如耳機之間通訊時,音頻訊號需要經過相關的編碼,受限于這套技術規格相當老以及藍牙頻寬一直以來1Mbps最大頻寬[實際吞吐量更小],所以最基礎的SBC編碼、AAC編碼、apt-X等編碼考慮的最重要的是壓縮數據。例如手機對音頻數據編碼壓縮,然后藍牙耳機接收到后解碼,然后再做D/A轉換等輸出工作。

SBC、apt-X甚至現在的LDAC、HWA都是藍牙應用特有。但AAC是個例外。AAC是像MP3、APE、FLAC等一樣我們平時就可以見到的音樂檔案,它基于MPEG4的音頻規范壓縮,比MP3、Atrac3等有損音頻算法在低碼率時有明顯更好的表現,例如128kbps以下AAC表現明顯更好,在十多年前互聯網和藍牙一樣慢的時代肯定更受歡迎些。蘋果公司的音樂服務無論是以往的iTunes Store還是現在Apple Music一直使用AAC規格壓縮音樂,目前幾乎所有Apple Music都為256kbps等級壓縮質量。而蘋果和Beats家的耳機產品也一直都支援AAC,甚至不支援apt-X。

在藍牙音頻應用中AAC即然和SBC、apt-X、LDAC、HWA都不一樣,相信有不少人和我們的想法:如果手機端播放的音樂本身就是AAC格式的,而藍牙耳機也接收的是AAC,這是不是就省去了發射端編碼的工作?而如今的AAC 256kbps編碼的音樂已經如此普遍,256kbps的AAC質量其實已經相當不錯。256kbps的碼率也和apt-X的接近,AAC的表現為什么要比apt-X差一點呢?尤其是高頻。我們最近的測試,發現了其中的部分原因。

測試方法:我們在電腦上直接將無損測試訊號,包括頻率掃描和RMAA訊號都進行256kbps和160kbps CBR質量Apple AAC規格的壓縮,然后恢復為WAV[有損壓縮,恢復以后損失部分仍然存在],進行數據分析得到一組數據。這些數據代表了AAC壓縮本身的品質。另外,我們使用iPhone輸出AAC到BTR3[分兩組WAV原檔案和AAC本身原檔案],得到AAC輸出的數據,這些數據代表了藍牙傳輸AAC的品質。當然,除此之外,我們也用矩聲iMiniPro2s進行了驗證以保證BTR3測試沒問題。同時,還驗證了三星S9手機手動切換到AAC的表現,具體什么用?下文再說。下來看RMAA測試成績。

HWA測試 AAC160本身 AAC256本身 iPhoneWAVtoAAC iPhoneAACtoAAC
噪聲水準, dB (A): -94.8 -94.7 -95.3 -95.9
動態范圍, dB (A): 94.5 94.7 95.8 96.1
總諧波失真, %: 0.0094 0.0006 0.010 0.0095
互調失真, %: 0.057 0.010 0.045 0.323
立體聲分離度, dB: -95.2 -95.2 -96.2 -96.1

只從RMAA的客觀測試數據來看,我們發現256kbps質量的AAC本身水準明顯高于藍牙傳輸的AAC,哪怕是發射源本身是并沒有壓縮過的無損訊號發出的AAC也不如256kbps效果。而比較意外的是,即便使用高品質的AAC數據源作為訊號,藍牙AAC編解碼并不是直接傳輸AAC,原數據流,而還要對AAC解碼后再做一次AAC的壓縮再傳輸。

通過頻率掃描我們可以看到,藍牙傳輸的AAC訊號很多特征和本地壓縮的AAC檔案類似,但是細節上可以看出RMAA測試中看不到的內容,藍牙AAC傳輸的品質要比AAC本身訊號更差,肯定和256kbps的AAC差距很大。而在18kHz以上高頻部分,藍牙AAC也會切掉,這個切掉的幅度位置與160kbps的AAC本身接近。

我們可以看到LDAC上有自適應選項可以根據網路環境不同調整編碼質量,在測試中我們發現,AAC藍牙本身也有類似功能,而且極為敏感,每個手機的設定不同。例如三星S9即便手機和BTR3都擺在桌上不到1米距離,它也會進入到一個比較差的狀態。而iPhone X同樣位置下就要好不少,但只要稍微挪動到椅子背后晃一晃,就會進入到更差的模式。這個主要表現在高頻18kHz左右開始完全切掉訊號的損失程度不同。

從這套測試可以看出,目前藍牙AAC的設計還是相當古老,包含三個問題。

第一,頻寬利用率很低,大概只有160kbps-200kbps左右,更好的算法并沒有帶來更好的品質。

第二,重復壓縮缺陷。對手機端播放的AAC檔案還要進行AAC壓縮,且品質會明顯下降。而如果我們在音頻編輯軟體里對一個AAC檔案再做N次AAC壓縮,如果標準不變質量不會下降。藍牙AAC的壓縮算法質量弱于AAC標準算法應有質量。

第三,過于敏感的犧牲品質。AAC本身碼率品質已經不足200kbps,但藍牙AAC仍然非常敏感下調聲音品質,粗暴切割高頻。

總結:藍牙AAC雖然表面上看使用的是MPEG4 AAC壓縮算法,但目前來看老的標準設計過于保守,實際使用的質量大概只有160kbps AAC的水準,甚至還要更差一些。藍牙AAC并沒有利用本身大量的AAC規格的音樂檔案的優勢,反而簡陋粗暴的對AAC音樂解碼后進行再次壓縮,而壓縮質量更低,效果更差。保守、簡陋老設計造成了MPEG4在音頻方面的技術優勢被藍牙AAC糟蹋。但也可以看到,AAC的算法優勢如果稍加合理使用,就可以比現在的水準有很大幅度的進步。

請評分
1
2
3
4
5
6
7
8
9
10
分享到微博,暫時不可用
119.006.028.***
119.006.028.***
發表于2018.11.12 01:20:57
53
061.222.***.***
061.222.***.***
不知道那些問題在藍芽5.0有沒有獲得改善
發表于2018.11.07 13:14:51
52
222.072.***.***
222.072.***.***
藍牙用AAC發射編碼涉及專利,并且三社多次交手,最后擱置狀態就是目前這個樣子。
后來出于眾所周知的原因取消了AUX接口,藍牙發射編碼才重新變成風口問題。
下面是推測:
在切接口時肯定考慮過,甚至評測了一些改良方案(比如叫AAC+),
但開發資源評估不劃算(因為功率譜問題)。
這塊牙膏是有可能擠出來的(小出?商法),但一定會隨著某個重大硬體產品更新時推出。
其重要程度不亞于刷新一臺ipod hifi,并限定搭載在配套周邊,然后由那個時間點開始大量推廣接收晶片——即使廠商和消費者熱情不高(相比手機受眾),也不會大失敗。
如果廠商培養起來,再在第二代更新節點之前普及到手機平板(大約1年半~2年)。
——詳細閱讀
發表于2018.11.06 17:27:08
51
03
很好的文章,去偽存真,浮華的外表下讓我們知道了赤裸的本質
此帖使用Win10提交
發表于2018.11.05 11:16:44
50
106.047.098.***
106.047.098.***
發表于2018.11.05 11:12:44
49
113.005.***.***
113.005.***.***
如果不是使用系統自帶api來解碼的話可能會被軟體轉換成pcm再傳遞給系統,系統無法知道音樂的原格式是什么
此帖使用iPhone提交
發表于2018.11.02 08:31:34
47
03
學習了。謝謝!
發表于2018.10.29 17:06:05
46
03

此帖使用Win10提交
發表于2018.10.29 15:54:24
45
114.255.160.***
114.255.160.***
發表于2018.10.29 14:32:57
44
219.144.245.***
219.144.245.***
發表于2018.10.29 11:39:50
43
03
去年我就在論壇里發表設想“如果把解碼器單獨放在外部裝置里,手機作為一個純數字發射端使用豈不是更好”。有朋友說按照藍牙的速率還是不夠滿足無損碼流的,現在的藍牙技術成熟了,但是廠商之間銜接又出現問題,標準的不統一會造成本來挺好的一個技術的阻礙。這是一個好的前景,還是希望整個行業產生重視,手機功能模塊化是大勢所趨,應該給予考慮。
此帖使用VIVO X20PLUS A提交
發表于2018.10.28 23:49:26
42
124.076.108.***
124.076.108.***
發表于2018.10.28 21:21:44
41
124.152.217.***
124.152.217.***
發表于2018.10.28 19:52:17
40
03
之前記的是此藍牙AAC非彼*.aac
此帖使用HTC M10H提交
發表于2018.10.28 18:12:50
39
03
看到國外論壇有人將beats X改成了一根mmcx接口的藍牙耳機線。。
此帖使用iPhone提交
發表于2018.10.27 20:58:02
38
121.011.***.***
121.011.***.***
好在現在手機都取消耳機孔,也就是在倒逼配件商和手機去改善藍牙質量,并作為一個差異化的優勢賣點來宣傳,加上藍牙5.0更高傳輸速度的到來,相信幾年后的耳機音質會對比現在一個飛躍進步。
此帖使用Win10提交
發表于2018.10.27 08:33:12
37
03

此帖使用ZUK Z2131提交
發表于2018.10.27 06:52:11
36
042.157.007.***
042.157.007.***
發表于2018.10.26 17:29:32
34
提示
本貼可以匿名回復 ,您現在正處在潛水狀態
回復
驗證碼
6921 為防止廣告機貼垃圾,不得已而為之
表情
正文
京ICP備11010137號 京ICP證110276號 京公網安備110114000469號