ネットワークオーディオの三要素における「再生機能」の呼び方を【プレーヤー】から【レンダラー】に変更したことを良い機会だと思って、2015年の記事をベースに新たに記事を作成した。
目次
ネットワークオーディオの三要素
私の定義する「ネットワークオーディオ」とは、「再生機器に何を使うか」ではなく、「音楽再生におけるコントロールのスタイル」である。いわゆる単体ネットワークプレーヤーを使うシステムも、いわゆるPCオーディオのシステムも、私の中では等しく「ネットワークオーディオ」となり得る。それゆえ必然的に、私自身の理解と対外的な説明のために、様々なプラットフォームを分け隔てなく扱う方法が必要だった。
すなわち、ネットワークオーディオを理解・説明するための、特定のプラットフォーム・仕組み・ハード・ソフト・システム等に限定されず、なおかつそれらすべてに適用可能な方法。
ネットワークオーディオにオーディオの未来を見出し、様々な実践と情報発信を続けるなかで、それを考えて考え続けた結果辿り着いたのが、【サーバー】【レンダラー】【コントロール】から成る「ネットワークオーディオの三要素」という概念である。また、これは同時にPCオーディオやネットワークオーディオを包含する「ファイル再生の三要素」でもある。
「ネットワークオーディオの三要素」を構成する【サーバー】【レンダラー】【コントロール】は、言うまでもなく特定のシステムで使われる固有名詞や特定の機器（ソフトを含む）を指すのではなく、それらが果たす役割／機能を意味する。
【サーバー】 ：音源の管理・運用（ライブラリ機能）
【レンダラー】 ：音源の再生
【コントロール】：音源の閲覧・選曲、各種再生操作
青矢印で示した関係性は使用するシステム次第で微妙に変化し得るが、基本的にこの理解で問題ない。【レンダラー】から【コントロール】にも小さく矢印が伸びているのは、再生している音源のスペックや再生ステータスといった情報がやり取りされていることを意味する。
「ネットワーク」オーディオであるからには、大前提として三要素を担う機器はネットワークで繋がっている。その様子を図に落とし込むとこうなる。
上の図では【サーバー】【レンダラー】にそれぞれ線が繋がっているが、【サーバー】と【レンダラー】の両方を兼ねる機器も多く、その場合はまとめて1本線が繋がるだけになる（後述する「実例」を参照）。
機器や製品そのものではなくそれが果たしている役割／機能、そして機器と機能の関係――「システムの中で【サーバー】【レンダラー】【コントロール】を担っているものは何か」を理解することで、個別のシステムの範囲を越えた、ネットワークオーディオの包括的な把握が可能になる。理解と実践を通じて実感が得られれば、使う機器が変わるたびに最初から勉強し直しだなどと嘆く必要も、何か目新しい言葉が出てくるたびにいちいち踊らされることもなくなる。
UPnP（DLNA・OpenHome）のシステムも、
BluOSのシステムも、
Roonのシステムも、
すべて【サーバー】【レンダラー】【コントロール】モデルで理解・説明可能である。
なお、「ネットワークオーディオの三要素」を構成する【サーバー】【レンダラー】【コントロール】という言葉はあくまでも私が定義する役割／機能の私なりの呼称であり、繰り返すが特定のプラットフォームにおける固有名詞や特定の機器、機能の個別の名称を指すものではない。
例えば、
【サーバー】はRoonにおける「Roon Server」そのものを意味しない。
【レンダラー】はDLNAにおける「DMR：Digital Media Renderer」そのものを意味しない。
「このネットワークプレーヤーはDLNA準拠ではないからレンダラーと呼ぶのは誤り」などと言われても、そういう次元の話をしているのではない。UPnPベースだろうとMPDベースだろうと何だろうと、システムの中で「音源の再生」を担っているのなら、それは【レンダラー】である、という考え方である。
というわけで、定義も含めて「ネットワークオーディオの三要素」というモデルはメーカーや業界団体的なところから公式扱いされているわけではないし、唯一の正解というわけでもない。私が勝手に考え出し、勝手に提唱しているだけである。異論も別案もおおいに結構。
とはいえ、「ネットワークオーディオの三要素」という概念を対外的に発表した2015年以降もRoonをはじめ様々な「新しいもの」が登場したが、今に到るまでこのモデルで苦労したことは無いと言っていい。さらに、業界で「DLNA/UPnPはこう」「Roonはこう」という具合に、個別のシステムのレベルで説明がされることはあっても、このモデル以外に、個別のシステムの範囲を越えてネットワークオーディオを包括的に理解・説明する方法を見かけること自体、皆無に等しい。
十数年に渡る私自身の実践と経験の蓄積から、各要素の呼称が真に適当かどうかはさておいて、ネットワークオーディオの三要素：【サーバー】【レンダラー】【コントロール】はネットワークオーディオの全体像の把握と個々の要素の理解、その両方に有用な考え方だと私は確信している。
「言の葉の穴」時代から今に到るまで、私は【サーバー】【レンダラー】【コントロール】それぞれの定義を一貫して使用している。【レンダラー】については最近【プレーヤー】から呼び方を変えたが、定義は変わっていない。ついでに最近は文中でネットワークオーディオの三要素を意図する際は、それを伝えるために【】←コレを使って表記するようになった。
この記事でも書いたように、真に重要なのはどう呼ぶかではなく、それが指す内容である。
ちなみに、「ネットワークオーディオの三要素」というアイデアの出発点は、DLNAにおける「デバイスクラス」である。
【サーバー】
【サーバー】は、音源の管理・運用（ライブラリ機能）を担う。
「音源の管理・運用」とは、具体的には「音源（ファイル）を読み込み、タグをはじめとする各種メタデータに基づいてデータベース化を行い、音楽ライブラリとして提示する」ことを指す。なお、ここの「読み込む」とは、再生時に【レンダラー】が【サーバー】から音声データを取ってくることとは別なので要注意。
この一連のプロセスを、私はトータルで「ライブラリ機能」と表現している。
「ライブラリ機能」により、中身の音声データ以外はファイル名の羅列に過ぎないファイル音源が、各種メタデータを用いてデータベース化され（この部分はインデックスとも表現される）、様々な端末からの多面的なアクセスが可能になる。これを担うのが【サーバー】である。
「サーバー」という言葉は一般に機器／製品ジャンルの名称としても用いられるため、Audio Renaissanceでは単に サーバー と書いた場合は【サーバー】として機能する機器／製品を、【サーバー】と書いた時は三要素のひとつを指す、と捉えていただきたい。
単一のフォルダ構成と、中身の音声データ以外はファイル名の羅列に過ぎないファイル音源が、
タグをはじめとするメタデータを用いることで、
アルバムアートを含む様々な情報に彩られ、多面的なアクセスが可能な「ライブラリ」となる（それを「どう見せるか」は【コントロール】の領分）。
JRiver Media CenterのライブラリJRiver Media Center（以下JRiver）をはじめとするライブラリ統合型の再生ソフトも、Twonky ServerといったUPnPの枠組みで使用されるサーバーソフトも、まさにこの「ライブラリ機能」を担っている＝【サーバー】として機能している。
Roonが自身の最大の強みとしてアピールしているのも、まさにこの「ライブラリ機能」である。
他の例として、BluOSはUSBストレージまたはNASの音源を読み込み、単純なリストを越えたライブラリとして活用可能である。すなわち、NODEやPOWERNODE等のBluOS搭載製品は、ネットワークプレーヤー＝【レンダラー】であり、同時に【サーバー】としての機能も持っている。
BluOSは接続したストレージ内の音源をライブラリとして活用・再生できる「ユーザーが音源を閲覧・選曲する際のライブラリ」は【サーバー】によって提示されるため、「どのようなメタデータを参照し、どのような階層構造で音源／ライブラリを提示するか」は、【サーバー】にとって非常に重要になる。このような音源の閲覧・選曲の際に用いられる階層構造は「ナビゲーションツリー」や「メディアツリー」といった名前で呼ばれる。
ナビゲーションツリーに関して、【サーバー】として機能する製品やソフトによって、例えば「ジャンル」「アーティスト」「アルバム」という基本的な項目のみ提示するものもあれば、それにくわえて「作曲者」「指揮者」「オーケストラ」といった、特にクラシックにおいて重要な項目が充実したものもある。つまり前者の場合、どれだけ頑張って「作曲者」や「指揮者」といったタグを整備しても、肝心の音源の閲覧・選曲時にそれらがまったく活かされないということになる。
またほとんどの場合、ライブラリ項目のひとつとして、読み込んだ音源フォルダ構成もそのまま提示される。これは「フォルダビュー」や「フォルダツリー」と呼ばれ、ナビゲーションツリーの中に「フォルダ」的な名称で用意されている。これのおかげで、タグに頼らずフォルダ構成そのものを自分の使いやすい形に完璧に仕上げている人も困ることはない。
【サーバー】はライブラリ機能によって「音源の閲覧・選曲」の土台を成し、【コントロール】ほどではないにせよ、システムの最終的な使い勝手に大きく影響する。だからこそ、「どんなサーバーを使うか」はネットワークオーディオにおいて極めて重大なテーマである。
このように、【サーバー】は三要素の中では【コントロール】との関係性が強い。それに比べると、【サーバー】と【レンダラー】の間は基本的に音源のデータが内的にやり取りされるだけで、外から目に見えるようなものはない。よって、両者が問題なく機能さえしていれば、実際に音楽を聴く際にこの部分が意識されることはほぼない。
もちろん、個別のプラットフォームやシステムのレベルでなら、【サーバー】と【レンダラー】の関係、つまり「音源のデータがどのように再生機能に渡されるか」という仕組みの部分はおおいに音質にも関わってくるものと思われ、話題にされて然るべきだろう。
ちなみに、ファイル再生／ネットワークオーディオ界隈で【サーバー】のみを担う機器やソフトというのは実は少ない。それこそUPnPのシステムにおける純粋なサーバーくらいである。それ以外だと、この記事で登場したBluOSもJRiverもRoonも「ミュージックサーバー」と呼ばれる製品も、すべて【サーバー】と【レンダラー】の両方を備えている。
UPnPのシステムでは【サーバー】と【レンダラー】を容易に機器レベルで分離できることをメリットと捉えるか、デメリットと捉えるかはメーカー次第＆ユーザー次第といったところだが、少なくともそれが「UPnPならではのシステム構成の高い自由度」に繋がっていることは間違いない。
ストレージとの関係
【サーバー】とは「ライブラリ機能を担うもの」であって、「ストレージの有無」は関係ない。
上で登場したBluOSを例にすると、ライブラリ機能を担うNODEが【サーバー】であって、接続するUSBメモリやNASは単なる「データの置き場所」として扱われる。
PCでJRiverやRoonやfoobar2000を使う際、音源のデータをPC内蔵のSSDに保存していようと、外付けのUSB HDDに保存していようと、NASに保存していようと、【サーバー】となるのはPC（の再生ソフト）である。
すなわち、USBメモリ≠【サーバー】、NAS≠【サーバー】である。内蔵か外付けかにかかわらず、ストレージ≠【サーバー】である。
こう書くと、素朴な疑問として「一般的にNASはサーバーと言われてるじゃないか」と思われるかもしれないが、これはもっぱらUPnPの枠組みで、NASの中で何らかのサーバーソフト（メディアサーバーとも）が動いている＝NASが【サーバー】として機能していることを意味している。
NASは、それ自体では文字通りNetwork Attached Storage＝ネットワーク接続のストレージに過ぎない。UPnP（DLNA・OpenHome）のシステムでは、NASの中でUPnP対応のサーバーソフトが動いていなければ、コントロールアプリでNASの中身の音源を見ることはできないし、ネットワークプレーヤーでNASの中身の音源を再生することもできない。NASと【サーバー】を混同してはいけない。
一例として、私が持っているSoundgenicはNAS（ストレージ）であり、オーディオ機器／製品として見るとサーバーであり、システムの中で担っているのは【サーバー】であり、SoundgenicをUPnP対応の【サーバー】たらしめているのはTwonky Serverである。
音楽ストリーミングサービス
TIDAL・Qobuz・Amazon Music等の音楽ストリーミングサービスは、インターネットの向こうにあるサーバーと捉えることができる。
例として、TaktinaとHEOSでAmazon Musicを使うとこのようになる。
■Taktina
■HEOS
「どう見せるか」はアプリ次第だが、見ての通りAmazon Musicから提示されるライブラリそのものは変わらない。
実使用上、音楽ストリーミングサービスはローカルの（要は手持ちの）サーバーとの違いを意識する必要はなく、単に「使えるサーバーが増える」という感覚で扱うことができる。
BluOS Controllerでは、音楽ソースとして「ライブラリ」（ローカルの音源）と各種音楽サービスが同列に並んでいる【レンダラー】
【レンダラー】は、音源の再生を担う。
ネットワークプレーヤー／トランスポートといった「再生機器」だけでなく、JRiverやRoonといった様々な「再生ソフト」も、システムの中で「音源の再生」を担っている。すなわち、これらはすべて【レンダラー】である。「何らかの再生ソフトが動いているPC」もまた、トータルで【レンダラー】と捉えることができる。
そして、DACを搭載してアナログ出力を行うネットワークプレーヤーだろうと、USB出力を行うPCだろうと、再生機能を果たす以上は紛れもなく【レンダラー】である。
これらはすべて【レンダラー】【レンダラー】の本質は「再生機能」であり、再生機能こそが機器やソフトを【レンダラー】たらしめる。機器のレベルでDACを搭載するか否かや音声出力がアナログかデジタルかは関係ない。もちろんシステム全体で見ればD/A変換自体はどこかで行う必要があるが、私の認識ではファイル音源の「再生」そのものはデジタル領域で完結している。
【レンダラー】は「音源の再生」に直接関わるため、DAC搭載の有無を抜きにしても三要素の中では「音質」への影響が最も大きい。だからこそ「トランスポート」にこだわる意味がある。
【レンダラー】に比べて【サーバー】が音質に与える影響はずっと小さいし、【コントロール】にいたっては、そもそも気にする必要があるのかというレベルである（一応理屈のうえでは影響はゼロではない）。
例えばUPnP対応のサーバーとネットワークトランスポートとスマートフォン／タブレットを並べた時、「どれが最も音質に影響しますか？」と問われれば、まず間違いなく答えはネットワークトランスポート、つまり【レンダラー】となる。この辺りは、「システムを構築するうえでどの部分に投資すべきか」を考える際の材料にもなる。
再生機器／ソフトの再生機能そのもの、あるいは再生に関するプログラムの核心部分を表現するために、「再生エンジン（Playback Engine）」「オーディオエンジン」「レンダリングエンジン」（！）等の言葉が用いられる場合もある。同じPCで再生ソフトAと再生ソフトBを使って、Aの方が高音質だった場合、それはAの再生エンジンの優秀さを示している。機器やソフトのアップデートでこの部分が改善されるとすれば、当然ながら音質の向上にも繋がる。
ちなみに【レンダラー】を担う機器は無駄に多くの呼称があって一見するとややこしいのだが、「担っている役割／機能は同じ」ということさえ理解してしまえば、呼称の違いなど些末な問題でしかない。例えば、「ストリーマー」とは「各種ストリーミングサービスに対応するネットワークプレーヤー／トランスポート」の単なる言い換えに過ぎない、という事実も見えてくる。
ユーザー目線からもっともっともっともっと単純化してしまえば、つまるところ【レンダラー】とは、「リモコンを向けて再生（Play）ボタンを押す対象」のことである。NASとネットワークトランスポートとDACを並べて「何に対して再生の指示を出すか」を考えれば、システムにおける【レンダラー】の所在／「再生機能」を担っているものは何かは明らかだ。
【コントロール】
【コントロール】は、音源の閲覧・選曲と各種再生操作を担う。
実際に【コントロール】の機能を果たすのは、機器のレベルで見ればPC（モニターやマウスを含む）やスマートフォン／タブレットであり、ソフトのレベルで見れば再生ソフトやコントロールアプリである。
iPhone SE3とiPad Pro 12.9インチで動くコントロールアプリ「Taktina」ユーザーはそれらを使って、【サーバー】が提示する音源／ライブラリを閲覧し（ブラウズ）、聴く曲を選び、【レンダラー】に対して再生・停止・スキップ・シークといった指示を出す。【コントロール】とは音楽を再生する際の操作全般であり、それは「音楽を聴くという行為そのもの」でもある。
また、再生操作に用いるソフト／アプリのUIやデザインといった要素も【コントロール】に包含される。上で「再生ソフトも【コントロール】の機能を果たす」と書いたが、これは再生ソフトのUIやデザインの部分、要は操作画面が【コントロール】を担うという意味である。
【サーバー】が提示するライブラリを「どう見せるか」は【コントロール】の領分である。表示される音源の情報量と使いやすさを両立することが肝要で、もし2023年にもなってアルバムアートすら見せず、文字のリストを羅列するだけのソフトやアプリがあれば、時代遅れの謗りを免れないだろう。Roonの「音楽の海」は、【サーバー】と【コントロール】の素晴らしい連携の最たる例といえる。
選曲時のプレイリスト／キュー絡みの挙動も【コントロール】の領分である。これは「聴きたい曲を自由に、スムーズに聴く」ために不可欠な部分で、ここが要領を得なければ、物理メディアの制約を受けることなく自由に音楽を聴けるというファイル再生のメリットが著しく損なわれる。
ファイル再生のシステムで音楽を聴く際、ディスク等の物理メディアは基本的に介在せず、さらに「音源の閲覧」という点では物理リモコンも用を為さない。よって、ネットワークオーディオのスタイル（後述）においてコントロールアプリは音楽再生時に事実上唯一目に触れる＆手で触れるものであり、システムのユーザビリティを最終的に決定付ける。それこそ「ネットワークオーディオで最も重要なのはコントロールアプリである」と大真面目に言っていいレベルで、その重要度は極めて高い。
どれだけ「ユーザー自身による音源管理（タグ整備）」を徹底的に行い、それを基に理想的なライブラリに仕上げてくれる【サーバー】を選び、高い安定性と優れたレスポンスを両立させた【レンダラー】を使ったとしても、最後の最後で【コントロール】を担うコントロールアプリの出来が悪ければすべて台無し。
逆に、コントロールアプリだけが優秀でも、大元の音源管理が滅茶苦茶ではサーバーから提示されるライブラリも滅茶苦茶なので秀逸なデザインも宝の持ち腐れになるし、【レンダラー】自体の安定性やレスポンスの酷さはアプリ側ではどうにもならない。結局のところ、「快適な音楽再生」という夢を実現するためには、ネットワークオーディオの三要素すべてを把握したうえで、うまいことシステムを構築するほかない。
ちなみに、なぜ【コントローラー】ではなく【コントロール】と呼ぶかといえば、単純な「リモコン」的なイメージを越えて、「音楽を聴くという行為そのもの」というニュアンスを持たせたかったからである。実際この辺は私の個人的なこだわりでしかないので、【コントローラー】と読み替えてしまっても99％問題はない。
あと、未だに（！）誤解が多いが、KazooやLUMIN Appといったコントロールアプリが行っているのはあくまで「操作」であり、「再生」ではない。よって、これらのアプリを「再生アプリ」と呼ぶのはおかしい。CDプレーヤーのリモコンを「再生機器」とは呼ばないだろう。
ネットワークオーディオの本質
私の定義するネットワークオーディオの本質とは【コントロール】である。
再生機器の設置場所という物理的制約から解放された状態で、音楽ライブラリを縦横無尽に駆け巡り、聴きたい曲を自由自在に聴く。再生機器の小さなディスプレイをにらみながら物理ボタンやリモコンをポチポチすることなく、PCに向き合ってマウスをカチカチすることもなく、オーディオルームの椅子に身を預けたまま、あるいはその辺に寝っ転がりながら、音楽再生のあらゆる操作を手元の端末から行う。
「ネットワークを用いて再生機器からコントロールを独立させる」というスタイル。これこそ、「ファイル再生」を「ネットワークオーディオ」たらしめ、ネットワークオーディオの真価たる「快適な音楽再生」を実現する。
まさにこの考え方によって、「再生機器に何を使うか」は本質的な問題ではなくなり、一般的には「PCオーディオ」と扱われるシステムもまた、使い方次第で立派にネットワークオーディオたり得るのである。
ちなみに、「ネットワークオーディオとは再生機器に何を使うかではなく、コントロールのスタイルである」という定義は、2015年にRoon Labsの代表のEnno Vandermeer氏とチャットをした際、彼から直接同意を得ている。自分の考えに確信を深めた、今となっては懐かしい思い出。
実例
ここからは、実際に「ネットワークオーディオの三要素」というモデルで様々なシステムをどのように説明・理解できるのか、というところを示す。
UPnP（DLNA・OpenHome）
LINNのDSが採用して以来、ネットワークオーディオのプラットフォームとして、なんだかんだいってUPnPはずっと主流の地位にある。ネットワークプレーヤー／トランスポートを見かけると、真っ先に「この製品はUPnPベースか、否か」という意識が働くくらいである。
同じUPnPベースでDLNAとOpenHomeというバリエーションもあるが、ここではそれらの詳細までは踏み込まない。
UPnPのシステムの実例として、以下の機器を用意した。
■Soundgenic HDL-RA2HF
■SFORZATO DST-Lacerta
■iPhone SE3（Taktina）
このシステムにおける三要素は以下の通り。
【サーバー】 ：Soundgenic HDL-RA2HF（で動いているTwonky Server）
【レンダラー】 ：SFORZATO DST-Lacerta（が採用しているITF-NET AUDIOの再生機能）
【コントロール】：iPhone SE3（で動くTaktina）
TaktinaがSoundgenicの中身の音源を閲覧し、曲を選び、DST-Lacertaに指示を出し、音源が再生される。DST-Lacertaの持つデジタル出力はUSBのみなので、後段にはUSB DACが繋がる。
ネットワーク接続も含めて三要素と機器の関係を図にするとこうなる。
UPnPのシステムは【サーバー】と【レンダラー】を機器のレベルで分離でき、「ひとつの機器に対してひとつの役割」という構成が可能なので、ネットワークオーディオの三要素での理解が最もたやすい。
SoundgenicとDST-Lacertaの組み合わせはDirettaも使用可能であり、その辺は応用編となる。
BluOS
Bluesoundの手掛けるネットワークオーディオのプラットフォーム「BluOS」は、自社製品に搭載されるだけでなく、優れた完成度が認められて他社製品への採用も広がっている。自由度の高さゆえに機器やアプリの汎用・専用の区別が問題となるUPnPとは異なり、BluOSは三要素のすべてが純正の組み合わせとなるため、システムの構築が容易なこともメリットといえる。
BluOSのシステムの実例として、以下の機器を用意した。
■NODE (2021)
■iPad Pro 12.9インチ（BluOS Controller）
このシステムにおける三要素は以下の通り。
【サーバー】 ：NODE（が搭載するBluOSのライブラリ機能）
【レンダラー】 ：NODE（が搭載するBluOSの再生機能）
【コントロール】：iPad Pro（で動くBluOS Controller）
BluOS搭載製品は接続したストレージ（USBまたはNAS）を読み込み、自らのライブラリ機能でもってデータベース化を行う。よって、このシステムにおける【サーバー】の所在はあくまでもNODEである。
BluOS ControllerがNODEに接続されたストレージの中身の音源を閲覧し、曲を選び、NODEに指示を出し、音源が再生される。NODEはアナログ・デジタル共に様々な出力を持つので、後段はご自由に。
ネットワーク接続も含めて三要素と機器の関係を図にするとこうなる。NODEをはじめ、BluOS搭載製品は無線接続にも対応する。
BluOS搭載製品はどちらかといえば音楽ストリーミングサービスとの連携を志向しており、あまり意識されないが、ローカルの音源を再生するうえでは【サーバー】と【レンダラー】の両方を兼ねる、いわゆる「ミュージックサーバー」として機能しているのがわかる。
JRiver Media Center
JRiver Media Center（略してJRiver、JRMCとも）は長い歴史を持つ、「ライブラリ統合型の再生ソフト」の代表格である。一応は画像と映像も扱うマルチメディア対応のソフトだが、日本だとその辺はあまり意識されない。非常に充実したライブラリ機能、ハイレゾ音源の再生や柔軟なアップサンプリング等に対応する強力な再生機能を備え、さらにリモートコントロールを可能にする専用コントロールアプリ「JRemote」も完成度が高い。
多くの美点を持つJRiverは、今なおPCを再生機器に使う場合の有力な選択肢であり続けている。もっとも、強力なライバルとなるRoonが登場したことや、未だにTIDAL・Qobuzにネイティブ対応しないことから、近年ではだいぶ存在感に陰りが見えているのも確かだが……
JRiver Media Centerのシステムの実例として、以下の機器を用意した。
■ノートPC
（iFi audio ZEN DACは三要素とは無関係）
このシステムにおける三要素は以下の通り。
【サーバー】 ：PC（で動くJRiverのライブラリ機能）
【レンダラー】 ：PC（で動くJRiverの再生機能）
【コントロール】：PC（で動くJRiverの操作画面）
PCで動くJRiverが【サーバー】【レンダラー】【コントロール】のすべてを担う。実際の操作はPCのモニターやマウス等を介して行われる。
もちろん、これではただの「PCオーディオ」であり、「ネットワークオーディオ」ではない。
このシステムを「ネットワークオーディオ」たらしめるには、PCから【コントロール】を独立させてやればいい。そのために、JRiverには専用コントロールアプリ「JRemote」がある。
すると、こうなる。
■ノートPC
■iPad Pro 12.9インチ（JRemote）
このシステムにおける三要素は以下の通り。
【サーバー】 ：PC（で動くJRiverのライブラリ機能）
【レンダラー】 ：PC（で動くJRiverの再生機能）
【コントロール】：iPad Pro（で動くJRemote）
JRemoteがJRiverのライブラリを閲覧し、曲を選び、再生指示を出し、音源が再生される。PCからのUSB出力がZEN DACに繋がる。
ネットワーク接続も含めて三要素と機器の関係を図にするとこうなる。
実際には写真のようなデスクトップオーディオのシステムだと、音楽を聴くにも何をするにもPCの存在が前提となるため、特にPCから【コントロール】を独立させる意味はない＝PCオーディオのままでまったく問題はない。
しかし、普通の部屋やオーディオルームに設置するオーディオで、なおかつPCとJRiverの組み合わせを再生機器として使いたいとなった時は、ネットワークオーディオのスタイルによって活路が開ける。たとえ再生機器にPCを使っていようと、音楽を聴くためにいちいちPCに向き合ってマウスをカチカチする必要はない。そんな時代はとっくの昔に終わっている。
Roon
Roonは2015年に登場したライブラリ統合型の再生ソフトであり、「聴くだけにとどまらない多面的な音楽の楽しみ」が得られることから、私は「総合音楽鑑賞ソフト」と表現している。
Roonは「Core」だの「Control」だの「Output」だの「Roon Server」だの「Roon Remote」だの「Roon Bridge」だの「Roon Ready」だの「Roon Tested」だの「RAAT」だの、とにかく大量の固有名詞が登場する。さらに、「Roon Ready」の仕組みをもってRoon自体がひとつのプラットフォームとしての性格も持つようになっている。しかも、開発元のRoon Labsがいきなり機能の呼び方や説明を変えることすらある。
こんなありさまなので、Roonの全体像を把握し、単語の意味を理解することは、はっきり言ってなかなかに難しい。現に、Roonに関する滅茶苦茶な言説をいたるところで目にする。このサイトのRoonの解説記事はかなり初期に作ったものがほとんどなので、そろそろこの記事のように全面的にリニューアルしなければとも思っている。
しかし、それはそれとして、Roonのシステムも【サーバー】【レンダラー】【コントロール】モデルで理解・説明可能である。恐れる必要はない。
Roonのシステムの実例として、以下の機器を用意した。
■ノートPC（全部入りの「Roon」をインストール）
（iFi audio ZEN Streamは三要素とは無関係）
このシステムにおける三要素は以下の通り。
【サーバー】 ：PC（で動くRoonのライブラリ機能）
【レンダラー】 ：PC（で動くRoonの再生機能）
【コントロール】：PC（で動くRoonの操作画面）
PCで動くRoonが【サーバー】【レンダラー】【コントロール】のすべてを担う。実際の操作はPCのモニターやマウス等を介して行われる。
つまり、JRiverの場合とまったく同じである。これではただの「PCオーディオ」であって「ネットワークオーディオ」ではない、というところも同じである。仮にRoonでTIDALやQobuzを使っていても＝システムにネットワークという要素が介在していても、【コントロール】が再生機器と一体化している以上、これはネットワークオーディオの実践ではない。
このシステムを「ネットワークオーディオ」たらしめるには、PCから【コントロール】を独立させてやればいい。そのために、Roonには専用コントロールアプリ「Roon Remote」がある。
すると、こうなる。
■ノートPC
■iPad Pro 12.9インチ（Roon Remote）
このシステムにおける三要素は以下の通り。
【サーバー】 ：PC（で動くRoonのライブラリ機能）
【レンダラー】 ：PC（で動くRoonの再生機能）
【コントロール】：iPad Pro（で動くRoon Remote）
Roon RemoteがRoonのライブラリを閲覧し、曲を選び、再生指示を出し、音源が再生される。この例では接続相手のZEN StreamがRoon Readyに対応しているので、出力はLANで行われる。
ネットワーク接続も含めて三要素と機器の関係を図にするとこうなる。
これまたJRiverと同じく、デスクトップオーディオのシステムなら、PCから【コントロール】を独立させる意味はない＝PCオーディオのままでまったく問題はない。
しかし、普通の部屋やオーディオルームに設置するオーディオでもRoonを使いたいとなった時は、ネットワークオーディオのスタイルの出番である。
さて、上の実例でノートPCは【コントロール】を別端末のRoon Remoteに任せ、【サーバー】と【レンダラー】の役割に特化している。Roonの枠組みではこのような機能の組み合わせ、ないしそれを果たす＝Roonの「Core」が動いている機器を「Roon Server」と呼ぶ。
本来であればここで「Core」の話もしっかりする必要があるのだが、長くなるのでそこまで踏み込まない。
この「Roon Server」は単体オーディオ機器としても存在しており、Roon Labsが純正品として作っている「Nucleus」等の製品がある。Roonのシステムで高音質を狙おうと思えば、そうした製品（単体Roon Server）を使う、オーディオ専用に構築したPCをRoon Serverとして使うといった方法がある。
よくRoon界隈で「コアを替えたら音が変わった」という話題が出るが、RoonのCoreが動く機器＝Roon Serverを替えるというのはすなわち「再生機器を替える」ことにほかならず、そりゃ音が変わって当然である。
