フォーラムへの返信
-
投稿
-
こんにちわ。
古いトピックを引っ張り出していただき、ありがとうございます。
このトピックをオープンにしているのは、やらないと決めたわけではない故で、改めて検討中のメモを開いてみました。対象のトラックはいまは当然ハイレゾになろうかと思いますし、サンプルレートに上限を設けると逆に不評を買ってしまいそうなので、相当高いサンプルレートまでサポートすることになります。実際の波形はそんな高いサンプルレートで表示しても仕方がないでしょうし、描画にも時間がかかるので、なにか操作や再生をしている間にバックグラウンドでデコード、リサンプルあるいは間引き、描画用データへの変換といった処理を行うことになります。それでも、たとえばクラシックで30分から最長60分くらいのトラックを想定すると、相当重たい処理になってしまいそうです。5分や10分以内を上限とする、などというのは、サンプルレートの上限と同様に、やはりダメですよね。
わたしがなにか難しく考えすぎているのかもしれないという気もするものの、うまいやり方は依然として思いつけないでいます。なにかネガティブな感じが満載になっていたらすいません。依然として、やらないと決めたわけではありません(笑)。
こんにちわ。
時期や実現はお約束できませんが、将来の機能として検討するようにします。
こんにちわ。ご意見ありがとうございます。
タグの値の自動、半自動処理のニーズはたしかにあるのだろうと思います。挙げられているケースとはすこし異なりますが、わたしもPCで楽曲を管理しはじめたころ、自分のルール (好み) に則ったタグ値に統制していくために、コマンドラインで動作する変換ツールを作り、正規表現などを併用して一括変換を繰り返していました。
そうしたツールの機能をTuneBrowserにも盛り込むことはときどき考えるのですが、検索だけでなく置換まで行ってしまうと、意図しない変換が行われ、さらにその場でそのことに気が付かなかった場合のダメージがきわめて大きく、そのような機能の提供はTuneBrowserのユーザー層を考えるとリスクが高すぎるというところで気持ちが止まってしまっています。
また最近は、Naosさんに紹介いただいたように、わたし自身もテキストエディタを併用する手順が定着していて、たとえば全角/半角が混在している場合や、カッコの統制 (≪≫や《》など) などはそのやり方で賄っています。ただそれも、相応のスキルが必要になってしまいますが…。
冒頭に書きましたが、あるルールに則ってタグの値を加工する機能はあったほうがいいなと思うのですが、その機能を提供するリスクの整理がついていない、という感じです。
ご確認ありがとうございます。
また正常に再生できているにもかかわらず “INV” の表示が出るようでしたら、改めて教えてください。よろしくお願いします。
こんにちわ。
ご利用のドライバにもよりますが、INT:Lはごく一般的なデータ型です。PCM再生の場合は、わたし自身はINT:L以外は見たことがありません。INVは、ツールチップの説明にあったと思いますが無効を示しており、4.17.1.1548までその表示だったということが不思議です…。
データ型は、ASIOの場合はドライバから指定されます。アプリケーションに選択の余地はありません。WASAPIの場合は、アプリケーションから照会することができますが、たいていは選択の余地はありません。ですので、あまり気にされる必要はないかと思います。
データ型によって音質が変わるかどうか、については、わたしは変わらないと思いますが、なにをしても音が変わるのがオーディオですので、変わると言われる方もおられるかもしれません。
さっそくご確認いただき、ありがとうございました。(^^)
こんにちわ。
ご確認ありがとうございました。この設定項目、わたしも間違えましたが、Yes/No逆のほうがいいかもしれませんね(^^;。将来見直すかもしれません。その際には古い設定は引き継ぐようにしますので、ご安心ください。
ありがとうございました。
こんにちわ。
ご報告ありがとうございます。解決してよかったです。
そういう事象もあるのですね…。はじめて聞きました。参考になるご報告ありがとうございました。
すいません、まちがえました。Yes/Noが逆でした。
- 「人名表示の整形指定を無視する」をYesに設定する
でした。
クエリのどの部分を変えるかについては、ちょっと洗い出しや確認に時間がかかりますので、まずは上の設定をお試しいただけますか。
こんばんわ。
TuneBrowserの人名を表すクエリには、
%_PERFORMER,NameInitial% %_PERFORMER,NameFull% %_PERFORMER,NameSingle%など、NameXXXXのオプションがついていることが多く、これらのオプションは人名が “苗字, 名前” として表記されていることを前提しています．そのためカンマの部分で表記が変更されることがあります。
これらの動作を無効にするには、クエリのオプション部分を除去してもらう方法と、設定ダイアログボックスのツリー項目で「表示の設定」「クエリの設定」、右側の項目で「クエリの動作の設定」「人名表示の整形指定を無視する」をNoに設定する方法があります。
お試しください。
こんにちわ。
「Dドライブのミュージックフォルダの中の表示」と言われているのは、エクスプローラーで見たフォルダ名やファイル名のことでしょうか? とすると、変更されるのはタグの値だけなので、フォルダ名やファイル名には反映されません。
こんばんわ。
再生中の曲に自動で追従するのはPlayback Queueだけです。その他のViewは基本的に曲を選ぶためのものですので、ちがうアルバムや曲を探しているときに、再生曲が切り替わって突然Viewの内容が移動してしまうと、かなり不便になると思います。
Playback Queue以外で再生中の曲を探すには、タブの部分で右クリックして「再生アイテムにフォーカスする」を選択するか、そこに表示されているように、「Shift+P」を押します。
ご登録のメールアドレスがPayPalの記録にありましたので、先ほどお送りしました。
ご確認いただければと思います。
なおこの機会に (他の方向けに) すこし補足させていただくと、
ベクターでライセンスキーを入手された場合は、ベクターにライセンスキー再発行サービスがありますので、ベクターのほうにお問い合わせください。
個人情報保護法以降、作者には購入者の情報が開示されないようになり、わたしのほうではどなたが購入されたかがわかりません。マイクロソフトストアで取得された場合は、ライセンスキーはありません。Windowsが自動でライセンス認証しますので、おなじマイクロソフトアカウントをご利用であれば、TuneBrowserを再インストールするだけで、ライセンスが適用されると思います。
よろしくお願いします。
こんばんわ。
ご確認ありがとうございます。そうですね、たしかにPlayback Queueには前回の表示が反映されていませんね。ちょっと、どうするか検討させてください。
こんばんわ。
詳細ありがとうございます。「全体から検索」をチェック(色のついた状態)だと、ライブラリの全体から検索されているかと思います。チェックしていないと(色のついていない状態)、説明いただいたように現在のタブで表示している内容からの絞り込み検索になります。
それと、ショートカットキーについては、がんばってツールチップやメニューにも出るようにしていますので、ぜひ参考にしてみてください。
こんばんわ。
確認してみたところ、バーの高さは固定(選択矩形の1/4)でした…。
色は、「その他の色」のなかの「PlayingBar」です。
よろしくお願いします。
こんばんわ。
4.15.4から4.17.1までの変更内容を確認してみましたが、再生系の動作にかかわるような変更は見当たりませんでした。
TuneBrowserが再生中は、WASAPIの排他モードや排他動作をするタイプのASIOドライバをご利用の場合、当然ですが排他ですから他のアプリケーションからは音は出せなくなります。それがPCを再起動しなければならないというのは、なにか問題が起きているように思いますが、すいませんが現在のところはこれ以上はわかりません。
とりあえず、WASAPIの共有モードでご利用になられてはいかがでしょうか。やり方がわからない場合は、また質問いただけますか。よろしくお願いします。
Ctrl＋Fで検索窓をフォーカスがある状態で出せます、そのまま検索したい文字を入れ、Enterを押せば検索出来ます。
フォーカスとEnterに言及いただいて、ありがとうございます。あたりまえといえばあたりまえの動作なのですが、フォーカスの動きもEnterも作り込んで実現していますので、ちょっと嬉しかったです。(^^;
Naosさん、どうもありがとうございました。(^^)
ご確認いただき、ありがとうございました。
Playback Queueにブロック表示は、盲点でした。Z軸方向の制御をしておらず、たしかにうまく動作しませんね。
Shift+P (再生アイテムにフォーカスする) の操作の確認もありがとうございます。まったく余談ですが、改めて調べてみると、問題を起こしている機能を作った時期と、Shift+Pの機能を作った時期の間には、7年の差がありました。似て非なる機能が2か所にある恰好ですが、ジャケット画像を動かす加加速度(Jerk)が微妙にちがいますので、統合は見送ろうと思います。そのため、近日この処理を修正して、また改めてリリースするようにします。
それから、「隣のジャケットがかぶってしまいます」のご指摘ですが、これもShift+Pの動作との比較でそう見えるのですが、Shift+Pはユーザー操作で動作する処理ですので、アルバムをポップアップして表示させていますが、再生中の自動追従の場合は暗黙に動作する処理ですので、これについては現在の動作のままフォーカスを移動させるだけにしようと思います。
よろしくお願いします。
ご確認ありがとうこざいました。
おはようございます。
Album Viewは (Lyrics Viewなどもそうですが)、描画量が多いため、全体のアニメーション時以外は、毎秒1回の描画に更新頻度を抑制しています。そのため、ご指摘のような動作になります。これは最初のリリース時からそのような動作になっています。
今は静音ケースに入れて封殺しています(^^;
おお、おなじです(^^)。Grow Up JapanのSMART DRIVEで外出しにして、SATA→USB3に変換して、遠くに(^^;置いています。
一度再生した曲を再度再生する場合、ドライブのキャッシュとOSのキャッシュが効きますので、キャッシュにある分は事実上RAMDecode相当の動作になりますね。1曲まるまるキャッシュに乗るかどうかはファイルのサイズ次第ですが、何GBあるメモリに対して100MBのファイルだとしたら、キャッシュに乗る可能性は高そうですね。
HDDかSSDか、という話は、わたし自身は音楽ファイルの格納場所としては容量の関係でHDD一択ですので、聴き比べたことはありません。わたしはHDDの回転音も気になるクチですので、本当はメカ要素のないSSDにできればいいのですが…。
さっそくのご確認ありがとうございます。
趣旨が合っていてよかったです。(^^)
こんにちわ。
先ほど, 4.17.1の先行版を公開しました. ここで議論していた設定は、ツリー項目「表示の設定」「ビューの設定」「Album Viewの設定」の、「Album Viewの設定」「タブの内容を再現する」が該当します.
ご期待の動作になっているかどうか、一抹の不安も(^^;あったりしますので、お時間のあるときにでもお試しいただけると助かります。
よろしくお願いします。
こんにちわ。
2秒については、書かれている通りです。5秒や10秒にした場合、メモリを多めに使う以外にはわたしはデメリットはないと思います。ただ逆に安定再生の確度が高まる以外には、メリットもあまりないと言えます。
なおバッファ長の大小は音質に影響すると言われる方もおられますが、わたし自身はそれを体感したことはありません。
RAMDecodeは再生中はデコードのためのディスクアクセスを完全に止めてしまうので、またちがう意味を持ってきます。
こんばんわ。
Wave形式の場合、内部の処理としては、ファイルから読み込んでデバイス転送用のバッファに設定する行為をデコードと呼んでいます (FLACなどはその間にコーデックによるデコードが入ります)。
つまりデバイス転送用のバッファは存在します。これはデバイス転送の処理とファイル読込みの処理が非同期処理であることと、ディスクの読み込みが一時的に停滞した場合の音切れを防ぐために必要なものとなります。
ありがとうございます。m(__)m
ところで言ったすぐで恐縮なのですが、上部固定したトピック群の表示順は新しい順になるようです。そうするとたいていの場合「感想・雑談」がトップにくることになります。それはちょっとよろしくないような感じなので、すいませんがいったん通常の表示位置に戻します。
先ほど、「感想・雑談」のトピックを上部固定の表示にしてみました。
背中を押していただいてよかったです(^^)。みなさん活発な議論されていて、興味深く拝見しています。トピック中では、TuneBrowserやわたし自身のことについても触れていただいていて有難いかぎりですが、Q&Aのような形になってしまうことを避けるため、わたしからの個々のご発言への応答は差し控えさせていただければと思っています。どうぞご了承ください。
音楽/オーディオ好きとしてはなにかあれば発言させていただきます。
こんにちわ。
ひと晩空いてしまいましたが、「感想・雑談」のトピックを作ってみました。なにかあれば進めながら軌道修正していきたいと思います。よろしくお願いします。
気持ちあります(^^)。ありがとうございます。
フォーラムの部屋を増やすのではなくて、ひとつのトピックでやってみたら、というお話しですよね。それまで思いつきませんでしたが、いいと思います。トピックが長くなると使い勝手がどうなるか、ですが、やってみて考えるということにさせていただければと思います。
わたしの理解がちがっていないようでしたら、わたしが作ったほうがいいと思いますので、そのトピックを作りますね。
ご確認ありがとうございました。
わたしが目撃した状況と同じようですね。トラック一覧形式ではないのに、トラック位置にスクロールしようとして結果として関係のないところにスクロールしてしまうようです。
次回リリースまでに改善したいと思います。ありがとうございました。
こんにちわ。
「表示が追従しません」というよりは、トラックが表示されていない状態では、追従しようとして変なところにスクロールしているような感じでしょうか? まだ原因は掴めませんが、そのような状況は起きる問題はありそうです。
「表示が追従しません」がまったく表示が動かないようであれば、別の問題かもしれません。
こんにちわ。
Crawlerが自動で登録したというよりは、TuneBrowserにエクスプローラーからフォルダをドロップしたとか、そういった意図しない操作があったのかもしれませんね。了解しました。
こんにちわ。やはり再現方法させることができません..。
すでにお試しになられたかと思いますが、Tree Viewの “\\xxxNAS\Music” を右クリック、「データベースからの削除」を選択して、いちどデータベースから削除して、TuneBrowserを再起動させたときに、やはりその下の全フォルダのファイルが登録されてしまう感じでしょうか?
88.2kHz、176.4kHzは、クロックが別に必要になるようで、対応していない機器は意外とあるようです。
クローズの件、了解しました。
こんばんわ。
44.1kHzのBase x4=176.4kHzですが、ご利用のONKYO GX-500HDは、このサンプルレートに対応していないのではないでしょうか?
なるほど、了解しました。
NAS上でまったくおなじフォルダー構成を作って試してみたのですが、やはり現象は再現できませんでした…。
またなにかお気づきのことがあればお知らせいただけると有難いです。
関係ないかもしれませんが、上げていただいたスクリーンショットでは、\\とNASの間にスペースがあります。これについてなにかお心当たりはありませんか?
ありがとうございます。
プレイリストに関しては、プレイリストに登録されている(ほかのフォルダの)ファイルが登録されるだけで、そのほかのフォルダのすべてのファイルが登録されるわけではありません。
つけていただいたスクリーンショットを見ると、そういう程度ではなさそうですね。引き続き、調べてみます。
こんにちわ。
まず、TuneBrowserを長きに渡ってご利用いただきありがとうございます。別項での起動時間が長くなったのでは、という話もありますが、できることなら以前よりも良くなりたいと思いながら何とか開発をつづけてこられたのもChartreuxさんはじめ皆さんのご協力のおかげです。当人は開発中はともすれば「木を見て森を見ず」という状態になる可能性もありますので、今後もお気づきのことがあればお知らせいただけると有難いです。
それで、AVX2版の音質のお話し、興味深い話題をありがとうございます。わたし自身もAVX2版をリリースしたときには、これは画期的改善と思っていました。「画期的改善」というのは、かならずしも音質に直結したことではありませんが…。
音楽再生ソフトウェアによる音質差については、明確な音質的意図をもって開発されている方もおられるようですが、わたし自身はそのような音質操作に関する意図的なことは行っていません。先日「”TuneBrowserは高域を操作している” と断じている人がいる」と教えてくれた方がおられましたが、そういう話があるとしたらそれはまったくのデマ情報で、TuneBrowserはそのような操作は行っていません。
高域を操作していることはないのですが、結果として高域がきれいに、あるいは澄んで聴こえるということはあり得る話かもとは思います。TuneBrowserの再生系の処理でわたしがとくに注意を払っているのは、データの精度とCPUの負荷です。前者は言うまでもないと思います。後者は (ここから先のハードウェアのことはわたしは素人なのであくまでもわたしの理解ですが)、結果としてPCに何らかの形でつながっている機器のGNDに影響しているのだろうと思っています。AVX2は、その部分に影響を与えていると考えられます。ただ、その影響は、たとえばPC (Windows) の設定で、省電力のためのクロック変動を許容しているのかいないのか、メモリのスワップを起こしているのかいないのか、といった環境要因で埋もれてしまう可能性もあるかもしれません。
最近、別のトピックでリサンプラ―の音質の良し悪しについてのご質問があり、そこでは「良いか良くないかではなく、好きか好きでないか」だと思う旨お応えしました。リサンプラ―についてはいまはそう思っています。AVX2適用はじめTuneBrowserで日々やっている改良は、どちらかというとその逆で「好きか好きでないかではなく、良いか良くないか」であり、データの精度にしてもCPU負荷にしても、良いと思ってやっています。ただその結果として出てきた音を、好きか好きでないかという話はあって当然です。仮に高域に気づきがあるような音に聴こえたとして、オーディオ関係で高域と言えばわたしが思いつくのはB&Wのダイヤモンドツィータ、アキュフェーズのアンプ、ロジウムメッキといった話で、どれも賛否両論です (くり返しますが、TuneBrowserがそういう音を出すというわけではありません)。
ちょっとズレたような話をしてしまったとしたらすいません。また、CPU負荷と言いながら描画を派手めにしてるじゃないか、というご指摘もあるかもしれませんが、そこはまあ趣味、楽しみのための道具ということで。(^^;
こんにちわ。
ありがとうございます。ログからは、やはりご指定になったフォルダだけを読み込んでいるように見えますね。
フォルダーツリーは、ルートから表示されるようになっています。「すべてのファイル」と言われていましたが、\\NAS\Music\の下に登録された以外のすべてのフォルダが表示されているのでしょうか。
あと、「すべてのファイル」にはならないと思うのですが、プレイリストに他のフォルダのファイルが登録されている場合、そのプレイリストを表示させると、他のフォルダのファイルも登録してから表示します。
ありがとうございます。
先頭にスクロールした状態で表示されますので、1枚目の画像の動作になります。
起動時間についてはわたしも気にしていて、TuneBrowserは毎回自分の起動時間を計測しています。大きな改修の合間に、ときどきそれを調べては改善できる箇所がないか確認しているのですが、数ミリ秒とか(^^;、そういう改善の積み重ねになることが多いです。
起動速度の改善については、ご利用の状況によってはデータベースへの集中アクセスが劇的に削減されますので、程度の差はあっても寄与していると思います。
起動時間については、Per Monitor DPIへの対応を行ったときに起動時のリソースの調整量がかなり増えて、それでひとつひとつのウィンドウ (メニューやツールバーなども含みます) の初期化がすこしずつ重たくなり、全体として起動が遅くなった面があります。今回のリリースで96DPI (大半の方がその環境だと思います) 向けに処理を軽くする処置をして、ひょっとしたらそれも効いているかもしれません。
タブの状態を再現しない際のどこにもフォーカスがないというのはどういう意味になるのでしょうか？プレイリストの1曲目で読み込まれるということでしょうか？
すいません、「プレイリストの1曲目で読み込まれる」という動作がどのようなことを言われているのか、掴めませんでした。その状態でキーボード操作を行うと1曲目にフォーカスがあったかのように振舞います。マウスでクリックすると、当然、そのクリックしたトラックにフォーカスが設定されます。
使い勝手の件、ご確認いただきありがとうございます。
こんにちわ。
念のため動作を確認してみたのですが、通常のクロールでは指定したフォルダ以下のファイルしか読んでいないようでした。
よろしければログをアップしていただけないでしょうか。TuneBrowserを起動して、しばらくするとQuick Crawlが動作します。環境にもよりますが1分程度待っていただいて、
TuneBrowser上部のメニューから「表示」「ドッキングウィンドウ」「Log View」を選択いただくと、TuneBrowserの下部にLog Viewが表示されます。そのViewの下のほうにいくつかタブが並んでいますので「Crawler(Periodic)」選択してください。
ログはたくさん表示されているかもしれませんが、最初の20行くらいで結構です。このログはマウスで選択、右クリックでコピーなどができます。
よろしくお願いします。
ご確認ありがとうございました。
こんばんわ。
gif画像、どうもありがとうございました。おかげさまで、いまさらなのですが、データベースプレイリスト保存時の不具合を見つけました。長いあいだこの仕様で動作していて不具合と言えるのか、という話もありますが、すくなくともわたしの意図とはちがっていました。
プレイリストとタブの状態は本来は別のもので、プレイリストは基本的にはトラックのリスト、タブの状態は表示形式やフォーカス位置といった属性的な情報になります。両者は別の情報として管理しているのですが、データベースプレイリストに対して「上書き保存」を行うと、意図せずプレイリストにタブの状態も含めて保存してしまうようになっていました。
その結果、起動時にタブの状態を読み込み、その後 (時間がかかる場合があるので) プレイリストの内容を遅延読込みした際、プレイリストにもタブの状態が書かれていたため、あらかじめ読み込んでいたタブの状態を上書きしてしまう結果になっていました。そのため、一度上書き保存したデータベースプレイリストは、その後タブの状態が変化しても、上書き保存したときのタブの状態が再現される結果になっていました。
廃止する機能の動作について長々とご説明したのは、これが内蔵プレイリストファイルになると、将来「タブの状態を再現する/しない」オプションを設けて「しない」設定にしたとしても、今回のデータベースプレイリストのような動作にはならないためです。プレイリストファイルにはタブの状態は保存されないので、結果としてどこにもフォーカスがない状態でロードされるようになります。
もしこの動作について、なにかご意見があれば、お聞かせいただけないでしょうか。よろしくお願いします。
もうひとつご質問がありましたね。できればひとつのトピックでひとつの話題でお願いします。
アップサンプリングの効能そのものは、わたしは、音質が良いかどうかというよりは、好みか好みでないかという話だと思っています。以前にも書きましたが、音のエッジが立っていると感じるほうが良いのか、あるいは滑らかなほうが良いのか、これを一概にどちらが良いと断じることはできないと思うので、それと同じような話です。
こんばんわ。
まず、内蔵プレイリストファイルのフォルダは、ご希望のフォルダに変更することができます。設定ダイアログボックスのツリー項目「基本の設定」「詳細の設定」、右側の項目「内部フォルダ」「内部プレイリストファイルのフォルダ」(いちばん上の項目) です。
この項目の説明にあるように、ここでフォルダを指定すると、そのフォルダ内のファイルはアンインストール時には削除されませんので、ご留意ください。
TuneBrowserが内部で使用しているフォルダは、デスクトップ版の場合、以下の要領で確認することができます (UWP版はUWPの制約上アクセスすることはできません)。
Tree Viewの表示を「プレイリスト」にして、内部プレイリストファイルを選択し、右クリック、メニューから「エクスプローラーで開く」を選択します。そうすると、エクスプローラーでプレイリストファイルが表示されます。
また、「ファイル」メニューから「設定関係の操作」「設定のバックアップ」でバックアップすることもできます。ただデータベースなどほかの情報とまとめてひとつのファイルにしてしまいますので、プレイリストファイルだけに着目すると、あまり使い勝手はよくないかもしれません。
別のフォルダに置いたプレイリストファイルをTuneBrowserに認識させるには、そのプレイリストファイルをエクスプローラーからTuneBrowserにドロップすると、そのままプレイリストファイルとしてご利用いただけます。
また上でご説明した内部で使用しているフォルダにプレイリストファイルを置いておくと、内蔵プレイリストファイルとして認識します。
こんばんわ。
お手数をおかけしています。
データベースプレイリストと内蔵プレイリストファイルで、動作に差が出ているとは認識していませんでした。それで、改めてデータベースプレイリストを作って確認してみたのですが、わたしのところではやはり前回終了時のフォーカス位置 (とViewの表示形式) が再現されているようでした。
もしかしたらわたしが理解している事象が異なっているのかもしれない、という一抹の不安はあるのですが、設定の追加で解決できると思いますので、それはそれで進めますね。
タイトルの件は、上記のような次第で、とりあえずそのままにしておこうと思います。AVX2の件は考えてみます。
こんばんわ。
過去にこの設定を修正した記憶がありません。以前のバージョンは何もせずに切り替わってませんでしたか？
このフォーラムの類似の議論を拾ってみると、以下のようなものがありました。
https://tunebrowser.tikisoft.net/forums/topic/1071/
https://tunebrowser.tikisoft.net/forums/topic/2350/古いものは2017年末ですので、すくなくともそのころから現在の動作をしていたと思います。
以前、別のところだったか、「いつのまにかTuneBrowserの設定が変わっていた」という話を見かけたことがあります。そのためなにか設定の保持に問題があるのだろうかと調べてみたりもしたのですが、現在のところ問題のありそうなところは見つかりませんでした。
私としてはNo/Noの組み合わせが好みなのでこの設定で使用したいと思います。この設定を使用する上で注意点があれば教えて下さい。
とくに問題はないと思います。もともとトラックの切替り時の暗転アニメーションはちょっとうるさいかなと思い、アルバムがおなじであるかぎりはアニメーションさせず、表示を継続させるようにしています。その「ちょっとうるさいかな」というところくらいです。
こんばんわ。
ご指摘のポイントを正しく掴めていないかもしれませんが、まず「再生対象曲を保存する」設定は、起動後にPlayer Viewに表示される曲の情報が対象になります。この設定をNoにしていると、起動後のPlayer Viewは空の状態になっていると思います。
それとはべつに、起動後のAlbum Viewの各タブの内容は、前回終了時のフォーカスのあったトラック情報を再現するようになっています (4.11.0からその動作になっています)。おそらくこの機能がご指摘の挙動を示しているのではないかと思います。
改めて調べてみましたが、残念ながらこの動作をオフにするような設定は盛り込んでいませんでした。次のリリースはまだ未定で、すこし先になるかもしれませんが、この動作をオフにする設定の追加を検討したいと思います。
もし外していたらすいません。
こんにちわ。
関係する設定としては、設定ダイアログボックスのツリー項目「表示の設定」「ビューの設定」「Player Viewの設定」、右側の項目「トラックの切替りの設定」「可能ならジャケット画像を継承する」が該当します。ここをNoに設定してみてください。
このコメントを書くにあたっていちおう動作を確認しましたが、それでも動作がおかしいようであれば、またご連絡いただけますか。よろしくお願いします。
こんにちわ。
後ほど、ご登録のメールアドレスに情報をお送りさせていただきますが、最近はPayPalは銀行振込にも対応しています。よろしければそちらのご利用もご検討ください。
もう聞き飽きたと思うが、すばらしいソフトですね。ありがとう。
聞き飽きたなどということはありません。何回言われても嬉しいものです。ありがとうございます。
了解しました。どうもありがとうございます。(^^)
こんばんわ。
伺った状況だとイメージキャッシュがうまく動作していないような状況になっていたのかと思いますが、すいませんが、現在のところどうしてそのような状況になったのか、思い当たる点がありません…。
ひとつのアルバムに対して書かれているような操作を行った結果、ほかのアルバムも正常に動作するようになったような感じでしょうか?
こんばんわ。
言われているのは、「デスクトップ表示」と呼んでいるものでしょうか。そうであれば、これはすべてのマウスの操作を透過して、「前面壁紙」のように振舞いますので、操作はできません。
これの表示場所を変える場合は、設定ダイアログボックスのツリー項目「表示の設定」「ビューの設定」「Player Viewの設定」「デスクトップ表示の設定」、右側の項目「表示する位置」「表示位置」などで指定することができます。
BMMNJIMさん、Andrewさん、
早々のご確認ありがとうございました。助かりました。(^^)
またなにかお気づきのことがありましたら、ぜひお知らせください。
すいません、ありがとうございます。m(__)m
ご確認ありがとうございました。
ご確認いただき、ありがとうございました。
(先ほど、さらに別のご指摘があって、1547を再リリースいたしました…)
こんばんわ。
ご指摘ありがとうございます。たしかに空文字に対する変換動作ができなくなっていました。すでにクエリの工夫で対処されたとのことでお手数をおかけしましたが、この問題に対応した4.17.0.1547を先ほど公開しましたので、ご報告しておきます。
もしよろしければ、お試しいただけると助かります。
こんにちわ。
Mp3tagがAlbum Artistにどのようなタグを使用しているかわからないのですが、ReplayGainをタグ情報として書き込むときに、TuneBrowserは”ALBUM ARTIST”タグを使用してAlbum Artistを書き込みますので、その影響かもしれません (世の中にALBUM ARTISTではなくALBUMARTISTを使用するアプリケーションも多々あります)。
設定ダイアログボックスのツリー項目「タグの設定」「タグ名の扱い」、右側の項目の「ALBUM ARTIST」を項目を選択していただいて、ダイアログボックス下部の「削除」ボタンでその項目を削除してみてください。
なおTuneBrowserは、Album Artistの読み込みについては、ALBUM ARTISTとALBUMARTISTの両方に対応しています。
また (ついでのようで恐縮ですが)、もし他の方でもALBUM ARTISTではなくALBUMARTISTを標準にすべきでは、というご意見と根拠をお持ちの方がおられましたら、これを機会にお知らせいただれば有難いです。わたし自身はどちらのタグを使用すべきいう強い意見はなく、これまでの経験でよく見かけるという印象のあるほうをTuneBrowserの標準にしています。
おはようございます。
ご確認いただき、ありがとうございました。「ディスク上のファイルの削除」は見逃していましたので助かりました。またなにかお気づきのことがありましたら、よろしくお願いします。
serenityさん、ご確認いただき、ありがとうございました。
情報ありがとうございます。
TuneBrowserはAACやMP3など不可逆圧縮形式のビット数は0にしています (正確には2015年の2.2.4以降そのようにしています。また実際のデコード時には32bit floatでデコードしています)。そのため、ご利用のクエリの場合は、以前から0bitと表示されていたのではないでしょうか。
今回問題の出ていたクエリは、
$IF(%X_BITS,NonZero%,%X_BITS%bit,%_KBPS%kbps)のような形式で「X_BITSの値が0だったら(0以外だったら)」という判定がうまく動作しなくなっていたというもので、その対策を行っています。
まだクエリに問題が残っている可能性はありますが、いただいた情報からはそのように読み取れました。
Hi,
I like ASIO if it works well. ASIO seems simple and light, instead, somtimes it causes problems depending on the environment. WASAPI is official part of Windows, all drivers are supporting WASAPI and (perhaps ) running stably.
こんばんわ。
TuneBrowserの既定の設定では、不可逆圧縮の場合ビットレート、可逆圧縮の場合ビット数というかたちで表示が切り替わるようになっているのですが、serenityさんの環境ではつねに両方が出るようにカスタマイズされていますね。2つめのAACのトラックでは、それまでのバージョンでは0bitの部分にはどのような情報が表示されるようにされていたのでしょうか?
もしご面倒でなければその部分のクエリも教えていただければと思います。
よろしくお願いします。
こんばんわ。
先ほどリリースした4.17.0.1546で、ファイルの削除を操作した挙動については改善できているのではないかと思います。もうひとつご指摘いただいていた、TuneBrowserが動作していない状態での内部プレイリストファイルの操作(追加/削除)については、その検出はCrawlerで行っており、わたしの環境ではしばらく待っていると検出できているようでした。
CrawlerはTuneBrowserの起動後、すこし落ち着いてから動作をはじめるようになっているので、動作開始までしばらく時間がかかります。今回のリリースでは、いちおう内部プレイリストファイルのフォルダを最初に確認するように変更してみました。
どうぞよろしくお願いします。
こんばんわ。
さっそくのご確認、ありがとうございました。バックアップの問題と合わせて、生成するファイル名のルールを変更していますが、バックアップとしてはこれで解決したかなと思います。
こんばんわ。
ご理解いただきありがとうございます。こちらこそよろしくお願いします。
こんばんわ。
ファイルが検出されたら、暗黙にReplayGainの計算を行う… ということで考えてみましたが、ReplayGainの計算単位で課題が出そうです。ReplayGainの計算はたいていはアルバム単位でないと意味がないと思うのですが、アルバム単位でのファイルコピーはストレージの位置によって要する時間がまちまちでしょうし、それが録音に使用されていたとしたら、数分、数時間になるかもしれません。
そういったケースを考慮しながら、いつが終わりなのかわからない複数のファイルの検出をまとめて自動で処理するには、あまりスマートにはできそうにありません。結局、人間が終わりを認めて手動で処理してもらうのが確実簡単で良い、ということになるかもしれません。
やらないと決めたわけではありませんが、ご利用になる環境によって課題を引きずる機能になりそうな感じです。
こんばんわ。
ご指摘ありがとうございます。現象を確認したところ、バックアップ用にzip圧縮をかける処理内でWindows APIを呼び出す際に、長いファイル名への対処が不足しているところがありました。
この問題そのものは対処は難しくはなく、ほかの処理でやっているようなファイル名の長さ制限を緩和する方法 (=無制限ではなく最大32,767文字になります) でWindows APIを呼び出すように変えればよいのですが、それはそれとして、現在プレイリスト名の長さに制限をかけていないことは問題のような気がしてきました。ファイルシステムやOSの設定によっては保存そのものもできないかもしれません。
長さに制限を持たせるようにした場合、どこで切るかについてちょっと考えなければならないですが、あまり長いプレイリスト名というのも現実的ではないように思うので、長さ制限をつけさせていただく方向で検討したいと思います。
Chartreuxさん、おひさしぶりです。試していただいて、ありがとうございます。助かります。
ご指摘いただいた2点については、考慮が不足していました。バックアップとの併用も考慮して、どうするか検討したいと思います。
こんばんわ。
さっそくご確認いただき、ありがとうございました。またお気遣いいただきありがとうございます。m(__)m
こんばんわ。
ご確認いただき、ありがとうございました。また多くの例を試していただき、驚きました。結構いけるものですね…。
ご提示いただいた例をTuneBrowserに取り込ませていただこうかとも思ったのですが、検索サービスの提供を生業としているわけではない他社さんのサイトを利用させていただくのは、問題があるかもしれません。そのため、TuneBrowserのデフォルトの設定としては現在のもののままにさせていただこうと思います。ご了承ください。
こんばんわ。
ご指摘ありがとうございます。クエリの動作を変えたときに、あるケースでの長さ0の文字列の扱いをしくじったようです。現象確認できましたので、次のリリース時に改善するようにします。
こんばんわ。
できれば、1つか2つだけでも試してみていただけませんか?
こんにちわ。
お気づきかと思いますが、4.17.0でデータベースプレイリストのファイル化 (内部プレイリストファイルと呼びます) を行っています。内部プレイリストファイルは、Tree Viewのプレイリスト表示でアイコンから見分けることができます。ここで内部プレイリストファイルを右クリックして「エクスプローラーで開く」を選択いただくと、(デスクトップ版の場合は) ファイルが格納されているフォルダにアクセスすることができます。
このフォルダは設定で任意のフォルダに変更することもできます。
プレイリストファイルの拡張子は専用のtbplになっていますが、形式はm3u8と同じです。tbplではなくm3u8でもよかったのですが、Tree Viewにプレイリスト名を表示するときに拡張子を表示しないようにして、データベースプレイリストのときと互換性を持たせるために、専用の拡張子を導入しました。
更新履歴のところにも書いた通り、現在のバージョンではデータベースプレイリストから内部プレイリストファイルへの自動変換は行いません。データベースプレイリストをAlbum Viewに表示した状態で、Ctrl+Sなどで保存していただくと、内部プレイリストファイルとして保存されるようになっています。
よろしくお願いします。
Hi,
I have added “Play next” function in 4.17.0 (now this version is preliminary release). You can do it by clicking right button of mouse on the track, and select “Play next” in the context menu. This operation is only available during play.
Thanks.
こんにちわ。
昨日公開した4.17.0の先行版でこの問題を改善していますので、ご報告しておきます。
こんにちわ。
公開した4.17.0の先行版で、インターネット検索を見直しました。このバージョンからgoogle以外にbing/baiduを指定できるようにしています。あわせて、一定のURLパラメータの範疇であればカスタマイズできるようになりましたが、タワーレコードに対応できるかどうかは、すいませんが試せていません。
こんばんわ。
情報ありがとうございます。
Hi,
Thank you for response (^^).
And also thank you for your suggestion. I’d consider it for a future release.
Thanks again.
Hi,
Thank you for your confirmation. It’s nice to hear your “Perfect!” (^^)
Now I can clearly see TRACKS from Albums I have never played (or played).
Have you achieved your goal? “All Tracks”/”Some Tracks” classfication is still difficult. It may be impossible with current TuneBrowser function.
こんにちわ。
ご確認いただきありがとうございました。うまく動作したようでよかったです。
Compilation系のタグの取扱いについては、以前もどこかで問題になったような記憶があったこと、その回避策として、今回やっていただいたような動的タグの設定を変更する必要がある (=わかりにくい) ことから、見直したほうがいいのかなと思い、他の方のご意見も伺ってみたいと考えました。
ただkotoni22さんに書いていただいたように、今回の設定変更が難解だとお感じにならなかったようで、すこし安心しました。
ご意見ありがとうございました。
Hi Andrew,
Thank you for interesting question. To class tracks played/unplayed, use this query as Tree query:
$IFMATCH(%X_PLAYCOUNT,INT%,0,Unplayed,Played)\%ALBUM%Last of “,Played” argument is optinal.
The next step, “All Tracks” / “Some Tracks” classing is difficult(^^;. I have no idea to present it now…
By the way, I have published TuneBrowser Help pages in my site recently.
I have many sorries about it (^o^; like
- Japanese only. Please use external translation system like Google Translate.
- Some contents are not updated.
- It’s not useful as web pages. (Converted mechanically from manuscripts of help file)
But, if you have interest and time, please see above URL.
Regards.
こんにちわ。
ゾーンなど、ご使用の言葉が正しく理解できていないかもしれませんが、ご指摘の内容としてはCompilation (ITUNESCOMPILATION) の扱いが強すぎるということだと理解しました。
設定画面の「タグの設定」「動的タグ」ツリー内の、
- 別名タグ – _GRPARTIST
- 結合タグ – _CARTIST
の定義の冒頭に、「_COMPILATION」の指定が行われています。これによって、Artist系のタグよりもCompilationの定義のほうが優先される結果になっています。
それぞれの定義の部分から「_COMPILATION; 」の部分を削除してみてください。
Compilation系タグの適用については、以前メールで応対していたときに、かなり強く主張された方がおられて、わたし自身はまったく使わないこともあって「そういうものか」と思い、現在の定義のようにした経緯があります。もし混乱を招いているようでしたら、標準の定義を見直すことも検討します。ただその場合は、Compilation系タグを積極的にご利用の他の方のご意見も伺ってみたいです。
よろしくお願いします。
こんにちわ。
Wine環境での動作は、試したことがないのでわかりません。わたしは本業ではLinuxとWindows両方のソフトウェア開発をやってきましたが、もともとTuneBrowserはWindowsの特性をできるだけ引き出すことを念頭に開発しているので、将来的にもLinuxネイティブに動作させる予定はありません (以前はそういう互換性も意識しながらソースコードを書いていたのですが、互換性を重視するとどうしてもプラットフォーム特有の長所は引き出しにくくなるので、性能や機能を何年も追い込んでいるうちに、互換性の優先度は下げざるを得なくなりました)。
それと、TuneBrowserはオープンソースではありません。
あまりいい返信でなく恐縮ですが、ご了承ください。
Hi,
Ah… I understand what you’re saying. That’s right.
Unfortunately, it’s not easy to get TuneBrowser to work the way you expect. Because currently, TuneBrowser rebuild playback order when playback queue was modified in random mode.
Please give me a while (days, weeks or months…) to consider what should I do.
Regards