フォーラムへの返信
-
投稿
-
こんにちわ。
その場合、曲を選択して、右クリックメニューで「画像の埋込み」といった項目を選択して、そうするとご提示いただいたようなダイアログが開く、というイメージでしょうか?
現在でも、右クリックメニュー(あるいは既定でCtrl+Eキー)で「エクスプローラで開く」という操作ができます。それは代替にはなりませんか?
こんにちわ。
実現するかどうかはともかくとして、時系列方向の波形データで、おなじ曲の演奏者のちがいなどが読み取れるものでしょうか? (すこし驚きました)
「波形」と言われているもののイメージが異なるのかもしれませんが…参考になるサイトなどがありましたら、後学のために教えていただけないでしょうか?
こんにちわ。
不勉強というかなんというかで大変申しわけないのですが、わたし自身はTwitterをやっておらず、「再生されている曲情報をツイート」がどういうものか、いまひとつ理解できません (#NowPlayingがハッシュタグだというのはわかります)。
再生中の曲を勝手に送信(公開)していいのでしょうか。
また実装方法ですが、たとえば外部のスクリプトを再生中のトラックの情報をつけてキックするような仕組みがあれば、なんとかなるようなものなのでしょうか (あまり積極的に公開していませんが、TuneBrowserはLuaにはすこし対応しています)。
おわかりになる範囲で結構ですので、ご教示いただけると助かります。
こんにちわ。
ご確認いただき、ありがとうございました。
Windows10のアップデートはたしかにおっしゃる通りです。怖いのは、最新のWindows10に対応したアプリケーションを作るということよりも、何らかの理由で開発環境が動作しなくなってしまうことです。
そのため、どうしてもWindows10の更新に先陣を切って追従する勇気が持てません(^^;。
こんにちわ。続報と訂正です。
まずTuneBrowserのタグ編集(プロパティ)で値を編集しても反映されないことがある件ですが、以下のようなケースだと発生しそうです。
あるタグがファイルには”0″と記録されていて、それがTuneBrowserのデータベースには”1″と登録されているとします。この状況は、ファイルが更新されたときに他のアプリよってロックされていたりすると、ふつうに発生します。
ここでTuneBrowserのタグ編集で(“1″だと思っているので)”0″に書き換えて保存すると、ファイルに書く前にファイルの内容を読み取り(その結果はファイルにある”0″です)、編集後の値”0″と比較して、変更がないために、実際にはファイルには書き込まれません。そしてファイルの更新がなかったためにデータベースへの更新も行われず、結果としてはデータベースには”1″のまま残ります。これは何回”1″に変更して保存しても、同じ状況がつづきます。
どうしたらよいか? というのは悩み中です。ファイル更新がなくてもデータベースに保存するようにすると、大量のファイルのタグ編集に対してごく一部しか変更していない場合でも、長い保存時間がかかってしまうことになります。GUI上で「編集した」という情報を覚えておいて強制更新しようとすると、全タグ・全データにそのフラグを加えることになり、あまりに効率が良くありません。
それから、右クリックメニューでの「データの更新」ですが、「いまは手動クロールとだいたいおなじ」と申し上げましたが、ひとつ大きなちがいがありました。手動クロールは一般的なクロールと同様、ファイルのタイムスタンプで更新判断をして速度効率を稼いでいますが、「データの更新」はユーザからの明示的な指示ということで、かならず指定されたファイルの読み取りを行います。
今回のケースでは、手動クロールや自動クロールでは、タイムスタンプが更新されないので読み取り損ねた”0″はいつまでも更新されませんが、データの更新を行うと、あらためてファイルを読み取ることでデータベースとの差異に気が付きますので、データベースの内容が”1″に是正されると思います。
あー、たぶん関係ないと思います。
Intelグラフィックドライバについては、メジャーバージョンが10未満であれば警告を出すようにしているのですが、送られてくるクラッシュダンプを見ていると、そうした古いバージョンのドライバをご利用の環境では、高確率でドライバ内でクラッシュしています。
チップセットやOSによっては新しいバージョンが提供されていないこともあるかもしれませんが、可能であれば更新されることをお勧めします。
すぐに反映される場合と、Update Databaseを実行しないと反映しない（「反映しない」とはツリービューのCompilation分類からいなくなること）場合があるのは何故ですか？
調べてみたのですが、基本的にはちがいはないはずで、すいませんが原因はわかりませんでした。
また、Update Databaseの役割がいまいちわかりませんので、どういうときに使うべきものなのか具体的に教えてくださいますか。
最新のリリースでは、この機能は実質的に「手動クロール」になっています。「実質的に」というのは、選択されたファイル群に対して、
- 管理フォルダ配下のフォルダにあればそのフォルダを
- 管理フォルダ配下になければそのファイル単体を
再クロールしていて、指定したフォルダ以下を無条件にクロールする手動クロールとはすこし動作が異なる故です。
これで説明になっていますでしょうか。
ご指摘ありがとうございます。
この機能はわかりにくいというお話しを過去何回かいただいていて、その迷いが出ていますね(^^;。
次のリリースまでに見直しておこうと思います。
余談ですが、このデータベースのメンテナンス/クリーンアップは、環境やレコード数によって一時的に「応答なし」となってしまうことが多く、次のリリースではその課題を改善しようと計画しています。
こんばんわ。
わたし個人もそう思うのですが、それはたぶん、こまめにチェックしていて、更新情報をまず知りたいと思うからだと思います。
はじめてそのトピックを読む向きには、現在の時系列順のほうが読みやすいと思いますので、このままがいいかなと考えています。
はい、たしかにスペルミスです。ありがとうございます。
この手のミスは、軽微なだけに書いたときに気づかなければ、思い込みで本人は気がつかないということになりがちです。ですので、ご指摘いただけると大変助かります。
手許のソースコードは修正しました。
こんにちわ。
先ほど4.3.1を公開しました。このバージョンで、無事UWP版の公開と、アプリ内購入が正常に動作するようになりました。
大変お待たせしました > ALL。
そうですね。
検討してみます。ありがとうございました。
ありがとうございます。(^^)
提供している側からのそうした情報の信憑性というのは、どうなんでしょうね。やはりなにかの足しにはなるのでしょうか….。
ハイ、ありがとうございます…。
以前にも同様の投稿がありましたが、今回も”may”という表現から、おそらくTuneBrowserのダウンロード数が少ないという理由で警告が出たのだと思います。弱小ソフトなのでしかたがないですが、残念ですね。
気になる方はUWP版をご利用ください > ALL。
こんにちわ。
ASIOの場合、ビット深度はデバイス(ドライバ)側が決めていて、アプリケーションから指定することはできません。そのためTuneBrowserは、デバイスから指定されたビット深度に合わせてビットシフトを行い、引き渡しています。
そうですね、あと「PROJECT.2nd」や「PROJECT-2nd」のように、ピリオドやハイフンを挟むようなやり方もありそうです。
ソート方法を切り替えることができれば、というお話しですが、こうしたソートはTuneBrowserの性能の根幹中の根幹を成しているためあまり分岐を入れたくない、ということと、単純な文字列ソートにしたとしてもあまりいいことはなく、むしろほかのタイトルの並びに違和感が出てくるような気がします。
前のコメントにも書いたように、自然言語とは言わないまでも、計算機的に正規化されていない文字列の並び順は、観点によってさまざまな是非の議論があります。TuneBrowserも歴代のリリースのなかで何度かやり方を変えており、Windowsに合わせている現在も決して完全ではないとは思うのですが、いまのところはこのソート方法がいいかなと考えています。
ご確認いただき、ありがとうございました。
改善してよかったです(^^)。
仔細の状況ありがとうございます。
うーん、これまであまり聞いたことのない事象です。前回のコメントで、WASAPIのPush/Eventモードの切り替えのお話しをしましたが、そのあたりは試されたでしょうか? (あるいは再現待ちでしょうか)
またASIOをご利用になった場合はいかがでしょうか。もし機会がありましたら、お試しいただければと思います。
こんばんわ。
ご確認いただき、ありがとうございました。
こんにちわ。
先ほど, 4.3.1の先行版を公開しました。お時間のあるときにお試しいただけると助かります。どうぞよろしくお願いします。
サンプルレートの違う曲をかけると「やがて再生できなくなる」というのは、もうすこし具体的にどういう事象を言われているのでしょうか?
念のため、WASAPIで、192kHz, 96kHz, 44.1kHzなどの曲の再生をためしてみましたが、わたしのところでは問題はなさそうでした。
WASAPIでは、ドライバによってはEventモードとPushモードで動作の安定性が変わるものもあります。そのあたりも切り替えてみてはいかがでしょうか。また、DACのドライバの更新などもご確認されてはと思います。
ご指摘ありがとうございました。
さきほど修正しましたので、ご確認ください。
失礼しました。> ALL
こんにちわ。
つけていただいたスクリーンショットを拝見すると、WASAPIの共有モードを使用されていて、そのために共有モード(Windowsの設定)で指定されたサンプルレートでしか再生できないようになっています。
スクリーンショットの右下の部分に「SHAR」と書かれた部分がありますが、ここをクリックしていただくと、「EXCL」に変わり、排他モードで動作するようになります。それで一度お試しになってみてください。
余談ですがブーレーズのマーラー、いいですね。わたしも結局、いちばんよく聴いているのはブーレーズの演奏のような気がします。
wanwan2811さん、こんにちわ。
ご連絡ありがとうございます。トラックが切り替わっただけで発生するとのこと、そのヒントで改めて確認したところ、怪しそうな点が見つりました。DSD/DoPでの再生時のみ、トラックの切り替えで一瞬再生が途絶える可能性があります。Change Logでいうと、「DoPでの再生時, ひとつのプレイリスト内でDSDからPCMに移行したときにノイズを発生することがある問題を改善しました」の変更が該当します。この変更の副作用で、DoP→DoP / DSD→DSDの場合に再生が一瞬途絶えます。
もし先行版リリースの違いをすでにお試しいただいていたとしたら、お手数をおかけしたのですが、おそらく1351(正常)と1352(リレー音する)の間で差分が出ていたのではないかと思います。
DSD再生全般にかかわる可能性のある問題ですので、できればこの件を改善した版を今日中に先行版でリリースしたいと思います。そのときにはまたここでご連絡します。
どうぞよろしくお願いします。
こんにちわ。
イメージをつけていただき、どうもありがとうございました。よく理解できました。
やはりスクロールできないと話にならないですよね…。Player Viewの部分は、TuneBrowser独自のウィンドウスタイルで作成しているのですが、その中間位置に部分的なスクロールをつけるのは、技術的な難しさもありますし、人によってさまざまな大きさ・形式でご利用になっているので、整合性を保つのが甚だ困難だと思われます。
やらないと決めているわけではないのですが、やはりやるとしてもどのような形で表示するのが良いのか、もうすこし考える必要がありそうに思いました。
あまり良い返信でなく恐縮ですが、ご理解いただければ幸いです。
こんにちわ。
できればタイトルの順にきれいに並べたいのですが、
きれいに、と言われているのは、
○○○ ０１ ○○○ ０２ ○○○ ０３ ○○○ ２ ０１ ○○○ ２ ０２ ○○○ ２ ０３というような順番のことを言われているのでしょうか?
おそらく、現在は
○○○ ０１ ○○○ ０２ ○○○ ２ ０１ ○○○ ２ ０２ ○○○ ２ ０３ ○○○ ０３という順番で並んでいるものと思います。これは、Windowsではエクスプローラなどで一般的に行われている並び順にちかく、数字の部分の大きさを評価しています。
並び順は、世間でも目的によって妥当性の議論が果てしなく繰り返されてきているような気がしますが、TuneBrowserでは、さまざまな使い勝手を考慮して、現在の並び順が適切と判断しています (ほかにも、大文字小文字や欧州系言語のアクセント、ウムラウトなども考慮します)。
例示された番号の意味はわからないので外しているかもしれませんが、たとえば、
○○○ ０１ ○○○ ０２ ○○○ ０３を
○○○ １ ０１ ○○○ １ ０２ ○○○ １ ０３のような名前にして管理されるのが良いようにも思いますが、いかがでしょうか。
こんにちわ。
すべて同形式のDSF 5.6MHzとのこと、了解しました。
同じようなことを何度も確認して申し訳ないのですが、あるアルバム内の一連の楽曲を再生しているとき、通常であれば次のトラックに移るときには、ギャップレス再生を行いますので、DAC側から見ると曲の切れ目には見えないようになっています。その状況で、リレー音が聞こえるのでしょうか?
それとも、曲の途中で操作して次のトラックに移ったり、べつのアルバムを再生したりしたときに発生するのでしょうか?
また、もしRAMDecodeをご利用でしたら、自動モードの場合、1曲ごとに再生を停止してRAMへの読み込みを行い、再生を再開するという動作を行います。そのときには恐らくリレー音は発生すると思います。そのため一度RAMDecodeを切ってお試しいただけないでしょうか(ただ、このあたりの動作は最近のバージョンでは変わっていないので、関係ない公算も高いです)。
1351前後のプログラムを一段階きざみで、試してみることも可能なのですが、
お手数をおかけするのですが、お願いしてもよろしいでしょうか?
以下に、過去の先行版へのリンクを貼っておきます。
TuneBrowser(x64)Setup4.3.0.1351.exe
TuneBrowser(x64)Setup4.3.0.1352.exe
TuneBrowser(x64)Setup4.3.0.1353.exe
TuneBrowser(x64)Setup4.3.0.1354.exe
TuneBrowser(x64)Setup4.3.0.1355.exe
TuneBrowser(x64)Setup4.3.0.1356.exe
TuneBrowser(x64)Setup4.3.0.1357.exeお試しいただけると大変助かります。
どうぞよろしくお願いします。
※ ダウンロードリンクは削除しました.
優先的に表示するのは、以下のような順番です。
- フォルダ上の画像ファイルをジャケット画像として表示する際に, 以下の優先度で適合したファイルを使用するようにしました (ベース名とは、ファイル名から拡張子を除いた部分の名称です).
- ファイル名が ALBUM タグの値と同じベース名の画像ファイル
- 再生中の楽曲ファイルと同じベース名の画像ファイル
- 以下、ベース名が folder, front, cover, album の順
あとはファイル名順だったと思います。
こんばんわ。
歌詞の表示は、これまでにも何人かの方からお問い合わせいただいたのですが、わたし自身がまったく使用しないのと、それから表示場所の問題があって、対応する予定はありませんでした(UNSYNCEDLYRICSを詳細表示に表示したりすることは、現在でも設定の変更だけでできますが)。
表示場所を「アルバムアートワーク画像の右側」と言われていますが、そこはトラックタイトルなどが表示されているところですよね。歌詞の表示はそれなりに幅が必要だと思うのですが、そうすると、トラック情報類を表示しないような感じで、と言われているのでしょうか。
それと、Player Viewの場合、既定では横長の表示で高さがあまりありません。その場合、歌詞の上のほうの部分だけが表示されていればよいという感じなのでしょうか。スクロールとかそういった操作は必要になりませんか?
こんにちわ。
Playback Queque画面で、現在再生している曲にジャンプする方法があれば
教えてください。ちょっと考えてみたのですが、それに該当しそうな機能は思い出せませんでした。その機能をつけることは難しくはないのですが(既定の設定では曲が切り替わると、その曲が中心に表示されるようになっており、それを応用すれば…)、ただどういう操作でその機能を呼び出せるようにするか、というところが頭のなかでうまくまとまらず、すぐにはやれそうにありません。すいません。
それと、タスクバーのアイコンですが、ダブらないようにOSに登録しているのですが、たしかに環境によってダブって表示されることがあるようです(デスクトップ版とUWP版は、OSからは別のアプリとして認識されます)。
こんにちわ。
1352以降で、リレー音は本当に再生中の曲が次のトラックに移ったときに発生するのでしょうか? 単に曲が切り替わったというだけでなく、サンプルレートや変調方式など、なにかほかの条件も変わったりしていないでしょうか?
またご利用のドライバ(ASIO or WASAPI)も教えてください。
hiroさん、スクリーンショットありがとうございました。
そこに手動クロールのフォルダを指定するダイアログに表示されている文字列は、単に過去入力した文字列の履歴です。そのためドライブの存在有無とは関係はなく、これは正常な動作です。
よろしくお願いします。
nikuyamaさん、了解しました。
nikuyamaさん、お手許にPCがあるうちに、と思い、昼間はすこし慌ただしくさせてしまい申し訳ありませんでした。
TuneBrowserは、ジャケット画像として、楽曲ファイルのフォルダにある画像か、楽曲ファイルに埋め込まれている画像を使用します(ほかに関連画像などもありますが…)。
そのため、デスクトップにある楽曲ファイルの画像には、デスクトップにある画像が使用されるのは、自然な動作であるように理解しましたが、合っていますでしょうか?
楽曲ファイルはデスクトップにあるのですか？
ありがとうございます。
フォルダにないのに、フォルダ画像として表示されているということですね。わかりました。
ありがとうございます。
誤って楽曲のフォルダにキャプチャ画像が入ってしまっていませんか？
ありがとうございます。
イメージの管理はスクロールして下の方が表示されていますが、上の方は見れないでしょうか？ もう手遅れですか？
取り急ぎ
消えて以後は、まだHDをつないで登録処理を実行していません。
なるほど、わかりました。ありがとうございます。
それ以降に書かれている状況はきちんとはわかりませんが、たとえばOSにG:ドライブの情報が残ったままで、アクセスできないだけ、という状況になると、今回のような動作になりますね。
nikuyamaさん、すいません、もう1点教えてください。
G:ドライブの登録が消えた状態でそのまま置いておかれたら(あるいはTuneBrowserを再起動したら)、再度G:ドライブの内容がTuneBrowserに登録されたのですよね?
念のための確認です。よろしくお願いします。
設定はおっしゃる通りですね。
ドライブが存在しているかどうか、という情報は、以前(4.3.0.1354まで)は静的にキャッシュしていたので、タイムラグによってはご指摘のような事象が発生することがあったのですが、現在はフォルダを確認する都度情報を取得しなおしているので、現在のところは思い当たる点がありません…。
もうすこし調べてみます。
こんばんわ。
ご確認いただき、どうもありがとうございました。改善していて、よかったです(^^)。Core i7 4770であれば、負荷的にも問題なかったのではないかと思います。
そのアルバムに対して、右クリックメニューから「イメージの管理」を開くと、その画像はどこかにありますか?
nikuyamaさんは存在しないドライブの情報が削除されて、hiroさんは存在しないドライブの情報が削除されない、というお話ですね。
hiroさんの「手動クロールを開くと」というのは、どういう操作でしょうか? よろしければその画面のスクリーンショットを貼り付けていただけないでしょうか。
nikuyamaさんのほうは、確認してみたのですが、わたしのところでは再現ができませんでした。G:ドライブがマウントされていないときには、かならず発生するのでしょうか? それともそのとき1回だけでしょうか?
エンコーダのパスは、基本設定のエンコードツールのところで指定します。
エンコーダが見つけられないときには、たしかにすべて止めたほうがいいかもしれませんね。検討します。
1アルバム内の複数のアーティストの扱いはいつも悩ましいですね。
わたしはそうしていませんが、よく聞くやり方は、この場合にはアルバム内で共通の「アルバムアーティスト」を設定するという方法があります。
TuneBrowserのCD取り込みのデフォルトの項目にはアルバムアーティストは含まれていませんが、下の「タグの詳細編集」ボタンを押すことで、タグ編集のダイアログボックスが起動して、そこで入力することができます。
またCDの取り込みダイアログボックス右側の「設定」から、”ALBUM ARTIST” タグをアルバム項目としていつも表示させるような設定をすることもできます。
TuneBrowserは “ARTIST” タグと “ALBUM ARTIST” タグの両方が設定されている場合、既定の設定では、アルバムをまとめる際には “ALBUM ARTIST” タグを利用するようになっています。
こんばんわ。
【1点目】
全体ゲインは、「デコーダに設定」の設定でご利用でしょうか? (というか、いまはそれが既定の設定になっていますが…)。
だとすると、たしかにご指摘の通り、デコーダに設定するゲインにはBitPerfectの設定反映が漏れていました。これは、次のリリースで修正したいと思います。
【2点目】
デバイスのビット深度がデコード結果よりも小さい場合は、デバイスバッファに転送する際に、デバイスのビット幅に合わせて下位ビットを切り捨てて引き渡すようにしています。
よろしくお願いします。
ありがとうございます。(^^)
音飛びの原因は、ドライバのバッファ容量や特性、PCの性能などの要因があります。TuneBrowserの機能としてはRAMDecodeの機能が効果があるかもしれません。よろしければお試しください。
ご確認いただき、ありがとうございました。
これからもどうぞよろしくお願いします。
本当ですね。気が付いていませんでした。(__;
すいませんが、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インジケータが点灯する.
で合っていますでしょうか?
先ほど、本件に対応した先行版をアップしました。
ご確認いただければ幸いです。
先ほど、この件を対応した先行版を更新しました。
またお試しいただければ幸いです。