Winrar(64bit)がフリーズする

何故かは知らん。

日本語？ファイル名が含まれるファイルを圧縮した書庫を同じ実行ファイルでを開くとファイル一覧が表示できないっぽく、プログラムが応答なしに。
日本語全部というわけでもなく条件がいまいち不明ですが・・・

とりあえず5.61でも32bitバージョンか、x64の5.30以前？辺りは大丈夫っぽい。

そういえばwinrarは買ってからもう10年近くたつのにいまだに最新版を使わせてくれます。(まぁ、もともと永久にバージョンアップ無料、と言ってたからね)
ってかこれで儲かるんだろうか。
バージョンアップで金をとるシステムが一般的になってきた昨今からするとそんな事を思ってしまいます。

ついに使えなく・・・なっていはいないけど

zip/pdfの画像ビューアにずっとhamanaを使ってきてたのですが、
Win10-1809にアップデートしたら一部の設定が読み込まれない？ような状態に。
再度設定しなおせばそのセッションだけは使えるのですが、プログラムを再起動すると同じ事になります。
もうそろそろ潮時でしょうか・・・

というわけで探してみたらNeeViewというのが自由度が高くてよさげ。
起動に時間がかかるのが難点。

HoneyViewも必要なことはできるのですがカスタムしたくなる人にはあまり向かないかも。
しばらくNeeViewを使ってみて様子を見ましょう。

UnsharpHQのソースを見ていたのですが

僕はシャープフィルタにUnsharpHQを使っているのですが、ソースを眺めていてバグにしか見えないコードが・・・
あと、せっかく読んだの忘れないようにメモ

MT

MT化で早くなるぜ！
→ついでにバンディングを直そう
→あれ？dfttestのdither1だけじゃ足りなくね？
→dither2以上か・・・これってMersenne Twisterっていうよくわからんアルゴリズム使ってるんだよね・・・
→最近はSIMD化されたの(SFMT/dSFMT)があるらしいぞ
→開発者は日本人なのに日本語の関数説明ページがない・・・
→float精度で良いなら従来の方が軽いような？
→ループで呼ぶからダメらしいので、大量に生成してみたけど結局従来とあまり変わらないような？
というところで、元に戻しました。
使い方に依るのかもしれません

181216追記
→dffttestは最近16bit深度に対応した1.9.4.3があるらしい
→AVXで一部最適化されてるぞ
→その他もAVX化したら早くならんかね
→なんか速くなる時とSSEより遅くなる時とあるな・・・
→メモリアクセスがネックの場合、alignは大事なんですね
→使う関数はdither以外はあらかたAVX化したし、もうこれぐらいが限界かな
→でもやっぱりdither処理が一番コスト高い・・・こいつ(Floyd-Steinberg)をSIMD化したコードはないものか・・・
→ってかMersenneTwisterとFloyd-Steinbergを両方呼ぶ必要ってあるのかな・・・
という疑心暗鬼な今日この頃。
一応だんだん速くなってきていますが、結局MTが一番効く気がします。

↓今のdfttest.dll(fftwは除く)の各関数処理時間
(1000フレーム処理時・サンプル単位はms なのでサンプル数/1000で[ms/フレーム]になります)

dither=2,opt=0,threads=1,align=64/AVX
名前	排他サンプル数	排他サンプル %
+ dfttest.dll	16,100	27.52%
| - dither_C_sub	9,739	16.65%
| - filter_0_AVX	1,300	2.22%
| - MTRand::reload	1,253	2.14%
| - proc1_AVX	1,026	1.75%
| - proc0_AVX	887	1.52%
| - removeMean_AVX	859	1.47%
| - addMean_AVX	344	0.59%
| - memcpy	271	0.46%
| - memset	250	0.43%
| - func_0	113	0.19%

とやっていたら、一部の関数にAVX2の命令(_mm256_cvtepu8_epi32：鯖のSandyBridgeでは使えない)を使っていた・・・orz
→というのを直してもまだ動かず。
なんで？と思ってたら、浮動小数のFMAもHaswell以降だったんですね・・・。
Haswellで、AVX2：整数、FMA：浮動小数が追加されたということ？わからん。

最近のツールを知る

春ごろにL-SMASH Worksを知って、これでいいんじゃね？でもaacの同期を取るためにはちょっと手間だよね、とか思ったのですよ。

で。

世の中やっぱり誰かが同じことを思うようで、例によってmakiさんがts_parserというツールを作ってくれていました。

ts_parser.exe --mode da [options] <input.ts>

[options]
 --output <string>          出力名 を指定 (未指定の場合は入力名<input>を使用)
 --delay-type <integer>     ディレイタイプ を指定
        0 : None                無
        1 : GOP Key frame       MPEG-2 VIDEO VFAPI が該当
        2 : GOP 1st frame       DGIndex/DGDecode   が該当
        3 : 1st Video frame     Libav Reader       が該当 (L-SMASH-Works)

とのことで、まさに

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

でどうしようと思った僕の疑問をすべて解決してくれました。

世の中情報って大事ですね。危うくTSを解析してaacを抜き出すにはどうしたらいいかとか考え始めてました・・・

そしてmakiさんの補足を読んでいて書いてあったこと

[補足4]
本ツールを使用せずに、ts2aac でL-SMASH-WorksのLibav Readerに合わせる方法を提示。

(1) MurdocCutter でTSを全体選択して出力
(2) ts2aac で -B オプションを指定してAACをDemuxする

・・・ホウ・・・

なんでみんなやってないのかようやくわかった

Avisynth+でちゃんとMT化ができる(しかも安定して動きそう)ということを知りました。
というわけで、プラグインの個別最適化はそれ単体で律速になるような重量級のものでない限り、コア数を増やせば解決できるということなんですね・・・

で、

SetFilterMTMode("DEFAULT_MT_MODE", MT_MULTI_INSTANCE)
#SetFilterMTMode("dfttest", MT_SERIALIZED) #same story as with sangnom2
SetFilterMTMode("TFM", MT_SERIALIZED) #MT時は外部ファイルへの出力スレッドが呼ばれないので それを使わなければOK？
SetFilterMTMode("TDecimate", MT_SERIALIZED)
SetFilterMTMode("NNEDI3", MT_MULTI_INSTANCE)

MPEG2Source(vsource,idct=4)
TFM(mode=1,order=-1,PP=1,slow=2).TDecimate(mode=1)
FluxSmoothT(temporal_threshold=3)
Spline144Resize(resizex,resizey)
block=32
dfttest(sigma=4,sbsize=block,sosize=block/2,tbsize=1,dither=2,opt=0)
unsharpHQ_v05_x86_unsharpHQ(SHARPSTR=2.4,THRESHOLD=40,SMOOTH=0)

Prefetch(4)#←これがMT化に必要 昔の感覚でやると気づかないので注意

というスクリプトで50fpsを超えるようになりました。
・・・28→32fpsで喜んでいたのが馬鹿らしくなるほどの効果ですね。
そしてエンコード速度が1920x1080のソースでも30fps超が出るようになりました。

世の中、コアを増やせば簡単に速度UPできるから、dllのopenmp化とかが流行ってないのでしょうかね。
・・・ぼくもコアを増やさねば・・・

Avisynth+のMTって何なのかわからなかったのですが

AviSynthPlus
Avisynthには2.6を使っていたのですが、avisynth+というのもあります。
Avisynthは本家が止まり、その後継プロジェクトがあったのにどれも最終的に更新が止まる、というイメージがあって、こちらもプロジェクトがどこかで頓挫した・・・と思っていたらprinterfさんという方がメンテを継続しているようです。
doomのスレも賑わっているようでした。

で、なんでそんな話をし始めたかというと、
例によってdfttestのチューニングをしていたら実はバグってることに気が付いてorzとかなってたのですが実はベクトル化よりもMT化すればいいんじゃねという当たり前な結論に至って#pragma omp parallelをやってみたらメインPCでは上手くいったのに鯖でうまくいかなくて(というかスレッド化のコストが高すぎるのかCPUを100%占有した上にやたらと遅い)なんでだろうと思い、その原因がメインPCではavisynth+を使ってて鯖は2.6無印だったのが原因だった
ということに起因しているのです。

というわけで、MT化したプラグインを使うならavisynth+をインストールしましょう。
32/64の共存もやりやすくておすすめです。

ちなみに、dfttest(のdither)はベクトル化・・・というかパイプラインがストールしないように工夫するとかそんな感じのことをして、1440x1080を1000フレーム処理するのに元のコードだとdfttest単体で(fftw含まず)28sとかかかるのが、23s程に減らせます。
その中でdither部は8sを消費していて、dfttest.dllの中身では一番重い処理になっています。
ちなみに、この時
・fftw：42s
・MPEG2DecPlus：6s
・FluxSmooth:5.4s
・SplineResize：2.5s
・UnsharpHQv05：2.5s
な感じです。

これをMT化するのですが、MTのオーバーヘッドが約1s分ぐらいあるのかdfttestの時間は1sぐらい増える(24s位になる)んです。
が、処理速度は律速部分が解消され、27fps→32fpsへ向上します。(CPU負荷は32%ぐらいだったのが40%位に増えます)
MT化するに当たって本来1画面全体をdither(froid-steinberg)処理するのに対し、1画面を4分割して処理しているので、実は元と演算結果に差があるのですが、そもそもノイズを加える処理なので問題ないでしょ、という。

そういえばavisynth自体のmtを使ってないな・・・
これ使えばもっと早くなるんじゃね？
avisynthのmtって意味なくね？というのが数年前・・・5年前？ぐらいの記憶なのですが、きっとそこから変わっていると期待しています。
x264でCPUを100%使い切れてないのでちゃんと使い切ってあげようという親切心からこんなことをやってるわけですが、時代はどこまで変わってるんですかね。

→普通に別スレッドで呼んでくれているようで、コア数の分CPUを使ってくれそうです。
・・・ということはスリッパを買うしかない・・・！いや、9700とかでも良いけど


といろいろ調べていたら、やっぱりみんな考えることは同じみたいで、CMカット自動化ツール(joinlogoscp)とか、自動エンコードツール(Amatsukaze)とか、最近はいろいろ出てきているようです。(いや、前調べたのが5年前とかだから・・・)
https://github.com/nekopanda/Amatsukaze

やってることはおおよそ僕が自分用にやっていることと同じ(高機能だったり低機能だったりというのはありますが)なので、もう自分で環境をメンテしなくてよいのか・・・。
それはそれで寂しいものもありますが、誰かがやってくれるなら自分でやる必要はないですしね。

全然時代の流れについていけてませんが、ちょっと使ってみましょう。

ちょっと前の話ですが

AMDがNextHorionで公表してたらしいこと
【AMD】“Next Horizon”で7nmの“Zen 2”と“Vega 20”の詳細を発表

“Zen 1”では128-bit幅のレジスタを用い、SIMD命令を実行していた。この場合256-bit幅のAVX 2命令を実行する場合はスループットが1/2となっていた。
“Zen 2”ではそれぞれのコアのSIMDレジスタが256-bitに強化される。“Zen 2”の浮動小数点演算ユニットは2基の256-bit浮動小数点加算ユニットと2基の浮動小数点乗算ユニットを有し、おそらく2つの積和算を同時に実行できるものと推測される。

というわけでAVX2が伸びないのはこれが原因だったんですね、なんかアーキテクチャに問題があるだろ、とは思っていましたがそんな単純な理由だったとは知らなんだ。

当初の目的を見失ってる

・・・NASを運用して二年弱。
24時間動いてるパソコン(というか鯖)がある人には無用の長物じゃね？ということに気が付きました。

いや、わかってはいましたが、実に有効活用できてるとは言えない状況で、やってることはサーバのバックアップのみ。
その他の機能もいろいろあるんだけど、鯖でやってるのでNASにやらせることは何もない、という・・・

あれ？これ無駄じゃね？

というわけで昔の記憶を思い起こしてみると、もともと鯖のバックアップを目的として導入したような。
じゃぁいいのか。

晴れた日にすること

金曜は会社がお休みだったので鞍ヶ池～三河湖に行ってきました。
紅葉は真っ赤なよりも紅葉の緑黄赤と空の青のコントラストが楽しめるぐらいがきれいだと思うのですよ。

鞍ヶ池までトランポで、そこから適当に進みました。
一人なので出発はのんびり9:30頃、鞍ヶ池についた時にはすでに10:30頃だったのでいつもなら目的地についてる頃ですね。
天気は良かったのですが、全体的に山間で影になってるところだったので、ハーパン(上は長袖ですが、風は通すタイプ)で行ったのはまずかったかもしれません。
なんか寒い、と思いながら走ってた印象が強いです。
ログを見ると11:30に13℃や、13:30に12℃というログが・・・局所的に寒かったのは確かですね。全体的には17℃前後だったようです。

鞍ヶ池に行ったのは初めてで、香嵐渓に行った後は道が分からないので、何年か前のY'sのブログに乗ってたルートをたどって・・・
・・・あれ、今見ると、362号が川沿いでよいのでは・・・
どちらにしろ、途中からY'sの道(420号)とも違う道を走っていたので、どうも道を間違えてたようです。

477号？の途中で道が通行止めだったり、10%の坂が続いたりと、いろいろしましたがとりあえず無事に三河湖に到着。
337号は良い道でした。

三河湖周辺のお店にはサイクルラックが各所に用意されていたので、自転車で来る人が多いんでしょう。
途中のお店でイノシシ？が檻に入ってました。
僕は普通に今日は猪鍋だね、とか思いながら通り過ぎたわけですが、あとから調べると「ためよし君」というマスコットのようです。食べないんだ・・・

あと、三河湖周遊道路は要注意です。
奥まで行ってから折り返し・・・たら砂利道に突入しました。
僕はロードで多少ドリフトしながらでも気にせずガンガン進む方なのですが、気にする人は嫌がる道だと思います。
折り返してから7kmぐらいでしょうか 、その半分はダートでした。
帰りはゆるゆる？とR301を下って帰ってきました。
84km、1300m程で程よい感じです。


土曜日は会社の同期とぶらり香嵐渓へ。
途中でどう道を間違えたのか(というか今確認すると明らかに戸越峠と雨沢峠を取り違えていたとしか思えないルートを辿っていますが)。
・定光寺を超え、あれ、いつの間にか岐阜県に入ったぞ、と言いつつ南下し(R248で)大量のトラックで怖い思いをしたり、
・道の駅品野まで4kmらしいがこんな南北に走る道だっけと言っていたらR363に繋がってて、何故か見たことのある道だけど細部が微妙に違わね？と言いながら最終的にはやっぱり見たことのあった道のようだ、といつの間にか雨沢峠を越えたり
・県道33号を通って香嵐渓へたどり着く頃には結構足に来ていて帰りが大変、という。
僕はいつも品野のあたりで迷うのですが・・・何がいかんのでしょう。
帰りはグリーンロードをたらたらと。
何気に136km、獲得標高1500mでした。

天気は晴れという予報の割にはほとんど曇っていてなんか微妙でしたね。

そして、絶望した

LGの27UK850を買ってみました。

そして、絶望しました。

自分でもなんでそうしたのかわからない

大鯨を延々と演習とか3-2とかでレベリングし続け、ついにLv99になったので、秋刀魚期間中にカッコカリしよう、と思ったはずなのですが、
何故かカッコカリではなく「改装」ボタンを押していました。
完全に頭が働いていなかったらしく、ちゃんと改装画面でSSを取りつつ、押していました。

・・・仕方がないので龍鳳でカッコカリして(1隻目は龍鳳改でやったので)、次の大鯨をレベリングし始めました・・・・

同じ人かと思った

古川博之さんが監督・作監・キャラデザをしている作品のキービジュアルを見て、
あれ？これは倉嶋さんでは？
と思ったのですが、＠wikiによると「直接の後輩」とのことでした。

そういわれると少し違う気もしますが・・・似てますね。
・・・そして二話が・・・メルメドを思い出しますが、古川さんのツイートも大変そうです。
「悪魔が乗り移っているかのような様相であがってきた少女の顔を修正しながら、これエクソシストやん！って思いながら鉛筆を走らせてる(´▽｀)」
・・・頑張ってください


あと、プロダクションIMSが破産手続きとのこと・・・
はいふりはアニメが動いていて良かったので(ストーリーは微妙ですごく商業的に失敗な香りがしたので応援の意味を込めて)BDを全部買ったのですが、残念です・・・

BS11の番組で名前を変換してくれなくなった

SCRename名前を変換してくれない作品がある、とおもったら単純にBS11の名前が
BS11デジタル→BS11イレブン
に変わっただけだった。
というわけでSCRename.srvを直しました。

名前が変換できないのはBS11のみだというのに気が付いたのがポイントです。
最初は自分でmodしている部分がなんか悪さをしているのかと思って調べてしまった・・・

E2を73回まわったのにE3攻略中に出た。

E2でも甲なら岸波が出ると聞いてクリアしてからE2を回ってたんです。
なかなかでないので、疲労待ちが面倒だからE3乙の攻略を進めながらやろう、と思っていたら、
E3乙-2攻略中に出ました。
・・・
いや、そんなもんですよね。

まぁ、大東、三隈が各二人来たのでよしとしましょう。

身に覚えがありすぎる

最近タブレットの調子が悪いのですよ。
バッテリーが70％あったはずが突然電源が落ちたり。

で、amazonさんに聞くと交換用の電池が売っていたので買ってみました。
電池が1800円、携帯をばらすためのツールが200円だったので合わせて200円ぐらい。

そして開けてみたところ・・・

何か刺さった穴がありますね。
ええ、覚えがありますよ、GW頃にsimカードを外そうとしてマイクのところに棒を突っ込んでいたという記憶が。

というわけで自業自得でした。

ちなみにちゃんと治ったみたいです。
やっぱり電池の性能は新品のころに比べれば落ちますが、まぁ、許容範囲でしょう。

購入してから丸5年たちますが、最近電子書籍をタブレットで読むようになったので、またしばらく活躍してくれることでしょう。

2時間ぐらいが良いんじゃね？

今日奥美濃のあたりを走ってきたのですが、2.5Hr、52km程でTssが170超。
これはとても効率が良いのではないでしょうか。

前半は山岳(でアウター縛り)、後半平坦なのですが、L5以上のトレーニングがやりやすい感じがします。
固定ローラ台はL4はやりやすいのですが、それ以上はなんかやりにくい感じが・・・ちゃんと業務用扇風機を買えばやりやすくなるのかも、と思いつついまだに普通の扇風機なのがいかんのですかね

aaceditで正のdelayって

delay値が正だった場合、aaceditの実装はなぜか「ファイル末尾を削る」になっています。
なんででしょうね？
僕のイメージでは「ファイル先頭に無音を挿入」なのですが。

で、FakeAACWavは「先頭に無音を挿入したうえで末尾を削る」になっています。

・・・末尾を削る必要はあるんですか？よくわかりません・・・

とか思いつつ、aaceditに無音を挿入する変更を加えてました。

元々は某アニメで直前の番組が5.1chだったので音声先頭10フレームぐらいが5.1ch、その後2ch、となっていて、切り出したaacでは音声がちゃんと再生されなかった、というのを治そうと思っただけのはずなのですが、なんか全然違う方向に脱線してました・・・

そして、別にFAW使えば良いんじゃね？ という真実。いや、知ってたけど。

dfttestをチューンしてみた

VS2017にしたらなんか遅くなったけど、いろいろやってたらまた同じぐらいの速度になったので
そして、githubのところにUPしてみた。

自分の環境で問題になる不具合がなければあまりメンテする気がないですが。

オリジナル(1.9.4)に比べてdll単体のコストは3割ほど減ってるはず。
シングルスレッド部分がボトルネックになっている環境であればこれで多少早くなるのでは？

MPEG2DecPlus_MPEG2Source(vsource,idct=4)
FluxSmoothT(temporal_threshold=3)
Spline144Resize(resizex,resizey)
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)

のスクリプトでavs2pipe -benchmarkをすると28fps程＠i7-4790K
dither>=1には効果があるけど他はあまり変わらないと思います。

電子書籍を買ってみた

ずっと本は紙派だったのですが、先日電子書籍を買ってみました。

買ったのは13巻でているシリーズもの(というかオーバーロード)の1巻だったのですが、読み終えると次の巻を購入しますか？と出て来て、ワンクリックで買えるようになっています。
で、嬉々としてポチるとそのままシームレスに読み続けられるため、延々と終わらない、という・・・

これは危険ですね。
便利ですが。

意外と当たり

はたらく細胞が意外と面白い。

そして、ヒトの細胞は60兆ではなく37兆個ぐらいらしい。という論文が2013年頃に出たそうな。
T細胞もヘルパーTとキラーTとあるらしい。

まぁ、僕の頭の中は90年頃の人体Iでできているため、28年間でいろいろ分かってきたのでしょう。

それにしてもEテレで再放送しそうな気がして仕方がない・・・

投げ銭

ipv6の本(pdf)を無料で配っているらしいです。
出版費用をクラウドファンディングで集めたとのこと。
今はBOOTHで投げられるらしいんので、とりあえず読んでからいくら投げるかを考えます。

で、
いいから殺せ。後はこっちでなんとかするから
を読んで爆笑してました。
その会話はヤバい。
ありそうでヤバい。

GPPがいやなので

RX580を買ってきました。

ってかブラっと大須に行ったらRX580が30kだったので、Freesyncも使えるしこれならいいかな、という。
Watt/Performanceは大幅にGeforceから劣りますが、選択は自由です。

という割にはGPPに賛成らしいMSIを買ってしまうのは節操がないからですが。
変な特需が落ち着いて、最近はようやく当初の想定価格になってきたはずですしね。

GPPについてはこちらで読めます

ZERO

・・・iframeって使えたっけ？
と思ったら使えているみたい。

本家への不満がたまりにたまった結果、別杯を作ったようです。
というか、本家も20回で区切りをつけたのでしょうか、いまだに告知がないような。
まぁ、一般参加者にとっては楽しめればOKですね。

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を見て合わせるのが確実なんでしょうね。
ではそのためのスクリプトを作らねば。はて・・・どうしてこうなった・・・

あと、lwiを眺めていて知ったのですが、tsはPTS(再生時間)ではなく、DTS(デコード時間)の順番でデータが詰め込まれているようです。
Bは前後のPorIがないとデコードできないため、BBIBBPはIBBPBBとでいう順でデコードされます。

再生順に並べたとき
PTS  123456789ABCDEF
     BBIBBPBBPBBPBBP
DTS  120453786AB9DEC

デコード順に並べたとき(tsに入ってる順番)
PTS 312645978CABFDE
    IBBPBBPBBPBBPBB
DTS 0123456789ABCDE

ということはみんなPTSでは"BBIBBPBBPBBPBBP"、DTSでは"IBBPBBPBBPBBPBB"という並びで話をしているんでしょうね。
どっちも"BBIBBPBBPBBPBBP"になってるといえばそうなのですが・・・。
そんなことを考えていると、完全なフレームを得られるところから始めるm2vの実装も、存在するフレームからデコードするというL-SMASHも、GOP単位で考えようというDGIndexの考え方も、どれも正しいような。考え方の違いでしょうね。
いや、なんでこんなことを考え出したかというと、TSに入ってるフレーム(DTS)がBBIBB・・・で始まったときに5フレーム目まで正しい映像が出てこない、というのはなんでだろうと思ったので。(3つ目で完全なフレームが得られるのかと思ってた)

お前は狙われている！

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

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

！？・・・何事かと確認するとフロントをサイドカットしていました。
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絡みのは治ってないけど。