👨🏽‍🌾 😣 😗 Bluetoothワイヤレスオーディオテクノロジー：どちらが良いですか？ 🐒 👃🏾 🤾🏿

技術の発展に伴い、誰もが慣れ親しんでいる「チューブ」アナログヘッドフォンは歴史的に衰退し、Bluetoothワイヤレス対応製品に取って代わられています。

現代のスマートフォンでは、湿気やほこりから保護するために、通常のコネクタが奪われています。

開発者は、Bluetoothプロトコルのすべての新しいバージョンとコーデックのすべての新しいバージョンをリリースし、「より速く、より高く、より強く」-再生の遅延を減らし、品質を向上させます。

すべてがとても良いですか？見てみましょう。

はじめに

プロトコルの技術的な実装や、退屈な仕様については掘り下げません。親愛なるValdikSSは、この記事でインスピレーションや科学コンサルタントとしても大いに役立っており、コーデックに関する包括的な資料を準備しています-そして、すべてがより詳細かつ技術的に正確に提示されます。

私は個人的な経験についてもっと伝えたいです。まあ、少し面白い（退屈？）練習。

1年半前、aptXのアイデアに興奮しました。はい、私はこのようなたくさんのレビューを読み、これらの技術的なtwist余曲折をすべて信じていました。子供が生まれました。そして夜、妻と一緒にヘッドフォンでショーを見たいと思っていました。

それは何をもたらしましたか？

品質

数字と事実から始めましょう（こんにちは、ウィキペディア！）

SBCは古くからあるコーデックであり、A2DP標準に準拠しています。このコーデックは、Frans de Bont （F. de Bont、M。GroenewegenおよびW. Oomen、「128 kb / sの高品質オーディオコーディングシステム」、第98回AESコンベンション、1995年2月25〜28日）と使用の結果です。 特許EP-0400755B1に記載されているアルゴリズム。特許の著者がBluetoothアプリケーションでのみSBCの無料使用を許可していることは注目に値しますが、この特許は2010年6月2日に失効しました。 A2DP規格は非常に一般的であるため、SBCをサポートしていないヘッドフォンやスピーカーを見つけることは非常に困難です。

コーデックは、16〜32、44.1、48 kHzのサンプリング周波数と10〜1500 kbit / sの流量を提供します。はい、あなたは正しいと聞きました。最大1500 kbps。コーデックにはビットレートの制限はありません。しかし、それについては後で。

aptXコーデックは、1988年にクイーンズ大学ベルファストで開発されました。はい、Bluetoothが登場するまでにはまだ約12年ありました。そのため、コーデックはプロのオーディオ機器で使用されていました。クアルコムは現在権利を保持しているため、使用にはライセンスとロイヤリティが必要です。 2014年の時点で、コストはおよそ次のとおりです。最大10,000デバイスの関係者に対してリリースされた各デバイスに対して、6,000ドルと1ドルの1回限りの支払い。このため、Snapdragon 835、845、821、820、810、805、801、800、650、615、410チップを搭載した多くのデバイスは非常に可能性が高く、aptXをサポートしていますが、ライセンスが購入されていないため、そこでアクティブ化されません。それについて-以下も。

16ビットのビット深度と48 kHzのサンプリング周波数で、コーデックは384 kbit / s（デュアルチャネル）ビットレートを提供できます。

aptXを公式にサポートする製品のリスト。 aptXをサポートしている多くの未知のシステムをAliexpressで見つけることができますが、実際には同じ古き良きSBCが存在するという事実に備えてください。

aptX HD-同じコーデックですが、エンコードプロファイルが異なり、ストリーム速度は576 kbit / s、サンプリング周波数は最大48 kHz、ビット深度は最大24ビットです。これをaptX Losslessコーデックと呼ぶ人もいますが、これは完全なナンセンスです。ロスレスデータを伝送できるストリームの価値を現時点で達成できないからです。このコーデックの特別な利点は、調整可能なエンコード遅延であり、48 kHzのサンプリング周波数で1 msに短縮できます。また、コーデックはプロセッサのロードの観点から非常に有利であり、MP3およびAASよりも有利です。

aptX HDを公式にサポートする製品のリスト。彼は十分に小さいです。

aptX低レイテンシ （またはLL）は、サウンド遅延時間を40ミリ秒未満に短縮できるコーデックの特別なバージョンです。 aptX LLを公式にサポートする製品のリスト。

彼女がいる。かつて私に聖書を買ったのはこの写真でした。遅れる！結局のところ、アクション映画で爆発の音、ホラー映画でのモンスターの叫び声、フットボールの試合での観衆のof音が終わったときに誰が聞きたいですか？

しかし、これは本当にそうですか？

ああ、いや。

他のマーケティング資料と同様に、数値は非常に高く評価されています。遅延は、システムのバッファリングとコーデックの実装に大きく依存します。そのため、SBCの遅延は40ミリ秒未満である可能性があり、テレビ放送の標準（+40ミリ秒〜-60ミリ秒）を考慮すると、完全に許容可能です。

要約すると：

コーデックは真のロスレス圧縮を実現できないため、既存のコーデックは有線技術より優れたものはありません。
最も一般的なコーデックはSBCです。彼は最も柔軟な設定です。また、aptXが以前にリリースされたという事実にもかかわらず、明らかにSBCが無料であるため、SBCの人気に勝るものはありません。
音質は、コーデックの実装、および一般的なヘッドフォン/スピーカーのハードウェア性能に大きく依存します-スピーカー自体が弱い場合、コーデックによって品質を改善することはできません。したがって、将来的には、品質を比較して、同じスピーカー/ヘッドフォンで同じソースの同じコンテンツを異なるコーデックで再生することについて話します。

実用的で非常に主観的な結果

この情報は、外部のリスナーの操作、比較、および誘致に関する1年半の経験に基づいています。

この体験は、コーデックを選択できるSONYウォークマンNWZ-A17プレーヤーでロスレスを聴くことと、Avantree Priva IIIを介したオーディオ出力を備えたさまざまなプログラムを視聴することに基づいています。

3つのヘッドフォンがありました。ゼンハイザーPMX 60、コスポルタプロ、コスUR-20です。

Jabra BT3030（SBC）およびAvantree Clipper Pro（aptX）がワイヤレス信号レシーバーとして使用されました。

Voombox Outdoor（SBC）スピーカーとAftershokz Trekz Titanium（aptX）骨伝導ヘッドフォンも使用されました。

すべてのイコライザーとエンハンサーがオフになりました-これは重要です。

合計：

有線接続で再生されるサウンドの品質は常に優れています。これは間違いなくです。
SBCとaptXの違いは聞くのが非常に難しく、一部の種類の音楽の場合のみです。たとえば、この記事の著者は、クラシック作曲のチェロソロの違いをはっきりと聞きましたが、バイオリンと低周波の楽器では、その違いはあまり感じられませんでした。ポップ、エレクトロニックミュージック、ロックなどの現代のジャンルでは、違いは聞こえません。場合によっては、SBCがaptXよりも音をよく伝達するように主観的に思われました。
SBCとaptX間の遅延は、同じソースに接続し、異なるレシーバーを異なる耳に挿入した場合にのみ表示されます（たとえば、左チャンネルはSBC、右チャンネルはaptXです）。写真で遅延を確認することはほとんど不可能ですが、aptXが動的なシーンとコンテンツを対象としているという話は神話であるためです。
驚きは、かなり安価で「有名ではない」Voombox Outdoorの音質に起因していました。どうやら、これは上で述べたSBCの成功した実装です。
骨伝導を伴うヘッドフォンでのaptXの実装は完全に理解不能です-テクノロジーは非常に具体的であるため、テクノロジー自体により品質の低下が顕著です。デバイスの「範囲」の狭い範囲、2つのデバイスとのペアリングの実装が非常に悪いことを考えると、Aftershokzは開発よりもマーケティングに多く投資している会社であると言えます。

あらゆる種類のスペクトルアナライザーなどを接続すれば、違いを確認できるはずだと主張しているわけではありません。しかし、人間の耳、さらに悪いことに、平均的な人間の耳はスペクトルデバイスではないため、これらすべてのニュアンスが聞こえません。

練習：修正できるものを修正する

パート1. aptXをオンにする

すでに述べたように、一部のデバイスでは、おそらく特許出願を避けるために、aptXの使用が無効になっています。

この問題は、ライブラリデバイスをスリップさせてコーデックを実装し、build.propでこのコーデックを使用する機能を設定するだけで簡単に解決できます。

インターネットには、この性質のソリューションが多数あります。 Magiskのモジュールとして認識しながら、それらを1つに結合する自由を取りました。はい、私はこのプロジェクトが本当に好きで、システムへの変更をMagiskモジュールの形で実装することは、システムを元の形で簡単にロールバックできる機能を備えたより安全で安全なソリューションだと思います。

モジュールはここからダウンロードできます。はい、githubについて知っています。いや、そこに広める時間がない限り。

aptXを含むbuild.propのエントリ、および可能であればaptX HDは、モジュールによって自動的にエミュレートされます。

パート2. SBCビットレートを増やす

すでに報告されているように、SBCコーデックには基本的にビットレートの制限はありません。ただし、メーカーは通常、すべてのタイプの受信デバイスで信頼性の高い動作を促進するために、モノラルでは342 kbit / s、ステレオでは345 kbit / sの制限を設定しています。

同時に、2007年から2015年までアクティブだったA2DP v1.2仕様では、すべてのデコードデバイスが、モノラルでは最大320 kbit / s、ステレオ信号の場合は512 kbit / sのビットレートで正しく動作する必要があります。

仕様の新しいバージョンでは、ビットレートの制限はまったくありません。 2015年以降にリリースされ、EDRをサポートする最新のヘッドフォンは、最大730 kbpsのビットレートをサポートできると想定されています。

実際、これは確かにそうではありません。 ValdikSSが実施した大規模な調査では、ほとんどすべての受信デバイスが454 kbit / sのビットレート、および507 kbit / sのビットレートのかなり大きな数で確実に動作することがわかりました。

また、 ValdikSSの調査では、aptXコーデックの音質に関する一般的な考えに反して、一部のファイルでは標準ビットレートが328 kbpsのSBCよりも悪い結果が得られる場合があり、高ビットレートSBCに切り替えると、多くの場合、 aptX、ヘッドフォン。

これらのデータに基づいて、 ValdikSSはLineage OSおよびGoogleの開発者にコメントを送信しましたが、これまでのところ反応はありませんでした。

したがって、Bluetoothスタックを手動で変更することしかできません。

ARM、任意のHEXエディター（WinHEXを使用しました）、およびデバイスのbluetooth.default.soファイルを逆コンパイルできるIDA Proが必要です。通常、パス/システム/ lib / hwにありますが、パス/システム/ lib64 / hwにもあります（ルートアクセスが必ず必要です）。

そのため、bluetooth.default.soファイルを開きます以下で説明する操作と変更は、元のAndroidスタック（bluedroid）にのみ適用されます。 IDA Proで「Needed Library 'com.qualcomm.qti.bluetooth_audio@1.0.so'」などの行が表示される場合、この命令は役に立たない可能性が高いです。

最初のタスクは、標準構成でジョイントステレオをデュアルチャネルに置き換えることです。

bta_av_build_src_cfg関数を使用します。

IDAでこの手順を見つけるには、デバッグログ「Cant parse src cap ret =％d」の特性メッセージの行検索を使用します。

その結果、非常に迅速に、コード自体の形で関数自体を見つけます。

私たちのタスクは、チェックの元の構造を置き換えることです

if (src_cap.ch_mode & A2D_SBC_IE_CH_MD_JOINT) pref_cap.ch_mode = A2D_SBC_IE_CH_MD_JOINT; else if (src_cap.ch_mode & A2D_SBC_IE_CH_MD_STEREO) pref_cap.ch_mode = A2D_SBC_IE_CH_MD_STEREO; else if (src_cap.ch_mode & A2D_SBC_IE_CH_MD_DUAL) pref_cap.ch_mode = A2D_SBC_IE_CH_MD_DUAL; else if (src_cap.ch_mode & A2D_SBC_IE_CH_MD_MONO) pref_cap.ch_mode = A2D_SBC_IE_CH_MD_MONO;</code>  <code> if (src_cap.ch_mode & A2D_SBC_IE_CH_MD_DUAL) pref_cap.ch_mode = A2D_SBC_IE_CH_MD_DUAL; else if (src_cap.ch_mode & A2D_SBC_IE_CH_MD_STEREO) pref_cap.ch_mode = A2D_SBC_IE_CH_MD_STEREO; else if (src_cap.ch_mode & A2D_SBC_IE_CH_MD_DUAL) pref_cap.ch_mode = A2D_SBC_IE_CH_MD_DUAL; else if (src_cap.ch_mode & A2D_SBC_IE_CH_MD_MONO) pref_cap.ch_mode = A2D_SBC_IE_CH_MD_MONO;

これを行うにはいくつかの方法があります。

1つ目は、TST.W R0、＃1をTST.W R0、＃4に置き換え、MOVS R0、＃1をMOVS R0、＃4にチェック順序で置き換えます。

バイトコードでは、これはx01からx04への置き換えです。このパターンを見つけることができるバイトの特徴的なシーケンスに注意することが重要です。詳細に深く入ることなく、本質的にはシーケンスの検索だと言います

 10 20 8D F8 04 00 9D F8 0D 00 10 F0 01 0F ?? ?? 10 F0 02 0F ?? ?? 10 F0 04 0F ?? ?? 10 F0 08 0F ?? ?? 08 20 ?? ?? 01 20 ?? ?? 02 20 ?? ?? 04 20

およびその置き換え

 ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? 04 ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? 04 ?? ?? ?? ?? ?? ?? ?? ?? ??

ただし、この方法には欠点があります。

多くのコンパイラーは、最適化に応じてコマンドの実行順序を変更します。この場合、目的のパターンを見つけることができず、構造内のチェックメカニズムが一般にインラインコードに導入されることがあります。したがって、定数btif_av_sbc_default_configを変更する方が信頼性が高くなります。

手始めに-彼女を見つけてください。彼女は私たちの機能のまさに始まりです。

 void bta_av_build_src_cfg (UINT8 *p_pref_cfg, UINT8 *p_src_cap) { tA2D_SBC_CIE src_cap; tA2D_SBC_CIE pref_cap; UINT8 status = 0; /* initialize it to default SBC configuration */ A2D_BldSbcInfo(AVDT_MEDIA_AUDIO, (tA2D_SBC_CIE *) &btif_av_sbc_default_config, p_pref_cfg); /* now try to build a preferred one */ /* parse configuration */ if ((status = A2D_ParsSbcInfo(&src_cap, p_src_cap, TRUE)) != 0) { APPL_TRACE_DEBUG(" Cant parse src cap ret = %d", status);

そしてここに彼女は：

btif_av_sbc_default_config自体が一連のバイト20 01 10 04 01 35 02である一方、最初のバイトはサンプリング周波数をエンコードし、10（48 kHz）および20（44 kHz）であるため、特定できないことがわかります。したがって、私たちのタスクはシーケンスを置き換えることです
01 10 04 01 35 02
に
04 ?? ?? ?? ?? ??

これにより、同様の方法で構造のロジックを変更できますが、同時にコンパイラーを最適化しても問題は発生しません。

場合によっては、ヘッドフォンまたはスピーカー自体が接続を開始します。この場合、モードはbta_av_co_audio_init関数によって決定されます。

この関数は、「bta_av_co_audio_init：％d」という行で特徴付けられ、コードで簡単に検索できます。

可能な接続モードの列挙は、次のコマンドで実行されます。

  switch (index) { case BTIF_SV_AV_AA_SBC_INDEX: /* Set up for SBC codec for SRC*/ *p_codec_type = BTA_AV_CODEC_SBC; /* This should not fail because we are using constants for parameters */ A2D_BldSbcInfo(AVDT_MEDIA_AUDIO, (tA2D_SBC_CIE *) &bta_av_co_sbc_caps, p_codec_info); /* Codec is valid */ return TRUE;

定数bta_av_co_sbc_capsの構造は次のとおりです。

 const tA2D_SBC_CIE bta_av_co_sbc_caps = { (A2D_SBC_IE_SAMP_FREQ_44), /* samp_freq */ (A2D_SBC_IE_CH_MD_MONO | A2D_SBC_IE_CH_MD_STEREO | A2D_SBC_IE_CH_MD_JOINT | A2D_SBC_IE_CH_MD_DUAL), /* ch_mode */ (A2D_SBC_IE_BLOCKS_16 | A2D_SBC_IE_BLOCKS_12 | A2D_SBC_IE_BLOCKS_8 | A2D_SBC_IE_BLOCKS_4), /* block_len */ (A2D_SBC_IE_SUBBAND_4 | A2D_SBC_IE_SUBBAND_8), /* num_subbands */ (A2D_SBC_IE_ALLOC_MD_L | A2D_SBC_IE_ALLOC_MD_S), /* alloc_mthd */ BTA_AV_CO_SBC_MAX_BITPOOL, /* max_bitpool */ A2D_SBC_IE_MIN_BITPOOL /* min_bitpool */ };

定数はコードで簡単に見つかります。私の場合は20 0F F0 0C 03 35 02です。

バイト0Fに注意してください-有効なモードのいずれかと接続する機能を提供します。

 x0F = A2D_SBC_IE_CH_MD_MONO | A2D_SBC_IE_CH_MD_STEREO | A2D_SBC_IE_CH_MD_JOINT | A2D_SBC_IE_CH_MD_DUAL = x08 | x02 | x01 | x04

私たちのタスクは、この値を次のように変更することです。

 x0F = A2D_SBC_IE_CH_MD_DUAL = x04

したがって、交換する必要があります

?? 0F F0 0C 03 35 02
に
?? 04 ?? ?? ?? ?? ??

そのため、デバイスによる接続を開始する場合と、信号受信側による接続を開始する場合の両方で、スタックをデュアルチャネルモードで強制的に接続しました。

次に、ビットレートの制限を削除するか、上限しきい値を上げる必要があります。

btif_media_task_get_sbc_rateを処理する必要があります。同様に、「non-edr a2dpシンクが検出され、レートを％dに制限」という特性線を検索するには、コード内で関数を探します。

ビットレート制限は文字列で表されます
UINT16レート= DEFAULT_SBC_BITRATE（順番に328 kbpsです）

コードでは、これは次のとおりです。

この値を454 kbit / sに変更します-これは標準よりも高く、大部分の受信デバイスで機能します。これを行うには、バイトを置き換えます

B1 4F F4 A4 74 ?? E0
に
?? ?? ?? E3 ?? ?? ??

また、パターンで検索する必要があります。

E0 4F F4 A4 74 ?? E0
そしてそれを
?? ?? ?? E3 ?? ?? ??
-これは多くのデバイスに必要です。

E3の値は、希望する最大ビットレートに応じて異なる場合があります。

E3-454 kbps
F1-482 kbps
F3-486 kbps
10-576 kbps
48-制限なし

一般的に、これは操作MOV.W R4、XXXのバイトコードによって決定されます。

実際には、すべての受信デバイスが安定した信号受信を受信する最大値を実験して選択する価値があります。クラック、中断、歪みはありません。

私の実験のすべての受信機（上記で示した）では、この値は576 kbit / sであり、Xiaomi Redmi 4x MIUI10 Android 7.1電話が信号のソースでした。

説明されたアクションに基づいて、Bluetooth.default.soで指定されたパターンを検出し、それらを置き換える汎用パッチが作成されましたか？強制デュアルチャネルモードを含め、ビットレート制限を454 kbpsに設定します。必要に応じて、制限値は、対応するバイトの検索と置換に基づいて簡単に変更できます。注意深い読者はこれを簡単に行うことができます。

パッチはbluedroidスタックの場合にのみ機能し、フッ化物スタックとAndroidバージョン8以降の場合は成功しない可能性が高いと私は強調します。

パッチはここからダウンロードできます。

オリジナルのファイルをMagiskモジュールとして置き換えることを強くお勧めします。私自身は次のようにこれを行いました。注：これらのモジュールは、執筆時点で現在のグローバルな安定したMIUI 10ファームウェアを備えたXiaomi Redmi 4x 3/32 GB電話用に作成されました。あなたの場合、上記のようにbluetooth.default.soファイルを独自のパッチで置き換える必要があります。また、ファイルをpath / system / lib64 / hwに沿って複製する必要がある可能性もあります。これは、電話機のモデルとファームウェアバージョンによって異なります。

Magiskモジュールを使用するこのアプローチにより、受信デバイスの一部がデュアルチャネルをサポートしていないことが判明した場合、最大ビットレートを簡単に変更し、一般に変更を無効にすることができます。

おわりに

現時点では、販売を追求するために、多くの企業がより高い価格の正当化としていくつかの技術革新を提出しています。

実際には、既存の安価な技術が完全に開発されておらず、技術革新が完全に実装されておらず、品質に大きな影響を与えていることがわかりました。

非常に頻繁に、ユーザーは「プラセボ効果」を体験し、製品の完成度がより新しいか、よりカラフルであるという理由だけで説得力を発揮します。実際、この品質は想像上のものです。

有線バージョンと比較してワイヤレスオーディオ伝送の品質が明らかに低下しているにもかかわらず、現代のデバイスメーカーはワイヤレステクノロジーへの完全な移行を目指しているようです。同時に、価格上昇を正当化するためにマーケティングのトリックが使用されます：電話への水浸からの保護（水の下でどのように話すことができますか？なぜデバイスを水に落としますか？）、より高価なコーデックの使用など同時に、既存の一般的なSBCコーデックの可能性が十分に活用されていません。

Googleから328 kbpsのビットレート制限に関して明確化することも、この制限をなくすこともできず、Lineage OSの開発者からBluetoothメニューでデュアルチャネルを有効にするオプションを追加することもできませんでした。

最後まで読んでくれたみんなに感謝します！

コメントでの議論とLDACコーデックに関するスペースによって引き起こされたいくつかの継続はここにあります。

Bluetoothワイヤレスオーディオテクノロジー：どちらが良いですか？