フォーラムへの返信
-
投稿
-
TuneBrowserのライセンスはどちらで取得されたでしょうか。
- PayPal
- ベクター
- マイクロソフトストア
PayPalの場合は購入された方のメールアドレスがわかるのですが、このフォーラムにご登録のメールアドレスから記録を調べても、見当たりませんでした。
ベクターの場合は、ライセンスキー再送付サービスがありますので、ベクターのほうにお問い合わせください。個人情報保護法以降、作者には購入者の情報が開示されないようになり、わたしのほうではどなたが購入されたかがわかりません。
マイクロソフトストアの場合は、ライセンスキーは必要ありません。Windowsが自動で処理しますので、おなじマイクロソフトアカウントをご利用であれば、そのアカウントでWindowsにログオンすることでライセンスが適用されると思います。
よろしくお願いします。
tatuさん、
正常か異常かは何とも言えませんが、1枚目のスクリーンショットと2枚目のスクリーンショットでは、レジストリの見ているところが異なりますので、すくなくともちがっているのは当然です。1枚目はHKEY_LOCAL_MACHINEで、2枚目はHKEY_CURRENT_USERになっています。
isigakiさん、
表示が正常に戻り、よかったです。レジストリを直接触るのでない場合は、表示系の設定をすべてリセットするという方法もあったのですが、それだと意図しないところも初期設定に戻ってしまうので、最終手段的なものでした。
あいにく、リフレッシュレートがちがうモニタは持ち合わせていないので確認ができないのですが、DPIの異なるディスプレイ間のVST3プラグイン画面の行き来は問題なく動作するように結構苦労して調整したので、うまくいかず残念です。
こんばんわ。
発生した現象はともかくとして、元に戻す方法ですが、レジストリを変更する必要があります。
TuneBrowserを終了した状態で、レジストリキーの
HKEY_CURRENT_USER\SOFTWARE\Tiki\TuneBrowser\Workspace\VST3Editor
をノードごと削除してください。次回起動時にもとに戻ると思います。
レジストリを触れない場合は、また改めてご連絡いただけますか。
なお解像度の異なるディスプレイ間のプラグインウィンドウの行き来については、念のためわたしの環境で確認をしてみましたが、再現させることはできませんでした。
BMMNJIMさん、ありがとうございました!
norinoriさん、解決してよかったです。これからもTuneBrowserでお楽しみください。
こんにちわ。
解決とは言えないかもしれませんが、お使いいただけるようになってよかったです。ご報告ありがとうございました。
Thank you for your understanding.
Hello.
Unfortunately, sort order is not included in “View Style”.
ご確認ありがとうございました!
解決してよかったです(^^)。
Hello,
You can fix the view style by following: In preferences dialogbox,
- Tree item: Window/View – View – Album View
- Property: Auto view style – Enable
Set to “No” this, please.
Hillfireさん、ご意見ありがとうございます。
ニーズがあるものですね。参考にさせていただきます。
ご確認ありがとうございました。お手数をおかけしました。
ランサムウェアと疑われていた故でしたか…。通常、そのような機能はアプリケーションのバージョンが変わると、おなじアプリケーションであってもべつのアプリケーションとして取扱うことが多いようです。そのため一から疑われたのかもしれませんね。
今回は思いがけない原因でしたが、romeoさんに調べていただいたおかげで、あらたにこういう事象もあるということを学びました。改めまして御礼申し上げます。
Thank you for your confirmation. It’s nice.
Please post new topic if you have new question.
こんばんわ。
まだやるともやらないとも決めていないのですが、「登録はしているが再生対象にしない曲」というのはたしかにあるなあと思いました。わたしの場合はランダムかどうかは関係ないですが…。あるトラックの別テイクなどがボーナストラックとしてついていたりすると、それ単体では楽しめるものですが、アルバム全体を聴いているときには再生不要、ということはありそうです。
時間がかかるかもしれませんが、ちょっと考えてみます。
こんにちわ。
わたしも、この状況で新しいPCを購入するのは得策ではないように思います。かといって解決の手段があるわけではないですが..。
スクリーンショットを上げていただいた状況になったときに、しばらく(30秒以上)待っていると、TuneBrowserが「予期しない状態を検出」しないでしょうか? もし検出した場合、ダンプファイルを送る指示をしていただくと、なにかわかるかもしれません。
その際には、ダンプファイルは毎日そこそこの数が送られてきますので、ここでひと言「送った」とご連絡いただけると助かります。
Thank you for uploading logs.
TuneBrowser is copying image files to cache folder in C: drive to access quickly for the next time. And in your case, reading cached files were failed. Unfortunately, the reasons of these failure are not recorded in log (I’d like to record them at the next release).
For example, if your C drive is low on free space, this situation may occur… Do you have any idea what’s going on?
To avoid image cache, open the preferences dialogbox, select tree item: “Window/View” – “View” – “Image processing”, set “Cache images to disk” – “Cache images to disk” to “No”.
さっそくありがとうございます。なんと改善しましたか(^^;。ちょっと驚きです。
お手数ですが、もしできれば、どのプロセスが原因だったのか教えていただけると大変助かります。
どうぞよろしくお願いします。
こんばんわ。そのような機能は思いつきませんでした。
ちなみに、ですが、そのスキップする曲は、シャッフル再生でない場合は再生対象になるのでしょうか?
こんばんわ。状況のご説明ありがとうございます。
プラグインの開発元ではTuneBrowserと組み合わせて動作していて、tatuさんところでは動作しないというところがどうも不可解ですが、すいませんがいまなにか思いつくところはありません..。別のPCをお持ちでしたら、そちらではどうか、ということは確認されると良いかと思いますが…。
こんにちわ。
ダンプファイルを受領しました。2本、別々のところから受領しましたので、romeoさんだけでなく、こちらのkyamaさんもお送りいただいたのだと拝察します。
たしかに両方とも速度が低下していることは確認できました。が、予想に反して、これという停滞している処理はありませんでした。全体に漫然と遅くなっている感じです。正直なところ、大変申し訳ないのですが、すぐに原因の思いつくような状況ではありません。
なにかヒントを得たいといろいろ調べていると、マイクロソフトのサポートのこちらのページからリンクされているクリーンブートの案内ページを見つけました。常駐アプリケーションを止めて起動する方法を案内しています。これも正直なところヒットしている確率はそう高くはないとは思うのですが、一度お試しいただけないでしょうか。
よろしくお願いします。
こんにちわ。起動が遅い件については、原因が異なると判明するまでは、先にご発言のあったこちらのトピックでまとめて応対させていただこうと思います。ご了承ください。
Thank you very much for uploading logs.
Unfortunately, your log texts are contents of “Log” tab of Log View. I asked you to upload log text of “Image” tab of Log View.
I’m sorry, but can you please upload log again ?
こんばんわ。
そうでしたか、IKmultimediaさんのところでは問題なくTuneBrowserと組み合わせて動作しているのですね..。残念ながら、前のコメントにも書いたように、その状況では当該のVST3プラグインがハングしている理由はわからないと思います。
一旦はシステム要件OKだったのですが、それが間違いだったのかもしれませんね
これは、どういう意味でしょうか?
こんにちわ。
残念ながら、デスクトップ版のライセンスをストアアプリ用に変更することは、当初のマイクロソフトとの契約によりできません。
試された環境では、登録されている曲数や、VST3プラグインの適用状況などは同一の環境になっているのでしょうか? またこちらで起動時間のご指摘をいただいているのですが、ご覧になっていますでしょうか?
同様に、ダンプファイルの採取方法をメールでご連絡しておきます。よろしければご対応いただけると助かります。
こんばんわ。
最後に示されたスクリーンショットは、VST3プラグインの使い方とは別に、ウィンドウを表示しようとしてなぜかフリーズした状態になっているようです。
IKmultimediaさんのサポートにも連絡してますがなかなか解決しません。
とのことですが、先方はなにか調査あるいは改善しようと動かれているのでしょうか? おそらくTuneBrowser側からはどこでフリーズしているかはわからないのですが、なにか協力できることがあれば言ってください。
こんにちわ。
5.0前後で起動に時間がかかるケースとしては、一部のVST3プラグインのロードに時間がかかっていたケースがありました。VST3プラグインをご利用の場合は、確認をしてみてください。
もしVST3プラグインが原因でない場合にそなえて、ご登録のメールアドレスにダンプファイルの採取方法を書いたメールをお送りしておきます。起動したあと、その手順でダンプファイルを採取・送信していただければ、内容を調べてみることができます。
よろしくお願いします。
Thank you very much for your trying. I’m still wondering.
Would you please save log ? Please enable image log to set “Enable log” to “Yes” in the same prefernce page.
And you can show Log View by selecting top menu “View”- “Docking window” – “Log View”. When you select new tree node, many log text will be shown in the “Image” tab in “Log View”. You can select and copy these log text by right click menu.
Save log text to some text file, and please upload it as Attachments.
Oh…
Then, please set above item “Use embedded image first” to “No”.
Thank you for your confirmation.
Then, please check following setting of preferences dialogbox.
- Tree item: Window/View – View – Image processing
- Property: Jacket image – Read embedded and folder images
If this item is “No”, please set this to “Yes”.
こんにちわ。
通常はそのような動作にはなりません。おそらくご利用のPCでは解像度(DPI)の変更に類した動作をしているのだと思いますが、TuneBrowserのDPI変更に伴う動作は、率直なところこれ以上の改善は難しい状況です。
念のためわたしのPCのディスプレイの電源On/Offをやってみましたが、再現させることはできませんでした。
Problem 2 message means that you are not using network folder as managed folders of the TuneBrowser.
Hello,
TuneBrowser is using following images as a jacket image:
- Image files in same folder of music file.
- Embedded images in the music file.
- Downloaded images according to track tags.
You can check which images are recognized by the TuneBrowser, by “Manage images” in the context menu of selected tracks.
ご報告ありがとうございました。動作してよかったです。
スピーカーについているボリュームが、どこに効いていたのか、というところでBitPerfect設定の動作が変わってくると思います。BitPerfect設定は、あくまでもTuneBrowserから送り出すまでの経路に効くものですので、スピーカーのボリュームがその後に効くものであれば効きますし、TuneBrowserのボリュームを操作するものであれば、効かないということになります。
そうですか。きっとこれだと思ったのですが、外していましたか。ASIOの話は、TuneBrowserとしての機能は動作していて、なにかWASAPI特有の問題かも、ということでしょうか。
残念ながら、いまはこれ以上思いつくところがありません…。
その後改修点を確認していて、以下が該当するような気がしてきました。
設定ダイアログボックスのツリー項目「基本の設定」「操作の設定」、右側の項目「ホットキー」「この時間内に連続したら無視する (ms)」が800になっていると思うのですが、ここをたとえば0などにしてみてください。
連続的な操作を排除するようにしたのですが、ボリューム操作などではそれが裏目に出ている可能性もあるかと思います。
こんばんわ。
ご指摘いただいたあたりの機能を変更した覚えはないのですが、以前よりこちらのようなご指摘をいただく都度、処理を確認し、可能なところは見直しをかけているので、その副作用が出てしまったのかもしれません。
他にも同様の事象が起きている方はおられますか? > ALL
ご理解いただきありがとうございました。
いったん、このトピックとしてはクローズさせていただきますね。
ご確認ありがとうございました。
Playback Queueにある全曲がランダム再生対象になっていると思いますが、なっていませんか?
Album Viewのいま表示しているタブの全曲を再生対象にする (Playback Queueに入れる) 方法は、タブのところで右クリックメニューを表示させて「全体を再生」を選択します (他にも、Tree Viewからの再生操作や設定を変える方法などもあります)。
こんにちわ。
Player Viewの右下に RAND というインジケータがあります。これをクリックすることでランダム再生(シャッフル再生)させることができます。(下図の赤丸がそのインジケータですが, 点灯していないのでわかりにくくてすいません)
さっそくありがとうございました。
内容確認したところ、意図した通りに動作しているようで、安心しました。もうすこし細部を点検して、正式版化しようと思います。
こんにちわ。
先頭トラックがHDCDでなく、後続トラックがHDCDであった場合の救済も含めて検討したのですが、リッピング (変換) の処理は並列処理できるようトラック間の独立性を高めていて、この観点でのみトラック間の相関を管理するようにすると、思わぬ不具合や将来対応の足枷になるような気がしてきました。
そのため、ご期待に沿えず申し訳ないのですが、HDCDに関する対応は、現在リリース済みの機能までということにさせていただこうと思います。将来、また改善に挑む可能性もありますが、現在のところはここまでとさせていただきます。
どうぞご理解いただきたくよろしくお願いします。
こんにちわ。
先ほど、先行版1604を公開しました。更新履歴の説明に書いた通りなのですが、デバイス側がサイドチャンネルを使用していて、音源(FLAC)側がリアチャンネルを使用している場合、このリアチャンネルをサイドチャンネルにアサインして再生するようにしました。
わたしの環境では、リアなし・サイドありのデバイスの設定を行うことができませんでした。そのためお手数ですが、サイド設置に設定した環境で再生ができるかどうか、ご確認いただけると助かります。またその際には、お手数ですがログもアップしていただければと思います。
どうぞよろしくお願いします。
ああ、なるほど。それはたしかにそうかもしれません。
CDトラックのリッピングの場合、複数トラックをリッピングしてから判断というわけにはいかないので、最初のトラックの状態で判断ということになりそうですが…。
わたしはVST3には詳しくはありませんので、どなたかおわかりになる方がおられましたら、よろしくお願いします。
その設定は、CDメディア毎に指定することができませんので、強制デコードの指定は適さないと考えています。
TuneBrowserのDSD-PCM変換は、サンプルレートを指定することができます。再生の詳細設定 – DSDのPCM変換の設定を確認してみてください。
サイド設置の設定になっていたスピーカーがあって、これをリア設置に設定しなおしたら問題なく鳴るようになったということですかね…。
もともとのご指摘は、サイド設置のスピーカー設定になっていたとしても、TuneBrowser以外のソフトではリア音源をそちらに配置して鳴らせるということになろうかと思います。そういうふうに動作するようにいま大きな見直しをかけているところですので、リリースの際にはまたご協力いただけると助かます。
こんにちわ。
TuneBrowserは1種類の構成だけでご提供しています。そのため「最小構成」という別構成はありません。
追加の情報ありがとうございました。
あたらしくつけていただいたログでは、チャンネルマスクは期待通り0x0000003fになっていますね。ちなみに、Intel CPUを載せたPCでは、コントロールパネルのサウンドのところでサラウンドスピーカーがリアではなくサイドになっていないでしょうか?
foobar2000は、フリーソフトではありますが、オープンソースではないので、内部の動作は非公開です。
いまOSから取得できているチャンネルマスクの値をいまの方法で解釈すると、5ch/6chは存在していません。無理に解釈すると、未アサインのチャンネル番号がつづいたあとで10ch/11chが存在していることになります。その状況で存在していない5ch/6chに出力して「機器に委ねる」行為と称するのは、わたしにとっては無理があります。
解釈の方法がまちがっている可能性はありますが、結局、話は4月ごろの疑問点に戻ります。そのときの議論で、チャンネルマスクのビット位置とチャンネルが対応しているとした考え方がおかしいのだろうと思いつつあります。
ありがとうございます。
“「6chのオーディオ機器」側の処理に委ねるべきもの” と言われていたやり方とどう結びつくのかというところが、すいませんがよく掴めませんでした。
②の方法はこれまでTuneBrowserがやっているとご説明している動作と同様に見えます。
「機器側に委ねる」ことができれば、これまでの例で5ch/6chをVoidとして扱うようなケースを回避できるのかとも思いますが、そのようなうまい方法は見つからないです。
いただいたログの内容は、いずれもチャンネルマスクが0x0000060fになっていて、こちらでご報告した状況とまったくおなじでした。
ただその際にはこの数値にはあまり真剣な意味を見いだせていなかったのですが、今回2機種ともおなじ数値ということはなにか意味がありそうですので、これを調べています。
あと、対応の方向を決める際のポイントになると思いますので、昨日お願いした4chのソースを6chで再生する件、もうすこし説明をお願い致します。
すいませんが、なにが起こって、なにが問題か、掴むことができませんでした。
初期化処理は、ウィンドウを表示したり、データベースを読み込んだり、スレッドを起動したり、設定を読み込んだり、再生デバイスと接続したり、と、さまざまなことを行っています。
ログのアップ、ありがとうございました。取り急ぎ、御礼申し上げます。
リセットされたので、もう一度設定したいということでしょうか?
当時のトピックは見つけられていないのですが、それを見ても設定できないでしょうか?
タグの追加は書いていただいた方法で正解です。
残念ながらリッピング時に指定することはできません。
TuneBrowserあるあるです(^^;。
ご確認ありがとうございました。
「ソースのチャネル判定がおかしい」件の続報です。
挙げていただいたログは、以前PlayerLog1oppo.txtとしてアップしていただいたものの一部でしたね。このログの動作については、以前#11387でご報告した通り、デバイスから返されたチャンネルアサイン情報に基いて4chを使用しています。なおこれについては、その際に「マスク値は変動しているよう」とのご指摘をいただいたので、今回のリリースではそれに対応しています。Sonyはそれで救済されたように見えますね。
なお音源にはFLACをご利用と思いますが、FLACは、チャンネル数に応じて以下の固定のチャンネルアサインになっており、ご指摘のようにBack/Sideの情報がないということはありませんでした。失礼しました。
The assignments are as follows:
1 channel: mono
2 channels: left, right
3 channels: left, right, center
4 channels: front left, front right, back left, back right
5 channels: front left, front right, front center, back/surround left, back/surround right
6 channels: front left, front right, front center, LFE, back/surround left, back/surround right
7 channels: front left, front right, front center, LFE, back center, side left, side right
8 channels: front left, front right, front center, LFE, back left, back right, side left, side right処理もこれに則って動作していることを改めて確認しました。
複数の話題が進行しているので、ちょっと混乱しないようにしたいです。
ここでの指摘はそもそも「ソースのチャネル判定がおかしい」ということです。
これについては、昨日の報告にも書いた通り、わたしのほうで確認します。
お伺いしたのは、その前に#11505で、ソースが4chだった場合の動作としてご指摘いただいたほうです。わたしがこのご指摘の意味を理解できていないので、混乱しているのかもしれません。
もしできたら、検証の際に×をつけたケースについて、ログを添付ファイル(Attachments)としてアップしていただけませんか。
パラメータをいくつか変えて試していただいたとのことで、それぞれのログがあると有難いです。まとめてアップするのが大変なようでしたら、採取できた分からだけでも構いません。
ご承知と思いますが、ログはマウスの右クリックですべて選択、コピーなどができます。コピーができると、メモ帳などを使用して貼り付けて、テキストファイルとして保存することができます。複数ファイルの場合、ZIPファイルにまとめていただくと、取扱いが容易になるかもしれません。
お手数をおかけしますが、どうぞよろしくお願いします。
こんばんわ。
デコードのチャンネル判定の処理については、再度確認をしてみます。
それで、
「4chしかない音楽ファイルを、6chのオーディオ機器で再生する」ことに全く問題はありません。
何故なら、それは「6chのオーディオ機器」側の処理に委ねるべきものだからです。すいませんが、この部分について、言われていることがわかりませんでした。この状況で「処理に委ねる」とは、1から数えて5chめ、6chめにどういうデータを流すべきと言われているのでしょうか? 音源ファイルにデータがない場合は、どうしようもないと思うのですが。
ご確認ありがとうございました。
挙げていただいたVoidの表記は、デコーダ側にそのチャンネルの情報がなく、デバイス側にはチャンネルはあっても使用しない、という意味で表示しているものになると思います。4chしかない音楽ファイルを、6chのオーディオ機器で再生しようとしている状況です。この場合、再生するものがないので、Void以外にしようがありません。
今回の対処で、いま考えられる手は打ち尽くしたという状況です。実のところ「TuneBrowserはほぼぜんぶダメ」という表を目にしたときに、心がどこか折れてしまったのだと思います。いろいろと検証していただいて申し訳ないかぎりなのですが、わたしの正直な気持ちとしては、実質的に使い物にならないと言われるような機能を「対応している」と表明するよりは、潔く対応していないとしたほうが、さまざまな意味で (使う側にとっても、作る側にとっても) まだ健全であると考えます。そのため、長いTuneBrowser開発経緯のなかでこのようなことははじめてなのですが、WASAPIのマルチチャンネル対応は取りやめとさせていただこうと考えています。
ご期待に沿えず、大変申し訳なく思います。
ご理解いただきありがとうございます。
また今回はご要望に沿うことはできませんでしたが、またなにかあればご連絡いただければと思います。よろしくお願いします。
こんにちわ。確認ありがとうございます。
あまり良い結果になりませんでしたか..。「Tunebrowser不可の要因は、OSの認識結果を使っていないところかな？と思われます。」とご指摘されていたので、それに沿うようにかなり変えてみたのですが…。
ひとつ設定を変更してお試しいただきたいです。WASPIの設定の「WASAPI固有の設定(2)」に、「再生前にチャンネル数を初期化する」があります。Noになっていると思いますので、Yesに設定して試してみていただければと思います (これをYesにすると、逆にOSの認識結果は使わず、毎回設定に行くようになります)。
なおこの項目は、デバイス固有の設定を有効にしていると、デバイス毎にありますので、ご注意ください。
よろしくお願いします。
お手数をおかけしますが、どうぞよろしくお願いします。
こんにちわ。
先ほど公開した5.1.0.1602で、HTTP経由でアクセスするメタデータの動作を改善しました。よろしければお試しください。
こんにちわ。
今回の現象のご指摘をいただいて、変換の設定の保存に関する動作を再確認したところ、ある条件で保存した条件以外が保存されない事象が発生することがわかりました。最新のリリース(現在は先行版)で対処しています。
ご報告しておきます。
こんにちわ。
先ほど公開した5.1.0.1602で、WASAPIデバイスに対する動作を変更してみました、よろしければお試しください。
こんにちわ。
先ほど公開した5.1.0.1602で、HDCD_MARKタグを導入しました。更新履歴の説明にあるように、1で強制的に適用、0で強制的に非適用、空(値なし)でいままで通りの自動検出です。
期待された対処とは異なると思いますが、よろしければご利用ください。
こんにちわ。
ツリーのノードをダブルクリックした場合の動作はノードの開閉で、Playback Queueに入れるという動作ではないのですが…。
こんにちわ。
タイトルにコロンが含まれた場合の動作については、こちらのトピックを参考にしてみてください。よろしくお願いします。
こんばんわ。
スリープの抑制を有効にしてなおWindowsが時間の経過とともにスリープしてしまうということは、TuneBrowser側からできることはもうなさそうです。これはきっとWindows 11の問題にちがいないと思って調べてみましたが、そういう情報もありませんね。
なおご理解いただいていると思いますが、TuneBrowserが抑止できるのは、時間とともにWindowsがスリープに入る動作であって、ユーザーによって強制的にスリープする操作が行われた場合は、抑止はできません。
スリープに入るまでの時間設定によってはさぞ不便とお察しします。もうすこしなにかできないか調べてみます。
こんばんわ。TuneBrowserのご利用ありがとうございます。
ツリーのノードをダブルクリックして再生というのは、これまでのTuneBrowserの操作感とちょっと合わないような気がします。ツリーノードの深さによっては非常にたくさんの楽曲が再生対象になってしまいますし、わたしが古い人間なのかもしれませんが、ダブルクリックしたときの期待動作としてはノードの開閉のような気がします。設定でその動作を切り替えられるようにせよ、エクスプローラーの操作の感覚で開閉しようとしてダブルクリックして、再生する曲が突然変わってしまうということが起きそうです。ということで、せっかくご要望いただいて恐縮なのですが、これについては現在のところは対応する予定には入らないです。すいません。
ご確認ありがとうございました。
そうですか、ではVersion 5になっておかしくなったというわけではないのですね。
全トラックがHDCDとして変換できたと言われているコープランドのアルバムは、たまたまわたしが確認したアルバムのひとつとおなじで、たしかに全トラック変換ができました。
Version 5でおかしくなったという話ではなさそうですので、差し止めていた次のリリースを行おうかと思います。
TuneBrowserのHDCDデコードはdBpowerampの処理と差があるのかもしれませんが、わたしにはdBpowerampの内部の動作がどうなっているかわからず、いまのところはエラーかどうか、あるいはどちらが正しいとかそうでないと言うことはできません。ただ現実に、ひとつのアルバム内に16ビットと24ビットが混入するのは不便かと思いますので、その対策は考えたいと思います。
ご連絡ありがとうございました。クローズしますね。
お気持ちは有難く頂戴します。でも、考えてみればXLDでリッピングしたデータでも再現できるとのことですので、いざとなればCDそのものではなくそのデータを検証用に送っていただくという手はありますね。
そうしたお手数をおかけする前に、念のため、TuneBrowser 4 (4.18.2) では全トラックHDCDとしてデコードできることを改めてご確認いただきたいのですが、可能でしょうか。
こちらから4.18.2をダウンロードしていただくことができます。基本的に、バージョンダウンはあまりお薦めしていませんし、もし気になるようでしたら、現在ご利用のTuneBrowserとは別のフォルダにインストールしていただくこともできます。その場合は、おそらく4.18.2の起動時に「ほかに新しいTuneBrowserがインスートルされている」と出てくると思いますが、気にせず使用していただければと思います。
よろしくお願いします。
TuneBrowserは、HDCDのデコードにあたってゲインの調整は行っていません。
流通しているメディアによってHDCD適否がまちまちであるという状況で、やはり現在のTuneBrowserのHDCD処理には問題があると言わざるを得ないのでしょうか? 現象が再現できず改善の目途がなく、さらに確たる方法論も持てないという状況だと、HDCD対応は止めたほうがいいのかと思いつつあります。CDの発売に際してリマスターの行われることが一般的になった現在において、HDCD対応は逆に不便や混乱の元になっているように感じています。
その後手がかりを探している経緯で、TBLoverさんのこちらのトピックを発見しました (Googleの検索でヒットしました(^^;)。
このときには、まだVersion 4系をご利用だったと思うのですが、その後こちらの件はどうなりましたでしょうか?
エラーが出ているというか、検知ができていないのですよね。
トラック5については、HDCDパケットは検知できていて、ただその中身が空になっているということで無視しているので、これを救済して24ビットに拡張すればいいのかもしれませんが、そういう話でもないですよね..。
何とかわたしのところでも再現できればいいのですが…困りました。
こんにちわ。
リッピング時の問題ではなくデコードの問題と言われていましたが、アップしていただいたログはリッピング時のものですね。言葉の捉え方の問題かもしれませんが、やはりリッピング時に発生している問題だったと理解しました。ちょっと問題を捉え違えていました。
Version 5になって、Change Logにもあるように、たしかにHDCDの処理を変更しているところがありますが、これは16ビットデータだけを対象としたものです。ですので、CDのリッピング時には影響はなさそうです。念のためわたしの手許のReference RecordingsレーベルのCD (大植英次とミネソタ管のもの3枚) で試してみましたが、全トラックHDCDとして24ビットで記録され、問題はなさそうでした。
なにかTBLoverさんご利用の環境で問題が発生しているとは思うのですが、わたしの環境での検証と処理の確認では問題が見つからず、次の手が見つからない状況です。しばらく次のリリースは控えるようにしますので、なにかほかにお気づき点があれば、また情報いただけると助かります。
あー、すいません。レスピーギのトラック群は1トラック目だけが16ビットになっているということを言われているのですね。読み取れていませんでした。
で、このトラックはReference Recordings社のものなので、HDCDになっているはず、ということを言われていると理解しました。
ただこのトラックの処理状況がどうかというのはわからないのですが、前に書いたように、HDCDデコーダに通した結果、トラック冒頭部にHDCDパケットがない、あるいはあっても内容がNULLだったという判定になっているのだと思います。
ありがとうございます。
トラック毎に処理しているというのは、ご指摘の通りだと思います。ただ結果としてログにある通り、HDCDパケットのある/ない/あってもNULL、という状況が発生して、現在の結果になっているのだと思います。
まだもうひとつ理解が充分ではないのかもしれませんが、
Respighiの方はHDCDを開発したReference Recordings社のものですから、間違いありません。
とのことですが、最初にアップしていただいたスクリーンショットでは、レスピーギのトラックはすべて24ビットになっていて、これでHDCDデコードされたことを示されているのではないのでしょうか? ですので、このレスピーギのアルバムは正しくHDCDとして扱われていると思えるのですが..。わかっていなくてすいません。
リッピング時ではなくデコード時のエラーと言われているのは、何のことなのでしょうか? トラックが16ビットになっていることを言われているのか、24ビットになっていることを言われているのか、あるいはまた別のことなのでしょうか?
呑み込みが悪くて申し訳ありません。
こんばんわ。
これは、CDからのリッピング時にエラーがあったと言われているのでしょうか?
そうだとして、確認なのですが、HDCDであるという確度はとれくらいのものでしょうか? というのは、HDCDであるか否かというのはCDというメディア単位で判定するもので、トラック毎にHDCDである/ないという動作はしていないためです。
トラック毎にビット深度に差が出るとしたら、Pre-Emphasisの指定がある場合です。ただTuneBrowserのPre-Emphasisの動作については、過去このフォーラムで複数の方から幾多の検証をしていただいた後にリリースしていますので、不具合のある可能性はもう相当低いのではないかと思います。そのため可能性としては、ご使用のメディアにその通りにPre-Emphasisのフラグが設定されていたということではないかと思うのですが、いかがでしょうか。
こんばんわ。
他のソフトでも発生するということは、元の音源ファイルに何か問題があるのだろうと思います。通常の再生時、ふつうのソフトはファイルに確認されている順番にデータのかたまりを取り出して音に出します。具体的にはわかりませんが、この順序を乱す要因がファイルのどこかにあるのだろうと想像します。
シークすると再生できたり、そのまま再生できるソフトがあるというのは、この順序について補正がかかるためと思われますが、そのまま再生できるソフトは、通常の再生時でも補正をかけながら再生しているのかもしれません (あまり効率はよくないかも)。
具体的なことが書かれていませんでしたので、こちらもあまり具体的なことは書けませんでしたが、こういうように感じました。
こんばんわ。
ご連絡ありがとうございました。わかりました。今後もTuneBrowserをどうぞよろしくお願いします。
ご連絡ありがとうございます。
ファイルのアップロード方法を示したメールを、ご登録のメールアドレスにお送りしました。お時間のあるときにでもご対応いだたけると助かります。
なおファイルは、トラック毎に分割されている場合、ノイズの発生する前後の2ファイルだけで結構です。アルバム全体は不要ですので、よろしくお願いします。お送りいただいたファイルは、検証目的にのみ使用します。
そうでしたか^_^
解決してよかったです。ご連絡ありがとうございました。
こんばんわ。
TuneBrowserは標準でギャップレス再生に対応しています。そのため、連続しているトラックであればトラック間でノイズが発生することはありません。
そのトラック間は、これまで別のソフトで再生していたときにはノイズは発生していなかったのでしょうか。また特定のトラック間で出るのでしょうか、すべてのトラック間でしょうか、不特定のトラック間でしょうか。
できればノイズ前後の楽曲ファイルを検証用にお送りいただきたいのですが、192kHzとのことで、相当大きなファイルだろうと想像します。まずはなにかもうすこし情報をいただればと思います。
こんばんわ。
TuneBrowserの機能でもとに戻す機能は残念ながらありません。もしnashさんがWindowsのディレクトリとファイルに関する知識をお持ちでしたら、関係する設定ファイルを消すことでもとに戻すことはできます (AppDataのRoaming/Tiki/TuneBrowserの下にあるTBConvert.iniというファイルを削除します)。
それがむずかしいようでしたら、いまはちょっと策を思いつかないのですが、またご連絡いただけますか。
こんにちわ。
その後いろいろ調べていて、TuneBrowserでHTTP経由で楽曲を読み込む際に、2018年のこちらのトピックでの指摘を受けて、楽曲のメタデータではなく、外部から供給されるメタデータを使用するようにしていたことを思い出しました。
そのため、(当該トピックの議論はMP3でしたが) HTTP経由でFLACを読み込んだ際にも、FLACのメタデータ類は正しく読み込まれない結果になると思います。
楽曲のスペックやメタデータをどこから得るのかというのはソフトウェア構造上の大きな前提で、すぐにどうしたら良いという方向性は得られないのですが、取り急ぎ、ご報告しておきます。
お手数をおかけしていたら、すいません。
ご承知と思いますが、もともとTuneBrowserはTIDALには対応していません。というか、そもそも日本ではサービスされていないような気もしますが…。
HTTP経由での再生にはいちおう対応しているので、今回の件は、なにが課題になっているのか、という興味でお尋ねしています。動かないのがふつうという状態ですので、無理にデータを採取いただくには及びません。どうか、ご無理のない範囲でお願いします。
こんばんわ。
もしよろしければ、1024KBに設定したときのログをアップしていただけませんか。どのような動作になったのか、すこし興味があります。
TuneBrowserの更新は、基本的には古いものはアンインストールせず、そのまま上書きできるようにしています。ただバージョンダウンについては、ないことではないのでできるだけ齟齬が発生しないように気をつけてはいますが、ひょっとしたら考慮不足のところがあるかもしれません。
たくさん質問を挙げていただきましたが、すいませんがすべて消化はできませんので、ポイントだけご報告します。
再生中にチャンネル数が動的に変わったという事象は、思いつくかぎりでは、トラックが切り替わり、その前後でチャンネル数が変わった場合に発生します。
ただ現在はここが正しく処理できず、チャンネル数は変動するものの、それまで再生していたトラック分しか有効な再生データを送信しません。次のリリースでは、この部分は改善します。
それと、ASIOは、WASAPIとは異なり、ドライバやOS側でチャンネルアサインを管理しません。そのため、TuneBrowserにも手動でチャンネルアサインを指定する設定を用意しています。
こんばんわ。
つけていただいたログの内容から、ご利用のサーバーが、TuneBrowserからの256KBの送信要求に対して1024KBのデータを返してきており、TuneBrowserはバッファのオーバーフローを防ぐためにそのデータを棄却して、エラーにしているようです。
ちなみに、このログはマウスの右クリックですべて選択、コピーなどができますので、今後もし機会があれば、テキストファイルに落としていただいてAttachments:につけていただけると、解析が楽になりますので、ご配慮いただけると助かります。
256KBの要求に対して1024KB返してくる挙動はまったく理解に苦しむのですが、TuneBrowser側から要求するデータ量を1024KBにしてみましょうか。正直なところ、そうしたとしても次の課題が出てきて依然として再生できない可能性はまあまあ高いのではないかと思いますが…。
設定ダイアログボックスのツリー項目「再生の設定」「デコードの設定」で、右側のいちばん上に「通常の読込み時のキャッシュサイズ(KB)」があり、ここが256になっていると思います。これを1024にしてみてください。
ご報告ありがとうございました。
こんばんわ。ログの採取ありがとうございました。お手数をおかけしました。
結果は、ちょっと意外だったです。いずれも、OSからはチャンネル数としては6chあると返しているのですが、チャンネルマスクがOPPOは 0x0000060f、Sonyは0x00000003になっていました。
このチャンネルマスクは、ishi216さんがこちらのコメントで言われていたもので、結果としてOPPOは末尾0xf=4chだけが使用でき、Sonyは0x3=2chだけが使用できると判断してそのように再生しています。
これは、TuneBrowserとしてはWASAPIの仕様に則って動作しているということになります。チャンネルマスクを無視して6chとして再生するのは、たとえば多chのオーディオインタフェースを使用されている場合などにおいて意図しない動作をする可能性を考慮すると、簡単には踏み切れないものがあります。
現在のところ、このくらいしか言えそうにありません。
ご確認ありがとうございました。
次の手を思いつかない状況になってしました。さらにお手数ですが、再生操作時のログを採取していただけないでしょうか。
TuneBrowser上部のメニューから「表示」「ドッキングウィンドウ」「Log View」と選択すると、TuneBrowserの下部にLog Viewが表示されます。Log Viewの下にはいくつかタブがありますので、「Player」を選択してください。この状態で再生関係の状態が変化するとログが更新されます。この内容はマウスの右クリックメニューからすべて選択、コピーなどができますので、テキストファイルに貼り付けることができます。
そのテキストファイルを、Attachments:から添付ファイルとしてつけていただけると助かります。
よろしくお願いします。