フォーラムへの返信
-
投稿
-
本当ですね。気が付いていませんでした。(__;
すいませんが、4.3.0はこのまま行きます。ヘルプそのものは「ヘルプ」メニューから「トピックの検索」で表示させることができます。
ありがとうございます。修正しました。(^^)
わかりました。またお気づきのことがあれば、情報をお願いします。
細かい点を確認させてください。
- 事象が出ているアルバムは、前回も含めて、新規登録でしょうか?
- 動的タグ “_ALBUMARTIST” の設定は変更されていますでしょうか? (既定の設定は “ALBUM ARTIST; ALBUMARTIST” です)
- 次回、同様の現象が発生した場合、TuneBrowserを再起動せずに、そのアルバムに対して右クリックから「データの更新」を行ってみてください (お願い)。
この現象は、大量更新中に稀に発生するとのことで、追い込みが非常に難しい状態です。念のため事象をまとめると、
- FLACファイルのみで発生。
- タグがまちがった値になるのは、いつもArtist系のタグ = Tree ViewもAlbum Viewも両方ともおかしい。
- 大量更新中に発生。
- TuneBrowserを再起動すると正常化する = ファイルからは正しく読めて、データベースにも正しく記録されている。
といったところでしょうか。いかにも排他処理でなにか問題が起きてそうな感じなのですが、動作を確認しても、これという点は見つけられません。何とかわたしのところで再現ができればよいのですが。
ということで、この件が解決していない状態で恐縮ですが、4.3.0は現在の状態で正式版にしました。ご了承ください。
解決していない課題があるのに ここでこう言うのもいかがなものかという話なのですが、今回の一連の取り組みで、長い間改善のなかったクロールの処理をかなり見直すことができました。いまはもうそのコードは見たくもないという感じですが(^^;、ここまで改善できたのはnikuyamaさんのおかげです。この場を借りて御礼申し上げます。
要するにいつまでも使える状態にならない。
とのことですが、TuneBrowserは、画像を読み込み中は黒塗りに四角枠、画像が読み込めなかった場合には(既定の設定では)オレンジ塗りの四角で表示します。このどちらでしょうか?
4.2.3から4.2.4の差分をもう一度確認してみたのですが、これという点は見つけられませんでした。すいませんが、改善できるにしても、かなり時間がかかりそうです。
ありがとうございます。
ご利用になられているTuneBrowserのバージョンを教えていただけますか？
ご確認いただきまして、ありがとうございました。
今日 関係する処理を見直してみたのですが、キャッシュヒット時の処理以外には、これといった点は見つかりませんでした。
「不定期にキャッシュの再読込が起こります」という状況は、どのような現象から言われているのでしょうか? 少々答えにくい質問で恐縮ですが、なにかヒントがいただけると助かります。
また、4.2.3での様子をまた教えていただけると有難いです。
お手数をおかけしますが、よろしくお願いします。
ご確認いただき、ありがとうございました。うまく動いたようで、よかったです。(^^)
しばらく間を置いて再度試していただくと、動作するのではないかと思います。
それでも同様のメッセージが出る場合は、当該のモジュールは更新していないので、無視していただいて構いません。
TBShProc.dllは、一部のキーボードについているマルチメディアキーを処理するためのモジュールです。TuneBrowserがアクティブでない場合でも処理できるように、シェルからの通知を受けます。そのため、TuneBrowserを終了したあとも、しばらくほかのモジュールに読み込まれていて、上書きできないことがあります。
こんにちわ。
管理対象外のファイルだったのですね。TuneBrowserは起動時にプレイリスト(タブ)を読み込む時や、ファイルを選択してデータの更新を行ったとき、それらのファイルが属するフォルダを対象にファイル更新の確認を行っていました (フォルダを管理対象にして操作する、というのは大きな前提でしたので、管理対象外のフォルダ/ファイルへの考慮があまりできていませんでした)。
先ほどリリースした先行版(1357)で、これらの動作を抑制してみました。現在判明しているフォルダ操作はすべて対策したつもりですが、ひよっとしたらまだ網羅できていないかもしれません。
また、すでに登録されたファイルは自動で削除されることはないので、お手数ですが、余計に登録されてしまったファイルは手動で登録を削除していただく必要があります。ご了承ください。
こんばんわ、
ご確認いただき、ありがとうございました。やはり、その設定変更で正常動作するのですね。
マイクロソフトとの調整状況は、また進展があればこちらでご報告するようにします。
どうぞよろしくお願いします。
早速ご確認いただき、ありがとうございました。
ご連絡いただかなければ、大きな問題を抱えたまま4.3.0をリリースするところでした。危なかったです。(^^;
ありがとうございました。
NASの機種名ありがとうございました。また仕様を確認しておきます。
先ほど、1355を先行版としてリリースしました. またご確認いただければ有難いです。
また最初のトピックで言われていたTree Viewの更新が欠ける件、このリリースでも発生しているかどうかについても、お手数ですが確認していただけると助かります。
どうぞよろしくお願いします。
ありがとうございました。
ダンプファイルも受領しました。アップしていただいたほうのログからは、ご指摘の通り残念ながら得られるものはなかったのですが、ダンプファイルの情報は(たまたま)役立ちました。
1354でパス名の大文字小文字の厳密化を行ったのですが、正しいパス名を得るための手法が、ご利用のNASでは利用できないようで、空のパス名になり、結果としてその状態を「パスが存在しない」と判定して、削除していたようです。
このまま行けば今夜、つぎのリリースを行うつもりなのですが、ダンプファイルの原因も含めて、この件を対処してリリースしようと思います。またその旨、ここでご連絡しますね。
ちなみに、なのですが、ご利用のNASの製品名を教えていただけないでしょうか?
すこし状況が(良いことと、悪いことと)変わりました。
良いことは、わたしの環境ではストアに対して以下の設定を行うことで問題を回避することができるようになりました。
Microsoft Storeアプリを起動し、右上の「・・・」から「設定」を選択、「購入のサインイン」を「オン」にします。
これをオンにすると、その場でサインインが求められ、その後TuneBrowserでアプリ内購入の機能を起動すると、問題なく動作するようになります。ただし、その後は他のアプリでもサインインを求められなくなりますので、それが気になる方は、あとでこの設定を元に戻しておいてください。
悪いことは、この件でマイクロソフトと見解が合わず、UWP版の更新が止まってしまっています。マイクロソフトはTuneBrowserの問題だと言っているのですが、わたしからは(処理を確認した後)上記の設定で回避できることもあり、WindowsのおそらくFall Creators Update以降の問題ではないかと申し入れしています。
先方の連絡待ちですが、何らかの結論に至るまでには、ひょっとしたら時間がかかるかもしれません。最悪の場合、TuneBrowserからのアプリ内購入機能を削除することも検討します。
こんにちわ、ご連絡ありがとうございます。
数年前に同様の現象を起こしたことがあるような記憶があるのですが、4.3.0.1354でまたそれが発生しているとは気がついていませんでした。クロール関係の改修が影響しているのだと思います。お知らせいただき、ありがとうございます。
現象が発生したら、以下の要領でログをコピーしていただき、トピックの返信の添付ファイルにあげていただけないでしょうか。
TuneBrowser上部のメニューから「表示」「ドッキングウィンドウ」「Log View」を選択します。
TuneBrowserの下部にLog Viewが開きます。このLog Viewの下側に、さらにタブが並んでいますので、「Crawler(Periodic)」を選択します。
この内容は、マウスの右クリックで選択、コピーができます。テキストファイルに保存していただき、アップしていただけると助かります。
よろしくお願いします。
設定画面の左側のツリーのいちばん上をクリックしていただき、右側の項目のいちばん上「音楽ファイルのフォルダ」がそれに該当します。この項目を選択すると、右側に「…」というボタンが現れますので、これをクリックしていただくと、最初にインストールしときと同じ、音楽フォルダの指定ダイアログボックスが表示されます。
ありがとうございます。
とくに、4.3.0では「ダンプファイル用の動作記録の効率を改善し、さらにCPU負荷を低減しました.」の件がかなり改善に貢献しているので、個人的にはこの点は結構 自己満足しています。(^^;
こんにちわ。ありがとうございます。
今朝からずっと追いかけているのですが、再現ができず、思い当たるフシもなく、おっしゃるように前バージョンとの齟齬かも、ということで様子を見ていただくしかないかもしれません。
これを追いかける過程で、状況によって問題があるケースを見つけて改修しているので、近日リリースはすると思います。
ありがとうございます。
ご指摘の通りで、ですからツリー単体の問題ではなく、アーティストの認識の問題だと捉えました。
TuneBrowserは、アーティスト名は
ALBUM ARTIST; ALBUMARTIST; ARTIST
の順で検索し、最初に値の入っていたタグを使用します。そのため、ALBUMARTISTに適切な値が入っていたとしても、ALBUM ARTISTにゴミデータが入っていると、ゴミデータが表示されます。
今回はそのケースにぴたりとハマりますので、このケースだろうと考えたのですが、お送りいただいたデータは全アルバムともアーティスト名は問題なく表示されました。
とすると? というのはまた今後です。
ちなみに、nikuyamaさんのところではもう二度と再現しないですよね?
ですので、５ツのアルバムのうち２ツにタグの不整合・ゴミなどがあったのであれば、この同期でも現象が出たPCと同じようなツリー表示になるのではないかと思います・・・
なるほど、おっしゃることがわかりました。
ファイル受領しました。追って調べてみます。
あ、大きすぎるかもしれません。
ファイル一個だけで結構ですので、お願いします。
到着していませんでした。
手づくりスクリプトですので、なにか不備があるかもしれないですが、ほかの方のファイルは到着していますので、すいませんがファイル名を変えるなどして、試してみていただけないでしょうか。
こんにちわ。
そのフォルダは、TuneBrowserの管理対象として登録しているフォルダでしょうか?
続報ありがとうございます。
TAGSCANNERの出力は、おそらくすべてのタグを表示していないのではないでしょうか。”albumartist” のカラムが “ALBUMARTIST” を示しているのだとしたら、これとは別に “ALBUM ARTIST” というタグが混入していて、そこにスペースあるいはゴミデータが含まれているのではないかと推察しています。
「TuneBrowserを再起動したら正しく表示された」との情報で理解できたのですが、TuneBrowserはファイルからタグを読み取ったあと、データベースに書くときにゴミデータを除去して書き込みます。ただしその後画面に出すときには、ファイルから読んだデータをそのまま利用しているため、ゴミデータを含んだ状態で表示されてしまいます。次に再起動したときには、こんどはデータベースから読み込むため、ゴミデータが除去されていて、正しく表示されたのだろうと思います。
これは、次のリリースのときに、ファイルから読み込んだデータそのものをスクリーニングするように動作を変更したいと思います。ただ、いまちょっと4.3.0 UWP版の件でマイクロソフトと調整中で、4.3.0を更新できるか、4.3.1になるかはすいませんが微妙です。
確認してみたいので、お手数ですが、ファイルを送っていただけますか。この後、ご登録のメールアドレスに送信方法をお送りいたします。
こんばんわ。
続報のほうのスクリーンショットのステータスバー部分の表示から察するに、ALBUM ARTISTまたはALBUMARTISTタグのどちらかにスペースが入っていて、それが表示されているのではないかと思います。
ご確認いただけないでしょうか?
P.S. 最初のポストの添付ファイルには、バージョン情報ダイアログにnikuyamaさんの本名と思しき情報が表示されていたので、私のほうで削除しました。
あー、よかったです。
速報、どうもありがとうございました。感謝します。
遅くなりましたが、先ほど先行版4.3.0.1354を公開しました。
お時間のあるときに、見ていただけると助かります。どうぞよろしくお願いします。
こんばんわ。
検証の件、ありがとうございます。助かります。先ほど、本件に対応した先行版を公開しました。
設定画面の
- 左側のツリー:「基本の設定」
- 右側の項目 :「登録に関する詳細設定」-「ファイルのタイムスタンプは最新を使う」
ここをNoにしていただくと、更新日時だけを見るようになります(ちょっと設定項目名がへんですが)。
お手数をおかけしますが、ご確認よろしくお願いします。
HAlkさん、こんばんわ。ファイルの送付ありがとうございました。
TuneBrowserは、MP3ファイル内の無効フレームが10,000以上あるとエラーと見なしていたのですが、お送りいただいたファイルは10,320個の無効フレームの後、正常フレームがつづいていました。
先ほど更新した先行版で、無効フレームの上限値を10,000から30,000に変更しておきましたので、よろしければお試しください。読み込めると思います。
お手数をおかけします。
今晩を予定しています。
こんばんわ。
ドライブの交換というのは、そう頻繁にあることでもないと思いますので、設定で切り替える機能を用意したとして、果たして使っていただけるのだろうか、という点が正直なところもうひとつピンときません。。設定のデフォルトは作成日時と更新日時の新しいほう、という現在のやり方になると思います。
機能の追加そのものはそう難しくないので、次のリリースに入れたいと思いますが、ドライブ名が同じでファイルの更新日時も同じで、作成日時だけが異なるという検証環境の用意がちょっと難しいかもしれません。
お手数をおかけするのですが、リリースの際には動作確認をお願いしてもよろしいでしょうか?
以前にどこかに書いたような気がしますが、WASAPIで排他モードをご利用の場合、その名の通り、排他モードで動作しますので、あるアプリがそのデバイスを使用している間は、他のアプリはそのデバイスは使用できず、音が出せなくなります。
もしWASAPI排他モードでご利用の場合は、共有モードを使用するようにしてください。
ASIOをご利用の場合は、排他になるかどうかは、ドライバメーカー次第です。その場合もWASAPI共有モードに切り替えてご利用いただければと思います。
4.2.4で、画像のキャッシュの方法を変えたのですが、そのせいかもしれませんね。
4.2.4以降は使えない、4.0.2をご利用になるという結論を出されたとのこと、作者としては残念ですが、それはそれでわかりました。そのまま4.0.2をご利用いただければと思います。
また、もし将来、4.2.4以降をご利用になることがある場合は以下の設定変更を試してみてください。設定画面の、
- 左側のツリー:「基本の設定」-「性能に関する設定」
- 右側の項目 :「画像に関する設定」-「ローカルディスク上のキャッシュ」-「キャッシュにヒットした場合は追加画像は読み込まない」
ここがNoになっていると思いますが、Yesに設定します。説明にある通り、動作が高速になると思います。
わかりました。わたしの知らないMP3のファイル形態があるのかもしれません。
すぐには見れないかもしれないのですが、お手数ですが送っていただけますか。メールで検証用ファイルの送信方法をご案内します。
仔細のご報告ありがとうございます。
今回、TuneBrowserのパス名の大文字小文字の区別の仕方が一部で中途半端だったという点に問題があったと思っています。大文字小文字だけが異なるファイルが登録された場合、二重に登録されて、本来のファイル名とは異なったほうのエントリが置き去りになることがあります。そしてnikuyamaの環境ではそれが「タグ変更が反映されない」エントリとして見えていた可能性があります。余波ではないかというのはそういう意味です。
今回のご報告も含めて、まずは大文字小文字の区別を厳密に取り扱えるようにして、それで様子を見ていただくということでお願いできればと考えています。
いろいろお手数をおかけしますが、どうぞよろしくお願いします。
ひと段落するときがきたら、Fostexに検証用の機材を貸してもらえないか、頼んでみましょうか。。
こんばんわ。
たしかにTuneBrowserは作成日時と更新日時の両方を見て、新しい方を採用しています。
ファイル更新の判断は更新日時だけ見れば充分ということでしょうか?
(ファイルサイズは, 音楽ファイルの場合タグのパディング領域があるので、更新有無の検出には使えないと思います)
4.3.0がずっと先行版のままですので、ちょっと焦ってます(^^;。
これ用に、壊れてもよいポータブルHDDも調達してきました。
Deleted, New File 云々の更新メッセージが出たことです
大文字小文字の区別が効いたとか、そういうことなのかなとも思いました。
お忙しいところご確認ありがとうございました。
3分くらいの「ひと休み」は、私が考えていたものとはちがっていました。TuneBrowserを起動して、ドライブをマウントしたときには、以下の順番でクロール処理が走ります。
- ドライブマウントに対応したイベントクロール
- 起動後のクイッククロール
- 定時のフルクロール
これら3つは連続して動作するわけではなく、それぞれにタイミングに基いて動作します。おそらく1.2.3のどれかが走って、その後次の1.2.3のどれかが走ったのを目撃されたのだと思います。
本日ご確認いただいた状況は、問題なさそうと受け取りました。
その前にいただいた、
- 管理フォルダの大文字小文字が変わった場合の処理
- ジャンルの検出漏れ
このふたつを順番に片付けましょう。2.は1.の余波の可能性もあります。
1.のほうは、思いがけず大手術になっています。昨晩からずっと改修をつづけているのですが、なかなか手ごわいです。
あー、管理フォルダそのものの名前の大文字・小文字を変更されたのですね。わかりました。その観点は抜けていたかもしれません。
ジャンルのほうは、ひょっとしたらその影響かもしれません。
ありがとうございます。
検出されない問題ですが、前回の例でご提示いただいたフォルダ構成は変わりませんか?
e:\files\flac\xxxxxxxx e:\files\MP3\xxxxxxxxこのときに、管理フォルダとして登録されているのは、”e:\files” ですか、それとも “e:\files\flac” ですか。
あと、ジャンルのほうですが、楽曲形式は何でしょうか(MP3, FLAC等々…)? ジャンルを編集したのはTuneBrowserですか、それとも別のソフトですか? 別のソフトの場合、そのソフトはジャンル番号かジャンル文字列のどちらを書き込んでいるかおわかりになりますか?(TuneBrowserはジャンル番号は認識しません)
別のトピックでもご報告されているような、認識されていなさそうなファイルがある場合、そのファイル/フォルダをTuneBrowserにExplorerからドロップすると、TuneBrowserはそのファイル群の情報を読み込んで更新します。そうした操作を行ってみていただけませんか。それでも古い情報のままでしょうか。
ありがとうこざいます。正直なところ、これ以上は実機がないと難しいかもしれません。。
TEACの新しいの、この価格でこのスペック、よさそうじゃないですか。(^^) わたしはいまもUD-501を持っていますが、最近使っていないこともあり、買い替えてみようかな、と思いました。まだ決めていませんが。
こんばんわ。
エラーの内容にある通り、無効なフレームが多数検出されているのでエラーと判定しています。
もしこのファイルは再生できるはず、ということであれば、調べてみますので、その旨コメントいただけますか。楽曲ファイルの送信方法をメールでご案内します。
ご確認いただき、ありがとうございました。
いったん、これで行ってみましょう。
おそらく、Chartreuxさんがいま一番お詳しいのではないかと思いますが…。(^^)
あの複雑な書式設定を使いこなしていただき、感無量です。
先ほど先行版を更新したのですが、すいませんがこのFostex対応は力尽きてしまい、対応ができていません。
確認ですが、現在の状況は、
- Fostexドライバを使用している場合は、WASAPI 排他Eventモードで正常に再生されない.
- Microsoftドライバであればすべて正常に再生される.
- どちらも、WASAPI排他Pushモード以外では再生開始時にDECDインジケータが点灯する.
で合っていますでしょうか?
先ほど、本件に対応した先行版をアップしました。
ご確認いただければ幸いです。
先ほど、この件を対応した先行版を更新しました。
またお試しいただければ幸いです。
先ほど、高速化した先行版をアップしました。
GUI更新部分は以前とやり方を変えたので、以前とはちがう次元の動作になっていますが、そのぶん不具合がある可能性もあります…。
それと、大文字小文字問題も対処してあります。
どうぞよろしくお願いします。
こんにちわ。
UWP版のダウンロードに際しては、64bit/32bitのCPUアーキテクチャは判別できるのですが、それ以上に細かいCPUの仕様は指定できません。そのためWindows 10が古い(AVX2をサポートしていない)CPUで動作しているかぎり、AVX2対応版をUWP版として配布することはできません。
また、UWP版としてストアで取得されたライセンスは、UWP版専用になります。ストアからは購入者の個人情報は開示されないため、わたしのほうでライセンスキーに変更することもできないです。
あまり良い内容でなく心苦しいのですが、ご了承いただければ幸いです。
よろしくお願いします。
hiroさん、こんにちわ。
音量に明確な差が出ているとしたら、BitPerfectでないときに、ReplayGainとかボリュームとか、そのあたりの設定が有効になっているのかもしれません。
yubeiさん、こんにちわ。
現在のTuneBrowserの動作を確認しました。現在は、Resamplerの32bit演算はあくまでも途中経過として扱っていて、16bit Source -> 32bit Resample -> 16bit Result ということなっています。これはyubeiさんご認識の通りだと思います。
そこでResamplerの結果の扱いを変えて、16bit Source -> 32bit Resample -> 32bit Result と変えてみたのところ、べつの課題が出てきました。
ASIOとちがい、WASAPIの場合、ソフト側から再生スペックを指定します。44.1kHz/16bitのソースに対してBase x2の設定で手許のRealtekで試してみたところ、本来は88.2kHz/32bitで再生したいところが、対応しているサンプルレートに限りがある(88.2kHzに対応していない)ため、
- 16bit Resultの場合 : 96kHz/16bit 再生
- 32bit Resultの場合 : 48kHz/32bit 再生
となりました(自分で作ったソフトに対して「なりました」というのも変ですが)。
これは、再生処理側としては、目的のサンプルレートで再生できない場合、bit深度を維持しつつできるだけ目標サンプルレート(88.2kHz)より高いサンプルレートでの再生を目指した結果で、今回のRealtekは16bitでは96kHz、32bitでは48kHzまでしか再生できなかったという結果になります。
わたしももうすこし考えますが、ちょっと面倒なことになっています。元が16bit Sourceだということも考慮した上で、ちなみに上記の1.2.ではどちらが良いですか?(^^;
なおこれは、デバイスが88.2kHzの再生に対応していなかった故であり、一定の機能以上のDACであれば、88.2kHzも再生できると思うので、このような問題は発生しません。
そうしてみました。
もしまた他の方からのご意見があれば、すいませんがそのときに改めて検討するということにさせてください。
現在は、トピックが作られた順になっているのですが、更新があった順のほうがよさそう、という話でしょうか。
簡単に設定を変えられそうなので、そうしてみましょうか。
DRINKING BIRDさん、こんばんわ。Naosさん、どうもありがとうございます。
Album Viewの上部のツールバーのドロップダウン▽とか、いろいろなものが依然欠落していますね。
どうも、「Windows 10 1709 (Fall Creators Update)でWin32 APIのGetPixel()が遅くなった」問題への対処でしくじっているようです。
泣けてきます(^^;。調べます。
Europaさん、Chartreuxさん、こんばんわ。
Chartreuxさんがフォローしてくださった内容以上に、わたしから加えることはありません。処理に問題がないかどうか、また確認をしておきます。
「アルバム２」のフォルダをExplorerからTuneBrowserにドロップしたら、どうなりますか?
とくに変えた覚えはないのですが…。
ただセキュリティ対策のため、断続的にバージョンアップをしているので、その余波があるのかもしれません。
たしかに編集できないトピックがありますね。
見当もつかないのですが、調べておきます。
対応については検討しますね。ヘルプにはいちおう、ファイル形式ごとのタグの対応は書いてあります。
それと、トピックのタイトルを変更させていただきました。ご了承ください。
こんばんわ、
たしかにリサンプル処理を32bitでやっておいて、出力時に(元の形式が16ビットだから?)16ビットというのはちょっとおかしいような気がしますね…。ちょっといま慌ただしく、すぐにはとはいかないのですが、近日改めて動作を確認したいと思います。
取り急ぎ。
こんばんわ。
途切れずにクロール処理しているものの、クロール進捗情報窓（半透明のやつ）が一定時間で消えて何かのタイミングでまた表示再開されるので、処理が途切れているように見えているだけでしょうか。
その可能性はあると思います。
ただ、今回はクロールの並列化を行ったということなので、いっぽうでGUI側の更新速度にも課題は残っているのだと思います。GUI側のキューがいっぱいになると、Crawlerは安全のためGUI更新を待つようになっており、それが「待ち」に見えている(というか「待ち」そのものですが)可能性も高いです。
ということで、いまGUI側の更新性能を上げられないか、あれこれやっています。ここは並列化のような力技はできないので、現状動作の分析とそれに対する知恵がどれだけ出せるかということなのですが、基本そんなに頭が良くないので試行錯誤です。
みなさん、どうもありがとうございます。m(__)m
他項でもすでにフォローいただいていますが、それを拝見すると、ちょっと涙ぐみそうになるほど感激です…(・・、
ぜひともご支援いただけると大変助かります。
Chartreuxさんご指摘のこのサイトの構成については、たしかにその通りですね。ソフトは作れてもWordPress(bbPress)は初心者で、試行錯誤しながらの状態です。また時間を見つけて改善したいと思います。
こんばんわ。
ヘルプのタグのマッピングのところに書いてあるのですが、MP4(ALAC)形式はあまりタグが充実しておらず、ファイルに保存できるタグは限定的です。
最初の保存時にはデータベースに格納された値が表示されるのですが、次のクロールや、今回行われた「データの更新」で、ファイルの内容に戻ってしまうため、タグの内容が消えたように見えます。
ファイル形式ごとに保存できるタグが異なるというのは、基本的な話だと思ってエラーなどにはしていなかったのですが、ひょっとしてあまり良くないですかね?
Thanks! (^_^ヾ
Thank you for your comment.
I know that Chinese version is requested also in the Microsoft Store Reviews. To translate into Chinese, it is nessesary to translate from Japanese directly, or from Japanese to English and from English to Chinese. But I have no friend who can speak Chinese, so translation is very difficult for me now.
TuneBrowser seems to be used widely by Chinese speakers (many thanks!). I hope it will be translated into Chinese in someday.
Thanks.
ありがとうございます。
別PCで変更ずみのHDをPCに接続してTBを起動したときの検知速度
問題なのは、ドライブをマウントしたときの動作速度なのですね。こちらのほうは、定期クロールを再起動して、そのままそれに任せた状態になっていました。イベントクロールで処理するように変えてみます。
TBの場合はあるディレクトリについて更新したらちょっと休んで別のディレクトリについて更新して、また休んでみたいな動きをします
まだ本当にそのような動作をしていますでしょうか? この点は、このひと月ほどでだいぶ改善したと思うのですが…。
クロールの動作速度は、HDD/SSD/NASといったデバイスの種類や、SATA接続/USB2.0・3.0/100Mbps・1Gbpsかといった接続形態、さらにデバイスとOSのキャッシュの状態によって大きく変わります。そのため、nikuyamaさんご所望の評価基準の設定というのは残念ながら困難です。
大切なのは、nikuyamaさんが、ここで「もう少しなんとかなならんかなとの印象です」と言われていることだと思います。TuneBrowserのクロール処理が使い物にならないという状態で、終わらせたくはありません(くじけそうですが)。
ありがとうございます。お手数をおかけしました。
取り急ぎ、御礼まで。
こんにちわ。確認いただいてありがとうございます。
おそらく、ディレクトリ名の変更は\flacから\FLACへと大小文字の変更であり、TBはUpper・Lowerの違いを区別していないからではないかと推察される。
えっと… フォルダ名の大文字小文字の変更で多重登録が発生する、というのは今回新しい話ですよね? 1月上旬ごろに問題にされていた、イベントクロールの動作速度のほうはいかがでしょうか?
それで、フォルダやファイル名の大文字小文字の区別の件なのですが、この現象は以下の状態のため発生します。
- OS(Windows)は大文字小文字を区別していない.
- TuneBrowserは大文字小文字を区別している.
OSのほうの仕様はよくご存知だと思いますが、TuneBrowserの仕様のほうは、これは動作中のさまざまな文字列比較時の効率の問題で、このようにしています。OSとTuneBrowserでここが合っていないというのは、もちろんあまりよろしくはないのですが、実際にはユーザがパス名を手入力するケースはほとんどなく、発生してもデータベースのエントリを消してもらえばいいだけの話ですので、開発着手時から8年間、この効率優先のままです。
これまであまりこの辺の仕様については、説明できていなかったかもしれないですね。質問されたこともなかったですが…。
今回やられたようなケースへの対策は、また別の課題として検討していきたいと思います。まずは基本的なクローラの動作を確定したいと思っていますので、1月ごろお話しになっていた観点で見ていただけると助かります。
いろいろとお手数をおかけします。どうぞよろしくお願いします。
WAITインジケータが “DECD” で点灯する件、 DECDということは、デコーダ待ちが発生しています。
WASAPIの方式のちがいでそれが発生するのは、たしかに腑に落ちないですね。
よろしければ、Playerのログを添付ァイルにアップしてもらえないでしょうか(本文でも良いですが)。
TuneBrowser上部のメニューの「表示」-「ドッキングウィンドウ」-「Log View」を選択いただくと、メインウィンドウの下部にLog Viewが表示されます。
このLog Viewの下部にさらにいくつかタブがあり、「Player」部分を選択すると、再生に関するログが見れます。この内容は、マウスの右クリックで選択、コピーなどができます。
お時間のあるときで結構ですので、どうぞよろしくお願いします。
Chartreuxさん、ありがとうございます。
良いと言っていただけるのはいつでも嬉しいです。(^^)
色々手を加えすぎて何かの拍子に音質が悪くなってしまったりしない事を祈るばかりです。
まったくです。気をつけます。
ありがとうございます。
参考にさせていただきます。
念のため、の細かい話ですが、ここで応対させていただいているのは、ライセンスを購入していただいたからではありません (ライセンスはサポート費ではありません。もし何らかの尺度でサポート費を定めたとしたら、いまのライセンス体系ではまったくまかなえないと思います)。
ただ、ライセンスを購入していただいた方がおられなかったら、まちがいなくTuneBrowserの開発はここまで来れていなかったと思いますので、大変感謝しています > ALL m(__)m
ありがとうございました。
ありがとうございます。お手数をおかけしました。
本当にご確認いただきたかったのは、TuneBrowserが認識している名前 (たとえばPlayer View右下に表示されている名前) なのですが、たぶん同じ名前ですよね?
わたしの確認の仕方がアバウトで失礼しました。
ありがとうございます。
ご無理をなさらず、お時間のあるときにお願い致します。
tanaさん、こんばんわ。
「感想・雑談」トピックは、最初は考えたこともあったのですが、1)閑古鳥が鳴くような状態になったらどうしよう、2)話題がモラルの範疇を超えるようなことが起きたらどうしよう、というようなことを考えて、設置は見送っていました。
こちらのフォーラムは「ご意見、ご感想、ご質問」と謳っているのですが、たしかに質疑が主となっていて、単なる感想は書きづらいかもしれませんね。作り手としてはその「感想」をぜひともお伺いしたいとは思っているのですが…。
すこし考えてみます。
ご確認ありがとうございました。
AVアンプのケースは、先に例に挙げたChordと同様、ユーザの意図しない操作などで破裂的な音が出ないように、という考慮なのではないかと推察します。Chordの場合は、あらかじめ無音を送ることで回避できましたが…。
ダメでしたか… (__;
どうもお手数をおかけしました。
細かい点を確認して恐縮ですが、今回はFostex固有のドライバをご利用にならなかったとの由、その状態でもデバイス名には”Fostex”の文字列は含まれていますでしょうか? ドライバ名にこの文字列が含まれていたら4.2.3と同等(と思っている)の状態で動作するようにしていますので、念のための確認です。
また4.2.3でも発生する条件については、事象としてはまずは了解しました。
ご心配おかけしてすいませんでした。すでに復活しております。
発熱で寝ている間、何度もクローラの夢を見ました(^o^;。TuneBrowserが使い物になるかどうかのところにいると理解していますので、何とかこれで実用になるとよいのですが。
ご確認いただき、ありがとうございました。(^^)
補足です。
もしDAC側が、何らかの理由(省電力など)で、無音でないデータをトリガにして動作を開始するような場合は、残念ながらこのやり方は効かないことになります。アクディブスピーカー系で、そのような動作をするものを見たことがあります。
こんばんわ。お試しになられた状況は わかりました。ありがとうございます。
もしDAC側の事情でしたら、以下の設定で抑制できるかもしれません。
設定画面の
- 左側のツリー:「再生の設定」-「再生の詳細設定」
- 右側の項目 :「自動無音再生」-「方式の切替り時」-「再生開始時にはいつも実施」
ここをYesにしていただくと、再生開始時に、その上の項目にある無音再生時間分、無音データを送出します。
一度お試しください。
pontaさん、こんにちわ。
このトピックで議論されたような内容は、お試しになられたのでしょうか?
こんにちわ。しばらく反応できず、失礼しました。
iOS版のKazooをご利用とのこと、了解しました。
言葉の定義の問題なのですが、「プレイリスト」と言われているのは、Kazoo(iPad版)で言うと、右側からスワイプして表示されるリストのことですよね。ここで、
アルバムの1曲目のみアルバムアートが表示され、２曲目以降は表示されないことが多いです。
とのことですが、これはKazooの仕様上、同一アルバムであれば先頭の曲だけアルバムアートが表示され、2曲目以降は表示されないようになっているのではないでしょうか? ちょうどTuneBrowserのトラック一覧表示やプレイリスト表示のような形です。
Kazooでは、アルバムをブラウズしているときなど、たしかにときおりジャケット画像が欠けることはあるものの、あまり派手に欠落するようなことはないと思っているのですが…。
大量の楽曲を一度に再生しようとすると、その準備に時間がかかるのは、HTTP(SOAP)ベースのネットワーク通信を介しているので、ある程度仕方がないことだと思います。
こんにちわ。
先ほどリリースした先行版4.3.0.1351で、ピークラインの無限大対応を入れてみました。滞在時間を0にすると、無限大の意味になります。
お時間のあるときにでも、お試しください。
こんにちわ。
しつこく(^^;さらにFostex対応を入れてみた先行版4.3.0.1351をリリースしました。何度もすいませんが、お時間のあるときにでもお試しいただけると有り難いです。> ALL
こんにちわ。体調はかなり普通になりました。(^^)
先ほど、本件について対処した先行版4.3.0.1351をリリースしました。
お時間のあるときにでもお試しいただけると有り難いです。
先ほど、本件について対処した先行版4.3.0.1351をリリースしました。
お時間のあるときにでもお試しいただけると有り難いです。> ALL
こんにちわ。
先ほど、クローラの取りこぼし対策を強化した先行版4.3.0.1351をリリースしました。お時間のあるときにでもお試しいただけると有難いです。
よろしくお願いします。
こんにちわ。
Recording Data、Release Dateなどの日付タグは数字の年の4桁のみ対応で、例えば20180210(2018年2月10日)といれても月・日の部分は無効という解釈でよろしいのでしょうか?
そんなことはないのですが、どこかにそう書いてしまっていましたか? それとも他のソフトの動作からの推定でしょうか?
個人的には日付は “2018-02-10” のように、ハイフン区切りのISO形式で(多少なりとも理屈があるということで(^^;)統一するのがオススメです。
tanaさん、回答下さったのはNaosさんですので、念のため。(^^)
Naosさんの指定方法は、デフォルトで取り込ませてもらってもいいかな、と思いました。いま4.3.0の次の先行版の準備をしていて、それには間に合わないのですが、また検討させてください。
ありがとうございました。
こんばんわ。
Naosさん、ありがとうございます。あの複雑な書式設定を使いこなしておられて、かなり感激です (^o^)。
tanaさん、別項のこちらのほうですが、ご確認いただけましたでしょうか。もしご確認いただけたら、ひとことその旨をご返信いただけると有り難いです。よろしくお願いします。
ありがとうございます。
クローラの機能として退化している、ということですね…。無念ですが、もう一度見直してみます。
前回のお話はこれですね。
このときにお応えしたときとあまり状況は変わっていませんが、いま現在の最大の懸案であるクロール精度・性能の問題と、再生系の問題がすべて片付いたら、(偉そうな言い方で誠に恐縮ですが)検討するかもしれません。
このサイトの右側のガジェット類の一番下に、”Search Forum” というフォーラム内の検索機能がありますので、よろしければご利用いただければと思います。
herazikaさん、こんばんわ。
ご確認いただき、どうもありがとうございました。ホッとしました。
また追加で設定を試していただき、素晴らしいです。(^^)
ご利用のCore i5-3210Mは、2コア4スレッドのCPUのようですが、今回の事例を参考に、コア数をベースにデフォルト値を決めるような処理を検討しようと思います。
わたしのほうも大変参考になりました。ありがとうございました。
皆さま、どうもありがとうございます。
解像度を変更すると表示されなくなるようで、同様の事象をわたしの環境でも確認できました。
開発環境更新の煽りを受けたような感じです。近日修正したいと思いますが、当該の部分はあまりに長いあいだ触っていなかったので、ちょっと気が遠くなっています。(^o^;
こんにちわ。ご連絡ありがとうございます。
ひょっとしたら、4.3.0で変更したクローラの動作が影響しているかもしれないです。
以下の設定で、クローラの動作が元に戻りますので、それで試してみていただけないでしょうか。設定画面の
- 左側のツリー:「基本の設定」「性能に関する設定」
- 右側の項目 :「Crawlerのパラメータ」「定期クロールも並列処理する」
ここがYesになっていると思いますが、Noに設定して様子を見てみてください。
どうぞよろしくお願いします。