「XnConvert」が調子悪いときの対処

※全部のケースに対応してるわけではありません。
　バグに遭遇した場合、製作者のホームページで報告をお願いします。

---

①画像をドラッグアンドドロップしたらXnConvertがフリーズした

　フォルダの履歴（進む・戻る）が嵩んでいるとき。
　フォルダを閉じ再度同じディレクトリを参照して画像をD&Dしたら何事もなく参照する。

　ファイルパスの文字が不正なとき。
　F8キーなどで全角半角の変換をした場合、windowsでは扱いできてもXnConvertは扱ってくれないことがあるので、ファイル・フォルダの文字を半角全角キーの変更で入力しなおしてみるとうまく行くことがある。

　サムネイルキャッシュが大きすぎる・阻害しているとき。
　私は「SageThumbs」というサムネイル表示ソフトを使っているが、ディスククリーンアップでこれのキャッシュ(10GB超え)を削除すると問題なく扱えることがある。

　「互換モード」がONになっている。
　普通は機能していないが何らかの理由でONになっていることがある(トラブルシューティングさせたときとか)。win10以前のプログラムでもないのでONにしなくていい。プロパティを変更しよう。

　上記ぜんぶやってだめなとき。
　ドラッグアンドドロップしない。
　こんなことになると思わなかったが、上記の処理でそのとき上手くいっても次にうまく行かないケースがぽろぽろ出てきた。何故かデスクトップのフォルダはD&Dできたが、いちいちデスクトップにコピーするという話も現実的ではない。なのでD&Dではなく「+ファイルの追加」「フォルダの追加」を使って当該の画像データを選択した方がいいかもしれない。この「ファイルの追加」で開くエクスプローラーにも検索窓があるので、例えばjpgだけ選択したいときもこれでスクリーニングできる。

---

②zipに変換中フリーズして強制終了した

　C:\Users\ユーザー名\AppData\Local\Temp　に一時保存ファイルとしてzip変換前のデータ(画像処理済み)が保存されている。

　フォルダ名が「XnView_zip_数字」のフォルダがあるので、そこから変換後のデータを直接触ることができる。zipだと解凍しないといけないので、むしろ解凍が面倒ならクラッシュしてくれたほうが楽かもしれない。

---

③マルチコアで変換できない

　私の記事「「XnConvert」をマルチCPUで処理してもらう」を見てくれると嬉しい。

　端的に言うと”AskモードがON”つまり「ファイルがすでに存在するとき→[確認する]」になっているので尋ねてAskくるので、[スキップ]に変更すると何不自由なく処理できる。

「無効なMS-DOSファンクションです。」というエラーに遭遇

　ファイルをフォルダごとVVAULTで作った仮想ストレージにコピーしようとしたところエラーメッセージ発生。曰く「無効なMS-DOSファンクションです。」ということで意味が分からなかった。

　結論から言うとフォルダ名が不正だった。

　ファイルの名前に使えない文字が入っていると考えてただの数字にリネームしてみたが効果はなかった。このフォルダを他のドライブ、物理的に別なドライブ以外にVVAULTの元になった（VVAULTとしては折半して使っている）ドライブにコピーすることは全く問題なかったので、受け入れ先がVVAULTでなかったらこれはエラーとならないようだった。

　VVAULTはティアリングという、ファイルのアクセス頻度に応じて保存先を高速帯や低速帯に移動させる作業を行うのでそれが原因か、とも思ったがそれでもなかった。

　いろいろブログや記事を漁ってみると、”NUL”というデータがつくられているからエラーでコピーできない状況になっているらしく、これを削除することで解消されるらしかった。

　問題は、これをコマンドプロンプトでは不可でLINUXのソフトを入れて使う必要があるらしいこと、そもそもNULができるのはコピー元なのかコピー先なのか分からないということ、これらが面倒で放置していた。

　ふと、このフォルダを作成する際に、フォルダの名前の入力を間違って全角で入力してしまったためF8で半角に変えたことを思い出した。なので改めて半角で打ち直しをした。その時点でフォルダの順番が変わったうえ、そもそも同じ文字を打ったはずなのに入力カーソルの幅が違っていた。

　そしてリネームしたフォルダは、それまで散々エラーを吐いていたのがウソのようにすんなりコピーできてしまった。

 

　「無効なMS-DOSファンクションです。」

　このエラーメッセージが出た時にはまずファイルパスになるファイルやフォルダの名前が正常か確かめるのをお勧めする。

「XnConvert」をマルチCPUで処理してもらう

「XnConvert」という画像一括処理ソフトがある。

　これは数百枚あるJPGを一括でPNGに変えたり、一括でリサイズ(画像サイズを80%に縮小するとか)するとか、一括でレタッチ、カラー情報が入ってるPNG(24bit)をグレースケール(8bit)に減色してファイルサイズを減らす、とか、とにかく一括処理することに長けたフリーソフト（企業で使う場合ライセンス料がかかる）で、写真の枚数が多いほどこのソフトの恩恵は大きくなる。

　実際「Photoshop」にもバッチ機能があり、リサイズ・解像度変更・画像加工などできるが（サブフォルダも使えるとはいえ）フォルダ指定であり、ドラッグ＆ドロップで任意のファイルを処理できる「XnConvert」の方が簡単で楽である。

　このソフトは何もオプションを設定しなければ1スレッドで処理しようとするので、特にカラーを処理するときにはファイルサイズが大きいので凄まじく時間がかかる。

　しかし「出力」オプションで”使用するCPUコア”という項目があり、ここで使用コア数をCPUの最大スレッドまで(8C16Tなら16)設定してやると爆速で処理してくれてとても便利である。

　しかしこれは罠でもある。

　普通にチェックを入れて処理させようとすると、

　こんな風に

　「使用するCPUコア設定が不可です。'Ask'モードやマルチページPDFファイルが使用できません。」

　というメッセージでエラーになってしまう。そしてASKってなんだよと解決方法が見いだせず結局シングルスレッドで処理させてしまう。がこれをマルチ処理させる方法がある。　

---

　ZIPで出力する

　これが解決方法である。つまり同じフォルダに変換後の画像を入れて元の画像はゴミ箱に捨てて互換というやり方はできないし、フォルダを変えてファイル出力してもダメである。

　出力種類は他にもあるが、実データが保存先にできることを考えるとZIPが安心だろうと思う。そこは需要に応じで差配していただきたい。

　これによって私の8C16TのCPUを100％使って(80℃まで上がりながら)すさまじい勢いで処理してくれる。今までシングルだとなんだったのか、とか、PNGの圧縮設定をデフォルトの4から6に変えただけでも糞遅かったのに、とか考えることがあるが、処理速度が速いのはとても気持ちいい。シングルスレッドではオプションで早い遅いの違いが結構出ていたが、この処理速度は1ファイル1秒もかからない。

 

　すさまじいデメリットとして日本語でファイル名を入力しているとアンダーバーに変えられてしまう。

　なのでZIPを見たらなぜか入力できないはずの半角?でファイル名が表示されている。例えば「雪、窓辺、無音にて。_001」だと「??????????_001」と表示されており、これを解凍すると「___________001」となってしまい、こんなものがZIPにちゃんぽんされているので何のデータか分からなくなってしまう。

　元ファイルの削除にチェックを入れているとその後のリネームに手間がかかるので手元に置いておいた方が良い。捨てるのはファイル名を直し終わってからでいいだろう。半角英数字なら問題ない。

　またZIPで保存するということは１個の巨大なデータをつくるということでもあるので、保存先の容量は十分に確保しておくことを忘れてはならない。また画像変換は爆速だがZIPに圧縮する工程がある関係で秒で終わるというわけではない。そこを勘案しても高速処理されているのは見ていて気持ちいいし、これまで費やした時間を考えれば革新的でもある。

　ぜひ試していただきたい。

　直倫　https://www.xnview.com/en/xnconvert/

　とマルチスレッドで処理する方法を紹介したが、実際シングルスレッドの方が都合がいい場合もある。シングルスレッドでは複数のファイルパス（別々のフォルダ・ドライブなど）を一括で処理できるし、そもそもスレッドを１しか使わないのでCPU使用率をなんら圧迫しない。なのでバックグラウンドで処理させて他の作業をするのに何も抵抗を感じないのだ。

　正直一長一短かもしれない。

---

追記

　コメントが来たので確認したが、他にいじってなかった「ファイルがすでに存在するとき→[確認する]」を[スキップ]に変更するとマルチコアで処理してくれるようだ。

　確認スキップしたら変換前と変換後が二重になるかもしれないと思ったが、「元画像を削除」のチェックがあれば変換後だけが残るのでそこの心配もいらないようだ。

16:9の画像解像度で動画サイズをリサイズしたい早見表

　はっきり言って謎需要でもあるし、最初から4Kで録画して処理している人からすればそんなことで騒ぐのかという話でもある。

　だが正直3840*2160で4K動画を作ろうとしたら、自分のr7-3700Xですら5分の動画→40分x2(2-pass)エンコードにかかるし、その間ずっとCPUは100％でアチアチである。定格固定クロックで頑張っているなら別だが、自動OCで4GHz到達しようものなら80℃の超高温に跳ね上がってしまうだろう。

　一応映像と音声のエンコードの順番を決められるAviutlみたいなソフトなら”同時にエンコード”することで100%にならないので超高温に跳ね上がるのを抑えられる。がエンコード時間は若干延びる。

　なのでCPUの冷却に自信ニキではないというなら、なんちゃって4Kや3Kで動画をつくった方がまだパソコンにもやさしいし、これから先夏場になれば部屋の温度も上がるのでパソコンにガンガン排熱されるとしんどくもなる。なので一助になればよいと思い表を作ってみる。

　４K動画のエンコードなんぞ屁でもないという人は帰っていいです。

画像解像度 ヨコ	画像解像度 タテ	備考
1600	900	HD+
1760	990
1920	1080	1080p (FHD/Full-HD)
2560	1440	1440p (WQHD)
2880	1620	3K
3008	1692	3K (QHD+)
3072	1728
3200	1800	QHD+
3520	1980
3840	2160	4K

　当初このセルをエクセルでつくっていたのだが、「TAG index」というサイトの「ExcelのHTMLテーブル化」(web便利ツール)を使って簡単にブログ用の表に変換できた。謝謝茄子！

 

　勘のいい人は気づいたかもしれないが、これは[タテ+18/ヨコ+32]の比率を守って足し算すれば最適な画像解像度を計算することができる。

　”最適な”というのも、H265の場合は画像解像度が奇数になっても動画エンコードがうまく行くが、H264の場合奇数が入るとエラーでエンコードできない。ましてアップコンバートする場合、指定の画像解像度に合わせて元動画を伸ばした際に、この縦横比が維持されてないとたてながだったり横長だったりして元動画と形が変わってしまう。なので適当に計算せず、なおかつ偶数・偶数で画像解像度が設定できるのが良いのである。

 

　まあ身も蓋もない言い方だが、1920x1080の出力が難産でないのなら2560x1440もそこまで厳しいコンディションにならない。

　差分を考えれば想像しやすいが、例えば1920x1080を2560x1440にアップコンバートするというのは、タテヨコを各々1.33倍に拡大処理することに等しい。つまり面積的には1.33^2=1.7689倍、2倍に満たない程度の拡張だ。なので3K(2880x1620)ですら1.5^2=2.25倍程度の拡大処理で済む。そう考えると1080pを4Kに変えるということは縦も横も2倍にするわけだから面積は4倍に膨れ上がる。処理が手間がかかるというのも当然といえば当然である。

可変フレームの動画を固定フレームにして編集する ①Handbrake

　そもそも可変フレームとはなんぞや、というと「動きの変わらない部分のフレーム数を下げて、動きの激しい場面のフレーム数は増やす」加工をしたもののことである。

　これの利点は動画のファイルサイズが小さくなること。
　例えば動きが激しいところに合わせてすべて60フレームにしてしまうと毎秒60枚をどんな部分にもあてがってしまうので、明らかに動きが遅かったり画面の変化が小さい(動きの小さいキャラクターがしゃべってるだけ、とか)部分まで丁寧に60枚の画像で表現してしまう。
　これが可変フレームだとそういう場面は別に枚数減らしても構わんだろう、とCPUで計算することで描画枚数を減らして節約をしてくれるというわけだ。

　これの欠点は再編集しようとすると音声と映像がずれること。
　例えば、カットしきれてない部分がまだ残ってるがマスターは出力終わったから削除してしまった、という場合や、出力した動画がでかすぎて読み込みに手間がかかるので分割しようという場合、エンコード後の動画をさらに編集することになるだろう。
　 そういうとき、エンコーダにもよるが可変フレームレートだとそもそも読み込めなかったり、読み込んで再編集・エンコードしてみたら音が先に来ることがあったりして、仕上がりがうまく行かないという場面に遭遇することになる。

 

---

Handbrakeで固定フレームの動画にして出力する

　段取りとしては
　「Handbrake」というフリーの動画編集ソフトを使って可変フレームの動画を固定フレームに変えて出力し、それをマスターにしてオーサリングする
　というものだ。
　これの欠点は、フレーム補完して固定フレームに変えているので大元の動画と違っていることがあるということ、固定フレームの動画を出力するストレージ・スペースが欲しいということだ。

　編集したものをマスターにするたびに劣化するので、例えばYoutubeなど動画サイトでシークバーを後ろに持って行ったときに再生した時のような、不自然な再生速度になった部分が生まれる可能性がある。これは仕方がない。マスターがなければそれを許容して再編集しなければならない。

　また可変フレームでファイルサイズを節約したものを固定フレームになおすわけだから、少なくともその動画の２倍くらいは空き領域のある場所に保存する必要がある。つまり空き領域がない場合そもそもこの方法で処理できない。

　以上のことを踏まえて手順を書き残す。

1. Handbrakeに動画ファイルをドロップする
2. 【編集タブ】「動画」フレームレートが”30・可変”になっているので”60・固定”に変える（30でよければ30）
3. 【編集タブ】「動画」品質の基準が”22RF”になっているのを”平均ビットレート”で元動画より少し大きな値(1000Kbps増やす程度)に変える、2-passと高速1パスのチェックは外さない
4. 【編集タブ】「動画」コーデックのエンコーダレベルをAutoに変える
5. 【編集タブ】「オーディオ」コーデックの"AAC(acvodec)"を"AAC paththru"に変える
6. "保存されるファイル"でファイルの保存先を設定する
7. 変換開始

 

　前提として、元動画の動画コーデックがH264だった場合、出力はH264でもH265でも動画編集ソフトやプレーヤーが対応していれば問題ない。しかしH265→H264にすると圧縮率の関係で画質が大幅に落ちてしまう。その場合ビットレートはH265の1.5倍は必要になるだろう。当然ファイルサイズも膨らむので余剰スペースは十分に確保しないといけない。

　2のフレームレート固定化がこの編集の肝である。

　3の品質基準VBRは自動でビットレートを決めてくれるものの品質基準の数字の加減が直感で理解しづらいので、具体的なビットレートを指定した方がいい。そこで出力後の画質が劣るなら数字を増やせばいい。ビットレート計算の際に最適な圧縮率を計算させるため、時間に余裕がない場合を除いて2パスエンコードにしたほうが仕上がりがよくなる。

　4のエンコーダレベルは、H265の場合画像解像度で勝手に決まるので数値を設定しても無駄だが、H264の場合設定できてしまうため、元動画のエンコーダレベルがわからない場合Autoにした方が無難だろう。

　5のオーディオエンコードは割と重要で、再エンコードした場合ビットレートをどんなに盛っても音質が落ち、圧縮しまくったMP3みたいな音になってしまう。基本元動画のオーディオコーデックに”passthru”がついてるものを選ぶのがベストだろう。

　6はよく忘れる。保存先は参照してきちんと選んだほうがいい。拡張子をmp4(m4v)/mkv/webmから選べる。

　7。いってらっしゃい！