フォーラムへの返信
-
投稿
-
ご確認、ありがとうこざいました。この件は大丈夫そうですね(^^)。
こんにちわ。
Active Backgroundはちょっとハメを外したような機能ですので、気に入ったと言っていただくと、いつもホッとします。(^^;
画像関係のパラメータの設定化については、確認したところ内部に該当する変数がありましたので、次のリリース (4.7.0正式版後になると思います) で対応してみます。ただ、ご期待の動作になるかどうか、というのはちょっと使ってみていただかないとわかりませんが…。
Active Backgroundへの画像の表示は、じつはもうひとつ気に入っておらず、あまり積極的には表示していませんでした (確認したら25%の確率でした。これはつぎで設定化されます)。たまに、すごく間の抜けたような、あるいはギョッとするような表示になることもありますよね…。Windows 7を動作対象外にすれば、多様なDirect Xのフィルタが使えるようになるのものの、下品にならないようにフィルタを適用するのはむずかしく、そもそもそこまでPCのパワーをかけてやるものなのかという話もありますね。いずれにしても、いまもときどき、もうすこしうまい表示方法はないかなと考えていたりします。
こんにちわ。
人名に関するタグについて、まったくの一個人としてどうしているかということをお話しすると、
- Performer: 演奏者
- Composer: 作曲者
- Artist: そのアルバムを代表する適当な名前 (クラシックだと主として作曲者, それ以外だと演奏者)
- Album Artist: 使っていません
という感じです。
P.S. 元のご発言の「WEBファイル」は「Waveファイル」でしょうか? よろしければ訂正しておきます.
こんにちわ。
ご確認ありがとうございました。Active Backgroundは思ったように出ないことも多いので、確認いただくのも面倒なところがあったのではないかと思います。お手数をおかけしました。
こんにちわ。
ご確認ありがとうございました。うまく動作したようで、よかったです。(^^)
こんにちわ。
これまでご報告をいただいた事象は、すべてWindows 7で、それ以外のWindows 8.1, Windows 10では伺ったことがありません。わたしのところでも発生しません。Windows 7以外では大丈夫とはっきりしたことが言えず恐縮ですが、事象としてはそのような状況です。
ご確認いただき、ありがとうございました。
こんばんわ。
さっそくご確認いただき、ありがとうございました。荒っぽい仕様のままだった部分が改善して、わたしもよかったです。
こんばんわ。
Windows 7で、WASAPIのご利用ですよね…。この環境での再生デバイスを切り替えたときの問題はもう長い間引きずっているもので、再生デバイスを切り替えても古いほうのデバイスが (TuneBrowserの内部では解放しているにもかかわらず)、OSから解放されず、残ってしまう事象が確認されています。
TuneBrowserからのWASAPIの制御のどこかがまずいのか、あるいはWASAPI関係のWindowsの仕様なのか、というところも判明していません。Windowsは、あるアプリケーションがWASAPIデバイスを使用したときに、使用が終わってもしばらく (再利用に備えて) キャッシュするという特性があり、それを早期に解放させるようにTuneBrowser内で制御しているのですが、期待通りには動いていません。
この件は過去かなり時間をかけて調査してきましたので、申し訳ないですが、すぐには改善するのはむずかしそうです。
momoさん、こんにちわ。
僕のタグ付けルールも当初はTikiさまのblogやヘルプをもとに作りました。
そうだったのですか。ブログはそのときにやっていた個人的なタグ活用を記したものですが、お役に立てたとしたら、大変嬉しいです(^^)。
TuneBrowserのタグ活用の思想も、もちろんこのブログに書いた内容がベースになっています。再生環境は時代とともに変わっていきますが、音楽コンテンツの捉え方は当面は変わらないと思います。つまり、ジャンルがあって、作曲者がいて、演奏者がいて、時代があって…とかそういった捉え方は大きくは変わらないように思います。
TuneBrowserがそのお役に立てると嬉しいですし、なによりもTuneBrowserの源泉データは楽曲ファイル自身のタグデータです。そのため、将来もし何らかの理由でTuneBrowserをご利用いただけなくなったとしても、整理し蓄積された情報が失われてしまうことはなく、そのまま将来のべつのやり方に活かせます。そうして、長く活用できる資産になっていくはずです。そう考えるとタグデータは個人の利便性や思いを込めて整理する価値のある情報だと言えると思います。
すいません、いちどクローズした話題ですが、追加情報があります。
Lyrics ViewにActive Backgroundがかぶさって表示されるような状況の場合、メインウィンドウやデスクトップにActive Backgroundが表示される状況になっていると思いますが、この状態だけを抑制することができます。
設定画面の
- 左側のツリー:「表示の設定」「ビューの設定」「Player Viewの設定」「デスクトップ表示の設定」
- 右側の項目 :「Active Background」
この下に、
- デスクトップ表示でも表示する
- デスクトップ表示しない場合はメインウィンドウに表示する
のふたつの項目があり、Yesに設定されています。
意味はそれぞれ推察いただけるかと思いますが、これらをNoにすると, Active BackgroundはPlayer View上にだけ表示され、Lyrics Viewにかぶさるような表示にはなりません。
上でご案内した方法は、Active Backgroundそのものを止めてしまうやり方ですが、こうした細かい指定もできますので、ご報告しておきます。
(そういう機能を作ったほうがいいかなとソースを調べていて、この設定を「再発見」しました(^^;)
momoさん、こんばんわ。
ご確認いただき、ありがとうございました。
sambacancaoさんからも工夫の紹介をいただいていますが、わたしも、たとえば、既成のジャンルにとらわれず、自分の嗜好に応じたジャンルを複数設定しています。ピアノ曲をよく聴くので、たとえばピアノ協奏曲には、ジャンルとしては “Classical; Concerto; Piano” の３つを設定しています。またすこし嗜好とはちがいますが、オーディオ試聴用の音源には、通常のジャンル以外に「試聴用」というジャンル名も加えています。
あと、以前pochipon_hさんからご要望いただいたRating(★をつける)も開発はつづけていますので、もしかしたらお役に立つのかもしれません。
よろしくお願いします。
こんばんわ。
ご要望になっている趣旨はよく理解できました。
ただ残念ながら、実現はむずかしそうです。内部の処理の話になりますが、TuneBrowserのタグ情報の処理は、あくまでもタグとして事前に記録された静的な情報に基いて行っています (例外として、再生時間とか再生デバイス名とか、そういった全体状況に関する情報もあります)。
これに対して、ツリーの下位ノード数というのは、タグには記録されていない動的な情報になります。高速なマシンをご利用の場合には気がつかれないかもしれませんが、ツリーを生成する際には、階層別に表示→下位層の生成、という処理を繰り返しています。そのため、あるツリーノードの下位ノード群が表示されたときには、まだその各下位ノードの下にさらに何ノード存在しているかは判明しておらず、ウィンドウの表示とはまたべつに非同期で検索をつづけています。
すべてのユーザが高速なマシンをご利用であれば、すべての情報が出そろってからツリーノードを生成するということにしてもいいのかもしれませんが、それでもおそらく現在のツリーノード開閉の軽快感は出せず、うっ、と詰まるような感じになってしまうと思います。またツリーノードを表示後、下位の情報が出揃ってから並べ直すとすると、表示が瞬いたような感じになり、これも逆に見苦しくなってしまうと思います。
他社のソフトの例ですが、たとえばWindowsのエクスプローラも、容量別などでツリーノードの並び替えはできません。これはおそらくは同様の理由だろうと想像しています。
あまり良い返信でなく恐縮ですが、ご理解いただければありがたいです。
よろしくお願いします。
こんばんわ。
たしかに、あの系のポップアップウィンドウは、次に表示しようとするウィンドウサイズが前回と異なっていたら、既定の場所に戻して表示するようになっています。イメージの表示は、イメージの原画サイズとデスクトップサイズから適切と思われるサイズに変換して出しているので、イメージごとにウィンドウの大きさが異なり、そのような動作になっていました。
ここは、サイズが異なった場合には前回表示位置の左上点を維持したまま出すようにしてみましょうか。次の先行版リリースでそのようにしてみようと思います。
こんばんわ。
確認したところ、たしかに4.7.0で変更した部分が影響していました。Player部分の停止を行うときに、たとえばデコーダやドライバでハングアップしていたときのことを想定して、スレッド停止の方法を変更したのですが、そのときに一時停止状態の考慮が漏れていました。
再生中にべつの曲を再生する場合は、実際には「停止」「曲の変更」「再生」という動作を行うわけですが、一時停止中のときには最初の「停止」できちんと停止にならず、次の曲に変更しようとしても、再生(一時停止)中だから変更はできない、と判定していました。
Chartreuxさんからご報告いただいたWASAPIとASIOの差異ですが、おそらく動作タイミングの差異により、現象が異なって現れたのではないかと思います。
次の先行版の更新で対処しますので、お手数ですが、そのときにまたご確認いただけると助かります。
よろしくお願いします。
こんばんわ、ファイルの送信ありがとうございました。
確認したところ、やはり最近の変更で入れた、ABRフレームの扱いが影響していました。ご利用のMP3には冒頭部分に32kHzと44.1kHzのフレームと、無効フレームが混在しています。ある一定の条件で、それらを選別して曲としてのスペックを決めていたのですが、それが32kHzという結果になっていました。
いただいたサンプルでは、チェックした範囲の最終フレームであれば44.1kHzのようですし、それはそれで筋が通っているように思いますので、次の先行版の更新でそのように変更してみます。
よろしくお願いします。
なるほど、ダブルクリックで再生という設定もできましたね。了解しました。ありがとうございます。m(__)m
こんばんわ。
一時停止中に別の曲を再生するということは、アンカーの再生ボタンをご利用になったのでしょうか? その場合、たしかに期待とちがう感が否めませんね…。確認していないのですが、「一時停止中の再生操作 = 一時停止解除」ということで、この動作は以前からだったように思います。どうするか検討します。
こんばんわ。
スクリーンショットお手数をおかけしました。拝見したところ、わたしの意図通りに表示されていました。意図というのは、アンカーはいつもジャケット画像の上とはかぎらず、トラックに関連づいたアンカーは、そのトラックの「選択時に反転する領域」の左側に表示されるようにしています (左側に領域がない場合は下に出る場合もあります)。
その位置は、かならずしもジャケット画像の上ではなく (Album Viewでのトラック表示もそうですね)、わたしだけの感覚かもしれませんが、マウスをかざしたときに浮いて出るだけですので、おかしいようにも感じませんでした。
よろしくお願いします。
こんばんわ。
最近、MP3系の改修がつづいていますが、これはおそらく無効フレーム検出方法を変更した副作用かと思います。以前は32kHzのフレームを (何らかの理由で) 無効フレームとして弾いていたものを、有効なフレームとして読んでいるということのようです。
それで、すいませんが該当の楽曲ファイルをお送りいただけないでしょうか。この後、送信方法を書いたメールを、ご登録のメールアドレスにお送りします。お送りいただいたファイルは検証目的以外には使用しません。
よろしくお願いします。
こんばんわ。
ご確認ありがとうございました。念のため、ですが、
- ストイック表示を有効にしても、たしかに表示は抑制できます.
- ご案内したツールバーのボタンはActive Backgroundの切り替えです.
あくまでご覧になっている方向けの説明ですので、とくになければ返信無用です。よろしくお願いします。
わたしが反則してあとで追記した部分にもコメントしていただき、ありがとうございます。
UWP版は…ちょっと臆病になっています(^^;。でもできるだけ早く出すようにしますね。
こんばんわ。
おっしゃっているのは、Active Backgroundのことかと思います。これを表示させないようにするには、Player View右上にある、
この赤丸で囲ったボタンを押して、消してください。
こんばんわ。
相当、使い込んでおられますね。
拝見したスクリーンショットは問題なく表示されているように見えましたが、これは工夫された結果だから、ですよね。もともとの課題がどうだったかというのが、すいませんが、もうひとつ呑み込めていません。もしなにか改善したほうがよいようであれば、最初に課題が出ている状況でのスクリーンショットを見せていただけないでしょうか。
よろしければで構いません。よろしくお願いします。
こんばんわ。
昨日、4.7.0の先行版をリリースしたのですが、そこで本件の強化も行っています。対処にはなっておらず、また現象が発生したときのインパクトも大きいことから、試してみてくださいとは簡単には言えないのですが、いちおうご報告しておきます。
こんばんわ。
まあ、ケアレスミスというのは誰にでも起きるものですよね。それで冒頭にスペースが入ったら予想外の挙動をするというのは良くないので、これはTuneBrowserを直すべきだと思いました。
こんばんわ、次々とご確認いただき、ありがとうございます。
歌詞(UNSYNCEDLYRICSタグ)が設定されている場合、アクティブバックグラウンドで表示されるテキストがほぼ歌詞(厳密には歌詞の中のどれか1行)ばかりになるような気がします。
あれ?(^^; さりげなく (たまに) 歌詞が表示されるようにしたつもりでしたが、失敗しているようです。行数の多い少ないというよりは、テキストの候補とするタグを決めるときのロジックで、UNSYNCEDLYRICSの値が存在していると、それが必ずヒットしてしまうような条件になってしまっていました。
ちょっとここは見直します。ご指摘ありがとうございます。
歌詞表示のほうは、うまくいってそうだと理解しました。よかったです。(^^)
こんばんわ。
さっそくご確認いただき、ありがとうございました。ヘッダ/フッタ表示は今回改めてロジックを見直す機会になりましたので、よかったです。(^^)
こんばんわ。
ご確認いただき、ありがとうございました。治っていてよかったです(^^;。
こんにちわ。
そうですね、設定画面としては用意しませんでした。わたし自身はF11 / Shift+F11で適当な大きさに調整しています。
ご確認いただき、ありがとうございました。
さっそくご確認ありがとうございました。
うまく動作したようで、良かったです。(^^)
こんにちわ。
ID3v2.2形式の画像読み込みの件とジャンル番号の件、先ほど公開した4.7.0(先行版)で対応しています。できれば、お時間のあるときにでもご確認いただけると助かります。
よろしくお願いします。
こんにちわ。
先ほど公開した4.7.0(先行版)でMP3 ABRの読み込み方法を変更しています。そのためには設定変更が必要で、標準設定のままだとこれまでと同様の動作をします。
設定変更は、設定画面のツリー:「再生の設定」「デコードの設定」、右側の項目「MP3の処理」「ABRの確認フレーム数」を既定の0 (=全フレーム確認) から100など適当な値に設定してください。
それから、
OpenHome対応を歌っているのですから、仕様を満たしていないのは
問題だと思いますよ。の件、どの仕様のことを言われているのか大変気にしておりますので、引き続きご連絡をお待ちしています。
どうぞよろしくお願いします。
こんにちわ。
本件、4.7.0で設定画面の設定で切り替えられるようにしました。効果は上のコメントで公開した設定ファイルによるものと同じです。
わざわざご確認いただくにはおよびませんが、いちおうご報告しておきます。
こんにちわ。
本件、さきほど公開した4.7.0の先行版で対処しています。わざわざご確認いただくには及びませんが、いちおうご報告しておきます。
よろしくお願いします。
こんにちわ。
先ほど、歌詞表示をサポートした4.7.0の先行版をアップしました。標準の設定では表示されていませんので、上部のメニューから「表示」「ドッキング・ウィンドウ」「Lyrics View」を選択して表示させてください。ほかのドッキング ウィンドウと同様に、メインウィンドウのどこかに組み込むことができます。
よろしくお願いします。
こんばんわ。お手数をおかけしています。
ヘルプの件も考えているのですが、ある程度まとまった解説を書かないと説明するのがむずかしそうで、手をつけかねています。ここでノウハウが蓄積されていくと良いのですが…。
こんばんわ。ご確認ありがとうございました。
わかりにくい動作で申し訳なかったです。でもおかげで、これで古い曖昧仕様がひとつ整理できそうです。
ありがとうございました。
こんばんわ。
ご連絡とダンプファイルの送信、ありがとうございました。内容拝見しました。異常終了というよりは、動作に時間がかかるようになって「予期しない状態」が検出されるようになったのだと思います。
前回のトピックでグループクエリを “%ALBUM%” に変更されましたが、そのときに、冒頭部分に半角スペースが入ってしまっていないでしょうか? ご確認いただき、もし入っていればそのスペースを削除して、%ALBUM%を指定してください。
それで動作のようすを見ていただけないでしょうか?
まだこれが原因と特定できていないのでご説明するのは早計かもしれませんが、「半角スペースごときで」という話もあろうかと思いますので簡単にご説明すると、固定文字だけでクエリが完結した場合ひとつも楽曲がヒットしないということになるため、クエリの冒頭部に固定文字(今回は半角スペース)があると、全曲をヒットしたとみなす特別な処理が入っています。
そのため半角スペースつきの ” %ALBUM%” を指定すると、最初のスペースで全曲がヒットして、その後のALBUMタグでアルバムが分類され、結果としてすべてのアルバムにすべての楽曲が含まれるという状態が発生します。再生時にそれをPlayback Queueに転送しようとして、処理に長い時間がかかり、ご利用のPCのスペックもあって、長時間応答しない状態が発生していたものと思います。
まずはクエリの設定をご確認いただいた上で、TuneBrowserとしては、グループクエリの冒頭に固定文字が入ると全曲ヒットという図式はまずいと思いますので、これはこれでべつの対策を考えます。
よろしくお願いします。
こんばんわ。
検討した結果、ヘッダ表示専用でイメージサイズを保存できるようにしました。
次のリリースで対応しますね。
ご確認いただき、またお気遣いいただき、ありがとうございましたm(__)m。
こんにちわ。
「ライブラリー」と言われているのがアルバムだとして、アーティスト名が異なっても、アルバム名だけを見てアルバムをまとめたい、ということでしょうか?
もしYesであれば、設定画面で以下のように設定してください。
- 左側のツリー:「表示の設定」「クエリの設定」
- 右側の項目 :「標準のクエリの設定」「標準のグループクエリ」
ここが標準では以下のようになっています。
%@_GRPARTIST% - %ALBUM% - %ALBUM EDITION% - %X_ENCODER_TYPE%これを以下のようにALBUMタグだけ指定してください。
%ALBUM%あと、その下の「標準のグループソートクエリ」も、同様に
%ALBUM%にしたほうが、並び順がわかりやすくなるかもしれません。
こんばんわ。
お考えとしては、トラック表示と共用の大きさでよいということでしょうか?
こんばんわ。
今日、時間をかけて処理を追いかけてみたのですが、エラーを見逃してそうな部位は見つけられませんでした。次のリリースでは、以下の強化を行います。
- ログの追加
- チャンク書き込み後の書き込み位置のチェック
前のコメントにも書いたように、他のソフトの影響含め、ご利用のPC/デバイス関係でなにか問題が起きているものと推察しますが、TuneBrowser側でそれを検出できればいいのですが、現在のところは対処療法となっています。
よろしくお願いします。
こんにちわ。
しかしこの方法ですとTuneBrowserを再立ち上げすると設定が元に
戻ってしまいます。なるほど、たしかにヘッダ表示はトラック表示のヘッダ部分のみという位置づけで、独立した設定を用意していませんので、そのような動作になってしまいますね。現在のところ覚えさせることはできなさそうです。
念のための確認ですが、やっぱり覚えさせたいですか? (^^;
こんにちわ。
CBRとABRのトラックに関してはシークは問題ないのでは？
（同期ビットもありますからCBRは問題ないです。ABRは同期ビットというか、フレームを走査する必要があると思っていますので、前掲の動作になります。
VBRはABRと思っていい加減に対応するか、
VBRもABRもフレームとバイト位置の地図を作って対応しています。
OpenHome対応を歌っているのですから、仕様を満たしていないのは
問題だと思いますよ。仕様と言われているのはどの文書のことでしょうか? いちおうOpenHomeとUPnPの仕様には目を通したつもりですが、集めそこなっているものがあるのかもしれません。具体的に所在を教えていただけると助かります。
前に挙げられていたunofficial-google-music-api.pdfは、その名の通り仕様ではありませんね。
こんにちわ。
追加のファイルありがとうございました。受領しました。
現在のところでわかっていることをご報告します。
- 2番目のファイルには、ご指摘の通りタグ情報だけが入っていて、data chunkは入っていませんでした。
- 1番目のファイルに対して、わたしのほうで画像を追加操作をしたところ、問題なく追加されました。
現在、画像の追加の処理(ソースコード)の再確認を行っています。ご利用のファイルには、途中にLIST chunkが含まれています。LIST chunkの内容はID3v2タグと重なる部分があるため、以下の手順でWaveファイルを更新します。
- テンポラリファイルを作成し、このLIST chunkを除去したWaveファイルを再構築します.
- 再構築したテンポラリファイルに、内容の整合を図ったLIST chunkとid3 chunkを追加します。
- テンポラリファイルが完成したら、元のファイルをバックアップのために別名に変更し、テンポラリファイルを元のファイルに名前変更します。これで新しいWaveファイルが完成します。
- 残ったテンポラリファイルがあれば削除します。
それぞれのステップでエラーがあれば、元のファイルを維持した形にもどして処理を終了するわけですが、data chunkだけが抜けるという形が起き得るとしたら1.の部分です。これはテンポラリファイルに対する操作になるのですが、何らかの理由でエラー検出ができなかった場合があるとすると、2.以降に進んで、今回の状況になる可能性があります。
それで1.の処理でエラーの見逃しがないか再チェックを行っていますが、現在のところ問題のありそうな部分は見つかっていません。
また1.でエラーが起きるとしたら、
- ディスク容量不足
- デバイス、ケーブル等の動作不安定
といった理由くらいしか現在のところ思いつきません。
取り急ぎ、よろしくお願いします。
こんにちわ。
ファイルの追加ありがとうございます。ただ残念ながら、今回は届いていないようです。わたしのシステムの問題かもしれずお手数なのですが、もういちど2番目のファイル再送していただけないでしょうか?
Chartreuxさん、ご指摘ありがとうございます。m(__)m
いまはまだ何とも言えないのですが、やはりそうしたほかのソフトの影響の可能性ということもありますよね…。考慮しつつ検討を進めたいと思います。
こんばんわ。
上部メニューの「表示」「アルバムビューの操作」「イメージのサイズ」から変更することができます。またそのメニューの表記にあるように、F11/Shift+F11キーで変更することもできます。
よろしくお願いします。
こんばんわ。ファイルの送信ありがとうございました。
確認したところ、お送りいただいたファイルは、ジャケット画像は出ませんでしたが、再生そのものは正常に行うことができました。この結果で、ご認識と合っていますでしょうか?
またその場合、お送りいただいたファイルは、再生に失敗する前の原本というか「ジャケット画像埋込み操作前」のファイルでしょうか、それとも実際に再生に失敗したファイルそのものでしょうか?
検討の方向が変わってきますので、ご確認いただければ幸いです。
どうぞよろしくお願いします。
こんばんわ。
わたしは冷静な人間ではありませんよ。冷静な人間だったら、このソフトをここまでひとりで作り上げることはできなかったのではないかと思います。
ただ、このフォーラムという公共の場では、面識のない大人同士が表情も見えないなか、文字だけで挨拶以上の会話をしようというのですから、できるだけ冷静というか礼節をもって応対しなければならないとは肝に銘じています。ときどきは、我慢の限度を超えてしまうことはありますが。そうした結果、「冷静に応対できている」と言っていただけるのであれば、それは、よかったというか、有難いことだと思います。
それで、全フレーム走査については、わたしは総演奏時間ではなく、CBRとABRの話をしました。ABRの場合、シーク操作を行ったときの頭出しをするためには、シーク位置(時刻)に対応したフレーム位置(バイト)の情報が必要で、そのテーブルを作っています。それはVBRの場合でも同様なので、VBRとABRの処理を合わせればいいような気もしますが、現在はXingヘッダの有無で大きく処理がわかれており、そうなってはいません。
また、TuneBrowserの再生部はOpenHome専用ではなく、基本的にはファイルの再生を主眼に開発してきたもので、OpenHomeはHTTPプロトコルをファイルシステムに抽象化してアクセスする形で実現しています。そのため最初からOpenHome対応を主目的として開発されたプレーヤーでは簡単に思えることも、実際のソースコードの構成上簡単ではないこともあります。というか、先ほどのシークの件もそうですが、ファイルシステム上の音源を快適かつ正確に再生できるようにこれまで腐心してきました。それは容易には捨てられません。
ご意見をいただけることは大変ありがたく思っています。ご意見踏まえて今後どうするかは、最初のほうの返信で申し上げたように、すこし時間をかけて検討していきたいと思います。
Google Play Musicに関する課題の情報は、現在のところyamaさんからのこのトピックのみで、ほかの方からのご意見はないようです。ですので、yamaさんに行っていただいている検証作業のみが唯一の設計材料となっています。ゴールにたどりつけるかどうかもわからない状況で、この検討を進めていくのであれば、わたしとしては頼りにさせていただくほかありません。よろしくお願いします。
こんばんわ。
メタ情報として送られて来ているのに、正確な演奏時間を調べるためだけに
フルダウンロードするのは無理があるのでは？MP3でXingヘッダがない場合、CBRであれば良いのですが、たまにABRのものが存在しています。ABRの場合、フレームの位置が特定できないため、はじめに全フレームを走査しています。その方法はネットワーク再生の場合は良くないということなのだと思いますが、どういう方法が取り得るのか、というのはすぐにはわかりません。
ところで、さまざまなケースを試していただいて大変心強いのですが、現在のところ、
再生対象曲:
1) ローカルからアップロードした曲
2) Google Play Musicが提供している曲再生方法:
A) TuneBrowser
B) SoundGenic OpenHome player(など)の組合せパターンがあると理解しているのですが、どの組合せのことをお話しになっているのか、少々混乱しています。たとえば
再生の方は、失敗を繰り返しながら何度かボタンを押していたら、
成功しました。
というのは、上記のどのパターンのことを言われているのでしょうか?
こんばんわ。お手数をおかけしています。
ログの掲載ありがとうございました。
ポイントとなるのは
2018/11/01 08:57:11,569.121: T38ec: Error: No data chunk found.の部分なのですが、残念ながらこのログからはなぜこのメッセージが出たのかというところまではわかりません。
ログの状況から再生されようとしている以下のファイル
I:\Totalmusic\マイベスト：My favorited old popular-music & screen-music\1965 ララのテーマ Lara’s Theme – Andre Kostelanetz.wavは存在していると思うのですが、これをお送りいただけないでしょうか? わたしのほうで中を調べてみたいと思います。
この後、ファイルの送信方法を書いたメールをご登録のアドレスにお送りします。お送りいただいたファイルは検証目的以外には使用しません。
どうぞよろしくお願いします。
こんばんわ。続報ありがとうございます。
前にも書きましたが、TuneBrowserはMP3の再生にID3v2タグは必要としていません。ID3v2タグがないのが再生できない原因だと思いこまれているようでしたので、どのようにご説明したものか悩んでいました。
ついでながら、再生に必要な演奏時間などの情報も、メタデータから取得することはなく、MP3のフレームから取得します (またビットレートは再生にはまったく必要ありません)。
そのため結局は、問題はMP3のフレームが読めていないということに尽きます。それで、今回あらたにいただいた情報で問題要因らしいところは、「最初のフレームが届くまでに最大で１分程度待ち時間があります」という点です。TuneBrowserの通信のタイムアウトは5秒です。
これまでいただいた情報を総合すると、次回リリース時に、このタイムアウト時間を設定で変更できるようにするというのが対策らしい対策になりそうです。
こんばんわ。
「取り込んだ曲が時々紛失してしまいます」というのは、どういう状態でしょうか?
- 画像が表示されなくなる
- TuneBrowserに表示されなくなる
- ファイルそのものが(エクスプローラなどで探しても)見つからなくなる
など、いくつかの状態が考えられますが…。
それから、Pause操作が効かない件ですが、もしデスクトップPCをご利用であれば、”Pause”キーがあると思いますので、それを使ってみられては、と思います。こちらは名前は “Pause” ですが、動きは多少ちがっていて、現在の再生位置を維持したまま停止します。こちらのほうが機器差が出にくいかと思います。
よろしくお願いします。
こんばんわ。
コメントありがとうございます。歌詞のご要望は意外に多いですね。
現在のところ、先のコメントにも書いたように、ひとつドッキング・ウィンドウを増やすことで考えています。残念ながらそこでは編集はできませんが、タグ編集(プロパティ)で編集ができるようにする予定です (現在も編集はできるのですが、複数行編集の操作性がもうひとつなので、そこは改善します)。
よろしくお願いします。
こんばんわ。ファイル送信ありがとうございました。
確認したところ、メタデータがID3v2.2形式で格納されていて、対応できていませんでした(^^;。v2.2の形式に遭遇したのははじめてです。
これも、次のリリース時に画像を読み込めるようにします。ほかになにかお気づきのことがあれば、お知らせいただけると助かります。
どうぞよろしくお願いします。
こんばんわ。ログ送付ありがとうございました。
原因が大体分かりました。
TuneBrowserはID3タグがなくてもMP3を再生することができます。理解が悪くて恐縮ながら、もうひとつ原因が掴めていないのですが、ご利用の環境では解決したと理解してよろしいのでしょうか?
こんばんわ。
ジャケット画像の状況、了解しました。
お手数ですが、事象の出ている(ジャケット画像が出ていない)ファイルをひとつ、お送りいただけないでしょうか。調べてみたいと思います。
この後、送信方法を書いたメールをご登録のメールアドレスにお送りします。お送りいただいたファイルは検証目的以外には使用しません。
どうぞよろしくお願いします。
こんばんわ。さっそくご確認ありがとうございました。
「少数」が少々気になりますが, またなにかお気づきのことがあればお知らせください。
よろしくお願いします。
すいません、ちょっとボケてました。
たしかにご指摘のような動作をします。それで、その動作をオプションで切り替えられるようにしているのですが、現在はそのオプションを画面には出していません。
添付ファイルは、オプションを制御するファイルです。テキストファイルです。ダウンロードして、そのファイルをTuneBrowserのウィンドウにドロップしてください。動作が切り替わり、次回から “Unknown Artist” は勝手に入らないようになると思います。
もし操作がわからないようでしたら、またご連絡いただけますか。
どうぞよろしくお願いします。
こんばんわ。
MP3には、ジャンルを番号で書くという古い仕様があるのですが、その判定が甘いために「01.管弦楽」を1という番号と解釈してしまう問題があることがわかりました (1は「Classic Rock」です)。すこしお時間をいただくのですが、次のリリースのときに改善したいと思います。
ジャケット画像が出ない件は、すいませんがすぐには理由が思いつきません。ジャケット画像は楽曲へ埋め込んでいるのでしょうか、それともフォルダに画像ファイルを置かれているのでしょうか?
こんばんわ。
ARTISTが空欄のときに、Unknown Artist”が勝手に入ってしまう事象は、たしかに以前のバージョンではそのような仕様になっていたのですが、改めて確認したところ現在はその処理は動作しないようになっていました。
念のため、ですが、ご利用のTuneBrowserのバージョンをご確認いただけますか? 最新は4.6.1です。
わたしのほうでは、ほかに想定外にそのような処理が動作するケースがないか、改めて確認をしておきます。
よろしくお願いします。
こんばんわ。さっそくのご対応ありがとうございました。
どうもプロトコルは通じていて、MP3形式の問題のような感じですね。いただいたログも双方確認してみましたが、有意な差は現在のところ認められませんでした。
MP3形式の確認ですが、ファイルを前提にしているため、残念ながら現在のTuneBrowserのログだけでは確認ができません。ひょっとしたら、再生開始時にLog ViewのPlayerタブ内になにか情報が表示されるかもしれませんが、ご指摘の通り長さ0でとくになにも出ない可能性もあります。
何度もすいませんが、もしよろしければ再生操作後のLog ViewのPlayerタブの内容をお送りいただけますか。わたしのほうでは、次のリリース時にログを強化するポイントを検討します。
よろしくお願いします。
こんばんわ。
基本的なスタンスはわかりました。ただ現状ではわたしのほうは雲をつかむような状態です。
ご利用の環境をわたしのところで再現させるのは難しいので、すこし期間をかけて、細かい点を確認しながら議論を進めてもよろしいでしょうか?
一連の操作を行ったときの、TuneBrowserのログは確認されていますでしょうか。TuneBrowserのログは、もし表示されていなければ上部のメニューの「表示」「ドッキングウィンドウ」「Log View」で表示されます。Log Viewの下部にはいくつかタブがあり、そのうちの「UPnP」タブを選択いただくと、その関連するログが表示されます。
このログは、マウスの右クリックで「すべて選択」「コピー」ができます。コピーした内容をお送りいただきたいのですが、ネットワークに関するログのため、内容にはIPアドレス等が含まれます。そのIPアドレスは、ローカルIPか、あるいはサービス提供側のIPアドレスで、個人情報に類するものは含まれないと思いますが、念のためということもありますので、このフォーラムではなく、専用のアップロードフォームをメールでご連絡します。そちらにアップロードをお願いします。
ログをとっていただく際には、できれば新しい曲の追加～再生の一連の作業を行ってください。
また、プロトコルの問題か、MP3フォーマットの問題かを切り分けるために、可能であれば以下の情報をいただければ有難いです。
- MP3以外のフォーマットで試すとどうなりますでしょうか。
- Google Play Musicは、ローカルにあるファイルをアップロードして管理することができると聞きました。TuneBrowserで再生できている、お手持ちのMP3ファイルをGoogle Play Musicにアップロードして、今回の操作を行った場合はどうなりますでしょうか。
わたしの理解がまちがっている、あるいは対応がむずかしいようでしたら、その旨ご連絡ください。
どうぞよろしくお願いします。
こんにちわ。
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は、CDのメタデータの取得に際しては、freedbのようなオープンサービスのみ利用しており、Gracenoteのような商用サービスは利用できません。そのため、iTunesのような大手開発のアプリとは、メタデータを取得できるCDに差が出るのかもしれません (Gracenoteとはすこし話をしてみたのですが、やはりTuneBrowserからの活用は残念ながら契約面でクリアできそうにありませんでした)。
TuneBrowserは、他のソフトでリッピングしたファイルも取り込むことができます。そうしたやり方でご活用いただければと思うのですが、いかがでしょうか?
細かいですが、TuneBrowserは、外部のメディアサーバとしては、DLNAは対象としていません。UPnPのメディアサーバのみ対象としています (DLNAはわたしのような個人には仕様が開示されないので、残念ながら実装しようがありません)。
これがなにかヒントになりますでしょうか?
こんばんわ。
TuneBrowserはBubbleUPnPをプロキシーとしたCloudのストリーミング再生を
サポートしていないということなのでしょうか？
サポートしている=動作保証している、という意味でしたら、サポートはしていません。でも、動作しない理由もすぐには思いつきませんね…。TuneBrowserは転送プロトコルとしてhttp/httpsのみ実装しているのですが、その故でしょうか?
youさん、こんばんわ。
アイデアありがとうございます。これは再生中だけ浮遊霊のように(^^;表示させれば良い、ということでしょうか。Active Backgroundはまったくマウス操作などが効きませんので、縦方向に収まらずスクロールさせたくなったり、位置を変えたくなったときの操作が課題となるかもしれないですね…。でもおもしろいです。
現在のところは、収まりがよくないと言いつつ、第4のドッキング・ウィンドウとして表示させることを考えています。
ありがとうございました。
白の枠線というのは、フォーカスをあらわす線のことを言われているのだと思います。
Playback Queueは既定の設定で再生中の曲にフォーカスをあわせるようになっているので、結果としてそのように動作しているということになります。
そのポップアップウィンドウの右下に、サイズ変更ができることを示す三角がありますので、そのあたりをマウスでドラッグしてください。
三角部分以外のウィンドウのフレームをドラッグすることもできます。
スクリーンショットありがとうございます。
ウィンドウの幅が狭いのですね。もうすこし広げていただけると、その分タイトルが表示されると思います。
4.6.0からチャンネル数も出すようにしたのですが、狭い領域で使用されると、その分だけタイトル幅が狭くなってしまいますね。
ご確認ありがとうございました。
こんにちわ。わりとタイムリーな話題です(^^;。
先日来、歌詞表示についてあらためて検討していました。以前にHAlkさんからいただいたアイデアは、コメントに書いたように実現は難しいのですが、別ウィンドウに出すだけであればできなくはないと思います。ただ、どこにそのウィンドウを出すにしても、あまり収まり良くはなさそうですが…。
ちなみに、なのですが、歌詞に関しては
- 自動取得などの機能は現在は考えていません。UNSYNCEDLYRICSに類するタグデータとして楽曲ファイルに埋め込まれているものを対象に考えています。
- “Unsynced” なので、楽曲の進行に合わせた自動スクロールなどは行えません。
というような内容で考えています。とくに1番目については、みなさんどういうところで歌詞を入手されているのかわからないので、他の(専用の?)ソフトなどでタグデータが埋め込まれたあと、TuneBrowserで再生時に表示する、という感じでイメージしています。それで機能としては成り立っているものでしょうか (編集そのものはいまのTuneBrowserのタグ編集(プロパティ)でも行うことはできます)。
よろしくお願いします。
すいませんが、なにか問題が起きているのかもしれませんが、どういう状況かさっぱりわかりません。
当該の事象が出ているスクリーンショットを貼り付けていただけないでしょうか。あるいは同様の事象が起きている他の方でも、情報をいただけないでしょうか? > ALL
よろしくお願いします。
ご指摘の見え方は、たしかにもうひとつなのですが、View上のレイアウトによって「押しやすい位置」あるいは「押せる位置」というものがありますので、動的に位置を切り替えるようにしています。
統一したい気持ちはあるのですが、そうするとかなり操作しにくくなると思います。
こんばんわ。
先ほど確認したら、ストアで公開されていました。すでにダウンロードされているようです。自動更新の設定にされている場合は、そのうち更新されると思いますので、よろしくお願いします。
こんばんわ。
ええと、お願いしたのは「MOTU以外の再生デバイス」でして、「他のASIOドライバー」ではありません。もし他のデバイスがPCにインストールされていないとしたら、TuneBrowserには “Null output” というソフトウェアで模擬したデバイスが (リストの一番下に) ありますので、これを選択してください。
どうぞよろしくお願いします。
こんばんわ。お問い合わせありがとうございます。
お待たせしています。すでに米国Microsoftには申請を出していますので、(リジェクトがなかったとして) 期待としては明日なのですが、土日の休業日を挟んでしまうため、週明けになる可能性が高そうです。
いましばらくお待ちください。
sambacancaoさん、こんばんわ。
お願いがあるのですが時期バージョンでヘルプに%_TitleValue%の説明を
追加して頂けませんでしょうか？じつは現在のTuneBrowserのヘルプには、このあたりの書式設定の方法について書いている部分がそもそもありません。設定画面の下に表示される説明文に頼っている状況です。
%_TitleValue%関連の設定が難しいことは自覚していまして、ですのでここで説明をさせていただいたわけですが、もうすこしなにか良い説明方法がないか、考えますね。どなたかブログなどに書いていただけると素晴らしいのですが(^o^;。
こんばんわ。
ご連絡ありがとうございました。ひと息のところでダメでしたね。
MOTUのASIOドライバの特性はわからないのですが、ドライバによっては、システムでひとつだけ動作する前提をとっている場合があるようで、その関連の確認のため、以下を試していただけないでしょうか?
- TuneBrowserの再生デバイスをMOTU以外のものにする (Player View右下のドライバ名のところをクリックすると選択できます).
- 念のためTuneBrowserを再起動する.
- その状態で、設定画面からチャンネル一覧が出てくるかどうかをご確認いただく。
チャンネル一覧は設定時にだけ必要なものです。もしその状態でうまく設定できたとしたら、とりあえずは再生デバイスをMOTUにしたままご利用いただけます (だからそれでよいという話にはすぐにはなりませんが…)。
よろしくお願いします。
ご確認いただき、ありがとうございました。お手数をかけてしまって、すいません。
youさん、ご確認ありがとうございました。
ご確認いただいて、よかったです(^^;。youさんの環境ではコンテンツグループを明示的に指定されているのですが、そのケースの考慮が充分でなかったようです。べつのトピックで「昇格」の話題が出ていたこともあり、検証時の思考が昇格系に重きを置くようになってしまっていました。
すいませんが、すこし先は長さそうなので、本件の改修はいったん4.6.1から外して、その先のリリースで対応していこうと思います。
それで、先ほどそのもとに戻した1416を公開しました。もうしわけないのですが、処理が「もとに戻っている」ことをご確認いただけないでしょうか? 大変お手数で恐縮ですが、どうぞよろしくお願いします。
おはようございます。
youさん、ご確認ありがとうございました。お手数おかけしました。
hiroさん、同一曲は、「ファイル名+サブソングインデックス」が同じ曲という意味です。サブソングインデックスはCUESHEETをご利用の場合に付与されるもので、CUESHEETをご利用でない場合は0固定です。
そのためフォーマットがちがうとか、同じファイルでもべつのフォルダにある場合は、ちがう曲として判定しています。
よろしくお願いします。
あ、さっそくのご確認ありがとうございます。
こちらも入れ違いで失礼しました。再生できるようになって、よかったです。(^^)
こんにちわ。
あー、もしかしてRME Fireface UCXということは、18ch出力の機器でしょうか。またダンプファイルをお送りいただいたのは昨日でしょうか。
でしたら、たしかに受領しております。4.6.0は16chを超える出力を持つ機器を接続すると、ご指摘のように動作を停止してしまいます (実際に出力に利用するch数とはまたべつです)。先ほど、この問題に対処した4.6.1の先行版を公開しています。お手数をおかけしますが、ぜひこの先行版で動作をご確認いただけると助かります。
どうぞよろしくお願いします。
こんにちわ。
この機能について、Viewに大量の楽曲 (数万曲とか) が表示されていると、動作が著しく遅くなることが判明しました。4.6.1でその動作を改善しています。
どうしても全曲総当たりの検索になるので、曲数が増えるほどに時間がかかってしまいますし、この処理は描画要素に直接関係することもあり非同期化を行っていません。そのため処理のあいだは砂時計+描画停止の状況になるのですが (再生などは停止しません。あくまで描画だけです)、ESCキーで処理を停止できるようにしたこともあり、現実的な動作になっているのではないかと思います。
実際には、数万曲が表示されている状況でこの機能をご利用になる方はおられないかもしれませんが、4.6.0で実現した機能が変わらず実現できている、ということだけでもご確認いただけると有難いです。
どうぞよろしくお願いします。
補足です。
添付の例では、赤枠で囲ったトラック03と04が、トラック01/02の影響で、単体曲であるにもかかわらず「昇格」して、コンテンツグルーブの書式で表示されています。その上にある白枠で囲った通常のタイトルとは書式が異なっています。
Attachments:
こんばんわ。
Chartreuxさん、9jgw4yさん、sambacancaoさん、フォローどうもありがとうございます。m(__)m ほんとうに感謝しております。
議論の流れに追従できていなくて心苦しいのですが、取り急ぎ “%_TitleValue%” についてご説明します。「メイン行の書式」の説明部分には
メインとなる行の書式を指定します. メインとなる行には, 通常 %_TitleValue% を含めます. %_TitleValue% を含めると, 楽曲の内容に応じて, この部分が「タイトルカラムの書式」で指定された書式に置換されます.
と書いています。
TuneBrowserの楽曲タイトルは、曲の構成 (=コンテンツグループなどの適用状況) によって、書式が変わります。たとえば、10曲あるトラック構成のうち、3曲にコンテンツグループが適用された場合、残りの7曲はコンテンツグループの3曲との表示上のバランスをとるため、通常のタイトル表示ではなく、単体曲であるもののコンテンツグループの書式で表示されます (内部では「昇格」と呼んでいます)。
その場合、その昇格した7曲は、%_TitleValue%の部分が「タイトルカラムの書式」-「コンテンツグループの表示」で指定した内容で置き換えられて表示されます。
そのため、まぎらわしくて恐縮なのですが、「メイン行の書式」の “%_TitleValue%” のカラムに指定されている書式は実際には活用されず、「タイトルカラムの書式」で指定した書式が適用されることになります。
文章で書くと大変わかりづらいかと思いますが、これが
解決はしたのですが、“[トラック各行の書式]→[メイン行の書式]の位置のFormTitle”はどの部分のスタイルなのでしょうか？色々と弄ってみたのですが、どこも変わった様子がありませんでした…。
のご質問へのお応えになります。つまり、説明文にあるように、ここは単なるプレースホルダで、実際には「タイトルカラムの書式」で指定した書式が適用されることになります。
…以上の説明でご推察いただけるかと思いますが、このあたりはTuneBrowserの設定系でもっとも難しい部分です。答えになっていないとか、やはりわかりづらいとか、なにかありましたらご遠慮なく言っていただければと思います。
どうぞよろしくお願いします。
こんばんわ。あいかわらず、使いこなされていますね。嬉しいです(^^)。
うーん、どうもコンテンツグループには「最適化しない」設定が効いていませんね。Disc 1のほうに効いているように見えるのは、1曲だけ(1.7)ちがうヘッダがついているからですね。
また追って調べます。このあたりの処理はかなり入り組んでいますので、すこし時間をいただくかもしれませんが、よろしくお願いします。
その後いかがでしょうか。1週間 ご発言がないようですので、いったんこのトピックはClosedにさせていただきます。なにかあればまた別のトピックでお願いします。
