Google Play Musicは使えない?

フォーラム TuneBrowser Google Play Musicは使えない?

このトピックには22件の返信が含まれ、2人の参加者がいます。1 ヶ月、 1 週前 Tiki さんが最後の更新を行いました。

23件の投稿を表示中 - 1 - 23件目 (全23件中)
  • 投稿者
    投稿
  • #4393

    yama
    参加者

    こんばんは、はじめまして。

     

    BubbleUPnP(Android端末)をコントロールポイントとサーバー(Local&Cloud)

    にしてTuneBrowserのOpenHomeのplayerを使い始めました。

    Android端末のlocalコンテンツは問題なく再生できているのですが、

    Cloud(Google Play Muisc)のコンテンツはplaylistやジャケットなどの

    メタ情報は転送出来ているのですが、ストリーミング再生ができません。

    (TuneBrowser画面上で、再生ボタンが押されているのは見えています)

     

    同じPC上で、foobar2000のDLNAレンダラーは問題なくCloudのストリーミング

    再生が出来ていますので、TuneBrowserの問題かと思っています。

     

    TuneBrowserはBubbleUPnPをプロキシーとしたCloudのストリーミング再生を

    サポートしていないということなのでしょうか?

     

    #4396

    Tiki
    キーマスター

    こんばんわ。

    TuneBrowserはBubbleUPnPをプロキシーとしたCloudのストリーミング再生を

    サポートしていないということなのでしょうか?

    サポートしている=動作保証している、という意味でしたら、サポートはしていません。でも、動作しない理由もすぐには思いつきませんね…。TuneBrowserは転送プロトコルとしてhttp/httpsのみ実装しているのですが、その故でしょうか?

    #4398

    Tiki
    キーマスター

    細かいですが、TuneBrowserは、外部のメディアサーバとしては、DLNAは対象としていません。UPnPのメディアサーバのみ対象としています (DLNAはわたしのような個人には仕様が開示されないので、残念ながら実装しようがありません)。

    これがなにかヒントになりますでしょうか?

    #4402

    yama
    参加者

    コントローラーとしてはKazooの方が調子が良いので、

    Kazoo (controller), BubbleUPnP(Media Server), TuneBrowser(player)の

    構成で試しています。(Kazooから問題なくアクセスできるのでBubbuleUPnPは

    OpenHome対応なのでは?)

     

    プレイリストに、MP3; 44.1kHz; 0ch; 0:00  と出ているのでMP3ファイルの

    ヘッダーが読み込めてないようです。考えられるのは、ストリーミングのデータ

    なので、一度のREADでは全部読み込めなくて失敗しているとか、Copyrightビット

    が立っていて読めない、フレームの同期データが邪魔をしているとかでしょうか?

    #4403

    Tiki
    キーマスター

    こんにちわ。

    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の構成のときに、実際の曲データの授受に利用されるプロトコルは何か、という点がポイントのように思います。なにかその点で情報があればよいのですが…。

    #4404

    yama
    参加者

    こんばんは。私の基本的なスタンスは、BubbleUPnPは

    HTTPのプロキシーサーバー(メタ情報は予めキャッシュしておいたものを使用し、

    実際にバックエンドのGoogleと通信しているのはMP3ファイルの取得のみ)として

    動作しているのでTuneBrowserでも動くのではないか、動くとMP3 320kbpsの

    多様な曲をアップサンプリングして聞けてうれしいということです。

    (最近MP3フォーマットでも、ハイレゾマスターに近い音質で伝達

    できる潜在能力があると再評価しているのです)

     

    それから、RAMDecodeは使っていません。

    他に何か手掛かりがないかと、SoundGenicのNAS上にOpenHome

    playerを構築してみたところ、こちらは問題なくGoogle Play Music

    が再生しました。こちらもfoobar2000もストリーミング曲は

    アップサンプリングしてくれないので寂しいですね。

    #4405

    Tiki
    キーマスター

    こんばんわ。

    基本的なスタンスはわかりました。ただ現状ではわたしのほうは雲をつかむような状態です。

    ご利用の環境をわたしのところで再現させるのは難しいので、すこし期間をかけて、細かい点を確認しながら議論を進めてもよろしいでしょうか?

    一連の操作を行ったときの、TuneBrowserのログは確認されていますでしょうか。TuneBrowserのログは、もし表示されていなければ上部のメニューの「表示」「ドッキングウィンドウ」「Log View」で表示されます。Log Viewの下部にはいくつかタブがあり、そのうちの「UPnP」タブを選択いただくと、その関連するログが表示されます。

    このログは、マウスの右クリックで「すべて選択」「コピー」ができます。コピーした内容をお送りいただきたいのですが、ネットワークに関するログのため、内容にはIPアドレス等が含まれます。そのIPアドレスは、ローカルIPか、あるいはサービス提供側のIPアドレスで、個人情報に類するものは含まれないと思いますが、念のためということもありますので、このフォーラムではなく、専用のアップロードフォームをメールでご連絡します。そちらにアップロードをお願いします。

    ログをとっていただく際には、できれば新しい曲の追加~再生の一連の作業を行ってください。

    また、プロトコルの問題か、MP3フォーマットの問題かを切り分けるために、可能であれば以下の情報をいただければ有難いです。

    1. MP3以外のフォーマットで試すとどうなりますでしょうか。
    2. Google Play Musicは、ローカルにあるファイルをアップロードして管理することができると聞きました。TuneBrowserで再生できている、お手持ちのMP3ファイルをGoogle Play Musicにアップロードして、今回の操作を行った場合はどうなりますでしょうか。

    わたしの理解がまちがっている、あるいは対応がむずかしいようでしたら、その旨ご連絡ください。

    どうぞよろしくお願いします。

    #4410

    yama
    参加者

    試しにMP3(160kbps)のフリー素材をアップロードしたら、

    こちらはTuneBrowserで問題なくアップサンプリングで再生できました。

    色々試して後でログも送りますので少々お待ちください。

     

    それから、Play MusicはFLAC,AACなど全てのデータをMP3

    に変換してしまうのでMP3以外は存在しません。

    #4411

    yama
    参加者

    色々のファイルで試してみました。

    1. 購入したAACファイル、リッピングしたflacファイル、ネットのMP3

    フリー素材その他をアップロード(自動でMP3化) -> 問題なく再生可能

    2. Play Musicの購読ファイル -> 再生不能(タイトルや画像は表示可能)

     

    MP3ファイル自体のダウンロードではなく、メタデータからビットレートや

    演奏時間を取得するところで失敗して演奏時間が0秒となっているので、

    再生ボタンを押しても直ぐに停止しているようです。

     

    ログは成功例と失敗例の2個をアップロードして置きました。

    #4413

    Tiki
    キーマスター

    こんばんわ。さっそくのご対応ありがとうございました。

    どうもプロトコルは通じていて、MP3形式の問題のような感じですね。いただいたログも双方確認してみましたが、有意な差は現在のところ認められませんでした。

    MP3形式の確認ですが、ファイルを前提にしているため、残念ながら現在のTuneBrowserのログだけでは確認ができません。ひょっとしたら、再生開始時にLog ViewのPlayerタブ内になにか情報が表示されるかもしれませんが、ご指摘の通り長さ0でとくになにも出ない可能性もあります。

    何度もすいませんが、もしよろしければ再生操作後のLog ViewのPlayerタブの内容をお送りいただけますか。わたしのほうでは、次のリリース時にログを強化するポイントを検討します。

    よろしくお願いします。

    #4423

    yama
    参加者

    こんばんは、原因が大体分かりました。

     

    playerログは既にアップロードしてあります。

    https://media.readthedocs.org/pdf/unofficial-google-music-api/stable/unofficial-google-music-api.pdf の8ページに講読用の

    MP3ファールはストリーミング目的なのでID3タグを付けていないとあります。

    ID3タグに相当するメタデータは別のAPIで提供しているともあります。

    また、http://shopdd.jp/blog-entry-1307.html のplay music exporterの画面を見ると、ストリーミング用データだけでは再生できないのでタグを付けているのが

    見えます。

     

    playerログの中でも、ID3タグを見に行って失敗しているのが見えます。

     

    playlist用に送られてくるメタデータの中に再生に必要な演奏時間やビットレート

    が入っているのでそちらを使えとBubbleUPnP(Media server)は言っている

    ようですね。

    #4424

    Tiki
    キーマスター

    こんばんわ。ログ送付ありがとうございました。

    原因が大体分かりました。

    TuneBrowserはID3タグがなくてもMP3を再生することができます。理解が悪くて恐縮ながら、もうひとつ原因が掴めていないのですが、ご利用の環境では解決したと理解してよろしいのでしょうか?

    #4426

    yama
    参加者

    解決していません。原因が分かったと書いたので誤解を

    招いたようですが、

    アップロードしたMP3ファイルと講読したMP3ファイルの

    違い(ID3タグの有無)が再生できない大本の原因となっている

    ということです。再生ボタンを押しても講読したMP3

    ファイルは再生しません。演奏開始直後に自動的に停止してしまいます。

     

    #4427

    yama
    参加者

    ID3タグの有無と書きましたが、ストリーミングデータなので

    フレーム単位で転送速度を絞ってゆっくり送られてくること

    (320kbps?)の方が大きいかもしれません。

    #4430

    yama
    参加者

    こんばんは。

    間違ったことを書いていたので訂正しておきます。

    1トラック50分のID3タグ無しABRエンコード(Xingヘッダ有り)

    の曲をアップロードしてログを見てみました。問題なく再生しています。

    playlistの表示(演奏時間とビットレート)もKazooから送られたものが

    正常に表示されています。

     

    今、分かっていることは、

     

    1. 講読している曲のMP3ファイルは、ID3タグもXingヘッダもないABRの

    フレームの列です。

    2. Play MusicはHTTPでデータを取得に行っても最初のフレームが届くまで

    に最大で1分程度待ち時間があります。(1分を超えたらリトライが必要)

    3.  ファイル転送速度は絞っているようですが、ビットレート以上の速度で

    取得可能。

    4. 講読した曲のplaylistへの追加をKazooからTuneBrowserにプッシュしたときに

    演奏時間やビットレートの情報を取りこぼしている。

     

    以上です。

    #4434

    Tiki
    キーマスター

    こんばんわ。続報ありがとうございます。

    前にも書きましたが、TuneBrowserはMP3の再生にID3v2タグは必要としていません。ID3v2タグがないのが再生できない原因だと思いこまれているようでしたので、どのようにご説明したものか悩んでいました。

    ついでながら、再生に必要な演奏時間などの情報も、メタデータから取得することはなく、MP3のフレームから取得します (またビットレートは再生にはまったく必要ありません)。

    そのため結局は、問題はMP3のフレームが読めていないということに尽きます。それで、今回あらたにいただいた情報で問題要因らしいところは、「最初のフレームが届くまでに最大で1分程度待ち時間があります」という点です。TuneBrowserの通信のタイムアウトは5秒です。

    これまでいただいた情報を総合すると、次回リリース時に、このタイムアウト時間を設定で変更できるようにするというのが対策らしい対策になりそうです。

    #4437

    yama
    参加者

    こんばんは。

    先入観で間違ったことを書いていた所もありましたが、

    色々実験して事実に近づいていると思っています。

     

    Xingヘッダを削除するツールがなかなか見つからなくて

    時間が掛かりましたが。Xingヘッダ有りとXingヘッダ

    なしの33MB (ABR, ビットレート:90kbps, 演奏時間50分)

    のデータをアップロードして試してみました。

     

    Kazooからこの曲の情報をTuneBrowserのplaylistに追加する

    ときに、Xingが有るものは10~20秒程度。Xingが無いものは

    数回失敗した後に5分程度掛かってやっと成功しました。

    Xingがないものは演奏時間を取得するためだけにファイル全体を

    ダウンロードするようですね。(ダウンロード速度にして880kbps程度

    ですから、Play Musicの公称320kbpsの3倍程度ですね)

     

    再生の方は、失敗を繰り返しながら何度かボタンを押していたら、

    成功しました。こちらは2回ダウンロードをしているのでしょうか、5分以上

    時間が掛かっています。(Xingが有るものは10数秒程度で再生を開始します。)

     

    メタ情報として送られて来ているのに、正確な演奏時間を調べるためだけに

    フルダウンロードするのは無理があるのでは?

    #4440

    Tiki
    キーマスター

    こんばんわ。

    メタ情報として送られて来ているのに、正確な演奏時間を調べるためだけに
    フルダウンロードするのは無理があるのでは?

    MP3でXingヘッダがない場合、CBRであれば良いのですが、たまにABRのものが存在しています。ABRの場合、フレームの位置が特定できないため、はじめに全フレームを走査しています。その方法はネットワーク再生の場合は良くないということなのだと思いますが、どういう方法が取り得るのか、というのはすぐにはわかりません。

    ところで、さまざまなケースを試していただいて大変心強いのですが、現在のところ、

    再生対象曲:
    1) ローカルからアップロードした曲
    2) Google Play Musicが提供している曲

    再生方法:
    A) TuneBrowser
    B) SoundGenic OpenHome player(など)

    の組合せパターンがあると理解しているのですが、どの組合せのことをお話しになっているのか、少々混乱しています。たとえば

    再生の方は、失敗を繰り返しながら何度かボタンを押していたら、

    成功しました。

    というのは、上記のどのパターンのことを言われているのでしょうか?

    #4441

    yama
    参加者

    今晩は。

    Tikiさんは冷静な方のようですから、厳しくはっきり書くと

    OpenHomeのプロトコル上唯一の正しい演奏時間はメタデータ

    で送られてくるものです。MP3ファイルをスキャンして計算した

    ものは演奏時間ではありません。例え、再生処理に支障が生じると

    しても。

     

    それから何とか再生に成功したのは、ローカルに

    ID3v1,v2タグやXingヘッダを削除した純粋なMP3の

    フレームの集まりです。このファイルをPlay Musicに

    アップロードしKazooを介してTuneBrowserで再生しました。

     

    SoundGenicのプレーヤは全く問題なくアップロードしたものも

    講読しているものも再生できます。

     

    TuneBrowserを気に入っていて応援もしているし、意見を

    聞かれているようにも思えるので書きます。Xingヘッダやフレーム

    のフルスキャン結果はファイルシステムをクローリングしてタグ情報を

    収集しているときについでにデータベースに入れておき、OpenHomeの

    メタ情報はそのまま受け入れれば問題はなくなるし、TuneBrowserの動作

    も軽快で快適になるのでは。

    #4443

    Tiki
    キーマスター

    こんばんわ。

    わたしは冷静な人間ではありませんよ。冷静な人間だったら、このソフトをひとりでここまで作り上げることはできなかったのではないかと想像します。

    ただ、このフォーラムという公共の場では、面識のない大人同士が表情も見えないなか、文字だけで挨拶以上の会話をしようというのですから、できるだけ冷静というか礼節をもって応対しなければならないとは肝に銘じています。ときどきは、我慢の限度を超えてしまうことはありますが。そうした結果、「冷静に応対できている」と言っていただけるのであれば、それは、よかったというか、有難いことだと思います。

     

    それで、全フレーム走査については、わたしは総演奏時間ではなく、CBRとABRの話をしました。ABRの場合、シーク操作を行ったときの頭出しをするためには、シーク位置(時刻)に対応したフレーム位置(バイト)の情報が必要で、そのテーブルを作っています。それはVBRの場合でも同様なので、VBRとABRの処理を合わせればいいような気もしますが、現在はXingヘッダの有無で大きく処理がわかれており、そうなってはいません。

    また、TuneBrowserの再生部はOpenHome専用ではなく、基本的にはファイルの再生を主眼に開発してきたもので、OpenHomeはHTTPプロトコルをファイルシステムに抽象化してアクセスする形で実現しています。そのため最初からOpenHome対応を主目的として開発されたプレーヤーでは簡単に思えることも、実際のソースコードの構成上簡単ではないこともあります。というか、先ほどのシークの件もそうですが、ファイルシステム上の音源を快適かつ正確に再生できるようにこれまで腐心してきました。それは容易には捨てられません。

    ご意見をいただけることは大変ありがたく思っています。ご意見踏まえて今後どうするかは、最初のほうの返信で申し上げたように、すこし時間をかけて検討していきたいと思います。

    Google Play Musicに関する課題の情報は、現在のところyamaさんからのこのトピックのみで、ほかの方からのご意見はないようです。ですので、yamaさんに行っていただいている検証作業のみが唯一の設計材料となっています。ゴールにたどりつけるかどうかもわからない状況で、この検討を進めていくのであれば、わたしとしては頼りにさせていただくほかありません。よろしくお願いします。

    #4454

    yama
    参加者

    こんばんは。

    Tikiさんは私が思っていたほど冷静な人ではないという

    ことですので、ほんわかモードに戻します。

     

    OpenHomeのコントロールポイントは、メタデータとして

    平均ビットレートと演奏時間を送ってきます。

    CBRとABRのトラックに関してはシークは問題ないのでは?

    (同期ビットもありますから。VBRはABRと思っていい加減に対応するか、

    再生時にXingヘッダを見るのでしょうか)

     

    OpenHome対応を歌っているのですから、仕様を満たしていないのは

    問題だと思いますよ。対応は時間が掛かるでしょうから、気長にお持ちします。

    #4455

    Tiki
    キーマスター

    こんにちわ。

    CBRとABRのトラックに関してはシークは問題ないのでは?
    (同期ビットもありますから

    CBRは問題ないです。ABRは同期ビットというか、フレームを走査する必要があると思っていますので、前掲の動作になります。

     

    VBRはABRと思っていい加減に対応するか、

    VBRもABRもフレームとバイト位置の地図を作って対応しています。

     

    OpenHome対応を歌っているのですから、仕様を満たしていないのは
    問題だと思いますよ。

    仕様と言われているのはどの文書のことでしょうか? いちおうOpenHomeとUPnPの仕様には目を通したつもりですが、集めそこなっているものがあるのかもしれません。具体的に所在を教えていただけると助かります。

    前に挙げられていたunofficial-google-music-api.pdfは、その名の通り仕様ではありませんね。

    #4493

    Tiki
    キーマスター

    こんにちわ。

    先ほど公開した4.7.0(先行版)でMP3 ABRの読み込み方法を変更しています。そのためには設定変更が必要で、標準設定のままだとこれまでと同様の動作をします。

    設定変更は、設定画面のツリー:「再生の設定」「デコードの設定」、右側の項目「MP3の処理」「ABRの確認フレーム数」を既定の0 (=全フレーム確認) から100など適当な値に設定してください。

    それから、

    OpenHome対応を歌っているのですから、仕様を満たしていないのは
    問題だと思いますよ。

    の件、どの仕様のことを言われているのか大変気にしておりますので、引き続きご連絡をお待ちしています。

    どうぞよろしくお願いします。

23件の投稿を表示中 - 1 - 23件目 (全23件中)

このトピックに返信するにはログインが必要です。