生還しましたが

次出ることがあれば、MTBを買います。

ネットの情報に騙されてシクロでも行けるんじゃね？と甘く見ていたのが運の尽き、下りが怖いのなんの・・・
あれはできる人がやっていただけで、初心者がやってはいけない所業でした。
これだけ命のやり取りをしたのは久しぶりです。
トラブルとしては自転車が木にひっかかって前から地面に突っ込んでシフターが曲がったぐらいでしょうか。(人間は脱出できました)
結局自転車が倒れることはあっても人間が倒れることはなく、残ったのは疲労のみ。

というかカンチブレーキ・シクロという時点でいろいろ間違っていたんです。
カンチブレーキ：強く握らないと止まらない。というか制動の目的がシクロに適したものだからなかなかロックするような制動力は出ない。
シクロ：完全にリジッドなのでサスの動きを人間が行うという人力サスペンションによりすぐに腕が限界に達する
というわけで上りは問題ありませんが、ブレーキを握る握力を担う前腕とサスペンションを担う上腕がすぐに限界になって、最終盤の下りなんて数百メートルごとに一時停止して休む、ということに。
残り3キロ、と出てからが長かった・・・

というわけで、出るならディスクブレーキ・サス付きの自転車が良いです(当たり前ですが)。
あと、34-32でもなんとか足つきなしで行けました。
温泉でSS100kmの人に出会ったのですが、32-21でCP3後の直角＆劇坂(15%位？)以外だったら何とかなる、といっていました。
・・・すげぇ。良く回せますね。トルク的には僕の1.5倍です。

あとは「42km」に騙されます。
42kmコースの40kmポストを通過したらあとは2kmと思うじゃないですか。
計65km走れる「42km」なのに、実はもう終わるんじゃないかという妙な期待を持ってしまってその後に現れる激坂に怒りを覚える、という参加者共通？の現象に見舞われます。

というわけで本当にアドベンチャーでした。

MPEG2DecPlusの速度とか

せっかくなので僕の環境(avisynth2.60 32bit i7-4790K win10 64bit)でMPEG2DecPlusの速度とかDGMpegdec比でどう違うのか確認してみました。

使ったのはこんなavs

vsource="test.d2v"
ref=DGDecode_MPEG2Source(vsource,idct=5).trim(1,5000)
target=MPEG2DecPlus_MPEG2Source(vsource,idct=4).trim(1,5000)
compare(ref,target,"","hoge5-4.log")
return last

参考：昔調べたDGMpegdecの各精度


DGDecodeのidct=5をリファレンスに取ったMPEG2DecPlusのPSNR[dB]

idct	Minimum	Average	Maximum	Overall
1,2,3,6,7: AP922整数	59.3174	63.8421	81.0069	63.2977
4: SSE2/AVX2 LLM	92.9447	101.995	111.8096	100.4447
5: IEEE 1180 reference	100.3483	111.1362	111.8096	110.6078

BSのアニメ(1920x1080)をデコードしたときの速度

idct	DGDecodeSSE	MPEG2DecPlus
3	284.398fps	255.885fps
4	187.730fps	225.459fps
5	138.206fps	102.459fps

というわけで、idct=4を使うならMPEG2DecPlusの方が速そうです。

追伸
sandybridge(i7-2600K)ではMPEG2DecPlus_MPEG2Source(idct=4)を使うと遅い・・・
haswellでは速い、ということはAVX2とかで最適化されているのかな？
→「アセンブラの排除による64bitへの対応、及びSSE2/AVX2でのintrinsicによる最適化。等」と書いてあったので、そうなのでしょう

TIVTCが64bit化

pinterf/TIVTC

僕が去年適当にやっていたのと同じようなことをちゃんとやってくれていました。
といっても僕の使い方ではTIVTCはあまりボトルネックではない(さらにこの間スクリプト内で並列処理にさせた)のであまり速度アップにはつながらないかもしれませんが。

一部のインラインアセンブリコードはC言語化して64bitへ、ということなので、MPEG2DecPlusもそうでしたし、最近の64bit化の流れはそういうところなのでしょうかね。
にしても(当たり前ですが)違う人がやっても同じアセンブラから同じようなコードが出来上がるんですね。


以下、更新履歴より。

v1.0.8 (20170429)

    Fix: TFM PP=2 and PP=5 (Blend deint)

v1.0.7 (20170427)

    fix crash in FieldDiff (in new SIMD SSE2 rewrite)

v1.0.6 (20170421) - pinterf

    project migrated to VS 2015
    AVS 2.6 interface, no Avisynth 2.5.x support
    some fixes
    x64 port and readability: move all inline asm to simd intrinsics or C
    supports and requires SSE2
    MMX and ISSE is not supported, but kept in the source code for reference
    source code cleanups

2017春イベ

とりあえず攻略開始

えろまんがー

先生を見ました。

さすがのクオリティです。
ってか、OPテロップを見る限り、メインヒロイン用のアニメータを用意しているようで驚きですが、理にかなっているとも言えます。
描くのが難しい、というのもあるのでしょうが。
また、前作は千葉市、今作は荒川区？(というか千住新橋)と、なぜか僕がしばらくいたところが舞台になっているので気になってしまいます。

というわけでFHDで保存しようと思いついた結果、x264じゃなくてx265にしてみるのもいいんじゃね？とか思い始めてしまいました。
こんなことをやっているからアニメが進まないというのに・・・

とりあえずx264-10bitでエンコードしてみた。
らなぜかサイズが縮んだ・・・？

ログを見てみるとプロファイルがHigh4.2→High10 4.2になっていたのと、QPがビット数分(2bitなので12dB)増えているのが目につきます。
I、Pフレームの数が減ってsizeは若干増えているのに対し、Bフレームはsizeが10%程縮んでいる・・・
よくわかりませんが、10bitにするというのは、周波数領域からxy空間へマップする演算が10bitになるだけなんでしょうか？
だとするとほとんどサイズが変わらないのも理解ができます。
が、まぁ、世の中には不思議がいっぱいですね。


そういえば、春イベも始まりました。

今更の罠

「perlでint(-0.1)=0」

・・・そうですか。
int(-0.1)=-1
かと思ってました。

これだから浮動小数は・・・

perldoc
wikipedia 端数処理

各int関数の丸め方向
C言語：0方向
perl：0方向
VB：負方向
excel：負方向

C言語は浮動小数からのキャストの場合です
整数演算で除算をした結果の場合は調べてませんが、マイコン依存だったような？
ex.
(int)(-1)/(int)2=???

せっかくのなので検索しました。
http://www.bohyoh.com/CandCPP/FAQ/FAQ00134.html
や
stackoverlfowのページ
によれば

C：0方向
C99：処理系依存
C++ ～03：処理系依存
C++ 11～：0方向

らしい。
・・・昔も同じようなことを調べたような・・・