フォーラムへの返信
-
投稿
-
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:から添付ファイルとしてつけていただけると助かります。
よろしくお願いします。
そうでしたか。
残念なながら、他にはボリュームなど当然確認されている事柄くらいしか思いつきません。
こんばんわ。
さっそくのご確認ありがとうございました。ひとつ不具合が減らせて、助かりました。
こんばんわ。
ご確認いただきありがとうございました。つけていただいたスクリーンショットから、ご利用の機器は動的にチャンネルアサインを変更できるような印象を持ちました。それで、チャンネル情報をOSから取得するタイミングを変更してみました。
再度先行版を更新していますので、またお時間のあるときにでもお試しいただけると有難いです。
こんにちわ。ご報告ありがとうございます。
Bluetoothヘッドフォンの操作は、機器によるのですが、たいていはキーボード操作として通知されることが多そうです。そのため、キーボードについている再生キーと同様に複数のアプリに通知されるということになるのかなとも思います。
ありがとうございました。
こんにちわ。
Player Viewの右下に、インジケータの形式で出力デバイス名が表示されている部分があります。ここをクリックすると、出力するデバイスを選択するメニューが表示されますので、それと思われるものに変更してみてください。
具体的にどのデバイス名にすると光ケーブル出力になるのか、というのは、すいませんがわかりません。
こんにちわ。
先ほど、先行版を1596に更新しました。
上に書いたように、ウィンドウがデスクトップから外れた位置になった場合に補正する処理に誤りが見つかり、デスクトップ端部周辺に配置すると位置が勝手にずれるようになっていました。
またお試しいただけると有難いです。よろしくお願いします。
こんにちわ。
先ほど先行版を1596に更新しました。
WASAPIデバイスのチャンネル数をOSから取得する方法はいくつかあるのですが、その方法を変更してみました。これで一度お試しいただけないでしょうか?
よろしくお願いします。
お手数をおかけしました。ありがとうございました。
こんにちわ。ご報告ありがとうございます。
ひとつ確認させていただきたいのですが、
別のツールでできることが、できないというのは
やはり何か問題があるのでわ？と思うのですが今回の問題はイメージの管理の画面が開けないということだったと思いますが、別のツールでTuneBrowserのイメージの管理の画面を開くことはできないのではないかと思います。
イメージの管理の画面が提供している機能は、フォルダにあるイメージファイルと、楽曲ファイルに埋め込まれたイメージを列挙、追加、削除、名前の変更することです。これらの操作については、前者はたとえばWindowsのエクスプローラーで同様のことを行うことができます。後者は (実際に使用して確認したわけではないのですが) Mp3tag など著名なタグ編集ソフトではたいていサポートされている機能ではないかと思います。
今回の問題は、こうしたイメージを管理する機能に問題があるのではなく、そもそもイメージの管理の画面が開かないということで、その事象はわたしや他の方のところでは起きていないようですので、その点ではgonnnosukezaka69さんのご利用の環境と関係した問題はあるのだと思います。いま思いつくのは前回ご案内したディスプレイドライバの問題くらいです。それは問題なしとのことですので、なにか他に問題があるのだと思いますが、残念ながらこれ以上はわたしにはわかりません。決して問題がないと言っているわけではありません。
現在も、毎日TuneBrowserのダンプファイルが送られてきています。TuneBrowserになにか問題がないか確認するために時間を見つけてそれらを解析するわけですが、ディスプレイドライバの問題はかなり多いです。ディスプレイドライバ内で動作を停止すると、たいていはTuneBrowserからはそれ以上の手出しができなくなってしまいます。
こんばんわ。
その後いろいろと試してみて、ウィンドウがデスクトップ端部に配置されていると位置補正がはたらくようになっていて、それが意図しない動作をしている可能性があることがわかりました。これはディスプレイの解像度が変わったときの動作を想定して入れたものですが、ちょっとどうするか考えます。
こんばんわ。
まったく意識をしていなかったのですが、たしかにいつのまにかポップアップする位置がデスクトップ左上になっているようです。
それはそれで問題なのですが、その後ウィンドウ位置を修正すると、その後は修正したところに表示されていないでしょうか? また左上に戻ってしまったりしていますか?
こんばんわ。
再生機器の維持は、地味ながら気持ち的には結構大きな変更でしたので、お役に立ててよかったです。(^^)
再生停止操作は、わたしのところでは再現せず、詳しいお話しを伺おうと思っていたところでした。いったん、置いておくことにしますね。
こんばんわ。
すいません、まずトラック順の件をクリアにしませんか。ご提示した方法は試していただいたでしょうか。
「フォルダ内にCUEファイルやM4Aファイルがないとトラックの順番がおかしくなる」ということはないと思いますので、ご確認いただきたいです。
よろしくお願いします。
こんばんわ。
できれば別の話題は別のトピックを立てていただくようお願いします。
以前からTuneBrowserをご利用の場合、Tree Viewのフォルダーツリーを選択した場合のトラックの並び順はファイル名順です。これを通常のディスク番号・トラック番号に基いた順番にしていただくには、
フォルダーツリーを選択した状態で、Tree View右上の歯車ボタンをクリックして、ツリークエリの設定ダイアログボックスを開いてください。
下のほうに「トラックソートクエリ」があり、なにか文字列が設定されていると思います。ここをすべて削除して空欄にしてください。通常のディスク番号・トラック番号に基いた順番で表示されるようになると思います。
よろしくお願いします。
こんばんわ。さっそくのご確認ありがとうございました。
アンプ側をステレオ再生に設定しているにもかかわらず、マルチチャンネル音源を再生しようとするとアンプをマルチチャンネルに切り替えてしまうというのは、良い動作なのでしょうか? アンプ側をステレオ再生に設定した経緯やそのときのユーザーの気持ちにもよるとは思うのですが、オーディオ機器であるアンプの設定を尊重すべきのような気もしました。
それと、Intel CPUとAMD CPUで差が出るのは、CPUの差というよりは、CPUと紐づいたチップセットによるHDMI出力しているドライバの差と理解しました。アンプ2台接続という環境はこちらでは用意できないので再現させることはできませんが、なにかヒントになれば幸いです。
マルチチャンネルの動作については、わたし自身にはほとんど知見がありませんので、もうすこしご意見をうかがって、本機能をどのようにするか考えていきたいと思います。
こんばんわ。
結果としてご期待に応えられずすこし残念です。その後もなぜこのような結果になったのだろうと考えているのですが、たしかにTuneBrowserはざっくり言うと「アーティスト – アルバム名 – エディション – ファイル形式」のような形でアルバムを分類しており、既定の設定ではその順で表示しますので、まずはアーティストの順で並びます。
アーティストとして作曲家を指定している場合は作曲家順、演奏家を指定している場合は演奏家順です。
今回のケースではすでに作曲家を特定したあとの表示を言われているのと、おそらくアーティストに演奏家を指定されているので、なにか違和感のあるような表示になったのかもしれませんが、全アルバムなど複数の作曲家が混在した状況だと、それなりに意味が出てくるのではないかと思います。
だからどうするという話はないのですが、そのようなことを考えました。
こんばんわ。
先ほど5.1.0の先行版を公開しました。そこでWASAPIのマルチチャンネル再生に対応しています。よろしくお願いします。
こんばんわ。
先ほど5.1.0の先行版を公開しました。そこで、再生中の再生操作の対応を行っています。前のコメントに書いたように少々迷ったのですが、実装してみるとそう違和感もなかったので、再生中の再生操作はとのトラックの先頭から再生になるようにしています。
状態によりいろいろなケースが考えられるので、もしならなかったらご連絡ください。
こんばんわ。
5.1で$AND()/$OR()をサポートしてみました。詳しくはこちらのトピックを参照してみてください。よろしくお願いします。
こんばんわ。
5.1で$AND()/$OR()をサポートしてみました。詳しくはこちらのトピックを参照してみてください。よろしくお願いします。
こんばんわ。
アルバム名を “%ALBUM%” だけで表現して、ソート順にもそれが反映されるようにしたいと言われていたと思いますので、その方法をご案内しました。
shaoxing9さんのご利用環境においてアルバム名を “%ALBUM%” だけで表現することが適切かどうかは、どのようにタグ値を設定してご利用になっているか次第ですので、すいませんがわたしにはわかりません。アップしていただいた例から類推すると、たとえばアルバム名に曲名だけを指定されている場合は、作曲者や演奏者が異なってもすべておなじアルバムになってしまうので (セルやクレンペラーなど複数の指揮者の演奏が混ざっているように見えます)、アルバム名を “%ALBUM%” だけで表現することは適切ではないのではないでしょうか。
MinimServerというソフトがどのような分類をしているかわたしにはわからないのですが、それがわかれば、おなじ指定をしてやればおなじ、または近い表示ができるのではないかと思います。
こんばんわ。
試されている内容を反映するには、アップしていただいた設定のスクリーンショットの「グループクエリ」のところに “%ALBUM%” などと指定してみてください。
こんばんわ。
ご指摘をいただいて、動作を確認してみました。まずたしかに、ご指摘のように「UPnP(OpenHome)用のアルバムタイトル」を変更しても、アルバムのソート順は変わりません。
そこで「UPnP(OpenHome)用のアルバムタイトル」が指定されている場合は、このクエリによるソート順になるようにしようかとも思ったのですが、改めて確認してみると、そもそもアルバム (グループ) を生成する情報としてこの「UPnP(OpenHome)用のアルバムタイトル」が使用されているわけではありませんでした。
アルバムの生成やソートは、選択されているツリークエリに対応するグループクエリで行われており、「
UPnP(OpenHome)用のアルバムタイトル」は、あくまでも表示用のデータをレンダリングする際に使用する表記方法の指定ということになります。いろいろ書きましたが、筋としてはツリークエリに対応するグループクエリ、あるいはグループソートクエリを指定していただくのが良いのですが、いかがでしょうか。
もしわからないことがあれば、またご質問いただけますか。よろしくお願いします。
こんばんわ。
コメント下さり、ありがとうございました。お役に立てたとしたら光栄に思います。ちなみに、TuneBrowserの名称は、TuneとBrowserの間にスペースは入れません。ご配慮いただけると有難いです。
ご質問の件については、もし議論がつづくようでしたら、それぞれトピックを立てていただければと思います。簡単にコメントさせていただきます。
①現在のTuneBrowserはOpenHome PlayerとUPnP Media Serverの機能を持っています。以前よりこのようなご要望をいただいており、これが実現すると、コントローラーの機能の一部を担うことになると思います。
②TuneBrowserは他のソフトウェアに対して何ら要求はしていません。ただPC全体として見たときに、最終的な出音に影響する可能性はあるのかもしれません。「影響する」というのは、どうなったら良いのか、あるいは悪いのかは微妙ですが…。
こんばんわ。
ご要望ありがとうございます。右クリックにするかどうかはわかりませんが、操作方法は検討したいと思います (おそらくCtrl+クリックの動作を変えることになるのではないかという気がします…)。
こんばんわ。
Bluetoothイヤホンを用意して、操作を試してみました。やはりTuneBrowserで問題なく動作しているようです。
ということは、お書きになられているように、TuneBrowserの設定を変えられた可能性もあるとは思うのですが、上のコメントにも書いたように、イヤホンの操作はキー操作相当に変換されて処理しますので、関係するとすればTuneBrowser内のキーボードの設定です。この設定は少々難しいので、あまり慣れない方は触らないのではないかとも思うのですが、変更された覚えはありますか?
こんばんわ。
TuneBrowserの問題ではないとのことで、(お困りのところ恐縮ですが) その点についてはちょっとホッとしました。
状況のご報告、ありがとうございました。
こんにちわ。
数日前というと、とくにTuneBrowserのアップデートなどかあったわけでもありませんし、最近の更新で関連するような機能の変更も行っていません。そのためTuneBrowserの設定変更というよりは、機器やOS側の変更があったということはないでしょうか。
おそらく、イヤホンでの操作は、マルチメディアキー相当に変換されて処理されていると思います。こうした点はヒントにならないでしょうか。
また、ほかに同様の症状が出ている方はおられないでしょうか? > ALL
P.S. 再投稿ありがとうございました。元の投稿のほうは削除しておきました。
こんばんわ。
そうなのですね。念のため、複数のPCで試してみましたが、やはりイメージの管理は正常に動作しています。ご利用のディスプレイドライバを最新にしてみるとか、そういった対処で改善する可能性はないでしょうか。
イメージの管理の機能を使わずに、ということですが、特別なことをやっているわけではないので、ほかの一般的なツールなどでも同様のことはできると思います。