フォーラムへの返信
-
投稿者投稿
-
Tikiキーマスター
serenityさん、フォローありがとうございました。
Tikiキーマスターこんにちわ。
ご指摘ありがとうございます。4.17.3で「CUESHEET内でTRACKから参照されていないFILE指定があった場合には読み込まないように」という処理を入れたのですが、それがInternal CUESHEETで副作用を起こしているようです。
次のリリースで改善します。
Tikiキーマスターそれと、悩みに悩んだのですが、現在先行版として公開している4.17.4は、正式版にはしないことにしました。ご利用の方によっては音質の差異が認められていることは承知していて、それを否定するものではないのですが、やはり作者としてはリリースの意味が明確に説明ができそうにないので…。
ご了承ください。
Tikiキーマスターこんにちわ。
ご紹介いただいたシステムは一度アナログ出力した波形を元のデジタルデータと自動で照合できるのだとすると、オシロで言うところのトリガの仕掛け(解析)がよほどうまくできているのですね。ちょっと驚きました。
ただ、わたしが「客観的に」と言った表現が、どうも良くなかったかもしれません。音質の変化に関するわたしの考えはこのトピックの#10144, #10159あたりに書いた通りです (いずれも長文で恐縮です)。TuneBrowserが出力しているデータがバイナリレベルで完全に一致している状況で、ご紹介いただいたシステムによってバージョン間で波形の差異が確認できたとして、そして旧バージョンのほうが多くの人にとって好ましかったとして、ここまで進めてきた検証と議論に沿うと、結局のところここで開発を終了して、すでにリリース済みのTuneBrowserをご利用いただくようにする以外には現在のところ策がありません。
「客観的に」と言いながら曖昧な言葉になってしまっていて申し訳なかったのですが、いまのわたしに対応ができそうなのは、あくまでTuneBrowserというソフトウェアから出力するデータに差異があれば、ということになりそうです (なんとも味気ない話ですいません…)。
それはそれとして、どうしても一オーディオ好きとして好奇心はあります。実際には、どうなんでしょう。ここで皆さんが聴き分けられたような音質の差異は、本当にこのシステムによって確認できるものなのでしょうか?
以前こちらでお話ししたように、わたしは人間の聴覚は計測器の出力よりも遥かに敏感であると思っています。これは、そこに書いたように、点検や探知業務などで、測定器の表示ではなく耳で検知している職業の方々と知りあう機会があったときに痛感した話です。今回皆さんが話題にされているような音質の話は、そういう領域の話ではないかという気もします。
結果を知りたいような知りたくないような。結果に賭けられているものが大きいので、やっぱり作者としていまは知るべきではないかもしれませんね。ここではなくわたしの知らない別のところ(?)でそういう検証の議論がされると面白いのですが。
Tikiキーマスターこんばんわ。
一度確認なんですが、青丸のカーソルを合わせる詳細画面で曲を選曲して再生させるとそのアルバムのみの再生で、再生は停止するということでいいんですか?
はい、再生対象はウィンドウ毎に決まります。議論の余地はあるかもしれませんが、現在はそのような動作になっています。
別件については、別のトピックを立てていただければと思います。
TikiキーマスターTaiichiroKさん、コメントありがとうございます。
ご指摘いただいた内容を正確に捉えきれていないかもしれませんが、今回の件は、アルバム単位での再生の設定をオフにした状態で操作されています。そのため、ご指摘の事象とはすこし異なるような気がします。
Tikiキーマスター何度もありがとうございます。そうですか…。
操作された状況はわかってきましたが、残念ながら原因ぽいものはつかめていません。
Library Viewerから再生操作をして、あるアルバムで再生がとまったときに、Playback Queueを見てみると、そのアルバムが最後(または単独)になっていてつづきにあるはずのアルバムはない、というのは共通の状況でしょうか?
たとえば最初に #10118 でご報告いただいた例だと、”RedSwan [進撃の…” がPlayback Queueの最後のアルバムになっていて、そのつづきにあるはずのZARDは入っていない、という感じでしょうか。ここまでご説明いただいた内容からおそらくそうだと思うのですが、念のための確認です。
また再生されるアルバムに再現性 (いつもこのアルバムの前で止まってしまう、とか) はありますか? 上の例だと “RedSwan [進撃の…” とZARDのあいだでいつも止まってしまうのでしょうか?
Tikiキーマスターこんばんわ。
アルバム1枚しか再生されないケースは、最後にアップしていただいたウィンドウから再生した場合でしょうか。
もしそうだとすると、これはBMMNJIMさんが指摘されていたケースで、そのポップアップウィンドウにはひとつのアルバムしかないので、そのひとつのアルバムだけが再生対象になります。
よくよく考えると直感に反した動作になっているのかもしれませんが、そのような仕様となっています。
Tikiキーマスターこんばんわ。
ご利用のWindowsかマイクロソフトストアに問題が生じている可能性もあるのですが、以下のような点を確認してみてください。
- UWP版のTuneBrowserをご利用になっているか
- UWP版でライセンスを購入したときのマイクロソフトアカウントをご利用になっ ているか
- PCがインターネットに接続されているか(ここに書き込まれているということは接続されているとは思いますが)
またこちらのトピックなども参考にしてみてください(あまり参考にならないかもしれませんが…)。
Tikiキーマスターご確認ありがとうございました。
詳細な情報をいただいたにもかかわらず、スクリーンショットからの簡易な印象で申し訳なかったですが、ドライバの事情をうかがうと、たしかに問題がありそうかなと思いました。
Tikiキーマスターご確認ありがとうございました。
serenityさん、フォローありがとうございました。
Tikiキーマスターちなみに、ですが、Player Viewの右下のところのインジケータをクリックしても変えることができます。
BITP / BP:1 / BP:2 などと表示されている部分です。
Windowsアップデートは関係ないと思います。
Tikiキーマスタースクリーンショットありがとうごさいます。
Kazooは当該部分についてメタデータのdc:creatorまたはupnp:artistを出力しているぽいです。正確なところはLINNに問い合わせていただくか、LINNのフォーラムなどを当たる必要がありそうです。
LINNのフォーラムは、こちらのLINNのページから
こちらのフォーラムサイトにリンクされていますので、これがオフィシャル的な(?)扱いのようです。
TuneBrowserはdc:creatorには_GARTISTタグ、upnp:artistにはARTISTタグを渡しています。こうしたUPnPメタデータとタグのマッピングは対応がたくさんあって現在のところ設定には公開していません。
TuneBrowser側から設定でどうこうするのはちょっと難しい感じなのですが、参考になりますでしょうか。よろしくお願いします。
Tikiキーマスターこんにちわ。
serenityさんご指摘のDSD再生の場合のほか、Bit Perfect設定になっていると、ボリュームの制御は効きません。確認してみてください。
Tikiキーマスターこんにちわ。
「二行目」について、できればスクリーンショットで「この部分」と示していただくことはできますでしょうか。模式的なものでも構わないのですが…。
VST3は地道につづけています。
Tikiキーマスターご確認ありがとうございました。
TikiキーマスターChartreuxさん、どうかそのように謝らないでください。Chartreuxさんには、過去幾度も窮地を救っていただき、大変感謝しています。これからも助けていただけると大変うれしく思います。m(__)m
皆さん、ご意見・ご声援ありがとうございます。個別に返答できずすいません。
今回の件以前から申し上げていたように「機能をざくざく追加していく」フェーズはひと段落してペースダウンはあると思うのですが、TuneBrowserはシェアウェアにしたことも含めて「いかに継続するか」を大切なポイントと考えてやっています。そのためには開発環境の更新もつづけていく必要はあるのですが、現在のところTuneBrowserの開発を止める予定はありません。
それはそれとして、TuneBrowserは、オーディオに関する道具のひとつのつもりですから、音質の議論ができないというのも残念な話です。ukatさんが紹介されたようなべつの場所で、というのもあるでしょうが、今回TuneBrowserの内部だけでなく出力したデータを外部で受信して検証する仕掛けを整えましたので、客観的に評価・検証できる範囲での疑義があれば、今後もここでお知らせいただければと思います。
Tikiキーマスターこんばんわ。
Chartreuxさんが最初にご発言された以降の流れは、大変困惑させてしまったことと拝察します。「音変わった?」→「処理ミスってました」→「治りました」となればよかった(?)のですが、結局「再生系の処理は変えていない」し「出力データもバイナリ一致している」ということで、デジタルオカルトの領域に入りました。
じつは以前にも何度か同様のご指摘はいただいていました。それらはいずれも「良くなった」というお話しだったのと、その都度大きめの処理改善があったと記憶しているので、そのご説明をして、出力データは変わっていないことを認識しつつも、それ以上は深く突っ込まずにきました。それは突っ込んだとしても、このトピックでこれまでご説明してきたように、音質操作の所作ではなかったからです。
今回はご報告の内容から問題として取り組んでここまで来たわけですが、正直なところ途中で心が折れそうになったことは事実です。ただ一方で、TuneBrowserを信頼してご利用いただいているユーザーの方々に、わたしがどういう考え・スタンスで開発を行って基本的なTuneBrowserの品質を確保しているか、そしてその結果であるTuneBrowserはバージョンやチャンネルにかかわらずバイナリ一致するデータを出力していることを改めてご説明する機会となりました。
そして最後に、デジタルオカルトの話が残りました。というか、デジタルオカルトの話はやはり存在しているのかも、と多くの方々に印象づける結果となったのではないかと思います。できればそれを、趣味の一環として楽しんでいただけるようになれば良いのですが。
Tikiキーマスターわかりました。ご確認ありがとうございました。
TikiキーマスターBMMNJIMさん、フォローありがとうございます。
たしかにご指摘の操作だとそのViewには1アルバムしか表示されていないので、1アルバムだけの再生になりますね。
それと、ヘッダー表示は、それ独自のViewの設定はなく、トラック一覧表示のトラックを表示しないという状態です。ですので、トラック一覧表示のアルバム共通部分とおなじ表示、挙動になります。トラック表示のない表示形態ととらえると、たしかにご指摘のようにほかとちょっとちがうということになりますね。
Tikiキーマスターこんばんわ。
「再生すると再生しているアルバムのみの表示になってしまいます」のときの「再生する」操作は、Library Viewerのどこか途中のアルバムを選択して再生する、ということですよね?
おそらく設定の問題ではないと思います。なにか別の問題が起きていると思うのですが、まずはわたしのところで再現させるために、そこに至る操作を細かく確認させていただきたいです。
Tikiキーマスターこんにちわ。
対応に時間がかかっていてすいません。現在のところ再現ができていないのですが、その過程でタブの配置換えの問題を見つけました。この問題がご指摘の事象につながっているかどうか、微妙なのですが、次のリリースで改善します。
このタブの配置換えは、ベースとなるマイクロソフトのフレームワークとの兼ね合いでむかしから問題児で、今回の調査で長いあいだ潜伏していた不具合が見つかった格好です。これで改善していると良いのですが…。
Tikiキーマスターこんばんわ。
“Prev Track”というのは、ひとつ前のトラックという意味ですので、ひとつ前のトラックを再生することになります。その曲の先頭からもう一度再生したい場合は、現在のTuneBrowserでは停止-再生と操作します。
(以前は再生中に再生ボタンを押すとその曲の冒頭から再生する動作をしていたのですが、理由は忘れましたがご指摘があって現在の動作になっています)
Tikiキーマスターこんばんわ。
検証とご報告、ご意見、どうもありがとうございました。
コンパイラによって音が変わっているというご報告は、藤本健氏の言われているようなデジタルオーディオのオカルトネタがひとつ (やっかいなところで) 増えたという感じですね。念のために申し上げておくと、同氏は「オカルト」という言葉を使われていますが、決して否定的なものではなく、前回ご紹介した記事にもあるように、それをオーディオのネタのひとつとして楽しもうというスタンスに立たれていると理解しています。わたしも同感です。
同氏の記事のタイミングと同様に、まるで今回の議論に合わせたかのように、日本マイクロソフトのJapan Developer Support Core Teamから1月21日に以下のブログ記事が公開されていることに気がつきました。
この記事では、TuneBrowserが全面的に使用しているC++という言語については、同一のソースコード、同一のコンパイラを適用した場合、動作や機能は同一だとしても生成されるバイナリは同一とは保証されない、バイナリ内部のタイムスタンプや乱数的要素だけでなく、そもそも「決定論的ビルド」がサポートされていないと説明されています。
最近のC++コンパイラは、CPUのSIMD拡張と合わせて極めて高度な最適化を行いますので、決定論的ビルドが困難であることは理解できます。そして現在のTuneBrowserのソースコードは、コンパイラの進化に合わせてその最適化をできるだけ引き出せるように考慮した構造になっており、とくに性能に機微な部位はソースコードの変更のたびに生成されたアセンブラコードを確認するようにしています。
その経験から「ビルドのたびにバイナリコードが変わっている」という事象を目にしたことはほとんどなく (じつは数年前の数か月間その現象に悩まされた経験はあるのですがいまは解決しています)、生成されたバイナリコードはそれほど変動するものではないと思うのですが、わたしがアセンブラで確認できるのは本当にコアな処理の一部であり、その物量からとても全体を確認することはできません。つまり、ビルドのたびにバイナリコードが変動するリスクが発生します。
どうすべきでしょうか。ビルドしてリリースするたびに、「今回は音がいい」「残念、今回はもうひとつ」と一喜一憂していただけばいいのでしょうか (皆さんがそうではないと言われていることは重々承知しています。これは単に自問自答です)。
ASIOドライバが受けとったデータも含めた今回の検証で、こうした結果は、わたしの意思・技術力・開発行為とは別のところで発生していて、ケーブルの材料のように開発者の意思で選択できるようなものではないということはご理解いただけたのではないかと思います。そのような言い方をすると何となく責任逃れのような感じがして自分でも気持ちの良いものではありませんが…。
いっぽうで、今回の議論で、わたしの開発したソフトウェアがこのように高度な (=趣味性の高い) 領域での音質の議論ができる再生能力を持つに至ったことに、(へんかもしれませんが) 感慨も感じています。10年以上、良くなろうと念じながら自分の全力を投じて開発をつづけてきたわけですが、それは地道にデータの精度と処理に気を遣って改善する活動であって、決して「ここをこうして高域の質を上げてやろう」とか「低域を膨らまそう」とか、そういう音質選択的活動ではありませんでした。にもかかわらず、今回の議論ができるということは、ある意味その地道な開発の結果のひとつの現れなのかなあとも感じています。
コンパイラのバージョンは、上のマイクロソフトの説明から決定論的ビルドが保証されない以上、あまり強くこだわっても仕方がないのかとも思います。当面は4.17.4で使用したコンパイラを使用しますが、その結果として趨勢の進化から取り残されるようになるのも本意ではないので、必要があればバージョンは変更すると思います。
Tikiキーマスターこんにちわ。
ご所望のような再生ができるようにするために、CUESHEETというテキストファイルがあるのだと思います。TuneBrowserはCUESHEETに対応しています。CUESHEETの作成は凝った記載をしなければ、手作業で作成できる簡単なものです。このファイルについてはインターネット上にたくさん情報がありますのでここでは解説はしませんが、試してみてください。
CHESHEETのファイルの拡張子は .cue にしてください。
Tikiキーマスター回を重ねることは気になさらないでください。わたしの確認の仕方もよくないのだと思います。
うーん、そうですか。とくに変わった点はないのに、複数アルバムがPlayback Queueに入る場合と、選択した一つのアルバムだけがPlayback Queueに入る場合があるということですか。
すいませんが過去に例のない現象で、わたしのところでは再現もできません。しばらく、他の方々のところでも同様の事象が起きていないか、ご発言を待ってみましょうか。
Tikiキーマスターありがとうございます。お手数をおかけしました。
最後の「次のアルバムを再生されないPlayback Queue」のスクリーンショットにはひとつしかアルバムがなく、再生を期待されている「次のアルバム」が入っていないので、再生されないのだと思います。
このときの操作をもうすこし詳しく教えていただけないでしょうか。
Tikiキーマスターご期待に沿えず恐縮です。おそらく音を出すところまでであれば大きな問題はないとしても、TuneBrowserで扱うにはメタデータ(タグデータ)の取扱いが課題になりそうと感じました。
CUESHEETもある種のコンテナと言えると思いますが、その解釈の揺らぎには本当に苦労しました。おそらく、Matroskaでも、メタデータの部分についてはその定義をみるかぎり、同様の課題が出るものと思われます。
Tikiキーマスターご意見・ご感想、ありがとうございます。
ちょうど今日、インプレスのAV Watchにおいて藤本健氏の「「オカルト話をぶった斬る」から20年。デジタルオーディオは厄介で面白い!」が掲載されましたね。まるでこのトピックでの議論に合わせたかのような話題ですこし驚きました。CD-Rが活躍していたころのCDとCD-Rの音質のちがいや、デジタル系ケーブルの音質のちがいの話題を振り返られています。
hi-resさんにおっしゃっていただいた、ソフトウェアの果たすべき責任はビットパーフェクトの出力を行うところまでではないか、というのは、たしかにその通りと思います。
それ以外に、わたしがとくに気にしているのは、上にも書いたように処理の負荷ですが (AVX2版を出したのもそれが動機です)、これにしても、絶対的にその方向が正しいという話はありません。
- 処理の負荷を気にしている、なんて、Active Backgroundのような無駄の極致みたいな機能をつけておいてよく言う、と思う方もおられるかもしれませんが、そこはこれまでにもお話ししているように、音楽の楽しみとのトレードオフです(^^;。不要なら機能をオフにすることができます。Active Backgroundをオフにして、デスクトップ表示もやめて、ネットワーク関連の機能も切って、TuneBrowserを最小化すれば、ほぼよけいな機能は動作しなくなります。ついでながら、TuneBrowserは自身が最小化されたことを検知すると、より抑えた動作に切り替わるようにしています。
こちらのトピックで、PCとDAC機器で接続されているグランドラインの影響の話を紹介しました。わたしにはそれが正しいと断じるほどの知識はありませんが、なにをやっても音は変わるという世界ですから、影響はあるかもしれないとも思います (わたしの使用しているUSB DACにはガルバニック・アイソレーションが搭載されていて、そういうこともDACの性能のひとつとして気になります)。
むずかしいのは、たとえばケーブルの世界であれば、金メッキなら、ロジウムメッキなら、あるいは銀線なら、といった観点である程度傾向が認知され嗜好を反映することもできつつありますが、ソフトウェアの世界ではそういったわかりやすい方法論は見出せそうにないということです。さらにやっかいなのは、(ときどき思うのですが) 処理負荷を下げたほうが良さそうに思えるこの話も、逆に上げたほうが良くなると感じる可能性も否定できないことです。これは、べつのトピックで触れた例のように、リサンプル処理でサンプルレートを上げたほうが良いのかどうか、という話に似ています。あるいは、これは極論なのかもしれませんが、ディザの概念のように、多少の高周波ノイズが入っていたほうが、聴きやすい音と感じる方もおられるかもしれません。
「データを正確に取り扱う」という以外には絶対に正しいと言える方法論がない状況で、結局は、皆さんにおっしゃっていただいたように、わたしはわたしの思う方向に開発を進めていくしかないなと思います。
Tikiキーマスターわかりました。アルファベット順でなければ、というわけではなさそうですね。ありがとうございます。
Tikiキーマスターこんにちわ。
バイナリ比較の結果については、ご指摘の通り、わたしもあまり心配していませんでした。ただ、たまたまバージョン間で広範に修正した経緯があったので、明確に説明できる必要があるなと思い、今回の検証環境を用意しました。
出力バイナリデータに差異がない状態での音質の変化は、ひとつ前のコメントや以前のコメントにも書いたように、否定するものではありません。その要素のひとつとして、わたしが思いつく範囲ではコンパイラのちがいというものがあるかも、と思い、今回4.17.4を用意しました。
4.17.4でもやはり4.17.0とは異なっているというご試聴の結果は、残念なような安心したような微妙なところです(^^;。残念な点は、音質の変化の要素がまたわからなくなったということです。安心した点は、古いコンパイラバージョンに縛られる必要がなくなり、これまで通り趨勢の変化に追従して進化していけるということです。
ただ、「あまり時間が取れていないのですが」と書かれていました。もしよろしければ、まだしばらくこの先行版の状態にしておきますので、どこかで改めて比較してみていただけないでしょうか。おそらく集中できる環境と気力(?)が必要で簡単なことではないと拝察しますので気軽にはお願いしづらいのですが、急ぎませんのでできましたらお願いします。
音質については、折に触れわたし個人としては「ある一定以上のレベルであれば、良いか悪いかではなく、好きか嫌いかだ」と思う旨、書いてきました。わたしの古いスピーカーB&W 802Dはツィータが特徴的で、登場当時には賛否両論がありました。実際にB&Wの取説には「そのうち耳のほうが慣れてくるから」と書かれています。あるいはデジタル音源とLPの音、半導体アンプと真空管アンプの音、A級アンプとAB級アンプの音、いずれもどちらの音質が良いか悪いかという話ではないと思っています。
また音質を左右する要素の話として代表的なのは、ケーブルによる音質差異があります。とくにデジタル系ケーブルや電源ケーブルなどについては最近では多くの方が音質の差はあると認知しつつも、差がある技術的な理由については、明確な共通認識には至っていないと理解しています。
それらを踏まえたうえで、TuneBrowserの音質差については、以前「TuneBrowserは高域を操作している」というデマ情報については明確に否定しましたが、逆に、出力データのバイナリレベルでの一致を確保した上でそういう自分の思う音質の操作ができたらどれだけ素敵だろうと思います(^^;。残念ながらそれはできませんので、このまま今回も理由が明確にならないとしたら、これまで通り、TuneBrowserのなかを通過していく大量のデータの精度に最大限の注意を払いながら、負荷変動を極力抑えるように開発を進めていくということになりそうです。
Tikiキーマスターなるほど、プロテクトがかかっていないのですね。以前、古いブログで同様の例を (メディアはDVDでしたが) 紹介したことがあります。このような場合、そこにも書いたようにPCMデータを直接コピーできるとか、そういうものではないのでしょうか?
Matroskaコンテナをサポートするには、それなりに長い道程になりそうです (正直なところ気が遠くなります(^^;)。他の方々からも同様のご要望があるか、しばらく待ってみましょう。
いわゆるハイレゾ音源については、PC向けと専用ハードウェアによるプレーヤー向けで、所有形態としては道が分かれてきたように思います。PC向けの音源はつまりダウンロード形式などですね。日本国内では統制が厳格であるが故に品ぞろえ (あるいは音源を探し出す手段) に限りがあり、いま一歩物理メディアの代替になり切れないのが残念でなりませんが、いまから物理メディア向けの機能を追加してくことについては、慎重になるざるを得ない点はご理解いただければと思います。
Tikiキーマスターブルーレイ・オーディオは、合法的にリッピングできるようになったのでしょうか。
ハイレゾ音源のメディアとしては個人的にはかなり微妙な立ち位置だと思っていましたので、もし趣旨替えしたのだとしたら、それはそれでよいことだと思いますが…。
Tikiキーマスターこんばんわ。
最初のコメントに戻るのですが、再生操作を行ったあとの、Playback Queueの内容を確認していただきたいです。
Tikiキーマスターこれは、壊れたMP3ファイルですね。ひょっとしたら拡張子がMP3というだけで、中身はMP3ではないのかもしれません。
どれくらいの大きさのファイルかはわかりませんが、Valid frame: 0 となっているので、MPEGとして有効なフレームはひとつもなかったという状態です。
Tikiキーマスターそうなんです。私もカーソルキーでできるかと思いましたが,下にいってしまうのです…。
あー、ですよね…。ちょっと考えてみます。
Tikiキーマスタースクリーンショットありがとうございます。
これは、A,B,Cの3つのアルバムのあるタブに対して全再生を行ったときのPlayback Queueでしょうか? ひとつもトラックが入っていないように見えるのですが、この状態で「A→Bは再生が続く」「B→CはBの再生が終わるとCの再生が続かない」とはならないような気がするのですが…。
Tikiキーマスターこんにちわ。
A)について、そんなことを言っていましたっけ? もしよろしければそのトピックへのリンクを示していただけると有難いです。
もしそれに類した発言をしているとしたら、記憶にあるのはこちらの発言ですね。ここで言いたかったことは、カジュアルに音楽を聴きたいときに、全体のゲインを下げておくと、ReplayGainの効き幅に余裕ができるので、よりReplayGainの効果が得やすく、聴きやすいということです。いまでも、わたしはふだんはそのようにしています。またWalkmanやカーオーディオ用などポータブル機器向けの音源を作るときにも、そのようにしています。
B)については、-10dBは懸念があるとかそのような理由はありません。以前使っていたJeff RowlandのSynergyというプリアンプには各入力ごとにゲイン設定があり、大変便利だったので、TuneBrowserにもそれに類した機能をつけました。そのときに何となくSynergyが-10dBまでだったような記憶があってそのようにしています。
ちなみに、いま改めてSynergyのマニュアルを確認してみると、最小値は-20dBでした(^^;。だからというわけではありませんが、もしニーズがあるようでしたら-20dBなど設定範囲を広げることは可能です。ただ基本的には出力機器のゲイン差を吸収する目的のものですので、そんなに幅の大きな値を設定することはあまり考えていませんでした。
Tikiキーマスターこんにちわ。
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間で意図しない改修が入りデータに差が発生しているという可能性はないと考えています。
このことは、音質に差があるように聴こえる経験を否定するものではありません。みなさんのご検討の一助となればと思い、ご報告します。
Tikiキーマスターご確認ありがとうございます。
タグ名を並べて書くときに、アルファベット順に指定しないと認識されなかったということでしょうか?
Tikiキーマスターこんばんわ。
“; “を値の区切りと認識するタグは、事前に登録しておく必要があります (タグによっては支障があるかもしれないので)。
設定ダイアログボックスのツリー項目「タグの設定」、右側の項目「タグの設定」「複数文字列を格納するタグ」(いちばん上です)に指定します。既定の設定でたくさん並んでいるので、ちょっと操作しにくいですが…。
Tikiキーマスターこんばんわ。TuneBrowserのご利用ありがとうございます。
実際には問題ないのかもしれませんが、選択すると内部の状態が変わってしまうので、フォーカスをあてるだけにしています。Playback Queueの再生中の曲を示す場合も、同様にフォーカスだけの処理です。
ただ操作してみて、トラックにフォーカスのある状態でカーソルキーを動かすと、そのトラックが選択されてもいいような気がしますが、実際には下カーソルキーの場合その次の行が選択されてしまいますね。これは見直してもいいかもしれません (エクスプローラーなどとは動作が変わってしまいますが…)。
Tikiキーマスターこんばんわ。
動画まで撮っていただきお手数をおかけします。なかなか反応できずすいません。また改めてご連絡させていただきます。よろしくお願いします。
Tikiキーマスターこんばんわ。
仔細の情報、ありがとうございます。一次的には、ウィンドウが真っ黒になっていることから、ディスプレイドライバとそのDirectXのなかで落ちているような感じです
取り急ぎ、簡単なコメントで失礼します。
Tikiキーマスターこんばんわ。
だいたいご認識で合っています。
2)のところで、ゲインの値によっては32bit浮動小数点に変換されます。
Tikiキーマスターあまりに驚いてすこし断定的な書き方をしてしまいましたが、左右のバランスが偏って聴こえるという経験そのものを否定するつもりはありません。TuneBrowserの左右のバランスがおかしいというご指摘は解せないと言いたかっただけです。わたしも以前、自分のオーディオ機器でそのような事象に悩んだことがあります。部屋の問題か、アンプやケーブル・コネクタの問題か、あるいは自分の耳の問題か…。気になりだすと気になって、どうも偏って聴こえるような気がしたものです。
ちなみに、それを確認するために、TuneBrowserには再生中にモノラルに切り替えたり、左右のチャンネルを入れ替える機能があります。数か月のあいだ折に触れ悩んだ結論としては、「どうも気のせいだ」ということでした。みなさんも気のせいですよ、などというつもりはまったくありませんし、ここで発言されているような方々は一定の見識を持たれていると思うのですが、意識の下に密かにあるような先入観を排除するのは意外とむずかしいものだということは、共通の理解としておきたいところです。
Tikiキーマスターこんばんわ。
バージョンによって左右の音量差があるという話は、どうも解せません。今回のバージョンによる音質差は、上に書いたように、
- 意図しないソースコードの変更が行われている可能性
- コンパイラのバージョンちがいによる生成されるバイナリコードの差異
の2点を考えています。しかしこれらは、再生処理全体に影響を及ぼすことはあったとしても、左チャンネルだけ、右チャンネルだけ、という作用をするものではないと思います。TuneBrowser内ではモノラル・ステレオ・マルチチャンネルの3系統の再生処理があり、ステレオは2チャンネル専用の処理ですが、完全な対称性を持っており、左チャンネルだけ、右チャンネルだけといった特別な処理はありません。
Tikiキーマスターありがとうございます。了解しました。
大変な無理を申し上げることになるのだと思いますので恐縮なのですが、4.17.0と4.17.3の間、つまり4.17.1と4.17.2も含めてみたときに、どのあたりで変化が発生したのか、できれば情報をいただけると助かります。
(発生している変化が顕著なようですので、だんだんと変化したということはなくて、どこかのバージョンで変化したのだと思っています。そうではなく、やはりだんだんと変化したということであれば、その旨お知らせください)
Tikiキーマスター前のコメントの「再生中の動作に作用するようなものはありません」は「再生中の動作に作用するようなものはなさそうです」が正しい表現です。その点もあわせて見直します。
Tikiキーマスターこんばんわ。
TuneBrowserはタグの値を変更した際には、FLACファイルなど音源ファイルのタグを書き換えていますよ。
Tikiキーマスターこんばんわ。
4.17.0と4.17.3のあいだの再生に関する処理の変更は、機能面ではChange Logに出ているように、設定値の範囲の変更やデバイスの初期化の考え方の変更といったもので、再生中の動作に作用するようなものはありません。
機能の変更にかかわらない変更は多数行っています。たとえば内部の処理の最適化や、関数名・変数名の見直しなどです。それらの過程で、意図せず結果が変わるような変更を行っている可能性は否定しきれません。
また、11月から12月にかけて、使用しているコンパイラ (テキストで書かれたソースコードを、実行できるバイナリコードに変換する道具) の標準動作が変わり、その対応を広範囲に行っています。
4.17.0のリリースは9月、4.17.3のリリースはこの1月頭で、4カ月の期間があり、その間での変更を洗い出すにはかなりの時間がかかりそうです。
ちなみに、使用している音源のコーデック (FLAC, Wave, MP3など) は何でしょうか? 絞り込むヒントにできればと思います。
よろしくお願いします。
Tikiキーマスター返信ありがとうございます。
残念ながらもうひとつ状況がよくわかりませんでした..。Playback Queueの内容は確認されましたか?
Tikiキーマスターこんにちわ。
念のために確認をしてみたところ、機能としては期待通りに動作しているようです。
再生操作を行ったときに、対象の楽曲群がPlayback Queueに入ります。そこには他のアルバムも投入されているのでしょうか?
また「アルバムによっては」と書かれていますが、特定のアルバムだけでそういった現象が起きるのでしょうか?
Tikiキーマスターわかりました。解決してよかったです。
Tikiキーマスターこんにちわ。
ご提示いただいた情報だとどのようなデバイスを使われているかなどがまったくわかりませんので、Player Viewのスクリーンショットを添付していただけないでしょうか。あるいはログの全文をテキストファイルに落としていただいて添付していただいてもかまいません。
Tikiキーマスターこんばんわ、ログのアップありがどうございました。
おかげさまで、思いがけない形でしたが状況がわかりました。
「正常」としてお送りいただいたケースでも、やはりサンプルレートの設定に失敗していました。ZoomのUDAC-2は、写真で見るかぎり機器のパネル面でのサンプルレートの確認ができないようですが、TuneBrowserのPlayer Viewでの表示では、曲のサンプルレートが96kHz、機器のサンプルレートが48kHzと表示されていると思います。この48kHzは、おそらく機器のデフォルトのサンプルレートで、残念ながらこのサンプルレートで再生されているものと思われます。
1559で「再生デバイスの問題で再生できない場合のメッセージを明確化」したときに、機器側がそのサンプルレートで再生できると言っているにもかかわらず、実際に設定できなかったときにはエラーにするようにしました。1558までは、ここを曖昧に「そのサンプルレートに対応していないだけ」と扱っていました (そのため、結果としては意図しないサンプルレートで再生されることになっていました)。
どうするか、ですが、わたしとしてはDAC側の動作がおかしいと思うのですが、なにか救済する考え方ができないか、もうすこし検討してみます。
Tikiキーマスターこんばんわ。ありがとうございます。
例によってなかなかヒットさせることができなかったのですが、わたしの検証用の環境だと下側をクリックすると、同様の事象を起こすことができました。これは、検証用にへんなフォントを指定しているので、アラインメントがすこしズレているのかもしれません。
とにかく再現はさせることができて、やはり先日の対処で大丈夫なようです。次のリリースはまだ未定なのですが、ありがとうございました。
Tikiキーマスターこんばんわ。ご確認ありがとうございました。
ご報告いただいた内容だと、明らかにTuneBrowserの1558と1559のバージョン違いが要因で、再生できる/できないが変わっているように思えますね。
その後TuneBrowser内の変化を確認しているのですが、1559で改修した「マイクロソフトストアの指摘に基き、再生デバイスの問題で再生できない場合のメッセージを明確化」した作業で、たしかにこの近辺の処理を変更しています (再生できない理由をもうすこし細かく分類してメッセージに表示するようにしました)。
ただ、デバイスに対するASIO APIの呼び出しの順番やタイミングは変わっていないんですよね…。他の方からの同様の事象のご報告もなさそうですし、かなり不思議です..。
Zoom社のホームページからUDAC-2のWindows用のドライバをダウンロードして内容を見させていただくと、ZIPファイル内の更新履歴に、Ver1.2.0で「Windows10でサンプリング周波数を変更できない」問題が修正されたとの記載がありました。この更新は2016年4月になっており、可能性は低いとは思うのですが、念のためご利用のASIOドライバのバージョンをご確認いただけないでしょうか。
あと、これはもし可能であれば、なのですが、1558で正常に動作している状態のログもアップしていただけると助かります。TuneBrowser上部のメニューから「表示」「ドッキングウィンドウ」「Log View」と選択すると、TuneBrowserの下部にLog Viewが表示されます。Log Viewの下にはいくつかタブがありますので、「Player」を選択してください。この状態で再生を行うとログが更新されます。この内容はマウスの右クリックメニューからすべて選択、コピーなどができますので、前回同様にテキストファイルに貼り付けることができます。
お手数をおかけしますが、よろしくお願いします。
Tikiキーマスターすいません、ボリュームバーのご指摘がうまく掴めませんでした。
再生していない状態で、BP1か2にして、通常はスライダーのサムボタンは操作できないですが、それが上側ぎりぎりをマウスで操作すると、操作できるようになった(図例では-30.20dBになった)ということでしょうか?
そうだとして、これもどうもうまく再現できません。操作があっているか、ご確認いただけないでしょうか。
Tikiキーマスタートピックのタイトルについて、あのコントロールは「スライダー」または「トラックバー」と呼ぶのが一般的なようですので、そのように変更させていただきます。
Tikiキーマスターご確認ありがとうございました。引き続き、確認してみます。
Tikiキーマスターこんばんわ。ログのアップありがとうございました。
内容を確認したところ、前回書いたようなASIO制御用の子プロセスの問題は発生しておらず、その点では正常でした。
実際に起きているエラーですが、ASIOドライバに対してサンプルレートを設定するときに、以下のようなエラーが返ってきていました。
- Hardware input or output is not present or available.
このエラーは、通常、機器の電源が入っていないか、あるいはPCに接続されていないときに発生します。もちろん、そのような点はすでにご確認いただいているとは思いますが、わたしのところでも、ごくまれに、ASIOドライバと機器の間の状態がおかしくなることがあります。
念のため、以下を確認していただけないでしょうか。どれが有効かは、ASIOドライバの状態によりますので、残念ながら一概には言えません。
- PCの再起動
- 機器の電源の切 – 入
- PCと機器の接続(USB)の切断 – 接続
TuneBrowserのほうは、1558と1559の間で、再生に関する処理はほとんど触っていません。が、まったく触っていないわけでもないので、その点は引き続き確認します。またあいだでTuneBrowserを生成しているコンパイラのバージョンも変わっていますので、その影響がないとも言い切れません。
ただわたしのところでは引き続きASIOは問題なく再生できています。他の方で、4.17.3以降でASIO再生に問題が出ている方はおられるでしょうか? > ALL
Tikiキーマスターこんばんわ。
「上側ギリギリ」とのヒントをいただいて、さらに何度か試してみたところ、何回か再現させることができました。ありがとうございます。
けっこうシビアな操作で(^^;、安定的に再現させることができていないのですが、次のリリース時に対策を入れたいと思います。
ご指摘いただかなければ気がつかなかったと思います。改めましてありがとうございます。
Tikiキーマスターこんばんわ。
ご報告ありがとうございます。内容から、おそらくスライダーがマウストラッキング中だという判定が解除されないままになっているのだろうと想像できるのですが、わたしのところでは現象を再現させることができませんでした。
なにかマウス操作を扱うようなアプリを入れておられたりしないでしょうか?
Tikiキーマスターこんばんわ。
エラーが表示されたときに、その右側に「追加情報」というボタンがあったのではないかと思います。そのボタンを押して表示される内容を添付としてつけていただけないでしょうか?
おそらく、ですが、1559はリリースして間もないために、TuneBrowserが内部で起動するASIO制御用の子プロセスがセキュリティソフトによってブロックされたか、あるいは子プロセスのファイルそのものが削除されたのではないかと思います。
その場合、再インストール (アンインストールは必要ありません) していただいて、もうしばらく時間がたってから試していただくと、成功するのではないかと思います。「もうしばらく」というのはセキュリティソフト次第なのですが…。
Tikiキーマスターご報告ありがとうございます。
すこし確認をしてみたのですが、再現させることはできませんでした。
「新規のプレイリストを作成」という操作は、タブの部分の右クリックでのメニューから「プレイリストの新規作成」を行われたのでしょうか? また未保存のプレイリストはいくつありましたか? (ひとつだけでしょうか?)
Tikiキーマスター以前Lyrics Viewを用意したときに、このViewは歌詞専用ではなく、あるひとつのトラックのタグ情報を表示するという汎用性を意識して作りました。これを応用してLyrics Viewのように独立したウィンドウとしてコメントが表示できればいいような感じでしょうか?
設定系の検討などがあるので、すぐに対応できるということではないのですが、そういうやり方もありかなとも思いました。
Tikiキーマスターまた登録曲数の重複ですがフォルダツリーのみならず新着順でも出ました。
やっぱり、そうですよね。ご報告いただいていた事象から、フォルダーツリーのみということはないのだろうと思っていました。
目に見えない子フォルダがあるということはありませんので、何らかの理由でfidataが重複して受信しているのだろうと思いますが、前のコメントで書かれていたように、まずはLAN環境の確認をされたほうが良いと思います。
また、もうしばらくこのトピックはオープンにしておいて、他にも同様の事象が発生している方がおられるかどうか、待ってみましょうか。わかりやすいように、タイトルも変更させていただきます。
Tikiキーマスターserenityさん、Chartreuxさん、フォローありがとうございます。
tatsuさん、解決してよかったです。
Chartreuxさんご指摘のハイフンが別の文字に変わってしまう件ですが、たしかにそうですね。ハイフンが単品であると、Unicodeの文字に変わってしまうようです。Sandboxのほうで試してみたところ、CODE修飾して書くと、ハイフンのままで維持されるようです。なんか、他人事のような言いかたになっていて恐縮ですが、利用しているフォーラムのシステムの仕様ということで、ご了承ください。
Tikiキーマスター設定ダイアログボックスのツリー項目「基本の設定」「ネットワークの設定」のページに、「OpenHomeの設定」「メディアサーバーの設定」があります。
デフォルトでこの項目は閉じられています。ここを開くと「トラックの最大数」という項目があります。
TikiキーマスターHDCDデコード前の音、という聴感上の固有の音質というものがあるのですね…。恥ずかしながら気がついていませんでした。他のCDとおなじ取り込み方をされているのであれば大丈夫だと思うのですが、取り込み時にアップサンプリングやゲイン調整など、元のPCM波形を変形させてしまうような処理を行うと、波形中に埋め込まれたHDCDのマークは消えてしまいます。すいませんが、現在のところそのくらいしか確認点を思いつきません。
Tikiキーマスターこんにちわ。
fidataが763曲の受信に関する注意事項を表示したあと、2253曲を処理したと結果が出るのですね。そうすると、かならずしもきっちり3倍というわけではなくて、結果的に3倍ちかい値になったということですね。(20曲が40曲になった、というご報告もありました)
UPnPの通信にはUDPという送達が保証されない (そのかわり高速に扱える) プロトコルを使用しますので、ひょっとしたらLAN環境によって問題が発生するかもしれません。ただフォルダーツリーだけ問題が発生するというのはどうも考えづらいのですが… 現在のところわたしの環境では再現させることができず、他の方からの同様のご報告もないので、現在のところはLAN環境をご確認いただくことくらいしか、思いつきません…。
TikiキーマスターTuneBrowserのご利用ありがとうございます。
おそらくrefalac64.exeの引数の指定方法の問題だと思います。どなたかrefalac64.exeのご利用方法についてご存知の方はおられないでしょうか? > ALL
それと、tatsuさんには、変換の設定でどのように指定されたか、設定画面のスクリーンショットを挙げられたほうが、議論が進むのではないかと思います。
Tikiキーマスターもうひとつ、気のついた点があります。
これはfidataにかぎらず、TuneBrowser単体でもそうなのですが、Tree Viewでフォルダーツリー上のあるフォルダを選択した場合、そのフォルダだけでなく、子フォルダも含めたすべてのファイルを対象にします。その動作が現れているということはないでしょうか。最初のコメントで「同じものが3回登録されます」と書かれているので、そうではないとは思うのですが、念のための確認です。
また763 x 3 = 2289で、2253とは微妙にちがいますが、そのあたりでなにかお気づきのことはないですか。
Tikiキーマスター追加の情報ありがとうございます。
やはりわたしのところでは再現できませんでした。
fidataはたくさんの曲をプレイリストに追加すると、「xxx曲 追加しました」というメッセージを出すようです。
また1000曲以上をプレイリストに追加しようとすると、「処理を中止します」というメッセージを出すようです。
そのあたりの曲数とか、動作は763曲とか2253曲と言われているケースの場合、合っているのでしょうか?
Tikiキーマスターこんばんわ。
「transparent という表現」は、日ごろ開発時に内部の処理のあり方として心掛けている考え方に合致していて、すこし嬉しく思いました、またVST3プラグインをご紹介いただき、ありがとうございます。検証時の一候補とさせていただこうと思います。
Tikiキーマスターこんばんわ。
すいませんが、言われている操作がよくわかりませんでした。11曲が含まれたアルバムをfidata上で長押しして「一括プレイリスト登録」した場合、新着順からでも、フォルダーツリーからでも、11曲が登録されました。
TikiキーマスターFukiage701さん、ご説明ありがとうございます。またご要望についてのご配慮も感謝します。ときによりイコライジングを変えて再生されているという聴き方は考えもしていませんでしたので、勉強になりました。
VSTプラグインについては「消極的ながらも検討」とはまあまあ適切な表現ですが(^^;、この年末年始も (帰省などのイベントもなかったので) 相応の時間をかけて検討しています。先人の方々の情報を参考にしながら進めてはいるものの、わたしにとってはVST3 SDKはまったく新しい情報の坩堝で、なにかあったときに、TuneBrowserの問題か、SDKの問題か、プラグインの問題か、といった切り分けにも苦慮する状況で、果たしてこれを多くの人に使っていただけるような品質に持っていけるのか、我ながら心配です。
Tikiキーマスターこんばんわ。
HDCDは、PreEmphasisとは異なり、トラックの波形自身から判定することができます。逆にトラックの波形から判別できない場合は、HDCDとしてデコードもできないということになりますので、タグの値によって動作を変えるという機能はありません。
Tikiキーマスターこんばんわ。
参照されているファイルのタイムスタンプ (ファイルサイズなども) は、データベースには入っていません。必要なときにファイルにアクセスして取得するという手もないではないですが、使われ方や環境によっては非常に遅くなるので、基本的にTuneBrowserではそういう動作はしないようにしています。
ちなみに、差支えなければ、ですが、どのような用途でご利用を考えておられるのでしょうか?
Tikiキーマスター明けましておめでとうございます。
hiroさん、フォローありがとうございます。
manupassero san, thank you for using TuneBrowser. I wish you enjoy TuneBrowser.
TikiキーマスターChartreuxさん、熟達してますね…。いまさらですが改めて感銘しました。とくに連番のテキストファイルを用意しておいてTuneBrowserのタグ編集用のダイアログボックス (リストコントロール) に貼りつけるあたり、鮮やかです。(^o^)
TikiキーマスターChartreuxさん、ありがとうございます。
まったくの私事で恐縮ですが、今年は本業のほうの状況が大きく変わりました (ついでながら来年度もさらに変わりそうで、いまは少々心落ち着かない日々です)。そのような状況でも、このフォーラムの運営や開発とリリースをつづけてこれたのも、皆さんの支えがあったおかげです。本当に感謝しております。
来年以降も活動を止める予定はありませんので、どうぞよろしくお願いします。
Tikiキーマスターserenityさんが書かれている方法は、ファイルのトラック番号を直接書き換えるやり方です。
SUEZOさんがもし表示上だけの番号を言われているのであれば、残念ながら行番号のようなものを表示することはできません。ご存知と思いますが、TuneBrowserはプレイリストの表示の場合、ディスク番号やトラック番号に関係なく、プレイリストに記載された順で表示します。そのためあまり行番号的なものを表示させる意味はなさそうに思いますが…。
TikiキーマスターChartreuxさん、いつもありがとうございます。
kantyさん、ご確認ありがとうございました。
2020-12-27 09:19 返信先: Playback control caused timeout/cannot decode file – permanent with Tidal BubbleUPNP #9866TikiキーマスターIt’s nice. Thank you for your testing to get a goal.
I’m sorry but Desktop and UWP licenses are separated. UWP version will be published within almost two weeks. Please wait a while (Fully functions of the Desktop version are available during one month).
You can increase reading buffer of the TuneBrowser. In prefernces dialogbox, tree item “Playback settings” – “Decoding”, property “File acessing (accessing)” – “Memory cache size (KB)” is 256 (KB) now. Increase value.
Thanks.
2020-12-26 21:22 返信先: Playback control caused timeout/cannot decode file – permanent with Tidal BubbleUPNP #9856TikiキーマスターHi,
I have updated preliminary release. This version is reduced HTTP access. Can you try this ?
Tikiキーマスター1から連番は、ときどきわたし自身もあるといいなと思った記憶があるので、検討してみます。
TikiキーマスターTBLoverさん、素早い情報ありがとうございます。
示していただいたリンクの部分はきちんと認識できていませんでした。INDEX 00の存在がキーになるのかなと思いましたが、”Note that INDEX 00 of TRACK 02 is set while still referencing the first FILE.” とあるので、INDEX 01の立ち位置で判定する形にすればよいということでしょうか (そうは書いていませんが….)。
Noncompliantとわざわざ書かれている形式を「正常な形式」として扱うべきかどうか、ちょっと微妙な印象です。示していただいた章は、EACが出力している独自形式を解説しているだけで、これに追従しているアプリケーションもある、という情報のようにも思いました。X Lossless Decoderもそのひとつで、だから不具合ではないというのは、その通りだと思います。
厳密にトラックを管理せず、CUESHEETに追従して逐次的に音楽を再生するような場合は、この形式でも1行1行処理していければ破綻なく再生できると思います。ページの例ではTRACK 02はその前のファイルの最後の部分を含む (おそらくわたしなら表示上はトラックを切り替えつつ、実際には前のトラックのファイルを使用するような設計にします) というような逐次的な処理は、すべてのトラックをあらかじめデータベースで管理するTuneBrowserのような考え方とは相容れないものと思います。
余談ですが、おなじTuneBrowserでも「変換」の処理は、トラック単体で変換した場合のギャップレス変換のため、そのトラック前後のトラックの末尾と冒頭もデコードします (再生時はこの処理は意味がないと思うので、やっていません)。
ということで、ご期待に沿っていないかもしれませんが、NoncompliantのCUESHEETは世に正しくあって、それが今回のような混乱をまねく結果になっているので、トラックに関連づかないFILE指定があった場合は、それを検知して非対応と判断するような処理を考えたいと思います。
TikiキーマスターYUUKOBASBさん、
別の話題が進行して反応できずすいません。現在は右クリックメニューで「先頭から連番」という操作がありますが、「先頭から1から連番」があれば便利な感じでしょうか?
Tikiキーマスターご確認ありがとうございました。解決してよかったです。
Tikiキーマスターserenityさん、的確なフォローありがとうございます。
TBLoverさん、ファイルの一覧をアップしていただきましたが、トラックとファイル名の対応がわかりませんので、お願いしていた情報とは残念ながらちがいました。
それで、アップしていただいたcueファイルを調べていて、今回の現象に至る原因がわかりました。ファイル名が同じだと言われたときにはこれは原因究明は無理だと心が折れかけましたが、ファイル名をご確認いただいていれば、トラック番号4.5と4.05は以下のように異なっていたはずです。
■ トラック番号4.5のファイル名
05 Пётр Ильич Чайковский - Romeo and Juliet (Fantasy Overture after Shakespeare): Andante non quasi moderato - Allegro giusto - Moderati assai.m4a
■ トラック番号4.05のファイル名
The Six Symphonies - Symphony no. 4 / Romeo and Juliet.cue
件のcueファイルは、率直に言って、お行儀の良くないcueファイルです。リッピングソフトはなにをお使いでしょうか? 参考に教えていただけないでしょうか。
以下はお送りいただいたcueファイルのうち、トラック番号4.5と4.05を発生させていたものの抜粋です。
FILE "01 Пётр Ильич Чайковский - Symphony no. 4 in F minor, op. 36: I. Andante sostenuto – Moderato con anima – Moderato assai, quasi andante – Allegro vivo.m4a" WAVE TRACK 01 AUDIO TITLE "Symphony no. 4 in F minor, op. 36: I. Andante sostenuto – Moderato con anima – Moderato assai, quasi andante – Allegro vivo" PERFORMER "Пётр Ильич Чайковский" SONGWRITER "Пётр Ильич Чайковский" ISRC USSM18900935 INDEX 01 00:00:00 ... FILE "04 Пётр Ильич Чайковский - Symphony no. 4 in F minor, op. 36: IV. Finale. Allegro con fuoco.m4a" WAVE INDEX 01 00:00:00 TRACK 05 AUDIO TITLE "Romeo and Juliet (Fantasy Overture after Shakespeare): Andante non quasi moderato - Allegro giusto - Moderati assai" PERFORMER "Пётр Ильич Чайковский" SONGWRITER "Пётр Ильич Чайковский" ISRC USSM18900934 INDEX 00 09:18:20 FILE "05 Пётр Ильич Чайковский - Romeo and Juliet (Fantasy Overture after Shakespeare): Andante non quasi moderato - Allegro giusto - Moderati assai.m4a" WAVE INDEX 01 00:00:00
TRACK 01は、その定義の「前」にFILEの定義があるにもかかわらず、最後のTRACK 05については、その定義の「後」にFILEの定義があるように見えます。
cueファイルは仕様が不明確なファイルですが、TuneBrowserでは、ユーザーの方からお送りいただいたものも含めて入手できるcueファイルを調べた結果から、FILE→TRACKの定義順で処理するようにしています。つまり、TRACKの定義が出てきたら、そのトラックはその前に定義されたFILEの内容のトラック定義だと解釈します。
そのため、上の例でTRACK 05が出てきたときには、これはこの定義の前の FILE “04…m4a” のファイルについてのトラック定義だとみなしてトラック番号05を生成します。
そして最後に FILE “05…m4a” が出てきても、その後にTRACKの定義がないので、このファイルはcueシートから参照されているとはみなしません (=トラックを生成しません)。
TuneBrowserは、cueファイルから参照されているファイルは、データベースに登録しないようにしています。ファイル名が “04…m4a” のファイルはトラック番号05として参照されているのでファイル単品では登録されませんが、”05…m4a”はトラックとして参照されていないのでファイル単品で登録します。その結果が、トラック番号4.5のトラックです。またcueファイルから登録したトラック番号4.05のトラックは、実際には “04…m4a” のファイルを示していることになります。
今回のcueファイルは (他のcueファイルも同様でしたが)、ひとつのcueファイルのなかで FILE→TRACKのケースとTRACK→FILEのケースが混在しており一貫性がありません (「お行儀の良くない」と言ったのはそのためです)。
どうするか、ですが、わたしとしてはこのようなcueファイルがたくさんある状況では、cueファイルそのものを処理しないように設定することをおすすめしたいです。
設定ダイアログボックスの「基本の設定」から右側の項目で「登録に関する詳細設定」「CUESHEETファイルの扱い」を「処理しない」に設定します。その後いちどTuneBrowser内のデータベースの情報を削除してから、改めて登録してみてください。
Tikiキーマスターご報告ありがとうございます。
解決してよかったです。(^^)
Tikiキーマスターあるいは、最初に出していただいた例のトラック番号2と、トラック番号02のファイル名でも構いません。それぞれの具体的なファイル名を教えてください。
Tikiキーマスターありがとうございます。
繰り返しになりますが、トラック番号4.5のトラックのファイル名と、トラック番号4.05のトラックのファイル名を教えていただけませんか?
Tikiキーマスターすいませんが、ひとつひとつ状況をお尋ねしてTBLoverさんのご利用状況を確認していくこともできませんので、今回の件は問題の原因を突き止めるのは率直なところ難しいと思います。
最初にアップされた画像のトラック番号4.5のトラックのファイルはcueファイルでしたか? 参考までに、そのファイル名を教えていただけないでしょうか? また差し支えなければ、そのcueファイルをコメントのAttachments(添付ファイル)の機能を使って、アップしてみていただけないでしょうか?
また、再度確認させていただいて恐縮なのですが、トラック番号4.05のファイル名も、念のために本当に4.5とおなじかどうか確認いただけないでしょうか?
よろしくお願いします。
Tikiキーマスターこんばんわ。ご報告ありがとうございます。
使用するマイクロソフトアカウントは「関係があるかどうかは分かりませんが」どころか、最初のコメントも書いたようにもっとも大切な情報です。購入時のアカウントが特定できてよかったです。
デバイスの登録方法はマイクロソフトのアカウントシステムの操作になるのでわたしにはわかりませんが、通常はログオンすればそのPCが登録されたように記憶しています。
TikiキーマスターTBLoverさん、すべてcueファイルだったのですね。
残念ながら、現在のところいただいた情報からはこれ以上のことはわかりそうにありません。あまり目にしたことのない特異な状況でしたが、改善に至らず申し訳ありません。
Tikiキーマスターおなじファイルで、トラック番号が異なった形式で(しかもダブって)表示される問題と、その順番がおかしい問題は、別の話のような気がします。
前者については、cueファイルをご利用ではないでしょうか。Ctrl+Eでファイルを確認されたとのことで、この場合はcueファイルをご利用であればcueファイルが選択されてエクスプローラーで表示されますので、あまりまちがえる余地はなさそうですが…。
順番の件は、Tree Viewでフォルダーツリーを選択されていないでしょうか。その場合、トラック番号順ではなくファイル名順になりますので、意図しない表示になる可能性があります。この仕様は、最近でもこちらのトピックで話題になりましたが、そこにも書いたように、ややこしいので近い将来のリリースで改める予定にしています。
前者のほうは、これまで見たことのない事象ということもあり、的確な話ができずすいません。よろしくお願いします。
Tikiキーマスター1の例だと、おなじタイトルでも、トラック番号以外に再生時間もちがいますね(4.5と4.05、あるいは5.5と5.05)。またいずれもALAC形式ですね。
これらがおなじファイルだとすると、残念ながらすぐには思い当たる点がありません…。
ジャケット画像の部分を選択すると、そのアルバムの全トラックが選択されますが、その状態で右クリック、「データベースの更新」を行うと、なにか状況はかわりますでしょうか?
-
投稿者投稿