ティアのホームページ☆ミ:Page 107 oC
<<< << < prev3$F? 107/554ページ(1661件) $FAnext3 > >> >>>
To Close..大は小を兼ねない場合もある 2017年02月13日11時47分
先日上がった記事によると、

以前から発表はされてた、とてもManyコアなCPUが販売されるようです。

24コア/48スレッドでデータセンター向けだそうです。

確かに、一般PCでコレを有効活用するのは無理そうですが・・・本当にそれだけでしょうか??


CPUの処理能力の上限が生まれた理由は、メモリとCPUの距離の問題です。
486迄はメモリアクセスノーウェイトと言われるのが普通でしたが、CPUの高速化と共にメモリとの物理的な距離が問題になってきました。

ノースブリッジを介しての接続がCPU直の接続に切り替わったりもしましたが、それでもGHz単位で動くCPUに対して、未だに666〜800MHz程度で動いているメモリというのはとても遅いのです。

それでもSDRからDDR、DDR2等に進化するに従い、メモリのバースト転送とかブロック転送とか呼ばれる手法でCPUのキャッシュを満たし、メモリに直接データを読みに行かなくてもいいような作りにしてきましたが、それでもやはりメモリに読みに行かなくてはならない状況は多数生まれるわけですから、いかんともしがたいのです。

そこで何を行ったかお分かりでしょうか?

HyperThreadingとか言うので、メモリアクセスの遅延を、別のスレッドの処理をすることで誤魔化すことにしたのです。

しかし当初のHyperThreadingは余り性能が良くなく、失敗作だとか言われていましたが?そんな事もあって、複数のコアを乗せてくる手法をとったり、HyperThreadingを混ぜたり、そう言った手法をとることで、一般のPC(のハイスペックの部類)では4コア8スレッドまで来ました。
もちろん、もっと多くのコアを乗せたCPUを搭載したPCを自作している人も居ますが、まぁ、事実上の問題として、その程度が限界なのです。

何が限界って??
それは、CPUとメモリの距離に起因する、データ不足を解消するための複数スレッドの同時実行です。
メモリ技術はたくさん有りますし、CPUが乗せるキャッシュ量もとても増えましたが、限界というのはあるのです。

あたしのPCで動画のエンコードとかすると、4コア8スレッドで、大体CPUの利用率は8〜9割です。
動画エンコードというのは、同じデータの再利用率が高く、お陰様で、データが足りなくなるのは、次のフレームに進むときくらい?でそれが1割ちょいのアイドル時間になっています。

一般的なデータ処理では、もっとCPUの利用率は下がります。
なぜかというと、同じデータをこねくり回しながら計算をする処理というのは殆ど無いからです。
コンピュータというのは、大量のデータを大量に計算するために作られたものですから、データの方がプログラムに比較してとても多く、同じデータを何度も何度も処理することはあまりないのです。


それなのに、最新のCPUが24コア/48スレッドって何を考えているのでしょうね??

もちろん、無駄とは言いませんよ??

有れば、何かの役には立つでしょうが、48スレッド分のデータを保持できるだけのキャッシュがあるのでしょうか??

その気になるキャッシュ容量は60MB(笑
あたしの使っているDevil'sCanyonは8Mちょいです。コレで8スレッドですから48スレッドというのは6倍ですね?
8Mの6倍は48ですから、数値だけなら60MBのキャッシュメモリは十分と言っても問題は無いのかも知れません。普通のプログラムを動かすのであれば・・・

では、メモリの転送速度はどうでしょうか??

Devil'sCanyonはちょっと古いので・・・最新のCPUのメモリ速度を拝借しましょう。

7770KのKaby Lakeの数値を見てみましょう。
DDR4-2400をサポートしているようですから、約38G

それに対して、このCPUは実クロックも低いですが、対応メモリも余りパッとせず、大した速度ではありません。(4chで一応DDR4-1866には対応していますが、7770kの2倍にも及びません)

キャッシュミスがある程度発生すると、全てのCPUがデータ待ちで止まる可能性も有る非常に危険な状態です。

バランスが余りに悪すぎます。


所で、データセンターってなんだか判りますか??

一般的には、ユーザーが直接使う側のPCではなく、いろんなデータが一ヶ所に集められている場所です。
大企業に数個ある程度か、データセンターという設備を運用している企業が大量に持っていたりします。
他種で数多あるデータを、いろんな所からの要望に従って、処理してその結果を返す仕事をしています。

今でなら、ビッグデータやらディープラーニングとか言う言葉がある程度はやっていますが、どちらも、莫大な量のデータを処理するのが目的です。

計算量が多いのではなく、データが多くて、それぞれのデータへの計算量はそれほど多くないタイプです。

こういった場合、キャッシュミスが発生しやすく、キャッシュメモリの量がどれだけ多くても意味が無いのです。
それに、キャッシュメモリの量がどれだけ多くても、転送速度が大して無いので、キャッシュを満たすだけのデータ転送が出来ない可能性が高いです。

そんな場合でも、データ処理の能力を上げる方法が一つあります。
それが、マルチCPUのコンピュータです。

CPUはそれぞれに大量のメインメモリを保持し、それぞれが、メモリに直接繋がっているわけですから、たとえばで言うのであれば、8スレッドのCPUを6個乗せて24コア48スレッドのコンピュータを作るのであれば、そっちの方が遙かに早いわけです。

インテルも一体何を考えているのでしょうね?

もちろん、用途を限定した特殊なCPUと言うのであれば、判らないではないですが?

データセンター向けとは言え、汎用CPUとしてだすには余りに無計画なスペック。


CPU一個も100万円を超えるようですし、只のデモ用と考えるべきでは無いでしょうか??

それはそれとして、このCPUは8ソケット構成にまで対応しているようですが?

只でさえメモリのバスが弱いというのに、他のCPUからのデータ要求とかが発生するようなプログラムを作ってしまうと、ますます遅くなってしまいますよね〜


まぁ、データセンターのプログラムはWindowsの様に何処のCPUで実行されているのか割らないような状態で動くわけでは無いので、場合によってはCPUを固定して実行しているでしょうし、キャッシュ処理の命令も自分で発効しながら実行するんでしょうからね?ピンポイントで必要なデータだけキャッシュしながら動かすことも可能でしょう。
キャッシュミスをしないように、事前にデータ転送を開始することも可能でしょう。

こうなると、キャッシュ処理がどれだけ上手く回せるかに性能が掛かってきますよね!


何はともあれ、癖が強くて使いにくいCPUということになります。
48スレッドはすごいけど、安くても使いたくない感じではあります。
閉じる
テーマ:たわごと URL:https://tsukiyori.sakura.ne.jp/index_m.cgi?ID=1343
 
To Close..いつまで経っても、楽にならない。 2017年02月10日17時09分
ListViewはセル表示(表とかグリッドとか言われる物)をする上でいちばん楽な方法であるため、意外と使っているのがあたしの現状ですが?

ListViewに表示される物が増えてくると、気になってくるのが遅延


なので、遅延を隠蔽するためのいくつかの機能があり、これらを利用することになるのですが、それでも限界という物があります。

結局、ListViewにアイテムを大量に追加することその物が遅いと言うことです。

ListViewはItems.Add等を実行すると、その場で追加するため(昔のSendMessage等のように処理が終了するまで戻ってこない)、複数追加するとその度にListViewがリフレッシュ(画面上ちらつく)され、遅い。

なので、いくつかの方法で、コレに対処が出来ます。

その一つが、再描画その物を中止させる。
ListView.BeginUpdate;
ListView.EndUpdate;
です。

コレにより描画その物が停止されるので、画面がプルプルすることもなく、追加が終わってOSに制御が戻された時点で更新されます。

しかし、コレを試してみると、
ListViewItemを配列に組み込む作業その物が結構時間が掛かることが判ります。

それの対応のためか、
ListView.Items.AddRange
という、初めから複数を一気に追加するための機能が追加されました。
しかしこれも数千追加するとなるとそれなりに時間が掛かります。
それ以上に、元データを用意する方も時間が掛かるのです。

特にImageListを作るには、ImageListその物がUIに組み込まれている機能なので、別スレッドから追加することが出来ない。
上記ListView.Items.AddRangeもUIの機能なので同様ですね?

ですから、元データを作るところは別スレッドで行う事が出来ても、UIの追加自体はメインスレッドで行わなければならない。
マルチスレッドごときでは対策できないのです。
(注:Invokeを使えば別スレッドから処理できるとかいう馬鹿がたまに居ますが、あれは一時的にUI側のスレッドを走らせて処理して、戻ってくるのを待って居るのです。だからUI側のスレッドで走っているのです。)

現在、MusicPlayerを作っているのは過去のを読んで貰えれば判るとは思いますが、数万曲のプレイリストを作った場合どうなるのかは判ったものではありません。

OSが64Bit化され、メモリやアイテム数の制限がなくなってきたのかも知れない昨今において、数万程度で時間が掛かって貰っては困るのです。

もちろん、1,2秒が待てないという意味での話ではありません。

あれだけ書いておきながら、”結局遅いのか”と思われたくないのです(笑

でも、これだけは言っておきます。
あたしが作った部分が遅いわけではありません。
ListView.Items.AddRangeを実行してから、戻ってくるまでがとても時間が掛かるのです。
(5000曲追加すると数十秒かかります。)

手の出しようが無いのです。


とか思っていたのですが、別の解決手段が提供されていました。
それが、
VirtualModeってやつです。

これは、つねにリスト全体を保持しておくのではなく、必要になったときに、その部分だけのデータをLVIとして送り込んで、そこの部分だけ表示するというものです。
(注:この関数機能自体は、マルチスレッドではありませんが、マルチスレッドで1件ずつ追加してるようなイメージでOKです。)

コレにより、ListViewItemの問題の対外の問題が解決されるのです。

それが、消費メモリです。

現在テストのために取り込んでいる音楽データは5000曲

この全タイトルをListView.Itemsに追加すると、消費メモリが2G近くまで増大するのです。
(全テキストと全イメージのデータを合わせても20Mくらいなのにね!)

一度なら表示出来るのですが、2度目は、データ差し替えタイミングの問題で、メモリ不足になってしまうのです。
もちろん、更新タイミングをもっと細かく区切って細かくDisposeすれば大丈夫かも知れませんが、現状そうは行っていませんし、余りにクリティカルすぎです。
それと、数万曲は入らない確定です。


VirtualModeの場合は表示時にに必要なデータだけを取得して居るみたいです。
だから、全く何も保持していない感じです。

実際には、
必要になったときにListView.RetrieveVirtualItemが呼ばれますので、即座にLVIを引き渡します。

あと、ListView.CacheVirtualItemsにキャッシュ機能があるので、それを利用することで、十分な早さになります。
CacheVirtualItemsは作らなくても動作しますし、この関数自体にキャッシュ機能が有るわけでは無いので作らなくても全然OKです。
ですがが、RetrieveVirtualItemが必要なアイテムを一つずつ要求するのに対して、CacheVirtualItemsはある程度の量を”まとめて作っておくように”と言う通知なので、コレを作っておくことで次に来るRetrieveVirtualItemの時に作り置きを返答することが出来ます。

また、CacheVirtualItemsを使うかどうかとは関係が無いのですが、RetrieveVirtualItemはものすごく大量に飛んでくるので、ListViewItemの配列を作っておいて、作った物はそこにどんどん溜めておく必要が有ります。
結果的に、CacheVirtualItemsを用意しなくても、キャッシュ機能は作らなければならないので、有った方がスマートです。

ただ、構造的にLVIは全部作る可能性があると言うことが一つの問題です。
まぁ、データを1000件以上作ったら一度リフレッシュするとかの機能が有っても良いですね?

でも、それほど心配は要りませんでした。
5000曲全部読み込んだ段階での消費メモリは180M 約1/10ですね
コレなら、このままでも5万件で1.8Gですから、32ビットアプリでもギリギリメモリは足りそうです。

でも、10万件は無理
数万件程度溜まったらリフレッシュする機能は必要かも知れません。


そこで考えるのが64bit化

64Bitプログラムに変換した所・・・・・大問題多発なのです。

Accessを利用する都合でAccess Database エンジンも64Bitの物が必要。

これは、有るからいれれば良い的な話ですが?

問題はいれられないこと。

32Bitと64Bitを同時にいれられないみたいなのです。

OLEで接続するわけですから、OLEのエンジンが64と32を自動的に仲介してくれるのかと思ったのですが?
どうもOLEは実行プログラムに対してかなり身近にリンクされて実行されているようで、出来なかったのです。

しかもOfficeまるごと64Bitのを入れないとダメです。
ちょろっと読んだだけなので詳細は分からないのですが、DBに埋め込んでおけるいくつかの機能は32BitAccessと64BitAccessで互換がないとかで、データベースファイルその物を作り直さないとダメになるっぽいです。
(注:保存してあるデータだけなら互換はあるみたいです。)

このアプリのためだけにそれほど大変な作業を使ってくれるかも知れない人達に強いるのは無理。
まぁ、そんな感じで、64bit化はやはり諦めるしかないようです。


それはそれとして、以前Officeをインストールしたときは、4時間くらい経って成功して終わったはずなのですが、消して、64ビットに入れ替えて、再度消して32ビットにしようとか色々していたら、インストールもアンインストールも出来なくなって
削除ツールとか、手動削除方法とか、沢山して、それで、やっと32bit版が入りました。

まぁ、やらないことをお勧め、

但し、95%辺りで、正常に出来ませんでした的なエラーが出て、再試行は出来るのですが、何度再試行しても完了しないので、「無視」を選択するとすぐ完了したりして、使いづらいったらありゃしない?


で、そうなるとやはり2G居ないで動作するように作成する必要がありますね!

で、チョイチョイ弄ってあっちが動くようになると、こっちがダメ、あっちがダメというのが出てくる。

今度はImageList
5000曲分のサムネイルを読み込むのは確かにメモリを圧迫するかも知れません。
でも一応32*32にまで圧縮はしているんですけどね?
単純に32*32*4*5000バイト消費すると考えるとデータだけで20M
本来であれば、重いはずも無いデータ量。でもImageはそれぞれクラスですし、Imageクラスには余計な機能がたくさん有りますし・・・で、調べてみるとやはりImageListがかなり重いよう。

該当文章に書かれているPCは今からすると10年以上前のでしょうか?
クロックはおそらく1G前後だと思われる頃の文章ですから、それと比べると全然遅くないですが、
時間の問題ですよね。
ですから、自分でイメージの配列を保持して、OwnerDrawで書いてしまうのが良いらしいですね。

その結果として消費メモリは130Mになりました、イメージデータが増えるに従って速度の低下は見られますが、
Listクラスを使っているのを考えると十分でしょうか?

それはそれとして、OwnerDrawの際、Column 0だけなんか減んな癖が合って、
e.BoundのLeftが常に0なんですよね?
色々と調べてみたんですが?e.Header.DisplayIndexが0以外の場合はListView.Columnsの各DisplayIndexがColumn 0のDisplayIndexよりも小さいものの幅を全部足す以外無いっぽいですね。

まぁ、自分で計算するのは大変ですが、実際にはPCが計算してくれるので、適当にforeachで回してしまえばすぐなので、まぁ問題ないかと?
それはそれとして、あたしとしては、その結果に+1をしています。どうも境界線上に有る気がするんですよ? 気分的な問題ですけどね?
どうも、グリッドはセルの左側に書かれているような気がするんです。
他のの幅を全部足したところから書いてしまうと、グリッドと重なっているような気がする。

そう言ったあれこれを経て、ListViewの問題は大方完了

所で、コレが原因で、ソートが出来なくなりました。
ListViewが全件の情報を保持していないため、ソート機能が使えないのと、グループの設定も出来なくなりました。
現状、グループをOnにすると造り込みの甘さが目立つ結果となっているので、コレを使わない方向でって事なので、まぁどうでも良いんですが、グループをOnにしてもグループ表示してくれないのです。
(まぁ、一応今後のために、グループ情報自体は保持しているんですけどね)


で、そうなると、データのソートは毎回DBですることになります。
まぁ、DataTableでも簡単なソートは出来ますし、何なら、Sortを実装しても良いんですが?
プレイリストなどの分を全件メモリ上に展開しておく必要があります。

まぁ、余り褒められたものではありませんので、DB上で行うことにしました・・・
そしたら、今度は別の問題が発生したのです。

作成中のプレイリストのソートが出来ません。

保存すれば出来ますが?

勝手に保存するわけにも行かない。
でも、メモリ上で行うわけにも行かない。

なので、作成中のプレイリストという専用のテーブルを用意しなければなりません。
何故かというと、DBではファイル管理機能を謳ってはいますが、対象外のフォルダから一時的に追加することもあるでしょう?
って事で、ファイル名だけで保持しているデータもあるんですよ?
それらのTag情報はそもそも、DBに乗っていない。

登録済みのは、複数テーブルにデータが分散していますから、それらと一緒にソートすることは出来ない。

結果、ソート対象情報を全件持った専用のテーブルを用意しなければならなくなったのです。
因みに、保存しておかないとソートも何も出来ないので、この、仮置き場への保存は、随時となります。

画面上では、未保存としておいてって感じですね?

その上で、実際に保存したときに、有るべき保存場所へ有るべき形で保存すると言うことに成ります。


で、コレをするためには、プレイリストのもっと綿密な管理が必要になりました。
旧式のプログラムのように必要な機能を満たすために、それ専用の関数を作っていけば良い問題ではありません。

いわゆるオブジェクト指向と言うものです。

コレまでも、それなりに暮らすわけはして作ってきましたが、
それだけでは、もうどうにもならないほど構造が複雑になってしまったのです。

結局プレイリスト専用のクラスを作る事にしました。
PlayListCollection
複数のプレイリストをまとめて管理するための物です。
PlayList
プレイリストの情報を保持するものです。
PlayListItem
リストのそれぞれの曲を表すデータです。

PlayListCollectionには、現在のプレイリストと、保存済みのプレイリスト全体の情報を保持し、全ての保存/読み出しの機能を含めました。
仮に、プレイリストを間違えて消してしまうようなプログラムを作ったとしても、ここを通さないと消せないので、自動的に問い合わせが出るような感じです。

また、同様に、現在のプレイリストを変更するための機能も一つの関数に集約することで、間違えた操作をできなくしました。(オーバーロードはたくさん有ります。)

とりあえず、特殊な機能を持っているプレイリストは
「現在のプレイリスト」と呼んでいる作成中/更新中の物
「無名のプレイリスト」と呼んでいる自動保存されて好き勝手に追加や削除が出来るもの。

「現在のプレイリスト」自体は、実際にはプレイリストとしては存在していなくて、無名のプレイリストやそれ以外の普通(有名)のプレイリストのコピーとして作成され、リストへの追加や削除をしても、元になっているプレイリストを変更しないで、データの保持及びソートなどが出来る様にしたもの。

「無名のプレイリスト」はちょっとファイルを再生してみたいときとかに、mp3ファイルをダブルクリックしたりすると自動的に選択されて、リストに追加されたりする物です。
「新規」を選ぶと、まっさらになったりします。
今すぐ聴きたい曲があったり、最近買ったばかりで、ヘビロテしたいときとか、様々ですね!

それ以外のプレイリストは、「現在のプレイリスト」にコピーされて再生されるわけですが、ファイルをD&Dしたり、DBに登録されているファイルをダブルクリックしたりすると、プレイリストにどんどん追加されていくので、上書き保存すれば、元のプレイリストが更新される感じです。
編集中の情報は一つしか保持されないので、保存しないで、他のプレイリストを開いたりすると、変更は破棄されて、新しく開いたプレイリストが「現在のプレイリスト」になるかんじですね。

まぁ、使う側は「現在のプレイリスト」を意識する必要は全くありませんけどね、

それにしても、WindowsMediaPlayerはなんであんなに起動が遅いのでしょうか?
アイコンをダブルクリックして起動してから再生までに1秒の遅延もなくプレイヤーは出来たわけですが?

あ〜、未だ、仕様の変更が適用されていない場所が合ったりしているのを、作り込んでいる最中なので、まだ公開は出来ないのですが?

もう、普段あたしが使う分には、使用に多いえられるような状態にはなっています。

閉じる
テーマ:日記 URL:https://tsukiyori.sakura.ne.jp/index_m.cgi?ID=1342
 
To Close..mp3プレイヤーを作ろう! 2017年01月02日23時51分
さて、コレまでに幾つか作ってきた、あたし謹製?のアプリに新しく加わる物が出来ました。

それがmp3プレイヤーです。

まぁ、wmaとかも再生したいのですが、今のところは贅沢しないつもりです。

まず、いちばんの問題はWMPが”使えない”からです。

コレは、動かないとか、エラーが出るとかって意味です(笑


以前にも何処かに書きましたが、あたしの持っているアルバムは数千、曲数で言うと数万。

コレを保持し、問題なく再生してくれるアプリにこれまで会ったことがありません。


確かに、多いですが?

業界で言うCDの売上げが下がっているとかって言うのとは、あたしは無縁なのです。


あれらのえらいオッサン達は、CDが売れないのはMP3プレイヤーの所為だという(当時)

でも、あたしの持っているメディアの枚数、曲数、そういうのを考えてください。

CDに入っているのは良い音質なのかも知れませんが、とてもでは有りませんが、聴きたい曲を選んで聞くと言うことは不可能です。

あたしの持っているメディア(DVDなども含む)は全部まとめておけば部屋の半分を占めます。

どうやって目的のアルバムを探すのでしょうか?



さて、それから、月日は流れました。

音楽プレイやーがmp3などの電子媒体へ本格的に変更され、mp3ファイルを持っていても、捕まえられてしまう人は居なくなりました。
さて、それならそれで、ミュージックプレイヤーとして何があるのでしょうか??

appleのituneも含めて、あたしの持っている曲を全部登録して、落ちなかったアプリは何一つありません。
もちろん、落ちないだけでなく、あたしが頑張って入力していたTag情報を正確に読み出し表示出来るものとなると、更に少ないです。

また、登録された一部のファイルを再生するだけでも、プレイリストを作るのが大変なものや、ジャンルやアーティストによる絞込などが正確に出来る物がありません。

これは、タグ情報を正常に読み込まないことにも問題が有ります。

もしかしたら、初めは読んでいたのかも知れないのですが・・・実際に選択したり再生したりとかって段階になると正常に処理されていないのです。


こうなると、もう自分で作るしか有りません。
基本的には、仕事中に流しっぱなしにするので、とことん軽量で使いやすいこと。
ソートやフィルタリングなどが多彩に出来ること。
プレイリストを沢山登録出来るほか、臨時にいつでも気軽に作れて、更新や、新規登録が出来ること。

検索やソートを早くするためには、DBを利用する必要があります。
まぁ、一般的にはAccess以外の選択肢はありませんよね。
ちょっと遅いのがネックですが、その辺はあきらめましょう。


また、IDタグを参照するので、これを読み込むための機能が必要です。

なので、簡単にする方法として、ググってすぐに見付かったコレを利用することにしました。

ID3LibとMp3Libです。

これは、csid3lib-v0.6-src.zipとして配布されている物で、それぞれのプロジェクトを自分が作っているアプリの中にチョイっと入れてあげればOKです。

まぁ、初めはコレで、D&Dしたファイルのタグを抜き出して、リストに表示するという感じのを作ったのですが、いくつかのファイルで読み取り中にエラーが出る。

調べた結果URL情報タグの処理に失敗している。

幾つか直しもしたのですが・・・・

そのうち、UTF16のデータなのに、文字化けが大量に発生することが判りました。

まぁ、英語圏の人はこれでもいいのかも知れませんが?日本人としては話になりません。
もう、使っていられない。


そのついでに、再生用に利用を始めたBass24のライブラリの方でも、タグの表示が出来ることが判ったので、コレを利用してみたのですが・・・・
文字列のタグを、タグIDと共に取り出してくれるだけなので、タグの処理その物は必要で有る事が分かったし、ID3Libの方で出来ていた画像データの取り出しが出来ないことが判りました。

やはり、タグはタグとして、正確に処理するしか有りません。

Bass24の方で、タグの座標を取り出す機能がありましたので、それで、タグサイズを測り、タグ全体をByte配列として取り出し、タグの読み込みに対応することにしました。

そして・・・そこまで来て・・・・なんとmp3ファイルのビットレートが判らない(笑

別に再生するだけなら登録しなくてもいい情報ではありますが、ビットレートの低いデータをCDから取り込み直して更新している最中なので、値の低いのだけを抽出する機能が欲しい。

しかし、只これだけの機能のためにId3LibやらMp3Libを使うのはイヤ(笑

結局Mp3の型式も調べて、ビットレートの情報だけ抜き出すことにしました。


こうして、mp3の情報も、IDTagもどちらも自力で読み込み機能を作ってしまいました(笑


なので、再生に使うBass24のライブラリと、c#で開発しやすくするためのBASE24.NETのライブラリを使わせて貰うことになりました。


因みに、タグの読み込み速度は、Id3LibとMp3Libを併用したときに比べ異常に早くなりました(笑


今は未だ、DBの方が設計中なので、聴きたい曲をその度にフォルダからドラッグ&ドロップして再生しているんですが・・・・それでも、WMPよりはマシな感じです。



なぜって?? 1ファイル再生するだけで、同じフォルダの中身をガンガンに書き換えられてしまうからです。

たしかにね?色々な機能があって便利ではあるんですよ?

でも、「更新しない」設定にしてあるのに、何で更新するんでしょうね?

フォルダに置いてあるカバー画像とかも勝手に変更するし?

確かにね?Windows2000とかって頃なら小さくしてくれるのはありがたかったですけど、
今のPCは、巨大なサムネイルを表示したり、タグで設定したAPICデータをイメージで表示したりそういったことも出来るのに、なんで32×32って何の絵か判別できないくらい小さいのにしてしまうんですかね??

因みに、あたしがTagに登録してあるデータは500×500くらいです。

これくらい最低限でしょ??

まぁ、何にせよ、消されても良いように、別に沢山保存してあるデータからコピーし直したり、無理矢理変更されたタグ情報を元に戻したり、不要に付けられたタグ情報を削除したり。
そう言った作業をしなくて良いだけマシなのです。

mp3が勝手に書き換わる原因である「CDDBのタグ」と「UFIDのタグ」はそのうち自動で全部削除するような機能を付ける予定。

まぁ、何はともあれ、3日でここまで出来れば上出来かな??

閉じる
テーマ:日記 URL:https://tsukiyori.sakura.ne.jp/index_m.cgi?ID=1341
 
<<< << < prev3$F? 107/554ページ(1661件) $FAnext3 > >> >>>