動作確認NAPとDSD再生について

選択で並び順が替わります

投稿者:pianori  投稿日時:2015/04/30 10:52 親投稿 - 子投稿.1 .2 .3 .4 .5 .6 .7 .8 .9 .10 .11 .12 .13 .14 .15 .16 No.1

このRockDiskNextで公式に動作確認ができているNAPって2014年6月のリストのままなのでしょうか?
DSD対応となってますが、DSDファイル再生を動作確認できているNAPがあまりに少なすぎませんか?ごく一部のPioneer製品だけですよね。
ちなみにTASCAM CD-240とRockDiskNextではDSDファイルは再生できませんでした。TASCAM CD-240とUSB-HDD直結ならOKなのですが・・・。
ファームウェアの更新で改善されていくものなのでしょうか?

投稿者:pianori  投稿日時:2015/04/30 12:30 親投稿 - 子投稿なし No.2

投稿した者です。一応問題解決しました。
TASCAM CD-240の場合はDLNA経由ではDSD再生できませんが、HomeMedia経由だと再生可能であることが判明しました。

投稿者:え?  投稿日時:2015/04/30 17:09 親投稿 - 子投稿なし No.3

基本的にRockdiskNextはサーバなので、認識、再生できるかは、それを読み込む側の機器の仕様の問題です。
><ご注意事項>
> 本製品のメディアサーバー機能は、メディアファイルを再生機器に配信す
>る機能です。 ファイルの再生可否は 再生機器に依存します。
> 配信したファイルすべてが再生できることを保証するものではございま
>せん。あらかじめご了承ください。
と明記があるように、配信はするが、それを認識、再生できるかは、再生機器のファームウェアの機能に依存するので、Rockdisk側では対応が出来ないと思われます。

DLNA経由で、DSDを受信、再生可能な機器であるかがひとつの基準になるかとは思いますが、厳密にはUPnP-AVメディアサーバー(DLNA1.5相当)なので、非互換部分に依存する処理があったりする場合はその限りではないと思われます。

投稿者:pianori  投稿日時:2015/05/01 11:16 親投稿 - 子投稿.1 No.4

コメントありがとうございます。
一つ確認をしておきたいのですが、TASCAM CD-240の仕様をご覧になりましたでしょうか?
TASCAM CD-240ではDLNA/HomeMedia機能の両方でDSDに対応している、とあります。
http://tascam.jp/product/cd-240/specifications/
この仕様を読む限りでは再生機器側のDSD対応は問題はないはずですが、実際は

×DLNA経由-DSD再生
○Home Media経由-DSD再生

なので謎が残るわけです。
これって詰まるところは再生機器側のファームウェアの問題になるのですか?

投稿者:pianori  投稿日時:2015/05/01 11:37 親投稿 - 子投稿なし No.6

あ、そうそう、投稿者名ぐらいちゃんと書いておいてね。
え? じゃなくてさ。

投稿者:Takeshich  投稿日時:2015/05/01 12:12 親投稿 - 子投稿なし No.5

pianoriさん

>×DLNA経由-DSD再生
>○Home Media経由-DSD再生
>なので謎が残るわけです。
>これって詰まるところは再生機器側のファームウェアの問題になるのですか?

どう確認されたのかが不明なので、ハッキリとは言えないのですが、使用されているプレーヤーはDSFのみの対応と記述されています。dffを再生しようとしてできないわけではないですよね?

それとDLNAのDSD配信はガイドラインで扱われているか不明です。統一の規格が怪しいので、渡す側と受け取る側の齟齬が生じる場合もあります。
さらに、そもそも配信方式も複数あります。DSDをそのまま配信する方式とかPCMにWrapするDoPE方式とか。

RockDiskNextはDSDをそのまま配信する方式です。
プレイヤーのドキュメントをざっと確認したところどの方式に対応しているか明記されていなかったので、プレイヤーのサポートに確認してみてはいかがでしょうか?

もし、DSDをそのまま配信する方式であっても、
再生側がサーバからの応答を厳格に解釈してしまうのであれば、再生できない場合もありますし、送られてきたデータ部のみを見て再生側で寛容に解釈すれば再生できるという場合もあります。

ですので、問題というよりも再生機器側の実装によるところです。

ただ、RockDiskNextのメディアサーバのDSD配信の実装も微妙で、.dsfのMIMEをaudio/x-dsdとしているのに
http-get:*:audio/dsf:DLNA.ORG_PN=DSF
と返していたりしています。

投稿者:pianori  投稿日時:2015/05/01 12:54 親投稿 - 子投稿なし No.7

Takeshichさん

コメントありがとうございます。
動作確認はごく通常のネットオーディオの再生のやり方で行っており、ファイルはもちろんdsf.です。

>ですので、問題というよりも再生機器側の実装によるところです。
ただ、RockDiskNextのメディアサーバのDSD配信の実装も微妙/

どうもDLNAのDSD配信というのはまだまだ不可解な部分が残っているようですね。困惑しているユーザーも少なくないでしょう。
一応TASCAMにも問い合わせ入れていますので、何らかの回答が得られると思います。



投稿者:Wet  投稿日時:2015/05/01 13:44 親投稿 - 子投稿.1 No.8

DSDはDLNA1.5のガイドラインに含まれません.
どのメーカーも独自実装です.

ONKYOはRockDiskNextには対応してません.
TEACやTASCAMはONKYOと同じです.
TEACに問い合わせた経験ではHOME MEDIAで使う結論でした.

多分Twonky Server搭載NASなら使えますよ.
ONKYOは純正品としてNASを売る唯一の国内オーディオメーカーです.
その中身はTwonky Serverです.

投稿者:たく  投稿日時:2015/05/01 20:31 親投稿 - 子投稿.1 No.10

pianoriさん

一応、情報までに

RockDiskNextに下記のdsfサンプルファイルで確認してみました。
・e-onkyo のサンプル「チャイコフスキー: SOUVENIR de Florence op. 70: I. Allegro con spirito」(

DSF 2.8MHz/1bit)

・RockDiskNextから配信されてる主な情報
Media Class:object.item.audioItem.musicTrack
contentUri:http://192.168.10.4:8200/MediaItems/1652.dsf
protocolInfo:http-get:*:audio/x-dsd:DLNA.ORG_OP=01;DLNA.ORG_CI=0;DLNA.ORG_FLAGS=01700000000000000000000000000000

となりました。

Takeshichさんが書いてる様に「http-get:*:audio/dsf:DLNA.ORG_PN=DSF」とクライアントには通知してるけど
メディアサーバーのdbには MIME:audio/x-dsd で登録されてるので、再生時のコンテンツのprotocolInfoは「audio/x-dsd」になってしまってるようです。

CD-240を所有したませんので「MIME:audio/x-dsd」に対応してるか確認はできませんが、
CD-240が 「audio/x-dsd」 を受信できるようになるか
RockDiskNextが 「audio/x-dsf」 も配信出来るようになれば、DLNAで聞く事が出来ると思います。

ちなみに、たまたま見かけた OPPO BDP-103のDSD関係のMIMEは下記のようでした。
dsf = audio/dsf
dsd = audio/dsd
dff = audio/dff
何でも来い状態ですね…、なのでDLNAの動作確認出来たのかと。

という事で、DSDに対するDLNAの規格が無いので どっちが悪いとは判断できません
両社に要望として出すのが良いかと思います。


あと、ご存知かとは思いますが CD-240の取扱説明書には
「リモート再生では、本機の次のフォーマットには対応していません
  FLAC、Ogg Vorbis、DSD」
とあるので、本体からしか再生出来ないのかもしれませんね。

投稿者:pianori  投稿日時:2015/05/01 23:06 親投稿 - 子投稿なし No.9

>TEACに問い合わせた経験ではHOME MEDIAで使う結論でした.
やはりそうですか。
現状としてはHome Mediaで使えている以上不便はないのですが、Home Mediaで使えるからいい、という結論では納得いかない部分もあります。今後DLNAの新しいガイドラインなりができてDSDデータの機器間のやりとりが問題なく行えるようになる事を期待するとしましょう。
ONKYOのNASの情報もありがとうございました。

投稿者:pianori  投稿日時:2015/05/01 23:30 親投稿 - 子投稿なし No.11

たく さん

豊富な情報をいただきありがとうございます。

>CD-240が 「audio/x-dsd」 を受信できるようになるか
RockDiskNextが 「audio/x-dsf」 も配信出来るようになれば、DLNAで聞く事が出来ると思います。

なるほど、勉強になります。IO DATAが発表している動作確認機器リストはその辺りのデータ送受信の適合具合が関係しているのですね。

>「リモート再生では、本機の次のフォーマットには対応していませんFLAC、Ogg Vorbis、DSD」とあるので、本体からしか再生出来ないのかもしれませんね。

これについては、HomeMedia経由でFLACもDSDも再生できていますので、おそらく別の意味だと思われます。どうもWindows Media Playerなどのアプリケーションからのリモート再生の事を指しているようです。

投稿者:たく  投稿日時:2015/05/02 00:08 親投稿 - 子投稿なし No.12

pianoriさん

「audio/x-」の「x-」はMIMEのsubtypeがRFCで決まってない場合使われます。xが取れるまでは、各メーカーの独自仕様となってしまうのではないかと思います。
この辺、各社がユーザーの為に歩み寄って暗黙の了解的にdsfはコレと決めてくれれば、すごく助かるのではと思います。
DLNA側に反映されるのはその後になるか、「x-」のままで固定されるか、まだまだ先かと思います。

今、ソニーの「Media Go」のDLNAサーバーの方を確認していたのですが、こちらも「audio/x-dsd」となりました。
ただ、「audio/L16;rate=44100」と「audio/L16;rate=48000」の3パターンあるので、
dsfが再生出来ない場合は、LinearPCMで再生される仕組みになっています。
余裕がありましたら、「Media Go」でPCMに変換されずdsf再生されるか切り分けにはなるかと思います。
「Media Go」でdsf再生出来てしまった場合は、RockDiskNext側にまだ何かある可能性がでてきます。


>これについては、HomeMedia経由でFLACもDSDも再生できていますので、おそらく別の意味だと思われます。
 やっぱりWMPだけでしたか、本機でないと確認できない事柄だったので
 念の為、お知らせしておきました。


一応、毎度ながら強引な回避策は提示出来る用意はあるのですが
残念ながら今 私の所で試せる環境がないのと、購入されたばかりかと思いますので
保証期間が切れて、まだ対応されてなかったらお知らせもらえれば、提案します。
あと、Linuxの操作が必要になりますので…

投稿者:たく  投稿日時:2015/05/02 04:35 親投稿 - 子投稿.1 No.13

pianoriさん

DLNA関係の調査方法です。参考までに

Windows用の確認用のツールです。
Developer Tools for UPnP (MSI Installerの方をDL)
http://opentools.homeip.net/dev-tools-for-upnp

・GetProtocolInfo:サーバー、クライアンとの対応フォーマット一覧の取得方法
1.「Device Spy」 を起動
2.「CD-240」を選択 + 展開
3.「urn:schemas-upnp-org:device:MediaRenderer:1」を展開
4.「GetProtocolInfo(~略~)」を右クリック + 「Invoke Action」を選択
5.「Invoke」ボタンをクリック
6.情報が表示されたら、メモ帳などにコピペしてください。(カンマ区切りの1行です。)
(見ずらい時は後述のサクラエディタで改行に置換えしてください。)
7.同様の方法でサーバー側のRockDiskNextの情報も取得できます。

・subtype:mp3 の場合の例
 クライアント(Windows Media Player12)
  http-get:*:audio/mpeg:DLNA.ORG_PN=MP3
 サーバー(RockDiskNext)
  http-get:*:audio/mpeg:DLNA.ORG_PN=MP3
上の様に、サーバー、クライアント共に「MIME」と「DLNA.ORG_PN」がほぼ一致していれば、対応出来るはず。

RockDiskNextのdsdとdsfは
 http-get:*:audio/dsd:DLNA.ORG_PN=DSD,
 http-get:*:audio/dsf:DLNA.ORG_PN=DSF,
となっていますので CD-240側と比較すると、違う所が判ると思います。RDNにdffの設定は無いみたいですね。

・コンテンツのProtocolInfo確認方法
サーバー(RockDiskNext)のみ
1.「AV Media Controller」 を起動
2.「RockDiskNext」を選択 + 展開 + 「ミュージック」フォルダから適当なdsfファイルを探す
3.該当ファイルを右クリック + 「Display Properties」を選択
4.「Resource #1」を選択
5.「ProtocolInfo」を確認、右クリック + 「Copy」でクリップボードにコピーされます。
6.メモ帳などにペーストしてください。

サンプルDSFファイルの情報だと下記になります。
http-get:*:audio/x-dsd:DLNA.ORG_OP=01;DLNA.ORG_CI=0;DLNA.ORG_FLAGS=01700000000000000000000000000000

よく見たら、「DLNA.ORG_PN=DSF」も「DLNA.ORG_PN=DSD」も無いですね…
Media Goも同じですね。
http-get:*:audio/x-dsd:DLNA.ORG_OP=01;DLNA.ORG_CI=0;DLNA.ORG_FLAGS=01700000000000000000000000000000

Twonky Server系とは実装が違うのかな?


補足:サクラエディタ
http://sourceforge.net/projects/sakura-editor/?source=navbar
http://sakura-editor.sourceforge.net/download.html

GetProtocolInfoで取得したデータはそのままだとみずらいので、カンマの後に改行を追加します。
※サクラエディタでの方法になります。
1.GetProtocolInfoで取得したデータをコピペ後 メモ帳を保存して閉じます。
2.サクラエディタで開きます。
3.「設定」→「入力改行コード指定」が「入力改行コード指定(CRLF)」になっているのを確認。
4.「検索」→「置換」
5.「正規表現」をチェックし、置換対象が「選択文字」、範囲が「ファイル全体」選択されているのを確認。
6.「置換前」に「,」を入力(鍵かっこは省いてください)
7.「置換後」に「,\r\n」を入力(鍵かっこは省いてください)
8.「すべて置換」ボタンをクリックしてください。

これで、大分見やすくなると思います。

ついでに… flacのところ、dsdとくっついてた
http-get:*:audio/x-flac:*http-get:*:audio/dsd:DLNA.ORG_PN=DSD,

カンマ抜けてるのを見つけてしまった…
何て事だ。。。

投稿者:Takeshich  投稿日時:2015/05/02 10:16 親投稿 - 子投稿なし No.14

たくさん

>RockDiskNextのdsdとdsfは
> http-get:*:audio/dsd:DLNA.ORG_PN=DSD,
> http-get:*:audio/dsf:DLNA.ORG_PN=DSF,
>となっていますので CD-240側と比較すると、違う所が判ると思います。RDNにdffの設定は無いみたいですね。

ソースを見るとdffのMIMEはaudio/dsdとしているんです。
独自の場合はx-をつけるべきというところで、ちょっと微妙なんですよね。(dsfをaudio/x-dsdとしているのですが)
だけど、dff,dsfって違うし、dsdでもあって、再生側もどう判断するか統一されてないようで、私も独自実装した時にどうすればいいのか迷ったところです。
私は、あんまり良くないと思うけど、dff,dsfともにaudio/x-dsdとしちゃって、再生側に判断を任せるようにしました。

>ついでに… flacのところ、dsdとくっついてた
>http-get:*:audio/x-flac:*http->get:*:audio/dsd:DLNA.ORG_PN=DSD,
>
>カンマ抜けてるのを見つけてしまった…
>何て事だ。。。

ああっ。
https://gist.github.com/takeshich/c9be ... ile-upnpglobalvars-h-L174

これに限ったことじゃないけど、
再生機器側でサーバのGetProtocolInfoで得られるものと、配信時に送られてくるProtocolInfoのMIMEを比較してチェックとかしてたら、再生できない場合もあるかもなぁと思っているのだけど、所有している再生機器はチェックしていないようで、再生できてしまうから確認できない。。。

もし、ここ付近の修正で再生できる機器が増えるのなら、他のバグも含めて修正してくれるかな。。。

投稿者:たく  投稿日時:2015/05/02 11:51 親投稿 - 子投稿.1 No.15

Takeshichさん

>ソースを見るとdffのMIMEはaudio/dsdとしているんです。
あらら… なるほど /dsdだったのか~

https://gist.github.com/takeshich/04d9 ... 3de5#file-metadata-c-L395
と utils.c L-334
で dsfのMIMEと思われる所が前者(upnpglobalvars.h)が「audio/dsf」で後者が「audio/x-dsd」…
これで、いいのかな? 仕様がさっぱりわからん。
DTCP-IPとか除いたものでいいから、ガイドライン公開してほしいな。。。

以前、REGZAのクライアントで*.m2tsの動画の件でAVCの判定がおかしな所があり
DLNA.ORG_PN(files.dbのDLNA_PN)も見ていた様で、リスト表示時と再生時でチェックしてくれるPS3の様なクライアントはごまかせるんですが、REGZAはNGだったようです。

多分、今回は mime か DLNA.ORG_PN によって再生出来るかもしれないと思っています。
前回同様、強引な回避策しか手が無いのですが…
Twonkyにあわせると、他(Twonky以外)が使えなくなると困るなぁと思い
何か良い手はないものかな…

Twonkyは有料なので試してないのですが、この辺はXMLで後から変更できるみたいですね。
独自仕様の所だけでも、Twonkyの様にしてくれてれば楽なのにと思う。

IO DATAがココら辺の不具合をちょっとずつでもいいから、修正してくれることを願うばかりです。

投稿者:Takeshich  投稿日時:2015/05/02 14:13 親投稿 - 子投稿なし No.16

たくさん

わかりやすいところにソースおいておきます。
https://github.com/takeshich/minidlna-IODATA-1.1.0

>https://gist.github.com/takeshich/04d9 ... 3de5#file-metadata-c-L395
>と utils.c L-334
>で dsfのMIMEと思われる所が前者(upnpglobalvars.h)が「audio/dsf」で後者が「audio/x-dsd」…
>これで、いいのかな? 仕様がさっぱりわからん。

私は、サーバとして返すのがupnpglobalvars.hにあるaudio/dsfで、dbに保存されているmimeが配信時に送られる方で、audio/x-dsdという理解でいます。

>DTCP-IPとか除いたものでいいから、ガイドライン公開してほしいな。。。

http://jp.dlna.org/dlna-for-industry/about-dlna/guidelines

500ドル。。。
実装するときに確認したかったけど、手が出ません。

>多分、今回は mime か DLNA.ORG_PN によって再生出来るかもしれないと思っています。

プレイヤーのチェックが厳密でなければ、行けそうですよね。

>前回同様、強引な回避策しか手が無いのですが…
>Twonkyにあわせると、他(Twonky以外)が使えなくなると困るなぁと思い
>何か良い手はないものかな…

SonyのSTR-DN2030を持っているのですが、audio/dsdとaudio/x-dsdだけでした。(表示の区別にはMIMEを使用するようですが、再生は、配信されたデータをみてのようです)
今回のプレーヤーはaudio/dsdやaudio/x-dsdではなく、audio/dsfとかaudio/x-dsfなんじゃないかと勝手に思っています。

メーカーが集まって共通の規則で歩調を合わせてもらうしかないのですよね。ユーザーとしては。
そしてその規則を公開して欲しいのだけど。。。


投稿者:たく  投稿日時:2015/05/03 11:14 親投稿 - 子投稿なし No.17

Takeshichさん

>わかりやすいところにソースおいておきます。
ありがとうございます。助かります
C言語はどうも苦手で、ググりながらなんで なかなか全体が把握出来なくて…
(別件でminissdpの挙動追っかけてはいるのですが、進まない…)

>私は、サーバとして返すのがupnpglobalvars.hにあるaudio/dsfで、dbに保存されているmimeが配信時に送られる方で、audio/x-dsdという理解でいます。

表示されてるみたいなので、お互いaudio/dsfでやりとりは出来てると思うんですが
配信時のaudio/x-dsdが、クライアント側では登録なくてコーデックに渡せてないのかな~
しかし、何故わざわざ変えてるんだろう?理由あるからだとは思うけど…


>500ドル。。。
高いんですよね…。たしか登録制で個人は相手してくれたかな…
500ドル出すんだったら、他の機材 買ったほうがましかな。

>今回のプレーヤーはaudio/dsdやaudio/x-dsdではなく、audio/dsfとかaudio/x-dsfなんじゃないかと勝手に思っています。

相手側の受取可能MIMEが判る方法があれば良いのですが、最終的には手当り次第やってみるしかなさそうですね。配信時のMIMEは
dsf=audio/x-dsf
dff=audio/x-dff
がTwonky系は一般的みたいですね。
拡張子見てdbのMIME書換えればいけそうだけど、機材無いしな~

投稿者:え?  投稿日時:2015/05/03 18:51 親投稿 - 子投稿なし No.18

そもそも、DLNAとしての認証はされていない機器で、U-PnP AV1.5相当の互換部分で動くものは動くんじゃないの?っていうサーバ
http://www.iodata.jp/support/qanda/answer/s18648.htm
なので、DLNAの機器としてきちんと動くことを期待するのは酷なのかもしれないとは思います。元々箱買いしたシステムに入ってただけの機能ですし、
http://www.phileweb.com/interview/article/201312/25/206_5.html
正式に定義が無いならしょうがないんですが、場合によっては通るって変更をしてるような感じでもあります。要望で実現したなら、このときの入れ知恵で実装してるのでしょうし。

結局製品が無ければ意味も無いので、今後面倒を見てもらえる可能性の高さを考えれば、組み合わせとして世に出てプロダクトの系譜が生きてるTwonkyの挙動にあわせておくのが幸せになれそう(少なくとも、ONKYOの今後の製品が素直に動いてくれる可能性は増しそう)ですが、変更したときに「確認済み」の機器でどうなるのか?という問題があるので、「出来ればいじりたくない」だろうなぁとは思います。もう未来が無い商品ですし。

規定された挙動がないと、「修正するべき」という根拠は薄くなるので、利益は生まないけど、機能として約束した範囲で瑕疵があり、対応すべきと認識してもらう説得力がある何かってあるんでしょうかね?対応をうたってる機器で動かないのなら強く出ても良いと思うのですが、確認済みの機器があって、あとは知らないって表記になってるので、難しいところです。修正が、現状確認はしましたよとしている機器で、動作不良を起こさなければいいのですが、その可能性があれば、逆に公式に確認済みとしてしまった手前問題になりそうですし、物によっては、相手方に話をつけてるものもありそうですし。

ユーザー側で手を入れる場合にはその限りはなさそうですが、今度は、手を入れると保証の問題が出てきてしまうので、どうしたものでしょうね。

投稿者:たく  投稿日時:2015/05/03 21:12 親投稿 - 子投稿なし No.19

minidlnaのDSDのMIMEとか登録状況を確認する為にシェルスクリプト書いたので
使う事無いと思うけど、参考までに。
一応、自己責任でお願いします。

このスクリプトはファイル拡張子 *.dsf,*.dff のMIME, DLNA_PN, PATHを一覧表示し、ファイルに書出します。
スクリプトの保存先、ファイル書出し先は下記で設定しています。
/home/Public/minidlna_sh

スクリプトのファイル名:minidlna_db_dsd_list.sh
minidlna files.dbの場所:/home/.nas/files.db
ログのファイル名:DSDlist.txt

・実行方法
1.telnetでログイン(読取だけなので「admin」ユーザーでも出来ます。)
2.下記コマンドでスクリプト実行
. /home/Public/minidlna_sh/minidlna_db_dsd_list.sh

minidlna_db_dsd_list.sh の中身は以下から 「echo "End"」までです。注意点:改行コードはLF[\n]で ( CRLF[\r\n]はエラーになります )
#!/bin/sh

db="/home/.nas/files.db"
log="/home/Public/minidlna_sh/DSDlist.txt"

if [ ! -f "$db" ] ;then
echo "Error: file not found $db" ;return
fi

echo "start sqlite3"
#return

SQL="SELECT MIME,DLNA_PN,PATH FROM DETAILS WHERE (PATH LIKE '%.dsf' AND MIME LIKE 'audio%') OR (PATH LIKE '%.dff' AND MIME LIKE 'audio%');"

COMMAND="sqlite3 -header -column "$db""
echo $SQL | $COMMAND | tee $log

echo "End"

投稿者:Takeshich  投稿日時:2015/05/06 22:26 親投稿 - 子投稿なし No.20

こんなのを見つけました。

>β版ではmimeにてファイルタイプの判別頂く内容となっておりますが、dffかdsfかはクライアント側が自己判別する必要がありました。現在の開発バージョンでは拡張子を記述しています。公開バージョンに反映予定です。

http://bbs.ioplaza.jp/forum/index.php?topic_id=2135#post_id8525

と公式さんが書いているんだけど、微妙な書き方だなぁ。
twonkyってRaspberryPiでも使えそうだから、試用してみようかな。

投稿者:たく  投稿日時:2015/05/07 21:19 親投稿 - 子投稿.1 No.21

Takeshichさん

たしかに微妙…

前はこの辺を見てたんですが
https://github.com/takeshich/minidlna- ... ob/master/upnpsoap.c#L906

クライアントとのmimeタイプやDLNA.ORG_PNなどの違いをこの辺で吸収して互換性を持たせようとしてるのかな?
Regzaの時は、minidlnaのdb登録時のスキャンの仕様が変わってdlna_pnが変わってしまい
Regzaに送られる時、対応していないフォーマットとして伝えられてしまったので再生出来なくなってしまったみたいでした。

この辺の機能をうまく調整すれば、クライアント毎の互換性を保てるんではないかな?

投稿者:Takeshich  投稿日時:2015/05/07 22:47 親投稿 - 子投稿なし No.22

たくさん

>クライアントとのmimeタイプやDLNA.ORG_PNなどの違いをこの辺で吸収して互換性を持たせようとしてるのかな?

おそらくこの関数内でクライアントに合わせて送っていると思います。あとは、client.c client.hとかで検出させたいのを入れるんだと思います。

https://github.com/takeshich/minidlna- ... lob/master/clients.c#L131

IO-DATA版の独自追加ですね。TA-DA5800ESとかSTR-DN1040とか。

>この辺の機能をうまく調整すれば、クライアント毎の互換性を保てるんではないかな?

おそらく可能とは思います。

投稿者:Takeshich  投稿日時:2015/05/10 14:17 親投稿 - 子投稿なし No.23

RaspberryPiでTwonky Serverの情報を確かめてみました。

http://www.twonkyforum.com/downloads/
から

http://www.twonkyforum.com/downloads/ ... l-glibc-2.13-hf-8.0.3.zip

をいれて、試用してみました。
GetProtocolInfoで

http-get:*:audio/L16;rate=44100;channels=2:DLNA.ORG_PN=LPCM,
http-get:*:audio/mpeg:DLNA.ORG_PN=MP3,
http-get:*:image/jpeg:DLNA.ORG_PN=JPEG_MED,
http-get:*:image/jpeg:DLNA.ORG_PN=JPEG_LRG,
http-get:*:image/jpeg:DLNA.ORG_PN=JPEG_TN,
http-get:*:image/jpeg:DLNA.ORG_PN=JPEG_SM,
http-get:*:audio/x-wav:*,
http-get:*:audio/x-flac:*,
http-get:*:image/jpeg:*,
http-get:*:audio/dsd:*,
http-get:*:application/octet-stream:*

でした。

で、コンテンツのProtocolInfoは、dsfおよびdffで
http-get:*:audio/dsd:*

でした。
URIは
http://192.168.11.8:9000/disk/NON-DLN ... 1700000/O0$1$8I316940.dsf
な感じでした。

この(twonky serverの8.0.3のデフォルト)状態で今回のプレイヤーで再生できるのであれば、
個人的にはRockDiskNextのDSD対応のminidlna実装が原因の可能性が高いような気がします。
確認できる機器がないのとDLNAのガイドラインを参照できないので、明確には言えないのですが。。。

このスレッドに投稿する

投稿者名
投稿本文

※入力支援機能(引用・画像挿入)をご利用の場合は返信ボタンを押してください。
※メールアドレス等、個人情報にかかわる情報の掲載・取扱については十分に注意してください。

 
CAPTCHA Image 画像を替える読みづらい場合は画像を替えてお試しくださいスパム防止のため画像認証を設置しています
画像内の文字をボックスに入力してください