先日、とある方からエンコードについてご質問がありました。
内容としては
本家様動画にご自身の歌みた音源を合わせるいわゆる「エンコード」がしたい
というもの。
もろもろ理由からご自身でやりたいということでQAしてたわけなんですが・・・
適当な情報を元に「よい！こうするべき！」
と書かれたものが結構多いんだなーと再認識しました。
その時は深く考えずこっちの方がいいですってな感じでお答えしてたんですが
今日全く違うことを調べていて偶然その方が参考にしていたであろう
サイト？ブログを見つけて何これ状態になったので・・・
珍しく今回はあえて敵対しましょう。
ソースの情報はこちら。
https://ch.nicovideo.jp/lejemento/blomaga/ar1709340
色々書かれていますがウソ＆適当が多い（印象）です。
高画質エンコで検索すると上位に出てくるので参考にされている方多そうですが。。。
では記された方には申し訳ないですがボロクソ言っていきます。
まずコンセプトの
ロスレスでエンコードすべき
に関しては私も同感です。
投稿された動画を観るときはサーバエンコードや視聴環境によって画質／音質が
落ちるのは仕方ないとしても、上流（元データ）は高品質（ロスレス）で仕上げるべき。
お化粧するにしても日々のお肌ケアや下地作りをしっかりしないと
化粧乗りが悪いでしょ？そういうこと。男性にはピンとこないかもしれませんが・・・
急ですがここで今回の話における前提を記します。
本内容は、AviUtlを使って１から動画を作ってH.264にエンコードするときの話です。
元々のご相談にあった本家様動画にご自身の歌みた音源に入れ替えるときは
このやり方が全くダメではないですが別のやり方を推奨します。
推奨する方法っていうか本来やるべきことは、
本家様動画にご自身の歌みた音源を入れてエンコードするのではなく
本家様動画に自分の音源をmuxでmp4コンテナすべき
ただこのやり方の難点？はCLI操作(黒い画面で呪文打つやつ)が必要なこと。
ご質問された方だけでなく多くの方はコマンドライン？パス？？何それ？？？
ってなると思ってしまったのでご質問くださった方にはmuxでのやり方ではなく
エンコードする方法でお教えしました。
私が知らないだけで実はGUI操作できるツールがあったりするのかもしれません。
はい、戻りましょう。戻りましょう。
＜拡張x.264出力(GUI)Exの画面にある１と２に関して＞
Youtube投稿するなら現在(2019/3/30)の仕様を見ると
ファイルの最大サイズは128GB or 12時間のいずれか小さいほう
※引用元
https://support.google.com/youtube/answer/71673?co=GENIE.Platform%3DDesktop&hl=ja&oco=0
なので一般的な動画でこの制限にかかることは皆無だと思うので
このシングルパス-固定量子化量の0もよいのかもしれません。
そして一方のニコニコ動画(く)の動画仕様(2019/3/30時点)は
ファイルの最大サイズは3GB以下かつ動画長さは6時間以下
※引用元
https://qa.nicovideo.jp/faq/show/5685?site_domain=default
参考に手持ちの動画２つをロスレスでエンコードしたら2.3GBと6.5GBとなり、
後者は投稿仕様の制限にかかってしまって投稿できません。
出来上がるファイルサイズは動画尺や内容で大きく変動するので
今回のは3GB以内か超えるか？！どっち？！な賭けは無駄な気がします。
そして動画サイトの仕様を知らずにやってる方だとこの前はうまくいったのに
今回は投稿できない！どうして？！？！なんてのも目に浮かびます。。。
今の時代、仕様を知らないだけでなくファイルサイズって
どこで見るんですか？なんて方も実際いらしたりするし・・・
--------------------------参考データ----------------------------
試しに4分16秒の動画(1080p)を先のシングルパス-固定量子化量の量子化0でエンコードすると
約2.3GBなのでニコニコにも投稿できるサイズではありますねー。
別の5分55秒の動画(1080p)だと約6.5GBでファイル3GB制限にかかって投稿NGです。
--------------------------参考ここまで----------------------------
ということで「ロスレスでエンコードすべきには同意」と言っておきながら
いきなり矛盾したことを言いますが・・・
ローカル保存（自分のパソコンで鑑賞する用とか）するならロスレスでいいですが
動画サイトに投稿する場合は、圧縮かけた方がいいのではないかなと私は思います。
・圧縮かけることでサーバーエンコード結果により近い形で確認できる
・しったこっちゃないでしょうが無駄な帯域食わなくていい
圧縮によるデメリット分はシャープフィルタやらかけてしまえば
むしろクッキリするぐらいな気すらするし。
ちなみにニコニコさんの拡張 x264 出力 (GUI) プラグインのwikiには
「シンルグパス-固定量子化量」の項目に
固定量子化量では品質基準VBRの項に記したようなビットレートの節約を行わないので、
固定量子化量を用いてエンコードすると、品質基準VBRを用いてエンコードしたものに
比べて視覚的に同じ品質でも容量だけが大きくなる。
ある開発者曰く「特殊な実験目的以外では使う価値がまったくない」とのこと。
＜引用元＞
http://nicowiki.com/%E6%8B%A1%E5%BC%B5%20x264%20%E5%87%BA%E5%8A%9B%EF%BC%88GUI%EF%BC%89%E3%81%AE%E8%A8%AD%E5%AE%9A%E9%A0%85%E7%9B%AE%E3%81%A8%E3%81%9D%E3%81%AE%E6%A9%9F%E8%83%BD%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6.html
なんて書かれていたりします。
ではお前はどういう設定でエンコードしてるのか？というと・・・
これです(音源が24bitのとき)
16bit音源時はこちら
※二つの違いは音声部分のモードの違いです。
Apple Lossless(ALAC)24bit と16bitの違い。
そんなのないけど？ええ、これがカスタムしてるってやつです。
ここに関しては次の記事に書いていますのでそちらで。
rigayaさん提供プリセットからはちょこちょこといじってる気はしますが
ほぼデフォルトです。
他のタブも変化も分かぬままちょいちょいいじってるけど。。。
先にも記した＆rigayaさん提供プリセットからしても
サイズ確認付き品質標準VBR(可変レート)で問題ないと思ってます。
rigayaさんのブログをご覧になればわかりますが詳しすぎて
書かれていることの意味がほぼわかりません。。。
そんな方がとりあえずこれでいいじゃん？って提供してくださっているんだから
これが正義。
何よりこの拡張x.264出力(GUI)Exの生みの親
鬼のように検証されていますもの。疑う余地などない。
------------------脱線1:圧縮って何よ-----------------------
この例えは映像でも音でも同じです。
012345678901234567890123456789(30個あるよって数える用)
こんな感じで数字の0が30個並んだものがあります。
000000000000000000000000000000
ロスレスさんはあなたに
000000000000000000000000000000
このように伝えます。
圧縮さんはあなたに
0が30個
このように伝えます。
受け取った側としては結果は同じでしょ？
でもロスレスさんはゼロゼロゼロゼロ・・・って言い続けるのに対して
圧縮さんは0が30個っていうだけで簡潔だし早くね？
ラインで友達に伝えるってなったらどっち使う？
なんとなーくロスレスと圧縮の違いが分かってもらえれば
例えを簡単にするために可逆変換な例になってるけどスルーして。
--------------------------------------------------
ああ、どうしようなんか面倒になってきた・・・
PR
