フォーラムへの返信
-
投稿
-
Hello.
Random playback affects to the tracks in the Playback Queue. “One more thing” seems that it is working normally for internal CUESHEET. Processing internal CUESHEET is improved at 4.18.0. Please see this topic.
こんばんわ。
さっそくTEACから返信をいただきました。TuneBrowserというソフトの開発者であることを伝えて、ドライバ側からの情報が得られないかとお願いしましたが、残念ながら、同社のサポート部門や開発部門には今回のような事象は報告されておらず、なにもわからないそうです。
また貸出機の申し出もいただきましたが、わたしが再現させることができたとしても、このフォーラムでご報告いただいている以上の情報は得られそうにないので、あまり意味はなさそうです。
残念ですが、これ以上は進めそうにありません。どうか、ご了承ください。
Hello.
Please click RAND indicator in the Player View.
こんばんわ。
今回は2例目ということで、わたしのほうからTEACに問い合わせを行ってみました。返信を待ってみましょう。
TEAC UD-301のASIOエラーのご報告はこれで2回目です。以前はこちらのトピックでしたが、残念ながら結局解決していませんね。
TuneBrowser以外のアプリケーションは問題がないとのことから64bit版ドライバの問題か、という雰囲気でしたが、特定はできていません。他にも、AVX2をサポートしたCPUであれば (TuneBrowserでも) 問題なく、またわたしが保有しているUD-501でも問題なく、どうも要領を得ないままクローズとなってしまいました。
今回つけていただいたログにも、(発生する経緯は異なりますが) おなじエラーが記録されています。
WASAPIとASIOの音質の差ですが、WASAPIの排他モードであれば、ふつうは聴き分けるのは困難だと思います。
ご確認ありがとうございました。
さっそくのご確認、ありがとうございました。
ご確認ありがとうございました。まずは解決してよかったです。
またこの後の状況などお知らせいただけると助かります。よろしくお願いします。
ご確認ありがとうございます。うまく動作したようでよかったです(^^)。
Keyword Viewも動いているようでよかったです。
こんばんわ。先ほど先行版の1568を公開しました。ご指摘いただいた問題は改善していると思います。よろしければお試しください。
こんばんわ。
確認をしてみたのですが、動作しない条件を見つけることができませんでした。
それで、改めて書いていただいたやり方を読み返してみたのですが、
ご提供頂いたTB.tbdidlをcopyしdisktopにpasteし、TuneBrowser画面内へドラッグ&ペーストとしましたが
の部分について、ひょっとしたらデスクトップ上にインターネットショートカットが作成されている状態かもしれません。インターネットショートカットは実際には拡張子がURLのファイルで、内部には文字通りURLが書かれています。
ご利用のブラウザにもよりますが、TB.tbdidlへのリンクをクリックするか、右クリックするなどしてこのファイルを「ダウンロード」してから使ってみていただけないでしょうか。
よろしくお願いします。
お手数をおかけします。再起動を促すメッセージが表示されないのは、何らかの異常です。明日以降になるのですが、改めて動作を確認をしてみます。
ご確認ありがとうございました。うまく動作しているようでよかったです。
上にも書きましたが、きっかけをいただいたおかげで、根深い問題をひとつ改善することができました。
あれ? (^^; と思って、改めて確認をしてみたのですが、わたしのところでは意図通り動いていました。
念のため、ですが、以下の2点を確認お願いできますか。
- 対応しているのは4.18.0の先行版です。先行版はこちらからダウンロードできます。
- (Ignore…と出ているのでちがうとは思いますが) ドロップする前に何らかの理由でエラーなどを示す上部のキャプションバーが表示されていると、それが優先されて、新しいキャプションバーは表示されません。キャプションバーがすでに表示されていたりしないでしょうか。
よろしくお願いします。
こんばんわ。
ご連絡が遅れましたが、4.18.0の先行版で、ご指摘の動作を改善しています。別のトピックでお忙しい状況と伺っていますので確認いただくには及びませんが、一応ご報告しておきます。
こんばんわ。
ご連絡が遅れましたが、4.18.0の先行版で、タブの動作を改善しています。問題に対処した、と言い切れないところもあるのですが、またようすを見ていただけると助かります。
どうぞよろしくお願いします。
こんばんわ。
現在公開している4.18.0の先行版で、この問題に対応しています。お時間のあるときにでもご確認いただけると助かります。
よろしくお願いします。
すいません、肝心なことを書いていませんでした。
このテキストファイルを編集したら、TuneBrowserにドロップしてください。TuneBrowserの再起動を促すメッセージが表示されると思います。次回の起動時から適用になります。
ファイル名は、拡張子で種類を判別しますので、拡張子以外は自由に変更していただいて構いません。
こんばんわ。
更新履歴には書いていないのですが、現在公開している4.18.0の先行版で、外部ファイルでの定義に対応してみました。しばらくは試験的な機能ということでご理解をお願いします。
このコメントにつけている添付ファイルは、YAMLという形式で書かれたテキストファイルです。UPnPのメタデータ (DIDL-Lite) 名が見出しになっていて、その下に、
- TagT2D : TuneBrowserのタグからUPnPのメタデータへの変換時のタグ名
- TagD2T : UPnPのメタデータからTuneBrowserのタグへの変換時のタグ名 (空欄の場合はTagT2Dとおなじ)
という形で、タグ名を定義することができます。
YAML形式は、テキストのインデントでデータの階層構造を読み取りますので、行頭のスペースは変更しないようにしてください。
Zackさんのスキルを拝察して簡単な説明に留めていますが、もしなにか不明点があれば、またコメントしてください。
よろしくお願いします。
こんばんわ。
ご指摘ありがとうございます。たしかに動作がすこしおかしいですね。この部分はあまり役に立たないメニューしか表示されませんが、そういう問題でもないので、改善したいと思います。
ご確認、ありがとうございました。
4.18.0の先行版は、(変更が多岐に渡るので) もうしばらく先行版のまま置いておくつもりです。またなにかお気づきのことがありましたら、お知らせいただけると助かります。
さっそくのご確認ありがとうございました。
ご確認ありがとうございました。
上のコメントにも書きましたが、VorbisCommentのRATINGの値については確たる論拠を持っていませんでしたので、今回のご指摘が良い機会と思い、対応しました。
他の方のご意見もあるかもしれませんので、このトピックはすこしタイトルを変えて、しばらくオープンのままにしておきます。ご了承ください。
wanwan2811さん、TBLoverさん、情報ありがとうございます。
ダンプファイルがないということは、ウィルスバスターなりWindows標準のセキュリティなりにブロックされているのかもしれませんね。先行版のページ書いたように、ある程度ダウンロード数が増えると落ち着く可能性もあると思いますので、しばらくようすを見ることにしましょうか。
こんばんわ。
先ほど更新した先行版の1567で、対応をしてみました。前のコメントで書いたこととちょっと動作が異なります。
- 読み込みについては、とくに設定なしで1-5の値を読み取るようにしています。
- 書き込みも1-5にするには、設定の変更が必要です。変更は「タグの設定」ツリー項目の、「タグのファイルアクセス」「VorbisCommentのRATINGは1-5を使用する」で行います。
- ここでの説明は1-5か1-99となっています。前のコメントで0-100という説明をしましたが、他形式でのWindows Media Playerとの互換性を考えて、100ではなく99を書きこむようになっていました。また0は、タグの値を書き込まないことで実現していますので、書き込む値としては1からということで説明しています。
よろしくお願いします。
こんばんわ。
先ほど更新した先行版の1567で、ウィンドウサイズの問題を改善しています。またお時間のあるときにでもご確認いただけると助かります。よろしくお願いします。
こんにちわ。
お手数をおかけしています。先ほど更新した1567でキーボードの操作を改善しました. ひっょとしたらご指摘の全ケースには対応できていないかもしれません。お時間のあるときにでもまた確認いただけると助かります。
こんにちわ。ご確認ありがとうございました。
食い下がるようで申し訳ないのですが、設定によってFLACの0-5で書かれた値を扱えるようにすることはできなくはないのですが、どうでしょうか。
詳しくいうと、以下のような感じです。
- 設定でFLACのRATINGを0-5として扱う項目を設ける。ここをYesにすると以下のような動作を行う。
- 以後TuneBrowserでの書込みは0-5で行う。
- 読み込み時に0-100で書かれた値は0-5に変換して読み込む。
0-5の値域と0-100の値域が重畳していないので、おそらく可能ではないかと思います。上にも書いたようにFLACの値域は強い根拠に基いたものでもないので、考えてもよいかなと思っています。
念のため、なのですが、上のコメントでわたしが「正式版」と言ったのは、現在公開している4.17.3の正式版のことです。
こちらをインストール、起動して、ダンプファイルが検出されるかどうか、確認してみていただけないでしょうか。
そのダンプファイルが4.18.0先行版の異常を記録している可能性が高く、このダンプファイルがないと、4.18.0の正式版までに問題を改善できないかもしれません。ご協力いただければ助かります。
hiroさん、
はい、仕様です。
ご指摘ありがとうございます。
こちらのトピックでご指摘いただいたキーボード操作の改善を入れたのですが、それが問題を起こしているようです。改善します。
こんばんわ。
正式版をインストールしなおして、起動してみてください。そのときに、もしダンプファイルの送信を訊ねるダイアログボックスが表示されたら、できましたら送信をお願いします。
なお、TuneBrowserのバージョンアップは、もともとあるバージョンをアンインストールする必要はありません。アンインストールすると、それまでの設定やデータベースが消えてしまいます。
こんにちわ。
改めて処理を確認してみたところ、たしかにFLACのRATINGについては、0-5の値を0-100に変換して使用するようにしていました。
★の0個～5個をどのようにタグの値として格納するかについては、メタデータの形式によってさまざまです。FLACのVorbisCommentではその根拠にするものが見つからず、残していたコメントから類推するに、それっぽいものとしてMediaMonkeyやWinampの記述を見つけたので、そこから導出したようです。
ID3v2はいちおう仕様でPOPMが決まっていますので、このような問題は発生しにくいです。
とりあえず、現状は上のような状況ですので、ご報告します。
ありがとうございます。再現させることができたと思います。
致命的な問題ではないので、次のリリース (たぶん明後日だと思います) で改善しようと思います。
こんばんわ。
スクリーンショットありがとうございます。これは… ウィンドウのサイズが変わったにもかかわらず、Album View内部の描画情報が更新されていない状態ですね…。念のために確認をしてみたのですが、わたしのところでは再現させることができませんでした。
毎回起きるのでしょうか?
それと、おそらくこの状態になった場合、TuneBrowser全体のサイズをすこし変更すると、直るのではないかと思います。よろしければお試しください。
こんばんわ。さっそくのご試用ありがとうございます。
ダンプファイル届いていました。内容を確認すると、Album Viewに関する設定変更時に問題を起こす可能性があることがわかりました。可能性があるというよりは、ほぼ起きそうですので、この問題については今夜中に対処して更新したいと思います。
Keyword Viewは動作していますか。新しいViewの追加はひさしぶりですので、ちょっと緊張していました。
なにかお気づきのことがあれば、またよろしくお願いします。
こんにちわ。
古いトピックを持ち出してきてすいません。先ほど4.18.0の先行版を公開しましたが、このバージョンで、思うところあってここで処置した内容を元の仕様に戻しましたので、ご連絡します。
設定で、「基本の設定」-「操作の設定」、「マウス操作の設定」-「非アクティブ時もマウスを処理する」をNoに設定すると、ここで処置した動作に戻ります。
よろしくお願いします。
こんばんわ。
仔細を調べていただき、ありがとうございます。設定ファイル上で、UPnPのメタデータとTuneBrowserのタグの関係を定義できるように、検討してみます。
ちょっとややこしいのは、「TuneBrowserのタグからUPnPのメタデータに変換する」場合と、その逆に「UPnPのメタデータからTuneBrowserのタグに変換する」に変換する場合で定義が必ずしも互換になるわけではないところです (後者は、UPnPコントローラーからTuneBrowserの知らない曲を指定された場合に使用します)。
こんばんわ。
その後考えてみたりもしたのですが、やはり、トラック単位で表示する情報はそのトラック単体で得られる情報から生成するというのはとても大きな前提で、ご要望の動作の実現は困難でした。ご理解いただきありがとうございます。
こんばんわ。
その後考えてみたりもしたのですが、やはり、トラック単位で表示する情報はそのトラック単体で得られる情報から生成するというのはとても大きな前提で、ご要望の動作の実現は困難でした。ご理解いただきありがとうございます。
ご確認ありがとうございます。
すでにRAMDecodeを使わない方法も試されたのですね。前のコメントを書いたあと、むしろRAMDecodeをやめたほうが、継続的な処理になって再生が安定するかも、と考えていたところでした。
あまり的確なコメントができませんでしたが、もうしばらくこのトピックはオープンしておきますので、またなにか (他の方でも) お気づきのことがあればコメントいただければと思います。
こんばんわ。
ごく稀に音飛びが発生する可能性は、どうしても否定はしきれません。1時間に1回はちょっと多いような気がしますが、わたしの環境でも数か月に1回くらい、突然に発生することはあります。数秒間再生が止まって、その後何事もなく再生が継続します。そのときにはPlayer ViewのDECDインジケータが点灯して、デコーダ待ちが発生したことを示していました。
自分の環境ですから、その後仔細に状況を調べたところ、見た目のままデコードスレッドが一時的に動作していなかったことがわかりました。なぜ動作していなかったのかについては、確たるところはわからず、以下の2つの可能性しか思い至りませんでした。
- Windowsのスレッドのスケジューリングが停滞した.
- ログ出力のためのディスクI/Oが停滞した.
わたしの環境では、問題発生時に備えるため常時ログをディスクに出力しています。皆さんのところではログをディスクに出力するようにはしていませんので、とくにRAMDecodeをご利用の場合は、2番目の問題は発生しません。
1番目の問題は、WindowsというOSの原理上、発生してもおかしくはありません。詳しくは省略しますが、WindowsはいわゆるリアルタイムOSではないためです。ただ現実にはマルチコアCPUが一般的になり、その性質が表面化することは現実にはほぼありません。わたしのところでも、仮にこれが原因だったとしても、上に書いたように数カ月に1回とか、そういう確率です。
tocchik1962さんの環境では、すでにRAMDecodeご利用になっているようですので、ディスクI/Oの問題はなさそうに見えます。すこし気になるのは、「DSD5.6・11.2MHz、PCM384kHz/24bitあたり」というと、1曲のサイズも相当大きくなると思いますが、それに対してメモリ8GBはちょっと心許ないかも、という点です。
実装メモリ容量が少ない環境への対策として、自動モードのRAMDecodeの場合、TuneBrowserは対象の曲数を自動で調整してメモリの圧迫を抑制します。ご存知と思いますが、Windows (に限らずたいていのOS) は実装されているメモリ容量以上のメモリをアプリケーションに提供できるようにしています。アプリケーションにはメモリと見せかけて、実際にはディスク上にその内容を移しておく、いわゆるスワップとかページングと呼ばれる操作です。これが発生すると、結局はディスクI/Oが発生することになるので、TuneBrowserは上記のような抑制策をとっています。
ただ、いくらTuneBrowserが自粛したとしても、ほかのアプリケーションがメモリを使用していたら結局スワップは発生しますし、Windowsの判断によってはほかのアプリケーションのためにTuneBrowserの実メモリ割り当てを削減してしまう可能性もあります。そしてスワップは時として非常に重たい処理になることもあります。
音飛びの要因がこれだとは断定はできませんが、いただいた情報からぱっと気がついたのは、このような点でした。
serenityさん、フォローありがとうございました。
こんにちわ。
ご指摘ありがとうございます。4.17.3で「CUESHEET内でTRACKから参照されていないFILE指定があった場合には読み込まないように」という処理を入れたのですが、それがInternal CUESHEETで副作用を起こしているようです。
次のリリースで改善します。
それと、悩みに悩んだのですが、現在先行版として公開している4.17.4は、正式版にはしないことにしました。ご利用の方によっては音質の差異が認められていることは承知していて、それを否定するものではないのですが、やはり作者としてはリリースの意味が明確に説明ができそうにないので…。
ご了承ください。
こんにちわ。
ご紹介いただいたシステムは一度アナログ出力した波形を元のデジタルデータと自動で照合できるのだとすると、オシロで言うところのトリガの仕掛け(解析)がよほどうまくできているのですね。ちょっと驚きました。
ただ、わたしが「客観的に」と言った表現が、どうも良くなかったかもしれません。音質の変化に関するわたしの考えはこのトピックの#10144, #10159あたりに書いた通りです (いずれも長文で恐縮です)。TuneBrowserが出力しているデータがバイナリレベルで完全に一致している状況で、ご紹介いただいたシステムによってバージョン間で波形の差異が確認できたとして、そして旧バージョンのほうが多くの人にとって好ましかったとして、ここまで進めてきた検証と議論に沿うと、結局のところここで開発を終了して、すでにリリース済みのTuneBrowserをご利用いただくようにする以外には現在のところ策がありません。
「客観的に」と言いながら曖昧な言葉になってしまっていて申し訳なかったのですが、いまのわたしに対応ができそうなのは、あくまでTuneBrowserというソフトウェアから出力するデータに差異があれば、ということになりそうです (なんとも味気ない話ですいません…)。
それはそれとして、どうしても一オーディオ好きとして好奇心はあります。実際には、どうなんでしょう。ここで皆さんが聴き分けられたような音質の差異は、本当にこのシステムによって確認できるものなのでしょうか?
以前こちらでお話ししたように、わたしは人間の聴覚は計測器の出力よりも遥かに敏感であると思っています。これは、そこに書いたように、点検や探知業務などで、測定器の表示ではなく耳で検知している職業の方々と知りあう機会があったときに痛感した話です。今回皆さんが話題にされているような音質の話は、そういう領域の話ではないかという気もします。
結果を知りたいような知りたくないような。結果に賭けられているものが大きいので、やっぱり作者としていまは知るべきではないかもしれませんね。ここではなくわたしの知らない別のところ(?)でそういう検証の議論がされると面白いのですが。
こんばんわ。
一度確認なんですが、青丸のカーソルを合わせる詳細画面で曲を選曲して再生させるとそのアルバムのみの再生で、再生は停止するということでいいんですか？
はい、再生対象はウィンドウ毎に決まります。議論の余地はあるかもしれませんが、現在はそのような動作になっています。
別件については、別のトピックを立てていただければと思います。
TaiichiroKさん、コメントありがとうございます。
ご指摘いただいた内容を正確に捉えきれていないかもしれませんが、今回の件は、アルバム単位での再生の設定をオフにした状態で操作されています。そのため、ご指摘の事象とはすこし異なるような気がします。
何度もありがとうございます。そうですか…。
操作された状況はわかってきましたが、残念ながら原因ぽいものはつかめていません。
Library Viewerから再生操作をして、あるアルバムで再生がとまったときに、Playback Queueを見てみると、そのアルバムが最後(または単独)になっていてつづきにあるはずのアルバムはない、というのは共通の状況でしょうか?
たとえば最初に #10118 でご報告いただいた例だと、”RedSwan [進撃の…” がPlayback Queueの最後のアルバムになっていて、そのつづきにあるはずのZARDは入っていない、という感じでしょうか。ここまでご説明いただいた内容からおそらくそうだと思うのですが、念のための確認です。
また再生されるアルバムに再現性 (いつもこのアルバムの前で止まってしまう、とか) はありますか? 上の例だと “RedSwan [進撃の…” とZARDのあいだでいつも止まってしまうのでしょうか?
こんばんわ。
アルバム1枚しか再生されないケースは、最後にアップしていただいたウィンドウから再生した場合でしょうか。
もしそうだとすると、これはBMMNJIMさんが指摘されていたケースで、そのポップアップウィンドウにはひとつのアルバムしかないので、そのひとつのアルバムだけが再生対象になります。
よくよく考えると直感に反した動作になっているのかもしれませんが、そのような仕様となっています。
こんばんわ。
ご利用のWindowsかマイクロソフトストアに問題が生じている可能性もあるのですが、以下のような点を確認してみてください。
- UWP版のTuneBrowserをご利用になっているか
- UWP版でライセンスを購入したときのマイクロソフトアカウントをご利用になっ ているか
- PCがインターネットに接続されているか(ここに書き込まれているということは接続されているとは思いますが)
またこちらのトピックなども参考にしてみてください(あまり参考にならないかもしれませんが…)。
ご確認ありがとうございました。
詳細な情報をいただいたにもかかわらず、スクリーンショットからの簡易な印象で申し訳なかったですが、ドライバの事情をうかがうと、たしかに問題がありそうかなと思いました。
ご確認ありがとうございました。
serenityさん、フォローありがとうございました。
ちなみに、ですが、Player Viewの右下のところのインジケータをクリックしても変えることができます。
BITP / BP:1 / BP:2 などと表示されている部分です。
Windowsアップデートは関係ないと思います。
スクリーンショットありがとうごさいます。
Kazooは当該部分についてメタデータのdc:creatorまたはupnp:artistを出力しているぽいです。正確なところはLINNに問い合わせていただくか、LINNのフォーラムなどを当たる必要がありそうです。
LINNのフォーラムは、こちらのLINNのページから
こちらのフォーラムサイトにリンクされていますので、これがオフィシャル的な(?)扱いのようです。
TuneBrowserはdc:creatorには_GARTISTタグ、upnp:artistにはARTISTタグを渡しています。こうしたUPnPメタデータとタグのマッピングは対応がたくさんあって現在のところ設定には公開していません。
TuneBrowser側から設定でどうこうするのはちょっと難しい感じなのですが、参考になりますでしょうか。よろしくお願いします。
こんにちわ。
serenityさんご指摘のDSD再生の場合のほか、Bit Perfect設定になっていると、ボリュームの制御は効きません。確認してみてください。
こんにちわ。
「二行目」について、できればスクリーンショットで「この部分」と示していただくことはできますでしょうか。模式的なものでも構わないのですが…。
VST3は地道につづけています。
ご確認ありがとうございました。
Chartreuxさん、どうかそのように謝らないでください。Chartreuxさんには、過去幾度も窮地を救っていただき、大変感謝しています。これからも助けていただけると大変うれしく思います。m(__)m
皆さん、ご意見・ご声援ありがとうございます。個別に返答できずすいません。
今回の件以前から申し上げていたように「機能をざくざく追加していく」フェーズはひと段落してペースダウンはあると思うのですが、TuneBrowserはシェアウェアにしたことも含めて「いかに継続するか」を大切なポイントと考えてやっています。そのためには開発環境の更新もつづけていく必要はあるのですが、現在のところTuneBrowserの開発を止める予定はありません。
それはそれとして、TuneBrowserは、オーディオに関する道具のひとつのつもりですから、音質の議論ができないというのも残念な話です。ukatさんが紹介されたようなべつの場所で、というのもあるでしょうが、今回TuneBrowserの内部だけでなく出力したデータを外部で受信して検証する仕掛けを整えましたので、客観的に評価・検証できる範囲での疑義があれば、今後もここでお知らせいただければと思います。
こんばんわ。
Chartreuxさんが最初にご発言された以降の流れは、大変困惑させてしまったことと拝察します。「音変わった?」→「処理ミスってました」→「治りました」となればよかった(?)のですが、結局「再生系の処理は変えていない」し「出力データもバイナリ一致している」ということで、デジタルオカルトの領域に入りました。
じつは以前にも何度か同様のご指摘はいただいていました。それらはいずれも「良くなった」というお話しだったのと、その都度大きめの処理改善があったと記憶しているので、そのご説明をして、出力データは変わっていないことを認識しつつも、それ以上は深く突っ込まずにきました。それは突っ込んだとしても、このトピックでこれまでご説明してきたように、音質操作の所作ではなかったからです。
今回はご報告の内容から問題として取り組んでここまで来たわけですが、正直なところ途中で心が折れそうになったことは事実です。ただ一方で、TuneBrowserを信頼してご利用いただいているユーザーの方々に、わたしがどういう考え・スタンスで開発を行って基本的なTuneBrowserの品質を確保しているか、そしてその結果であるTuneBrowserはバージョンやチャンネルにかかわらずバイナリ一致するデータを出力していることを改めてご説明する機会となりました。
そして最後に、デジタルオカルトの話が残りました。というか、デジタルオカルトの話はやはり存在しているのかも、と多くの方々に印象づける結果となったのではないかと思います。できればそれを、趣味の一環として楽しんでいただけるようになれば良いのですが。
わかりました。ご確認ありがとうございました。
BMMNJIMさん、フォローありがとうございます。
たしかにご指摘の操作だとそのViewには1アルバムしか表示されていないので、1アルバムだけの再生になりますね。
それと、ヘッダー表示は、それ独自のViewの設定はなく、トラック一覧表示のトラックを表示しないという状態です。ですので、トラック一覧表示のアルバム共通部分とおなじ表示、挙動になります。トラック表示のない表示形態ととらえると、たしかにご指摘のようにほかとちょっとちがうということになりますね。
こんばんわ。
「再生すると再生しているアルバムのみの表示になってしまいます」のときの「再生する」操作は、Library Viewerのどこか途中のアルバムを選択して再生する、ということですよね?
おそらく設定の問題ではないと思います。なにか別の問題が起きていると思うのですが、まずはわたしのところで再現させるために、そこに至る操作を細かく確認させていただきたいです。
こんにちわ。
対応に時間がかかっていてすいません。現在のところ再現ができていないのですが、その過程でタブの配置換えの問題を見つけました。この問題がご指摘の事象につながっているかどうか、微妙なのですが、次のリリースで改善します。
このタブの配置換えは、ベースとなるマイクロソフトのフレームワークとの兼ね合いでむかしから問題児で、今回の調査で長いあいだ潜伏していた不具合が見つかった格好です。これで改善していると良いのですが…。
こんばんわ。
“Prev Track”というのは、ひとつ前のトラックという意味ですので、ひとつ前のトラックを再生することになります。その曲の先頭からもう一度再生したい場合は、現在のTuneBrowserでは停止-再生と操作します。
(以前は再生中に再生ボタンを押すとその曲の冒頭から再生する動作をしていたのですが、理由は忘れましたがご指摘があって現在の動作になっています)
こんばんわ。
検証とご報告、ご意見、どうもありがとうございました。
コンパイラによって音が変わっているというご報告は、藤本健氏の言われているようなデジタルオーディオのオカルトネタがひとつ (やっかいなところで) 増えたという感じですね。念のために申し上げておくと、同氏は「オカルト」という言葉を使われていますが、決して否定的なものではなく、前回ご紹介した記事にもあるように、それをオーディオのネタのひとつとして楽しもうというスタンスに立たれていると理解しています。わたしも同感です。
同氏の記事のタイミングと同様に、まるで今回の議論に合わせたかのように、日本マイクロソフトのJapan Developer Support Core Teamから1月21日に以下のブログ記事が公開されていることに気がつきました。
この記事では、TuneBrowserが全面的に使用しているC++という言語については、同一のソースコード、同一のコンパイラを適用した場合、動作や機能は同一だとしても生成されるバイナリは同一とは保証されない、バイナリ内部のタイムスタンプや乱数的要素だけでなく、そもそも「決定論的ビルド」がサポートされていないと説明されています。
最近のC++コンパイラは、CPUのSIMD拡張と合わせて極めて高度な最適化を行いますので、決定論的ビルドが困難であることは理解できます。そして現在のTuneBrowserのソースコードは、コンパイラの進化に合わせてその最適化をできるだけ引き出せるように考慮した構造になっており、とくに性能に機微な部位はソースコードの変更のたびに生成されたアセンブラコードを確認するようにしています。
その経験から「ビルドのたびにバイナリコードが変わっている」という事象を目にしたことはほとんどなく (じつは数年前の数か月間その現象に悩まされた経験はあるのですがいまは解決しています)、生成されたバイナリコードはそれほど変動するものではないと思うのですが、わたしがアセンブラで確認できるのは本当にコアな処理の一部であり、その物量からとても全体を確認することはできません。つまり、ビルドのたびにバイナリコードが変動するリスクが発生します。
どうすべきでしょうか。ビルドしてリリースするたびに、「今回は音がいい」「残念、今回はもうひとつ」と一喜一憂していただけばいいのでしょうか (皆さんがそうではないと言われていることは重々承知しています。これは単に自問自答です)。
ASIOドライバが受けとったデータも含めた今回の検証で、こうした結果は、わたしの意思・技術力・開発行為とは別のところで発生していて、ケーブルの材料のように開発者の意思で選択できるようなものではないということはご理解いただけたのではないかと思います。そのような言い方をすると何となく責任逃れのような感じがして自分でも気持ちの良いものではありませんが…。
いっぽうで、今回の議論で、わたしの開発したソフトウェアがこのように高度な (=趣味性の高い) 領域での音質の議論ができる再生能力を持つに至ったことに、(へんかもしれませんが) 感慨も感じています。10年以上、良くなろうと念じながら自分の全力を投じて開発をつづけてきたわけですが、それは地道にデータの精度と処理に気を遣って改善する活動であって、決して「ここをこうして高域の質を上げてやろう」とか「低域を膨らまそう」とか、そういう音質選択的活動ではありませんでした。にもかかわらず、今回の議論ができるということは、ある意味その地道な開発の結果のひとつの現れなのかなあとも感じています。
コンパイラのバージョンは、上のマイクロソフトの説明から決定論的ビルドが保証されない以上、あまり強くこだわっても仕方がないのかとも思います。当面は4.17.4で使用したコンパイラを使用しますが、その結果として趨勢の進化から取り残されるようになるのも本意ではないので、必要があればバージョンは変更すると思います。
こんにちわ。
ご所望のような再生ができるようにするために、CUESHEETというテキストファイルがあるのだと思います。TuneBrowserはCUESHEETに対応しています。CUESHEETの作成は凝った記載をしなければ、手作業で作成できる簡単なものです。このファイルについてはインターネット上にたくさん情報がありますのでここでは解説はしませんが、試してみてください。
CHESHEETのファイルの拡張子は .cue にしてください。
回を重ねることは気になさらないでください。わたしの確認の仕方もよくないのだと思います。
うーん、そうですか。とくに変わった点はないのに、複数アルバムがPlayback Queueに入る場合と、選択した一つのアルバムだけがPlayback Queueに入る場合があるということですか。
すいませんが過去に例のない現象で、わたしのところでは再現もできません。しばらく、他の方々のところでも同様の事象が起きていないか、ご発言を待ってみましょうか。
ありがとうございます。お手数をおかけしました。
最後の「次のアルバムを再生されないPlayback Queue」のスクリーンショットにはひとつしかアルバムがなく、再生を期待されている「次のアルバム」が入っていないので、再生されないのだと思います。
このときの操作をもうすこし詳しく教えていただけないでしょうか。
ご期待に沿えず恐縮です。おそらく音を出すところまでであれば大きな問題はないとしても、TuneBrowserで扱うにはメタデータ(タグデータ)の取扱いが課題になりそうと感じました。
CUESHEETもある種のコンテナと言えると思いますが、その解釈の揺らぎには本当に苦労しました。おそらく、Matroskaでも、メタデータの部分についてはその定義をみるかぎり、同様の課題が出るものと思われます。
ご意見・ご感想、ありがとうございます。
ちょうど今日、インプレスのAV Watchにおいて藤本健氏の「「オカルト話をぶった斬る」から20年。デジタルオーディオは厄介で面白い!」が掲載されましたね。まるでこのトピックでの議論に合わせたかのような話題ですこし驚きました。CD-Rが活躍していたころのCDとCD-Rの音質のちがいや、デジタル系ケーブルの音質のちがいの話題を振り返られています。
hi-resさんにおっしゃっていただいた、ソフトウェアの果たすべき責任はビットパーフェクトの出力を行うところまでではないか、というのは、たしかにその通りと思います。
それ以外に、わたしがとくに気にしているのは、上にも書いたように処理の負荷ですが (AVX2版を出したのもそれが動機です)、これにしても、絶対的にその方向が正しいという話はありません。
- 処理の負荷を気にしている、なんて、Active Backgroundのような無駄の極致みたいな機能をつけておいてよく言う、と思う方もおられるかもしれませんが、そこはこれまでにもお話ししているように、音楽の楽しみとのトレードオフです(^^;。不要なら機能をオフにすることができます。Active Backgroundをオフにして、デスクトップ表示もやめて、ネットワーク関連の機能も切って、TuneBrowserを最小化すれば、ほぼよけいな機能は動作しなくなります。ついでながら、TuneBrowserは自身が最小化されたことを検知すると、より抑えた動作に切り替わるようにしています。
こちらのトピックで、PCとDAC機器で接続されているグランドラインの影響の話を紹介しました。わたしにはそれが正しいと断じるほどの知識はありませんが、なにをやっても音は変わるという世界ですから、影響はあるかもしれないとも思います (わたしの使用しているUSB DACにはガルバニック・アイソレーションが搭載されていて、そういうこともDACの性能のひとつとして気になります)。
むずかしいのは、たとえばケーブルの世界であれば、金メッキなら、ロジウムメッキなら、あるいは銀線なら、といった観点である程度傾向が認知され嗜好を反映することもできつつありますが、ソフトウェアの世界ではそういったわかりやすい方法論は見出せそうにないということです。さらにやっかいなのは、(ときどき思うのですが) 処理負荷を下げたほうが良さそうに思えるこの話も、逆に上げたほうが良くなると感じる可能性も否定できないことです。これは、べつのトピックで触れた例のように、リサンプル処理でサンプルレートを上げたほうが良いのかどうか、という話に似ています。あるいは、これは極論なのかもしれませんが、ディザの概念のように、多少の高周波ノイズが入っていたほうが、聴きやすい音と感じる方もおられるかもしれません。
「データを正確に取り扱う」という以外には絶対に正しいと言える方法論がない状況で、結局は、皆さんにおっしゃっていただいたように、わたしはわたしの思う方向に開発を進めていくしかないなと思います。
わかりました。アルファベット順でなければ、というわけではなさそうですね。ありがとうございます。
こんにちわ。
バイナリ比較の結果については、ご指摘の通り、わたしもあまり心配していませんでした。ただ、たまたまバージョン間で広範に修正した経緯があったので、明確に説明できる必要があるなと思い、今回の検証環境を用意しました。
出力バイナリデータに差異がない状態での音質の変化は、ひとつ前のコメントや以前のコメントにも書いたように、否定するものではありません。その要素のひとつとして、わたしが思いつく範囲ではコンパイラのちがいというものがあるかも、と思い、今回4.17.4を用意しました。
4.17.4でもやはり4.17.0とは異なっているというご試聴の結果は、残念なような安心したような微妙なところです(^^;。残念な点は、音質の変化の要素がまたわからなくなったということです。安心した点は、古いコンパイラバージョンに縛られる必要がなくなり、これまで通り趨勢の変化に追従して進化していけるということです。
ただ、「あまり時間が取れていないのですが」と書かれていました。もしよろしければ、まだしばらくこの先行版の状態にしておきますので、どこかで改めて比較してみていただけないでしょうか。おそらく集中できる環境と気力(?)が必要で簡単なことではないと拝察しますので気軽にはお願いしづらいのですが、急ぎませんのでできましたらお願いします。
音質については、折に触れわたし個人としては「ある一定以上のレベルであれば、良いか悪いかではなく、好きか嫌いかだ」と思う旨、書いてきました。わたしの古いスピーカーB&W 802Dはツィータが特徴的で、登場当時には賛否両論がありました。実際にB&Wの取説には「そのうち耳のほうが慣れてくるから」と書かれています。あるいはデジタル音源とLPの音、半導体アンプと真空管アンプの音、A級アンプとAB級アンプの音、いずれもどちらの音質が良いか悪いかという話ではないと思っています。
また音質を左右する要素の話として代表的なのは、ケーブルによる音質差異があります。とくにデジタル系ケーブルや電源ケーブルなどについては最近では多くの方が音質の差はあると認知しつつも、差がある技術的な理由については、明確な共通認識には至っていないと理解しています。
それらを踏まえたうえで、TuneBrowserの音質差については、以前「TuneBrowserは高域を操作している」というデマ情報については明確に否定しましたが、逆に、出力データのバイナリレベルでの一致を確保した上でそういう自分の思う音質の操作ができたらどれだけ素敵だろうと思います(^^;。残念ながらそれはできませんので、このまま今回も理由が明確にならないとしたら、これまで通り、TuneBrowserのなかを通過していく大量のデータの精度に最大限の注意を払いながら、負荷変動を極力抑えるように開発を進めていくということになりそうです。
なるほど、プロテクトがかかっていないのですね。以前、古いブログで同様の例を (メディアはDVDでしたが) 紹介したことがあります。このような場合、そこにも書いたようにPCMデータを直接コピーできるとか、そういうものではないのでしょうか?
Matroskaコンテナをサポートするには、それなりに長い道程になりそうです (正直なところ気が遠くなります(^^;)。他の方々からも同様のご要望があるか、しばらく待ってみましょう。
いわゆるハイレゾ音源については、PC向けと専用ハードウェアによるプレーヤー向けで、所有形態としては道が分かれてきたように思います。PC向けの音源はつまりダウンロード形式などですね。日本国内では統制が厳格であるが故に品ぞろえ (あるいは音源を探し出す手段) に限りがあり、いま一歩物理メディアの代替になり切れないのが残念でなりませんが、いまから物理メディア向けの機能を追加してくことについては、慎重になるざるを得ない点はご理解いただければと思います。
ブルーレイ・オーディオは、合法的にリッピングできるようになったのでしょうか。
ハイレゾ音源のメディアとしては個人的にはかなり微妙な立ち位置だと思っていましたので、もし趣旨替えしたのだとしたら、それはそれでよいことだと思いますが…。
こんばんわ。
最初のコメントに戻るのですが、再生操作を行ったあとの、Playback Queueの内容を確認していただきたいです。
これは、壊れたMP3ファイルですね。ひょっとしたら拡張子がMP3というだけで、中身はMP3ではないのかもしれません。
どれくらいの大きさのファイルかはわかりませんが、Valid frame: 0 となっているので、MPEGとして有効なフレームはひとつもなかったという状態です。
そうなんです。私もカーソルキーでできるかと思いましたが，下にいってしまうのです…。
あー、ですよね…。ちょっと考えてみます。
スクリーンショットありがとうございます。
これは、A,B,Cの3つのアルバムのあるタブに対して全再生を行ったときのPlayback Queueでしょうか? ひとつもトラックが入っていないように見えるのですが、この状態で「A→Bは再生が続く」「B→CはBの再生が終わるとCの再生が続かない」とはならないような気がするのですが…。
こんにちわ。
A)について、そんなことを言っていましたっけ? もしよろしければそのトピックへのリンクを示していただけると有難いです。
もしそれに類した発言をしているとしたら、記憶にあるのはこちらの発言ですね。ここで言いたかったことは、カジュアルに音楽を聴きたいときに、全体のゲインを下げておくと、ReplayGainの効き幅に余裕ができるので、よりReplayGainの効果が得やすく、聴きやすいということです。いまでも、わたしはふだんはそのようにしています。またWalkmanやカーオーディオ用などポータブル機器向けの音源を作るときにも、そのようにしています。
B)については、-10dBは懸念があるとかそのような理由はありません。以前使っていたJeff RowlandのSynergyというプリアンプには各入力ごとにゲイン設定があり、大変便利だったので、TuneBrowserにもそれに類した機能をつけました。そのときに何となくSynergyが-10dBまでだったような記憶があってそのようにしています。
ちなみに、いま改めてSynergyのマニュアルを確認してみると、最小値は-20dBでした(^^;。だからというわけではありませんが、もしニーズがあるようでしたら-20dBなど設定範囲を広げることは可能です。ただ基本的には出力機器のゲイン差を吸収する目的のものですので、そんなに幅の大きな値を設定することはあまり考えていませんでした。
こんにちわ。
2点ご連絡します。
まず、4.17.3のソースコードに対して、4.17.0とおなじコンパイラでビルドした版を4.17.4の先行版としてアップしました。これを正式版にするかどうかは未定です。興味のある方はお試しください。
つぎに、検証用の専用ASIOドライバを作成し、TuneBrowserから受信したデータをASIOドライバ側で記録できるようにしました。そしてefu氏のWaveGeneを使用してL/Rチャンネルにまったくおなじ信号を記録した24bit Wave形式のファイルをTuneBrowserで再生し、検証用ASIOドライバで記録したデータについてバイナリ比較を行いました。
その結果、4.17.0と4.17.3の両バージョン間でデータが完全に一致し、またL/R間でもデータが完全に一致することを確認しました。これにより、バージョン間やL/R間で意図しない改修が入りデータに差が発生しているという可能性はないと考えています。
このことは、音質に差があるように聴こえる経験を否定するものではありません。みなさんのご検討の一助となればと思い、ご報告します。
ご確認ありがとうございます。
タグ名を並べて書くときに、アルファベット順に指定しないと認識されなかったということでしょうか?
こんばんわ。
“; “を値の区切りと認識するタグは、事前に登録しておく必要があります (タグによっては支障があるかもしれないので)。
設定ダイアログボックスのツリー項目「タグの設定」、右側の項目「タグの設定」「複数文字列を格納するタグ」(いちばん上です)に指定します。既定の設定でたくさん並んでいるので、ちょっと操作しにくいですが…。
こんばんわ。TuneBrowserのご利用ありがとうございます。
実際には問題ないのかもしれませんが、選択すると内部の状態が変わってしまうので、フォーカスをあてるだけにしています。Playback Queueの再生中の曲を示す場合も、同様にフォーカスだけの処理です。
ただ操作してみて、トラックにフォーカスのある状態でカーソルキーを動かすと、そのトラックが選択されてもいいような気がしますが、実際には下カーソルキーの場合その次の行が選択されてしまいますね。これは見直してもいいかもしれません (エクスプローラーなどとは動作が変わってしまいますが…)。
こんばんわ。
動画まで撮っていただきお手数をおかけします。なかなか反応できずすいません。また改めてご連絡させていただきます。よろしくお願いします。
こんばんわ。
仔細の情報、ありがとうございます。一次的には、ウィンドウが真っ黒になっていることから、ディスプレイドライバとそのDirectXのなかで落ちているような感じです
取り急ぎ、簡単なコメントで失礼します。
こんばんわ。
だいたいご認識で合っています。
2)のところで、ゲインの値によっては32bit浮動小数点に変換されます。
あまりに驚いてすこし断定的な書き方をしてしまいましたが、左右のバランスが偏って聴こえるという経験そのものを否定するつもりはありません。TuneBrowserの左右のバランスがおかしいというご指摘は解せないと言いたかっただけです。わたしも以前、自分のオーディオ機器でそのような事象に悩んだことがあります。部屋の問題か、アンプやケーブル・コネクタの問題か、あるいは自分の耳の問題か…。気になりだすと気になって、どうも偏って聴こえるような気がしたものです。
ちなみに、それを確認するために、TuneBrowserには再生中にモノラルに切り替えたり、左右のチャンネルを入れ替える機能があります。数か月のあいだ折に触れ悩んだ結論としては、「どうも気のせいだ」ということでした。みなさんも気のせいですよ、などというつもりはまったくありませんし、ここで発言されているような方々は一定の見識を持たれていると思うのですが、意識の下に密かにあるような先入観を排除するのは意外とむずかしいものだということは、共通の理解としておきたいところです。
こんばんわ。
バージョンによって左右の音量差があるという話は、どうも解せません。今回のバージョンによる音質差は、上に書いたように、
- 意図しないソースコードの変更が行われている可能性
- コンパイラのバージョンちがいによる生成されるバイナリコードの差異
の2点を考えています。しかしこれらは、再生処理全体に影響を及ぼすことはあったとしても、左チャンネルだけ、右チャンネルだけ、という作用をするものではないと思います。TuneBrowser内ではモノラル・ステレオ・マルチチャンネルの3系統の再生処理があり、ステレオは2チャンネル専用の処理ですが、完全な対称性を持っており、左チャンネルだけ、右チャンネルだけといった特別な処理はありません。
ありがとうございます。了解しました。
大変な無理を申し上げることになるのだと思いますので恐縮なのですが、4.17.0と4.17.3の間、つまり4.17.1と4.17.2も含めてみたときに、どのあたりで変化が発生したのか、できれば情報をいただけると助かります。
(発生している変化が顕著なようですので、だんだんと変化したということはなくて、どこかのバージョンで変化したのだと思っています。そうではなく、やはりだんだんと変化したということであれば、その旨お知らせください)
前のコメントの「再生中の動作に作用するようなものはありません」は「再生中の動作に作用するようなものはなさそうです」が正しい表現です。その点もあわせて見直します。
こんばんわ。
TuneBrowserはタグの値を変更した際には、FLACファイルなど音源ファイルのタグを書き換えていますよ。
こんばんわ。
4.17.0と4.17.3のあいだの再生に関する処理の変更は、機能面ではChange Logに出ているように、設定値の範囲の変更やデバイスの初期化の考え方の変更といったもので、再生中の動作に作用するようなものはありません。
機能の変更にかかわらない変更は多数行っています。たとえば内部の処理の最適化や、関数名・変数名の見直しなどです。それらの過程で、意図せず結果が変わるような変更を行っている可能性は否定しきれません。
また、11月から12月にかけて、使用しているコンパイラ (テキストで書かれたソースコードを、実行できるバイナリコードに変換する道具) の標準動作が変わり、その対応を広範囲に行っています。
4.17.0のリリースは9月、4.17.3のリリースはこの1月頭で、4カ月の期間があり、その間での変更を洗い出すにはかなりの時間がかかりそうです。
ちなみに、使用している音源のコーデック (FLAC, Wave, MP3など) は何でしょうか? 絞り込むヒントにできればと思います。
よろしくお願いします。
返信ありがとうございます。
残念ながらもうひとつ状況がよくわかりませんでした..。Playback Queueの内容は確認されましたか?
こんにちわ。
念のために確認をしてみたところ、機能としては期待通りに動作しているようです。
再生操作を行ったときに、対象の楽曲群がPlayback Queueに入ります。そこには他のアルバムも投入されているのでしょうか?
また「アルバムによっては」と書かれていますが、特定のアルバムだけでそういった現象が起きるのでしょうか?
わかりました。解決してよかったです。
こんにちわ。
ご提示いただいた情報だとどのようなデバイスを使われているかなどがまったくわかりませんので、Player Viewのスクリーンショットを添付していただけないでしょうか。あるいはログの全文をテキストファイルに落としていただいて添付していただいてもかまいません。
こんばんわ、ログのアップありがどうございました。
おかげさまで、思いがけない形でしたが状況がわかりました。
「正常」としてお送りいただいたケースでも、やはりサンプルレートの設定に失敗していました。ZoomのUDAC-2は、写真で見るかぎり機器のパネル面でのサンプルレートの確認ができないようですが、TuneBrowserのPlayer Viewでの表示では、曲のサンプルレートが96kHz、機器のサンプルレートが48kHzと表示されていると思います。この48kHzは、おそらく機器のデフォルトのサンプルレートで、残念ながらこのサンプルレートで再生されているものと思われます。
1559で「再生デバイスの問題で再生できない場合のメッセージを明確化」したときに、機器側がそのサンプルレートで再生できると言っているにもかかわらず、実際に設定できなかったときにはエラーにするようにしました。1558までは、ここを曖昧に「そのサンプルレートに対応していないだけ」と扱っていました (そのため、結果としては意図しないサンプルレートで再生されることになっていました)。
どうするか、ですが、わたしとしてはDAC側の動作がおかしいと思うのですが、なにか救済する考え方ができないか、もうすこし検討してみます。