2013/12/29(日)WindowsでUSBデバイスが最後に挿された日付を確認する

2013/12/29 16:53 PC（全般）
あるUSBデバイスが最後にPCに認識された日付を確認する方法。
for Windows7。

以下を参考。
NetAgent Official Blog: USBメモリとレジストリ

手順をまとめると、
  1. そのデバイスのベンダ名、デバイス名を把握する
  2. HKEY_LOCAL_MACHINE\SYSTEM\MountedDevicesからベンダ名、デバイス名で該当デバイスのGUIDを探す(バイナリデータ内にベンダ名、デバイス名が入っているので頑張って探す)。
  3. HKEY_USERS\<ユーザSID>\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2から前項で調べたGUIDを持つキーを探す。
  4. 前項で得たキーのタイムスタンプを調べる。
タイムスタンプの確認にはタイムスタンプを見られるタイプのレジストリエディタを使う。もしくは、Windows標準のレジストリエディターを使用しtxt形式でエクスポートして確認する。

以下を参照。
レジストリ・キーの最終更新日時を調べる－ ＠IT
コメント（0件）

2013/12/28(土)IE8のtable表示バグメモ

2013/12/28 26:41 PC（プログラミング）
かなり以前に書いたメモから起こしてるので、ちょっとおぼろげ。

IE8において、特定の条件下でtableタグのレンダリングに以下の問題が発生する。
問題の内容は、
・表の外枠の上罫線が欠ける
・表の外枠の左罫線が欠ける

先にコードを提示する。
IE8で以下のようなコードをレンダリングすると発生する。
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
<head>
	<title>test</title>
	<style type="text/css">
		table{
			border-collapse: collapse;
		}
		td,th{
			border: solid 1px black;
		}
		div{
			overflow: hidden;
		}
	</style>
</head>
<body>
	<div>
		<table>
			<thead>
			</thead>
			<tbody>
				<tr>
					<td>a</td>
					<td>b</td>
					<td>c</td>
				</tr>
			</tbody>
		</table>
	</div>
</body>
</html>
条件は以下の通り。

・ブラウザ: IE8
・モード: 標準モード
・tableの親divで"overflow: visible"以外を指定
・border: collapse
・空のtheadタグがある

必要十分かどうかは不明。

主たる原因は、空のtheadタグがあるから。
これを消すと罫線が表示される。

バグという表現を使ったが空theadは元々validate通らないので、IE8が必ずしも悪いわけではない。ただし他のブラウザで線が欠けるものは発見できなかった。

空theadを使うなと言えばその通りだが、IE対応かつ表の固定ヘッダ(Excelのような)を作ろうとするとsampleなどにもちょいちょい出て来るコードなので多少留意をしておくこと。
コメント（0件）

2013/12/13(金)fi-6130のTWAINがフォーカスを取るのを抑止する

2013/12/13 16:27 PC（全般）
fi-6130等、Fujitsuのfi系ドキュメントスキャナのTWAINドライバウィンドウが1枚スキャンするごとにフォーカスを持っていってしまう問題。スキャン中他の作業、特に入力作業が出来ない。

とりあえずAPIフックで対処可能。

Windows API Hooking Tutorial

上を参考に、SetForegroundWindowを握りつぶせば良い。

最初単にグローバルフック(SetWindowsHookEx)でどうにかなるような気がしていたのだが、WM_ACTIVEAPPメッセージを握りつぶそうとしてもうまくいかなかった(WM_ACTIVEAPPが飛んできたタイミングは捕まえられる。そこで元のウィンドウにフォーカス移すのはちょと……)。

実のところWindowsのメッセージ機構の理解にあやしいところがあって、キーボード・マウス以外のメッセージにキャンセル機構がないのか、SetWindowsHookEx自体の制限か、それともWM_ACTIVEAPPメッセージは通知だけで、ウィンドウのアクティブ処理自体はエクスプローラ側の触れない領域にあるのかといったあたり判断できてない。C++でWin32ネイティブアプリ書いて、WndProc内であれこれやってみれば結論が出るんだろうけど、今回は時間がないので次回以降の課題。

.NET系でもマウス・キーボードのグローバルフックがかけられることは覚えておこう。

ソース整理できたらそのうち載せたいけども、元コードのライセンスがわからないな……
コメント（0件）

2013/12/13(金)自炊を突き詰めてみた

2013/12/13 15:23 PC（全般）
自炊、いわゆる書籍の自家電子化。

自分が妥協できるやり方で、どれだけ高速化・効率化できるかを突き詰めてみた。

所要時間

突き詰めた結果、こんな感じ。

おおざっぱに、前処理 -> スキャン -> 後処理となり、

前処理: 人力
スキャン: 自動
後処理(操作・目視判定): 人力
後処理(自動): 自動

となる。

ページ数依存の時間

200ページ(背厚おおよそ10mm程度)ごとに、5分(スキャン:4分, 後処理(自動):1分)

冊数依存の時間

1冊ごとに、3～4分(前処理(裁断・タイトル作成):2分, 後処理(操作・目視判定):1分)

その他ミスによって生じるロス時間

ミス1回ごとに、だいたい10分。
(ミスのほとんどは、スキャン時に発生。紙サイズ自動判定のミス、ノリ残りによる給紙ミス、紙質混在による給紙ミスがほとんど)

モデルケース

[a]週刊少年誌2冊 = 50mm = 1000ページ => 5分 * 5 + 3分 * 2 = 31分
[b]薄い本15冊 = 50mm = 1000ページ => 5分 * 5 + 3分 * 15 = 70分

こんな感じ。正直集中力が続かないので(特に冊数が多い場合)、実作業時間はこれに1.2～1.5掛けになるが最大効率だとこの数字になる。

複数の本を対象にまとめて作業すれば、パイプライン化によって前処理とスキャンを同一時間に行うことは可能(ただし、本当にかかりっきりになる)。

方法

自分のやり方をざっと書いておく。

機器構成的には以下のような感じ。
・中国製裁断機(XD-3203A)
・Fujitsu fi-6130
・PC(Core-i5 2500K, 16GB, HDD)

前処理

自炊する対象を決める
最終的にはこれが一番重要。とっとくか、捨てるか、自炊するか即断。
裁断
使用している裁断機(XD-3203A)は精度が低いのでちょっとした工夫・コツがいる。

突き当ての遊びが大きく垂直が出てないので、突き当てをちょっと刃側に寄せて位置合わせをする。

裁断面が斜めにならないように(特に厚い本で斜め切りになりやすい)、紙押さえ下部と紙押さえの接地部にゴムシートなどの滑り止めを貼っておく(参考: 漫画をスキャナで電子書籍化する初心者向け自炊解説サイト 裁断機で斜めに切断・切れないようにする解決方法)。紙押さえを強く押し下げたあと、ちょっと緩めて押し下げるを何度か繰り返す。さらに裁断時にも左手で紙押さえを押し下げながら裁断する。

ここまでやってもほどほどの精度なので、裁断機は良いもの(自炊裁断機200DXなど)を使った方がよい。
チェック
裁断した束を、スキャナまで移動する間に、以下のことをチェックする。
[1]特殊サイズ・特殊紙がないか
[2]くっついているページがないか(特にカラーページ・表紙の周り)
[3]ノリが大きく残っていないか

[1]に該当する場合、スキャナに通るかどうか考える。通らないのであれば追加で裁断をするか、フラットベッドで取り込むか、スキャンを諦めるか決める。

[2][3]に該当する場合、剥がして手当てする。
タイトル作成
本タイトルor誌名、お好みで著者・サークル名・出版社・出版年・ジャンルなどをテキストエディタで作成する。

出版された書籍のみを扱うのであれば、バーコード読み込みからタイトルを自動生成するスクリプトなどを生めば効率が上がるかも知れない。

ただし、amazon DBはかなりの表記揺れがあるため、シリーズでタイトル揃えるといった要望を満たせないかも。古い本ではバーコードがなかったり、JANコードがDBになかったりということもある。amazonを万能とは考えないこと。

私は秀丸で、項目(ジャンル, 著者, タイトル)をタブ区切りにしたファイルを作り、マクロでクリップボードへコピーまでやっている。
//一般的な書籍タイトル名を生成するマクロ
movetolineno 1, 3;
deleteline;
movetolineno 1, 2;
beginlinesel;
copy;
paste;
//著者名有り
replacedown "([^\\t]+)\\t([^\\t]+)\\t([^\\t]+)\\t([^\\t]+)", "(\\1) [\\2 (\\3)] \\4", regular;
if(result == 0){
	//著者名無し
	replacedown "([^\\t]+)\\t([^\\t]+)\\t\\t([^\\t]+)", "(\\1) [\\2] \\3", regular;
}
if(result == 0){
	//団体名・著者名無し
	replacedown "([^\\t]+)\\t\\t\\t([^\\t]+)", "(\\1) \\2", regular;
}
movetolineno 1, 3;
beginlinesel;
copy;
これを、以前のBTScanTool(AutoIt!でBTScanをちょっと改良 - 色々日記（ざ・めも）)にCtrl+A, Ctrl+Vして、フォルダ名をBTScanにセットする。

BTScanの入力開始ボタンを押下して、フォルダを作成。

スキャン

fi-6130の給紙枚数はだいたい10mmくらいまでなのでそれくらいごとにスキャナに通す。
このとき、摩擦が少ない紙(カラーページなど)はセット時の束中で一番最後に取り込むように区切るとミスが少ない。fi-6130の給紙能力は素晴らしく優秀だが、紙質混在原稿ではミスをすることがあり、摩擦が大きいページを先に吸ってしまうことがある。

原稿をさばいて、先に給紙するものほど奥に入るように若干斜めにセットする方がミスが少ないのはプリンタと同じ。

スキャナが止まってから束に割ると効率が落ちるため、作業スペースを確保して先に全部束に割ってしまう方がいい。少なくとも次にセットする束は準備しておくと効率がよい。

スキャンは、BTScan + fi-6130(TWAIN)で行う。

基本的に全て両面、300dpi, カラー, bmp, 自動用紙サイズ検出、4桁1始まり連番でスキャン。

特殊紙は都度単体でスキャン。

自動用紙サイズ検出に失敗したケースでは、黒背景でB5,A4等の規定サイズでスキャン。

コミック等表紙については、長尺で取り込めるものについては横向き長尺でスキャン。

現状、BTScan以上に優秀なソフトがないのだが、BTScanはプロファイルを自動更新してしまうなど使い勝手が悪い。スキャンパートは実時間依存大であり、手戻りが多大なロスになるため極力どんな本でも同じ設定で出来るようにすること。BTScanのプロファイルは信用しないこと。

なお、fi-6130含むfi系のTWAINドライバは1枚スキャンするごとにフォーカスを持って行く。これだとスキャン中は他の作業が出来ないため結構きつい。APIフックで何とかする方法はあるのでfi-6130のTWAINがフォーカスを取るのを抑止する - 色々日記（ざ・めも）を参照。

後処理

自作スクリプトとZoner Photo Studio 15, RalphaPlus, SpringM等を駆使する。
サイズ取得
スキャンしたフォルダで自作Rubyスクリプトを実行し、最小サイズと全体のずれを取得する。
$KCODE = "Shift-JIS"

require "rubygems"
require "image_size"
require 'win32/clipboard'

max_width = 0
min_width = 99999
max_height = 0
min_height = 99999

Dir.glob("*.bmp"){ |f|
	open(f, "rb"){ |fp|
		img = ImageSize.new(fp.read)
		
		if max_width < img.width then
			max_width = img.width
		end
		
		if max_height < img.height then
			max_height = img.height
		end
		
		if min_width > img.width then
			min_width = img.width
		end
		
		if min_height > img.height then
			min_height = img.height
		end
		
	}
}

width_diff = ((max_width.to_f-min_width)/max_width*10000).round.to_f/100
height_diff = ((max_height.to_f-min_height)/max_height*10000).round.to_f/100

param = "W/2-#min_width/2,H/2-#min_height/2,#min_width,#min_height\n"

output = ""
output += "w:#min_width-#max_width #width_diff%ずれ\n"
output += "h:#min_height-#max_height #height_diff%ずれ\n"
output += "\n"
output += param

open("c:\\**documents**\\ralpha_trimming_param\\ralpha_trimming_param.txt", "w"){ |wp|
	wp.write output
}

Win32::Clipboard.set_data(param)

IO.popen "c:\\**program**\\hidemaru\\hidemaru.exe c:\\**document**\\ralpha_trimming_param\\ralpha_trimming_param.txt"
適当に書いたのでメチャクチャ。実行すると、秀丸が立ち上がってこんなのが出る。
w:1642-1658 0.97%ずれ
h:2041-2045 0.2%ずれ

W/2-821,H/2-1020,1642,2041
プロンプトでやると閉じ忘れたときに一手間増えるので敢えて秀丸に出力する(スキャンフォルダを削除するときに「使用しているアプリケーションがあるため～」となる)。

最後の1行はRalphaPlusに投げるためのパラメータ。自動的にクリップボードにコピーされている。

ずれが2%を超えているケースは、スキャン時に何かが起こっている可能性が高いので見直しをかける。
目視チェック
サイズ取得と並行して、Zoner Photo Studio 15を立ち上げる。Zoner Photo Studioは起動ディレクトリを指定できないので、AutoIt!で起動ディレクトリを渡してやる。
$Title = "Zoner Photo Studio 15 FREE"

Run("C:\\**program**\\Zoner\\Photo Studio 15\\Program64\\Zps.exe")
WinWaitActive($Title)

WinActivate ( $Title )

ControlClick ( $Title, "", 100 )

ClipPut($CmdLine[1])
Send("^VENTER")
このAutoIt!のスクリプトにディレクトリ名を引数として渡してやると、Zonerを立ち上げたあとにそのディレクトリに移動してくれる。

ここで、カラーページを選択しRalphaPlusにD&D。Zoner上にいったん戻り、次の作業のためにCtrl+Iして選択を反転。
bmp->jpg(カラー)
ここから先はRalphaPlusでの処理。

プロファイルをカラーに切り替え、トリミングのパラメータに"X座標、Y座標、幅、高さ(px)"指定でクリップボードのデータをCtrl+Vする。

カラープロファイルでやっているのは
・レベル補正
・トリミング
・リサイズ
・アンシャープマスク
・ノイズ除去

F5で実行。Ctrl+Delでクリア。
bmp->jpg(モノクロ)
再度、Zonerに戻って現在選択されているファイルをもう一度RalphaPlusにD&D。

プロファイルをモノクロに切り替え、トリミングのパラメータに"X座標、Y座標、幅、高さ(px)"指定でクリップボードのデータをCtrl+Vする。

モノクロプロファイルでやっているのは
・グレースケール化
・レベル補正
・トリミング
・リサイズ
・アンシャープマスク
・ノイズ除去

適当なページを選んで、レベル補正のみ確認する。
裏移りが極端に酷い場合、若干白飛ばしを強めにする。
薄いグレースケール・トーン飛びが酷い場合、若干白飛ばしを弱めにする。

F5で実行。
bmp移動
現時点で、スキャンフォルダにbmpとjpgが混在しているため整理する。
スキャンフォルダで、backフォルダを作成しbmpファイルをそこに移動するスクリプトを実行。
$BACKUP_DIRNAME = "back"

if not File.exist?($BACKUP_DIRNAME) then
	Dir.mkdir($BACKUP_DIRNAME)
end

Dir.glob("*.bmp"){ |file|
	File.rename(file, "back/" + file)
}
チェック
Mangameeya等のビューアでざっと後処理したjpgをチェックする。
削除
チェックして問題無ければ、bmpの入ったbackフォルダを削除。
圧縮
Zoner等がまだひらいていれば閉じる
WinRARにスキャンフォルダをD&Dして無圧縮・リカバリレコード付きで圧縮する。

これにて完了。

今後の高速化

スキャンデータストレージとしてHDDをRAMディスク or SSDに変更

　スキャン周り・後処理について高速化が期待できる。
　RAMディスクの場合、今のやり方ではまとめて作業すると簡単に使い切ってしまうのと後続作業を後日に回したいときがネックか。
　SSDは効用次第だが、このためだけに導入するのは疑問。

BTScanの上位互換ツールの発見 or 開発

　BTScanがもうちょっと使い勝手が良ければ、スキャン時に特殊紙・カラーを選り分ける、jpegでスキャンするなどをした方が効率が上がる可能性がある。現状のBTScanでこれをやると、プロファイル仕様の問題でどうしてもミスが増える。

可読性を多少犠牲にする

　モノクロとカラーで後処理を分けているが、これを一本化すればかなり人力判定・操作コストが減る。ただし、モノクロページはやはりグレスケ化した方が綺麗ではあるのでどこまで割り切るか。

機器の更新

　CPUについては、高速化すれば当然後処理が多少早くなる。とはいえ抜本的な改善はintel CPUでは2015年のSkylake待ちである。AMD GPGPUが進めば面白いが…？
　ドキュメントスキャナについては、fi-6130でも既に準業務機という位置づけなのでこれより早いスキャナはなかなか手に入るような価格では出てこないとは思うが、なにがしか技術革新があるかも知れない。
　裁断機については、ダーレ200DX等に変えることで(裁断可能厚そのものは減少するが)、垂直性や斜め切りが改善できるならば結果的に効率化できる可能性がある。

総括

自炊は時間と空間のトレードである。

使われる時間はなんら生産的でも文化的でもないため、とにかく辛い。人には絶対勧めない。入手性が高い本であれば手放してまた読みたいときに買い直すも良し、電子版があるならそれを買うも良し。

トレード対象になる時間を鑑みて、本当にその価値があるか考えるようにしたい。特にコミックには手を出さない方が無難。20分で読める本の自炊に最速8分かかるということを肝に銘じる必要がある。解像度が低かろうが、カバー裏が収録されて無かろうが、Kindleがあればもうそれでいいじゃない。amazon万歳。

赤松先生が以前提唱していた、電子化されてない本をアップしたら、版権取りと電子書籍販売まで代行してくれるサービスがあったらいいのに……
コメント（0件）

2013/11/29(金)エディタ界隈

2013/11/29 22:22 PC（プログラミング）
久々に日本語テキストエディタをさらったので雑なメモだけ。

サクラエディタから乗り換え先を探すイメージで、出来れば機能包含＋軽い＋ライセンス緩いというのがよい。

まっとうな比較は
比較 - テキストエディタ・スクリーンショット Wiki*
を見てもらうとして。

自分として乗り換えられそうな使用感を得た物だけメモしておく。
フォント周りを調べたときの副産物なのでそこら辺も。

・WZ EDITOR
シェア。ちゃんと進化してた。保有機能はすごいが、インターフェースがちょっと雑然としている。明らかに一太郎になろうとしてるっぽい。フォントを文字コードごとにかなり細かく指定できる。VerUPごとに買うのはちょっと微妙。

・秀丸
シェア。ちゃんと進化してた。高機能だし、うまいことトレンドにシフトしてるとは思うのだが、ほんのちょっとが足りない感じはする。とはいえ最有力。DirectWrite対応でかなり調整できる。複数行正規表現もかなり健康。

・newQX
まさかのQXが新生。さらにまさかの高機能。見た目やI/Fは古臭い。サクラや秀丸のいいところを敢えて無視してる感じ。地味にASCIIだけフォント切り替えにも対応。

・xyzzy
生き残ってた。案外なんでも出来る。オプションが分かりづらい！(笑) Emacsの練習とかによい。地味にASCIIだけフォント切り替えにも対応。

・otbedit
複数行正規表現に強くてフリー。

・Epsaly
・Mery
今後に期待が持てる。

・Sublime Text
新進気鋭がついに3まできた。日本語入力インラインにならないのかな？

・Vim
慣れれば。

・NtEmacs
慣れれば。xyzzyでいいかも。

総合的には秀丸が最右翼。

秀丸がかなり進化しており、サクラの進化が止まってるのでシェアウェア分くらいの差は付いたかも知れない。

WZ EDITORは購入をためらわせる何かがある。整理されてないコンフィグ周りとあのインターフェース、そして何か…　方向性が違う。他と違うI/Fにしてる理由が、改善じゃなくて単に違うことをしたいだけのような……

OtbEditはサクラから乗り換えるのに必要十分な機能を持っている。が、乗り換えるに足る明確な動機がない。

newQXはさすがにインターフェースが古いか。機能面については十分な方向に行きそうだが、もうちょっとインターフェースを何とかして欲しい。

全ての開発・書き物を一本でやれるならVim, Emacsもアリだと思うのだが実際そうではないので慣らすモチベーションが出ない。IDE使ってるし。

ということで、秀丸買うか。

ここに挙がったソフトの動向はある程度注視しつつ併用で。非秀丸ならサクラかOTbEditかxyzzyをその時の気分・用途で。WZは特に秀丸になくWZにある機能が出てきたときにだけ考える。

Vimなー、出来ることと出来ないことを誰かに全部リストアップしてもらえると気軽に移行できるんだけどなあ。
コメント（0件）

2013/11/29(金)2013年後半のプログラミングフォント事情

2013/11/29 17:05 PC（プログラミング）
以前(4～7年前？)調べたときとだいぶ状況が変わってるようなので久々にさらってみた。

前提はWindows7 64bit、WUXGA(1920x1200)モニタ環境。

日本語入力有りという使用方法を考える。

■結論
以前の調査では、
・IPAフォント類ではJISカバー率が低すぎて無理(これは誤認だった？)
・悔しいけどMSゴシックは悪くない
・とりあえずこだわるならOsakaとか？

うろ覚えだがこんな結論だった。

で、先に今回の結論を書くと、
「よくわからないのでMSゴシックを使おう」

はい、そこ物を投げない。

もうちょっと詳しく書くと、

●gdipp, MacType環境下なら → Ricty
●ClearType(DirectWrite)環境下で、
・ライセンスが怪しくても良いなら → Consolas + MeiryoKE Console(フォント合成)
・それがダメなら → Migu 1M(好みでMigMix 1M, VLゴシック)
●標準アンチエイリアス環境下で、
・記号類が半角表示でも良いなら → Consolas + (MSゴシック or MeiryoKE)(FontLink)
・ライセンスが怪しくても良いなら → MeiryoKEゴシック or MeiryoKE Console
・どれもダメなら → MSゴシック

以下調査。

■レンダリング周り
Windows環境では厄介なことにフォント選びよりもレンダリング環境を先に考える必要がある。
大きく分けて3つ。まあ想像通り一長一短あるわけで。

●標準アンチエイリアス
Windows標準機能。
コントロールパネル -> ディスプレイ -> ClearTypeテキストの調整。
チェックボックスをOFF。

[メリット]
・標準

[デメリット]
・アルゴリズムが悪いのか、ビットマップフォント以外はかなりぼけやすい。視認性が悪い。

●ClearType(DirectWrite)
Windows標準機能。
コントロールパネル -> ディスプレイ -> ClearTypeテキストの調整。
チェックボックスをON。

もしくはDirectWriteを実装したアプリケーションを使う。

[メリット]
・標準アンチエイリアスより視認性が向上することが多い。
・DirectWriteは実装によってはかなり調整可能(秀丸, FireFoxなど)

[デメリット]
・ClearType Tunerの調整範囲ではgdipp, MacTypeより劣る
・標準ClearTypeはサブピクセル描画による偽色をかなり盛るため、背景色によっては目立つ・衝突する
・上記により目が疲れやすくなる可能性あり
・標準ClearTypeは縦方向にアンチエイリアスをかけないため、横線が多い文字(漢字とかだよ！)で恩恵が薄い。

●gdipp, MacType
いわゆるgdi乗っ取り系。

[メリット]
・OS全体に影響
・調整次第だがClearType系よりも綺麗？

[デメリット]
・アプリケーション(独自レンダリングを持つ)によっては反映されない
・アプリケーション(古いゲーム等)によっては文字描画が壊れる
・一部、標準アンチエイリアス環境下で視認性が高かったフォントがかえって悪化する可能性がある
・乗っ取り系なのでおそらくリソースを食う
・gdippはカスタマイズ性低い
・MacTypeはgdippよりカスタマイズ性が高いが、インストーラがadwareだし中国製で英語になりきれてないところがある

[参考]
フォントスムージングの比較 - かえでのWebログ


■フォント
フォントの話に移る。

●欧文
まず、欧文フォントでもっとも趣味に合うのはConsolasだ。視認性が高く、0がslashed、小サイズでも読みやすい。ほとんどの文字で見分けが付く。若干l(半角エル)と1(いち)の見分けがあやしいが、許容範囲内。標準アンチエイリアス下でも高い視認性を誇る。

よってConsolasを軸にする。

Consolasライクな欧文フォントを探すと、
・Consolasオマージュでラインセンスが緩いInconsolata
・#が低いGoogle製Anonymous Pro
・MacのMenlo
・MenloライクなMeslo LG M

あたりを見つけた。ただし、MenloはWindowsに入れようがないので除外。

What are the best programming fonts? - Slant
Top 10 Programming Fonts

これらは日本語フォントとどうにかしてくっつけないといけない。

●日本語
またこれに近い欧文を備えるなり組み込んだりした日本語フォントとして、以下の物を見つけた。
・Ricty
プログラミング用フォント Ricty
・MigMix 1M, Migu 1M
M+とIPAの合成フォント
・VLゴシック
VL Gothic Font Family

M+に不足部分を補う物がトレンド。M+すごい。

最後にライセンスがあやしいメイリオ改造手段と、
MeiryoKe
Windows で見やすくて綺麗なフォント表示 ? MeiryoKe に変更し、MacType で滑らかにする | すぐに忘れる脳みそのためのメモ

さらにそれにConsolasを合成しちまえというもの。もうここら辺はライセンス的にはかなり怪しい。
MeiryoKe_ConsoleとConsolasの合成方法 - GONE WITH THE MEDICINE

●ライセンス
ライセンスを確認する。

欧文ではライセンスが緩い(改造・合成が出来る)のが、Inconsolata, Anonymous Pro, Meslo LG M。詳細は各Webを確認。

日本語系ではM+がまだ字体が足りてないためIPAで補完している物が多く、だいたいがIPAのライセンスに依存。

●欧文フォントの合成方法
欧文フォントはどうにかして日本語とくっつける必要がある。

フォント自体を合成して新しい一つのフォントを作る方法と、WindowsのFontlink機能を使う方法がある。またもや一長一短。

○合成
FontForge
unofficial fontforge-cygwin
等を使用する。

ASCII部(U+0021～U+007e)をはめ込むだけならさして難しくない。が、フォントの特性を理解し、綺麗に、違和感なく仕上げるのは難しい。ビットマップ絡むとさらに難解。先に上げたMeiryoKe + Consolasの合成方法なんかを参照。

合成する方はフォントのライセンスに注意。基本的にOS付属の物はたぶんライセンス×。

○FontLink
FontLinkについては
Windows 7 で日本語フォントを Segoe UI に合わせて調整
FontLink SystemLink の設定値の数字について

を参照。

レジストリをいじって、対象フォントに参照のない文字はリレー方式で次のフォントを見に行くようにする。

結果を確認するのにいちいちOSの再起動が必要。すごくめんどくさい。

Consolasなどの欧文フォントではU+25CF("●")等一部の記号が含まれている。このため、記号等で欧文フォントで描画される物と日本語フォントで描画されるものがあり表示がイマイチになる。"●"は半角、"◎"は全角とか言うことになりかねない。

●評価
自分の評価が高い順に挙げていく。
ただし、どうしても環境依存。
書体記号類一部欧文gdipp/MacTypeClearType標準アンチエイリアスライセンス
Ricty◎○○△×○
Consolas + MeiryoKE Console(フォント合成)○(合成によるズレ)○○○△×
Migu 1M(好みでMigMix 1M, VLゴシック)○○○○△○
Consolas + (MSゴシック or MeiryoKE)(FontLink)◎×○○○○(MSゴシック) ×(MeiryoKE)
MeiryoKEゴシック or MeiryoKE Console△○○○○×
MSゴシック△○○○◎○
○Ricty
ConsolasオマージュのInconsolata + Migu 1Mという理想型。
書体そのものは可読性が高く決定版とも言えるようなフォントだが……

実質、gdipp or MacType必須。

Inconsolata自体が標準アンチエイリアス環境下ではアンチエイリアスが強く出てしまう書体のため、Rictyもそれを引き継いでボケボケ・欠け欠けでかなり厳しい。

標準ClearType環境下でもちょっと厳しい。DirectWriteなら調整によっては。

gdipp, MacTypeはデメリットがいくつかあり、これに踏み切れない場合は別のフォントを考える必要がある。

○Consolas + MeiryoKE Console(フォント合成)
gdipp, MacTypeでなくともClearType系で十分な視認性を得る。
しかし、二重にライセンスがあやしい。

さらに、合成のやり方次第だが、
・文字の水平位置ずれが生じる
・Consolasが持っていた標準アンチエイリアス下での視認性を失う
等の問題がある。

ライセンスあやしいのはダメという場合、別のフォントを考える必要がある。

○Migu 1M(好みでMigMix 1M, VLゴシック)
gdipp, MacTypeでなくともClearType系で十分な視認性を得る。

Consolasよりは欧文書体が好みではない("*"が浮く)。

標準アンチエイリアス下ではアンチエイリアスが強く出てボケボケになる。

ClearTypeの描画が気に入らない場合、別のフォントを考える必要がある。

○Consolas + (MSゴシック or MeiryoKE)(FontLink)
Consolas部はビットマップでないはずだが、標準アンチエイリアス下で高い視認性を得る。MSゴシック, MeiryoKEは好み次第。MeiryoKEはゴシックでもConsoleでも。当然ライセンスあやしいのがダメならMSゴシック。

ちなみにMeiryoKEをリンクする場合は横長になる問題が知られている。レジストリの値を好みで、
"meiryoKe_602r1.ttc,MeiryoKe_Console,128,85"
や
"meiryoKe_602r1.ttc,MeiryoKe_Console,128,100"
などとして、比率を調整した方が良さそうだ。

一部の記号類(ex.U+25CF("●"))がConsolas側に含まれるため半角描画される。この際の挙動はソフトによって違いキャレットの移動も半角に成るケース・全角になるケースと様々。

これが許容できない場合、別のフォントを考える必要がある。

○MeiryoKEゴシック or MeiryoKE Console
標準アンチエイリアス下で高い視認性を得る。

0にスラッシュもドットも入っていないので、Oと見分けが付きづらい。

ライセンスあやしいのはダメという場合、別のフォントを考える必要がある。

○MSゴシック
最後に行き着いたのはやはりここ。
標準アンチエイリアス下で高い視認性を……　得る。

ビットマップを大量に持っているのが強く、やはり100dpi程度までのモニタだとビットマップフォントが光る場面はある。漢字類の罫線の太さの調整はさすが謹製といったあたり。

○おまけ
アプリケーション上でASCII部とそれ以外でフォントを変えられるものがあればそれを使うとよい。Consolas+MeiryoKE(MSゴシック)で幸せになれそう。日本語テキストエディタだと、newQX, WZ EDITOR, xyzzyあたり。もちろん汎用性はナッシング。

●総括
結局自分の使い方だが、M+に期待しつつエディタを選んでソフト合成するか、Consolas＋MSゴシック(FontLink)でしのぐといった感じになりそう。DirectWrite調整でRictyが使えないかどうかも継続的に検討してみる。

前回調べたときは発芽レベルだったはずのM+が成長して、日本語プログラミングフォント界隈の幹のようになってきた。M+で足りない文字をどうやって補うかが今のテーマで、その主役がIPA。今後M+が充実してくると、そこも意味のない議論になってくる。これがラインセンス緩いとは……　M+すごい。感謝。

また、Inconsolata, Meslo LG M, Anonymous Pro, Source Code Proと欧文でライセンスが緩く素晴らしいフォントが揃ってきた。後ろ２つはちょっと趣味ではないが、書体そのものは手が足りた感じがある。

なお、以前はOsaka(等幅)を好意的に受け止めていたがOsakaはa,o や 1,lの判別が難しく、プログラミング向きではなかった(そもそもWindowsで使うにはライセンスがダメ)。文章を読むにはいいフォントではある。

Windowsのレンダリングはいまいちだ。古くからある標準アンチエイリアスの品質は致し方なかったにしても、比較的新しいClearTypeで調整幅が少ない。DirectWriteはかなりいじれる感じだが、ClearTypeそのものに手を入れれば良かった気がする……

そんなこんなで、どうしても現時点でのWindows7の世界では、環境を意識して使うフォントを考える必要がある。

標準アンチエイリアスでの見栄えを良くするには、ビットマップを埋め込むか、Windowsの仕様を意識したフォントデザインにする必要がある。当然面倒なので、世のフォント作者はWindowsの標準アンチエイリアスを置いていく。ビットマップについてはIPAが打ち切ったことからも分かるように、切るか極小サイズにのみ残すのが主流のようだ。確かにディスプレイが(特にモバイルで)高精細化していることもあって、ビットマップはどんどん不要になる。M+は一応ビットマップを別配布しているが、これも極小サイズのみのようだ。

今後PCのディスプレイも高精細化するだろうし、Windowsのレンダリングにも手が入るだろう。こういうのはたぶん昔話になっていく。が、目下は何かしら工夫が要る段階だ。

ソフトを作る方からすると、DirectWriteを頑張ってるソフトだけ見た目が優位になる。テキスト周りを扱うソフトが競争やるなら、もうDirectWriteは必須という状況らしい。

そしてMicrosoftがWindows9でテーブルをひっくり返す。この世界ってそういう風に出来てるのよね。

なお、決まり文句ですが全て自己責任でお願いします。
コメント（1件）

2013/11/27(水)電子書籍雑感

2013/11/27 11:08 PC（全般）
2013年11月現在のお話。

一応一通りショップ調べたけど、汎用性のKindleと画質のebookJapanという構図でよさそう。

[参考]
週刊少年ジャンプデジタル版の画質をKindle版とeBookJapan版で比較してみた : 見て歩く者 by 鷹野凌
電子書籍の情報をまとめてみる

以下、個人的な使い方とあれこれ考えたことを書き連ねる。

私個人としては、マンガと小説を徐々に電子書籍にシフトしたいという感じ。重くてかさばる技術書や技法書を移行するのが一番いいのだが、課題が結構ある。

・現在の電子書籍(和書)はほぼ全てがDRMあり
・DRMありである以上、読書アプリは固定
・ほとんどの読書アプリがサムネイル表示機能を有しない。ページ移動や動作が重いものも多い。

好きなところから読んだり、ぱらぱらめくって興味を探す的な用途には酷く向かない。他方、先頭から連続的にしか読まないようなデータ、特に小説類では現在の電子書籍でもそこそこの満足が得られそうだ。

将来的に、DRMが無くなってepubやpdfでの提供になればユーザは好きに高機能な読書アプリを選択できる。

DRMが無くなってもフォーマットコンバート手段が出てこない可能性はあるが……　ま、メジャーなものについては誰かが何とかするだろう。たいていのものはepubをDRMの皮でラップしたものだろうし。

DRMフリーのものについては好きにフォーマット変換するのは当たり前のようだ。下のアプリケーションなどが有名どころ。
calibre - E-book management

さて、私が毎号買っている月刊アフタヌーンが電子書籍化した。
1000ページ級の巨人漫画誌アフタヌーンがスマホ＆PCで毎月読める「アフタヌーン電子版」配信開始！ - アフタヌーン公式サイト - モアイ

大手のコミック誌が継続的に電子書籍を発行するようになったのは一つのマイルストーンと言えるだろう。

アフタヌーンはかさばるわ重いわで電子書籍化のメリットが大きい。電子書籍という物を理解するにもいい素材と判断して移行を決断。なにも考えずに、メジャーどころのKindleで買ってみた。

Kindle版はぶっちゃけ解像度が低い。フキダシは読めるが、ルビやマンガ以外の記事はかなり苦しい。Kindleアプリの最大拡大率が低いこともあって今私が使用しているデバイスではマンガ以外の記事はちょっと読めない。

参考サイトにもあったがebookJapanの方が画質はずっと良さそう。
アフタヌーンではKindle版181.0MBに対して、ebookJapanは238.4MBである。この容量差がそのまま解像度に換算されていれば、縦横それぞれ1.15倍程度の差がありそうだ。

Android Kindleアプリは使い勝手が悪い。
最大拡大率が小さい、サムネイル表示が出来ない、ページジャンプまわりのI/Fが奇っ怪。

良いところもある。複数の端末で最終ページを同期できるのは実本よりも便利だろう。

トータルでは、最初から最後へ読み進めるタイプの本(小説とか)で、文字データならかなり良さそうではあるが、画像タイプの本では不満の方が多い。

一方ebookJapanはというと、使い勝手が聞くだに厳しい。電子書籍を保持できるのは常に1端末。別の端末に移すにはいちいちebookJapan経由で書籍を"トランクルーム"に返す必要がある。とてもやってられそうにない。買って比較するのが正しいのだが、ちょっと意欲が湧かなかった。

どちらを軸にするかを考えると、まあ使い勝手でKindleかなと。

将来的にDRMが無くなるか緩くなってくれば、解像度が高い側で買い直すということは考えられる。

あるいは解像度アップや複数データサイズからの選択制に踏み切る電子書籍書店が出て来るかもしれない(一応amazonに解像度アップの要望は出した)。

どうせ数年内にKindle for PC(日本版)が出て来ると思うので、そこら辺で状況が変化してくると思う。

どこをどう考えても、amazonやAppleが先行してDRMを取っ払い、日本企業が置いてかれて、海外商店の大勝利という構図は見えている。なんだか悲しい。

ま、状況が変わるまではとりあえずアフタヌーンを軸に少量Kindleで買っておきアンテナを張るくらいでいいかな。
コメント（3件）

2013/11/09(土)HL-5450DNの印刷設定メモ

2013/11/09 4:44 PC（全般）
HL-5450DNの印刷設定のメモ。
メモしておかないと毎回間違えそうなので残しておく。

最近、BrotherのモノクロレーザープリンタHL-5450DNを導入した。

この機種、True 1200dpi出てグラデーションもかなりよいとの評判。
主にマンガ原稿を印刷する用途としても期待していた。

が、どうも期待した結果通りにならない。
あれこれ試した結果、どうも印刷結果に対して設定項目を誤認しやすい(あるいは自分がレーザプリンタの慣習を知らないだけ)名前になっているようだ。

[Brother HL-5450DN seriesのプロパティ->基本設定->印刷設定]
ここの項目が一番印刷結果に影響を与える。

3種類。

"グラフィックス":
プリンタ側でPhotoShopでの誤差拡散に近い二値化処理を行っている。元画像が二値画像なら(おそらく)これで問題無いが、グレースケールではディザ処理がかかる分汚くなる。

"テキスト":
"グラフィックス"のように二値化をかけずに(そのまま？)出力している。元画像のグレスケ部はインクジェットでのグレスケに近いし、二値・トーン部もしっかり出る。

"手動設定"->"システムのハーフトーンを使う":
一定の閾値を境に二値化がかかる。色々設定を弄ってみたのだが、想定と違ってハーフトーンにならなかった。グレスケを出力する場合白に飛ぶか黒につぶれるかどちらかになりそう。

それ以外に、"手動設定"内部に3種類の改善チェックボックスがある。これらについては確認した限りでON/OFFによる大きな差異は見えなかった。基本外す方向で良いような気がする。

ということで、"テキスト"がすさまじく優秀。マンガ原稿の場合、二値化にしろなんにしろ原稿側で処理してしまうのが基本だろう。"グラフィックス"を意図して選ぶ必要はないと思われる。

"グラフィックス"はお手軽にプリンタ機能だけでハーフトーンかけたいときに使うのが良いんだろうねえ。

最後にオマケで5450DNの雑感を書いておく。これまで使っていたのがMultiWriter 2350Nなので、それと比べてっていうところ。

印刷速度や綺麗さは大変優秀。特に1200dpiはすごい。グレースケールがこんなに綺麗に出て、この印刷速度。サイズも、ギリ卓上と名乗れるくらいでコンパクト。

動作音はかなり五月蠅い。静音モードにしないとちょっと夜間は無理。静音モードにした上でなお壁が薄くなければ使えるか。

心配していたオゾン臭や発熱も、2350Nに比べればずっとマシだった。あとは不満になりやすそうな用紙カールとか印刷の濃さがどうなるか。これらもドライバから制御できるようなので、そこは今後といったところ。

本体にパネルがないのでトラブったときが心配だけれども、とりあえず生きてさえいればブラウザからIPアドレス直打ちで設定・確認できるようなので大丈夫だろうか。
コメント（0件）

2013/10/17(木)機器入れ替え

2013/10/17 10:43 PC（全般）
PC周辺機器類が色々古くなって(ガタが)きていたので、この際一斉に入れ替えた。
メモだけ。

■カラーインクジェットプリンタ
HP DJ-955C → Brother DCP-J552N

基本年賀状＋イラスト・原稿の出力確認。ほぼ普通紙専用。

DJ-955Cはメカニックは未だにしっかりしているのだが、さすがに古くなってきたし、フチなし印刷がないのが不満だった。

出来るだけ長期間使用しなくてもインク詰まりのない、使いたいときにすぐ使えて、普通紙にそこそこ印刷品質が出るものを調査。

店頭確認したらBrotherの印刷結果が比較的良好だったので、同等程度以上の使い勝手を確保できるだろうと見込んでこれに入れ替えた。

・Epson機はインクの容量・クリーニング時の消費がすごいらしいのでパス。

・(最近の)Canon機は印刷実行から待ちが長い(しょっちゅうクリーニングする？)らしいのでパス。

・HPはあまりに印刷品質が進化してなかった感じだったのでパス。(業務機はそうでもないかも？)

業務機とか色々選択肢あって難しいね。

■モノクロレーザープリンタ
NEC MultiWriter 2350N → Brother HL-5450DN

元々6k位で買ったものだし、ピックアップが怪しくトナーも切れてきたので入れ替えを決断。

A3はほとんど使わなかったので除外。コンパクト・高速かつ、可能ならモノクロでグレースケールが綺麗に出せるものものがほしい。A4両面は必須。

Brotherのグレースケールが良好とのことで、店頭調査。対抗機種のHL-2270DWはコンパクトかつ無線LANがついて値段も安いのだが、印刷品質、特にグレースケールの表現は1200dpi時の5450DNが優る感じだった。消費電力がちと心配だが5450DNに決定。

■サブモニタ
Dell 2001FP → Dell P1914S

2001FPの焼き付き問題が酷くなってきたので入れ替え。

2001FPの焼き付き問題は、複数台で経験したので少なくともロットレベルでこの機種に共通っぽい。それこそ半日～1日レベルでかなりはっきりと見える焼き付きのような輝度差が残る。しばらくすると戻ることもあるのだが、なかなかに不快だった。

このモニタは資料やBGV表示用途なのでピボットは欲しく画面サイズは小さくて良い。

軽量で取り回しがしやすく狭額で、入力端子種類が多く、画角が広く確保できる(IPS/VA系)ものが欲しい。非光沢であるのは大前提。極力低消費電力であると良い。

探したらほとんど選択肢がなかった。正直あんまりDellから買いたくないのだが、消去法でP1914Sに決定。

モニタは今過渡期で、タブレット用などとPC用での乖離が大きくなってしまっている。多分2～3年内に落ち着いてきそうではあるので、それまでのつなぎ。

■サーバ
Compaq nx6110 → Panasonic Let's Note CF-T8(EC6AAS)

サーバにガタが来はじめていたので、入れ替え。

低価格、速度UP、メモリ容量UP、良保守性、コンパクトなものないかなーと思って探していたらCF-T8という選択肢があった。Intel Gigabit EthernetもOK。中古だと激安。うはー。

これはピタリとした一手だったと思う。ノイズ・発熱も今のところは減ったかな。
コメント（0件）

2013/10/13(日)VHSデジタル化(再)

2013/10/13 19:04 家電
手持ちのVHSビデオテープは全てデジタル化したと思っていたのだが、30本ほど発掘してしまったため再びデジタル化をした。
その苦闘のメモ。

手段だけ読みたい場合は3に飛んで欲しい。

1.デジタル化の際の留意点

まず復習。

[全体]

●VHS(S-VHSソースがあれば、S-VHS)デッキが必要(当然)。
●デジタル化においては、アナログ映像のノイズが多ければ多いほど破綻しやすい。品質を確保するためにはノイズ量に応じたビットレートが必要。
●特に3倍ソースではノイズが乗りやすい。元映像が悪いほどビットレート上げる必要があるという点に注意。
●コピーガードがかかったものはダビング不可である(法律上の制約。手段はあるがやらない)。メディアを買い直すか、無ければ発売元へ要望。

[PCでキャプチャする場合]

●キャプチャデバイス(ソフトウェアエンコードorハードウェアエンコード)が必要
●ソフトエンコの場合、リアルタイムで高品質に録画できるエンコーダを探す必要がある。
●ソフトエンコで可逆圧縮等を用いる場合、大量の保存領域を要する。
●ハードエンコの場合、安定した良いエンコーダ(MPEG2の可能性大)を探す必要がある。
●ファイルサイズに制限があるケースに注意。特にアナログ放送期のハードエンコボードでは録画ファイルが4GBを超えられないものがある。
●タイマー予約がキャプチャソフトに影響されて面倒くさい場合がある
●デバイス・使用ソフトなどによって音ズレが起こるケースがあり確認が必要
●PCの安定性に左右される
●保存メディアはHDD/BD他自由になる

[HDDレコーダ等デッキでキャプチャする場合]

●デジタル化後の保存先としては録画デッキ(もしくはデッキ＋外付けHDD)をそのまま保持しておくか、BD 25GB/ DVD 4.3GB(それぞれ1層片面の場合)の選択。
●2層以上の光学メディアは価格、保存性を考慮する必要がある。2層以上エリア・切り替え箇所でエラーが増える傾向があり、劣化が怖い
●リネームが面倒くさい。
●例外的に、東芝 VARDIAなどの一部の機種では録画ファイルのPCへの転送が可能。
(FrontPage - RD-Wiki （東芝REGZAブルーレイ&VARDIAまとめサイト）のRDエンジンHD以降)
●エンコーダの質・音ズレ・長時間録画については担保されていると考えて良い(だろう)。
●使用したい機種が新品で販売していない可能性がある。
●中古で入手した場合、デッキの状態・安定性が悪い可能性がある。

[業者委託する場合]

●人に見られても良い、デジタル化の品質等を気にしなければ外部への委託もあり
●ただし、VHS->DVDの業者が多いことに留意。120分x3倍をDVDにした場合、かなりデジタルノイズが乗ることになる。

2.手段検討

前回は次のような構成で実施した。

[前回構成]

三菱 HV-BX200/HV-SX200 -> 東芝 RD-X6 -> RDLNAでPCに転送 -> リネーム -> BDに保存

PCで安定してキャプチャすることが当時難しかったこと、VARDIAからのPC転送が便利だったのが事由。

今回さらなる省力化のため、次のようなやり方を考えた。

[今回構想構成]

東芝 3in1機 -> RDLNAでPCに転送 -> リネーム -> HDDに保存

で、

[HDDレコーダ(3in1)を購入]

■東芝 RD-W301

この機種はビデオデッキ/HDD/DVDを搭載し、ダビング操作をするだけでVHS->HDDが可能である。これでお手軽になると思った。

……結果として大失敗。構想は悪くなかったが、この東芝3in1機がくせ者だった。

RD-W301は中古で(新品がないので)入手したのだが、VHSデッキ部がボロボロでしょっちゅう止まったりテープを巻き込んだりする。

トラッキング性能が非常に悪い。画面が縦にグルグル回る。

ならば単純にHDDレコーダとして使うことを考えたが、今度は長時間使用していると高確率でER0004と表示されシャットダウンしたり再起動したりする。

調べてみるとこの個体特有の問題ではなく、機種・シリーズに共通した問題のようだ(特にER0004)。とりあえず扇風機を当てるなどして安定し始めたのでビデオデッキ部だけ別の手段を考えた。

[ビデオデッキを追加購入]

■Panasonic NV-SVB1
■三菱 HV-SX200

ビデオデッキを2機種追加。複数確保したのはトラッキングが合わない現象を経験したための保険。

で、半分くらいは、次の構成でやったのだが……

[今回暫定構成]

NV-SVB1 -> 東芝 RD-W301 -> RDLNAでPCに転送 -> リネーム -> HDDに保存


あまりにRD-W301のER0004に悩まされたのでさらに機器を入れ換えた。RD-W301いらなかった。くそう時間を返せ。

[HDDレコーダを追加購入]

■RD-S301

[今回最終構成]

NV-SVB1 -> RD-S301 -> RDLNAでPCに転送 -> リネーム -> HDDに保存

これは安定した。テープ1本のみトラッキングが怪しかったので、送り出し元としてHV-BX200を使用した。
最初からこの構成でやっておけば良かったと後悔している。

3.実施

最終構成を再掲。

[構成]

NV-SVB1 -> RD-S301 -> RDLNAでPCに転送 -> リネーム -> HDDに保存

[手順]

  1. NV-SVB1に対象のテープをセット
  2. 巻き戻してなかったら巻き戻す
  3. テープ先頭でカウンターをリセット
  4. 早送りする
  5. ビデオテープ末尾で自動折り返しする際に、カウンターの値を見てメモ
  6. 先頭まで巻き戻ったら何度か巻き戻しをかける(テープの冒頭映像が落ちてしまうため)(HV-BX200の場合、再生 -> 一時停止 -> ジョグでテープ頭までコマ戻し)
  7. RD-S301の録画ソースがビデオデッキを繋いだ入力先になっていることを確認(しばらく放置していると、番組情報取得取得スケジュールが動いて入力先が勝手に変わってしまうので注意)
  8. RD-S301を録画操作
  9. 録画カウンターがスタートしたことを確認して、NV-SVB1を再生操作。
  10. RD-S301のクイックメニュー -> 録画終了時刻/電源設定で、(現在時刻 + テープ総時間 + 5～10分)を録画終了時刻に設定
  11. 録画終了後、RDLNAでPCからRD-S301にアクセス。PCへ録画データを転送する。
  12. 転送がサーバビジーなどで途絶・失敗した場合、レジュームして再送(一度確認したがレジュームの有無でファイル内容は変わらなかったため、信用して良いと思う)
  13. 転送したファイルの中身を確認し、テープ頭から末尾超までがきちんと録画されていることを確認。何カ所かサンプルで確認して、トラッキング・音声・ノイズなどに問題がないかを確認。
  14. 特に重要なソースがあれば、その映像については全てチェック
  15. 転送ファイルは録画時刻のみのファイル名のため、ビデオデッキのラベルに従ってリネーム。
  16. キャプチャ済みのビデオテープにはシールを貼るなどして管理。
  17. 最後に録画ファイルをFireFileCopyで保存用のHDDに移動。
なお、DLNA転送と録画は同時に行える(ただし、テープの入り繰りをしないように)。

4.覚え書き(設定編)

総じて、ノイズリダクションの設定類を決めるのが厄介。
無限の処理能力・保存領域・時間があるなら、ノイズリダクションは一切切り、最終的にソフトエンコで思う存分調整すればよい。

今回はそうではないので、破綻しない限りノイズリダクションを入れるポリシーにする。
何度も見返す予定はないので、手間と1回2回の綺麗さのバランスをとりたい。ならば用意されているノイズリダクションを使用するのが賢いだろう。ここらへんは自炊も同じ。

[RD-S301関連]

●DLNAの有効設定はネットワークに繋いでからネットDEナビ上からやる必要がある。
●録画品質は手動設定の最高値(MN 映像:9.2Mbps 音声:D/M2)とした。
(リニアPCMだと映像ビットレートが最大8Mbpsとなる。L-PCMのメリットを感じないため、D/M2とした)
●上記品質で3倍120分テープ(6時間+α)だと26GB前後。ここら辺は保存メディアや最大録画時間と相談して決めればよい。
●録画機能設定->録画映像効果設定->録画DNRは"入"
[2018/09/07追記]
"弱"(当時"入"と書いたけど"弱"のことだと思われる)
[2018/09/07追記ここまで]
にした。多分あまり差はない。

●S端子で接続したため、録画機能設定->録画映像効果設定->3次元Y/C分離は無関係(マニュアル参照)。
[2018/09/07追記]
[参考]
●録画映像モードは標準でいいんじゃないかなあ…
S-VHS総合スレ Part12の214
[2018/09/07追記ここまで]

[NV-SVB1関連]

●オプション設定->オンスクリーン: 切
●3次元Y/C: 入
●3次元NR: 弱
　弱と標準で差はほとんどわからない。

[HV-BX200関連]

●3DNR/TBC: 入
　TBCと連動してるので入れざるを得ない。

●画質: スタンダード
　多分アンシャープマスク的なもの。切るとかなり輪郭が緩い感じなのでスタンダードかマイルドでよいと思う。

●3DNR設定: マイルド
　HV-BX200はノイズリダクションがフレーム単位で処理している感じで、フレーム間ではノイズを強調しかねない(ちらちらして目立つ)。マイルドでよいと思う。

HV-BX200のノイズリダクション設定は、「再生中に」リモコンのAVセレクトを押さないと出ない。

[接続関連]

●RD-S301 -> PC
　イーサネットLANケーブル(スイッチングハブ経由)
●NV-SVB1 -> RD-S301
　S端子ケーブル＋RCA赤白(出来るだけ高品質なもの)
●RD-S301 -> モニタ(コンポジット入力があるもの。チェック用)
　コンポジットケーブル

5.覚え書き(機器特性)

[NV-SVB1とHV-BX200比較]

●トラッキング性能
　NV-SVB1 > HV-BX200

HV-BX200で怪しいケースでもNV-SVB1できっちりするケースは多い。HV-BX200は縦揺れ・縦回転・横ずれが多い。今回キャプチャしたテープ34本中1本でのみ、NV-SVB1で画面下部に横ずれが出てHV-BX200で出ないケースあり。

●ノイズ
　フレーム単体を見ると、HV-BX200はアニメ向きなノイズの消し方。べた塗りエリアをばっさり行く。連続して見ると、HV-BX200はフレーム間の考慮が甘くピクセル単位レベルのチラチラノイズが出やすい。NV-SVB1は素直なノイズの飛ばし方だが、若干輪郭が甘くなる。フレーム間ノイズは出づらい。個人的にはNV-SVB1の方が好ましい。

●メダカノイズ(っぽいなにか)
　NV-SVB1 > HV-BX200

明るい箇所で横方向に走る黒いメダカノイズみたいなの。NV-SVB1の方が少ない。

●オプションの設定方法
　NV-SVB1 > HV-BX200

NV-SVB1の方が素直(HV-BX200は再生中でないと設定できない項目がある)

●画面表示周り(画面に出る"再生"とか"一時停止"とか)
　NV-SVB1 > HV-BX200

NV-SVB1は画面表示を完璧に切れる(HV-BX200は再生直後に表示される"再生"のみ切れない)。ただし、再生後 -> 一時停止 -> 録画開始することで、気にしなくて済む。

HV-BX200はテープ状態が悪いときに、ブルーバックの"クリーニング時お知らせ"を強制表示する。これをオフにする手段がない。

●操作周り
　HV-BX200 > NV-SVB1

NV-SVB1はコマ送り・戻しができない。ジョグダイヤルがない。HV-BX200に比べ、若干操作レスポンスが遅い、早送り・早戻しが遅い。どれだけ巻き戻しをしても、テープの冒頭部分の映像が再生できないことがある。

HV-BX200はジョグを活用すればほぼテープ頭に合わせられる。動作・レスポンスが全般的に高速(私はこれ以上速い機種を知らない)。

●まとめ
送り出し機としてはNV-SVB1の方が勝るように思う。

もし次回があったら(もう無いと思うが)。ビデオデッキ1台でやるなら、NV-SVB1(同性能と言われるNV-SVB10/NV-SV1)を確保してやるのが良いと思う。さらに優秀と言われるNV-BS800W/NV-BS900でも良い。保険で+1台なら、またHV-BX200/HV-SX200/HV-BX500/HV-SX500でいいだろう。とりあえず2台で無理なら諦めがつく。

[RD-W301]

●数時間(2～3時間使用していると)ER0004を頻発する。当初熱暴走が原因であるとあたりをつけたので色々試した。蓋を開けてヒートシンクをHDD上におき扇風機を当て続けてみたところ、しばらくはこれで安定稼働したのだが2週間程度で安定しなくなった。

●ER0004以外でも不意の再起動などあり、きわめて動作不安定。

●ビデオデッキ部はテープ巻き込み・突然の再生終了などがあり不安定。メカニックが安いと思われる。トラッキングも悪い。経年劣化、不良品をつかんだ可能性あり。

●仮にスペック通りに動けば、ビデオからHDDへのダビングをスイッチ一つで行えるため便利。

[RD-S301]

●RD-W301にあったような不安定さは一切感じなかった。きちんと動くって素晴らしい。
●音質・画質は比較検討していないので分からない。VARDIAシリーズ内で、A/Dコンバータは多分そんな差をつけてないと思うが……

雑文ご容赦。

[参考]
ビデオテープを高画質でデジタル保存 2 コン♪
コメント（3件）
OK キャンセル 確認 その他