ぬるぽを見かけたら 全力でぶっ叩くのみ


by Denullpo Smasher Hammerson
カレンダー
S M T W T F S
1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30

カテゴリ:こっち関係( 56 )

今回は、再生時間を調べてみた。
今時のプレイヤは再生時間が充分に長いんですが、
調べるにはいい機会なんで。

んで、再生時間ってのはメーカーが公表していて
購入時の選択ファクタとなる。

・Round #2-0a: 公称再生時間
1st: (64h) COWON J3-16G
2nd: (50h) Media Keg MG-F516
3rd: (42h) WALKMAN NW-S645
4th: (24h) iPod nano MC068J/A

これだけ見るとiPod不利なんですが、一般的にバッテリ容量は
重量に影響を与えるわけで、再生時間が長けりゃいいってもんでもない。
その重量で比べると、こうなる。

・Round #2-0b: 公称重量
1st: (21.1g) iPod nano MC068J/A
2nd: (53g) WALKMAN NW-S645
3rd: (62g) Media Keg MG-F516
4th: (76g) COWON J3-16G
…とまあ、見事に逆転しました。

More
[PR]
by denullpo | 2010-10-09 14:04 | こっち関係
10年近く使い続けてきたMP3プレイヤのリモコン部分がこぁれかけたので
そろそろ買い換え…ってところで、大容量の端末にいろいろブチ込むよりも、
用途別に端末分ける方が使い勝手いいのではないかと考えた。
で、ついでにいろいろ比べてみようってことで、別機種で4台。

a0101404_852777.jpg



左から、
iPod nano MC068J/A
WALKMAN NW-S645
Media Keg MG-F516
COWON J3-16G
どれも16GBでし。

まず、テストデータとして手持ちのMP3ファイルかき集めてきた。
2292曲で15.1GB、まずはこれを転送してみる。
ストレージとしての性能を見たいので、単純にコマンドシェルでの
コピーにかかる時間を計った。しかし…

ディスクに十分な空き領域がありません。

__prz

More
[PR]
by denullpo | 2010-09-20 08:27 | こっち関係
年末にまとめて放映してた某アニメをDVDに焼くというミッション。
でもこれ、6時間枠2本に無理矢理詰め込んであったので、ファイルが1話毎に
分かれてなかったり。

そんなわけで、まずは1話毎に分けるところから。
方法としては
・プレイリストで擬似的に分ける
・分けたい位置でチャプタに分けて、これらをHDD→HDDで再録画
のどちらか。
何時間もかけて再録画する気は起きなかったので、とりあえず前者で。
しかし、これはこれで面倒な作業だったりする。
プレイリスト作成は1つのファイルに対して奇数チャプタ/偶数チャプタしかない。
まず、1,2話をチャプタで分けて奇数チャプタ→1話
次に、2,3話をチャプタで分けて偶数チャプタ→2話
次に、3,4話をチャプタで分けつつ1,2話を最結合して偶数チャプタ→3話
次に、4,5話をチャプタで分けつつ2,3話を最結合して以下略。
だりぃ…

んで、各話ともプレイリスト上でCMカットしますた。
ここでちょっと気になったのだが、長時間録画すると後ろの方でちっとっつ
映像と音声のタイミングズレてくる模様。
CM→本編の映像切り替わりでチャプタ分けたとき何故かCMの音が残ってて、
音を外すには2コマほど余計に映像を切り取らなければならない。
おそらく、ハードウェアの都合で音声の再生レートが微妙にズレてんでしょ。

で、さぁ焼こう…っと、初めの1話が書き込み完了したところで動作が止まった。
何十分待っても先へ進まないし、操作も一切受け付けない。ハマットル
泣く泣く強制シャットダウンかまして再起動。
コピーワンスなのだがHDDから消滅してなかったのは不幸中の幸い。
DVDだと不安定なのかと思って1話だけHDD→HDDを試みてみたが、それでもダメ。
おそらく、長時間録画したコピーワンスのファイルから継ぎ接ぎのプレイリストで
ダビングしようとして複数箇所への部分削除が発生するときハマるっぽい。
(短いファイルで実験したときは正常動作してた)

結局、寝る前とか出かける前とかで時間空いたときに再録画する方針で何とか。
CMカットやり直しだけど。
[PR]
by denullpo | 2010-01-21 01:24 | こっち関係
[ロジクール ロジクール G13 アドバンス ゲームボード G-13]
どんなに優れたハードも、ソフトがなければただの箱
…とはよくいったものである。
とりあえず、アナログスティックと見せかけて4方向ディジタルとしてでしか
反応しないのは一体なんなんだと。

んで、キーアサインユーティリティの使い勝手もアレなので全Gキーでスクリプト
呼び出して、スクリプト側でキーアサインするようにしてみた。
なお、G23~25はマウスボタンに固定し、アナログスティックでマウスカーソルを
それなりに動かせるようにしてみた。でもpress/releaseしか補足できないので、
押した方向に矯めてって離したときに移動するような形で。
これでも、ピクセル単位の細かい操作ぐらいには使えるです。

なお、日本の最新版ドライバではGキー操作でOnEvent()が呼ばれない
バグがあるので、このスクリプトは動作しませんです。
アメリカ版サイトから最新版ドライバ持ってきてちょ。

スクリプト表示
[PR]
by denullpo | 2009-08-07 23:59 | こっち関係
某筋でタイムアタックやってたので考えてみた。
慣れればコンスタントに1分切れるかと。

・最終形の一段階手前を確立する
最後にハマるポイントは、おそらく13~15の入れ替えとなろう。
(何故いきなり最後の話なのかというと、パズルの解き方を考えるときは
最終形を念頭においておくのが基本なのであーる)

その13~15が入れ替え可能であり、且つ他の駒をすぐ最終形にもっていける形は、
以下のような感じ。

1234
5678
1012 15
9111314


ここから [12]→ [11]↑ と動かせば、 [9]~[12] [13]~[15] が繋がる。
あとは最終形に向けて [14]← [15]↓ [10]→ [9]↑ [15]← で完成。

因みに、この形にできない場合はどうやっても絶対解けない。
試しに、最終形から隣り合う2つの駒を入れ替えただけの配置から解いてみよう。
例えば、こんな感じの。

2134
5678
9101112
131415 


解けないことを悟るまでにどれだけ時間かかることになるのか興味。
悪戯のネタにも使える。

More
[PR]
by denullpo | 2009-05-25 20:32 | こっち関係

革命的筆算 除算篇

某所で話が出てきたので、ちょいと考えてみた。
こういった現場の声は、改善のきっかけなのであります。
確かに、学校で教わる割り算の筆算は面倒で難しい。

というか割り算自体、四則演算のなかで最も面倒なのです。
コンピュータを使った計算でさえ、割り算は他の四則演算に比べて数倍の
負荷がかかる代物。(だから通常は逆数の乗算で代用する)
効率的演算で定評のあるインド式でも、除算についてはあまりパッとしない。

んでも、わかりやすさを追求するなら、もっとミクロに考えてみるといいんです。
割り算 a÷b がもつ意味は、
aから何回bを減算できるか
ということ。
例えば 20÷3=6…2 は、20から3を6回引けて2余る。
単純明快。これを筆算に応用していけばよい。

More
[PR]
by denullpo | 2009-03-29 20:43 | こっち関係
インド式の凄いところは、最適化の発想なんですな。
従来の常識を破りつつも、ちゃんと数学的に証明できる方法を見いだしたところね。
んでも、実際使ってみると別の面で今ひとつ面倒だったりする。
ならば、その発想を活かしつつ従来の手段に取り入れればいいのだ。

例えば、987×876という乗算を従来方式で計算すると

   987
  ×876
──────
  5922
 6909
7896
──────
864612

…とまあ、どうやっても暗算は無理そな。
何故この形で暗算ができないかというと、積和の手順が複雑だからなんです。
この計算を手順通りに分解すると、以下のようになる。

   987
  ×876
──────
    42
   48
  54
   49
  56
 63
  56
 64
72
──────
864612

こんな桁位置バラバラな手順で積和繰り返してたら暗算なんて無理。
もうね、計算途中でテンポラリ忘れるから。

More
[PR]
by denullpo | 2008-05-10 03:21 | こっち関係
[過去記事]
[壹] [弐] [参]

変数に相対的な計算を重ねていくと誤差が嵩むわけで、その対策として
リフレッシュ処理が要る。具体的にどーすりゃいーのかっつーと、誤差が嵩んで
きそーなところで精度を改善してやればいい。
前回で例示した2D回転ベクトル(c,s)を加法定理で回していく場合、誤差により
"回転ベクトル"としての要件を満たさなくなる可能性がある。
この要件ってのは、cとsの関係が成す法則。任意の回転角に対して cos と sin を
求めたとき、両者にはどんな関係が成り立っているのか?

c2+s2=12

が正解。
(1じゃなくて12なのは、2乗された値であることを強調しているん)

で、誤差が嵩むとこの式が成り立たなくなるんですよ。
回転させているうち、渦巻き状に狭まっていくかもしれないし、逆に広がるかも
しれない。この問題を防ぐには、前述の式が成り立つように修正してやればよい。
特に、単位ベクトル,単位マトリクスを回転したものに対してこの手のリフレッシュを
行うことはノーマライズといって、ベクトルやマトリクスを扱うときの基本技だったり。

More
[PR]
by denullpo | 2008-04-19 21:27 | こっち関係
[過去記事]
2D,3Dプログラミング向け我流数学 其之壹
2D,3Dプログラミング向け我流数学 其之弐

今回は、実践的なところで。

[お題]
平面上の任意点を原点周りでひたすら回転し続けるプログラムを考えるべし

普通に考えるなら、回転角を変数として変化させつつ、その都度回転公式を通して
いけばよい。以下の例では、ループの度に回転後の値が x2 と y2 に格納される。

x=INPUT_X;
y=INPUT_Y;
r=0.0; // 回転角
while(1){
    // 回転角のcos,sinを求める
    c=cos(r);
    s=sin(r);

    // 回転後の位置を求める
    x2=c*x-s*y;
    y2=s*x+c*y;

    // 回転角をずらす
    r+=0.1;
    }


…とまあ、こんな感じになるのだが、この例は処理効率の点でボツ。

More
[PR]
by denullpo | 2008-04-16 23:33 | こっち関係
[過去記事]
2D,3Dプログラミング向け我流数学 其之壹

ベクトルとマトリクスの乗算はベクトルをどちら側に置くかでマトリクスの意味合いが
変わってくるが、プログラミングにおいてはそれだけではなく、さらに重要な違いが
顕れる。それはハードウェアの性質に起因する要素であり、どう扱うかで計算効率が
大きく変わる。3DCGみたいに大量のベクトル演算を要する場合、これらを考慮して
設計しなければならない。

法則1: データをメモリ上に置くときは、何次元のデータだろうと必ず1次元に展開される
例えば、2次元であるマトリクスをメモリ上に置くときは通常、行単位でまとめられ、
それを1次元に並べ直した状態となる。
a0101404_0415245.gif

はメモリ上に
xx xy xz xw yx yy yz yw zx zy zz zw wx wy wz ww
と配置される。

一方、ベクトルはどっちでも内部構造的には変わらない。数学的には表記が変わって
くるものだが、1次元に展開しちゃえば(X,Y,Z,W)が X Y Z W の順に連続して置かれる
のは一緒。

More
[PR]
by denullpo | 2008-04-08 00:58 | こっち関係