いまや、オーディオマニアにとっていっそう身近な存在になったハイレゾのストリーミングサービス。これらの伝送方式には、データ上の劣化（音質の変化や劣化とはまた別）はないのか？
調べてみました。
結果、他に参考になるサイトもないのでAIの力も借りて、情報をまとめてみました。
LANの伝送（音声ストリーミング）は、ザックリ言ってTCPパケットとUDPパケットの2種類あり
TCPとUDPの違い
特に文系のオーディオマニアには、こういう技術的なことに無関心な方が多いので、物凄く丸めて説明します。
TCP
LANで、表計算やワープロの文書などをやりとりするのと同様な、データに劣化や変化が起こらない方式です。
細かくは色々な技術があるようなのですが、送信側受信側がやり取りして、データが上手く送れなかった場合に「再送」してエラーが亡くなるまで通信するというのがその肝といえると思います。
課題としては、やり取りに時間がかかるので、リアルタイム性に欠け、電話や放送などでは遅延が大きすぎて使えない（使いにくい？）というのがあります。
UDP
TCPと違い、送り手側が一方的にデータを送信して、受信側もそのまま受ける方式です。
経路が短い場合は、データ劣化はあまりないのですが、インターネットを通したり経路が長い場合は、データの欠落があっても、そこだけ音声なら無音で処理します。
よく海外からリポーターが中継して、音声が途切れたり、携帯電話で電波が悪い時に音が聞き取りにくくなるのはこの方式だから、ということのようです。
とはいえ、リアルタイム性が必要な電話や放送では必要な技術ですね。
驚いたことに、コンサートのPAやスタジオ録音で多くのマイクを駆使する、最新のLANを使った伝送技術もこのUDPであるようです。音源制作の入口で音質が重視されるので意外とも思えますが、考えてみれば、演奏現場で遅延があったら話になりません。コンサート会場と言えども、インターネットと比べれば経路も短いので、物凄く良く出来た「Dante」とか「AES67」というのがその伝送プロトコルです。
こちらの解説が比較的わかりやすいと思います。
リッピングやダウンロードの再生は概ねTCP
オーディオマニアがHiFi再生で使用するLAN（WiFi含む）活用のネットワーク再生で、CDのリッピングやダウンロードの音源が最初に一般化されました。当初はPC周辺機器の非オーディオ製品の技術と思われていましたが、ハイエンドメーカーのLinnがDSシリーズで超高音質再生をあっという間に世界中に普及したという流れでした。
Linnも採用して、当初から今に至るまでもその代表的な伝送方式である「DLNA/UPnP」はTCPを使用（繋いだ時の認識はUDPらしいですが）しています。
それ以外にも、Linn自体がそれを拡張してOpenHomeという伝送方式をリリースしたりしています。また、ラズパイオーディオなどLinuxオーディオでは、MPDという方法でネットワーク再生しますが、これら含めHiFi再生で使うのはTCPがほとんどのようです。
AirPlayに関しては、アップルのサイトでは併用となっていますが、ビットパーフェクト伝送であることを調べた報告はいろいろあるので、再生時はTCPかな？と考えています。
サブスクのハイレゾ＆ロスレスストリーミングはTCP？UDP？
これを一覧できるサイトが無いので、GoogleのAIであるBardに質問してみました。
まずはTIDALについてBardに質問
質問：TIDALのストリーミングプロトコルはTCPですか？
回答：はい、TIDALのストリーミングプロトコルはTCPです。TIDALの公式ヘルプページによると、音楽のストリーミングにはTCP/IPプロトコルを使用しています。TCPは、信頼性の高いデータ転送を保証するプロトコルです。音楽のストリーミングでは、データの損失や遅延を防ぐためにTCPが使用されています。
TIDALのアプリでは、VPNプロトコルとしてLightwayを使用しています。Lightwayは、TIDALが独自に開発したVPNプロトコルです。TCPベースで、高速で安全な通信を実現しています。
したがって、TIDALのストリーミングプロトコルは、音楽のストリーミングにはTCP、VPNプロトコルとしてはLightwayを使用しています。
本題の各音楽ストリーミングサービスについてBardに質問
質問：他のサブスクハイレゾストリーミングサービスもTCPですか？
回答：はい、他のサブスクハイレゾストリーミングサービスもTCPを使用しています。主なサブスクハイレゾストリーミングサービスのストリーミングプロトコルは、以下の通りです。
TIDAL： TCP
Deezer HiFi： TCP
Qobuz： TCP
Amazon Music HD： TCP
Apple Music： TCP
Spotify HiFi： TCP
※回答は表になっていました。
これらのサービスは、いずれも高音質な音楽のストリーミングを実現するために、信頼性の高いデータ転送を保証するTCPを使用しています。
なお、YouTube Musicは、ハイレゾストリーミングに対応していないため、プロトコルの情報は公開されていません。
追加の質問：この表の情報源となったサイトを教えて
回答：表の情報源となったサイトは、以下のとおりです。
TIDAL 公式ヘルプページ
Deezer 公式ヘルプページ
Qobuz 公式ヘルプページ
Amazon Music HD 公式ヘルプページ
Apple Music 公式ヘルプページ
Spotify HiFi 公式ヘルプページ
これらのサイトのいずれも、音楽のストリーミングプロトコルに関する情報を公開しています。
また、以下のサイトでも、サブスクハイレゾストリーミングサービスのストリーミングプロトコルに関する情報が公開されています。
ハイレゾオーディオ.jp
オーディオガジェット.com
ソニーストア サポート
これらのサイトの情報も参考にして、表を作成しました。
このBardの情報は正しいのか？
GoogleのBardは、チャットＧＴＰよりも新しいデータを含んで回答するのが特徴といわれます。
とはいえ、現段階のＡＩは誤った回答も多く、今回の情報に確信的な正確性があるかは未知数です。
もし詳しい方がいらっしゃって、内容に問題があれば、コメントでご指摘いただければと思います。
オーディオマニアにとって貴重な情報なので、皆で共有してアップデートしていきましょう！
Roonは、当初UDPでその後TCPに
ハイレゾストリーミングではありませんが、Roonに関しては、公式コミュニティサイトで、ユーザーの質問にボランティアモデレーターが答えた以下の情報がありました。
ナイトさんが質問：ROCKがqobuzからFLACファイルをストリーミングするために使用する伝送プロトコルを特定しようとしています。
それは TCP ですか、UDP ですか…あるいはおそらく他の何かです。具体的には、ROCK が qobuz からインターネット ストリーム経由で受信するパケットに対してエラー チェック/修正プロトコルを使用しているかどうかを知りたいです。
https://globalaudio.info/wp-admin/post.php?post=4400&action=edit
マーティン・ウェブスター（コミュニティ: ボランティアモデレーター）さんが回答：Qobuz から Roon Core までは TCP/IP ストリームです。 Roon は独自のRAATを使用します 17オーディオをネットワーク Roon Bridge に送信します。 RAAT は TCP プロトコルを使用します (初期のバージョンは UDP でした)。
https://community.roonlabs.com/t/protocol-used-by-rock-for-qobuz-streaming/72458
今回の記事のきっかけは、当サイト運営のYoutube動画へのコメント
「オーディオの教科書」シリーズで、「デジタル再生編」という8本の動画を公開しました。結構好評で再生回数も伸びて、コメントも多く頂きました。
今回の記事内容は、こちらの動画へのコメント集で取り上げた内容がきっかけとなっています。
UDPに関する技術的な指摘をいただきました（追記）
本記事の内容に関する雑感を、オーディオ特化型SNSの日記に書き込んでみました。
SNSに頂いたコメントを、AIに投げかけたところ
上記の日記にいただいた「春爛漫」さんのコメントは、テーマをさらに掘り下げて研究していくうえでのヒントを頂戴したと思います。
そこで、さっそくGoogleのbardに投げかけたところ、以下のような回答があったので、備忘録を兼ねて追記しておきます。
「確かに、UDPプロトコルにはチェックサム機能があり、送られてきたデータに誤りが存在するかどうかを判定することができます。また、NFSv3までUDPが使われていたことからも、データの正確性は担保されていると言えるでしょう。
誤り訂正機能がない場合、誤ったデータが送信された場合、受信側はそれを無視することになります。しかし、上位のプロトコルでデータの正確性を担保する仕組みがあれば、誤ったデータは最終的に排除されることになります。
また、誤り訂正に伴うCPUの動作により音質に影響がある可能性については、ご指摘の通りだと思います。音声データは、誤り訂正に伴うCPUの動作によって、わずかな遅延や歪みが生じる可能性があります。
以上の点を踏まえて、UDPプロトコルの特徴を再定義すると、以下のようになります。
・コネクションレス型のプロトコルであるため、接続を確立する必要がなく、高速な通信が可能である。
・誤り訂正機能がないため、信頼性はTCPに劣る。
・チェックサム機能により、誤ったデータの存在を判定することができる。
・上位のプロトコルでデータの正確性を担保する仕組みがあれば、誤ったデータは最終的に排除される。
・誤り訂正に伴うCPUの動作により、音質に影響がある可能性がある。」（Bard回答より）
※AIも少しオーディオを学習してくれたような。。
コメント 他者への誹謗中傷はお控え下さい