ごまめの遠足。

旧メインPC高速化のこと

どうせゲーム専用機なので、読み込み高速化とファンの数を減らすために、SSDの導入を検討するが、2004とFSXを合わせて30GBを超えた(汗)。

同じPCに再セットアップするのに、アクティベーション通ってから昔のディレクトリを上書きコピーという強引な方法でアドオンデータの復元をやっているせいで、あるいはゴミファイルを雪ダルマ式に巻き込んでいる可能性も考えられる。といっても、少々削ったところでFS GLOBALが2004/FSXあわせて30GB居座っているので、他のゲームをインストールするまでもなく、64GBに全部収まるとは思えない。

さすがの私も、メインPCでもないPCに100GB超のSSDは(経済的に)二の足を踏むものであり、それに見合ったうまみを見つけるために、SSDでエクスペリエンスインデックスがどこまで上がるのか調べてみたところ、HDDはどう頑張っても5.9どまりという記事をたくさん発見する。うちのエクスペリエンスインデックスが、まさにHDDが足を引っ張っての5.9なのだ。

一次資料(MS社の公式のアナウンス)にたどり着いていないので100%とは言えないが、これだけ並ぶと正しいようだ。ということは、うちのHDDもリミッタがなければ6とか7とか叩き出しているのかもしれない!? と考えると、逆にSSDを買う気が失せた(笑)。

ひとまず他のゲームもひととおり試した後で、明らかにディスクアクセスのせいで遅いことが判明すれば考えることにする。私としては、ロード時に待たされるのはまだ我慢できるが、飛んでいるときにデータを読みに行って一瞬停まるのが回避できるのなら、SSD化の値打ちはあると考えるものである。

2011/07/20 23:35 | カテゴリー：FSX, Windows, ゲーム, 計算機とか | コメント（0）

TVrock v. J:COM というか単にヤブヘビ

結論から言うと、素人はTVrockのチャンネル名には手を出すべきではない。もっとも、TVrockを使っている時点で、素人ではありえないような気もするけど(笑)。

地デジ化工事の結果、チャンネル構成が変わった。具体的にはNHK-G大阪が入らず(これは京都局が安定して入れば全く文句はない)、TVOとケーブル局(J:COM)独自放送が入るようになる。

この機会に、NHKBSのチャンネルが変わったのに何もしてこなかったのも含めて、TVrock/TVtestの再設定を行う。

とりあえず、チャンネルエディタにて、新称「NHKBSプレミアム」がRockバーでやたら鬱陶しいので半角に、ついでに他の英数字も半角に統一しようと思ったら、局によってすんなり半角化したり、なぜか全角のまま言うこと聞いてくれなかったりして往生する。半角全角混ざったまま手も足も出ないぐらいなら、全部全角の方がまだマシであろう。

いろいろ試して、既存の全角チャンネル名をチャンネルエディタで削除→半角名を追加、という手順をいっぺんにやると無効になる(同じチャンネル名とみなされる?)らしいことはわかった。ここは、削除して一旦抜ける→Rockバーからチャンネル名が消えたのを確認してから→再びチャンネルエディタで半角のチャンネル名を追加、という手順を踏む必要がある。

念のため、TVtest側も同じチャンネル名にして、そのサービスNo.をTVrockのセットアップで設定してみたが、とりあえずJ:COM以外は、番組情報が取得できるし、TVrockから目的のチャンネルに変えることもできてめでたい。

TVtestや37Z1ではJ:COMだろうと番組表が出るので、なんでTVrockだけ!?と思いつつ、まあJ:COMに番組情報は特に要らんかとか思っていたら、TVrockのワークディレクトリを整理しているうちに、各チャンネルの番組情報が、そのチャンネル名と同じファイル名で保存されていることがわかった。全角のファイル名については、タイムスタンプが更新されていないのを確認して消去しているうちに、ファイル名"J"で、サイズ零のファイルを発見。思うに、J:COM.???なるファイルを作ろうとして、DOS系のファイル名としてNGな文字が含まれていたためにコケたというところであろう。チャンネル名がそのままDOSファイル名になることを想像できない限り、回避できない落とし穴である。

原因がそうであれば、回避策はいろいろ考えられるが、今回はチャンネル名を"J_COM"とする策を採用した。

今回は、まあTVrockが最低限の対策をしてくれていた(さもなければ『ドライブJ』にファイルを書きにいっていた可能性が高い)おかげで事なきを得たが、チャンネル名がXSSになりうるという事象にちょっとびっくり。ということは、(手口としてはあまりにもコストフルなので書いても問題ないと思うが)TV局を立ち上げてそのチャンネル名を『C:\WINDOWS\…』とかにすると(笑)、脆弱なTVチューナソフトによっては…ということも考えられる!?

あるいは、TVrockやTVtestの初期状態のチャンネル名が全角で統一されているのは、このことを見越してのことなのかもしれない。あともしかしたら、本件はチャンネルエディタの取説に記載済みかもしれない(すみませんまだ見てません)。でもまあ、それならそれで、チャンネルエディタ上でヤバい文字が入力された時点で、警告するなり、適当な文字に置き換えるなりのチェックを追加してもいいような気もする。

2011/06/16 23:57 | カテゴリー：Windows, 計算機とか | コメント（0）

こういう時期に限って

やたらブルースクリーンやらフリーズやらが発生しはじめて、留守録させるのに心許ない状態になってきた。

いろいろ(主にFLV再生関連で)怪しいソフト入れまくったからなぁ。

せっかくDynabookが浮いたので、録画機としてメインPCから独立させようとも思ったが、それだとメインPCでTVが見られなくなるので、結局いろいろインストールする前の状態に戻してみた。

あと、やっぱり元々Windows7に対応してなかったAcrobat9も心配ということで、やっぱりAcrobatXも導入。

本格的に使い始めてわかったが、問題の「全奇数ページ左回転、全偶数ページ右回転」のアクションウィザードって、スキャン直後の文書に対しては高速に行われるらしい。以前とにかく遅いと書いたことは撤回する。

ただし、私の場合、カラーの表紙とモノクロの本文ページを別々にスキャンして結合するのが一般的な手順だが、こういう文書に関しては、回転の処理が手作業より遅いというのは変わらない。個別に回転してから結合すれば速いかもしれないが、手数があまり減らなくなる。

あとiTunesStoreで購入したアルバム中の2曲ほどが、エラー発生してダウンロードできなかったところ、OS復元したやつにiTunesをインストールしたところ、無事にダウンロードできてしまった。どうやら先方のデータではなく、再インストールで解決できる問題だったらしい。失礼しました。

2011/06/06 23:53 | カテゴリー：Windows, 計算機とか | コメント（0）

ScanSnap v. AcrobatX

最近帰宅が遅いのと、自炊にかまけているので、更新のペースが上がらない。

自炊の方も、こないだまで二度手間の嵐だったが、先週あたりからやっと手順が確立できて、作業が軌道に乗りはじめた。

• カラー自動は認識当てにしない
• 解像度はカラー/グレー/白黒ともに『スーパーファイン』で統一
• 自動回転補正は当てにしない
• 自動傾き補正は当てにしない
• 雑誌はカラー/白黒に分けた後で、それぞれカラー300dpi/グレー300dpiで読み込み
• ノベルズや漫画は、時々挟まるカラーページを除いて(結構変色しているため)白黒600dpiで読み込み

…ようするに、原稿種類を見て、ユーザ側ですべてをコントロールしろということ^^;

実は、スキャンした雑誌の中身を確認して、カラーの雑誌が途中から突然グレーになったり、モノクロの記事で途中から突然二値になったりしていたのに愕然としたため、処分前の雑誌をほどいて再度スキャンしてしまった。

滅多に読み返さなければ、サイズが小さい方がいいような気もするが、それでも300dp二値でソースコードを読むのはちょっとしんどい。

あと、表紙カバーの扱いについて、背表紙を切り離したり、切らずにスキャンしてAcrobat上でトリミングしたり、いろいろ試したが、結局『表紙と背表紙の間のみ切る』で落ち着いている。Acrobat上でトリミングしても、切ったデータは実はデータとして残っているため、カバーについては二重持ちになってしまう。

残念なのは、最初期のデータは背表紙を廃棄してしまっていることだが、これは致し方ない。

さて、こうやって切り離したカバーは、折りしろを折ったままスキャナに通すため、どうしても横向きにセットしないと安定しない。また本体については、裁断で油断すると、かなり斜めに切れてしまうため、この場合は裁ち切りの部分を底にしてセットしないと傾く可能性が高い。

もっとも、A5判以下のサイズだと、横向きにセットした方が読み取り時間は短くなるので、最近では表紙カバーとともに横向きで読み込んでいるが、残念なことにScanSnapでは横向き原稿の回転機能がない。『自動回転補正』はあるが、完全には信頼しかねるし、中途半端に誤認識するぐらいなら、Acrobatで『全奇数ページ』と『全偶数ページ』で回転をかける方がよっぽど安心できる。

ここで、最新のAcrobatXでは、アクションウィザードなる、これら一連の作業をプリセットできる機能があるというので、ひとまず体験版を試用してみたが…、この手の処理は苦手と見えて手作業でやる方がよっぽど速いという結果になっている。

メリットがあるとすれば、手数とそれに伴う操作ミスがなくなるぐらい。オフィシャルサイトでは、特定のケースを取り上げて「作業時間が大幅に短縮」などとアピールしているが、自炊に使っている者としては、ページ回転については改善の余地があると思う。

いや待てよ、1ページずつ回転をかけるのに較べたら、確かに作業時間は圧倒的に短いか(笑)。

あと『スキャン文書のサイズが大幅に圧縮』という売りも、よく見たらOCRを使う前提の話みたい。というわけで、AcrobatXの本格導入は、まぁOffice2010を使わざるをえなくなるか、9に超致命的なセキュリティホールが露見して、もうサポートしませんと宣言されるかするまでは見送りか。

ところで、Acrobat9Standardなら最初から持っていたんだけど、Acrobat無しでもうちっと安いモデルは出せなかったもんでしょうか?≫富士通さん

2011/04/27 00:54 | カテゴリー：Windows, ただの日記, 計算機とか | コメント（0）

Windowsサーバのsendmail.exe

職場のWebサーバで運用しているFSWikiの参照の一部が、FirefoxでクリックしたらInternalServerErrorになるという昨日の一件。

参照の一部だけ、さらにFirefoxだけで発生するというのが怪しいが、このサーバってば、リモートでGUIができるという理由でWindowsを走らせているくせに、Web関連ではApache for Win32とか、1行目のパス指定が#!/usr/bin/perlになっているperlスクリプトとか、まあUnixyなコードが入っている。おかげで何かあった時の心当たりが広すぎるのが困りものである。

個人的にはむしろリモートコンソール(SSH)の方が好きなのだが、私の次が引き継いだ時に困るとおっしゃる。トラブルの原因の特定に手間がかかるとか、それ以前にわざわざトラブルが発生しやすい状況を作るのを思えば、いくらGUIでわかりやすくても意味がないと思うけどねえ。

それはともかく、apacheのエラーログ見たら、ヘッダの内容がおかしいと出た。Bad header= =?ISO-2022-JP?B?Zg==?="だと。どういう事情かはよくわからないが、ファイル名を渡す処理のどこかでMIME64に変換しようとして失敗しているらしい。試しにWikiについてきたJcode.pmの該当箇所で、変換を通さずに(EUC-JPの)ファイル名をそのまま返すように細工したら直った。

本来なら、なぜFirefoxの時だけここを通って失敗するのかを調べなければならないところだが、サイト内部でメールを出したりしない限り、MIME64への変換は行われない、とみなして(本当かどうかは知らん)しばらく様子を見る。あとFSWikiは他のホストでも使われているが、それぞれのlibディレクトリの下のJcode.pmを使うはずなので、この意味でも問題ないだろう。というか他のFSWikiはどうして平気なのか!? ひと世代旧いから?

と思ったら、翌日Webサーバからメールが来ない。サードパーティのsendmail.exeでエラーログを私宛に出すスケジュール、ただしエラーログの出ない日はメールを出さない仕掛けにはしているが、昨日あれだけトラブったのでさすがに気付いて、リモートデスクトップを開いたところ、おなじみ「ご迷惑をおかけして申し訳ありません」のダイアログが出てsendmail.exeが停まっている。メールだけにMIME64関連をいじったのを疑ったが、一時的に元に戻しても改善なし。よく考えたら、C:\Perl\binに間借りしているsendmail.exeが、一介の!?ホストのJcode.pmなんか見に行くはずがねえや。

ということで、昨日やったことを思い出しながらテストしたところ、どうやら環境変数PERLLIBにパスをセットしたのが直接の原因らしい。真の原因はよくわからんが、とにかく削除したら回復した。パス自体は間違いなかったはずだが、パス区切りに"/"を使ったのがまずかったのか、あるいはそもそもWindowsではセットしたらいかんかったのかはよくわからない。まあ結果的には、昨日のエラーの心当たりがありすぎて色々無用無益な手を打ったせいということになる。Windows自体が悪いとは言わんが、Unixyなツールが絡むと、恐ろしくメンテナンスコストのかかるサーバになりうるのだ。

2011/01/29 00:32 | カテゴリー：Windows, 計算機とか | コメント（0）