stretch

例のごとくstableが更新されました。
aptitudeであっさり行けるかと思いきや、courierが動かない・・・
pidとかの場所が/runに変更になった模様で、設定ファイルとかでそれを変えたら動きました。

apacheもmpm-workerとかが統合されてました。


そしてなんかautofsでアクセスできんな、とか思っていたらdirectioのオプションが通っていないだけだった。
・・・ちゃんとログを読みましょう、ということで。

to the WEST!

Let's bring Visual Novel Hoshizora No Memoria to the West!

・・・西へ。
まさかkickstarterとは。

え？これで英語を勉強するんですか？
・・・母国語が日本語なので、nativeの発音とかニュアンスとか無理っすよ。

いや、それ以前に積んであるゲームをクリアしなければならないという使命が・・・orz
いろとりどりのセカイとかもう何年積んであるんだ、という気が・・・
最近自転車とか提督業とかにかまけているのがいかんのです。

そういえば今日出張で鎌倉の辺に行ったのですが、逗子駅ではいふりのナレーションが流れていました。
なにやらスタンプラリーをやっているらしいとのこと。
こういうのが普通に受け入れられているのが日本なんでしょうね。

-1min

平均：177bpm、189W、82rpmで、去年より-1minぐらいでした。

開始30分ぐらいずっと180bpmを超えていたのでちょっときついかな、と思って途中から175位に抑えるように。
そのペースで終盤まで行ったのですが、終盤は混雑していてちょっともたついた感があります。
最後は、平坦区間に入ってギアを上げた瞬間にふくらはぎが攣りかけたため、全く追い込めていません。大腿筋はまだいけたのに・・・
とは言っても心拍が85%を超え続けていたためそっちが持たないのですが、無酸素の領域で多少は追い込めたのではないかと。
それで5秒早くなったからなんだ、という話ではありますが、ちょっと悔いの残るところです。
ふくらはぎが攣りそう、というのは水曜にローラー回したとき、意図的に高強度で回すペダリングをした際にあっさり攣りかけたので、そういえば回す練習をあまりしていない、とわかってはいたのですが・・・今更どうにもできず。

というか、ゴールラインがどこか分かりづらくて？？？と思いながら何か線を踏んであぁ、これがラインなのか、と後から気が付くような感じでした。
隣の人も「あれゴールですよね？」と疑問形。


自転車は走行重量で7.6kg(ボトル含まず)
スペック上は6.9kgなのですが、ペダルで+213g*2、ボトルケージで+40g*2、スプロケを14-28にしたので+50gぐらい、サイコンが+100g、マウンタ+60g、ハンドルは-100g、サドルが-30g、・・・あとは何だろう・・・バーテープとかシーラントとか完成車重量に含まれてないのかな？

そういえば土曜日に山の神を見かけました。
パット見、意外と普通の人っぽいのですが、GOKISOのジャージを着ていてをぉっ？と気が付きました。

生還しましたが

次出ることがあれば、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方向

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

今年の花粉は意外と平気だった

・・・まだこれからなのかもしれませんが。
というか、いつもそこまでひどくないので気にしなければよいという話もあります。
何年か前に結構くしゃみが出たり目がかゆかったりとかしたのですが、去年も今年もあんまり反応せず。

そんなこんなで、もうそろそろ冬眠から目覚めて自転車で外に出る時期でしょうか。
現在は週に二日、部屋の中で1時間平均3W/kgでTSS100こぐ程度。
まぁ、最大出力はせいぜい7W/kg程度しか出していないので、LSDと言えなくもない？(違うとは思いますが)

というわけで金色豹さんでPMCとか見ながら、トレーニングを管理していこうと思う今日この頃。

かぴばらさんのところの記事によると
ATL（Acute Training Load）は70以上だとオーバートレーニング、
CTL（Chronic Training Load）は１週間で3～7ぐらいまでの上昇程度が適度
TSB = CTL－ATLで、+5位がベストコンディション、-20以下は疲労状態
とのこと。
そう難しいことを考えなくても、PMCのモデルは一次遅れ？のインパルス応答、ということを知っていれば、あとは指標として置き換えているだけ、というのが分かりやすい理解かと。
というかパワートレーニングバイブルを買ったのにまったく読んでない・・・

本当は時定数とか個人で違うんでしょうからそこも合わせないと良いモデルではないのですが、とりあえずデフォルトで使ってます。
まぁ、そもそもFTPもちゃんと測ったことないですしね。

良いガンダムだった

全話見終わりました。

第1期が終わったときは心配だったのですが、今回は良いガンダムでしたね。さすが長井監督。


というわけで、スクリプトを組んで、ユーフォニアムを見ながら自転車をこいで、スクリプトの確認をして、また自転車をこいで、ガンダムを見て過ごした週末でした。

けものフレンズのMMDが本家を超えていたり、OPを作曲の人が歌っているのがとても良かったりしました。

よい週末です。

assumefps

・・・もしかしてavisynthってサブ関数でfpsを変更してもメイン関数のパラメータ(FrameRateとかFrameRateNumerator)は変わらない？

ちょっとEasyVFR2のAssumeFPSがいつも30fpsなのが気になっていろいろやってみましたが、なんとなくそんな感じ。
まぁいいか

追記
単純にEasyVFR2の使い方が分かってなかったからと思われます。
(いまだに正確にわかっていませんが・・・)
改めてスクリプトを読見直したところ、EasyVFR_Create時に引数にbaseclipを取るのですが、指定しないとカレントのclipになります。
で、最後のクリップがfps変更前のものの場合、そのfps変更前のものが使われる、というだけの模様。
なので、多分↓で行けると思う。

今まで
v001=Trim( 0, 6345).VFR24()
v002=Trim( 8144, 8264).VFR24()
・・・

all=EasyVFR_Create(v001,timecode)
all=all.EasyVFR_Append(v002,timecode)
・・・

変更後
v001=Trim( 0, 6345).VFR24()
v002=Trim( 8144, 8264).VFR24()
・・・

all=EasyVFR_Create(v001,v001,timecode)
all=all.EasyVFR_Append(v002,timecode)
・・・

赤い部屋

小学校の友人と行ってきましたが、脱出できませんでした。
もうちょっとだったのですが・・・

残念！

王滝？

中津川に行った会社の同僚に誘われ、なぜか出ることになりました。42kmですが。
なんでだろ・・・謎です。

MTBを購入、という選択肢もあるのですが、今のところシクロで行けるんでは？と考えています。
SDAということで、シクロでほとんど山道を走ったことのない人がどこまでいけるかがテーマというところでしょうか。
ちなみに、僕の実家は山の中(未舗装路)にあるので、通学時はママチャリでドリフト(というかロックしてただけ)とかしてました。
そんな慣れもあり、何とかなるのではないかという淡い期待をしています。

現時点での課題
・10%超の上り
→美ヶ原とか登ってるし、シクロには34-32Tがあるからいけそうな(普段は28T)
・砂利道で10%超
→・・・・チャレンジで。
・ダート
→ただのダートであれば別にタイヤが太ければ問題ないのでは？石とかごろごろしてるところは・・・
・42km
→どうだろ？

ちなみに、最近の山道経験としては3年ぐらい前に紅葉狩りに行って道に迷って林道を6km位？(200m位登った)23Cのロードで走ったという記憶が。
そういえば下りでブレーキかけていたらすぐに手がしびれてきましたね。
まぁ40Cのタイヤ・カンチブレーキでいけば大丈夫でしょ。
後は石だけです。

あそこに練習しに行ってもよいですね。


そして、wiggleでWTB nano 40cを買ったらHARIBOが入っていた。
どうやら、たまにおまけでついてくるらしい。

タイヤを装着していたら「リム内径はETRO17-23」と書いてある。
・・・僕が今持っているホイールは基本的にちょっと前のロード用。
そして(おそらく)今回ぐらいしか使わないと思われる40cタイヤ用のホイールを買うつもりは今のところない。(17mm=ワイドリムは最近の流行でロードにも使えますし買ってもよいのですが・・・)
で、つけようとしていたのはETRO15mmのWH6700。
あれ？リム壊れるんじゃね？(リム幅が小さい場合、幅広なタイヤに対して極端にリムで狭めることになるため過大な応力がかかる)
まぁ、11sが使えないWH6700の使い道に悩んでいたところですし、空気圧も推奨2.5-4barのところを3bar位で使えば何とかなるかな？
その辺は自己責任で逝ってみましょう。
この件もあって、今更ながらnano 40cをTCS lightにしなかったのを後悔始めましたが、(チューブの重さが1個170g位なので結構馬鹿にならない・・・)
そういえばTCSにするかどうか悩んだ時、「重さもほとんど変わらないしなんかメリットあるんだろうか？」とか思っていた記憶が・・・
すいません、チューブの重さをすっかり忘れていました。

シンクロシフトになった

6870ですが、シンクロシフト対応になりました。

Cyclowired
サイクルスポーツ

最初ファームを最新にしてもできねぇ、と思ってたのですが、ジャンクションのボタンをダブルクリックすると切り替わることを知りました。
うむ。

後はスプロケを14-28と12-25と買わなければ・・・

3.5年越しに

録画スクリプトに無音判定を追加中・・・。

logoguilloでも無音判定に対応しているものの、出力を無音区間でマスクしているだけ、というような話をどこかで見かけた記憶があるので、無音区間判定にミスったら出力が誤差るな、と思って使っていませんでした。

いま改めていろいろ試してみると、実は無音判定をフレーム単位(30fps)でやるとミスることがある気がしてきました。
CMの切れ目なのに、無音区間がない、という判定がされることがあるので。
で、フィールド単位(60fps)で無音判定やればよいんじゃね？
実写の編集ってフィールド単位でしょうし。

・・・やっぱりなんかlogoguilloの挙動が怪しい。無音区間リストを指定するとなぜか先頭のロゴ判定をミスる・・・。
(20フレームが切れ目なのに、0からロゴ判定する 無音リストを指定しなければちゃんと20から、と判定してくれるのに)
無音リストでは3-20まで指定されているのに。

なんかの実装上の都合があるのかもしれません。
ひとまずlogogulloに無音リストを指定するのはあきらめて、後段のスクリプトで対応するようにしましょう。

・・・無音リストってすごいですね。
ものによるんでしょうが、CMパターンマッチングだけでロゴを使わずにロゴ判定とほぼ同等の精度が確保できます。
ってCM消すだけならそりゃそうか。
これを組み合わせてより高精度に・・・夢は膨らみます。

休日の過ごし方

今日も平日休みだったので、午前中にスキーに行き、午後映画(SAO)を見てきました。
いや、4DXが公開初日だったので観てないしせっかくだから、と。

で、4DXにするより、音響を頑張った方が僕はずっと良いと思います。
動く席に合わせて頭も動かされるようにした方が良いのか、頭の位置は変えずに体だけ動かされていればよいのかとか、なんかにおいが毎回同じだなとか、確かに体は動くけど、この動きは映像の誰に合わせてあるのかとか、エアーのプシュッって音がするけどこれは音を聞かせたいのか局所的な風を起こしたいのか、とかいろいろと考えながら見ていましたが。
4DXの使い方は興味深くはあるのですが、今回の使い方は何ら必要性がないし、一体感もあまり感じられませんでした・・・
あくまで個人の感想なのですけど。

映画館の生き残り策として「体感型」は良い手法だと思うのですが、有効なコンテンツとそうでないものがあるのではないでしょうか。
単純に映画館に2回来てほしい、という目的で作っていないかという気がしてしまった今日この頃です。
いや、僕は1回目ですが

まれによくある

foobarでmp3のタグが破壊されるようになることってよくありませんか？
2・3回経験している気がします。(前は単純な互換性の話だったかもしれませんが)

ある日はたとreplaygainタグとかつける(要はタグを編集する)と、foobar上で見る分にはわからないもののSTEPとかで読み込むとおかしな文字列が見えるようになったことに気が付きました。
32bitのHEX値がそのままASCIIとして書き込まれているようなので何かの値だとは思うのですが、あまり何の値かまで確認していません。
(ちゃんと間にはスペースが入ってるし)

バージョンが少し古かった(1.3.13)ので、最新版(Ver1.3.14)にしてみたものの変わらず。
昔はこんなことにならなかったのに、ということで1.3.5に戻したら治りました。
その後、1.3.11、1.3.12を拾ってきても症状が出ず。
ということは1.3.13の変更が影響しているはずなのですが・・・

1.3.13の変更内容

Corrected 1.3.12 regression causing certain DSP configurations to crash.
New utility commands to optimize file layout & minimize file size.
Improved compatibility with certain internet radio stations.
Updated FFmpeg to 3.1.4.
M4A file format compatibility fixes.
Enabled WavPack 5 DSD decoding.
Fixed a bug in Converter causing conversion to a root folder of a drive to occasionally fail.

・・・なんか関係するもんあるの？
1.3.10ではmp3タグに関する変更が入っているので可能性はあるのですが

M4A file format compatibility fixes.
辺りでしょうかね。
それとも単純なリグレッションでしょうか。

170319追記
と思ったら1.3.15で修正が入った模様
まだbetaなので試してませんが。

1.3.15
Tag manipulation improvements.
When editing tags of iTunes-encoded M4A files, excess padding (often as much as 32 kilobytes) will be removed.
Better handling of WMA “rating” field.

日曜大工

先日自転車のコンポを6870に変えたのですが、お店にやってもらったのにフロントの変速が微妙・・・
トルクをかけたままインナーからアウターに変速させようとしても上がってこない。
機械式の時はちゃんと上がるように調整していたのですが、お店が適当にやったのか、と疑って自分で調整してみました。
(調整値が25段階、中央値13のうち「1」になっているという衝撃の事実が気になりすぎて)

結論としては別にお店の所為ではなく、フレームが悪い、もしくは6870の調整代が6800より狭い、ということが判明。

フロントディレイラーはフレーム直付けなのですが、そのマウント部の位置が悪く、もうちょっと外側じゃないと調整代が全く取れない(というか足りない)状態に。
というわけでマウントにシムを挟めばいいんじゃね？と計画中。
最初アルミ板を切ろうかと思って、次に加工しやすいプラ板を挟めばいいんじゃね？と思いつき、けどよくよく思い返してみるとヤング率が数十倍違う。
どれぐらい圧力がかかるかにもよりますが、ディレイラー部で100N(10kgf位じゃね？という妄想)ぐらい出て、マウント部の面積は200mm^2ぐらい(すごく適当)でしょうから1GPaだと0.05%位歪み、2mm位シムを入れるとすると・・・いや、問題ないか。

後はネジの長さをどうするか・・・1mm程度なら別に大丈夫だと思いますが・・・M5ならかかり代は5mm程度あれば良いのですかね？
よくわかりません。というか変な方向に進み始めている気が。
とりあえず気にせず行ってみましょう。まずはネジ深さを確認して1dも取れないようだったら考えます。

というわけでネジを外したところで計画倒れに終わりました。
何かというと、フレーム側のネジ受けの頭がフレームより出ており、さらにそのネジ受けは面が出ていない(というか出なくていいように皿ネジになっている)ので、シムを入れるならこいつらを回避する必要があるのですが、マウントの幅とほぼ同じ大きさのため回避しようとすると完全にはみ出すことに。

とかいろいろ考えましたが、頑張って調整すればよいような気がしてきた。
実は何とかなるんじゃね？

Ryzenでそのうち組もうと計画を・・・

たまたま発売日にお休みだったので、Ryzenを買いに行ってみました。
が、事前情報通りX370マザーの種類がなく、入荷数も少ない(行ったときはまだありましたが)ので、別に全く急いでいない僕は使いなれたASUSのマザーが潤沢に出回るまでまってからでよいんじゃね？と思い直してそのまま帰ってきました。

どうもAVX2周りがintelの実装と異なるようで、現時点ではうまく最適化が働かない？のかなという印象。
AMD「Ryzen 7 1800X」はIntelの牙城を崩せるか?
ベクター処理はうまく動いていそうなので、単に最適化の問題なのであればx264,265の最適化を待てばよいだけですし。

というわけで、来る日に備えて8コアを使い切れるようにスクリプトを改変せねば。
・・・まずは今のまま、処理を見直しますかね。
と思ってプリプロセスの部分の見直しに着手。
僕のエンコードは無駄にプリプロセスに20%近くの時間をかけているため、まずはそこを並列処理させ、そののちに本体も、という計画。

というわけで、並列処理をやるにはどうするかを考えていたのですが、batでやるよりもperlにやらせた方が楽だな、という結論に。
というわけで、use threadsを勉強中です。

perlthrtut - Perl におけるスレッドのチュートリアル

本体は複数エンコードを走らせるぐらいしか思いつかないので、CMカット部分で別処理でエンコードさせようという計画です。
・・・なんとなくiピクチャが増える分エンコードサイズが増えそうな気しかしないですが、それはおいおい。

とか言っているうちにすべてをperlで書き直したくなってきた・・・いや、やらないけど

ひとまずネット上の情報を参考に、下記のようなコードに。

foreach my $i(1 .. $num){
my $thread = threads->new(\&divenc,$i,$num);
push(@threads, $thread);
}

foreach(@threads){
my $retdata=$_->join;
}

sub divenc{
}

とりあえず4並列にさせていままで10分かかっていたものが4分で終わるようになりました。
24minをエンコードするのに45分かかっていたものが40分に。
単純に並列数に反比例しないのは、まぁ仕方がないですね。