突発ビワイチ

金曜にどこ行こうか、と話をしていて、土曜日の朝高速の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絡みのは治ってないけど。

クリアカード

日本引きこもり協会がまた作ってくれるようです。

丹下さんや岩男さんなどのキャストは大体そのままで、とても懐かしい感じが・・・
制作もマッドハウスで、監督・脚本は昔のままですが、キャラデザはさすがに違うようです。
高橋さんや藤田さんよりも原作側に寄せてきていますね。
今の技術で作ってくれるのはありがたいことです。

一番の懸念は日朝のため時刻テロップが入るような気がすること・・・金曜に再放送するのでそちらが保存用でしょうか。

楽しみにしています。

というわけで適当になっていたBSP用の設定を煮詰めなければならないということが判明。
ふむふむ・・・いや、全部手動設定でも良いのですが。

ちなみに、PVは知世編が好きです。

ちゅーぶレス

某英国の通販サイトで安売りしていたPrimeのRR-50を買ってみました。
チューブレスのタイヤを嵌めたことがない(完成車付属のSLR-1はチューブレスなのですが、パンクしたことがないのでお店で買ったまま)ので、試したいというのと、鈴鹿でやっぱりCC40Eはすごいな、と思ったので50mmだとどうなるんだろう、というよくわからない妄想に取りつかれたためです。(単純にリムハイトだけではないのはわかってますが(w)
本当はRP-50が良かったのですが、目立たない黒色は28kも値段に差があった(白なら15k)ので、スポークがcx-rayになるだけ？にそこまでかけられんな、と。
(一応ハブも変わるのですが、ストレートプルにするために違うだけで、ベアリング部は多分変わらないんではないかという妄想)
スポークの違いで剛性が、とかもあるんでしょうが、僕的には巡行時を楽にする、というホイールでガシガシ踏んだ時のフィーリングをどうのというのもナンセンスです。

とりあえず重量を測定・・・720g+900g=1620gで、カタログ値の1560gに比べると各+30g位。リムテープの分？

今回は温くいきます

E3 戦力ゲージ1発目で照月Dropして、輸送ゲージ4回目で春日丸が来たので、をぉ、これは幸先良いな、とか思ったらその後さっぱり。
一方で何故か瑞鳳が5隻も・・・
E3輸送ゲージ丙堀
加賀、愛宕、利根、春日丸、蒼龍、高波、長波、松輪、金剛、萩風、
長波、高雄、嵐、霧島、萩風、瑞鳳、瑞鳳、高波、蒼龍、国後、
矢矧、能代、最上、扶桑、日向、瑞鳳、長波、嵐、愛宕、榛名、
山城、扶桑、飛鷹、金剛、金剛、扶桑、伊400
まぁ、50回もかからず来てくれたので良かったです。
今回は欲しいものがないのでこのままE3も丙でクリアしてしまいましょう。

E4は乙ですかね。

3時間過ぎてからがつらい

4Hrの平均出力は今までとあまり変わらず、146Wでした。

前の記録によると180W程出せば9min前半が出ていたのですが、今回は同じ出力で10min前半。

4時間平均出力は変わらないのに、今回は風が強かったためか、10minを切ることなく、寒くて水分補給をしていなかったのがいけないのか3時間を経過してから出力が全くでなくなるという。あと腰とお尻が痛い。
まぁ、風速7m/sとかだったので仕方がないでしょう。

そしてやっぱり寒かったようで指ぬきグローブでは後半手が動かずに変速に苦労するという・・・
いや、電動でよかったです。

いろいろ新しくしたら速くなってきた

MPEG2DecPlusとUnsharpHQを新しくして、dfttestのdither_Cをもうちょっとチューニングしたら

MPEG2DecPlus_MPEG2Source(vsource,idct=4)
TDout =ScriptName+"_TDmetrics2.txt"
TFMout =ScriptName+"_TFMout2.txt"
TFM(mode=1,order=-1,PP=1,slow=2,input=TFMout,batch=true)
TDecimate(mode=1,tfmIn=TFMout,input=TDout,batch=true)
FluxSmoothT(temporal_threshold=3)
Spline144Resize(resizex,resizey)
block=32
dfttest(ftype=0,f0beta=1,sigma=4,sbsize=block,sosize=block/2,smode=1,swin=0,tbsize=1,tmode=0,twin=7,dither=1,opt=0)
unsharpHQ_v05_x86_unsharpHQ(SHARPSTR=2.4,THRESHOLD=40,SMOOTH=0) #unsharpHQ(STR=1.0)

というスクリプト(リサイズは1440x1080→1280x720)で28fps程度出るようになりました。(i7-4790@4.5GHz)
最適化対象はAVXで、AVX2用(FMA3を使う)にするともうちょっと(0.5%位？)早くなります。

何にせよ、ようやく実エンコード環境(x264と同時に走らせて)で24fpsを超えることができました(24.5fps)。
事前にTIVTCのhintsを求めてるため、本当のリアルタイムエンコードはできませんが(というかもっと時間がかかりますが)、

・・・あれ？
svml_dispmd.dllが見つかりませんとか言われる・・

確認していったら新しくしたNNEDI3_v0_9_4_47のnnedi3.dllがリンクしてるっぽい。
ってかintelってintelコンパイラか・・・
というわけでNNEDI3のノーマル版を入れたら治りました。
(ちゃんとreadmeに書いてあった・・・
Get Intel Parallel Studio 2017 redistribuables to use Intel versions.
https://software.intel.com/en-us/articles/intelr-composer-redistributable-libraries-by-version)

ついでにFluxSmoothを速くできるんじゃね？と思って探したらSSE化している人がいた！
・・・と思ったけど、x64専用になってる・・・
xmmも8以降がまんべんなく使われていて単純に32bit化するのは面倒そう・・・
いや、そもそも全部64bit化すればいいのか？とか悩みちゅう。


作ったdfttestはバグがありそうですし例によってバイナリ配布とかは面倒なので適当にdfttest.cのdiffから作ってください・・・↓