支援ツイート: https://twitter.com/aoirint/status/1491411617094897666 リターン: https://twitter.com/aoirint/status/1515225713825452032 リターンの追加ボイスを使って作った動画（シルシランド）: https://www.nicovideo.jp/watch/sm40364332

https://twitter.com/aoirint/status/1519680749531664384

適当に検索すると、ホストへの特権昇格を許す設定ばかり見かける。 自分だけしか使わないならば構わないかもしれないけれど、なんらかのCIを実行する権限さえあれば、ホストのroot権限をとれるというのは危険だと思う。 （コードレビュー必須でPRではマージ済みのCIが実行されるならいいのか…？） GitLabの公式Shared Runnerがやっているように、docker-machineを使うのがいいはず。 おそらくdocker入りの仮想マシンをCIジョブごとに立てて、privilegedなコンテナからブレイクアウトしても仮想マシンの外に出られないようになっていると思う。 GitLabはいろいろオープンなので、実際のShared Runnerの構成・設定が公開されている。たいへん助かる。 https://docs.gitlab.com/ee/ci/runners/saas/linux_saas_runner.html のだけれども、GCPでこれを稼働させるのはちょっと費用面がよくわからない…。 ツリー https://twitter.com/aoirint/status/1523826104343343105 https://twitter.com/aoirint/status/1524426103615500288

考えたこと・連想したことを、論理の破綻を放置してとりあえず書き出してみる。 データセット、保存したイラスト、素材、ゲーム録画ファイル、編集プロジェクト、電子書籍や資料のPDF。 こういった、ありふれたファイルの管理がすごく苦手だなと思った。 プログラムのソースコードならば、gitで管理せよ、で済ませることができる。これは5年以上使っているので、それなりに慣れているつもりだ。こちらは問題ない。 一方で、10年以上やっているはずの通常のファイル管理はすごく苦手だ。あるいは、苦手になってしまった。 この原因は、以下のようなものかもしれない。 どこにいてもファイルにアクセスできるようにしたい。すべてのファイルのバックアップをとりたい。 すべてのファイルをアップロードする。オンラインストレージ上にファイルがあふれる。 すべてを同期してはローカル容量が不足するので、複雑な同期設定が必要になる。あるいは、同期設定を前提とした複雑なディレクトリ構造にせざるを得なくなる。 ファイルの管理ができない。 物理的な移動なしでファイルにアクセスできるようにするというのは、利便性という面で間違っているとは思っていない。 まあコロナ禍以降、外出の減少によって意味は薄れているかもしれない。 GitHubやニコニコ動画などのWebサービスがどこからでも使えるように、自分のファイルをどこからでも使えるのは便利なはずだ。 実際にどれだけこの利便性を享受しているかというと、怪しいところではあるのだが、これを掘り下げるべきだろうか。 実際にそのすべてを使うかどうかはともかくとして、100MBを越えるファイルやファイル群を扱うことはままある。 これをSaaSでぽこぽこ扱っていたら、料金がすごいことになる。 そのために、自宅でNextcloudをホストして、8TBのオンラインストレージを確保している。 ほぼすべてのPCがデュアルブートになっている。 巨大な単一のオンラインストレージがあることで、どこにどのファイルがあるか、という管理をする必要がなくなる。 このファイルはあのPCの中のあのOSにしかない、ということがなくなる。どの環境に保存したかを覚えておく必要がなくなる。 一方で、何の目的にも、どの環境を使ってもよくなる。 それならば、一番スペックが高く、最も自分の目的で処理上のパフォーマンスを発揮できる環境ばかり使うようになる。 2021年まで母艦のUbuntuばかり使っていた。 一方で、2022年からWindowsでしか動かないVOICEROIDを使い始めたので、それを理由にWindowsをメインに使うようになった。 プログラムを集中して書くときはWindows環境は処理上のパフォーマンスが悪いので、Ubuntuに切り替える。 それでも最近では、Windows環境を使ってもいいんじゃないかと思ってきている。 いまのところプログラムを書く目的が例外ではあるが、環境によって目的を分ける、目的によって環境を分けるということができていない。 すごくファイルがごちゃごちゃしてしまう。 いまはある程度整理した・整理するようにしたけれど、Twitterで見かけた画像とか自分で撮った写真をフラットな単一ディレクトリに保存していて、1ディレクトリに何千とか何万とかのファイルがあった。 同期の仕様とかアプリの仕様とか保存時の手間とかでそうするのが楽だったのだけれど、とてつもなく扱いにくい。 同じことがメモアプリにも起きている。Twitterでファボしたツイートを、IFTTTでEvernoteに自動保存するようにしていて、数万件のツイートが単一のノートブックに保存されている。また、訪れて何か得るものがあったURLをすべてPocketに送っていて、数十万件のURLが分類されることなくフラットに保存されている。Joplinでは、InboxやArchivesというノートブックが、ほぼ分類上の意味を持たずに数百件・数千件のノートが保存されていたりした。これはさすがに整理したが、整理したことの恩恵をあまり受けた記憶がない。これでは整理した意味がなかったのではないかとも思っている。 巨大な単一のオンラインストレージがある環境で、目的意識をもつことは難しいのか？ 最近は、「数字_大分類/数字_小分類」というようなディレクトリ名をつけて分類している人を見かけたので、試しに真似てみている。Joplinでは、これ以前に同様の分類をしたけれど、恩恵を受けられているかは怪しいのだが、ファイルシステムでは違う結果が得られるのではないか、と思った。 この方法をとると、このディレクトリをファイラーで開いている、その間はこの作業をしている、というフレーム・目的意識を持つことができそうだと思った。 最近、Workspaceという同期ディレクトリを作った。この中で番号付けし、分類したディレクトリ構造を作っている。Documentsも考えられるが、特定のOSでしか意味がないファイルなどOS依存の構造をもっているため分けている。 こういう取り組みはこれまでに何度もやって、使わなくなって破綻していた。 なぜ使わなくなったかというと、分類されていないために使いづらかったからだと思っている。 これまでは分類はいずれ破綻する、という想定のもと、分類しないことにしていたのだ。分類が破綻したり再分類が必要になるとパスが変わってしまう。様々な環境に同期する都合上、パスが変わることは問題にならないのではないかとも思うのだが、パスが変わるのはあまり気分がよくなかった。 GitHub上のリポジトリも200以上あるが、最近他の人を参考にwebサイト管理用のリポジトリをorgに分割した以外に分類はしていない。 分類しないことによって、思考の枠組みがなくなってしまったのではないか。 永続化の目的でしかオンラインストレージを使わなくなってしまったのかもしれない。 何か作業をすることが減ってしまった。ひたすら永続化し続ける。その状態をなんとかしたかった。価値のある作業をするようにしたかった。 根源には、いろいろなことに対するモチベーションがすごく落ちているということがあるのかなと思った。 それになんとか対処したいというのが、ファイルの管理ができないという問題意識につながっている。 ある意味では、テスト前に部屋の掃除をしたくなるとか、新しい文房具セットを買ってみたくなるとか、というのと同じなのだと思う。つまり意味がない。 すごく飽きっぽいのかなと思っている。飽きっぽさはずっとありそう。簡単に触れるところだけ触って、深淵には立ち入らない。すごくそれが好きだ、ということがない。なんとなく触って、飽きて終わってしまう。そういうことばかりなのではないか？ 日記を書くのが無理だ。なにか印象的なことがあったときに、その感想を書くくらいはできる。それに何時間もかけることもできる（逆にかかってしまう、のだが）。だけれど、日記を書くためにいろんなことをしてみるとか、感性豊かにするとか、そういうことはできない。書くことがないから書けない。 絵を描くのが無理だ。なにか好きなものがあったときに、突発的に下手な絵を描くことはできる。それに何時間もかけることもできる。けれど上達するために継続して少しずつ絵を描き続けることができない。 プログラムを書くのが無理だ。なにか必要なスクリプトがあったときに、一回きりあるいは変えずに使い続けるだけのスクリプトを書くことができる。それに何時間もかけることもできる。けれど価値あるプログラムを計画して書くことができない。アイデアもないし、アイデア出しもしていない。作業中のPRも放置してしまっている。 動画を作るのが無理だ。一応の撮れ高があったときに、一回きりで十時間前後かけて動画を作ることはできた。けれど新しくネタを考えたり、ブームに乗ったりしていない。一応まとめればほかに1本作れそうなのに、30秒のクリップとかいって、まとめる時間をかけなかった。 この文章だってそうだ。 自宅のインターネットがたびたび不安定になる。 これもプライベートネットワークにストレージを置きたい理由ではあるのだけれど、そうはいってもインターネットにつながらなければどうせ作業が難しいだろう。インターネットを経由すると遅い、というパフォーマンスは理由になるかもしれないけれど、それが問題になるほど重いファイルをやり取りするかというとしない気がする。出先で使いたい場合にモバイル回線の容量をあまり使いたくないというのはあるかもしれないけれど、転送速度制限がかかることをあんまり気にしたことがない気もする（もともと遅いのでは）。 オンラインストレージ以外に、ファイルが添付できるWikiも考えられるけれど、サイズの上限は数MBあるいは数十MBで、おそらくセキュリティや濫用防止の目的でファイルの種類も制限されることはままある。 これは可能性があって、ファイルにそれを説明する文書を添付できる。オンラインストレージはこれが難しくて、ただファイルをおくだけで、まともに分類できていなかった。なにも禁止されてはいないのだけれど、おそらく面倒くさいからだ。NextcloudにはディレクトリのREADMEを作る機能があったりするけれど、まあブラウザ上で見ることになるし取り回しは悪い。 結局、これまでもできたところでやらなかったのだから、Wikiもまともに作るわけがない…。ファイルサイズの制限とか、ストレージ肥大化とかは問題にならなくて、やらないのは面倒だからなんだろうなという感じがする。 ドキュメントを書くのもすごく下手だ。 画像とテキストを組み合わせたいとか、いろいろ難しい。 またEvernoteを有料契約してしまったけれど、あまり使えている気もせずに、こういうメモをScrapboxに書き出している…。 技術記事を書いても論理破綻とか脱線とかしかしないんじゃないかと思っている。 イーブイを肉じゃがに進化させたけど、エナドリも飲んだし砂糖が多すぎるかもしれない…。 上に行ったり下に行ったりして文章を書くと絶対流れが破綻する。 先にプロットを決めて書くといいと思うけど、それが面倒くさい。 プロットを作った時点で満足するか、途中で脱線してプロットが破綻する。 結局ほかにやらないとならないことがたくさんあるのがよくないんだよな 誰かと時間を約束しても守れる気がしない

OBSには、音声を複数のストリームに分けて録画する機能がある。 Shotcutを使って編集しているのだけれど、複数の音声ストリームをうまく扱えないでいる。 1つの動画アイテムに対して、全部のストリームを混ぜるか、もしくは1つの音声ストリームを選ぶことはできるけれど、音声ストリームを選択して混ぜることができない。 動画アイテムを複製すればできるはずだけれど、そういう想定なのかな・・・？ → 音声を分離したあと、音声を複製して、それぞれストリームを選択すればいいのかもしれない。 ffmpegは、mapオプションを使って複数のストリームを持つ動画ファイルを扱うことができる。 そこでffmpegを使って、音声なしの動画ファイルと、各音声ストリームを別々に取り出した音声ファイルに分割するのを試してみた。 以下のようなシェルスクリプトを作った（映像：NVENC H.264、音声aacのmkvファイルを想定）。 #!/bin/bash INPUT=$(realpath "$1") #OUTDIR=$(realpath -- "$(dirname "${INPUT}")") OUTDIR=. FILENAME=$(basename -- "${INPUT}") EXTENSION="${FILENAME#*.}" BASENAME="${FILENAME%%.*}" mkdir -p "${OUTDIR}" ffmpeg -i "${INPUT}" \ -map 0:v:0 -vcodec copy "${OUTDIR}/${BASENAME}_video.${EXTENSION}" \ -map 0:a:1 -vn -acodec copy "${OUTDIR}/${BASENAME}_app.m4a" \ -map 0:a:2 -vn -acodec copy "${OUTDIR}/${BASENAME}_mic.m4a" \ -map 0:a:3 -vn -acodec copy "${OUTDIR}/${BASENAME}_meta1.m4a" \ -map 0:a:4 -vn -acodec copy "${OUTDIR}/${BASENAME}_vc.m4a" splitAudioTrack myrecording.mkv これを使って、Fallguysの60fps, 15分程度の録画ファイルを分割してみたけれど、ストレージが録画用のHDDなのが悪いのか、変換に実時間程度かかってしまうことがあった （ffmpegは、Windows 10上でWindowsバイナリとWSL2上のLinuxバイナリをそれぞれ試したけれど、速度はほぼ同じだった）。 場合によって、4倍速から7倍速で分割できることもある。Windows Defenderとか、Search Indexerとかが悪さをしているのかもしれない。 FPSも、実際に60フレームを正確に掴めてはいないと思うし、容量や処理時間と映像品質の間でコスパが悪いと思うので、30fpsに落とすと速くなりそうではある。 1度分割すれば好きな動画編集ソフト上で、各ファイルをトラック（レイヤー）に配置して好きにできるけれど、分割に時間がかかるのはうれしくない…。 分割ファイルができることによって容量が2倍になるのもうれしくない…。 ...

これまで自宅サーバへの外部からの接続には、 数年前から自宅のグローバルIPアドレスにフリーのドメインを紐づけて使っていたのですが、 3月末に更新を忘れてこのドメインを失効させてしまいました。 自宅サーバでは、主に個人用のWebサービスや身内用のゲームサーバが動いています。 同じドメインを再取得するには追加の料金がかかりますし、（若干用途が規約的に怪しいこともあり）新しくドメインを取り直す気にもなれなかったので、 以前から契約していたVPSをTCP/UDPプロキシとして使ってみることにしました。 この記事では、nginx.confのhttpディレクティブとstreamディレクティブそれぞれについて、拡張子でincludeを切り分けるようにする構成にしています。 基本的には、nginx.confに以下のように記述するイメージです。 http { include /etc/nginx/conf.d/*.http; } stream { include /etc/nginx/conf.d/*.stream; } 関連ツイート https://twitter.com/aoirint/status/1510309731642257408 https://twitter.com/aoirint/status/1511896279731040261 また、この記事の内容には関係ありませんが、envsubstでconfigファイルに環境変数を注入する、nginxのDocker Hub公式Dockerイメージのtemplate機能を使用しているため、 nginx設定ファイルの拡張子がtemplateになっています。 上のツイートに関連して、certbot --nginxで自動生成される/etc/letsencrypt/options-ssl-nginx.confを手動でnginx.confに統合しているので、 以下の設定ではコメントアウトされているincludeがあります。 構成 自宅サーバ側：systemd + autosshによる自動SSH接続＆リモートポート転送 VPS側：nginxによるHTTPリバースプロキシ・UDPプロキシ 自宅サーバ側 ~/.ssh/config Host vps* HostName VPS_IPADDR Port VPS_SSH_PORT ServerAliveInterval 10 ServerAliveCountMax 5 TCPKeepAlive yes IdentitiesOnly yes IdentityFile ~/.ssh/vps Host vps-forwarding-homeserver # SERVICE1 RemoteForward 127.0.0.1:VPS_SERVICE1_PORT 127.0.0.1:LOCAL_SERVICE1_PORT # SERVICE2 RemoteForward 127.0.0.1:VPS_SERVICE2_PORT 127.0.0.1:LOCAL_SERVICE2_PORT /etc/systemd/system/autossh-vps.service [Unit] Description=AutoSSH VPS [Service] Type=simple Restart=always User=user Group=user WorkingDirectory=/home/user ExecStart=/usr/bin/autossh -N vps-forwarding-homeserver [Install] WantedBy=multi-user.target VPS側 HTTPリバースプロキシ（SSHポート転送使用）: myservice.http.template server { server_name myservice.example.com; client_max_body_size 500M; add_header Strict-Transport-Security 'max-age=15552000; includeSubDomains; preload'; location / { #auth_basic "Auth required"; #auth_basic_user_file /secrets/myservice.htpasswd; proxy_pass http://127.0.0.1:VPS_MYSERVICE_PORT; proxy_redirect off; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-Host $host; proxy_set_header X-Forwarded-Server $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; send_timeout 3600s; proxy_connect_timeout 3600s; proxy_send_timeout 3600s; proxy_read_timeout 3600s; #proxy_max_temp_file_size 2048m; } location /.well-known/acme-challenge/ { root /letsencrypt-webroot; } listen 443 ssl; ssl_certificate /etc/letsencrypt/live/myservice.example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/myservice.example.com/privkey.pem; # include /etc/letsencrypt/options-ssl-nginx.conf; ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; } server { if ($host = myservice.example.com) { return 301 https://$host$request_uri; } server_name myservice.example.com; listen 80; return 404; } UDPポート転送（SSHポート転送不使用）: myserviceudp.stream.template server { listen VPS_SERVICEUDP_PORT udp reuseport; proxy_pass HOME_IPADDR:HOME_SERVICEUDP_PORT; proxy_connect_timeout 3600s; proxy_timeout 3600s; #proxy_max_temp_file_size 2048m; }

https://twitter.com/kfcarabia/status/1491779797038428161 https://chickenstock.net/ KFC（ケンタッキー）のチキンやハンバーガーなどの写真が公開されている。 自社商品の販促のためにケンタッキーの商品写真を利用している店舗への牽制らしい。 Free of chargeで使える。

Ubuntu Rhythmboxで取り込む。 ogg形式に変更する。 EasyTagを使ってID3タグ、アルバムアートを設定する。 Windows Windows Media Playerで取り込む。 初期設定が低ビットレートのMP3になっているので、320kbpsのMP3に変更する。 MP3Tag 2.88aを使ってID3タグ、アルバムアートを設定する。 （Windows版EasyTag 2.4.3は日本語が文字化けしてID3タグの書き込みが動作しないことがある）

ボイスコネクト：VOICEROID、CeVIO中心の同人即売会。 https://twitter.com/voiceconnect_ad ボイスコネクト2戦利品！ — aoirint🎐 (@aoirint) March 27, 2022 参加動機 ボイスロイド文化圏（ソフトウェアトーク文化圏）にこの1年で浸かった VOICEROID劇場・遊劇場・実況、ふにんがす、なのそん、VOICEROID投稿者の生放送、etc Seiren Voiceのデモ体験をしたかった VOICEVOXでお世話になっているヒホさん（ヒロシバさん）の数年来の努力＆お仕事の成果を応援したい この文化圏に来た端緒はDeNAの声変換技術の七声ニーナの影響が少なからずある＝声変換技術への興味がある 何かしらの同人即売会に参加してみたかった いわゆる同人即売会（コミケとか）に一度も参加したことがなかった（似ているものといえば、技術系の展示会くらい？） 感想 今回の参加体験はとてもよかった。次回もよい体験ができることを願っています。 同じものが好きな人が集まる場所って面白いなと思った。 ヒホさんに挨拶できてよかった（まあ忙しかっただろうし、覚えてないと思うけど…）。 即売会は、同好の士の社交の場という認識を強くした。まあわたしはこの文化圏に対して独自の成果物がある身ではなくファン目線なので、若干肩身が狭いけれど…。 蒲田 Seiren Voice Seirenの列 — aoirint🎐 (@aoirint) March 27, 2022 あとで書く！ 収集管理について Todoistのカンバンを使って、ブースの種類別にセクションを分類して、各サークルをサークル名とブース名でタスク化、各頒布物の名前と価格をサブタスク化して管理した。 途中、移動中に間違って操作されて状態管理がめちゃくちゃになったので、なにもわからなくなったけど・・・。 頒布物の収集について SeirenVoiceのデモがなければ参加していなかったと思うし、参加登録も（SeirenVoice発表後の）前日～前々日くらいで2部構成の2部参加だったので、頒布物の収集ははじめからある意味で手に入ったらラッキーくらいのおまけだった。（もちろん好きなので、ほしいことはほしいが）。 まあ次回があるかもしれんし、ワンチャン委託が出る可能性もあるし、Twitterでイラストあげてくれるし…。 これからも手に入ったらラッキーくらいで考えていくといいと思った。 釣銭について 現金は参加の前から、これは交換チケットだな、と思った。 頒布物は、釣銭問題（お釣りが発生すると大量の釣銭の準備が必要または釣銭が不足する）を起こさないためにキリのいい頒布価格になっていることが多いという事前知識はあった。 今回の一般参加にあたっては、100ポイントと500ポイントと1000ポイントの交換チケットがそれぞれ何枚ある、として、各サークルでの収集物と、その支払いに使う券の種類を事前に決めた上で、一切お釣りが発生しないように計画を立てていた。 サークルを巡る順番を厳密に決めること、確実に目的の頒布物を収集すること、は困難で、特に初参加かつ準備時間が限られた自分には不可能だった。釣銭の概念を捨てることで、それぞれが支払いに影響しないという利点を得られるという考えがあった。 釣銭については、前夜にTwitterでサークル参加者の発言を検索して何かお願いが出ていないかも探した。それは特に見つけられなかったが、この頃は銀行の硬貨取り扱い手数料が上がる傾向になっていることを踏まえて、釣銭を発生させないこと、の次に、紙幣が使えるなら紙幣を使うことを計画していた。 まあ最悪、何忘れても参加証（スマートフォン）と財布だけは持って行けよ、というようなツイートもあったので、余裕があるときの気遣いくらいで、気楽に構えることができた。 結果的には、終盤に計画外の追加収集をしたことで1度釣銭を発生させる取引をしたけれど、終盤であったこと、集まりやすいだろう500円の釣銭であったこと、頒布物的に紙幣の支払いが発生するサークルであったこと、から大丈夫だろうと判断した。 小銭の用意について 今回はたまたま500円玉と100円玉の持ち合わせが多くて、1000円札で引き出して、分散させつつちょっと崩すくらいで済ませられた。 まあ銀行で両替するのが安牌だけれど、平日昼間しか取り扱いしていなかったし、手数料結構するしで難しい。 普段の取引は95%くらいキャッシュレスなので、まともに現金を使ったのはすごく久しぶりな気がした。 現金を使うのは、キャッシュレス非対応の自動販売機とか、ごはん屋さんとか、コンビニプリンターくらいか。 次回の参加に備えて、すこしずつ集めていくのが一番いい気がした。 サークルチェック ソフトウェアトーク動画投稿祭応援しまくる祭（ニコニコ公式生放送）

ボイコネ2いきたい https://twitter.com/voiceconnect_ad