音ブロック動画の録画指南
前書き
音ブロックのワールドは極めて細長く、短い時間で大量のチャンクをロードしてはアンロードする。さらにそれを録画するとなるといっそう負荷がかかり、処理が追いつけずチャンクの表示が中途半端になったりスタックしたり、もしくは最悪の場合tpsが落ちたりする。誰が必要とするかはわからないが今回は自分の動画作成方法、おもにreplay modのエンコードまでを書き連ねる。
以下、fabric 1.16.5または1.18.2、1.20.3でreplay modおよびcarpet modが導入済を前提とする。また、おそらく1.12でも同じように操作すればできると思われるが別の操作が必要になる可能性がある。
この記事でわからないことがあったら、私のtwitterのDMにでもなげてほしい。なんとかなる可能性は低いが、できるかぎりのことはする。
録音
ソフト
replay modは通常音を記録しない。これは発生する音をすべて記録するとファイルが肥大化するからである。そのために別のソフトを用いて録音する必要がある。またreplayを使わない場合でも音ブロックは音が命であるため音をよりきれいに撮るためにも、画面をそのまま録画する場合においても音声と映像は別でとるべきである。
して、そのやり方はなんでもよいのだが、OBSなど録画を主にするソフトではなくAudacityなどの録音に特化したソフトを使うとよい。さらに保存方式には.mp3ではなく.wavを使うとよい。これは.mp3が不可逆圧縮であることに対し.wavが可逆圧縮であることに由来する。
しかしやはりwavにも欠点があって、それは可逆圧縮全般に言えることなのだが不可逆圧縮であるmp3に比べてファイルサイズが肥大化することである。とはいえたかだか100MBごときでなにか変わるわけでもないので、できるだけwavを選ぶようにしよう。
いくつかにわけて録音したいというならとめないが、分割録音は少々めんどくさくなる。最終的に1つにまとめるのだが、余裕があるのなら最初から1つに、つまりすべての音を同時に録音しよう。
バージョン
1.20.3よりtickコマンドがminecraftに追加されたことは記憶に新しいだろう。このコマンドはcarpetのものより正確で、carpetはミリ秒(ms | 10⁻³s)単位までの正確性であったが、次のtickまでの待機時間(今までのmspt = mili second per tick)がfloat型(有効数字およそ7桁)で管理されるようになったためminecraftでは100ナノ秒(100ns | 10⁻⁷s)単位でも正確である。つまり録音は1.20.3以降でやるべきだといえるが、notebetterもしくはそれに準ずるものが1.20.3以降には私が観測している限りないので、悩ましいところである。もし1.20.3以降でも録音できるのならそのほうが確実によいだろう。
たいていのサンプリングレートは44.1kHzもしくは48kHz、ハイレゾと呼ばれるいわゆる高音質とされる音声は96kHz〜192kHzが使われることが多く、高くてもせいぜい384kHz程度である。つまりサンプルの最小間隔は2.6×10⁻⁷s程度であり、1.20.3の正確性よりも低い。これはラグを考慮しなければ理論上ずれがおきないことを示している。
現在私は1.16.5で作成しているが、このバージョンには私が確認した限り音の同時再生数上限が音ブロックなどの非ミュージックカテゴリは247であり、これを増加させるmodはなかった。しかし1.18.2にはそれがあり、かつnotebetterも存在するので録音するなら1.18.2のほうがよいだろう。私の理想は1.18.2で作成をして1.20.3以降で録画録音するというものだが、1.20.3ではnotebetterの癖が強いという話を聞いているのでどちらでもいいように思える。
サーバー
多くの人はシングルワールドで録音しているのではないだろうか。これはスペックに余裕がある人向けではあるが、サーバーを立てて録音することをお勧めしたい。というのもminecraftはそのほとんどがCPUのうち1コアしかつかわない。シングルワールドではこの1コアでチャンクのロードや音の再生、tickingなどの処理を行う。ほかのコアは(minecraftにおいては)遊んでいるのである。
これはサーバーを立てることによって緩和できる。サーバーとそれに参加するクライアントはそれぞれ別のプロセスであるため、完全に独立して処理をすることができる。これによりサーバーで1コア、クライアントで1コアを使うことができて、負荷軽減につながるのだ。
さらにチャンクのロードとアンロードは重いため、carpet botをおいて読み込むであろうチャンクをすべて先に読み込んでおくこともできる。非常に長い場合は逆に重くなる可能性もあるが、たいていの場合演奏中軽くなるはずである。
サーバーを立てるといってもわざわざポート開放まではしなくてもよい。サーバーを立てたネットワーク内のクライアントから接続する場合(同じpcでサーバーを立てている場合も)にはlocalhostとしてポートを開放せずとも参加をすることができる。下手にポートを開放すると攻撃される可能性が少なからずあるので必要になったときにやるべきである。
録画
minecraftの画面を直接録画するのもいいが、shaderや後述するmodによって高い描画距離に設定すると負荷が高くなるのでreplay modを使えるならそれを使ったほうがいいだろう。しかしながらreplay modを使うことのできない演出や演奏方法もある。以下にその一部を示すので、これらを使っているならおとなしく画面を直接録画しよう。その際でもbobby modは比較的参考になるだろうから読むことをおすすめしたい。
titleや視点移動、視野角変更などのクライアントサイド限定の演出
インベントリ(プレイヤーか否かを問わず)を用いた演出
メニュー画面やタイトル画面などのワールドによらない情報を用いる演出
tick freezeをするなどリアルタイムを用いた演出
これらを使っていない演出、たとえばパーティクルやチャット芸、エンティティなどを用いた演出のみである場合は後述するreplay modを用いた録画が大いに役立つだろう。
replayファイルの作成
replayファイルはサーバーに参加していてもシングルワールドでやっていてもクライアントの描画距離内のものを保存する。そのためどっちでやっていても以下の手順はそう変わらない。多くの人は1/2倍速で録音していると思うが、録画でも同じことをする。単純にreplayファイルをつくるときにtpsを1/2にするだけである。
カメラパス
ほしいreplayファイルができたらそのファイルをreplay viewerで読み込む。replayの基本的な使い方はほかのサイトに譲ることにする。
多くの人はここでプレイヤーの視点になるだろうが、ところでそれはほんとうに等速直線運動だろうか。うまく操作することできれいな映像を作ることができるのにこれをしていない人が意外と多いように感じる。
replay modにはリニア(画面右下)というカメラモードがある。これは始点と終点を等速直線運動で結ぶカメラパスを作るモードである。replayの設定より変更可能だ。正直始点及び終点は各々好きなようにタイムスタンプをいれてほしいが、私の場合最初と最後は完全に止まっているか少しゆっくりにして動かすかの二択である。完全に止まっている状態を作る場合、動かさずに時間だけを進めてキーフレームをうつか、キーフレームの詳細設定から値を直接打ち込もう。
できたらパスを確認してエンコードにうつる。当たり前だが1/2倍でファイルを作ったなら通常の再生速度を二倍にする必要がある。
エンコード
エンコードの設定はデフォルトであるが、そこをカスタマイズするのもよいだろう。このコマンドラインはFFmpegのコマンドラインそのものなので、そちらを調べるとよい。
あとは好きな解像度、ビットレート、フレームレートでエンコードしてほしい。適切な値は調べればでてくるだろう。
ただし、エンコードプリセットでMP4 potato quarityは選ばないほうがよい。これは映像の品質を可能な限り落として、より早く終わらせるためのものなのでなにもなければ使う必要はない。
ここでも注意として、先頭にMP4とついているものはあまり使わないほうがよいとされる。録音の段でも述べたように、mp4は不可逆圧縮形式なので二十圧縮になってしまう…といいいたいところなのだが可逆圧縮であるMKV losslessは非常にファイルサイズが大きくなる傾向にある。さらには再生できないソフトもあるためよほど気にしない限りMP4 custom Bitrateをおすすめしたい。
さらに画質を求めるのであれば、PNG sequenceやOpenEXR Sequenceも手である。これらは簡単に言えば1フレーム毎にスクリーンショットをとった、大量のスクショの集合体である。すべては画像形式、たとえば.pngで出力されるため、FFmpegなどで動画形式に変換してあげる必要があり、一部シーケンスでも読み込める編集ソフトがあるが、基本的に望み薄だろう。ただし圧縮をほぼしないという点で映像(画像)の品質は極めて高い(一般人は気にならないだろうが)という利点もある。これらを使う人は別途FFmpegについて学ぶ必要がある。といっても意外と簡単なので、学ぶべきではあると思うが。
いつも私がエンコードしている設定はデフォルトからエンコードプリセットをMP4 custom Bitrateにして、bitrateの値を30Mbpsにしているのみである。とはいいつつも、毎回MKV losslessのほうでもエンコードはしている。
しかしながらコマンドラインはデフォルトでは最低限であるため、すこしいじる必要がある。
まずFFmpegをダウンロードし、FFmpegまでのパスをコマンドラインの左側にいれる。そしてMP4で出力するのであればとくに、以下のテキストをコマンドラインの右側に過不足なく入力してほしい。
-y -f rawvideo -pix_fmt bgra -s %WIDTH%x%HEIGHT% -r %FPS% -i - %FILTERS%-an -movflags +faststart -c:v h264_nvenc -preset:v slow -b:v %BITRATE% -cq 18 -pix_fmt yuv420p "%FILENAME%"
このコマンドラインに使われている主要なオプションについて解説していく。
-pix_fmt bgra
ピクセルのフォーマットをbgra(blue green red alpha)にする-s %width%x%HEIGHT%
動画(画像)の縦と横を指定する。ここでは上の指定された値にするように設定している-r %FPS%
同様、動画(画像)のfpsの値を指定する。ここでは上で指定された値にするように設定している。-i
入力ファイルを指定する。-c:v h264_nvenc
動画のコーデックを指定する。これはNVENCに対応している製品のみ有効であるため、AMD製のGPUを使っている場合はh264_amfとしてほしい-preset:v slow
プリセットを選択する。以下に挙げる値のみ使用可能で、その名の通り速度と品質をおおまかに決める部分になっている。
上にいけばいくほど画質は悪いがエンコード速度ははやく、下にいけばいくほど画質はよいがエンコード速度は遅くなる。
なにも指定しなければ自動的にmediumが指定される。ultrafast
superfast
veryfast
faster
fast
medium
slow
slower
veryslow
-cq 18
クオリティを指定する。-presetとは別に設定可能で、数字が小さければ小さいほどクオリティが高くなるがファイルサイズはでかくなる。0はいわゆる自動で、品質がばらばらになるので指定したほうがよい。
ほかの設定は正直気になる人だけかえてほしい。FFmpegのオプションはいろいろためしてみよう。またこれらの設定は一度設定したら保存されるため毎回設定しなおさなくてもよい。
ここまで設定できたことを確認したらいよいよエンコードだ。中央下のrenderingをクリックして、実際にレンダリングしてみよう。
役に立つmod
carpet等のおもに制作に必要になるmodは抜きにして紹介しておくことにする。これら以外にも出したいmodはいくらかあるがきりがないので重要なものだけを書いておく。
serverReplay
ServerReplay - Minecraft Mod (modrinth.com)
生成されたreplayファイルをviewerでみてみると、どうにもチャンクのロードが遅れていることが確認される人もいることだろう。そんな人、いやそれ以外の人にもこのmodを導入してサーバーで録画することをお勧めしたい。このmodはワールド内のチャンクを指定することで静的なreplayファイルを作ることができる。これを使い、回路全体を過不足なくそのエリアに収めることで、replayの読み込みの遅さが改善される。録画時に描画距離をあげずに全体を録画できるのは魅力的だろう。
とはいえ、replayにおいて録画と描画は別の問題である。全体を録画することができても、エンコードをするときに遠くの地形を描画をするには後述のbobbyやほかの描画距離を伸ばすmodが必要になってくる。
bobby
Bobby - Minecraft Mod (modrinth.com)
このmodではクライアントが読み込んでいる範囲外のデータを別のファイルから読み込み描画することができ、これにより描画距離を33以上にすることができる。たとえば実際の描画距離は8であるが、bobbyにより疑似的に32にするということができる。とはいえシングルでやっているのなら描画距離をbobbyで32にしても実際の描画距離を32にしてもかわりはない。このmodが真価を発揮するのはサーバー環境もしくはreplayのエンコードである。とくにreplayのエンコードでは強力で、replayの性質上すべてのレンダリングが終わってからフレームを書き出すのでbobbyを使えば必ず遠くのチャンクも描画できるのである。
サーバー環境においてこのmodの効果は極めて高く、サーバー側の描画距離を32にする必要がなくなるのでサーバーのtpsは低いままになるのである。つまり、サーバー側を8でクライアントを128にするということも可能になるのだ。本来であればサーバーの描画距離を(基本的にはできないが)128にする必要があり、サーバーはとても重くなるだろう。しかしこのmodを使えば最低限の8などにできるので、この部分で負荷軽減ができてreplayを使わない録画においてはかなり強い味方になるだろう。
また、Distant Horizonというmodでも遠くの地形をLODにして残すことでbobbyに比べてとても軽く描画できる。しかし欠点として、プロファイルによっては一番上のブロックが一番下までに適用されるため、線のようなものができてしまう可能性があるという点があげられる。あまり好ましくはないだろうから、重くてもbobbyをお勧めしたい。
1.20.4+ではまだα版ではあるがvoxyという比較的軽くbobbyと同じような見た目になるmodもあるためこれを使うのも手だろう。
Nvidium
Nvidium - Minecraft Mod (modrinth.com)
ここまで描画の負荷がどうだこうだと言ってきたが、Nvidia製GPUかつ16xxシリーズかRTXシリーズ以上のGPUを使っている人に朗報だ。このmodをいれることで劇的に描画の負荷が軽減される。bobbyによる広域のレンダリングにおいてはさらに効果を発揮する。shaderを使う際には勝手に無効化されるがそれを差し引いても絶対いれるべきmodになってくるだろう。
sodiumが前提となっているが、全員いれていると思うのでこれを筆頭とする元素ファミリーによる軽量化については省かせていただく。
radeon?帰ってくれ。
編集
ソフト
戦争になりそうなので、おすすめだけを提示して足早に話を終わらせたい。
好みは分かれるが、個人的には私も使っているdavinci resolveをお勧めしたい。少々登録などがめんどいが、それだけの価値はあると思う。無料で使ってみて、課金してみたいとなったら有料版にするのもよいだろう。ほかにもみんな大好きAviUtlやadobe税でおなじみのpremire proなどがあるが、今まで使っていたものがあるなら、それを使えばよいと思う。
音合わせ
replayを使うなら、音とreplayの映像を合わせる作業は必須になる。さらに音をばらばらに録音している人もいると思うが、その人たちはさらに神経を使う必要がある。複数の音声を合わせる場合は最初に合わせるための音をすべての音源に対して挿入して録音し、合わせたのちその音のある部分をミュートすればよい。
これに対し完成した音源と映像を合わせるには、そのような識別子を入れづらい。
なのでパーティクルが発生する時間と音が発生する時間で合わせる必要がある。映像は単純にパーティクルが出たそのフレームに、音声は波形を見ながら最初に波形が動いた時間をキーとすればよいだろう。
ところが音声が60Hzなんてことはないはずなので、基本的に音声は正確にキーをうつ必要はないということが直ちに分かる。実際、映像のフレームレートが60fpsで音声のサンプリングレートが44.1kHzとすると、映像が1フレームかわる間に音声の波形は約735回変わっているということになる。この数字からもそこまで厳密にやらなくてもいいことは容易にわかるだろう。
そうしてできた音声と映像を合わせたものをいざ再生して確認してみるとなにか違和感があることがわかる。何回も再生していくうちにうっすら「音声がほんの少し早い」と気づく。おかしい、しっかり合わせたはずなのになぜずれているように感じるのだと思うことだろう。この理由は聴覚が視覚に対して時間分解能が高いことに由来すると考えられている。
動画先行の原則
動画先行の原則とは、簡単にいうと動画と音声を合わせるときにぴったりあわせるのではなく動画を少し早くするとよいというものである。つまり、音声は少し遅いほうがしっくりくるということだ。さきほどぴったりに合わせて発生した違和感はこれによって解消することができる。もともと動画を編集していた人の直感からくるものであったが、今ではその理由なども明らかにされつつあるそうだ。
宣伝
youtubeに不定期で動画を出しています。
ほかの動画は概要欄、またはチャンネルから。
twitterでもたまに、たまーに音ブロック関連のツイートをしています。