【聞き比べ】響け！ユーフォニアムのそこん所

記稿.2023/09/23

＞　正直言うと、本編での中世古香織と高坂麗奈のトランペット対決は聞き分けづらい
＞　それをＣＤ化してあるのを見つけ‥確認しても‥まだ判りにくい
＞　で、俺のハイレゾにしてみて、漸くにその差を見出し理解した


　中世古香織のトランペットは上手だけど、素直すぎていて主張が弱い
　なので、ハイレゾにした全体演奏のそれを聞き流しているとあら不思議
　トランペットのソロの印象がゼロだったに近い（マジか‥）

　その点、高坂麗奈のトランペットは主張が強いので聞き流していても印象に残るのだ（へぇ〜）

　（人生に見られがちな‥あるあるどえむ）


＞　いやはや、それにしたって音大一年生の演奏にあるらしい
＞　収録するのに音大一年生あたりが一番に、高校生演奏に近いという次第での皆集まれ採用らしい


　それにしたって、大学生相手ともなると、しっかりしたバイト代を出さないとすぐに噂になる
　京アニの雇用体制からすると当然の話だが、収録曲数がべらぼうなんだから
　シリーズ収録なのに、間が空くと‥どうなってんだよみたいな‥

　その上で、本編のＢＧＭはプロの演奏なんだろうし（予算編成等で興味深い）

　いやぁまぁ京都辺りに住んでる吹奏楽部員からすりゃ
　もしかしたら収録出演できる機会を得るかも‥なんて次第もありげでしょう‥人生の妙に興味深い
　（さぁどうなんでしょうね？‥間が空いてるだけにそれはそれでそそるぜ‥）


＞　それにしても黄前久美子の「響け！ユーフォニアム」のソロ想定の息継ぎの下手印象が濃すぎる


　いやぁまぁそれだけ、息継ぎのしどころを要求する吐く息のなが〜〜〜〜〜〜い曲でヤンス
　七年間ほどユーフォニアムを吹いてきた者でさえ息が続かない感がもの凄ー

　そんな曲を相手にひたすらに吹き続けてきた田中あすかの腕前の裏付けとして濃いでヤンス

　（その黄前久美子のソロ版が、とくにハイレゾの際の鬼門でとても悩ましかった‥）
　（本編でも、ぎこちなさげに聞こえるけど、それを更に増幅してくるのにはまいったｚ）
　（まぁそれも音大一年生によるそう演出してくれ表現なんだろうけどね）


＞　その息継ぎとした光景の意味が、俺のハイレゾにしてみてようやく分かった


　合奏の際に、息継ぎが一斉に揃うべきで揃ってないと、心地良さとしてまとまらない
　（そんなの今まで考えたこともなかったｚ）

　まぁその辺追及していくと、息継ぎが短く且つ無い程にクリアーに思えるものなの？
　という疑問にも成るわけですが、ＭＩＤＩに満足できかねるポイントでもありそうです

　（やはり、生物としての呼吸感を感じられてこその息継ぎ部分なんですから）
　（そういう感触こそ美学みたいな‥そういう事のようですよ）


＞　其を逆算すると、息継ぎの阿吽を理解して、自在にこなせる才能こそ華みたいな
＞　それも、てめえの相棒（楽器）の癖をも勘定に入れてこなさないと成らないのだ


　（まさに支え合う形の阿吽とした世界なのにおったまげ）
　（だがしかし、ブクブクに太った音大一年生らのお姿を見ると、其もぶっ飛ぶんだが‥どうなの？）

　‥まだまだ伸び代がある様に見える感が、ぶっ飛んでふざけすぎに見えてしょうがねぇ‥

【俺のハイレゾ】CD音質→16bit,176400hz→24bit,48000hz

追稿.2023/09/23...20230922...

＞　XRECODE3で最高にしてしまった上に
＞　flacの圧縮度を（8）にしてしまってあるそれらをどう立て直すべきか
＞　（再生中に音声解凍が間に合わないケースで、プチッと飛びノイズやらかします）


　‥で、巷に転がる24bit,96000hz（flac）のハイレゾを
　24bit,48000hz（wav）に変換すると、これがサイズ共に好い感じに仕上がるのに注目

　（ちなみに、XMedia Recodeを使用します）
　（こちらは、味付けしないソースに忠実重視です）
　（XMedia Recodeのflacだと192000hzまでハイレゾやらかせます）


　‥で、まず
　CD音質（16bit,44100hz）から
　処理速度重視で、flacの圧縮度（0）で（16bit,176400hz）に変換し
　それをさらにwavで（24bit,48000hz）に変換します


＞　すると、とてもすばらしい
＞　（できる限り割り切れる数値でやるのがやっぱコツ‥みたいな）


　44100×4＝176400
　176400÷48000＝3.675

---

＞　色々と確認していると
＞　16bit,176400hzの処理の際に課題がでまくる（やる気を削ぐほどに悩ましい）


　‥DDR3マシンだともはや瞬間的な処理スピードが足りていないのか
　まさかのHDDのデフラグ状態どころか、セーブ先の窓がうっかり開いていたりするだけで
　Windowsが余計なファイルカウントなアクセスをしだすことで、それだけで
　まさかのまさかの「再エンコード時に音飛びした？」臭さを見せる

　（いやぁもう、保存先のHDD分けどころか‥その手の保存先の窓締め確認が逐一必要だ）
　（Webブラウザーだって落としておかないと‥裏処理発生するのは全部ダメ‥ぐらいな）

　（そんなこんなで‥音の処理の際には、圧倒的にSSDの方が有望なんだろうか？？）
　（だが予算的に、レコーディングの成功・失敗を気にしないほどの効果を見ないなら意味が無い）
　（大容量処理にハマると、SSDでもそれ程に速度差を見せないと聞くし）
　（所詮はそれ用消耗品扱いだ、そんなに優雅に音楽を日々聞くタイプじゃないし）

　（せめてHDDは、キャッシュ容量のデカいやつを保存先にすべきかも‥）

　（さらにスタート開始にはまず、CD規格のwavのそれに置き換えた方が良いと思う）
　（flacになっちゃてるソースでも、まずはwavにするのだ‥）

　（面倒くせぇと思ったら、てめえのマシンの都合を見極めましょう）

　（XRECODE3で最高にしてしまってあるなら）
　（重複を避け、XMedia RecodeでCD規格のwavのそれにするどえむ）
　（して無さそうなら、XRECODE3で最高にしてしまおう‥ここが端境くさい‥）


＞　それは、吹奏楽の息継ぎ箇所かと思わせる様な、とにかくなが〜〜〜〜く伸ばす箇所で見られる
＞　ソロ演奏ほど目立って「プチ切れ」発生する可能性が大‥みたいな悩ましさ


　原因として考えられるのは

　・プログラム間での何らかの受け渡し処理が追いついていない
　（特定のキャッシュ容量が小さい事による見えないエラーとか、瞬間的なバス容量問題とか‥）
　（それはとくに、FLAC内での基本的な処理の狭間に起きていそう‥圧縮度（0）なのに‥）

　・もとからそのCDには致命的な傷があり、ハイレゾ拡張すると発覚するみたいな
　（CDを聞いていて不可解な部分ほどその手の拡張に晒すと発覚しうる可能性を有するとか）
　（それをそのまま24bit,48000hzに置き換えると）
　（無かった形にも収まる場合とそうでない場合がある‥程度許容みたいな‥）

　・VLCの再生時に、ハイレゾすぎるFLACの時だけ、処理しきれないトラブルに見舞われる‥とか？


　だが、しかし


　諸々注意して再エンコードを行うほどに音質が確実に安定的に上がるんだから
　ハイレゾ化の際にその手の注意を怠ると、音質がばらつくという傾向は否めないのだッ

　（その辺に無頓着だから、ハイレゾの聞き比べの際に「？」の人も多くなっていそう）


　‥それはもう、大変です、謎です
　（その点は、映像のエンコードの方がまだ気楽かも‥なんで？）

【CD音源】原盤からハイレゾ化の間に潜む落とし穴

↓1)記稿.2023/09/20

　‥その昔、テレビ音声よりCDの方が圧倒的に高音質だった頃
　アニメのサントラでも、番組放送時の収録音を使わずに、再収録してあったりして
　こちらのイメージと違ったりしてガッカリした記憶がある

　今時は、高品質に収録したマスターデータを元にCD規格に落とし込んでいそうだが

　それはそれで、アニメイメージと微に異なるのは当たり前として理解せざるを得ない


＞　ところが、CD規格の場合
＞　商品とした形に為すまでの過程で、エラーを抱える可能性を有している
＞　それは、CDとした型枠を造る際に生ずる致命的な欠損だ


　まず銀盤の型枠を造り（保存用？）
　その型枠から樹脂の型枠を出して、それを大量生産用として、生産版プレスに回すのだ
　只でさえ小さいピットの凸凹だらけなので、欠損ありきなのに
　生産ラインに乗せるまでに、２回も繰り返すんだから度胸満点だ

　（だが、エラー率の発生は避けられず、品質管理の保持は、プレス工場に依存する）


＞　その上、さらに
＞　データ収録方式と、音楽収録方式とでは、データ収録の形式が違うのだという


　ここがどうにも謎で理解できないままなのだが
　パソコンから音楽CD情報を吸い出すとしたすべてにおいて、クセのあるズレが発生するらしい
　なので、結局の所
　どうにか手にした初期WAVのイメージとて、原音に忠実とは言い難い‥とかなんとか


＞　だがしかし、何の為に抽出したかというと
＞　曲事にバラして確認しやすくしたり、好きな曲だけの束なりにしたいからだ
＞　さらに、flacに圧縮して保管したい‥となる


　‥その際の管理は、それこそ個人の趣向によるので意見の分かれる所だが
　知っておかないと、原盤のイメージを崩してしまっている事に気が付かないままになる

　それは、ここまでの説明で
　「CD再生機にどんなメリットが有るのか？」について知らないのでは話が進まないのだ

　「CD再生機の音の吸い出しは、正確なのか？」（不正確なら何の価値も無い）

　その疑問を払拭するぐらいCD再生機は、再生機ながらに良い音を出すわけだが
　それはまぁ、クセのあるズレを織り込んで補正しつつ、味付けし直すからだろう

　その味付けを元に、さらに、各々がアンプを介して音への味付けに夢中になる
　そのアナログの感覚で得られたそれをデジタルにして
　さらに、人気の高まった補正処理が残るとした過程があって


＞　原音に忠実にリサンプリングするアプリと
＞　そこから掛け離れて、加工上等にリサンプリングするアプリとに分かれている点である
↓/続きを読む/↓

【エンコード日記】m2tsファイルをＰっちり切っちゃう謎な切り方（XMedia Recode）

記稿.2022/08/26

＞　XMedia Recodeでm2tsを切り分けたい場合
＞　通常のやり方だと問答無用で、後半部のそれに、ディレイ発生してしまうわけですが
＞　問答無用で、Ｉフレームからしか切り出せないわけですが
＞　ケースによっては回避できてしまう謎の切り方を発見しました


　（但し、すべてのケースに対応しているわけでは無いらしい）

　‥まず、クロップ／プレビューの映像トラックを出します
　で、そこの ||▶ボタンと　［ ボタンを使用します

　切りたいＩフレーム位置もしくは半端なＰフレーム位置より
　一つ前のＩフレーム位置を割り出して

　そこでとりあえず、　［ ボタンを押して開始時間確定します

　そこから再び、 ||▶ボタンを押して一コマ動かし
　再び、［ ボタンを押して開始時間確定します

　其の作業をを‥お目当ての画像位置まで、えっちらおっちらと繰り返します


＞　是のボタン操作が謎で
＞　まるでコマンド打ちにでもなっちまったかのように
＞　連続打ちすると、出てくる駒が、切っても切ってもＩフレームに化け続くんすよ


　（押しても押してもＩフレームが続くようだと、なぜかＰからでもぴっちり切れる‥謎）
　（なので、この技を「Ｐっちり切り」と呼ぼう‥当然、コピーモード使用での話だ‥）

　（どう考えてもバグの類にしか思えないのに）
　（普通にやるとＰフレーム位置のはずが、どうして頭にして切れるんだよ？‥てな感じになる）
　（で、うまく適正にあるようだと、ディレイ発生せずに切れてるって寸法だ）


　‥バグで無いなら、ソース構造が後付けでくっつけてあるって感じのを
　XMedia Recode側が、Ｉ位置を一枚ズレて表示している可能性がある（四捨五入誤差くさい）

　（avidemuxで確認すると大抵ズレているので、どっちが正しいかは、AviUtl確認になるが）
　（まぁ逐一確認するのは面倒としか言いようが無いのだが、そこはてめえでやってちょ）


＞　まぁ、Ｐっちり切れるにこしたこたぁねぇてな感じ
＞　（いろいろと試してみるのも面白いでしょう）
＞　（ちなみに使用したバージョンは、3545っす）

【其は正しいか？】フィルムグレイン（化学班、化学紋、化学楔）の意味

↓2)記稿.2022/08/17

＞　画像圧縮の際に、シロウトは、フィルムグレインの解釈で躓くわけだが
＞　それが何なのかを理解していないと、残念な圧縮にしかならない


　‥確かに、気にせずに潰し込めば、圧縮率は上がるにしても
　大抵は、てめえが使用する目的外の利用において、要求を満たさない画質に成り下がる

　正規に映像を売る方にしたって、とくに、マンガ等の静止画など
　どのような機材に、それら画像を表示して楽しむのかを事前に説明もせずに売りつけている

　海賊版を流す方にしたってそこは同じで、お互いに欲求が違っていれば
　当然の如く、再圧縮願望を募らせることにも繋がろう


＞　そこは、解像度を選んで売る時代に至っていないからこその不始末をやらかしているも同然だ
＞　否、お買い上げ頂いたからには、いつでも自由に別解像度を選択自由に選べなくては意味が無い
＞　（そのぐらいにやらないと、海賊版の排除には至るまい）


　‥いつでも変更できるとした対価感覚での年会員制とした位置づけぐらいにはできる
　（されど、管理経費は、双方共に馬鹿にならない）
　（付け加えるなら、解像度×ビットレートの是非なんじゃが）

---

　まず、私たちの映像文化は、白黒写真に始まり、カラー写真にて激変した
　白黒写真は、印画紙に現像液とした兼ね合いで
　カラー写真は、フィルムを基に、印画紙と現像液を用いる

　まぁよくは知らんが、そこには化学反応が欠かせない

　結果、化学班、化学紋とした核となる粒子に、なんちゃらがまとわりつくことで
　反射を見せ、色を紡ぎ出している
　その当時、カラー化の際に色の手本とされたのは、述べるまでもなく鏡だった


＞　そもそもフィルム化された裏には、駒を繋げて試写できないかとした映画があった


　‥つまり、映画が創造されて
　私たちの脳は、いつのまにやら、フィルムグレインありきにカスタマイズされたのだ

　なので、鏡と同じように再生されているとした思いこみの裏では
　フィルムグレインまでを、眼に、視野に焼き付けてきた

　だが、それをブラウン管を介して眺めだした時代、それがノイズの元だとは誰も考えもしなかった
　技術者の多くにしても、走査線や電圧差等での因果関係を思っていたぐらいだったように思われる
　（疑い始めたのは、デジタル化の際からだろう）
↓/続きを読む/↓

【インターレース】デジタルとアナログでコーミングノイズが違うんじゃが（アニメ）

↓3)記稿.2022/08/16

＞　デジタルのインターレースとアナログのインターレースって違うんですよ（アニメ）


　デジタルのインターレースをモニター上で縮小再生すると（デインターレース無効）
　インターレース部分が浪波になるのに

　アナログのインターレースで同じことをやると
　お約束のシマシマ＆がっつりコーミングノイズになるっす

　（昔のビデオデッキカタログには、くし形フィルター搭載なんてのが目玉だったりしたのですが）
　（当時はなんのことかサッパリだったのですが、インターレース解除の補正さだったわけですね）


　‥なにが言いたいのかというと
　編集の際には、どちらとも同じ解像度で編集されるわけですが
　人の眼には同じに見えていても
　デジタルとアナログのデータ構造がまったく異なるからこその↑の様相になると‥

　（なので、フィルムをスキャンしただけでは、デジタルデータとしては不十分）

1-3)1

＞　ついでなので、2-3プルダウン（30i）→24ｐにする際の屁理屈を一つ
＞　手っ取り早く説明するために↓の図をご覧下さい（拾いものでm(_ _)m）



<参照元>：https://steinberg.help/nuendo/v8/ja/cubase_nuendo/topics/film_transfers/video_telecine_process_three_two_pull_down_c.html


　４枚の駒を５枚に拡張するのが
　2-3プルダウンと称されるフィルム映像向けのインターレースです

　これをよく見ると、24駒に戻せそうに思えてきます（逆テレシネ）

　例えば、一つ目のフィールドで一コマ（Ａ）
　二つ目のフィールドもそのままに一コマ（Ｂ）
　五つ目のフィールドもそのままに一コマ（Ｄ）として素直に抽出できそうです

　では、元のＣを抽出するにはどうするのか？
　B3-C1のフィールドのボトムからC1を
　C2-D1のフィールドのトップからC2を
　それぞれC2＋C1の組み合わせ（ひっくり返し）でイケそうに見えています

　ところがです、ソース側エンコードの状態が問題です

　フィールド毎にビットレートが同じなわけが無く
　さらにマクロブロック単位においては、どこに元になるデータが収録されてあるのかが謎です

　なので、C2＋C1の組み合わせどころか、B1とB3，D1とD3でさえ同じとは限りません
　（思い切りよく、間を間引いても、噛み合わず、カク付いたりするわけです）


＞　所謂、心理的エンハンスト効果って奴で、違和感ないようにｉ補正されてあるからでしょう


　‥ようは、参照フレーム数やら、参照フレームMixやら、ｂフレーム云々やらで
　フィールド単位を飛び越えて、量子化やらかして
　マクロブロック参照の位置が複雑怪奇になるからです

　（ソースがオープンGOPを採用していようものなら、そりゃもう謎でっせ、無理）
　（DCTありでエンコードされていたりするのも、十分に怪しい）
↓/続きを読む/↓

【エンコード日記】BD映画版の収録長さによる都合と品質

記稿.2022/08/15

＞　一般にDVDなら120分、BDも120分
＞　既定品質で収録可能になっているわけですが


　DVDの場合なら、片面で120分以内なら既定品質なわけですが
　どうにもBDの場合は、色々と違っていることを思い知りましたん


　BD映画版ともなると、まず、おまけ映像ありきになっているせいか
　タイトル本体だけの収録としたサービスは、あまり見ないようです

　なので、アニメで90分程度が、25分モノをちょいと上回る気配の品質を醸しだし

　それ以上になると、段々と品質が下がるらしく
　らしく上下カットせざるを得ない状況にあるらしい（＆予算絡みでしょう）

　（ＴＶ版のまんま映画版で120分近くなら、25分モノより、品質劣化の可能性を疑わざるを得ない）


＞　とくに、アナログ版収録の場合


　パン部分のブレブレがあったりすると
　作業をした人の器量やら状況がそれだったりするので
　作品全体でのブレブレ傾向を見せ、パンでのカク付きが気になりがちだったりします

　（ＢＤでそれなら、ＤＶＤなんざ問うまでもない）


　‥そういう作品タイトルは、４ｋ版になるとパン動作で安定を見せる傾向にあるようです
　（ＨＥＶＣの３３方向なんちゃらってのが、誤差補正に猛烈に効くっぽい）
　（まぁその代わりに、テクスチャーパターンが削れやすいとかなんとか‥）
　（どちらかというとＨＥＶＣは、実写向きの構成に思われるわけですが‥謎）

　（ＡＶＣに見慣れてると、ＨＥＶＣでのそれの差に、困惑するんすよ）


＞　諸々サービス抜きでも、多言語化等‥音声にこだわるとビットレート持って行かれるので
＞　瞬間帯域の制限はどうにもならないので、ＵＨＤ期待ありきでしょう


　‥そもそも、ＢＤ規格初期の段階に、7.1ＣＨなんざ想定してなかったはず
　ＢＤにガチ載せしたら、映像の品質を下げにてこ入れせざるを得ないのは明白‥無理無理‥
　映像のマルチチャンネル化でさえ、画質低下でスルーされたのに‥謎

　（なんだかんだとＵＨＤにしたって、機能拡張していけば、ザルになるに違いない）


　‥そこで富裕層対象とした、専用デッキのみ再生可とする方向ってか？
　富裕層なら、いくらでも上位規格への買い換えをして頂けると
　毎年に順次拡張していっても商売できるとかなんとか（制作環境無視情勢）

　（だったら、拡張カード式にしないと誰もついてこないんちゃう‥差し替え式とか‥）
　（只でさえ、半導体不足なんだし‥その内大丈夫になるなんてありえへん‥）

【エンコード日記】Big／SignedとLittle／Signedの違いとは？？？

記稿.2022/08/06

＞　BDのPCM音声をwavに再変換すると
＞　設定：Big／Signed　→　Little／Signedに、問答無用で変更される


　‥この差が気になる音声にぶち当たってしまい、とても困惑
　‥この差が気になる音声にぶち当たってしまい、とても困惑

　Big／Signedのままの方が、伸びが細かいように感じられるンニャニャァァア‥


　（なにがどう技術的に異なるのかがまるでわからないニャー）
　（今まで気になったことは無かったニャー）


＞　らしそうな検索ヒットが
＞　ビッグエンディアンとリトルエンディアンに思われるのだが


　・ビッグエンディアン
　　データをバイト単位で配置する際のやり方のひとつで
　「最初のバイトからデータを並べる」やり方


　・リトルエンディアン
　　データをバイト単位で配置する際のやり方のひとつで
　「最後のバイトからデータを並べる」やり方


　（それだけのことで、違いが明確に発生するだなんてとても思えニャイニャ）


＞　だがしかし、劣化が多少は認められるから
＞　フリーでの取り回しをやらかせできている‥ブツブツ‥（やっぱ、わかんニャイニャ）


　‥ちなみにソースは
　□□版□☆□☆□□■■■■篇□○□のエンドロール曲っす

　（昭和と平成の境辺りの昔には、DATという20ビット録音がもて囃されておりまして）
　（その手のアプコンで発生するっぽい気配に思われるわけですが）
　（その手のソースは、DVDだと16ビットに抑えられているわけですが）
　（今まで、とくに気になったことは無く‥まぁAC3にしちまうからかな‥）


　‥でも、今回の件で言うなら
　BDで24ビットにアプコンされた結果、何かが違ってしまっているというのだろうか？
　（その差がたまたまLittle／Signedの際に引っ掛かるなにかがあったとかなんとか）
　（‥ああ、面倒くせー）

　（たまたまDVD版（16bit音声）との比較もできて、こちらの方が幾分都合良く聞こえるような‥）
　（もとい、勢い余ってハイレゾ加工する際に、都合の良い素材化しているような）
　（PCM16bit48KHz→flac24bit96000KHz→wav32bitfpLE48KHz‥てな感じに‥）

　（無論、BD版Big／Signedまんまの方が伸びが良いに決まってる歴然たる差はあるっすけど‥）

　（ちなみに、扱いの異なる32ビットにするとMediaInfoで認識不能に陥るっす‥）
　（いろいろと認識度が低いので、wav32bitfpLE48KHzはやりすぎっすけどね）

【エンコード日記】新しいアイデアが降りてきて‥まだまだ終わらない件

記稿.2022/07/26

＞　｛バッファ：最大ビットレート｝の値を｛1：1｝にすると高周波域が優先される
＞　Ｂフレームを使用すると高周波域が優先される
＞　そして、これは一般にスタンダードなエンコード設定だったりだろう


　‥ん？、じゃどこかでぼかし調整をやらかせば好いんじゃねぇ？
　候補に上がったのが「ＡＱ強度値」‥（まぁどこでも同じに思われる）
　（当然ながら、この方向のレシピは、1080→1080ｐという事になる）


　‥それにしても、XMedia Recodeの最新版で
　解像度変更で落ちる原因が未だに不明で、解像度変更無しでもどうにかやれんと後で困るし
　で、いつの間にか設定のてこ入れがされて、ブロッキング軽減の初期設定が遂に外されちまってる
　（オフにすると、全体的に微ボケが入る感じに思うのだが、FHDモニターにも無いので何とも‥）


　‥さらに
　AC3が二つに増えてるのだが、バグなのか、選択支の意味が無い状態になっちまっちいる
　これは何とかして欲しい（俺的には選択支の多すぎるのは困る、しょうがないのでE-AC3を代用）
　（選択肢が多くなっても、それの違いを推し量る環境には無いし、要素の基本的意味もわからん）

　（まぁもはや1080→1080ｐでは、テレビUSB挿しも爆Ｑるンも前提にしないのだけど‥）


＞　話を戻すと、どのようにＡＱ強度値を弄るのかと言う事になるわけだが
＞　弄ったのなら、弄った意図に沿うようにビットレート変更もきっちりする必要がある
＞　というのが、継続した思考に沿った方向だ


　0.5625＝1.00÷1.3333…^2　でやってみたところ、実写の動きの激しい部分で問題発生
　0.64＝1.00÷1.25^2　に落としても、まだまだボケ感が残るくさい
　0.81＝1.00÷1.1111…^2　にしたら、アニメでもFHDらしさを覗かせて好い感じになるっぽ

　だがしかし、量子化済みソースにあるせいか、ノイズをひっぱて来るだけにしか無い状態らしく
　残念ながら‥参照フレームMixを（□）に
　当然ながら、bフレームの安定を狙うならp4×4も（□）に

　さらに、Ｉ4×4は、演算上の誤差修正の参考程度に添えられてる程度で
　画質向上要素として、積極的に盛られているわけでは無いと判明
　ということで、≒24pなら‥レベル5.1で十分らしい

　（つまり、1080→1080ｐでは、爆Ｑるンを求めず、より画質の安定を狙う方向になるっぽ‥）


＞　で、ビットレートになるわけだが


0.81＝1.00÷1.23456790123456790…　※（1.1111…^2）

1920÷1.1111…＝1728
1080÷1.1111…＝972
16×9＝144
1728×972÷144＝11664

　1.111111…で、1920×1080解像度が割り切れてしまうことに驚いたが
　それの（1728×972）を想定したぼかし具合というのが
　大抵の数値で端数を導いてしまうので
　1.111111…^2＝1.234567890123456790‥で割り切れるところが
　1.234567890123456790‥×1.44＝1.777777…
　1.777777…×2.25＝4

　なので、｛平均：バッファ：最大｝＝｛1：4：４｝

　34492＝972×36＝11664×3
　｛36：144｝＝｛34992：139968｝


＞　ところが、aq（3:0.81）だと、ソースによってはまだまだノイズが乗ってしまうところが有り
＞　少しばかりぼかしてやる意味で、aq（3:0.80）且つビットレート計算を（0.81）とする
＞　（解像度1088と1080の誤差折り込みみたいな）


　‥いやいやこれが何というのか
　通常なら、高周波域の大部分をそのままに一番に低周波域をちょびっとぼかして終了しがちなのが
　全体を平滑＆平均的に間引きしつつ、画像印象ほぼそのままに
　まぁ微々たる欠落が想定位置で見られるのは、相も変わらずだが

　｛Bフレーム：ref：GOP長｝＝｛4：8：12｝のままにて、想定ビットレートの削減に成功

　とはいえ、平均（34992）なので、25分想定は‥6.48GBと言ったところで参考程度だ
　（まぁ実写なら、0.5秒置きにキーフレームがあれば、キュルキュル感は十分だろう）


＞　ちなみに、心理的エンハンストは触りません（I4×4に前提鎖動してるくさっ）

【エンコードレシピ】有言実行の爆ＱるンＣランチ（480ｉ→1080p(Bob)→720ｐ）圧倒的版

↓一次処理＋二次処理12)記稿.2022/07/25

｜MPEG-2爆Ｑるンやあのサーチ 同じくしたき今ここにAVC-Q

　
｜窮すれば美学に奔る冬の角 命の価値を問うてをり‥（いざ天誅）
｜をる影を未だ照らさず秋深し 格差はいつも他人の素振り‥（いざ粛正）
｜素振りから計れぬ未熟落ち椿 殺意が「誠」と抜かす無念
｜無念よりこぼるる雫花朧 命の是非や夢のまた夢



＞　用意して頂くアプリは
＞　XMedia Recode 64bitのバージョン3545です。
＞　最新版から、x264.dllを抜き出して、3545側のと差し替えます。（略）


　‥取り扱うランチの種類は（略）
　今回レシピは、Ｃランチ（わさｂ抜き圧倒的版）のみになってます。
　Ｃランチのみ「二度揚げ」手法を用います。
　（ＨＤＤの空きを大きく用意しないと作業完遂不能‥これは痛い‥）

一次処理＞　480i→全部盛り1080ｐ[Bob]

＞　一次処理の用とは、とくにDVDの480i映像は可変フレームレートだったりと
＞　頭に描くようなお手本としたインターレース構造になってません‥（謎）
＞　あと、ここでは全部盛りなので、全部盛りの解像度を、一旦、正しく捉える用があります。


　‥480i映像の有効解像度は、704×480です。
　‥引き延ばして調整する規格にありますが、720×480まで盛られています。
　‥盛られてある向きは、4：3映像に見られるフィルム揺れを盛り込んであるからです。
　‥なので、4:3DVDソースを単純に704に切り取れるかというと、そうはなりません。
　（又、ビットレート不足から横端を断ち切ってある様子なら、正しく４：３展開など無理な話です）

　‥16：9ソースでは、その空白地帯をも利用して、細かい端数計算をやってるので
　‥制作会社ごとに黒帯の置き方が異なります。
　（どのソースがどのような構成をしているかなんて‥根気の無駄づかいなだけでやんす）


＞　‥ということで、正しい比率で全部盛り拡大　→　16:９に再構成　→　統一です。
＞　ところどころで誤差計算が気になるわけですが、そこはまぁ手順を踏むことで良しとします。


◆　XMedia Recodeにてmkvを選択

・　Ut.video（コーデック）を選択
・　フレームレートをオリジナル→[５９.94]に変更‥（Bobの鎖動条件なので忘れずに）
・　カラーモードを[YUV4:4:4Planar24bpp]に変更

　※ここでGBR（RGB）を選んではいけません。再エンコードするたびに色ずれの因と化します。
　※全部盛り→16:9再構成なので、割り切れない解像度変更がもう一度待機しています。
　なので、確実に各ビット別に計算できる「4:4:4」を選択しましょう。

　※ちなみに、VLCプレイヤーは、Ut.videoの4:4:4映像をサポートしていません。
　ソース状態を確認したかったら、AviUtl等のアプリで確認するようにしましょう。


◆　音声トラックは、好きにやって下さい
◆　インタレース解除項目の目のチェックを外す

　使用するフィルター：Yadif
　モード：時間軸＆空間軸のチェック（Bob）をスキップ

　（※Bob指定そのものが、≒30→≒60フレームレート変更（手動）と鎖動です）
　（※スキップ指定しないと、ｉ映像の輝度が解除演算にて削られて、画質が決定的に劣化します）

　順序：自動．


◆　クロップ／プレビューにて

内部4：3の場合
　幅：1472　[2]（解像度に奇数値を取り扱わず）
　高さ：1080　[2]
　スケーリング：双三次スプライン
　ディザリング：自動
　アスペクト比：カスタム【1.363636】‥（手動で打ち込み）
　アスペクト誤差：-2.2727…（自動調整値）‥に整っていなかったら打ち間違いあり‥
　　　　　　　　：0.0000（BD収録タイプで、もともとが1.363636で編集されてある場合）
　拡大：なし
　□　アスペクト比を保持
　720×480


※　1440：704＝ｘ：720　を解くと、ｘ＝1472.727272…
　並びに、1472.727272…÷1080＝1.363636…

---

内部16：9の場合
　幅：1964　[2]（解像度に奇数値を取り扱わず）
　高さ：1080　[2]
　スケーリング：双三次スプライン
　ディザリング：自動
　アスペクト比：カスタム【1.818181】‥（手動で打ち込み）→（1.818182に自動的に書換あり）
　アスペクト誤差：−2.2727…（自動調整値）‥に整っていなかったら打ち間違いあり‥
　拡大：なし
　□　アスペクト比を保持
　720×480


※　1920：704＝ｘ：720　を解くと、ｘ＝1963.636363…
　並びに、1963.636363…÷1080＝1.818181…
↓/続きを読む/↓