Anonymous

フォーラムへの返信

100件の投稿を表示中 - 301 - 400件目 (全511件中)
  • 投稿者
    投稿
  • ご指摘どおりのようでありました。

     

    TAGSCANNERでダンプ↓

    artist –> One For All

    albumartist –> One for All

    album artist –> Null

    よろしくお願いします

     

    Attachments:

    あ、でも添付画像をみると

    アーティスト名ですね。。。

    確認します

    アルバムアーティストの One for All を触って

    One For All にしたような記憶があるのですが、いま手元のパソコンではないので記憶に自信がありません

    明日確認して連絡差し上げます

    >Tree Viewにフォーカスがあれば、カーソルキーの操作が効くはずです

    やりなおしてみたら、できました

    失礼しました

    1. Create a shortcut for TuneBrowser.exe
    2. Open the properties of the created shortcut, add ” / loc en” and start it.
    The author says that there may be incompleteness in English.

    Attachments:

    もしくは、ツリービューにフォーカスがあたっているときは、キーボードのカーソルキー操作(↑↓)でスクロール動作になると、ある程度使いやすくなると感じます(現仕様では、右下のペイン(ライブラリビューア、プレイバックキュー)内の移動動作になっています)

    もしかして設定で切り替えられますか?

    よろしくお願いします

    返信先: CUEファイルのエンコード #2213

    Tikiさんこんばんは、やはり1人での開発は大変そうですね、陰ながら応援しています。

    原因と解決法が分かって何よりです、koumaさんもQTTabBarを使っていたのには驚きました。

    ならばはっきりさせておこうと思い、デフォルトのエクスプローラーで試したところエラーは出なくなりましたのでやはりQTTabBarが原因だったようです。

    QTTabBarがあると他のツールなどでもエクスプローラーを開く動作をさせるとエラーを吐くことがよくあるのでTuneBrowserでも同じかなと漠然と放置していましたが分かって良かったです。

    本当は先に試して確認しておくべきでした、その点は申し訳ないです。

    返信先: CUEファイルのエンコード #2210

    エラー内容はフォルダを開けなかったという意味ですが、これはTuneBrowserで変換後に自動で開かせる場合でも手動で開く場合でも、曲が保存されているフォルダを2フォルダ以上エクスプローラーで開く動作をさせると必ず出るエラーですね、実際には開けてはいるのですが。

    私はエクスプローラーをQTTabBarというのを使って少し変えているのでそのせいかなと見送っていましたが、TuneBrowserの不具合の可能性が高そうかな?

    1フォルダの場合でもたまに出ますがこちらは条件が分かりませんね、どちらにしろ改善してもらわないと治らないと思います、別トピックにした方が良さそうではありますがどうなんでしょうか。

    コンバートの件ですが、先程の時点で条件をなるべく同じにすべく、実際にCUEシートを分割して変換していましたがやはり圧縮率は最大だったのでこちらでは正常っぽいです。

    聞く限りでは想像ですが、エンコード時のパラメータが逆になっているのと内臓エンコーダの圧縮率が低いのは恐らく原因が同じな気がします。

    原因として私が思いつくのはTuneBrowserのバージョンくらいですね、後は32bit版か64bitかAVX版かUWP版かの違いくらいなもんです、ちなみに私は現在の正式版で通常の64bit版を使用してます。

    私が分からない事を想像して予想するのは的外れで正直ほとんど意味がないのでこの辺はTikiさんのお力が必要かと思います。

    返信先: CUEファイルのエンコード #2207

    他の方がどうか分かりませんが、以前から変換時の圧縮率は8と同等だったのでそちらがデフォルトで、koumaさんの状況は本来の動作ではないとは思います。

    これ以上は私には分かりそうにありません、申し訳ない。

    返信先: CUEファイルのエンコード #2205

    私が確認する限りではfoobarでflac.exeを使って圧縮率8でエンコードしたのと同じですので、他のflacエンコーダを使ってるにしろ異常に低いって程の差はないと思いますが…

    具体的にどのソフトを使った時と比べてなのか、どういう系統の楽曲でビットレートの差がどれくらいあるのか等が分かると比較や解決に繋がるんじゃないかなと思います。

    返信先: CUEファイルのエンコード #2201

    こんにちは

    CUESHEETの扱いは変換時の設定 (画像の部分)で変更可能です。

    Attachments:
    返信先: DSF/DSD 5.6MHzのみノイズが出る #2171

    メーカーさんに問い合わせましたところ、想像を超えた回答を得ました!

    ———————-

    お世話になっております。ベンチャークラフトでございます。
    日頃は弊社製品をご愛顧頂きましてありがとうございます。

    お問い合わせいただきました件ですが、ご利用環境に
    よるかとは存じますが、SounDroid VANTAMは正式には
    Windows10への対応(サポート)は致しておりません。
    何卒ご理解いただきますようお願いいたします。

    今後とも、弊社製品を宜しくお願いいたします。

    —————————————————–

    そう来たか!(Windows10対応云々という論点ずらし)

    あきらめましょう。。

    皆様ありがとうございました。

    勉強になりました。

    こんばんは

    一番最初に書きましたがBase x2は再生している曲が44系か48系を判断し

    44系音源 (44:88:176kHz)なら88kHzになり元々88kHzの音源は変化なし

    48系音源 (48:96:192kHz)なら96kHzになり元々96kHzの音源は変化なし

    これがBase系の動作としては正しいはずですが私が間違っていますでしょうか?

    nikuyamaさんのおっしゃっている楽曲ごとのオリジナルレートの2倍で再生したいを実現するのはBaseと書いていない x2 の方を選択すればいいはずです。

     

    Attachments:
    返信先: DSF/DSD 5.6MHzのみノイズが出る #2162

    ご丁寧にありがとうございます

    さいわい、問題の出ているDACはベンチャークラフトという本邦のメーカーですので
    海外メーカーや代理店ものよりも丁寧な対応が期待できるかもしれません
    折を見て連絡をとってみたいと思います
    (同メーカーの別の機種でどうなるかを試してみれば、そのメーカのドライバの癖がわかると思うのですが、あいにくその別機種(Soundroid Typhoonというの)が壊れてしまったためにVANTAMという機種を購入したという経緯でありまして、手元で試せないのが歯痒いところです

    質問があれこれになって恐縮ですが、関連事項ですのでこのエントリーに書きます

    TBの右上のペインをみていると
    Basex2設定の場合に

    44Kのファイル→Device Samplerateの表示枡は88K
    48Kのファイル→Device Samplerateの表示枡は96K
    96Kのファイル→Device Samplerateの表示枡は96K
    176Kのファイル→Device Samplerateの表示枡は88K
    192Kのファイル→Device Samplerateの表示枡は96K
    と表示されていて、176k以上ではデバイスサンプルレートが半分の値になっています
    なんで?
    ※添付は176Kファイルのもの

    DACの設定かもと思い、マニュアルをみてみますと、それらしいことが書いてありまし

    ———————————————
    44.1kHz~96kHzまでの音源は、DSUS機能により最大
    192kHz/32bitにアップスケーリングが可能です。
    176.4kHz以上のサンプリング周波数のデータに関しては
    TH(スルー)モードでご使用ください。
    ———————————————
    そこでスルーモードに設定してみましたが、それでも状況かわりませんでした
    いま出先でSoundroid VANTAMしか手元にないので帰宅後別のDACでも検証してみます

    と、ここまで書いたところでご返信をいただきましたので、いったんをれを拝見します

    Attachments:

    DACのサポートする上限値を狙いたいわけではなくて、次のような理由からお尋ねしている次第です

    1.どのようなDACを接続しているときでも、アルバムのオリジナルレートの2倍で再生したい(DACのによってサポート上限が違うのでいちいち設定を切り替えるのはめんどくさいのと、オリジナルの2倍くらいで聴くのが適当とどこかで読んだことがあるため)
    2.ソフト(TB)の機能として、Basex2と設定しているのにそのとおりにならないのはなぜに?という単なる疑問から

    以上です

    返信先: DSF/DSD 5.6MHzのみノイズが出る #2136

    昨日購入したDACで、昨夜発見した現象ですので
    メーカーには未だ問い合わせていません
    他のソフトでは問題なく再生されることから、尋ねてもオクラいりする危惧を予見します(こういう業界での経験上・・・)

    「TBでエラーが出ていない」とは、通常再生ドライバの指定を間違えたときなどに出るメニューバー下のドッキリマークつきのエラー表示が出ていないという主旨ですので、他にエラーやダンプが吐かれるような機能なりがあるようでしたら取得してみますのでご指導のほどよろしくおねがいします

    Upper limit を0に設定してみても
    同じでした

    添付は、Basex2 Upper Limit 0の設定で
    96KのファイルをResampleオンで再生しているところ

    なにか、わたしがおおきな勘違いをしてるのでしょうか

    よろしくおねがいします

    Attachments:

    ご指導ありがとうございます
    この値をDACがサポートしている上限値に設定しても、事態に変化がないためお尋ねしている次第です

    返信先: DSF/DSD 5.6MHzのみノイズが出る #2129

    TBではブビブビいうアルバム(ファイル)を
    他のソフト(MusicBee)で同じDAC(Soundroid VANTAMのASIOドライバ)を使って再生したところ
    正常に再生されました
    したがって、同DACのドライバが腐り気味なのではなく、TBとの相性問題であるように推察されます

    よろしくおねがいします

    ご指導ありがとうございます
    設定は添付のとおりです

    Attachments:
    返信先: DSF/DSD 5.6MHzのみノイズが出る #2125

    (注)上記の1.2.は、それぞれ1が2.822MHzでサンプリングされたアルバム1、2が5.645MHzでサンプリングされたアルバム2と、別々のものです。1つのアルバムをサンプリングレートを変えて再生したという意味ではありません。

    返信先: DSF/DSD 5.6MHzのみノイズが出る #2124

    別のパソコンでの検証結果も同様でした。

    よろしくお願いします。

    別のパソコンでの検証結果も同じでした。DACは、Soundroid VANTAMでもxDuoo XD-05でも同様でした。

    プリファレンス設定:Basex2

    Resample釦:ON

    44kのファイル→88kになる

    48kのファイル→96kになる

    88kのファイル→88kのまま

    96Kのファイル→96kのまま

    192Kのファイル→192kのまま

    よろしくお願いします。

     

    こんばんは

    Base x2は実際の曲のサンプリングレートではなく44.1kHzか48kHz系のBaseからx2するという意味なので、88.2kHzと96kHz以上にはならないものだと思います、Base x4ならば176kHzと192kHzですね。

    ただのx2かx4ならば曲のサンプリングレートに応じてアップサンプリングしてくれるはずです。

    88.2の音源はありませんが、私の環境では96kHzの音源でもx2や176400や192000を選択しても反映されていますので、そちらはちょっとお力になれそうにありません。

    TuneBrowserは現在の正式版である4.3.1.1362です。

    返信先: 音 音量 の均一化 #2119

    すいません、説明下手で分かりづらかったですかね;;

    ReplayGainを計算する をした時点でTagに書き込まれます、曲を右クリックからプロパティで一番下の方に REPLAYGAIN_ALBUMとTRACKの情報が書き込まれているはずです。

    その後ReplayGainを有効化すればどの曲でも同じ音量になるので、元々の曲の音量差を意識しなくてよくなります (厳密には計算時にトラック単位かアルバム単位かで音量は変わるのですが)

    ReplayGainというのは「何dBにする」というのが決まっているので、計算した後は編集したりする必要はありません、-~dBの数値は元々の音量に依存するので曲ごとに数値は変わります。

    Tag扱いで曲の波形を直接弄っている訳でもないので音質劣化も招かず、ReplayGain情報を削除すれば元通りになりますし、計算してあってもReplayGainを有効化しなければ元の音量で再生されるので計算しておくことにデメリットは特にありません。

    Bit PはBit Perfectの略でTuneBrowserではBit Pとなっているのでそう書いたのですが逆に分かりづらくややこしくしてしまいましたね;;

    Bit Perfectの詳細はまた省きますが、これが有効になっていると音量を弄れなくなる為、手動でスライダーを弄ったりReplayGainでの音量調整が出来なくなるのでOFFにして下さいと言いたかっただけなのでOFFになっていれば気にしなくて問題ありません。

    また分かりづらいかもしれませんが、分からないことがあれば私に分かる範囲でしたらお答えしますので気軽に聞いて下さい(^^)

    返信先: 音 音量 の均一化 #2116

    こんにちは

    TuneBrowserに限らず音量はReplayGainというもので均一化することが出来ます。

    詳しくはReplayGainで調べたほうが理解も出来ると思うので説明は省きますが

    ReplayGainはTag扱いなので、まず曲を選び右クリックからReplayGainを計算、適用し、ReplayGainをONにして再生すれば反映されます。

    Bit Pを有効にしていると仕様上当たり前ですが音量が弄れないのでReplayGainも効きません。

    返信先: 要望:VSTプラグイン対応 #2100

    こんばんは

    そこそこ昔からTuneBrowserの1ファンであり使用者である私としては特に再生周りが変わってしまうのは残念だと思ってしまいます。

    私も使い勝手が良く自由度もあるし音質にもそこまで不満がなかったのでfoobarを使っていた事がありますが

    (勿論私の使いやすさとTikiさんの使いやすさの基準が違うのは理解しており当然で、その上で失礼を承知で申し上げますが大事な所なので) 使い勝手が今ほど万人向けとは言いづらく良くはなかった時でも、TuneBrowserにはそれらをひっくり返す位の音質に驚かされ使い始めました。

    これも上からな物言いになってしまいますが、再生周りに気を遣っていると言うだけのことはあるなと本当に思わせてくれたんです、そう思わせることがどれだけ難しいことか色々使ってきた人には分かると思います。

    他にも色々プレイヤーは使いましたが、その中でも直感的に使いやすいし弄りやすいなと思っていたものもありましたが音質に納得出来ず (開発者が改善する気もなかったようなのも大きいです) この使いやすさとTuneBrowserが組み合わさったら最高なのにと当時は思っていました。

    ですが今ではその使い勝手もTikiさんのこだわりや技術力、使用者からの要望を取り入れてきたことで本当に良くなり誰にでも薦められる程になったし、もっと皆に使ってみて欲しいとすら私は思っています、その結果要望も更に多くなり大変そうですが;;

    頭が固い私はあまり余計な処理が挟まれるのを好ましいと思わない傾向にあるので音源はwavにこだわり、アップサンプリングやアップコンバート、イコライザーなどは、勿論全て聴き比べをした結果ですが使わないような人種です。

    金持ちという訳でもないので何百万もオーディオ機器につぎ込めず、大体30万程なので相対的に見れば大した事ありませんが、これでもただ良い音を聴くために随分高い金を払っているなと思っているくらいです。

    そんな程度の私ですが、1ファンとしてTikiさんがこれからTuneBrowserをどうするか期待と不安の両方ありますが、今の音質、使い勝手に満足しているということもあり

    別件の時にも1度感想みたいのを書きましたが、音質に影響がおきそうな部分の変化には特別慎重になってもらいたいという想いが強いので、こういう経緯や意見もあるということを残しておきたくて長々書かせていただきました。

    返信先: SACD #2096

    なるほど

    わかりました

    返信先: Update Database #2088

    ご苦労さまです

    新版がでましたら、検証の助力となれればと思います

    よろしくお願いします

    返信先: Update Database #2084

    ありがとうございます。

    今回のケースでは、該当したアルバム(ファイル)が他のアプリケーションにエンキューされていた状態ではなかったと思います。まず最初にTBのプロパティ編集で0にした(他のアプリではそのアルバムは触っていなかった状態)もののツリービュー上が更新されなかったので、他のソフト(MusicBee)でみたところ、COMPILATIONが0になっていたため、ファイル上は書き換わっていると思い、TBにてUpdate Databaseを実行した流れだったように記憶しています。

    とはいえ、

    「今回のケースでは、手動クロールや自動クロールでは、タイムスタンプが更新されないので読み取り損ねた”0″はいつまでも更新されませんが、データの更新を行うと、あらためてファイルを読み取ることでデータベースとの差異に気が付きますので、データベースの内容が”1″に是正されると思います。」

    とおっしゃっている動きについては、そのように振る舞っていたように思いました。

    以上です。

    返信先: Update Database #2070

    ありがとうございました

    返信先: Update Database #2068

    ありがとうございました

     

    DB Updateしないと反映されないことがある件についてですが、まさかですがディスプレイドライバとの相性原因とかあるでしょうかね・・・

    いま手元のパソコンで出た現象ではないので正確にわからないのですが、現象がでたパソコンではTB起動時に「Intelのグラフィックドライバのバージョンが古いから新しくせよ」的なメッセージが出ます。

    ようは、見た目だけが更新されてないのか、ということ

    関係ないでしょうね。、、

     

    返信先: Forumのエントリー内の並び順 #2065

    わかりました

    ありがとうございました

    返信先: V4.3.1をChromeによるDLで警告 #2030

    Version 65.0.3325.146 (Official Build) (32-bit)に更新すれば大丈夫でした。

    返信先: MP4→MP3の変換エラー #1982

    Naos 様

    ご教示いただきありがとうございました

    返信先: MP4→MP3の変換エラー #1978

    >エンコーダのパスは、基本設定のエンコードツールのところ

    すみません、見つけられません💦

    「基本の設定」の、そのまた何処にありますでしょうか。

    よろしくお願いします。

    Attachments:

    ありがとうございました

    なるほど
    では、複数あるときは、どのようなルールで選ばれるのですか

    MP4動画とキャプチャ画像を置き、TBがManage Images…でFolder Imagesで表示している場所:デスクトップ

    今次懸念対象のMP4動画を楽曲と呼ぶのであれば、左様です。

    デスクトップ上の、DHCに云々というのがMP4動画、*.pngがキャプチャ画像などです。

     

    Attachments:

    厳密に申すとこういう環境です。

    楽曲(管理フォルダ):G:ドライブ(外部HD)の\Files\Flac と\Files\MP3

    MP4動画とキャプチャ画像を置き、TBがManage Images…でFolder Imagesで表示している場所:デスクトップ

    考えようによっては、デスクトップがこのMP4動画およびその他PNGファイルの管理フォルダとみなされているのかもしれませんが。。。

    よろしくお願いします。

    TBは、Library Viewerにファイルをドロップしたら、自動的に管理フォルダのどこかになにかを保存するみたいな機能があったりしますのですか?

    ありませんねぇ。

    人生には『三つの坂』がある。上り坂・下り坂・まさかの坂(まっさかさま)人生思い掛けぬ落とし穴がある。何が起きるか、『まさかの坂』でございます。

    銅像。

     

    05.png スクロール前(上部)

    06.png スクロール後(下部)

    よろしくおねがいします

    Attachments:

    朝イチでTBを立ち上げたところ、昨日終了したときの状態で、Library ViewerにMP4ファイルの画像(誤っているもの)が表示されていました。
    その画像で右クリックしてManage images…をみると、Cache Imageとして誤りの画像(フォーラムに投稿した画面キャプチャPNG画像)が登録されていました(01.png)。
    どうやら、なんらかのタイミング・原因で、MP4ファイルのアイコン情報が別の画像ファイルのものとしてTBに認識されてしまったようです(OSが管理している情報でしょうか?)。
    それで、このプロパティ画面上で、このキャッシュ画像を右クリックDeleteし、あらためてMP4ファイルをLibrary Viewerにドロップしたところ、今度はそれを示す画像が本日作成した別のキャプチャ画像(上記したChace Imageが示されているプロパティ画面の画像)になりました。

    どうやら、そのときにデスクトップに置かれているPNG画像、あるいは直前にWindowsのPhotosユーティリティで表示した画像などをTBがLibrary Viewer表示用の画像として取り扱っているように見えます。その画像はTBの画像管理プロパティ上では、Chahe Imageとして取り扱われています。

    昨日も、フォーラムの別トピックで画像添付すべく、まず画面キャプチャした画像をデスクトップに置いて、それをWindowsのPhotosでちら見し、Chromeを使ってフォーラムに添付送信、その後MP4ファイルをTBのLibrary Viewerにドロップ、という作業経緯だったように思います。

    素人ユーザには不可思議千万な動きですが、開発者の方なら原因が推察できるかもと期待。

    参考まで、わたしが行ったと記憶している手順を記述します。

    OSはWinwows10 (x64) 最新状態(Fall Creators Update、最新パッチレベル)

    1.Youtubeの動画をMP4としてデスクトップにDL
    2.TBを起動し、Library ViewerにこのMP4ファイルをドロップ。このときは、MP4動画の画像(アイコン)が表示されたと思う(うろおぼえ)。その後、いったんLibrary ViewerからDELでこの画像を削除。
    3.TBの画面をPrtScrnでキャプチャし画像編集ソフトで少しいじってデスクトップにPNG保存
    4.その画像をWindowsのPhotosで表示
    5.ChromeでTBのフォーラムに投稿、そのときこの画像を添付送信
    6.TBのLibrary Viewerに再度MP4ファイルをドロップ。すると画像がフォーラムで投稿したPNG画像に。以降は、この画像をLibrary ViewerからDELしてあらためてMP4をドロップしてもPNG画像画像のまま(つまりキャッシュされた画像を使っているらしい)。
    7.そこで、TBのManage images…画面で、このキャッシュ画像をDELしたのち、別のPNG画像画像をWindows Photosで表示し、TBにあらためてMP4をドロップすると、今度はこの別のPNGの画像がMP4画像として表示されることに。
    8.この誤画像をDelete from Database してから再度MP4をドロップしても画像はキャッシュされたもののまま。

    <添付ファイルの説明>
    01.png 枠で囲まれている画像が、MP4を示すもので絵は昨日フォーラムに投稿したPNG画像
    02.png 本日キャプチャした Mnage images…画面を保存したPNG画像
    03.Library Viewerの上側の画像が、本日あらたにドロップしたMP4を示す画像。絵が本日作成したPNG画像のものに変わっているのがおわかりいただけるでしょうか。
    04.png MP4動画のアイコン。絵が明らかに違うでしょう?

    よろしくお願いします。

     

    Attachments:

    トピック内の案件(課題)が混濁してしまい、ご面倒をおかけしていますが、当方の件はこれで終了としますので。

    (hiro様ご投稿の内容は、管理者様にて別トピックとして切り出していただいたほうが、のちのち他の閲覧者が参照するのに便利かもしれません。ご判断にてご処置をお願いします。)

    肉山のほうの結論。

    【結論】

    結論をまず申すと、本件は忘れてください。ジタバタしただけで終了。
    おそらく当方のハードェア(およびそれに関わるOSの振る舞い?)のせいだと思われます。

    【検証手順】
    1.OS立ち上げ
    2.HD(G:)接続(USB V2ポートに刺したV2対応ハブ経由)
    3.TB起動
    4.TBがDBの登録作業を始める
    5.ファイルが沢山あるので、ある程度のところでTBを終了
    6.HDのとりはずし
    7.TB起動→DB登録は消えない
    8.TB終了
    9.その後HDを再接続しようとごちゃごちゃやっていると、OS(ExplorerとStorage-Disk Management)がG:ドライブを表示しなくなる。
    ※ステータスバー内の機器とりはずしアイコンには同ドライブの製品名が表示されているがアサインされているべきドライブレターは表示されていない。つまりOSはハードウェアとしてHDが接続されたことを認識はしているがOSが認識するドライブとしてアサインしていない。
    10.同HDをUSBハブ経由しないで直接USB V2ポートにつないだところOSが認識しG:をアサインした。

    上記のような現象は、今日はじめて出た。

    ⇒ゆえに、ハブとHDとの相性問題がTBの振る舞い(OS経由のドライブ認識)に影響を与え、誤認識させたものと結論づけることとしたいと思います。。。

    昨日から、おそらくハブとHDとパソコンの相性悪い兆候が出始めていたのではないかと推察します。おそらくハブが腐り始めているのだと思います。。。ハブ酒になる一歩手前。

    安物のハブ(実売で700円くらいのもの)で、1年以上使っているので、そろそろお釈迦なのかもしれません。
    なにも高度な機能を持たないハブだと思うので、そのハブがHDをの接続状態を記憶保持しているとか、ハブの状態をOSが記憶しているとか、そういうことはないものだと想像しますが、機械やOSの素人がいろいろ斟酌してもしょうがないので忘れることとしたいと思います。

    ちなみに、ハブは下記の製品です。

    サンワサプライ USB-HCS307BK

    よろしくお願いします。

     

    OSのStorageーDisk Management画面では、
    Gドライブは接続されてない(認識されてない)状態が示されてたと思うので、面妖なと思うのですが。。。
    いずれにしても、あす同じようなことをしてみます

    G:ドライブの登録が消えた状態でそのまま置いておかれたら(あるいはTuneBrowserを再起動したら)、再度G:ドライブの内容がTuneBrowserに登録されたのですよね?

    否です。
    消えてそのままです。
    消えて以後は、まだHDをつないで登録処理を実行していません。
    あすそれをしてみて挙動を報告します
    検証のための有効な手順があれば教えておいてください

    ちなみに、そのパソコンはだいぶ初期のUSB V3ポートがついているらしく、そのポートにHDをさしても認識しなかった(もうひとつのUSB V2ポートは認識するのでいままでそのポートを使っていたところ、きょうはじめてたまたまUSB V3ポートにつないでみたらだめだということを知った)という経緯もありました

    ちなみに2、関係ないと思いますが、一連の操作は次のとおりです
    1.HD接続→TB起動・DB同期→TB終了→HDとりはずし→TB起動→DB登録消える
    2.USB V2ポートにハブがつながっていて、その先にHDをつなげているのですが、そのハブにもう一台のHDをつないでHD-HDでFastCopyを使って内容同期しようとしたら、同じポート内に2台のHDをつないでいるとIOエラーが出ることがわかったため、初めてV3ポートにHDを接続してみらた認識されなかった
    3.それでHD同期をあきらめて、V3ポートとV2ポート(のハブ)からHDをとりはずした
    4.たまたまMP4ファイルをTBでもMP3変換できるはず、いちど試してみようとHDを繋がない状態でTBを起動したら、DB登録が消えていくことに。

    ※上記のようなディスク認識やIOに係る操作をしたことからOSの管理する情報にへんな情報が保持されたのかしらん?

    きょう、はじめて報告した現象が出て、その後はあらためてDB同期→TB終了→HDとりはずし→TB起動をしていないので、必ずなるかどうかわかりません
    Gドライブをはずした状態でTB起動したら、あれよあれよという間にDB登録数が減っていって登録がなくなってしまって、目が点になりましたわ。
    ※添付したプリファレンス設定では、HDがないとき消さない の設定だと思うんですが。。。

    この現象も手元の環境ではないので、あすためして報告します

    いまいる場所にはないパソコンでのことですので
    明日ためして報告します

    ちなみに、MP4ファイルもPNGファイルもデスクトップにおいた状態で作業し起こった現象ですので、おそらくイメージの管理を開くとデスクトップ上にあるということになると推察します

    返信先: MP4→MP3の変換エラー #1926

    もしlame指定わすれが原因なのであれば、できれば、初回MP3変換のときは、処理をはじめる前にlame.exeを場所指定せよとゆぅてもらえますと、ありがたいですね。。
    結構な時間、処理が走ってからエラー、といわれたから。。。

    返信先: MP4→MP3の変換エラー #1924

    あ、Error : File does not exist: lame.exeと出ていますね
    自分で用意したlame.exeの場所を設定するんですね?
    そういえばFB2KでもはじめてMP3変換するときにlameのありかを聞かれた気が。。

    どこで設定するんですか?
    x64TBにはx64lamegが、x86TBにはx86lameがいいですか?

    返信先: MP4→MP3の変換エラー #1922

    訂正

    clipboxというアンドロイドアプリでDLでした

    画面に表示されている画像は、質問で添付したTBのプリファレンス画面ですが、右クリックしてプロパティをみると、MP4動画の情報が正しく表示されます

     

    以前に、下記のように教えていただきましたが、、

    ————————————-

    ドライブがいなくなってしまった場合、既定の設定では、一時的にマウントが外れただけと考えて、楽曲の情報は削除しないようになっています。

    この設定を変更するには、設定画面の、

    左側のツリー:「基本の設定」
    右側の項目 :「登録に関する詳細設定」-「ドライブごと存在しない場合は消去しない」
    この部分をNoにしていただくと、削除されるようになります。

    ———————————-

    本日、外部USB HD(G:)をつなげてDB同期→TB終了→ 外部HDをとりはずす→TBを立ち上げる→TBがDBエントリを削除してしまう という動きがありました。これは仕様どおりでしたでしょうか。

    監視フォルダ G:\Files\FLAC;G:\Files\MP3

    TB版:4.3.0.1358

    プリファレンスの設定は添付のとおりです

    宜しくお願いします

    Attachments:

    1.事象が出ているアルバムは、前回も含めて、新規登録でしょうか?

    はい、そうです

    2.動的タグ “_ALBUMARTIST” の設定は変更されていますでしょうか? (既定の設定は “ALBUM ARTIST; ALBUMARTIST” です)

    していません

    3.次回、同様の現象が発生した場合、TuneBrowserを再起動せずに、そのアルバムに対して右クリックから「データの更新」を行ってみてください (お願い)。

    承知しました。ただ、ご指示の操作は私のところで実施してみたけど変化が起こらなかったようにうっすら記憶しています。うっすらです、確証はありません。

    4.この現象は、大量更新中に稀に発生するとのことで、追い込みが非常に難しい状態です。

    どれくらいが大量への閾値か主観的ではありますが、6万5千曲ほどが入ったHDに対して、50~100ファイルくらいを追加するといった処理をよく行います。

    この現象がでるようになったのは、.1354ビルドからです。ただし、それまで気がついてなヵっただけかもしれませんが、おそらく.1354ビルドからの問題だと思われます。また、この現象は前回同様いちばんマイナーレビジョンの適用を行っている機械でのみ出ています。もっとも、この機械の使用頻度が一番高いので問題が出る/気がつくだけなのかもしれません。

     

    念のため事象をまとめると、

    FLACファイルのみで発生。→いまのところはそうです
    タグがまちがった値になるのは、いつもArtist系のタグ = Tree ViewもAlbum Viewも両方ともおかしい。→そのようです。問題が出ているときは、ぴんくいろのアーティスト名が表示されてないという事象がみられますね
    大量更新中に発生。→上記のとおり
    TuneBrowserを再起動すると正常化する = ファイルからは正しく読めて、データベースにも正しく記録されている。→そうです

    今後も品質向上の助力となれれば幸いです。

    よろしくお願いします。

    4.3.0.1357です

    名無し分類再現しました。(前回のとは別のアーティスト、アルバムで、本日新規に追加したもの)

    添付01の現象が出て、TBを再起動したところ名無し分類がなくなりました。

    スクリーンショットでは撮り損ねましたが、ステータスバーのReadyの位置に、前回と同様[]のような表示がでていました。

    必要であれば楽曲ファイルをお送りします。

    よろしくお願いします。

     

     

    Attachments:

    承知しました。

    他の明示的な諸課題にご注力ください。

    よろしくお願いします。

    これは、ダムユーザの根拠なき仮説ですが、5ツのうち2ツ名無し現象が出たPCは、いちばん頻繁にTBの版(マイナーレビジョン)更新をしクロールに係る検証をしている機械ですので、DBに一部コラプションがあったのかもしれないという視点もあるかと。TBのファイルからのタグ情報読み出し処理に問題ありの視点でなく、DBがくちゃけてたのではとの視点。

    寝言です。

    よろしくお願いします。

    >ちなみに、nikuyamaさんのところではもう二度と再現しないですよね?

    いまのところ再現しておりません

     

    よろしくお願いします

    分類おたくですみません

    よろしくお願いします

    現象が出たPCでは、そのとき、右下のペインのアルバム名の上にピンク色のアーティスト名が表示されていないものがあると申しました。(その表示されていないものが、名無しに分類されたもの)

    で、別PCでみると、5ツのアルバムすべてについて、右下ペインでアルバム名の上にピンク色のアーティスト名が表示されていました

    でで、現象が出たPCでTB再起動によって5ツ正しく分類された状態で右下ペインを見ると、5ツともアルバム名の上にピンク色のアーティスト名が表示されています

    参考になるかどうかわかりませんが、気づいたことをお伝えしておきます

    よろしくお願いします

    265MBでも同じエラーになるので、データ便で送りました。

    DLのURLはメールにてお送りします。

    データ便したファイルは、1ツのZIPに各5アルバムの1曲めだけをいれています。

    よろしくお願いします

    昨日申した、「別PCでは正しく5ツ格納されていた」件ですが

    このPCではだいぶ前のTB版で1ヶ月くらい前のHDの状態でDB同期したものに対して

    昨夜TBを最新ビルドにして自動クロールしたら対象アーティストの箇所に5ツのアルバムが入っていたものです。ですので、5ツのアルバムのうち2ツにタグの不整合・ゴミなどがあったのであれば、この同期でも現象が出たPCと同じようなツリー表示になるのではないかと思います・・・

    さきほど、もう一度フォームから再送信してみましたが、またも同じくFile is not selectedが出ました。

    21.6GBです。大きすぎますか?

    もし大きすぎるなら、わけて送りますので1送信時の最大許容サイズをご教示ください。

    よろしくお願いします

    TAGSCANNERはダンプ対象とするアイテムを自分で編集できますので、先のダンプは下記が対象になっています。

    $document_open
    $select %_index%,0
    “%title%”;”%album artist%”;”%albumartist%”;”%artist%”;”%album%”;”%track%”;”%year%”;”%genre%”;”%_length_sec%”;”%_filesize%”;”%_filedate%”;”%filepath%”;”%filenameext%”
    $endselect
    $document_close

    エクセルはこのソフトが吐いたCSVを私がXLSにしたもので、カラムの位置とか不要カラムの削除とかしていますので、上記の指定の順序どおりにはなっていません。エクセルの1ぎょうめは、私がつけたもので、albumartistと全小文字・スペースなしで書いたのは、私がそうかいただけです。ただ、上記指定のように”%albumartist%”と指定しているので、それに合致するタグ内容がダンプされたのだと思います。試しに、”%album artist%”という指定も加えてダンプしてみましたが、これは出てきませんでした。

    さきほどご指定のフォームから送信しましたが、

    完了画面でFile is not selectedと表示されています

    サーバ内には、到着してますでしょうか?

    現象の出ていたPCでTBを起動したまま一晩中(10時間程度)放置していましたが、ツリーに名無し登録があるところはそのままでした(おそらくその間に自動クロールが走ったものと思いますが)。

    そこで、いったんTBを終了して、すぐにTBを再起動(PCは再起動していない)してみると、名無し登録がなくなり、正しくEli Degibriというアーティストの中に5ツのアルバムが表示されていました。

    ツリー部の表示更新処理に課題があるのでしょうか?

    よろしくお願いします。

    別PCでは、正しく表示されていることがわかりました。

    クロール時になんらかの条件があると起こるのかもしれません。

    添付は、別PCのもの。

    よろしくお願いします

    Attachments:

    調べてみましたが、スペースがはいっている、何も入ってない、先頭にスペースが入っている などの状況はありませんでした

    参考として、TAGSCANNER(https://www.xdlab.ru/en/)というソフトでタグをダンプしたものをお送りします。黄色で塗った部分が、TBで名無しに分類されたものです。

    ※解決するまで、対象アーティストのタグメンテは止めておきます

    ※必要であればFLACファイルそのものの参考提供も可能です

    よろしくお願いします

    Attachments:

    続報します

    さきほどのツリーにいないといった2ツのアルバムについて、そのカテゴリの一番上に「名無し」で登録されていました

    これらのタグ付けをいろいろやってみて正しくアルバムアーティスト名のところに収まるか試してみてもよいのですが、まずはご意見(とご指示)をいただくまで、触らずにおいておきます。

    よろしくお願いします。

     

    Attachments:

    次の手順で、ツリービューに反映されない事象が発見されました。

    1.DB同期済みのHDを接続しWindowsに認識されていることを確認後TB(.1354ビルド)を起動

    2.アーティスト別に管理しているサブフォルダに新アルバムを追加→自動クロールされたと思ったもののツリービューに反映されない

    3.おかしいと思って、そのアーティストのサブフォルダを対象に手動(強制)クロールしたが、ツリービューに反映されない

    4.TBの右下のペインにはそのアーティストのサブフォルダに格納されているアルバムがすべて(5つ)表示されているが、ツリービューには表示されていない

    5.右下のペインのアルバム表示で、左の2つはアルバム名の上にアーティスト名が表示されていない(その2つについてツリービューに表示されていない)。その2つのタグのつき方は、添付2つ目のとおり。

    アーティスト名:Eli DegibriかEli Degibri Trio

    アルバムアーティスト名:2つともEli Degibri

    音声形式:FLAC

    TBのバグでしょうか、タグの付け方がまずいのでしょうか?

    たまたまこのアーティストで気が付きましたが、他のアーティストについても同様のことが生じているような気がします。

    ※新トピックスにしたほうがよければ、貴殿にて移動をお願いいたします。

    よろしくお願いします

    前記の

    【古い登録が残る場合の手順】
    1.TB4.3.0.1352以前の版で、過去のHDの状態(状態1)でDB同期
    2.TBを4.3.0.1352版にして、更新されたHDの状態(状態2)で自動クロール→古いDB情報が一部残る
    3.TBを4.3.0.1353版にして、さらに更新されたHDの状態(状態3)で自動クロール→古いDB情報が一部残ったままとなる

    の環境に対して、1354を適用し、30ファイル程度の更新のかかったHDを装着し自動クロールに任せたところ、古い登録が削除され、本日の30更新についても新規登録されました。

    クロール速度、ツリー表示への反映速度については、不満足を感じない程度である(ただし主観)と思いました。

    しばらくHDの更新にともなって、観察してまいります。

    ありがとうございました。

    ありがとうございます

    次の先行版(あるいは正式版)のビルド提供の日程目処がわかればご教示願えれば幸いです。そのタイミングに、HD更新のDB反映のタイミングを合わせるようにすれば検証に資することができるので。。

    よろしくお願いします。

    改修でご苦労をおかけしているところ、もしかするとムカつかせてしまうかもしれない事象について報告致します。。

    昨夜遅くに自宅の別のパソコンでTBをいじっていたところ、自動クロールで過去(小文字→大文字ディレクトリ名変更前、ジャンルタグ変更前)に登録されたDB登録情報が削除されない件につき、次のような条件で起こるのではないかと推察できる事象が見られました。

    【古い登録が残る場合の手順】
    1.TB4.3.0.1352以前の版で、過去のHDの状態(状態1)でDB同期
    2.TBを4.3.0.1352版にして、更新されたHDの状態(状態2)で自動クロール→古いDB情報が一部残る
    3.TBを4.3.0.1353版にして、さらに更新されたHDの状態(状態3)で自動クロール→古いDB情報が一部残ったままとなる

    【古い登録が残らない場合の手順】
    1.TB4.3.0.1352以前の版で、過去のHDの状態(状態1)でDB同期
    2.TBを4.3.0.1353版にして、さらに更新されたHDの状態(状態3)で自動クロール→古いDB情報は残らず新しいディレクトリ名/タグ情報に基づいてDB更新されたようにみえる
    ———————————————————–
    参考)

    (状態1のHD)
    ディレクトリ名 \Files\MP3\、\Files\flac\
    ジャンルタグ  (MP3)Jazz 、(FLAC)Soul など

    (状態2、3のHD)
    ディレクトリ名 \Files\MP3\、\Files\FLAC\
    ジャンルタグ  Jazz、Soul など
    ———————————————————–

    推察するところ、ディレクトリ名対応されていない先行版を途中

    に挟むと、DBの登録状態がおかしくなってしまうが、ディレクトリ名対応した先行版に直接UpgradeするとDBの登録状態は正しいものとなる、という動きのようです。よって、1353版で対処していただいたディレクトリ名変更対応は奏功しているのではないか。いずれにしても1352も先行版(テンタティブ)であるので、この問題について追求していただく必要性は低まったのではないか。(一般的には、正式版から正式版へのUpgradeで問題がでなければよいので)

    上記の現象は、ある1台のPC環境で検証しただけのものであり、別のPCでも同じようになるかどうかは確証がありませんし、本当に全ファイルを対象にDB更新されたかどうかまでも確認することができません(6万曲以上あるし、あちこちのファイルについて情報更新しているので確認は事実上不可能)が、ご参考までお伝えしておきます。

    いずれにしても、もっと問題点を追求なさって品質向上に努められるかどうかは、開発者さんのご判断ですので、上記は一現象レポートということで扱っていただければと存じます。

    よろしくお願いします。

    かもしれませぬ

    今やっていただいている対処によって派生的にイロイロ治るような気もしております

    よろしくお願いします

    ありがとうございます、ご無理のないようにお願いします

     

    ただ1点気になるのは、前回同期時からHDに変更がないのに、本日PCに接続してTB(新版)を起動したところ、進捗マドに

    Deleted, New File 云々の更新メッセージが出たことです

    これは、前回に漏らしていたということなのかな?と。

    よろしくお願いします

    ※別トピックと関連する内容ですが、こちらのトピックに書きます

     

    昨日とは別環境のPC(先週、ツリーに現れないアルバムがあるようだと申したPC))のTBを4.3.0.1353にしたところ、前回クロール以降、同じ外部HDにファイル(楽曲)の追加をしていないにもかかわらず、HD接続後TBを起動すると自動クロールが走ってかなり多くのファイルが追加(DB登録)されました。

    Crawler(Periodic)窓をみていると、あいかわらずある処理単位のあと一休み(3分くらいかな)して、次の処理単位がはじまる動きは相変わらず見て取れます(その一休み期間が従前バージョンより速くなっているのかどうかまでは、計測をしていないのでわかりません)

    一休みにはいる前に
    UL07275: 2018-02-19 10:30:56,602: 3354: TL02: Crawling all folders (Normal) has finished.
    UL07276: 2018-02-19 10:30:56,603: 3354: TL02: Next normal crawl time is 2018-02-19 14:30:56
    というメッセージが出ていたかどうかはわかりません(次の処理単位が走ると、前の処理単位のCrawler(Periodic)ログがクリアされてしまっているようなので。

    DB登録されていない(ツリーに現れない))アルバム/楽曲があったかどうかは、本日の観察ではわかりませんでした。

    宜しくお願いします

    動作速度については、前掲のとおりです

    >新規エントリーについてのDB登録やツリーへの反映は速くなったように思います

    >(ただし計測・比較をしたわけではなく、あくまで印象であります)

    フォルダ構成は次のとおりです

    前の構成とジャンル設定:

    e:\files\flac\xxxxxxxx

    (FLAC)Jazz Sax

    (FLAC)OST

    など
    e:\files\MP3\xxxxxxxx

    (MP3)Jazz

    (MP3)Guitar

    など

     

    今の構成とジャンル設定:

    e:\files\FLAC\xxxxxxxx

    Jazz Sax

    OST

    など

    e:\files\MP3\xxxxxxxx

    Jazz Sax

    OST

    など ※MP3ファイルのアルバムのアルバム名の先頭に(MP3)とつけて識別するように方針を変更した

    今の管理フォルダ設定

    e:\files\FLACと e:\files\MP3

    楽曲形式はFLACフォルダのものはFLAC、MP3フォルダのものはMP3

    ジャンルを編集したのは、メインはMusicBee、TuneBrowserで少々。(今回の問題(疑念)の対象となっているファイルはMusicBeeで編集のものと思って差し支えありません)

    ジャンル番号かジャンル文字列のどちらを書き込んでいるかはわかりませんが、私の場合独自のジャンル名を使っているので、文字列を書き込んでいるのだと推察します

    添付画像のツリー部で、先頭に(FLAC)とか(MP3)とかついているのは、前のジャンル設定のときのもので、今はその下の頭に(XXX)が付かないジャンルに変更しています。しかし、(XXX)の登録が消されていません。

    今日の環境では、認識されていないファイルがあるかどうかわかりません(気が付きません)

    ※認識されてない環境は別場所にあるPCであすなら確認できます

     

     

    Attachments:

    自動クロールにて、

    ①古いディレクトリ名時代の登録について、新版でも消されることはありませんでした(前のレポート時と同様の状態)

    ②また、ディレクトリ名は変更されていないが、タグ編集でジャンルが変更されているものについてもそれが反映されていません(前のレポート時と同様の状態)

    ①について、新ディレクトリ名に基づく新DB登録はされています

    ②について、新タグ情報(ジャンル名)に基づく新DB登録はされていません

    もしかすると、私がそういう仕様であることを勘違いして、おかしいおかしいと騒いでいるだけでしょうか?

    新規エントリーについてのDB登録やツリーへの反映は速くなったように思います(ただし計測・比較をしたわけではなく、あくまで印象であります)

     

    返信先: 4.2.4 で WASAPI で再生がおかしい #1758

    ですよねぇ… 基本Fostexドライバを使用してASIO使う方が多いと思いますが、

    WASAPIを使う場合、最初Event使用が多そうなので、HP-A?シリーズが定番機種というのもあり、今後もちょくちょく再生がおかしいという話題が出てしまいそうな気もします。

    Bulk Petも個人的には気になってるので聴いてはみたいのですが、アンプはP-1uが気に入っているのもあるので単体DACが欲しいなぁとも思ってるんですよねー。

    このままの状態になってしまうなら目立つ所に注意書きとか書いておくのもいいかもしれませんね。

    返信先: 4.2.4 で WASAPI で再生がおかしい #1748

    Tikiさんこんばんは、更新お疲れ様です。

    色々問題が出ており忙しそうですので、あくまで私の意見ですが、Fostexドライバ使用時でもMicrosoftドライバ使用時でも再生自体は出来、問題が難しいのもありますので対応は急がなくても大丈夫です。

    念の為に4.3.0 (1352)を使用して再度検証しました。

    Bit Perfect:Resample:RAMDecode(ALL) を各種ON OFF

    A8で確認出来る192KHzまでのあらゆるサンプルレート:ビット深度:ファイル形式 (基本wav)

    あらゆるパターンで試しましたがこれらは全て、下記に記載する再生不具合もしくはDECD反応との関連性は見つけられませんでした。

    Fostexドライバ使用時

    ASIO:正常

    排他Event:正常に再生されない、DECD反応なし

    排他Push :正常再生、DECD反応なし

    共有Event:正常再生、DECD反応したりしなかったり (条件不明)

    共有Push :正常再生、DECD反応したりしなかったり (条件不明)

     

    Microsoftドライバ使用時

    排他Event:正常再生、必ずDECD反応あり

    排他Push :正常再生、DECD反応なし

    共有Event:正常再生、DECD反応したりしなかったり (条件不明)

    共有Push :正常再生、DECD反応したりしなかったり (条件不明)

    デコード処理のバッファ時間及び、WASAPIのバッファ時間:デバイス呼出し間隔、

    スレッドの制御等、再生周りに関係しそうな設定は初期値で検証しました。

    使ってる私自身、挙動が意味不明ですし、この機種めんどくせーなとすら思いますが買い換える程でもないしなーって感じですね。

    Teacから新しいのも出ましたがまだ初値価格だしなぁと思ったり。(聴いてみないと候補に入るかすら分かりませんが)

    逸れましたが、他に何かあればやれる限りやりますのでよろしくお願いします。

    texmexさんこんばんは、

    幅の設定はそれぞれの表示方法の書式内にあるカラムで出来ます。

    私のプレイリスト表示の場合は画像の部分、幅調整Flexという方法で表示させています。

    下に説明が出ているのでそれを参考に色々試してみて下さい。

    ちなみに文字数が決まっている、あるいは最大文字数が決まっていてそこまで多くない項目の場合は、

    Fixを選択して幅テンプレート文字列で00000000 (適当ですが) のようにすると、

    文字数分 (上のだと8文字分) だけ確保するので表示の幅の無駄がなくなり調整しやすくなります。

    正直この辺は私もあまり詳しくないので、Tikiさんかこの書式に詳しい人がいると良いんですけどね。

    Tikiさんは今は忙しそうなので、代わりと言っては何ですが参考になれば幸いです。

    返信先: クロールの不確かな動き #1721

    訂正!すみません!

    さきほどお送りしたアルバムは、当方のタグのつけ間違い(ジャンルをつけ間違っていた)でした

    「補足2」についてはご放念ください

    返信先: クロールの不確かな動き #1720

    補足2です

    クロールで検知されないアルバム(フォルダ)について、FB2Kでも同じように検知されていないようです。フォルダか各ファイルの属性とかタグ記述に問題があるのでしょうか?

    そのアルバムフォルダをFB2K、TBに手でドロップしてみると、ちゃんと再生されますし、タグ情報なども問題ないように見えます。。。

    おそらく、他のアルバムで検知されていないものも同じ理由かと推察されます。

    参考として、FB2k、TBで検知されないアルバムフォルダを添付します。(個人的な鑑賞又は開発の目的のみに使用してくださいネ)

    https://www.datadeliver.net/receiver/file_box.do?fb=78a0d2d1c1924e66908cc376c5990174&rc=66956ba5c2cf46369b7357132890a3c4&lang=ja

    返信先: フォーラム掲示板のバグ? #1718

    補足

    別トピックでは、「編集」できました

    返信先: クロールの不確かな動き #1717

    補足です

    \アーティスト名フォルダ

    アルバム1

    アルバム2

    アルバム3

    とHDに入っているのに、ツリーにはアルバム1と3しか表示されていない、その状態のフォルダに対して、新しいアルバム4を追加したらツリーにアルバム1、3、4が(すぐに)表示された。アルバム2が検知されていないのに、新しい4は検知されたようです。

    むむぅ、でしょう?

    追記です、一度設定ファイルを削除してみるのもいいかもしれません。方法を記載しておきますのでよければ試してみて下さい。

    尚、改善しなかった場合にすぐ元に戻せるように、削除する前にどこかにファイルをコピーしておいて、

    試した後、そのファイルを戻せば削除前の状態に戻るので安心して下さい。

    ここでフォルダを開いて TuneBrowser.ini というファイルがアンカーツールチップの設定が格納されているファイルなので、

    これを削除して設定をリセットしてみるのもいいかもしれません、意外とiniを生成し直すのは解決に繋がることが多いです。

    削除する時はTuneBrowserを終了させてから削除しその後、TuneBrowserを起動すれば自動的にiniファイルが生成されます、余計なお世話かもしれませんがご参考までに。

    Europaさん、こんにちは

    私もwin10 1703で4.3.0.1351ですがYes/Noの切り替えはしっかり効いていますね。

    過去のverでもツールチップが勝手に出て来る事は無かったので、TuneBrowserの他に原因があるような気がします。

    初期ではYesですが、説明にもある通り何回か表示した後は自然とNoになるはずなのですが何が原因なんでしょうね…

    返信先: Player Viewのタイトルフッタ表示 #1710

    chandoraさんこんばんは

    Performerタグの所に文字はなくても空白のスペースが入っていませんか?その場合でもなるので確認してみて下さい。

    はい、GUI(ツリー表示部分)への反映がもぅちと速くなると使いやすいです

    もしかすると

    1.実際は、ディレクトリをまたいで、途切れずにクロール処理しているものの、クロール進捗情報窓(半透明のやつ)が一定時間で消えて何かのタイミングでまた表示再開されるので、処理が途切れているように見えているだけでしょうか。(以前に、進捗窓は放っておくと消えるというお話があったように思いましたので)

    だとすると、それを検証するために

    2.TBの1起動単位中に処理された(ファイル単位の)全クロールログを取得する方法はありますか?それを見れば、クロール処理が途切れたか途切れていないかを時間軸で確認できるから。

    よろしくお願いします

    こんにちは、私も何か意見でも言おうか悩みましたがあまり無責任な事は言えないので、

    Forum周りで一つだけ気になった点がSupportからForumに飛ぶと、ご意見、ご感想、ご質問などは~と出ますが、

    右側中ほどのForum欄のTuneBrowserから飛ぶとそれが出ないので、見つけやすさ的な意味ではどちらかというと後者からのアクセスが多い気がするので、そちらでも表示させるようにした方が伝わるのではないかなーと思いました。

    eibonさんこんにちは

    設定の一番下のタグの設定にコンテンツの区切り文字という欄があるので、そこの:を削除するか何かに置き換えればOKですよ。

    eibonさんこんばんわ

    表示方法は %ARTIST% という文字列で好きな所に表示させる事が出来ます。

    具体的にはプレイヤービューのアルバムアーティストの所に表示させる場合は、ファイル→設定から

    %_GRPARTIST%となっている所を%ARTIST%とする事でグループアーティストからアーティスト表示にする事が可能です。

    グループアーティストの隣にアーティストを追加で表示させる場合は%_GRPARTIST%の前か後に%ARTIST%を書き足せばOKです。その際はスペースや、等で間を空けないと繋がって表示され見にくいのでお好きに調節して下さい。

    テキストのスタイルの所で文字の大きさや色等もテンプレートから選べるので自分の見やすい様に変えてみるのも面白いです、自分で作る事も可能です。

    ライブラリービューやプレイリストを使っての表示では表示方法によって弄る所が変わってきます、画像の表示方式はプレイリスト表示ですが

     

    私は少し弄ってこんな感じになっています、メイン行の書式という所がタイトル等を表示させている列で、ここをクリックすると下の追加ボタンが押せるので押すと、カラムというのが新規に作成されますので自分で細かく弄りたい場合はそれで好きな位置に%ARTIST%を表示させると良いと思います。

    調整が少し面倒な場合もあるので、手っ取り早いのは上のグループアーティストの所で説明したように、既存のカラムのクエリ文字列を%ARTIST%に置き換えるか追記してしまうのが楽ですね。

    アルバムビューの設定の所でお好きな表示方法を弄れるのでトライしてみて下さい、分かりづらかったらすいません;;

    ちなみにですが画像はドラッグアンドドロップで新しいタブに持っていけば見やすいです、余計なお世話だったらすいません、左クリックで見れると良いなーと思いますね。

    >まだ本当にそのような動作をしていますでしょうか?

    LogView窓と、クロール状態表示窓(半透明のやつ)をチラチラ見ている限り

    そのように思われます

    返信先: 4.2.4 で WASAPI で再生がおかしい #1666

    EventとPushで分けて添付しておきます、見れば分かると思いますが両方共に1曲目再生→2曲目再生→停止です。

    いつもはRAMDecodeも使用していますが使用不使用に関係なく発生するので今回は省いています、よろしくお願いします。

    Attachments:

    そういう意味では、こちらから「印象」でレポートされても開発の効率が悪いでしょうから、
    なにかテストシークエンスと計測ツール(あるいは手順)みたいなものをご提供いただければ
    貴殿の参考により資するものになるかと思います

    失礼しました

    前記載の

    「どうも、いまいちのようです。

    前にクロールしたときから、同じHDでクロール対象のフォルダ名を変更していると、ツリービュー(つまりDB)にある以前の登録が残っているように思われます。

    新しいディレクトリ構造のエントリーは新しくツリービューに反映されているものの、古いエントリーも残っているようです。ただし、過去のものがきれいに全部残っているわけでもなくて、新しい構造にともなって消されたものもあるように見えます(対象ファイル数が多いので、詳しくすべて調査することはできないので印象です)」

    の繋がりとして本日記載しました

    速度については・・・

    目視での感覚でしか申しようがないのですが、
    従前より変更検知の速度は上がっているようには感じます
    (しかしながら、FB2Kのようなスルスル感までは程遠い印象です、ただしこれは言っても詮無い比較なので今後申しますまい)

    それと、これも印象ですが
    HDがPCに接続ずみの状態でかつTBが起動している(つまりHDをモニタリングしている)状態でHDに変更を加えたときの検知反応速度はこれまでより大分と速くなった「気がします」が、別PCで変更ずみのHDをPCに接続してTBを起動したときの検知速度はだいぶ以前の版よりは早くなったもののもう少しなんとかなならんかなとの印象です。

    これも比較してもしょうがないのですが、FB2Kではいろいろなディレクトリに変更がかかっていてもつながってスルスルDB更新してくれるのですが、TBの場合はあるディレクトリについて更新したらちょっと休んで別のディレクトリについて更新して、また休んでみたいな動きをします
    まぁ、忘れておいて他の作業をしていればいいのですが、気になりだすと「もう更新終わったかいな、いつ終わるんかいな」ときになってしまうので・・・
    更新終了する前にTBを終了するのもアレな気がするので、LogViewでクロール終了してることになっているかを確認したりして、僕ってけなげなユーザーと思ったりして。

    一定量の変更に対するDB更新のトータル速度については、速くなったかどうかはよくわからないというのが正直なところです。ファイル更新量によって都度違ってくるから。

    ある一定の更新に対してDBを新規作成にして、旧版と新版で速度比較してみればいいのですが、そこまではちとめんどくさい。。

    よろしくおねがいします

100件の投稿を表示中 - 301 - 400件目 (全511件中)