3%ダウン

7%程平均出力が落ち、タイム的には3%弱遅くなりました。
まぁ、ブロンズはもらえたのですが・・・

やはり準備不足ですね。

続・お前は狙われている！

・・・
・・・・・・
日曜日にトランポで静岡のあたりを走ってきました。清水とか日本平とか焼津とか。

走ってる最中もなんかタイヤが柔らかいな、と思ったような気がしたのですが、特に問題なく

で、家に着いた後に、あれ？これ柔らかすぎじゃね？と気が付いたときには3気圧ぐらいまで落ちてました。
空気を入れていったところ、特に問題な・・・あ・・・シューという音がする・・・。

どうも微妙な穴が開いたのをシーラントが防いでくれていたようです。
というわけで先日ちょうど買ってみたチューブレスにも使えるタイヤパッチを当てて直しました。
このタイヤは500kmも走ってないですし、シーラントでふさがる穴ならパッチでいいでしょ。

修理は特に問題なく終わったのですが、ビード上げが・・・
ホイールはPrimeのRR-50なのですが、どうやっても上がらないため、よくよく観察してみると、ビードを落とすくぼみよりもスポーク穴の方が大きく、くぼみにビードを落としてもスポーク穴の隙間から空気が駄々洩れ、ということに気が付きました。

それで前回も苦労したのか・・・これだから安物は・・・
というところでもうあきらめてチューブを入れてしまうことに。
チューブを入れて、をぉ、こんなに簡単に空気が入ってビードが上がるぜ、とか言っていたところ、タイヤの回転方向を逆につけていました。

orz

仕方なくタイヤを嵌めなおそうとして片側のビードを落とし・・・たところであることに気が付きました。

これって片側はビードがハマってるからこのまま(片側ビードを嵌めたまま)チューブを抜いてもう片側だけビード上げればいいんじゃね？
我ながらナイスアイディア、と思いつつ、いそいそとタイヤの向きを直してチューブを入れて空気を入れてからまたチューブを抜いて・・・再びチューブレスのビード上げを実施。

→やっぱり出来ませんでした
何故だ・・・

この時点でかれこれ3時間ほど格闘していたので、もうこれで最後にしようと思いつつ、1回だけCO2ボンベで上げてみた(今まではフロアポンプ・タンクでやってた)ところ、あっさりビードが上がりました。

・・・このホイールには勢いが必要なようです。
(多分スポーク穴のくぼみを超えてタイヤが膨らめばそれ以降はちゃんと空気が入るため)
シーラントを入れずに24Hr放置してみましたが、7→5気圧ぐらいで、十分許容範囲。
これでシーラントを入れれば問題ないでしょう。


そんなこんなで、5月はサイドカット2回、パンク2回、ビード上げ3本、という ことになりました。
お祓いとか行った方が良いですかね。

KING滝

42km走ってきました。
機材のおかげで去年よりざっと1時間ほど速くなりました。
でも二回目の上りがやたらと辛かった・・・ハンガーノックなんだろうか？
心拍は80～85%位だったのですが、全然力が入らない、という。

そして、リアの2速に入らないな、なんでかな、とか、なんか後輪がふにゃふにゃするな、パンクかな、とか思いつつ走っていたのですが、家についてから
「後輪が外れかけている(スルーアクスルなのですが、ボルトが緩んだ) 」ということが判明。
・・・外れなくてよかった・・・

あと、いつの間にかリアライトがなくなっていました。というかサドルバックにちょうどライトを付けれるところがあったのですが、その取り付け部がちぎれていました。
CP1ではついていたので、その後どこかでパージされてしまったようです。
・・・サドルバッグも7年近く使っているものなので寿命でしょうか。

もうこれでいい気がする

L-SMASH Works r935

僕はずっとDGIndexを使い続けているのですが、L-SMASHってデコーダ(とは言ってもffmpegに渡すだけ？)もあったんですね。
ずっと、正しいコンテナ実装するぜ！っていうプロジェクトだけだと思ってました・・・

ffmsはtsでフレームアキュレートではないという欠点があったのですが、こちらでは-ss的な何かで正しくなっているのでしょうか。
・・・AAC抽出時の音合わせとかどうすればよいんだろう・・・LWLibavAudioSourceからの再エンコードとか？
まずはちゃんとreadme読むか・・・
→やっぱりちゃんと書いてあった

av_sync
LWLibavVideoSource読み込み時のインデックスファイル(またはファイルを生成せず
内部的に生成したインデックス）で設定された映像ストリームと音声を同期させて、音ズレを防ぎます。
ただし、映像・音声ともに Libav で読み込まれていることが同期条件となります。

先頭フレームが音声の同期ポイントとなりますが、ffmpegを用いてMPEG系映像を表示する場合、先頭GOPのIピクチャ、またはデコードが保証されないBおよびPピクチャが先頭にある場合は最初のIピクチャで代替表示するため、ClosedGOPとOpenGOPでは表示ルールが若干異なります（いずれも音声は同期する）。* 当プラグインは ffmpeg を使用しています。

Libav を用いている場合も先頭フレームが同期ポイントとなりますが、OpenGOP等のようにBピクチャ始まりであってもIピクチャで代替表示せず、壊れていても強制表示します。

=true インデックスファイルで指定されている映像ストリームと音声を同期します
=false 音声を同期させません（デフォルト）

DGIndexは先頭GOPのBフレーム部分をフレーム数として数える、という特徴があるのですが、それと同じ？

とか思っていたのでですが、 何かが違う・・・
どうも、DGIndexは完全なGOPからしか始まらない？のに対し、L-SMASHは上述の通り不完全なGOPからでも始まるようです。

先頭フレーム例
d2v：     BBIBBPBBPBBPBBP
lwi：PBBP BBIBBPBBPBBPBBP
gl ：       IBBPBBPBBPBBP

サンプルのtsではDGIndexはlwiでkey=1となっているGOPから始まっているのに対し、l-smashはその１つ前のGOP(の一部)が存在するので。lwi(とソース)を眺める限りではpic=1がIフレーム、pic=2はPフレーム、pic=3はBフレームのようです。
音合わせはL-SMASHでデコードしたものを再エンコードするか、PTSを見て合わせるのが確実なんでしょうね。
ではそのためのスクリプトを作らねば。はて・・・どうしてこうなった・・・

お前は狙われている！

ある日、峠へ行こうとしました。
まだ今年は開通して間もないのか、雪が残っていたり、土砂崩れがあったりする道でした。
そんな中、洗い越しを走っていた時のこと。

「パンッ！プシュー・・・・」

！？・・・何事かと確認するとフロントをサイドカットしていました。
30mmのリムと写真で比較しても結構ざっくり行っていてシーラントでもふさがらず。


仕方がなくチューブとタイヤブートを入れて走り出すこと1min程、下りで、「ゴンッガンッ！」という衝撃が。
今度は枯葉・・・と思ったけど石だったようで、なんか派手にぶつかりました。
幸い落車せずに済んだ(ハンドルから手が外れたものの、たまたま下ハンドルに手が収まった)ものの、再びパンク。
そしてここからが大変でした。
チューブが残りは同行した友人の1個しかないため、パッチで対応しようとしたのですが、パッチを貼って、3～4気圧ぐらい入れたときに「プシュー」という音がして漏れる、という。
試行錯誤しながら3回ほど繰り返し、気が付いたことは「これシーラントが糊を阻害してるんじゃね？」
というわけでシーラントをなるべく取り除いてからもう一度パッチ。
ある程度大丈夫・・・かな？
ということを試行錯誤しながらパッチを5個ほど消費し、パッチの残弾が0に。
ちょっとこれ以上進むのは危険かな、ということで、石には気を付けつつ引き返すことにしました。

そして水の流れる道路をゆっくり下っていた時のこと。

「パンッ！プシュー・・・・」

・・・はて、聞き覚えがある音がしたけど何が起こったのやら？
というわけで、今度は後輪をサイドカット。

orz

でもチューブが残っていてよかったです。
その後、下りで最高62kmとか出しながら、残り30km程無事に走れました。

さて、今日はタイヤを買いに行ったりチューブレス用のパッチがあるらしいのでそれを買ってみたりしてみましょう。

突発ビワイチ

金曜にどこ行こうか、と話をしていて、土曜日の朝高速のETCを通過する直前に、伊豆に行くか、安曇野に行くか、琵琶湖に行くか、という決断を迫られた結果、とりあえず近場の琵琶湖で、となりました。
朝は気温が12度しかなかったので寒い、と思いながら走っていたのですが、9時ぐらいになってきたらあったかくなってきました。
11時ごろにはまだ19度で、予報は27度だけど本当だろうか、と言いながら走っていたら13時頃に走り終えてしまいました。
が、やっぱり28度くらいまで上がっていたので、日が高くなってきてからは1時間当たり3度ぐらいずつ上昇していったことになるのでしょうね。

前日に突発的にサドルを変えていたりしたのですが、4時間過ぎぐらいからお尻が痛い・・・という残念なことに。
というわけで戻しました。
・・・同じメーカーの、同じシリーズの、穴あきタイプに変えただけだったのですが・・・
角度が合わなかったのか、滑りやすい素材になっていたからいけないのか、なんででしょうね。
そして新しいサドルはシクロにつけました。こっちは長距離乗らないから4時間も持てば十分です。

そういえば今日でしたね

Ryzen2の発売日

AVX2がどうしてもintelに比べると劣りますが、値段的にはこなれてきたのでエンコード用に買ってもよいような気がしますね。

24pを誤爆する

なんか最近24pのはずなのに30pと誤判定することがあるな、ということに気が付きました。
・・・大変今更ですが。

で、元々は
均一に動いている場合、フィールドマッチ後の映像は前フレームからの差分に対して
24pは変動係数は50％ 偏差値は[55 55 55 55 30]
15pは変動係数は94％ 偏差値は[59 39] (5frame探索時は 82/122 [58 42])
12pの理論上の変動係数は122％ 偏差値は[62 42 42 62 42]の繰り返し
8pは変動係数は166％ 偏差値は[67 44 44 44 67 44 44 44 67 44 44 44 67 44 44] (15frame探索時)
均一に動いている場合重複フレームが1/5(=24p)なら変動係数は50％、2/5なら82、3/5(=12p)なら122、4/5なら200になる
と考えていたのです。

が、24pだけどインタレ解除していない（フィールドマッチに失敗した)場合、
変動係数は31％ [58 58 38 58 38]位になるんじゃね？
ということはそれに対応してスクリプトを変更・・・あれ？でもなんでフィールドマッチが失敗しているんだろう？
field情報が違うとか？
というので確認中。

→失敗するのは動きがない(静止画)とかでどのフィールドに一致させても縞が出ない時で、単純にフィールドマッチに失敗したときっぽい。
なのでとりあえず上述の理屈で説明が付くような。
ただ、変動係数30%位ってよくありそうなので、ある程度判定は厳しくしないと誤爆するような・・・。
まぁ、これでやってみましょう。

突発的に

マウンテンバイクを買っていました。
・・・はて。

SDAに出ようとかそんな話をしていて、去年カンチブレーキなシクロで42kmに出たら死にかけた(下りが怖い)ので、次に出るならちゃんと自転車を買おう、と思っていたのです。
で、出ようとかそんな話をしながら自転車屋さんに行ったらいつの間にかSCOTTのXC車を買っていました。
予定調和ですね。

 で、冷静になってちゃんと考えるとGiantのFATHOM1か2かでよかったんではなかろうか。
いや、過去3台giantを買ってきたGiant好きとしては。いや、SRAMという付加理由があるから・・・
あと、27.5の方が日本人には合うだろうとか思っていたのですが、なぜ自分は29erを買っているのだろうか・・・

まぁ、結局のところ、やってみなければわからないので、そんなにこだわりもありませんが。

→そういえば18年モデルからBOOST規格に揃えてきてて、GIANTのラインナップはえげつない、と店員さんが言っていましたね。
(新規格は29erしかない。そしてXTCは上位モデルしかなく、下位モデルのFATHOMは27.5だけどBOOST規格ではない。
SCOTTも27+か29er以外は前モデルのフレーム)
という感じで、結局よくよく考えても同じ選択になるようです。

で、メモ
FOX 32 RHYTHM FORK setting

・・・あれ？延期したのはこれが原因じゃなかったの？

というわけで、めるめどの9話を全体とおして10秒ぐらい眺めてみました。
あ、こりゃ延期するわ、という出来です。

多分これでもいろいろ修正が入っているのでしょうが・・・

大変ですね(他人事)

tc2mp4.plってしばらく更新されていないですよね

なので勝手にmodしました
・exe版と同じように-Lオプション対応させた
・日本語のダメ文字に・・・自分が困らない程度に対応
・mp4boxが新しい場合に対応(nhmlの出力が最近はなんか違う)

そういえば、vfrにする時って多分プロファイル(最大ビットレート)が不正になるんですよね。
なんせ普通にエンコードしたのに2.5(60/24)倍のフレームを詰め込むことになるので。
x264で直接tcfileinを指定していたときはどうだったんだろう・・・

2018冬イベ

E4まで来たので周回してドロップ回収しなくちゃな～とか思っていたんです。
で、ボス到達1回目で大東が、2回目でJervisが、5回目？で大東(二隻目)が出ました。
・・・そろそろ死ぬんだろうか。

この後は、E5以降の特効艦の那智・足柄を既に使ってしまったのでちょっと大変そうな気がしますが、まぁ何とかなるでしょう。

UR242を買った

ずっとM-AudioのFirewire1814を使い続けていたのですが、IEEE1394のカードが変な動きしかしないのでUSB-Audioに変えてみました。
そして、せっかくだからとRMAAをやったら10年使い続けているFireWire1814の方が性能が良い(SN比:約2倍、thd,クロストーク:10倍)ということが分かって「・・・」となった今日この頃です。唯一周波数だけは192kHzに対応していますが、96kHzでも十分です。
そして、1814を再インストールしてみたら以前の挙動(スリープ・休止に入れない)がなんか治ってるような気が・・・
実は1814ではなく、一緒に変えたNIC(オンボード)が微妙なWOLな挙動になっていたということなのか。

あと、元々OSミキサーを介さずに(DirectSoundのミキサーが糞で、F.S.の出力すると波高値に達したサンプルだけ3dB位？？落とされるらしい )いろいろやりたいということで、
・OS等のDirectSound系はS/W1,2ch出力
・foobarからASIOでS/W3,4chに出力
をH/Wミキサーを介してH/W1,2chから出力していたのですが、UR242ではそういった使い方はできないみたいです。

ということで、UR242はノートPC(ほぼ艦これ専用マシン これも10年選手)からの出力用になってしまいました。
そういう使い方をするならバスパワー駆動するUR22の方が良いのですがね。

使い分け

気持ちを伝えたいのか、考えを伝えたいのかれるような気がします。
というか別に感情を伝えたいことがないので、僕にはSNS系の双方向さは必要ないな、と思った今日この頃。

あと、LINEとメールの違いは仕組み上、LINEはデータを「見に行く」のに対し、メールは手元のデータを見る、というところで違います。
imap等では(ローカルにも保存できますが)サーバ上にデータを置いてあるためその観点では微妙なところですが、「こちら側」のサーバにおいてあるものと、間借りしているだけの掲示板では情報の確実度が違います。
要は信用していない、というだけですが。

とか言いながらスマホを買ったら使うんでしょうね。

[外: MD5Str ]って表示されるのって鬱陶しくないですか？

というわけで、iGlitchさんのCaption2Ass_C5を参考にPCRのソースをコメントアウトしてmod。
じゃぁC5を使えよ、という話もありますが、まぁビルドできたんでいいや。
makiさんのPCRのビルドはそのまま開いてビルドするだけなので簡単ですし。

いや、本当は設定で切り替えられるようにした方が良いんでしょうが・・・

4k対応で変わるらしい

NHK BS1などBS放送の解像度が横1,440ドットに。新4K/8K放送に向け帯域削減
ある日突然ロゴ判定ができなくなりました。
何事・・？？と調べた結果、いつの間にかBS放送の解像度が変更されていたとのこと。
・・・まじか

10GbEを確認する際にWindows上でのiperf3は気にしない方が良い？

先日買った10Gbセット(NIC+HUB)が届いたので早速インストール。
早速ベンチを・・・とったらiperf3で4Gb位しか出ない。
？？？
ということで、確認中

試したこと：
・iperf3.1.3を32/64bit両方でやってみる
→大した変化なし
・TCPOptimizer4でoptimizeしてみる
→大した効果なし
・driverでjumboframeや割り込み加減率を変えてみる
→大した効果なし
・iperfのオプションを-M,-l,-wとかいろいろ弄ってみる
→大した効果なし
・電源設定をハイパフォーマンスにしてみる
→大した効果なし
・iperfで-P4とかしてみる
→全部で7Gbpsぐらいまでは増えるが・・・
・iperf -c localhostでそもそもの帯域を確認してみる
→Win2008R2鯖で10Gbps、Win10で5Gbps程度！？意味が分からん
・Windows10のクリーンインストール
→結果変わらず
・同じマシンにUbuntsu(物理)をインストールしていろいろ確認
－ubuntsu(物理)からdebian(Win鯖のHyper-V上)へのiperf：これ位出ればいいよね(リトライが気になるけど)

[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-30.00 sec 28.9 GBytes 8.28 Gbits/sec 1884 sender
[ 4] 0.00-30.00 sec 28.9 GBytes 8.28 Gbits/sec receiver
CPU Utilization: local/sender 17.2% (0.4%u/16.8%s), remote/receiver 9.1% (0.7%u/8.4%s)

－debian(Win鯖のHyper-V上)からubuntsu(物理)へのiperf：なんか遅くね？

[ 4] 0.00-30.00 sec 13.1 GBytes 3.75 Gbits/sec 36 sender
[ 4] 0.00-30.00 sec 13.1 GBytes 3.75 Gbits/sec receiver
CPU Utilization: local/receiver 14.8% (0.8%u/14.0%s), remote/sender 1.5% (0.1%u/1.4%s)

－ubuntsu(物理)からWin鯖(ホスト)へのiperf：まぁ許容範囲

[ 4] 0.00-30.00 sec 25.5 GBytes 7.30 Gbits/sec 0 sender
[ 4] 0.00-30.00 sec 25.5 GBytes 7.30 Gbits/sec receiver
CPU Utilization: local/sender 17.1% (0.9%u/16.2%s), remote/receiver 2.3% (0.4%u/1.8%s)

－Win鯖(ホスト)からubuntsu(物理)へのiperf：これくらい出ればよいのに

[ 4] 0.00-30.00 sec 29.1 GBytes 8.32 Gbits/sec sender
[ 4] 0.00-30.00 sec 29.1 GBytes 8.32 Gbits/sec receiver
CPU Utilization: local/receiver 28.9% (1.3%u/27.5%s), remote/sender 33.7% (8.0%u/25.7%s)

－Win10(物理)からWin鯖(ホスト)へのiperf：いや、おかしいって

[ 4] 0.00-30.00 sec 12.9 GBytes 3.69 Gbits/sec sender
[ 4] 0.00-30.00 sec 12.9 GBytes 3.69 Gbits/sec receiver
CPU Utilization: local/sender 33.6% (2.8%u/30.8%s), remote/receiver 7.0% (1.7%u/5.3%s)

－Win鯖(ホスト)からWin10(物理)：だからおかしいって

[ 4] 0.00-30.00 sec 16.1 GBytes 4.61 Gbits/sec sender
[ 4] 0.00-30.00 sec 16.1 GBytes 4.61 Gbits/sec receiver
CPU Utilization: local/receiver 81.0% (25.3%u/55.7%s), remote/sender 23.5% (5.9%u/17.6%s)

→Windows同士のiperfが有意に遅い
→Windowsからの送信時、CPUを異様に占有している

・Win同士でファイルコピーしてみる
→500～600MB/s程度(ローカルでの読み書きMAX)は出るから実質問題はない

結論：Windows上のiperf3は信用してはいけない、もしくは何か(バイナリか環境か)おかしいのでは？
実使用上問題ないし、H/Wに問題があるわけでもなさそうなので、気にしない(見なかったこと)ことにしよう！

それにしても、最近のOSインストールはとても楽になりましたね。
「試しに」クリーンインストールするのが1Hrも待たずに済みます。

10GbEtherの時代

冬休みの間に10GEtherっていいよね、とか、でもHUBにちょうどいいのがないな、とか思っていたのです。
2016～7年に普及期に入ったといわれているとはいえ、5portsHUBが50kはちと高いのでは？。
で、Netgearの新製品情報を見たら10,5,2.5,1G×2ports、1G×8portsのちょうど良いのが1/10に出ていました。
外部電源というのがちょっと気になりますが、ファンレスですしまぁ、仕方がないでしょう。
NETGEAR『GS110MX』と『GS110EMX』を発売開始
元々の想定用途はサーバとメインマシン間だけ10G(もしくは5G以上)でつなげないかな、というところなので、まさにピッタリのスペック。
というわけでポチってしまった今日この頃。

ついでにNICも買わねばならんので、X550かX540かどちらにしよう、と悩んでみましたが、結局
・X550はマルチギガに対応してる
・X550はPCIe3.0×4で、X540は2.1×8
・X550は13WでX540は18W？(どこで見たか記憶が定かではない・・・)
位しか違いがありません。
x4かx8かはもともと3.0x8のポートを使っていますし、10GHubを使うのでマルチギガかどうかも関係ありません。
というわけでX540でいいや。そっちの方が安いし。

IntelNICは偽物が良く流通している、と言われています。(今もそうなのかどうか知りませんが)
で、Amazonでいかにも怪しい？(一応IntelのX1とかの想定価格が$350～、チップ単体で$120とか$140位なので、別に20kでもそんな変ではないという話も)のがたくさんあったのですが、その中で10Gtekという出品者がいました。

中国のちゃんとした会社らしく、Intel NICではなく、Intelチップ搭載品、と唄って実際にパッケージにも10Gtekと書いている様子。
かねてから偽物ではなく、自分たちのブランドで商売してほしいと思っていたのでこれはこれは、ということで購入。

そしていろいろ調べていたら驚愕の事実が・・・
なんと！メインマシンまではCat6Aでつないでいるものの、サーバまでがCat5Eだった！
いや、3m位だから何とかなるかもしれませんが、せっかくなのでCat6か6Aかのを買わねば。(本当は6Aまで要らないんですけどね)
・・・ってよくよく確認したら1/4本だけCAT6のケーブルが入ってた。
ってか、CAT6の開封されていない袋があった。
どうも昔、変えようとしたものの必要性がないので面倒になってCAT5Eのままにしたっぽい。

githubが死んだ

もういない！

いや、何があったのか知りませんが・・・
昨日からエラーが増え始め、いつの間にやら死んでたらしいです。
すぐ戻りましたが。

僕はあまり困りませんが、困る人も多いのかもしれません。

https://status.github.com/messages/2018-01-11

265を試そう

もうそろそろx265を試してみてもいいかもしれない、と思い始めたので試してみました。

ほぼx264互換だろ、とか思ってたらいろんなところにはまったのでメモ。
・--demuxerオプションがなくなって、--y4mに変わってたってか入力がYUVかY4Mしかない
→オプションを変えるだけ

・mp4出力に対応していない
→mp4という拡張子を付けても出来上がるのは.h265なので、mp4boxで取り込む

・--tcfileinに対応しない(raw出力だし)
→仕方がないのでtc2mp4とかを使ってmp4boxでのインポート時にタイムコードを付加(予定)

・使ってたmp4boxが(古いから)hevc/h265に対応していない
→新しいのを使う

・新しい(0.70)mp4boxに放り込んだら大量に「Error parsing slice header: byte_align not found at end of header !」と言われる
→https://github.com/gpac/gpac/issues/801によるとrev3以降ではで治ったらしい。ってかgpacのdlページにある070rev0は安定最新版ではないのか・・・仕方がないので0.72DEV最新版(rev357)にする

・mp4boxを0.72DEVにしたら、最近(ここ5年ぐらい？)のmp4boxは既存ファイルを上書きしないようになってる(から昔のを使い続けていたのですが)のが、いつの間にか治っていたと喜ぶ
mp4boxからunicodeで吐かれてたファイル名がちゃんと表示されるようになったのを鑑みると、ようやくunicode絡みのfilehandlingが治ったのでは？という想像(変更履歴とか確認してません)
と、思ったところ、I/O errorは出なくなったけど、代わりに-outオプションを受け付けなくなっている・・・？もしくはsjisで入力するのがいけないのかもしれませんが。
あとcmdの標準出力の変数を弄っているのかなんかで、mp4boxを使った後のコンソールで日本語がおかしくなる。
具体的には
echo "%SOURCE%.h265" >>"%LOGFILE%"
%mp4box% -add "%SOURCE%.h265" "%SOURCE%.mp4"
echo "%SOURCE%.h265" >>"%LOGFILE%"
というコマンドを実行すると、mp4boxの後のechoでは%SOURCE%から吐き出される2byte文字が化ける(おそらくutf8を吐いてる)
chcpをしても932と帰ってくるのに、chcp 932と打ちなおすと治る
→捜したところ、videohelpに0.70.rev27があったので、それを使えばいいんじゃね？結局unicode絡みのは治ってないけど。