フォーラムへの返信
-
投稿
-
Thank you for your confirmation. (^^)
こんばんわ、ご連絡ありがとうございます。
たしかにトラック順に問題があるようです。引き続き調べますね。取り急ぎ。
こんばんわ。
ご連絡ありがとうございます。まずは正常に動作するようになってよかったです。
原因については明確になりませんでしたが、設定ファイル次第ではTuneBrowserではタグの形式毎にどのようにタグを使用するか指定したりすることもできます。ひょっとしたら、そうした設定が邪魔していたのかもしれません。
Hi,
Then you have to setup channel assign of ASIO driver in TuneBrowser. See screenshot below.
Hi,
Sorry, but TuneBrowser is supporting multi-channel playback with ASIO driver only…
こんにちわ。
確認してみたところ、プロバディとして表示したときに、タグとしてRATING 1が設定されていることが見えました。以下の図のいちばん下の部分のです。この表示がないということでしょうか?
ありがとうございます。
TuneBrowserのスクリーンショットは、確認してみると、ファイル名順になっていますね。
Tree Viewは「フォルダーツリー」をご利用ではないでしょうか。その場合、トラックは特別なトラックソートクエリの指定によりファイル名順になるようになっています。そのせいではないかと思うのですか…。
これは不思議な順番ですね。どうしてこのような順になっているのか、いまは見当がつきません。
ちなみに、右クリックからプロパティで見ると、トラック番号はきちんと見えているのでしょうか?
またファイル名はトラック名でしょうか?
Naosさん、さっそくありがとうございました。
すぐに送っていただきながら恐縮ですが、中を見れるのは明日(以降)になりそうですのでご了承ください。
こんにちわ。
Naosさん、問題の出ているMP3ファイルをひとつ、お送りいただけないでしょうか。
この後、ご登録のメールアドレスにファイルのアップロード方法をお送りさせていただきます。送っていただいたファイルは、検証目的以外には使用しません。
お時間のあるときで結構です。どうぞよろしくお願いします。
こんばんわ。
わたしのところでも改めて試してみたところ、ちゃんと動作しているように見えました。表面上の動作だけであまり内部の確認まではできていないのですが、取り急ぎご報告します。
ご確認ありがとうございました。
このトピックはいったんここで閉じさせていただこうと思いますが、ミニプレイヤーを大きく表示する動作については、今後 (だいぶ先だと思いますが…) また考えてみたいと思います。
ご確認ありがとうございました。
お忙しいところご確認ありがとうございました。
おかげさまでひとつ不可解な動作が減らせて、よかったです(^^)。
こんにちわ。TuneBrowserのご利用ありがとうございます。
ISOファイルについては、近年あまり利用されなくなっていると思いますので、現在のところサポートする計画はありません。
64ビット音源については、すいませんが具体的なフォーマットの情報を持ち合わせておらず、こちらも現在はサポートする計画はありません。デバイス側のビット幅が大きくても32ビットという状況でどれほどの意味があるのか…。その後の加工を考慮した音源制作用のマスターなどであれば意味があるのかもしれませんが、その場合でも、再生用には32ビットのフォーマットで流通するものではないのでしょうか。
ありがとうございます。この件については、ご確認いただくことは必須ではありませんので、どうぞ無理をされないようにお願いします。
こんばんわ。
先日公開した4.17.2の先行版で、1000ms上限だったパラメータを7000ms上限に変更しています。よろしければお試しください。
こんばんわ。
もう試していただくような状況ではないかもしれませんが、ここでご指摘いただいた問題点を4.17.2の先行版で改善しています。もしよろしければお試しください。
P.S. タイトルを変更させていただきました。
Chartreuxさん、フォローありがとうございました。
こんばんわ。
右クリックからの操作は、複数のトラックに対して行うことができます。Ctrl+クリックで複数トラックを選択したり、ジャケット画像をクリックしてアルバムを選択したり、Tree Viewのノードの右クリックからも操作できます。
お試しください。
こんばんわ。
スペクトルの高さについては、最大高さを絶対値で指定できるようになっていますので、お試しください。
こんばんわ。
変更履歴には漠然としか書きませんでしたが、Player Viewの表示に関して以下の変更を加えています。
- これまでは600DIP(≒ドット)を画像の最大サイズに制限していましたが、Player Viewではその制限を撤廃しています。
- 表示のバランスを維持するために、ウィンドウ幅の25%までという制限がありますが、これを設定で変更できるようにしています。表示の設定の「プレイヤー表示」の項目内に、「ウィンドウ幅に対するイメージの最大高さ (%)」がそれです。
- スペクトル表示の最大高さを指定できるようにしています。表示の設定の「スペクトル表示の設定」の項目内に、「高さの最大値」がそれです。
これらの設定項目を変えたとしても、ひょっとしたらご要望の表示にはならないかもしれませんが、お知らせしておきます。
あと、トラックの表示とプレイリストイメージの表示は、重ねて表示することはできません。ご了承ください。
さっそくご確認いただき、ありがとうございました。
こんばんわ。
TuneBrowserでの変換は外部のツールを指定することができます。その場合、ソースの形式→Wave→目的の形式という手順になりますので、WaveファイルをAIFFに変換するツールがあれば、ご利用いただけます。
すいませんがAIFFについては詳しくなく、具体的なツールについてはわかりません。他の方でお詳しい方がおられるといいのですが…。
こんばんわ。
最小化時の動作などは、WindowsというOSの基本的な約束事に準拠して動作していますので、たしかに書かれているような動作になりますね。その基本的な約束事も最近はあまり細かくなくなっているような気がしますが、本当に一時的にTuneBrowserを隠したくて最小化する場合もあるでしょうから、やっぱりいまの動作が良いように思います。
こんばんわ。
興味深いお話しありがとうございます。ミニプレイヤーを大きく表示して使うということは考えていませんでした。いまは手がつけられませんが、将来すこし検討してみますね。
①の件は、たしかに画像のサイズを制限していたと思います。②については、横にプレイリストイメージが表示されているからですね。プレイリストイメージは文字列なので、その上にトラックの再生時間などが重なると見にくいので、重ならないようにしています。
こんにちわ。ご報告ありがとうございます。
試してみているのですが、再現ぽいことができたのは、以下のケースでした。
- タブA について、名前の変更で新しいプレイリスト名Bを指定する。
- タブBになったあとで、Ctrl+Sなどで保存を行うと、古いAの名前で保存されてしまう。
ウムラウトのついた文字があると問題があるとのことでしたが、ウムラウトがついた文字でも、上記以外は問題なさそうでした。「Emil Grigoryevich Gilels」と保存されたのは、上記のケースということはないでしょうか?
上記の事象は問題ですので、次のリリース時に改善します。次のリリースは機能追加版の4.18を予定していましたが、ちょっと時間がかかりそうなのと、ほかの件もあるので、上記の改善も含めた4.17.2にするかもしれません。
こんばんわ。
情報ありがとうございます。サンプルレートはトラック毎に変わっているわけではないと理解しました…。
マランツさんのご指摘含め、またなにか情報がありましたら、よろしくお願いします。
こんばんわ。
情報ありがとうございます。ただこれは… どう捉えたらよいか、もうひとつわからないですね…。トラック毎にサンプルレートやチャンネル数がちがうとか、そういったことではないですよね。
引き続き、もしなにか情報があれば、教えていただけると有難いです。よろしくお願いします。
こんばんわ。
なにか解決の方法があるといいのですが… 上でご紹介した無音送出やウェイト時間は、あるメーカーさんからノイズ対策の相談をいただいたときに数msから数百msくらいのタイミング調整用として用意したもので (TuneBrowserは再生デバイスが特定の機種名の場合、そのメーカーさんと決めたプリセット値が適用されるようになっています)、秒単位を超えるような用途は想定していませんでした。
時期はお約束できないのですが、次のリリースで上限を5000msあたりまで延ばせるようにしてみましょうか。このあたりのウェイトは上に書いたような経緯から短時間を想定しているので、その間処理をブロックします (自動無音再生のほうは、その名の通り通常の再生と同様に無音を流すだけでブロックはしません)。ですので、あまり無制限に設定できるようにすることは避けたいです。
こんにちわ。ご確認いただきありがとうございます。
前向きに捉えていただいた(^^;上で、問題が改善してよかったです。
TuneBrowserの動作のほうについては、その後確認をしていて、これがトラックではなくアルバム(ジャケット画像)を選択していた場合は、今回のようなケースではアルバムを起点にn曲を使用するようになっていました。ですので、トラックが選択されていた場合でも、そのアルバムが選択されていたと見なすような動作に変えようと思います。
ありがとうございました。
説明を端折ってしまってすいません。
設定ダイアログボックスのツリー項目「再生の設定」「WASAPIの設定」「(ご利用のデバイス名)」、右側の項目で下のほうに「自動無音送出」と「ウェイト時間」があります。
HDMIでご利用とのことからWASAPIかと想像しましたが、もしASIOでしたら「ASIOの設定」の下に同様にデバイス名の設定項目があります。
ご確認、ありがとうございました。
こんばんわ。
改めて動作を確認してみましたが、再生中に次の曲の再生操作を行った場合でも、指定した時間 (この場合3000ms) はきちんと無音のPCMデータを送出していました。
「再生中に次の曲の再生」の際には、一度デバイスを止めて、改めてデバイスを開始させる動作を行うのですが、その間隔が短いと、なにかAVアンプ側の準備が間に合わないのでしょうかね…。
TuneBrowserでは、デバイスごとに、開始後/停止前の無音送出、あるいは開始前/停止後のウェイト(これは無音送出ではありません) なども指定することができます。このあたりの調整してみるという手もあるかもしれません。
設定場所がわからなかったら、また質問していただけますか。
こんばんわ。
その曲の再生途中に他の曲をダブルクリックして再生しますとおなじく3秒のカウントダウンになるのは通常のことなのですが出てくる曲の音の頭が切れてしまいます。
3秒の無音再生が行われた後、頭欠けして再生されるということでしょうか?
こんばんわ。
MP4の形式の場合、あらかじめ書き込めるタグが決まっていますので、PROVIDERタグのような、アプリケーションが独自に定義したタグは書き込めないようになっています。細かく言うとiTunes拡張定義というものがあり、これをさらに独自に拡張するという手もあるのですが、他のアプリでの影響が読み切れず、現在はやっていません。
そのため、ご指摘のような動作になってしまいます。
こんばんわ。
ご指摘をいただいて気がつきましたが、「選択されたアルバムを再生対象にする」をNoに設定している場合、表示している全アルバムの先頭から「再生対象の楽曲の最大数」までが再生対象になりますので、そのような動作になってしまいますね。
まさに今回ご質問いただいたように直感的な期待から外れた動作になっているわけですが、かといって、選択した曲以降「再生対象の楽曲の最大数」までにすると、それはそれで使いにくくなるのでしょうね…。
こんばんわ。
たぶん喜んでいただくのは早計ではないかと(笑。お伝えしたかったのは、検討は継続しているということで、それで結果としてうまくまとまらず、「やっぱり人前には出せないな」とお蔵入りになる機能は過去も現在もたくさんありますので…。
こんにちわ。
先日、メニューに謎の “VST3” の文字列が含まれたTuneBrowserをリリースするという失態をおかしてしまったところですが(^^; こちらでお約束したとおり、検討はつづけています。VST3の使用に関するSteinbergとの契約も済ませました。TuneBrowserの再生系に組み込む方法の目途も立ててあります。
ただ、わたしの語学力の問題もあって、自分のやっていることが果たしてVST3のSDKに対して技術的に適正なのか、いまひとつ掴めない状態がつづいていて、正直なところかなりつらい状況に陥っていました。
先は長いのか短いのかもわからないのですが、真摯なご要望いただきましたので、また改めて検討してみますね。
Naosさん、こんにちわ。
遅くなりましたが、動的タグの設定を紹介いただきありがとうございます。”_PERFORMER” などの動的タグは、まさに書いていただいたような目的のために用意しているものです。活用いただき嬉しいです。(^^)
こんにちわ。
古いトピックを引っ張り出していただき、ありがとうございます。
このトピックをオープンにしているのは、やらないと決めたわけではない故で、改めて検討中のメモを開いてみました。対象のトラックはいまは当然ハイレゾになろうかと思いますし、サンプルレートに上限を設けると逆に不評を買ってしまいそうなので、相当高いサンプルレートまでサポートすることになります。実際の波形はそんな高いサンプルレートで表示しても仕方がないでしょうし、描画にも時間がかかるので、なにか操作や再生をしている間にバックグラウンドでデコード、リサンプルあるいは間引き、描画用データへの変換といった処理を行うことになります。それでも、たとえばクラシックで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行くらいで結構です。このログはマウスで選択、右クリックでコピーなどができます。
よろしくお願いします。
ご確認ありがとうございました。