ネットワークプレーヤーにおけるDSDネイティブ再生の考察

最近ネットワーク経由のDSDネイティブ再生についてはJRMCのDoPE(DoP Ethernet)とかバッファローのDSD対応NASとかいろいろ出てきてわかりにくくなってきたんで自分なりにまとめてみました。(前回の記事も参考にお読みください)
このDSDネイティブ再生に限らずデータ伝送というものを考える際のポイントは伝送している中身はなにか?それをどう知るのか?ということです。本記事ではこの点に着目して考察していきます。

*PC上でのDSDネイティブ再生
例) PC->USB->DSD対応 DAC

まずPCの(従来の)USBでのDSDネイティブ再生ですが、まず再生ソフトウエアはハードディスクなどからDSDファイルを読みます。このときはファイルの拡張子で中身が何かを知ることができます。そして再生ソフトウエアからドライバーやCoreaudio経由でDACに転送するときは、これらの続くシステムソフトウエアが中身がPCMかDSDかを知ることが重要です。これはUSBにしろSPDIFにしろ、オーディオデータとしてハードにアクセスするときに搬送するフォーマットを知る必要があるからです。つまり単なるバイナリの塊ではなく、クロックとかサンプル、タイミングというものを意識したオーディオデータとしてドライバーがDACに送っているからですね。それゆえ中身としてDSDを認識できないシステムソフトウエア(ASIO以外のほとんど)では一般的なPCMに見せかけたDoPが必要になります。以降はこれを踏まえてご覧ください。

*ネットワークプレーヤーにおけるDSDネイティブ再生
例) NAS->DLNA->DSD ネットワークプレーヤー

- DLNAでのネットワーク接続

ネットワーク経由でのDSDネイティブ再生ですが、ネットワークにもいろいろあります。そこではじめにDLNAの話をします。
DLNAというのは決め事のようなもので、実体はプロトコルとしてuPnPを使用しています。またuPnPはつまるところhttpを使用しています(ウエブと同じ)。すなわち一番下のレイヤーはhttpです。(アプリケーション層では一番下という意味です、と書いておきます)
ここでのポイントはhttpはどうやって伝送している中身を知るか、ということです。それはファイルの拡張子ではなく、インターネット上の約束事であるMIMEタイプを使います。これは歴史的な理由からですが、MIMEは元は電子メールのためのものです。もともとインターネットはアメリカの文化ですから英字(ABC)だけ表現すればよく、それは7bitで足ります(これをASCIIコードといいます)。そのため初期のインターネットは7bitでのデータ送信を前提にしていました。
しかしネットが進化して日本語のように漢字や半角カナが使われたり画像が送られるようになると7bitではなく8bitをフルに使ってさらに2バイト以上の表現が必要になってきました。これを識別するのがMIMEです。MIMEはインターネット上の拡張子といっても良いかもしれません。MIMEを省略した場合にはインターネットの約束として7bitのASCIIテキストとみなされます。(これは見かけ上はUTF8のBOMなしと同じという点がミソなのですが、別の話なので省略します)
MIMEタイプがないとPCで言うとファイルの拡張子がないのと同じですから受け手は開き方が分かりませんし、送り手は伝送の仕方が分かりません。MIMEは具体的に書くと(audio/wav)のような記述です。
ストリーミングはファイル転送しながら逐次再生することと同じです。ストリーミング再生はhttpだけではありませんが、http(DLNA)ではMIMEタイプを知ることでストリーミング再生とかライブラリの取得ができるというわけです。

次にこれを踏まえたDLNAの問題点です。それはDSDファイルがMIMEタイプとして標準化されていないという点です。
実のところ昨年の春のハイエンドショウの時点ですでにスフォルツァートがDSD対応のネットワークプレーヤーを出していましたが、これはWAVにDoPを埋め込むといういわゆるminimServerでいうところのトランスコードしていたわけです。スフォルツァートはDLNA対応ですが、なぜこうしていたかというと、DLNAというものがMIMEタイプでDSDを規定していないからです。DSDファイル形式を考えに入れていないからメディアサーバー内(NAS)のDSDファイルがそもそも見えないということによります。下記に記事を書いています。
2012/5/19のハイエンドショウ記事

今回発表されたバッファローの「DSD対応NAS」は下記のitmediaリンクを見ると書いてありますが、「拡張子」を変えたとありますがこれはMIMEタイプのことでしょう。これを仮に規定することでDLNAでのDSDの再生やリストというものができるようになったというわけです。
itmediaリンク- DSDのネットワーク再生を推進するバッファロー

- DoPE(DoP Ethernet)とは

一方でこれまで見てきたDLNA改良の枠内でDSD再生が可能ならば、DoPEとはなにか、これは必要なのかということが問題となります。
なぜかというと、DLNAでDSDがaudioデータとして伝送されるならば、http上はサンプルとかクロックを意識しないバイナリの塊ですからファイルの中身がPCMかDSDかは気にしないはずです(PCで言えばバルク転送)。つまりPCMに見せかける必要もなく、DoPは必要ないはずです。上で書いたように本来ネットワークサーバーではDSDファイルそのままで転送できるはずなので、DoPのようにPCMエンコードというひと手間をかける必要はないように思えます。

これはJRMCのエンジニアに直接聞いてみたんですが、やはり私の上の考えは正しいようで、ネット上でDoP(PCM)にする必要性は本来はないそうです。それではDoPE(DoP Ethernet)とはなにかというと、RenduなどはもともとMinimServer(DLNAメディアサーバー)がサポートしているトランスコードの仕組みでDSDネイティブ再生がなされています。トランスコードはつまり昨年のスフォルツァートのような中身がDSD(DoP)でガワはWAVみたいなやつです。基本的にこの転送に対応しているように設計しているので、DSDに関してはDSDそのままではなく、DoPエンコードを前提としています。
つまりJRMCからRenduにDLNAの仕組み(=uPnP/http)でネット経由で送るときにも本来はDSDそのもので送れるにしても、Renduの都合を考えてDoPでエンコードして送っているわけです。DoPEではMIMEタイプはaudio/wavを使用しているということです。つまりDoPEとはMinimServerで言っているトランスコードと同じですね。ファイルはWAVで中身をDSD(DoP)にしています。
JRMCエンジニアの話によるとDoPEの必要性はこうしてDoPを必要とするレンダラーに送信できると共に、DSDフォーマットをWAVに統一できるというメリットがあるということです。

- DLNA以外のネットワーク接続

またネット越し(ネットワーク透過)といってもDLNAだけではありません。OppoではSMBではDSDネイティブ再生できているけど、DLNAではできないという問題もあったようです。(対応予定とのこと)
前述したように問題にしているのはhttpでのmimeタイプですから、OppoのSMB接続はこの点(DLNAでのMIME問題)は問題にならないですね。SMBはファイルシステムの延長ですから、中身が何かは通常のPCの拡張子でわかります。
SMBの下位はNetBIOSですから転送というより共有ですね。NetBIOSでOKということは、Samba使えばLinuxでもオーケーということです。OppoとMPDではこれで大丈夫ではないかと思います。

*

ちなみにネットワークでのDSDネイティブ再生と言っているものはどの場合でもそうですが、PC上でローカルにUSBやSPDIFでDACにDSDデータを伝送しているのとは話しているレベルが違います。ネットワークでのDSDネイティブ再生と言っているのはPC上でローカルの場合で言うと再生プレーヤーソフトがファイルを読む段階の話です。DACに出すときの話ではありません。端的に言うとPC上ではHDDからDSDファイルを簡単に読めますが、そのファイルがネット越しにあると読むのにひと工夫必要になるということです。