- このトピックには23件の返信、2人の参加者があり、最後ににより6年前に更新されました。
-
投稿
-
こんばんは、はじめまして。
BubbleUPnP(Android端末)をコントロールポイントとサーバー（Local&Cloud）
にしてTuneBrowserのOpenHomeのplayerを使い始めました。
Android端末のlocalコンテンツは問題なく再生できているのですが、
Cloud(Google Play Muisc)のコンテンツはplaylistやジャケットなどの
メタ情報は転送出来ているのですが、ストリーミング再生ができません。
（TuneBrowser画面上で、再生ボタンが押されているのは見えています）
同じPC上で、foobar2000のDLNAレンダラーは問題なくCloudのストリーミング
再生が出来ていますので、TuneBrowserの問題かと思っています。
TuneBrowserはBubbleUPnPをプロキシーとしたCloudのストリーミング再生を
サポートしていないということなのでしょうか？
こんばんわ。
TuneBrowserはBubbleUPnPをプロキシーとしたCloudのストリーミング再生を
サポートしていないということなのでしょうか？
サポートしている=動作保証している、という意味でしたら、サポートはしていません。でも、動作しない理由もすぐには思いつきませんね…。TuneBrowserは転送プロトコルとしてhttp/httpsのみ実装しているのですが、その故でしょうか?
細かいですが、TuneBrowserは、外部のメディアサーバとしては、DLNAは対象としていません。UPnPのメディアサーバのみ対象としています (DLNAはわたしのような個人には仕様が開示されないので、残念ながら実装しようがありません)。
これがなにかヒントになりますでしょうか?
こんにちわ。
Kazooから問題なくアクセスできるのでBubbuleUPnPは
OpenHome対応なのでは？
このご質問の意味が掴みかねているのですが、KazooはOpenHomeにもUPnPにも対応していると思いますので、かならずしもOpenHome対応とはかぎらないと思います。またもしこのご質問の答えがYesだとして、おっしゃりたいのは、「だからTuneBrowserのOpenHome Player機能に送出できるはず」ということでしょうか?
OpenHomeは主としてプレイリストの設定までの役割を担っていて、あとはOpenHome Player側がMedia Serverから自前でデータを取得して再生します。メタデータがTuneBrowserに渡っていて、再生開始まで至れているということは、それはOpenHomeがうまく動作しているということですが、その役割を果たしているのはBubbuleUPnPではなく、Kazooです。
その後TuneBrowserは指定されたURLを介してMediaServer (BubbuleUPnP) からデータの取得を開始しますが、ここはもうOpenHomeでもUPnPでもなく、単なるHTTP通信の世界です。TuneBrowserの開発時、外部のMedia ServerとしてNASなど手に入る機器で確認はしていますが、現在のところTuneBrowserは問題なく動作していて、NAS内のサーバ機能から音楽を取得して再生することができています。
ここで、BubbuleUPnPとそのバックエンドにいるGoogle Play Musicがお互いにどのような役割で動作しているのか、ということがわからないと、残念ながら机上ではなにがどうなっているのかというのはわかりそうにありません。そのあたりの情報はお持ちでしょうか?
念のため、ですが、ヘルプに記載の通り、TuneBrowserは以下のように動作します。
- 再生機能は OpenHome に対応しています. UPnP のレンダラーには対応していません.
- メディアサーバ機能は UPnP (ContentDirectory サービス) に対応しています.
MP3の再生ができないということで、こうしたプロトコル上の問題ではなく、単なるフォーマット上の問題という可能性もあります。これがファイルであれば、わたしに送ってください、とお願いするところなのですが、残念ながらそれはできませんね。
考えられるのは、ストリーミングのデータ
なので、一度のREADでは全部読み込めなくて失敗しているとか、Copyrightビット
が立っていて読めない、フレームの同期データが邪魔をしているとかでしょうか？
RAMDecodeを有効にしていると、たしかに全部読み込もうとしますが、TuneBrowserのRAMDecodeはHTTP経由のアクセスにも対応しています。ストリーミングぽいのデータとは言え、HTTPベースであれば動作すると思います。Copyrightビットは見ていません。非同期化されたフレームにも対応しています (長らく非同期化されたデータには遭遇していないので、ひょっとしたらうまく動作しなくなっているかもしれませんが…)。
まとめると、前回書いたように、BubbuleUPnP+Google Play Musicの構成のときに、実際の曲データの授受に利用されるプロトコルは何か、という点がポイントのように思います。なにかその点で情報があればよいのですが…。
こんばんわ。
基本的なスタンスはわかりました。ただ現状ではわたしのほうは雲をつかむような状態です。
ご利用の環境をわたしのところで再現させるのは難しいので、すこし期間をかけて、細かい点を確認しながら議論を進めてもよろしいでしょうか?
一連の操作を行ったときの、TuneBrowserのログは確認されていますでしょうか。TuneBrowserのログは、もし表示されていなければ上部のメニューの「表示」「ドッキングウィンドウ」「Log View」で表示されます。Log Viewの下部にはいくつかタブがあり、そのうちの「UPnP」タブを選択いただくと、その関連するログが表示されます。
このログは、マウスの右クリックで「すべて選択」「コピー」ができます。コピーした内容をお送りいただきたいのですが、ネットワークに関するログのため、内容にはIPアドレス等が含まれます。そのIPアドレスは、ローカルIPか、あるいはサービス提供側のIPアドレスで、個人情報に類するものは含まれないと思いますが、念のためということもありますので、このフォーラムではなく、専用のアップロードフォームをメールでご連絡します。そちらにアップロードをお願いします。
ログをとっていただく際には、できれば新しい曲の追加～再生の一連の作業を行ってください。
また、プロトコルの問題か、MP3フォーマットの問題かを切り分けるために、可能であれば以下の情報をいただければ有難いです。
- MP3以外のフォーマットで試すとどうなりますでしょうか。
- Google Play Musicは、ローカルにあるファイルをアップロードして管理することができると聞きました。TuneBrowserで再生できている、お手持ちのMP3ファイルをGoogle Play Musicにアップロードして、今回の操作を行った場合はどうなりますでしょうか。
わたしの理解がまちがっている、あるいは対応がむずかしいようでしたら、その旨ご連絡ください。
どうぞよろしくお願いします。
こんばんわ。さっそくのご対応ありがとうございました。
どうもプロトコルは通じていて、MP3形式の問題のような感じですね。いただいたログも双方確認してみましたが、有意な差は現在のところ認められませんでした。
MP3形式の確認ですが、ファイルを前提にしているため、残念ながら現在のTuneBrowserのログだけでは確認ができません。ひょっとしたら、再生開始時にLog ViewのPlayerタブ内になにか情報が表示されるかもしれませんが、ご指摘の通り長さ0でとくになにも出ない可能性もあります。
何度もすいませんが、もしよろしければ再生操作後のLog ViewのPlayerタブの内容をお送りいただけますか。わたしのほうでは、次のリリース時にログを強化するポイントを検討します。
よろしくお願いします。
こんばんわ。ログ送付ありがとうございました。
原因が大体分かりました。
TuneBrowserはID3タグがなくてもMP3を再生することができます。理解が悪くて恐縮ながら、もうひとつ原因が掴めていないのですが、ご利用の環境では解決したと理解してよろしいのでしょうか?
こんばんわ。続報ありがとうございます。
前にも書きましたが、TuneBrowserはMP3の再生にID3v2タグは必要としていません。ID3v2タグがないのが再生できない原因だと思いこまれているようでしたので、どのようにご説明したものか悩んでいました。
ついでながら、再生に必要な演奏時間などの情報も、メタデータから取得することはなく、MP3のフレームから取得します (またビットレートは再生にはまったく必要ありません)。
そのため結局は、問題はMP3のフレームが読めていないということに尽きます。それで、今回あらたにいただいた情報で問題要因らしいところは、「最初のフレームが届くまでに最大で１分程度待ち時間があります」という点です。TuneBrowserの通信のタイムアウトは5秒です。
これまでいただいた情報を総合すると、次回リリース時に、このタイムアウト時間を設定で変更できるようにするというのが対策らしい対策になりそうです。
こんばんわ。
メタ情報として送られて来ているのに、正確な演奏時間を調べるためだけに
フルダウンロードするのは無理があるのでは？MP3でXingヘッダがない場合、CBRであれば良いのですが、たまにABRのものが存在しています。ABRの場合、フレームの位置が特定できないため、はじめに全フレームを走査しています。その方法はネットワーク再生の場合は良くないということなのだと思いますが、どういう方法が取り得るのか、というのはすぐにはわかりません。
ところで、さまざまなケースを試していただいて大変心強いのですが、現在のところ、
再生対象曲:
1) ローカルからアップロードした曲
2) Google Play Musicが提供している曲再生方法:
A) TuneBrowser
B) SoundGenic OpenHome player(など)の組合せパターンがあると理解しているのですが、どの組合せのことをお話しになっているのか、少々混乱しています。たとえば
再生の方は、失敗を繰り返しながら何度かボタンを押していたら、
成功しました。
というのは、上記のどのパターンのことを言われているのでしょうか?
こんばんわ。
わたしは冷静な人間ではありませんよ。冷静な人間だったら、このソフトをここまでひとりで作り上げることはできなかったのではないかと思います。
ただ、このフォーラムという公共の場では、面識のない大人同士が表情も見えないなか、文字だけで挨拶以上の会話をしようというのですから、できるだけ冷静というか礼節をもって応対しなければならないとは肝に銘じています。ときどきは、我慢の限度を超えてしまうことはありますが。そうした結果、「冷静に応対できている」と言っていただけるのであれば、それは、よかったというか、有難いことだと思います。
それで、全フレーム走査については、わたしは総演奏時間ではなく、CBRとABRの話をしました。ABRの場合、シーク操作を行ったときの頭出しをするためには、シーク位置(時刻)に対応したフレーム位置(バイト)の情報が必要で、そのテーブルを作っています。それはVBRの場合でも同様なので、VBRとABRの処理を合わせればいいような気もしますが、現在はXingヘッダの有無で大きく処理がわかれており、そうなってはいません。
また、TuneBrowserの再生部はOpenHome専用ではなく、基本的にはファイルの再生を主眼に開発してきたもので、OpenHomeはHTTPプロトコルをファイルシステムに抽象化してアクセスする形で実現しています。そのため最初からOpenHome対応を主目的として開発されたプレーヤーでは簡単に思えることも、実際のソースコードの構成上簡単ではないこともあります。というか、先ほどのシークの件もそうですが、ファイルシステム上の音源を快適かつ正確に再生できるようにこれまで腐心してきました。それは容易には捨てられません。
ご意見をいただけることは大変ありがたく思っています。ご意見踏まえて今後どうするかは、最初のほうの返信で申し上げたように、すこし時間をかけて検討していきたいと思います。
Google Play Musicに関する課題の情報は、現在のところyamaさんからのこのトピックのみで、ほかの方からのご意見はないようです。ですので、yamaさんに行っていただいている検証作業のみが唯一の設計材料となっています。ゴールにたどりつけるかどうかもわからない状況で、この検討を進めていくのであれば、わたしとしては頼りにさせていただくほかありません。よろしくお願いします。
こんにちわ。
CBRとABRのトラックに関してはシークは問題ないのでは？
（同期ビットもありますからCBRは問題ないです。ABRは同期ビットというか、フレームを走査する必要があると思っていますので、前掲の動作になります。
VBRはABRと思っていい加減に対応するか、
VBRもABRもフレームとバイト位置の地図を作って対応しています。
OpenHome対応を歌っているのですから、仕様を満たしていないのは
問題だと思いますよ。仕様と言われているのはどの文書のことでしょうか? いちおうOpenHomeとUPnPの仕様には目を通したつもりですが、集めそこなっているものがあるのかもしれません。具体的に所在を教えていただけると助かります。
前に挙げられていたunofficial-google-music-api.pdfは、その名の通り仕様ではありませんね。
こんにちわ。
先ほど公開した4.7.0(先行版)でMP3 ABRの読み込み方法を変更しています。そのためには設定変更が必要で、標準設定のままだとこれまでと同様の動作をします。
設定変更は、設定画面のツリー:「再生の設定」「デコードの設定」、右側の項目「MP3の処理」「ABRの確認フレーム数」を既定の0 (=全フレーム確認) から100など適当な値に設定してください。
それから、
OpenHome対応を歌っているのですから、仕様を満たしていないのは
問題だと思いますよ。の件、どの仕様のことを言われているのか大変気にしておりますので、引き続きご連絡をお待ちしています。
どうぞよろしくお願いします。
こんにちわ。
先ほど公開した4.8.0の先行版で、MP3の処理をさらに見直しました。
設定画面で、ツリー項目「再生の設定」「デコードの設定」、右側の項目「MP3の処理」(下のほうです) のいちばん上に、「MP3ファイルの解析モード」という項目があります。これを “Easy” に設定してください。再生前のフレームの確認やID3v1タグの確認などを行わないようになり、メディアに対してシーク操作を行うことがほぼなくなります。
これでご期待の動作にほぼ近づいたのではないかと思います。ただしフレーム内に、メタデータで事前定義された仕様 (とくにサンプルレートとチャンネル数) と異なったフレームが含まれていた場合、Normalのときに行っていた推測などは行わず、すべてエラーとして弾くという動作になります。
また、TuneBrowserの動作がOpenHomeの仕様とちがうと言われていた件、引き続き情報お待ちしております。どうぞよろしくお願いします。
- このトピックに返信するにはログインが必要です。