フォーラムへの返信
-
投稿
-
こんばんわ。
昨晩、4.12.1の先行版を公開しました。ここで議論になったクエリの動作を見直しています。tanaさんにご紹介した動作になっているものと思います。お時間のあるときにでもお試しいただければと思います。
クエリの動作を変えたため、ほかの部位の表示でも、もしなにか動作がおかしい点などがあれば、お知らせいただけると助かります。
こんばんわ。
更新履歴に挙がっていなかったにもかかわらず、ご確認いただき、ありがとうございました。
わかりました。
では、クローズさせていただきますね。こんにちわ。
イメージの管理ダイアログボックスの場合、追加したい目的地として埋込みイメージ、フォルダイメージ、関連イメージの3ヶ所があります。どこに追加したいのかというのはすこし微妙な気がするので、参照ボタンによる追加はわかりにくいかもしれません。
sambacancaoさん、Naosさん、ありがとうございます。
COMBINEで正解です。さすがですね(^^)。
それ以上のレベルの「精度」については、そういうものがあるのかどうか知見を持っていませんので、対応できていないということになるのかもしれません。
すいません、ちょっと乱暴な言い方になってしまいました。
現在のTuneBrowserのCD取り込みは、
- AccurateRipのオフセット指定
- Pre-emphasis (TOCおよびQ SubCodeの双方)
- HDCD
に対応しています。
こんばんわ。
TuneBrowserのリッピング機能は使った事がないのですが、EAC並みに精度が高くて
各種情報が自動取得可能でしたら、使ってみようと思います。
（そもそも、何を使ってリッピングしてもバイナリレベルでデータは同じかも知れませんが・・・）hiroさんにも書いていただきましたが、TuneBrowserのCD取り込みは、EACで取り込んだものとバイナリデータとして一致していることは確認しています。それ以上のレベルの「精度」については、そういうものがあるのかどうか知見を持っていませんので、対応できていないということになるのかもしれません。AccurateRipのオフセット情報にも対応しています。ただこれは個人的見解ですが、音楽再生という観点では、オフセットにはあまりこだわる必要はないと思っています (終端部でオフセットを超えた場合にどう処理すべきかという点も不明瞭ですし…)。
なおTuneBrowserはOS標準の機能を使用して取り込んでいますので、昔のCCCDや傷のついたCDなど、通常の方法で取り込めないものは、取り込めません。そうした場合は、ヘルプにも書きましたが、餅は餅屋で、EACなど専業のソフトのご利用をおすすめしています。
こんにちわ。
ご連絡どうもありがとうございました。大変助かります。
しばらく、これで様子を見たいと思います。
そうですね。お願いします。m(__)m
こんにちわ。
TuneBrowserのバージョンアップは、基本的に「新しいバージョンを上書きインストールする」という前提で開発しています。ただし、新しく追加になった表示項目などがある場合に、もとの設定をユーザーが変更されていて、それが失われる結果になる場合は、ユーザーの方の変更を尊重して新しい表示項目は適用しないようにしています (完全ではない場合もあります)。
このユーザー設定と新しい標準設定の兼ね合いは悩ましいところで、とくに表示系に関しては既存のユーザー設定と競合するような設定変更はなるべく控えるようにしているのですが、かといって改善を諦めるというのもアレなので、ごく稀にこうした既定の設定の変更を行っています。
ちなみに、トラック毎のチャンネル数の表示は、以前はステレオ専用だったTuneBrowserがマルチチャンネルに対応したときに、新たに増設したものとなります。
こんばんわ。
バックアップについては、hiroさんに書いていただいた内容を参考にしてみてください。
今でもExactAudioCopyでリッピングを行っていますが、自動検索機能でアーティスト名を取得しても、TuneBrowserで再生時は「UNKNOWN ARTIST」になるため、1枚ずつ手動で入力しなおしています。
長らくEACは使っていないので、最新状況には疎いのですが、EACがタグを書き込んでいてTuneBrowserがそれを読み込めていないということでしょうか。リッピング時のファイル形式はなにをご利用ですか?
Hi,
Thank you for your understanding.
こんばんわ。
①tuneBrowser動作中にドライブが認識しなくなり、後から回復した場合、
手動クロールで再取り込みする以外に方法はないのか？基本的に、TuneBrowserはドライブ(のルートディレクトリ)にアクセスできなくなった場合、ドライブが一時的に取り外されたと判断して、データベースからの削除は行わないようになります。今回のケースがそれに該当しそうなのですが、ドライブへのアクセスチェックは性能面の課題から常時行っているわけではありませんので、タイミングの問題だったのかもしれません。
現在のTuneBrowserは、データベースも含めたバックアップの機能があります。その機能の利用が、手動クロール以外の方法ということになります。
②楽曲データのCSVエクスポート機能は、何のためにあるのか？
この機能を提供した意図は、テキストエディタなどほかの外部アプリケーションでタグを一括編集したい場合など想定していました。CSVのインポートは、あまり知識のない方が変更されると、データの不整合が発生し得るので、チェックを厳しめにしています。ひょっとしたら厳しくしすぎているのかもしれませんが…。
よろしくお願いします。
Hi,
There is no special reason. Simply -6dB * 0.5 -> -12dB * 0.5 -> -18dB.
tanaさん、こんにちわ。
tanaさんのところの動作とわたしのところの動作のちがいは、現在手を入れているタグの処理の調整が影響していそうです (すいません、リリース版ではなく開発版で検証していました)。
クエリコマンド $IFVALCOUNT_LE 導入時に起きた問題の修正の副作用のようです。どのようにすべきかという点で、ちょっと混乱しています。取り急ぎ、ご報告します。
こんにちわ。
追加の情報ありがとうございます。TuneBrowserの当該の処理部分は変えていませんので、4.12になって、ウィルスバスターがTuneBrowserのASIO制御に干渉するようになったものと思います。それに類したダンプファイルが送られてきていて気になっていましたが、こうして具体的にご報告をいただけたのは今回がはじめてです。
もしTuneBrowserが「予期しない状態を検出」あるいは「ダンプファイルを見つけた」といった類のメッセージを表示したら、お送りいただいて、その旨一報を下さると助かります。すでにお送りいただいているかもしれませんが、ダンプファイルからはどなたがお送られたのか、わたしにはわからないようになっていますので…。
ASIO制御は、TuneBrowserの起動後、別の子プロセスを起動して行っています。これはASIOドライバが問題を起こした場合に、TuneBrowser自身が巻き添えを食わないようするためです。このASIO制御プロセスの起動中に、TuneBrowser内にフックしているウィルスバスターのDLLがフリーズしてしまうことがあるようです (問題のパターンはいくつかあり、まだ絞り切れていません)。おそらくウィルスバスターの不具合を刺激してしまっているのだと思いますが、現在のところまだ対処方法は思いつかない状態です。
こんばんわ。
コンテントグループの含まれた楽曲の場合、そのコンテントグループ内ですべて共通であれば、_CONTGROUPの下、共通でなければ各_SUBTITLEの下、というのが基本の考え方だったと思います。_CONTINDEXもそれに準じたかと思いますが、これはちょっと時間をかけて処理を確認してみないと確かなことは言えません。
取り急ぎ。
こんばんわ。
ご連絡ありがとうございます。
「ハングアップ」とは、ソフトウェア開発の上では応答がなくなり、画面更新もされないような状態を言っているのですが、その後「エラーが出ると」ということはTuneBrowserはなにか反応をしているのではないかと思います。
もうすこし現象について細かく教えていただけないでしょうか?
今回の更新ではASIO関係はほとんど手を加えていません。そのため、俄かには心当たりがありません。これは外している可能性も高いのですが、ひょっとしてトレンドマイクロ製のセキュリティソフトをご利用ではないでしょうか?
よろしくお願いします。
こんばんわ。
ご確認ありがとうございました。実装そのものは難しくないのですが、操作が煩雑になるといけないので、右クリックメニューの「高度」の下あたりに入れることになるかと思います。
9jgw4yさん、こんばんわ。
ありがとうございます。では残させていただきますね。
Hi, Thank you for using and loving TuneBrowser for a long time.
I think FTP is a very rare protocol for a music server. TuneBrowser is supporting the following remote protocols for a music server:
- SMB (=Windows File Share)
- HTTP (with UPnP≒DLNA)
Unfortunately, FTP is not supported. If you are using NAS, I think NAS generally supports SMB.
Regards
こんばんわ。
再生回数は、長い目で見ればだんだんとばらけていくものですので、個人的にはあまり気にされないほうがいいのではないかと思いますが…。また「トラックチェックや誤操作で特定トラックがカウントアップされた場合」の対処として、「再生したとする秒数」という設定項目があり、既定で10秒になっています。これが短すぎるようであれば、長めに設定していただくことで、誤操作などは記録されにくくなるのではないかと思います。
「再生したとする秒数」の設定項目は、「再生の設定」-「再生の詳細設定」のなかにあります。もしわからなければまた質問してください。
それはそれとして、「クリア」と言われているのは、カウント値を強制的に0にする、ということで合っていますでしょうか?
追伸: 勝手ながら、トピック中に引用されている「youさんのトピック」にリンクを設定させていただきました。ご了承ください。
sambacancaoさん、ありがとうございます。
＞Tikiさんのスクショと見比べると私のアルバムビューには「2ch」のチャンネル表記が無く
この行は「トラック行」の設定と思われるので気になさらなくていいと思いますこれは、その通りだと思います。
代わりに%COMPOSER%を使ってみるのはいかがでしょうか？
こちらのほうは、「COMPOSER情報が無いとALBUM ARTISTが表示される」という挙動が必要かどうか、というところですね。COMPOSERが設定されていないアルバムの場合に空欄でよければ、ご提案の方法で良いと思います。
9jgw4yさん、フォローありがとうございます。
2019-10-16 00:35に投稿した私の投稿を削除してください。
とのことですが、バックアップに関連した情報として興味のある方もおられるかもしれません。差支えなければそのままにしておいて良いと思うのですが、いかがでしょうか?
こんにちわ。
DTS-WAVファイルというものがあることをはじめて知りました。そのため再生をサポートする計画もありませんでした。音源の普及状況や入手方法もわからないため、将来も検討そのものが難しそうです。
こんばんわ。
同じようなデータを用意して$ANYで確認してみたところ、期待通りの動作をしているようです。tanaさんの設定はまちがいないようですし、この動作の違いについていまのところ説明かできないのですが、取り急ぎご報告しておきます。
※ 図中の語がおかしいのは、検証用に機械的に生成したデータを使用しているためです。全楽曲におなじALBUM ARTISTを設定しています。
お手数おかけします。
よろしくお願いします。
こんにちわ。
まず大きな考え方として、基本的にTuneBrowserは自分のデータベースで楽曲を管理して、さまざまな方法で楽曲を選んで再生する、というつもりで作っているアプリケーションです。そのため、OSとの統合という意味では、どうしても優先度は低くなっています。
また、UWP版の場合はWindows 10だけで動作するという前提ができますので、Windows 10との整合は考慮しています。いっぽうデスクトップ版 (クラシック版と言われているのはこれのことだと思いますが) の場合、Windows 7、Windows 8.1もサポートしなければならず、これら3種類のOSそれぞれが異なった方法を採用しており、さらに古いOSは歴史的経緯もあって情報が混乱気味です。そのため、上に書いた優先度や必要性の話もあって、現在のところは積極的には取り組めていません。
あまり良い返信でなく恐縮ですが、よろしくお願いします。
ご確認ありがとうございました。
やはり、COMPOSER情報が1曲でもあれば、ALBUM ARTIST名を併記・表示させないとのは出来ないという認識でよろしいでしょうか?
$ANYを使用した方法は、これができるかも、というつもりでお話ししていました。ですので、アテが外れた格好です。すこしお時間をいただくかもしれませんが、またわたしのほうでもデータを用意して確認をしてみます。
ご確認ありがとうございました。
こんにちわ。
その後あらためて考えていて、以下のコマンドを利用すると、ご所望の動作になるかもしれません (検証用のデータを用意していないので、確認していませんすいません)。
$ANY(%_COMPOSERS,NameFull%,%_GRPARTIST,NameFull%)これを、TuneBrowserのトラック表示の書式設定のところで、
%_ARTCOMP,NameFull%となっている部分を置き換えてみてください。
TuneBrowserの書式設定はかなりわかりづらいので申し訳ないのですが、よろしければお試しください。
こんにちわ。
当該の場所は、_ARTCOMPという動的タグ (別名タグ) を使用しています。4.11.xまでの定義では、_COMPOSERS; _GRPARTISTになっていて、各トラックについて_COMPOSERSがあればそれを、なければ_GRPARTISTを使用して、最終的に全トラックの値をマージします。そのためご指摘のような動作になり、現在のところ_COMPOSERSがどれかひとつのトラックにあれば、という動作はできません。
先日べつのところにも書きましたが、タグの処理はトラック単位が基本で、あるグループ (≒アルバム) 全体の状況を見て動作を変えるような動きは例外的なものになります。
4.12.0からは、変更履歴にも書いたように、この_ARTCOMPの定義が変わっています。このフォーラムで出ていた議論を見ていて、そのほうがいいのかなと思い、変更しました。これはすこし軽率な変更だったかもしれませんが、先行版の公開中にとくにご指摘もなかったことから、このまま正式版となりました。
こんばんわ。
ご返信した件、ご確認いただけていますでしょうか?
もう1点、気のついた点があります。Tree Viewで選択されているノードがフォルダーツリーになっていますが、その場合、トラックはファイル名順で並ぶようになっています。その結果かもしれません。
フォルダーツリーのツリークエリの設定でトラックソートクエリを削除して空欄にしていただくと、デフォルトのトラック番号順になります。やり方がわからなければまた質問してください。
こんばんわ。
タグ値のDISCNUMBERが設定されていないでしょうか?
最近のTuneBrowserの既定の設定では、DISCNUMBERも表示させるようにしていますので、最近ご利用をはじめられたのであれば外しているかもしれませんが…。
まずはDISCNUMBERの設定をご確認いただければと思います。
こんばんわ。
TuneBrowserのAlbum Viewのなかはアルバム-トラック、アルバム-トラック、という順で並んでいて、またアルバムもLibrary Viewerの場合、選択したツリーノードによって並びが変わります。そのため、直感的な期待に合わない可能性がありそうです。
インクリメンタルサーチは、キーボード操作を検出した後、タイマで次のキーボード入力を監視するなど、難しいとは言いませんが実装が煩雑で、正直なところその割に利用シーンが限られるかなという印象です。
なおご存知かと思いますが、Album View内にインデックス (白地に1文字の画像) が表示されている場合は、キーボードでその文字を選択すると、そのインデックス部分にスクロールするようになっています。
あまり良い返信でなく恐縮ですが、よろしくお願いします。
Hi Andrew, Thank you for your comment.
I’m currently considering to be able to resize a Image View pane by dragging its window frame with the mouse.Koumaさん、
上に書いた通り、現在のところマウスでウィンドウ枠をドラッグしてリサイズできるようにするように考えています。ご確認ありがとうございました。
操作性は二の次で良いということでしょうか。
わかりました。検討します。
こんばんわ。
画像の表示は、さまざまなアスペクト比で検証した結果、現在の処理になっています。そのためすいませんが見直しの要否の検討には時間がかかりそうです。
ちなみに、ご利用のデスクトップ環境の画素数はいくつでしょうか?
こんばんわ。
先ほど、この問題について対処した先行版1491を更新しました. お時間のあるときにお試しいただけると助かります。
よろしくお願いします。
そうですか…。その場合、デスクトップのサイズにもよりますが、半分くらいの大きさで表示されているのだと思います。
以前こちらでも書いたのですが
サイズの調整は、良い操作性を実現できるような形で実装できる感触が掴めていません。引き続き考えてみます。
もとの画像の解像度が高ければ大きく表示されると思うのですが、もとの画像の解像度が不足しているということはありませんか? その場合、拡大してもぼやけてしまうだけということも考えられます。
Naosさん、フォローありがとうございます。
mikechanさん、ご確認ありがとうございます。アルバム数が少ない場合に、表示が煩雑にならないように、付加情報の出る量を自動で加減しています。その結果としてわかりにくくなっているのかもしれません…。Naosさんに引用いただいたトピックでも、どこかに説明を掲載することを検討すると言っておきながら、できていませんね…。
こんにちわ。
ポップアップ表示される画像の大きさのことだと思いますが、デスクトップのサイズと画像のサイズから、自動で判定して表示しています。現在のところユーザが画像の大きさを指定することはできません。
こんにちわ。
ご確認ありがとうございました。だいたいわたしが「やるとすればこうかな」と思っていたことと合っていました。
仕様上実装が大変ということであれば大丈夫です。タグに書き込んで運用でカバーします。
ありがとうございます。実現の検討ははじめていますが、前に書いたように少々時間が (すくなくとも1ヶ月以上は) かかりそうです。もしお待ちいただけるのであれば、また状況ご報告します。ただ恐縮ながら (最近は事実として) たまにほかの大きな改修に没頭して忘れてしまうこともあるので、ときどき「どうなっていますか」と聞いていただけると有難いです(^o^;。ちょっとポンコツ気味ですいません。
こんにちわ。
ご指摘ありがとうございます。
ご利用の例だと、複数タグが指定された場合の最適化処理 (複数のタグがあると検出すると、事前にタグの値ごとのグルーピングを行ってからクエリの処理を行います) が適用されて、結果としてタグの値の数が正しく判定されないことがわかりました。
現在のところどう対処したらよいかというのはまだ思いつかないのですが、ようやく原因がわかりましたので、ご報告します。
Hi,
Thank you very much for your mind.
As you said, TuneBrowser is not so famous in any country…And, I am developing the TuneBrowser in my private house.
Sorry, but this place is not open to the public.Many thanks.
P.S.
I’m just planning to update TuneBrowser license fee from November for new users.
Check this page (with translation system) for details.
Please keep it in mind if you would talk about TuneBrowser.Hi,
Thank you for your confirming. It was good to meet your wish. And sorry, but I’m not sure about a behavior of going back to previous tune now. (^^;
I’d like to close this topic after official release.
Thanks again.
すこしタイトルを変えさせていただきました。
こんばんわ。
LRCファイルについてインターネットで調べてみると、Sony Walkman用の同期マーカーのついたファイル形式だという説明がありました。そのファイル形式で合ってますか?
その場合、TuneBrowserでも曲の進行に同期して表示 (自動スクロールや歌唱中の行だけの表示など) されることを期待されていますでしょうか?
また、じつはTuneBrowserは画面の表示に合わせてファイルにアクセスすることは (近年のバージョンでは) 原則やっていません。これは、万一アクセスの遅い場所にファイルが置かれていた場合に、ユーザーの操作が停滞してしまうのを防ぐためです。たとえばジャケット類の画像の表示では、動作を見ているとおわかりになるかもしれませんが、画面の表示とは非同期で (別のスレッドで) 処理をして、準備ができたものから表示するようにしています。
ユーザーの楽曲の選択に合わせてLRCファイルにアクセスするためには、同様にそれ用の機構を作る必要があり、すこし大掛かりになりそうです。
何の話かおわかりにならない場合は、上記の背景説明は飛ばしていただいてかまいません。やるとしても時間がかかりそう、という感じです。
DRINKING BIRDさん、フォローありがとうございました。
WakuwakuPさん、ご確認ありがとうございました。
こんにちわ。
ご確認いただき、ありがとうございました。うまく動作して、よかったです。(^^)
こんにちわ。
ご連絡が遅くなりましたが、現在公開している先行版で、上でご紹介したコマンドを実装しています。仕様はそのまま変えていません。クエリを書く部分に、コマンドを書いていただく形になります。
$IFVALCOUNT_LE(%COMPOSER%,1,)で、COMPOSERがふたつ以上あったら、空になります。
よろしくお願いします。
追加の情報ありがとうございます。
WavPack形式だけで発生していること、一時停止クリック->再生クリックで発生するとのこと、了解しました。
あらためて試してみましたが、やはり再現しません。他の方からのご連絡も待ってみましょうか。情報を得やすいように、タイトルを変更しますね。
こんにちわ。ご連絡ありがとうございます。
念のため、手許の環境で確認をしてみましたが、再現させることができませんでした。
ファイルはWavPack、他のファイルでも試したが同じ現象が起こる
ここで、「他のファイル」と言われているのは、FLACなどほかのファイル形式という意味でしょうか? あるいはWavPack形式の他のファイルという意味でしょうか? 後者の場合、ほかのファイル形式の場合は、いかがでしょうか?
こんばんわ。
ご連絡、ありがとうございました。前のコメントを行ったあと、例2の件を見逃しており、大変失礼しました。
こんにちわ。
お気づきかもしれませんが、4.12.0の先行版で、ダウンロードした画像のURLを自動でブラックリストに載せる機能をつけています。ただURLは、このバージョン以降でダウンロードした画像しか記録されませんので、すぐに確認いただくのはむずかしいかもしれません。
念のため、お知らせしておきます。
Thank you for giving me a chance to explain behavior of ATT (^^).
Hi,
I have published preliminaly release of TuneBrowser, 4.12.0 (Desktop Version only). At this version, behavior has been changed when playing file was deleted.
Please try this version when you have time.
Hi,
Thank you for your reply. You are already using fidata control app with TuneBrowser, it shows TuneBrowser is working well as a OpenHome player.
TuneBrowser as a OpenHome player is now supporting http protocol only. That may not be enough for “OpenHome Streaming Service”… (As you said, Amazon Music HD has just begun in Japan, but I think it may not support OpenHome)
Thanks again for your understanding.
Hi,
A reason to exist “Apply to decoder” menu item is historical reason. Currently, “Apply to decoder” is enabled (checked) by default.
There are almost no difference between checked and unchecked for normal use.Following is a simplified data processing flow in TuneBrowser:
- File => Decoder (=> DSP) [1] => Buffer => Player [2] => Device
ATT processing is placed at
- [1]: Enable “Apply to decoder”
- [2]: Disable “Apply to decoder”
Advantage of case[1]
- In case[1] , ATT is applied to FLOAT type data of lossy formats like MP3 and AAC. So there is a possibility to be able to rescue clipped data.
- Case[2] data is usually INT type based on device format, and clipped peaks are already lost even if ATT decreases levels.
Advantage of case[2]
- When user changes ATT level while playing, case[1] should discard all decoded data in buffer, so playback stops once.
- Case[2] applies ATT level to the output data directly. Playback does not stop.
Earlier version of TuneBrowser was implemented with case [2] only. Because ATT was designed as one of volume control.
I think the advantage of case[2] is not important for most users. So “Apply to decoder” is enabled by default now. Perhaps I’ll remove this menu item in future.
Regards
OpenHome function of TuneBrowser is disabled by default. So you have to enable it in Preferrences dialogbox (Network tree) before use.
Thanks
さっそくご確認、ありがとうございました。
なおちなみに、ですが、UnsyncedLyricsが正しい表記となります。念のため、もとの投稿は修正させていただきますね。
Hi,
Thank you for using TuneBrowser.
Unfortunately, Tidal is not started in Japan, so I do not know detail about it.
You may know TuneBrowser is not supporting to manage streaming services directly. But player engine of TuneBrowser is published as a OpenHome player. If your Tidal controler app is supporing OpenHome player, there is a possibility to see a TuneBrowser OpenHome player in controler.
If that is shown, you can try it.But … if something goes wrong, it seems difficult for me to support…
Regards
こんにちわ。
どちらかというと、個別の残り時間はぱっと見て判断できる範囲ですが、総残り時間はそうはいきませんので機能としてほしかったのですが、そういえば他のミュージックソフトでも見かけませんね。
%_TOTALSEC_??%があったので可能かと簡単に考えたのですが、諦めます。
わかりました。ではちょっと優先度は下げますね。
こんにちわ。
状況を掴むのに時間がかかりました。ご指摘のように、1行が長く、結果としてウィンドウ枠いっぱいにテキストが表示されているような状況で、右端のスクロールバーの出入りが切り替わったときに、行の高さに不整合が出てテキストが表示されなくなることがわかりました。
おそらく、表示されていない状況ですこしウィンドウの幅を変えてみると、(スクロールバーの出入りが変わらない状態でメトリクスが再計算されるので) 表示されるようになるのではないかと思います。
現在準備中の先行版に対策を入れ込みたいと思います。ありがとうございました。
こんにちわ。
残り時間の算出には、プレイヤーの持っている再生時間と、再生曲が持っている総時間の両方の情報が必要になり、両者の同期で課題が出るかもしれませんが、検討してみます。
総残り時間のほうは、プレイリスト中の再生済み曲の総時間を考慮する必要があると思うのですが、その場合、巨大なプレイリストを使用されている場合だと、おそらく体感できるほどの負荷増になると思います。それを毎秒実行するということを考えると、現実的ではなさそうです。
ご確認ありがとうございました。
この件、UWP版が公開されてからしばらく経ちますが、クローズしてもよろしいでしょうか?
もしまだ課題があるようでしたら、2,3日中にご連絡いただければと思います。
わかりました。
ご確認ありがとうございます。
こんにちわ。
WASAPIでは再生できたとのことですが、ASIOドライバのエラーのほうはもういいのでしょうか?
とはいっても、
PIONEER DJ DJM-S9 ASIO
という機器がPCにつながっているか、電源が入っているか、メーカーからのドライバの更新が出ていないかくらいしか確認いただくポイントはないのですが…。
HDDは買ってから2ヶ月のものです。S.M.A.R.T.確認してみましたが異常ありませんでした。
そうでしたか。失礼しました。わたしが交換したディスクは数年は経過していたと思います。
こんにちわ。
前にも書きましたがHDDの反応が悪く、「削除された」と認識される瞬間があったのかもと素人考えもしています。
あー、それはあるかもしれません。たまたまですが、わたしのHDD (ファイルサーバー上のもの) もそのような状態になったものがあり、改めてHDDを取り出してSMART情報を確認してみると、代替セクタが大量に発生していました。
ちょうど先週末そのHDDの入れ替えを行いました。入れ替えは単純にUSBで接続してエクスプローラーでコピーしたのですが、結果として数十個のファイルがコピーできず、失われました。手動でリトライを繰り返したりしていると (リトライすると読めたりすることもあるので)、結局一日仕事になってしまいました。
早めの交換がよいかもしれないですよ。
こんにちわ。
ご確認ありがとうございました。
こんにちわ。
ご意見ありがとうございます。バックアップされるプレイリストは「データベースプレイリスト」だけですので、やるとすれば設定だけ、データベースだけ、を選ぶようなことになりそうです (データベース内のプレイリストのテーブルだけというのは、不整合が発生すると面倒なことになるので、やらないと思います)。
ただそうすると、たとえば数年前のデータベースと現在の設定をリストアしたり、あるいはTuneBrowserはバージョンアップをつづけているため数世代差のデータベースと設定を混ぜたりする状況が発生しますので、これも不整合のリスクが発生するかもしれません。かといって、時間がたったバックアップや古いバージョンのバックアップはリストアできないようにすると、それはそれで残念に思う向きも出てきそうです。
将来の検討事項のひとつとさせていただきますが、上記のような使用上の制約をどう説明してどう対処を考えるか、というのが課題のひとつになりそうです。
昨日、たしかに「意図しないデータベースの削除」が発生して、わたしのところにダンプファイルが送られてきていました。内容は薬師丸ひろ子の楽曲が1曲削除されたというものだったと記憶しています。1曲だけなのでエクスプローラや他のソフトで削除されたのだと思いますので、そうであればTuneBrowserから見て「意図しない」だけであって、異常ではないと思います。
その「意図しないデータベースの削除」が検出されたので、設定はいったんリセットされたのだと思います。
こんにちわ。
おそらく、ですが、上記の2.のプレイリストの保存の確認は、バックアップのためというよりは、いったんすべてのタブを閉じるときに、変更があったにもかかわらず保存されていないので表示されたのではないかと思います。
変更した記憶はないというお話しかと拝察しますが、プレイリストをロードするときに存在していないファイルがある、あるいはロード後にファイルが削除された場合、一覧からファイルが抹消され、タブの部分に更新ありを示す「*」が表示されます。
その状態で (バックアップのために) タブを閉じようとして、ユーザに判断を仰いだのだと思います。そのことを念頭に、動作を様子を見ていただけないでしょうか。
ご確認ありがとうございました。
コマンドの使い方をご教示頂きたくよろしくお願いいたします。
コマンドの使い方は、現在のところは前述した通りです。わからないところがあれば、またそのときにご質問いただければと思います。
こんばんわ。
その機能はActive Backgroundと呼んでいます。Player View右上のボタンで、On/Offを切り替えることができます。いくつかボタンがありますが、マウスをかざすと説明が出ますので、それでどのボタンかわかると思います。
フォントは、ユーザが指定することはできません。Windows 7を未だ動作対象OSに挙げていますので、Windows 7時代の標準フォントのなかから、質のよさそうなものを選んで使用しています。
こんばんわ。
要望事項：画像２で、アルバムタイトルの下(トラックタイトルの上)に「COMPOSER」を表示したい。
どこまでわたしにご要望になっているのか、きちんと消化できていないのですが、前のコメントでご説明したようなコマンドは用意します。ただ、そのコマンドを装備したTuneBrowserを起動したからといって、ご要望の場所に自動でテキストが現れるわけではありませんので、その点はご了承ください (ご自身でコマンドを利用したレイアウトを作成いただく必要があります)。
こんばんわ。
上の例を実現するにあたって、ALBUM ARITSTをべつの用途に使用しているときに、その代替としてどのようなタグ名を使用すればいいだろうと考えてみました。ALBUM COMPOSERなどを新たに定義してもいいですし、それが正しいという気もしますが、結局、新しいクエリコマンドを定義してみる、ということに考えが至りました。
以下のようなものです。
$IFVALCOUNT_LE(A,n,B) Aのクエリ結果の値の個数がn以下だったらA、そうでなければBを返す。ご期待のものとはすこしちがっているかもしれませんが、これで用を成すのではないかと思います。いかがでしょうか。実装そのものは難しくはないので、次のリリース (すこし先です) までに実装しようと思います。
ちなみに、ご推察されているかもしれませんが “_LE” はless or equalの意味で、これに対になる “_GE” (greater or equal)も実装する予定です。
こんばんわ。
ヘッダ部分というよりアルバムタイトルの下、フッタ部分or独立行に先に述べた条件で「COMPOSER」を表示したいという事です。
やはりそうですか…。ヘッダ/フッタ部分は特別なロジックで処理していますので、なんとかなるかもと思ったのですが、ひと晩寝た頭であらためて考えてみると、その場合は下の例では1曲目のピアノ協奏曲 第19番だけ作曲者名が表示され、それ以降は表示されないということになりますので、やっぱりへんですよね。
残念ながら、やはり上でお話したようなことになりそうです。
ところで、上の図は全作曲家がおなじという一般的な例で、赤枠の部分に作曲者名が出ています。これに対し、これまでご説明していたのは、下の例のように各トラックで作曲者が違う場合に、”Various Artist” と表示させるということでした。しつこくて申し訳ないですが、わたしとしてはやはりこれが簡単なのではないかと思います。
なおこの下の例の場合、Daniel Hopeの名前を使うほうが適切かと思いますが、これはあくまで説明用のサンプルですのでご了承ください (また、わたし自身はここに作曲者名が並んでも、あまり問題には感じませんが… これは私感です)。
こんばんわ。
ALBUM ARTISTの件、了解しました。
申し上げたかったのは、トラック毎にちがうかもしれない属性があって、それらがすべて共通のときには別の場所にその共通の値を表示し、異なっていればトラック毎に出す、というような制御をするのであれば、まずタグの値でその状態をきちんと定義したほうが良いのではないか (そして現在のTuneBrowserの機能で実現できる) ということでした。その場合、例として一般的なALBUM ARTISTを挙げましたが、ほかの独自のタグでも構いません。
素人考えでクエリ文字列等現存の機能で出来るかと思ったのですが、新たな開発が必要なようですので、一般的でなければ見送りとして下さるようお願い致します。
この機能は実現するとすれば、たしかにその機能独自の開発が必要です。ただ、それが面倒で申し上げているのではないことはご理解ください。
ちなみに、TuneBrowser (に限らず世の多くのタグを扱うソフト) のタグ処理は、基本的にはトラック単位に行うもので、複数トラックにまたがって行うことはできません。TuneBrowserの場合、唯一の例外がクエリのMIN/MAXのオプションで、新着順/再生した順のアルバムのソートを行うために、そのアルバム内の全トラックからもっとも新しいタイムスタンプを抽出しています。そうでないと、アルバム内の1曲だけを再生した場合に、アルバム内の全曲を「最近再生した」と認識できないためです。
ところで、最後につけていただいた画像を見ると、実際にご要望になっていることは、これまでお書きになられた内容からわたしが理解していたこととはちがうような気もしてきました。Album Viewの自由な場所に行を追加したいということではなくて、トラックのヘッダ部分に表示したいということでしょうか? すこし時間を置くかもしれませんが、また改めて、書かれていることを検討してみます。
すいません、1点教えてください。
先のコメントに書いたような、ALBUM ARTISTなどを援用する方法はなにか課題があるのでしょうか?
全部おなじCOMPOSERであれば、そのCOMPOSERが表示され、個々の楽曲で異なるCOMPOSERになっていて、それが見苦しいほど多数になるのであれば、(わたしの感覚ではそうしたアルバムはクラシックの場合、少数派なので) そのアルバムにはALBUM ARTISTを設定すればCOMPOSERは表示されなくなります。タグの管理上、ほかのソフトとの互換性も考えると、やはりそれが自然なような気がします。
こんばんわ。
現在はOS (Windows) のソート関数を使用してソートしています。ですので、おそらくエクスプローラのフォルダやファイル名順とおなじになっていると思います。
ソート系のタグについては、以前ご要望をいただいて対応は行っています (ご確認いただけなかったので、正しく動いているかどうかは定かではないという話はありますが…)。アルバムの順番などについては、グループソートクエリにソート系のタグを指定していただければ、反映させることはできます。
ただ、Tree Viewのツリーノードについては、昇順/降順の指定ができるだけで、特別なソート用のタグの指定はできません。ツリークエリの構文上、ちょっとむずかしいかもです。
こんばんわ。
テキストのスタイルについては、ご指摘のようなコピーがあってもいいかもれしれませんね。検討します。
こんばんわ。
私の希望はまさに最後に述べられた内容で、
はい、承知しています。その上でアルバムの管理の方法としては別のやり方のほうが自然なのではないか、というお話を差し上げました。
何とか実現したいのですが難しいでしょうか？
新しいコマンドを定義するにしても、どういう方法が良いのか、というのはすくなくともすぐには思いつきません。またすこし時間をかけて、考えてみます。
こんにちわ。
この件、その後いろいろと考えていて遅くなりました。
もともと、TuneBrowserのトラック表示のヘッダ部分に出す情報を検討するときに、雑誌『レコード芸術』の月評欄のアルバム情報を参考のひとつにしました。そこでは、たいていクラシックのアルバムは、作曲家がトップにきて、アルバム名≒主たる曲名、演奏家の順になっていました。
そしてオムニバスや演奏家が主たるテーマになっているアルバムの場合は、それに応じたアレンジがされていたと記憶しています。
これは、クラシックの場合、たとえばCDそのものもたいだい同様の形になっているのではないかと思います。
TuneBrowserのトラック表示のヘッダ部分もそれに準じたものになっているわけですが、作曲家主体のアルバムは標準の形式で良いとして、複数の作曲家の楽曲が収録されているアルバムの場合、キーとなっている人物がいれば、それをALBUM ARTISTなどのタグを使って定義し、TuneBrowserのトラック表示の先頭部分には、作曲家の代わりにALBUM ARTISTを表示するような設定にすべきではないか、と思いました。キーとなっている人物もいない場合は、そこは “Various” などにすることになります。
つまり、
①複数の作曲者がいるアルバムの場合、上部に作曲者がずらっと表示されるので、以前の本フォーラムトピックを参考に該当行を削除
とのことですが、この「該当行」を復活させ、その定義で「ALBUM ARTISTがあればそれを優先」のような定義にすればいいのではないでしょうか (その方法がわからなければまた質問してください)。
長い間お待たせした上にご質問の直接の答えになっていなくて恐縮ですが、COMPOSER (≒あるタグの値) が全部同じであれば有効になるような要素を用意すると、次はその表示位置の調整、などいろいろと大変ですので、上記のような考え方が適切ではないか、というように思いました。
よろしくお願いします。
こんばんわ。
当該の画像は、前のトピックにも書きましたが、内容はAmazonのことが書かれているにしても、おそらくダウンロード元はLast.fmだと思います。その画像を削除すれば、その画像をダウンロードする理由となったキーワードは使用されなくなります。
それ以外には、ネットワークからの画像のダウンロートを行わないようにする設定があります。もし設定方法がわからなければまた質問してください。
こんばんわ。
ご確認ありがとうございます。
プレイリストを作成していない場合に表示されませんか？
すいません、いまは時間をとるのが難しく、その状況を作って確認することができません。ご容赦ください。
奥深いソフトをお作りになりましたね。大変感謝します。
TuneBrowserをよく言っていただき、ありがとうございます。音楽とオーディオ好きなので、それが活きているとしたらいいなと思います(^^)。
ひとつは、先日serenityさんからご報告いただのと同じ画像ですね。
https://tunebrowser.tikisoft.net/forums/topic/5900/#post-6691
Last.fmが提供している画像に、適切でないものが含まれているようです。URLがわかればそれをBlackListに載せることはできますが、現在のところURLがわからないと対処ができません。
ダウンロードした画像のURLが逆引きできるようなしかけは、現在検討中です。
こんばんわ。
コントローラでサーバーとしてのTuneBrowserに接続すると、コントローラの画面に「新着順」「再生した順」などのノード一覧が表示され、たとえば「新着順」を選択すると、
- – アルバムを表示
- 2019
- 2018
- …
といった子ノードが表示されると思うのですが、そうなっていませんか? このいちばん上の「- アルバムの表示」のことを言っていました。
こんにちわ。
「:」で区切られたTITLEの処理は、TuneBrowserの特徴のひとつなのですが、そうした機能を欲されていない向きには、よく混乱させてしまう機能でもあります (ほかに、タイトル部分のダブルクリック操作などもあります…)。
過去、こちらのトピックで扱っていますので、ご参照ください。
Thank you for reporting the alternative way. (^^)
When files are not stored in management directories of the TuneBrowser, it works well.
Now I’m trying to reconsider basic behavior about deleting playing file.
Please don’t worry about it. This reconsidering is not for your case only, is for generic use and including your case. I thank you for giving me a chance of this reconsidering.
こんばんわ。
ご報告ありがとうございます。あまり役に立てず恐縮です。
もしよければ、なのですが、「- アルバムを表示」で全アルバムを表示させる方法は何がちがっていたのか、教えていただけないでしょうか?
こんにちわ。
ツリークエリ内にプレイリストを出すことは、むかしはそうなっていたのですが、プレイリストを積極的にご利用になる方は大量のプレイリストをご利用になるようで操作が煩雑になってしまうので、現在のように別ページ的な表示にしています。すいませんが、これは現在は変えることはできません。
こんにちわ。
プレイリストを選択すると全アルバムが表示されていたという状態は確認できていないのですが、先頭に「- アルバムを表示」というノードがあり、それを選択すると、全アルバムが表示されませんか?
Thank you for your mind, understand and proposal (^^).
I’ll continue to consider a solution…
Sorry but it may take a time.
Hi,
I confirmed that you are telling. The point was “delete playing track” (as you said).
When a playing track is deleted, TuneBrowser lose playback position and place playback position into -1 (it means “before top of the playlist”). And playback continues while possible. When playback has finished, playback position will be incremented from -1 to 0. This “0” is the top of the playlist.
This behavior is according to the basic operating policy of the TuneBrowser. And also I think this is not proper behavior for the case you are explaining, but I cannot figure out now what shoud I do while keeping the basic policy.
I’m sorry but I did not reach a conclusion.
Thank you for details. I’ll try again to reproduce.
詳細の情報ありがとうございました。
最初に発生した、きっかけとなる事象=貼り付けを行ったあとしばらく反応がなかった、という件は、ダンプファイル内のログにも痕跡は残っていました。ただTuneBrowserとしては音楽再生以外にはとくになにもしておらず、9.1秒後にWindowsからの制御が戻ってきて、その後の動作を継続したような形になっています。9.1秒というのは相当長いので、なにかが起きていたとは思うのですが、残念ながらTuneBrowser側からはこれ以上はわかりませんでした。
その間にOKボタンを2回押されていますので、その後Windowsから制御が戻ってきたときに、OKボタンを処理するイベントが連発したのだと理解しました。これについては、次のリリースまでに対処を入れておきます。
よろしくお願いします。