2006/12/30(土)スキャナ買い換え
2006/12/30 4:20
USB1.1世代のスキャナだし、最近のはきっと速いはず。入れ替えを考えた。
http://bbs.kakaku.com/bbs/00401010142/SortID=4590740/
http://bbs.kakaku.com/bbs/00400510146/SortID=5202764/
http://bbs.kakaku.com/bbs/00401010144/SortID=4676628/
これら書き込み等を参考にあちこち調べていたが、結論として最新機種だからといって速くなるわけではない。
常用する解像度によるようだけど、300dpiくらいまでだったら、Canon 8400Fあたり、EPSON GT-8300UF/9700F辺りの世代が一番早いようだ。300dpi以下では、モアレ除去を切ってもGT-Xxxx系のスキャン速度は8300UFに及ばないような気配である。
ただここら辺はカタログスペックからだとホント分からない。なぜならline/sが書かれている解像度がそれぞれ機種で違うから。そしてヘッドが戻る時間や、キャノン機種にある「調光中」で30秒近く停止する問題など実際に使ってみないと分からないことが多い。挙げ句最近はフィルムスキャナ推しなので、紙原稿は取り込み時間を具体的に書かない上に比較記事もない。海外の記事が参考になるかと思ったらラインナップが全然違ってやんの。機種名からして違うのは何か制限がかかってるのだろうか……
さて、結局オークションでGT-8300UFを入手した。型番上は下がっているが、300dpiまでなら爆速だと評判のスキャナである。廉価機種なので安いものの、電源ボタンがなかったりもする。Epson Scanが対応していないのでモアレ除去機能もこの機種にはない(とはいえ所詮ソフトウェア処理だからレジストリいじってやればいけるんじゃ???)。
閑話休題。で、GT-8700と比較計測。
測定時間は原稿台全面を対象に、「ボタン押してからスキャナから音がしなくなるまで」。全てオーバーヘッド分の時間も含んだ時間を書いている。計測は所詮ストップウォッチなので、精神的バイアスも含めた測定誤差あり。
原稿種:原稿台
フルカラー・ドライバ色補正無し・アンシャープマスク無し。
※なお、ヘッドの戻りはEPSONでは「キャリッジリターン」とも呼称。
[ GT-8700(USB1.1) ]
・preview: 12sec
・イメージタイプ:カラー写真
150dpi: 21sec
300dpi: 35sec
600dpi: 125sec
・イメージタイプ:白黒写真
150dpi: 19sec
300dpi: 28sec
600dpi: 64sec
・オーバーヘッド:
ヘッド動きだしまで:3sec
ヘッド戻り:4sec(取り込みは終了している))
[ GT-8300UF(USB2.0) ]
・preview: 8sec
・イメージタイプ:カラー写真
150dpi: 12sec
300dpi: 15sec
600dpi: 42sec
・イメージタイプ:白黒写真
150dpi: 12sec
300dpi: 14sec
400dpi(おまけ): 16sec
600dpi: 39sec
・オーバーヘッド:
ヘッド動きだしまで:2.5sec
ヘッド戻り:2sec(取り込みは終了している))
だいたい倍という所。感覚的にはヘッドが戻っている間に操作ができるのでもっと早くなった印象。確かに8300UFは速い。もちろんGT-8700は多分SCSIで繋いだ方が早いので若干損はしているだろうけど。スキャナメーカーはもう速度競争をしていないので、この辺りの世代で2倍はなかなか嬉しい。
ほかに速い機種は…… 書き込みを見る限りは、canoscan 8400Fのほうが速かったかもね。300dpiまではほぼ互角かというところだろう。ただCANONには「調光中」問題がある。どの機種でどの頻度発生するのか分からないので、どうもキャノンを敬遠したくなる。
600dpi以上を使うなら別の上位機種の方が早そう。8400Fはもちろん、600dpiだとEPSONでもGT-9400UFのほうがカタログスペックでは速い(600dpiはカタログ上表記されていることが多い)。
まとめ。速度を求めるなら、4k未満で手に入る機種なのでGT-8300UFのコストパフォーマンスは高いと思う。突き詰めたわけではないのでもっと早い機種はあるかもしれないけど、300dpi以下ではこれより格段に速い機種は現行無いだろう。なぜならこのあとの世代(EPSON)が300dpiでは速度面においてはむしろ退化していると思われるからだ。Canonはわからない。8300UFより速いとすれば8400F/8400FVだろう。600dpiに関しては、常用するなら最新機種を含め別のものを検討した方が良いかもしれない。
2006/12/29(金)Aviutlを自動化する
2006/12/29 21:49
今ままではjobsファイルを書くRubyスクリプトを作ってVirtualDubMod(本家と違ってMPEG2が読める)に投げてやらせていたのだが、jobsファイルのちゃんとした仕様が分かってなかった所為かどうも変なaviを作ってしまうことがあった。そしてインターレース解除がやっぱり変だ。ボケボケだし。どうにかしたい。
調べているときにuwscなるソフトを発見。マウス、キーボードの操作や、メニュー操作、ボタンクリックもスクリプトで書けるようだ。これはいい。
ということで、uwscで下のようなスクリプトを書いた。これをRuby+Apolloで作った簡易GUIでループ部分をファイルごとに書いて回すことにする。上手いこと失敗した状態をトラップできるようになればもうちょっと固くなりそう。少し楽になったかな。
※まるものMPEG-2 VIDEO VFAPI Plug-Inを最新のに更新したら、旧VFAPIで発生していた壊れ気味のMPEG2に当たるとエンコードが大破綻する問題が大きく解消されていた。PC-MV5DX/PCIで録画中に負荷かけたりすると、そういうファイルが出来るんだよね。で、フレームがぐちゃぐちゃ、音が全く合ってないファイルが出来ちゃったりしてたんだけど。足を向けて眠れません。あとは是非AC-3対応に(ry
ReadFile = "F:\みんなのうた_02281654.MPG" OutPutFile = "F:\test.avi" ID = Exec("c:\online\aviutl\aviutl.exe") //バッチのクリア ClkItem(ID, "ファイル\バッチ出力") ClkItem(GetID("バッチ出力"), "すべて削除") if GetID("OK") then ClkItem(GetID("AviUtl"), "OK") ClkItem(GetID("バッチ出力"), "閉じる") ////////ここからループ //読み込み ClkItem(ID, "ファイル\開く (Ctrl+O)") SendStr(GetID("ファイルを開く"), ReadFile, 1, TRUE) ClkItem(GetID("ファイルを開く"), "開く") while ClkItem(ID, "ファイル\AVI出力 (Ctrl+S)") <> TRUE Sleep(1) wend SendStr(GetID("名前を付けて保存"), OutPutFile, 1, TRUE) ClkItem(GetID("名前を付けて保存"), "バッチ登録") //同名のファイルが存在したら強制上書き if GetID("はい") then ClkItem(GetID("名前を付けて保存"), "はい") ////////ここまでループ ClkItem(ID, "ファイル\バッチ出力") ClkItem(GetID("バッチ出力"), "開始") Sleep(1) while GetID("バッチ出力") <> -1 Sleep(1) wend Sleep(1) ClkItem(ID, "終了")
2006/07/09(日)Excelのショートカット追加
2006/07/09 21:21
と延々文句を言っていたら、起動時に自動でマクロを読み込むことで対応できるということを知った。
http://park11.wakwak.com/~miko/Excel_Note/14-01_macro.htm#14-01-11
の方法で、personal.xlsを作って、
http://www.excel7.com/personal/personal2.htm
のスクリプトを登録。
特に「セルの結合」が便利。
Excelの起動は遅くなったけど仕方ない。
2006/06/01(木)gigabit LAN
2006/06/01 4:48
しかし、以前はMTUを色々いじったりしたのだが全く速度が出ず(88Mbpsくらい?)結局諦めてしまっていたのだった。
今回改めて再チャレンジ。構成は2台だけなので直結設定。最近はNIC直結ですらクロス・ストレートを考えなくて良いので楽だね。
さて結論から言ってしまえば
(1)ドライバをアップデートして(1.29 -> 1.44)
(2)ドライバプロパティでJUMBOFRAMEだけONにし、
(3)MTUの設定を飛ばしたら
速度がアップした! ドライバかあ……
今のところWindows間のファイル転送で827MBが36秒で転送できるようになったので、193Mbps相当出ている計算になる。gigabitはどうしても200~300Mbpsに壁があり(というかデバイスやバスの転送域を超える)あんまり躍起になって詰めるのもバカバカしい。これなら精神的には十分(100Mbpsの3倍程度)なので今回はここで終了。MTUは設定値次第で遅くなるということも実体験したし、最適設定は難しそうだ。
そうそうVIAにはgigacheckなるケーブル品質を測定できるソフトがある。これはなかなか面白いかも知れない。
あとはハブの消費電力とNICの消費電力を考慮して、gigaHUBを導入するかどうか。鯖がどうせ100Mbpsで必要十分なので当面gigaデバイスが増えない気がするんだよな……
ヤフオクでCG-SW08GTV2が安値で出ててジュルジュル。あー相場より3k安い。迷う。
2006/05/23(火)スキャナ
2006/05/22 25:17
こちらが知りたいのはなんといってもスキャン速度なのだが、最近のは複合機かフィルムスキャンかどちらかにシフトしてしまっていて、EPSONのカタログなんかプレビュー時間さえ書いてない。
おそらく今一番早いのは、canoscan 8400FV。
プレビューで2秒、多分全般今使ってるGT-8700よりも2倍強速そうだ。
まあ20kもするので、調べただけで終了。
あとA3で、Mustek ScanExpress A3ってのが30k弱で買えるらしい。まあ安いなりにトラップがあって、カラーで解像度を上げるととんでもない時間がかかって、使い物にならないらしいけどね……
http://www.canon-sales.co.jp/canoscan/lineup/8400fv/spec.html
http://www.j-deal.com/wts/goods_html/D0430.html
2006/05/19(金)日本語CDDB
2006/05/18 27:23
まあ、こっちに無ければ登録するって方向でいいと思うんですけどもね。
http://freedbtest.dyndns.org/
こういうのもあった。
http://nt.sakura.ne.jp/~uirow/product/cddb_server/index.html
2006/05/18(木)HPのプリンタのドライバがインストールできない
2006/05/18 19:28
要はここの問題と同じようだが、
http://h10025.www1.hp.com/ewfrf/wc/document?lc=ja&cc=jp&dest_page=product&tool=product&dlc=ja&product=71896&docname=c00080687
調べてみたらフォルダ名のフルパスに日本語が含まれているとダメで、アカウントそのものとは無関係のようだ。
分かってるなら直せばいいのに…… ブツブツ
2006/05/06(土)TortoiseSVNのメニューが春Mで表示できない
2006/05/06 15:51
http://tortoisesvn.sourceforge.net/node/102
OwnerDrawの絡みで表示が消えるということらしい。エクスプローラだと正常だということになかなか思い当たらなくて探すのに苦労した。
アイコンがWindows標準のサイズでいいなら以下の解決策が有効。
HKCU\Software\TortoiseSVN\OwnerdrawnMenusをDWORDで作成し、値を0にする。
ふう、表示されるようになったやれやれ。
2006/03/28(火)Memo移行
2006/03/27 26:34
変更の理由としては、華式のバグが使えば使うほどボロボロ出てくることや速度など色々。作者が1人で他に使用ユーザが少ないことも一因ではある。機能の豊富さに関しては非常に優秀なCGIであったのだが……
最後にメモ替わりに華式に関して気づいたバグ・不満点等
- 検索が全体に適応されない
- リファが大量にあると個別記事のレイアウトが崩れる
- 非公開の記事が非公開になってないことがある
- リファのリンクが別の記事に飛ぶ
- テンプレートの仕様がちょくちょくかわる
Serene Bachのいいところは
- 比較的軽い
- 動的・静的のどちらにも対応可
- テンプレート・プラグインの仕様がある程度明確
- Wiki記法対応
欠点もある
- アクセス解析が何かおかしい(カウントされてない?)
- Serene Bachへの移行が結構たいへん(だった)
- プレビューがない
- 各記事に編集ボタンを付けられない(記事の修正が面倒)
Serene Bachへも腰掛けになる可能性があるが、1年位はこれでいってみるつもり。
2006/02/27(月)Neroのファイル名文字種制限と、ボリュームラベル制限について調査
2006/02/27 19:00
調査対象バージョンは、Nero Burning ROM 7.0.5.4。
ボリュームラベル入力欄に、
12345678901234567890
と入力し、
ABC!#$%&',; ()=^-[]`+.test
という名前の、怪しいファイル名を付けた1ファイル(中身はテキスト)を焼いてみてテスト。Win32においては、,(カンマ)と;(セミコロン)が大分怪しい(MS的には付けるべきでないファイル名だが普通に付けられる)。
設定によって多少結果が変わったので、以下メモ。
●CD-ROM(ISO)で焼いた場合(jolietファイル名にセミコロンを許可オプションにチェックしない)
・ファイル名は;が_に変更される
・ボリュームラベルは"1234567890123456"となる
●CD-ROM(ISO)で焼いた場合(jolietファイル名にセミコロンを許可オプションにチェック)
・セミコロン(;)以降の文字列がファイル名として認識されない(ファイル名がABC!#$%&',に化けた)
・ボリュームラベルは"1234567890123456"となる
●CD-ROM(UDF)で焼いた場合
・ファイル名は元のまま
・ボリュームラベル入力欄に"123456789012345"までしか入力できない。またなぜかボリュームラベルをひとたび保存すると、"1234567・_"などと8文字目以降が文字化けるので、焼き込み直前の最終チェックが必要。
●CD-ROM(UDF/ISO)で焼いた場合(jolietファイル名にセミコロンを許可オプションにチェックしない)
・ファイル名は;が_に変更される
・ボリュームラベルは"123456789012345"となる
●CD-ROM(UDF/ISO)で焼いた場合(jolietファイル名にセミコロンを許可オプションにチェック)
・ファイル名は元のまま
・ボリュームラベルは"123456789012345"となる
結論として汎用性が最も高いのはセミコロンを許可した上でのUDF/ISOとなった。CD-ROM(ISO)でも大して変わらないのだが、セミコロンを含むファイルがほとんど無いことをさっ引いても、ファイル名が自動的に削られ(たように見え)るのは腹立たしい。というか不安。
Neroではボリュームラベルは半角全角問わず16文字までという仕様。ただUDFとUDF/ISOの場合は、なんでISOより1文字余計に切られるんだろう??? UDFはボリュームラベル文字化けが不安。確認を怠ると頻発する羽目になる。なお、これらのフォーマット設定による現象はDVDでもCDでもほぼ同じ結果になった。
セミコロンを許可オプションの有無に対するファイル名の検査と変更は単にファイルをウェルにD&Dした時に行われる。従ってD&D後にオプションを変更してもウェル上のデータには反映されないようだ。微妙な仕様。この変更が行われるのはISOもしくはUDF/ISO時のみで、UDF時はオプションに関わらずファイル名の変更は行われない。
ちなみにAplix WinCDR9.0.2だと、
・;と,は書き込み時に変更を要求される(絶対に書き込めない)
・ボリュームラベルは32byteまで(上記の例だと"1234567890123456")となる
さて、以前は日本語ボリュームラベルといえばWinCDRだったが、ついにNeroも追いついてきたようだ。とはいえボリュームラベルはまだWinCDRの方が自由度が高い。全角では1文字差があるかないかだが、半角だとNeroが16文字でWinCDRが32byteだから大分差がある。