フォーラムへの返信
-
投稿
-
先ほど、高速化した先行版をアップしました。
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に設定して様子を見てみてください。
どうぞよろしくお願いします。
おかしいですね。わたしのところでは表示されています。
以前からずっと表示されていない状態でしょうか?
また同様の状況の方はおられますか? > ALL
こんばんわ。
TuneBrowserのライセンスは、TuneBrowserというソフトに対して発行しているという考え方ですので、当該文の前段にある前提(*)の範疇であれば、各版(32bit版・64bit版・64bit AVX2版・UWP版)共通でご利用いただいて構いません。
*:個人のご本人または同居のご家族がひとつの住居内でご利用いただく場合には、 共有して使うという考え方が一般的だと思いますので、 1つのライセンスで4台までを目安に同時利用いただいてかまいません。
どうぞよろしくお願いします。
あー、なるほど。たしかに。
当該の設定は、それまでキャッシュの画像がヒットした場合は、それ以上(フォルダイメージ、埋込みイメージ、関連イメージなど)を検索しないという効率優先のための設定でした。これだとスライドショーが楽しめないというご指摘があったので、オフにしています。
イメージ関係の設定は、どこか一箇所にまとめたほうがよさそうですね…。
こんぱんわ。
DRINKING BIRDさん、フォローありがとうございました。m(__)m
なぜ、4.2.4から追加の画像を読み込まない設定の既定値をオフにしたのか、差し支えなければ教えていただきたいです。
ここは、動作を変えたつもりはないのですが(いちおうソースコードの履歴も確認してみました)、変わっていますでしょうか?
設定項目の場所の適切さは適宜見直していきたいと思います。
こんにちわ。
ログを拝見すると、ご利用の楽曲には “45b1d925-1448-5784-b4da-b89901050a13″ のようなGUID形式のタグが含まれていて、それをInvalid tagと言っています。
GUID形式のタグは、それを埋め込んだソフト以外には解釈できないものであること、仕様上無限の表記があり得て不必要にデータベースを肥大化させてしまうことから、無視するのはそれはそれで正しいとは思うのですが、”Error: Invalid tag found” というのは、すこし表現がきつすぎたかもしれませんね。
なお、TuneBrowserはこうした解釈できないタグが含まれたファイルに対してタグ編集を行った場合、もともとあったタグは置いておくようにしていますので、TuneBrowserが無視したからといってなくなってしまうことはありません。
こんにちわ。
万一、何らかの理由で不整合が発生したときにユーザが手動で更新できるように、という目的でつけています。
こんにちわ。
4.3.0で、定期クロール、イベントクロールは手動クロールとほぼおなじ動作になっています (ログの出力先などは異なりますが)。手動クロールの動作速度はあまり変わっていません。ちまちま改善はしているので、100msの処理が99msになった、というような部位はあるかもしれません(^^;。
手動クロールのほうが、ユーザの意思で対象フォルダを指定できますので、その意味では絶対に効率は良いです。
手動クロールの非同期で実行するのは、原理的には可能なのですが、競合の設計をやり直さないといけないので、道は険しいです。
よろしくお願いします。
こんばんわ。
これは、TuneBrowserの内部の処理がパス名をクエリと取り違えていますね。(^o^; すいません。
改善を検討します。ご連絡ありがとうございました。
ありがとうこざいました。無念です。(^^;
また検討してみます。
こんにちわ。
不勉強で申し訳ありませんが、iTunesのプレイリストはどのような形態で保存されているかご存知でしょうか?
あー、無限大ですか。なるほど。(^o^;
考えたことがありませんでした。ちょっと検討してみます。
nikuyamaさん、こんにちわ。
別のトピックの内容から、4.3.0の先行版をご利用いただいていると拝察します。4.3.0はクローラが並列動作するようになっていますが、本件の状況はいかがでしょうか? 後学のためにも、改善があったかどうか、教えていただけると有り難いです。
よろしくお願いします。
うまくいったようで、よかったです。
テレビとHDMI接続した場合ですが、きちんとは理解していないのですが、伝送経路HDMIはデジタルだと思いますので、アナログに変えているのはテレビではないでしょうか。
こんばんわ。
デバイス(DAC)によっては、再生開始時にデバイス側でフェード操作を行うものがあります。わたしの知っているなかでは、ChordのDACがそうした動作をするようです。
もしその場合、再生開始時にTuneBrowserから無音信号を送出できます。設定画面の
- 左側のツリー:「再生の設定」-「再生の詳細設定」
- 右側の項目 :「自動無音再生」-「方式の切替り時」
この下に、時間の指定と、「再生開始時にはいつも実施」の項目がありますので、それぞれ時間と”Yes”を設定してください。
また、これとは別に、このフォーラムでもSCHさんが同様の現象をご報告されています。こちらです。ただし、このときにはWASAPIでは正常に動作していました。このときの改善方法は、このトピックの議論を参照してください。
最後に、TuneBrowserには「曲の途中」からの再生時にフェード操作を行って再生する機能があります。ここで、曲の途中というのは、(ア)曲の冒頭(00:00)以外からの再生、(イ)2トラック目以降からの再生、です。
この動作を無効にするには、設定画面の
- 左側のツリー:「再生の設定」-「再生の詳細設定」
- 右側の項目 :「詳細の設定」-「途中からの再生開始時にフェード処理する」
ここNoにしてください。
いくつか原因が考えられますので、すこしややこしいですが、お試しいただければと思います。
こんばんわ。
OpenHomeは、Player側にプレイリストを持つという点でDLNAとは大きく異なっていて、TuneBrowserをOpenHomeに対応させようという気になったのも、この点がポイントになっています。
間に立つControllerがPlayerにプレイリストを送るときに異常を来すというのは盲点でしたが、ご提案いただいたような、Playerの再生状況を見て都度Playerのプレイリストを更新する、というのは、OpenHomeの基本的な考え方(=TuneBrowserのOpenHome対応のアーキテクチャ)から、ちょっと対応が難しいです。そもそもそうした動作はControllerの役割になりますので…。
ところで、ちょっと今回の問題の現象が整理できていないので、もうすこし教えてください。
Controllerから見てTuneBrowserは、MediaServerとPlayerのふたつの役割を提供しています。
Controllerでアルバムや楽曲をブラウズする操作をしたときにはMediaServerとして、選択したアルバムや楽曲群をプレイリストとして再生操作を行ったときにはPlayerとして、それぞれTuneBrowserは動作しています。プレイリストという概念は、Playerとして動作するときに現れます。
今回問題が起きているのは、MediaServer側を操作しているときか、Player側を操作しているときか、どちらであるか、おわかりになるでしょうか?
もしわかりにくいようでしたら、その旨ご連絡ください。
またご利用のKazooのプラットフォーム(OS)も教えてください。
よろしくお願いします。
こんにちわ、
先ほど, 4.3.0.1349を公開しました。
ContentGroupの区切りとContentIndexの区切りを同等に扱うことは難しくなかったので、そのように対応してみました。これまでと動作が変わることになりますが、設定で切り替えるようにするのは性能面で難しく、またContentIndexを活用されている方はそう多くないだろうと(^^;思い、そのようにしました。
お時間のあるときにでもお試しください。
よろしくお願いします。
こんにちわ、
先ほど, 4.3.0.1349を公開しました. 4.2.4からのWASAPI関係の処理の変更点を洗い出して、これだというのは見つけられず、関係なさそうだけど動作に影響するとしたらこれか? という点を4.2.4と同等になるように戻してみました。
ヒットしている確率は率直なところそう高くなさそうなので恐縮ですが、お時間のあるときにご確認いただけると有難いです。
どうぞよろしくお願いします。
わかりにくいかしれませんが、エラーチェックは 一覧で選択されているファイルを対象としています。複数のファイルを対象にする場合は ファイル一覧を(マウスドラッグで)選択して、やってみてください。
おはようございます。
エラーの出ているファイルは、ここで書いた要領でご確認いただくことができます。
さらに、TuneBrowserが検出したエラーのファイルは、以下の操作で確認することができます。
TuneBrowser上部のメニューの「ヘルプ」-「エラーファイル」-「エラーファイルの一覧」を選択することで、エラーファイルの一覧が表示されます。ここから、エクスプローラを呼び出したり、個別にTuneBrowserに改めてエラーチェックをさせることができます。よろしくお願いします。
kazuさん、こんばんわ。
やはり4.2.3では正常動作しているのですね。
ご連絡ありがとうございました。
こんばんわ。
エラーコードと言われているのは、
UL00458: 2018-02-02 22:25:52,754: 7ea0: TL05: UL00460: 2018-02-02 22:25:52,765: 48f8: TL04: UL00461: 2018-02-02 22:25:52,783: 30f8: TL04: UL00462: 2018-02-02 22:25:53,321: 48f8: TL05:この例でいうところの 7ea0, 48f8, 30f8 のことでしょうか?
これはエラーコードではなくスレッドのIDです。並列度を高めたので、検証用にスレッドIDを表示するようにしています。
よろしくお願いします。
Chartreuxさん、ありがとうございます。お手数をおかけしました。m(__)m
やはりTuneBrowserのバージョンの問題で確定ですね。迷いがなくなりました(^^;。
たしかに、4.2.4ではかなり触っているのですが、気持ちを改めて調べてみます。
ありがとうございました。
Chartreuxさん、こんばんわ、
仔細の情報、ありがとうございます。大変助かりました。m(__)m
PC固有の状況ということではないことがわかりました。Chartreuxさんが整理された通りだと思いますが、そうすると、TuneBrowser の4.2.3では再生できていたというところが、わたし的にはやはり気になります…。(^^;
kazuさん、
お手数をおかけするのですが、もし可能であれば、現在も4.2.3では正常に動作することをご確認いただくことは可能でしょうか? 4.2.3はこちらからダウンロードすることができます。
はい、特にOpenHome関係は長くなりそうなので、別トピックでお願いします。
ありがとうございます。お手数をおかけしました。
そうすると、TuneBrowserとFostexの機器間の固有の問題ということなのでしょうか…。
今日も、4.2.3から4.2.4の間でのWASAP関連の変更内容を調べていたのですが、これという点は見つかっていません。また私のTEACの機器などでも試してみたのですが、やはり正常に再生されます。
残念ながら、現在のところはこれ以上思いあたる点がありません。
もしほかになにか、お気づきのことがありましたら、教えていただけますでしょうか。
また、引き続きFostexの機器をご利用の方で、同様の現象が出ている、あるいは正常に動作しているなど、どちらの場合でも結構ですので、情報をいただけると助かります。 > ALL m(__)m
こんにちわ。
お手数をおかけしています。現在のところ、手立てが見つからない状態です。
上のコメントでもご紹介しましたが、PayPalまたはベクターでのライセンスキー取得でもご利用いただけます。問題の解決とはすこし違いますが、よろしければご検討ください。
よろしくお願いします。
ありがとうございます。
すいません、もう1点、
PC起動中にUSBケーブルを抜き差ししてみてもらえないでしょうか？
こんにちわ。
あー、まさかContentIndexまで積極的にご利用の上で、さらにそれでシャッフル再生をされる方がおられるとは思っていませんでした。(^^;
すいませんが、処理をおさらいする必要がありますので、すこしお時間をいただいて、またここでご連絡したいと思います。
よろしくお願いします。
こんばんわ。
もうすこし教えていただけますか。
1. FOSTEX HP-A4 再生時は、いつもそうなりますか、それともときどきですか?
2. 他のWASAPIデバイスでの再生はどうですか?
3. PCの再起動をしてみても、現象は継続しますか?
わたしのところでは、特段WASAPIの再生には問題は出ていません。ほかに、同様にWASAPIの再生で問題が出ている方(あるいは問題なく再生できている方)はおられますか? > ALL
こんばんわ。
了解しました。
ご確認いたただき、ありがとうございました。
よかったです。(^^)
こんばんわ。ご確認いただき、ありがとうございました。
今回の検証で気がついたのですが、foobar2000の埋込みCUEHSEETエディタは、どうも必ずしも埋め込まれているCUESHEETをそのまま表示しているのではなく、自分が解釈できたCUESHEETに変換しているようです。だからどうだという話はないのですが、ご報告しておきます。
各トラックの「PERFORMER “YUI”」がなくなっていました。
これは、おっしゃる通りです。全トラック共通の値ですので、トラックより上のアルバム情報のコーナーに集約しています。
こんばんわ。
ご確認いただき、ありがとうございました。同じ原因で、よかったです。(^_^)
先行版として公開中の4.3.0では、この問題を改善しています。これで期待通り変換ができると思いますので、お時間のあるときにでもお試しいただければと思います。
よろしくお願いします。
akiさん、おはようございます。
情報ありがとうございます。m(__)m
ここでご報告いただいた方々は、それぞれライセンスを取得されたとのご連絡をいただきましたので、残念ながら試していただくことができません。
他に同様の状況でお悩みの方がおられれば、ぜひ試していただいて、ここでご報告いただけると有り難いです > ALL。m(__)m
こんばんわ。
タグ名(ALBUM ARTIST)のなかに半角スペースがあると、ご指摘のようにおかしくなることがわかりました。
内部CUESHEETとfoobar2000に関する一連の事象がこれですべて解決するわけではないとは思いますが、この点は次のリリースまでに修正しようと思います。(半角スペースを除去した名前をタグ名にします)
ありがとうございました。
こんにちわ。
“Wafeform seekbar”, 時々は考えています(^^;。ただ、そこに表示すべき波形の情報をどのように短時間に解析して、どこに保持しておくか、というところで良いアイデアが出ないでいます。
hrk55さん、こんにちわ。
ご協力いただき、どうもありがとうございました。
その後お送りいただいたログを解析したのですが、残念ながらエラーに類するような事象は発生しておらず、TuneBrowserから見れば、ただ購入画面を表示して、即ユーザがキャンセルした、というようにしか捉えられませんでした(これは正常な操作と見なすしかありません)。
なにかTuneBrowser側で対処できればと思ったのですが、やはりWindows10の環境依存の可能性が濃厚です。
以上、状況のご報告でした。ありがとうございました。m(__)m
こんにちわ。
アルバム分類の条件からエンコード形式を除きたい場合は、以下の設定を変更してください。
- 左側のツリー:「表示の設定」-「クエリの設定」
- 右側の項目 :「標準のクエリの設定」-「標準のグループクエリ」
ここが既定の設定では以下のようになっています。
%@_GRPARTIST% - %ALBUM% - %ALBUM EDITION% - %X_ENCODER_TYPE%これを以下のようにしてください(“%X_ENCODER_TYPE%”を取り除きます)。
%@_GRPARTIST% - %ALBUM% - %ALBUM EDITION%こんばんわ。
その後 現象を確認していて、ひとつTuneBrowserの問題を発見しました。ConverterでDSDをPCMに変換する際に使用される設定は、Converterの設定ではなく、再生用の設定が適用されていました。
再生用の設定は、設定画面で行うほうのものです。
再現試験を行うときに、再生用の設定と(結果として, たまたま)同じ設定で行ったために、気づけませんでした。m(__;m
おかげさまでひとつ不具合を見つけることができました。ありがとうございます。次のリリースで修正します。momoさんのところの現象も、これと同じ原因であれば良いのですが…。お時間のあるときにでも、ご確認いただけると有難いです。
どうぞよろしくお願いします。
hrk55さん、こんばんわ。
もしまだお手許のUWP版が未購入の状態であるようでしたら、よろしければご協力いただきたいことがあります。
別途ご登録のメールアドレスに要領をお送りしますので(もうお送りしたのですが(^^;)、お時間のあるときにでもご検討いただければ有り難いです。
どうぞよろしくお願いします。
略号を使用しているのでわかりにくいのですが、DSDファイル形式にはDSDIFF (Philips)とDSF (Sony)の2種類があり、さらにその内部のデータ形式としてDSDそのままの場合とDST圧縮されている場合とがあります(DSFには仕様上DST圧縮はありませんが)。
それを “ファイル形式/データ形式” の形で表示しており、DSDIFFは長いので、ファイルの拡張子に準じて”DFF”と略記しています。
ですので、ご質問の答としては、DFFとDSFはちがうファイル形式ということになります。
こんばんわ。
プレイリストに連番（15曲あったら01～15までとか）振りたいんですが可能でしょうか？
すべての曲を選択して、右クリックメニューから「プロパティ」を選択いただき、タグ編集のダイアログボックスが開いた状態で、さらに右クリックメニューで「先頭から連番」を選択いただくと、トラック番号を連番にすることができます。
文字通り「先頭から連番」ですので、ある値から番号を開始したい場合は、先頭のトラックに手動でトラック番号を指定しておいてください。
またこれは楽曲のトラック番号を直接書き換えますので、そのプレイリスト専用の番号ということではありません。ご留意ください。
よろしくお願いします。
こんばんわ。画像の添付ありがとうございます。
これを見て気がついたのですが、わたしは状況を誤解していたかもしれません。
赤枠で囲んだ部分に、”DSF/DSD” がふたつ出てくると理解したのですが、ここでは “DFF/DSD” と “DSF/DSD” がひとつずつ、ですよね。
この部分の話ではないのでしょうか?
呑み込みが悪く恐縮ですが、ご確認いただければ幸いです。
こんばんわ、はじめまして。
追加の情報、どうもありがとうございます。m(__)m
参考にさせていただきます。
続報どうもありがとうございます。m(__)m
PCが変わっても固定サンプルレートの状況はかわらず、しかもそのサンプルレートはPCによって異なる、ということですね。
引き続き考えてみます。。
ありがとうござました。
了解しました。ご確認ありがとうございました。(^^)
こんばんわ。
TuneBrowserのスペクトル表示には、いちおうピークホールド(ピークライン)の表示機能がついているのですが、表示されていませんか?
Player View右上のツールバーのスペクトル表示を切り替えるボタンをクリックしていただくと、メニューが表示されます。そのいちばん下に「ピークライン」の項目があって、そこにチェックがついていると表示されます。
また、ピークラインの滞在時間は設定画面の「スペクトル表示」のところで設定することができます。
- 左側のツリー:「表示の設定」-「ビューの設定」-「プレイヤービューの設定」-「スペクトル表示の設定」
- 右側の項目 :「ピークラインの描画」-「ピークラインの滞在時間」
いちどご確認いただければと思います。
こんばんわ。
残念ながら貼り付けていただいた画像がうまく表示されていないようです。。
Tree Viewのノードに “DSF/DSD” がふたつ現れている、ということですよね。原因を考えてみたのですが、この識別子はTuneBrowser内部で生成していて、表記の揺れが起きそうな部分は見つけられませんでした。
うーん、謎です…。
ちなみに、それぞれのノードの下に同じファイル群がぶら下がっているのでしょうか?
ご確認いただき、ありがとうございました。
もともとBrooklyn DAC+は、DSD256のDoPには対応していなかったということですね。