【エンコード日記】480i→解除用途に限定で4×4マグロ丼が復活っぽ

↓2)記稿.2023/12/09

＞　前回、ベスポジに思えた↓だが
＞　9801（99^2）：627264（792^2）：793881（891^2）；（1.00）0.99235125％


　‥どうにも480i（16:9）の場合にそぐわないと判断
　704×480→1024×576という変換もさることながら、そもそものビットレートが足りんらしい
　（どちらかという（90^2）の方に輝度バランスの分が見られる）


　‥480i（4：3）の場合でも、パン場面において悩ましい不足を明らかに感じる
　（とくにアニメの場合は、あと少しとした感じが常にどうしようもねぇって感じ）

　（こうなっては、4×4を試してみようかなぁ‥みたいな）


＞　とはいえ、どうにも1080解像度出しして、比べてみないとなんとも言えないのである
＞　そんなこんなで計算し直した結果が↓になる


640×1.125＝720
88×1.125＝99　※（4：3）の場合、どうやら7744ではパンチ不足だったらしい

99×1.333333‥＝132（参考：99×1.5＝148.5，99×2.25＝222.75）
99×1.777777‥＝176
88×2.25＝88×（1.125^2）×（1.3333333‥^2）＝99×1.125×1.777777‥＝99×2＝198


_17424（132^2）：435600（660^2）：627264（792^2）；（0.49）0.78408％
_30976（176^2）：495616（704^2）：774400（880^2）；（0.36）0.968％
_39204（198^2）：352836（594^2）：627264（792^2）；（0.25）0.78408％


99×1.111111‥‥＝110
_12100（110^2）：592900（770^2）：774400（880^2）；（0.81）0.968％
_30976（176^2）：495616（704^2）：774400（880^2）；（0.36）0.968％
_48400（220^2）：435600（660^2）：774400（880^2）；（0.25）0.968％

（↑は、774400÷800000＝0.968％に揃えた様相である）


＞　共通解として垣間見えたのが
＞　30976（176^2）：495616（704^2）：774400（880^2）；（0.36）0.968％である


　‥そんなこんなで出してみたところ
　480i（4：3）→解除60枚構成1472×1080（1.36296296‥）
　480i（16:9）→704×480→解除60枚構成1920×1080（16：9）

　（ちなみに、23分半ぐらいで5.2GBに及ぶ）
　（さらに、再生支援機能で視聴した方が‥輝度解釈として補正が入るのか‥画質が安定的になる）


＞　それにしてもエンコード時間をもっとどうにかならないか？


　‥480i（16:9）に関しては
　（176^2）を1080解像度にできるんだから
　（110^2）を720解像度にできそうに思える‥

　‥480i（4：3）に関しては
　発色にこれとした問題は無さそうでも、どうにも動きにガタつきさが見られるのが惜しい
　この点を改善するには、4×4マクロブロックしかなさそうである


＞　‥その両方を併せて試してみたところ
↓/続きを読む/↓

【エンコード日記】空間軸圧縮が何をしているのかがよく分かるサンプル

)記稿.2023/12/07

＞　空間軸圧縮とは、マクロブロックサイズで、似たような形状を探し出して
＞　どうにかこうにか当てはめるパズルのような応用である


↓は、それがとてもわかりやすいサンプルどえす

では問題です
↓の絵の中に目玉に見えるマクロブロックはいくつあるでしょうか？




‥目玉に見える数ですよ

歯に付いてる影なんてどうですか？
その上にある、頬皺なんてどうですか？
そのちょっと上に髪の毛の影が二つほどありますが、その辺りなんてどうですか？

そんな感じで、右目の形を模したマクロブロックがチラホラしています
左目のもいくつか見られますが

そんな感じに、似たような形を探し出して使い回すのが空間軸圧縮どえす

（でもここまで露骨に目の形を使い回すとは、来てますよね）


‥という次第なので
解像度を上げた際にも、似たようなモノを探し出して
ビットレートを割り振るどえす

ド素人が考えるように品質が上がるという次第ではありません
品質を上げたいなら、量子化前のマスターデータ必須なんですよ


‥空間軸でさえこれですからね
さらに時間軸を掛け合わせると
その秒間にいくつの目玉が散らばるかと思うと、もう、うんざりしますよね


＞　なぜか、480→528サイズでキャプチャーされてる‥？？
＞　ということで、駄目押しで1472×1080サイズをどうぞ↓

【エンコード日記】解像度が異なると限界となるビットレート謎比が異なる‥規格上限を得る件

記稿.2023/12/06

＞　AVCのレベル6.2のVBV最大ビットレートの限度値は（800,000）kbits/s‥である
＞　その限界に近づけるほどに輝度を増す（艶を得る）ことが判明どえす


　‥ゴレンジャーの後期OP（キレンジャーの役者交代版）だと
　まだまだ輝度が不足していて色が出て来ないというパターンが
　時期的に重なる作品に多々見られる‥（何らかのどうしようもねぇ物理的な変更期だった草）

　其を改善する為の秘策＆着想こそ
　Psy-Trellis強度（1.00）に最適化する為のビットレート謎比とした値の調整だ
　1080解像度だと物理的に無理だが、480解像度でならギリギリで満たせる
　その数値こそ‥


＞　レベル6.2の上限800000→≒べき乗値の上限（894^2）→（891^2）
＞　9801（99^2）：627264（792^2）：793881（891^2）＆（1.00）‥こそベスポジだった
＞　とどのつまり｛1：64（8^2）：81（9^2）｝＆100（10^2）‥だった


　ザックリ↓のイメージになる


　7744（88^2）：_69696（264^2）：123904（352^2）0.25
　7744（88^2）：123904（352^2）：193600（440^2）0.36
　7744（88^2）：193600（440^2）：278784（528^2）0.49
　7744（88^2）：278784（528^2）：379456（616^2）0.64
　7744（88^2）：379456（616^2）：495616（704^2）0.81
　↓
　7744（88^2）：495616（704^2）：627264（792^2）1.00‥‥ビットレート不足っぽ
　8100（90^2）：518400（720^2）：656100（810^2）1.00‥‥ビットレート不足っぽ


　要約すると↓を得る

　｛1：_9（3^2）：16（4^2）｝＆25（5^2）
　｛1：16（4^2）：25（5^2）｝＆36（6^2）
　｛1：25（5^2）：36（6^2）｝＆49（7^2）
　｛1：36（6^2）：49（7^2）｝＆64（8^2）
　｛1：49（7^2）：64（8^2）｝＆81（9^2）
　｛1：64（8^2）：81（9^2）｝＆100（10^2）


＞　ちなみに‥｛640：704：720｝＝｛1：1.1：1.125｝＝｛88：90：99｝だった
＞　‥其を踏襲してやりゃバッチリだったのである‥


　‥うんちくを無理矢理垂れてみると
　マクロブロック数の倍倍を十分に満たすVBVバッファサイズを組み込んでやるのが
　一つの条件らしく‥そこから・・・・で、均一性を保った輝度の改善を得るっぽい

　つまり、バッファ値を64倍にすることで、十分に4×4マクロブロックの代役を満たすっぽい

　ならば、FHDでの4×4なんざ、ほんの気分程度しかないから、8×8に丸め込めるくさっ
　という関係性に思われる

　とはいえもう一つの物理的な限度値（208^2）が立ちはだかるので
　FHD規格での輝度上限値は、DVDもとい従来のテレビ規格より下回る流れになった草っ


＞　1：9：16＆25
＞　39204（198^2）：352836（594^2）：627264（792^2）＆（0.25）
＞　43264（208^2）：389376（624^2）：692224（832^2）＆（0.25）


　‥800000÷25＝32000　→　≒平方根の最大値（178）　→　99からのべき乗値比確保（176）
　176÷99＝1.777777‥（1.333333‥^2）

　ということから

　1：16：25＆36
　30976（176^2）：495616（704^2）：774400（880^2）＆（0.36）

　が、60枚構成1280×720pでの均一性を保つだろう輝度発色を期待できるのでは？

　　‥ソースに依っては、60枚構成1920×1080pでもイケそうに思われるも
　　それなら縮める用が無い分↓の方が良さげである
　　31684（178^2）：506944（712^2）：792100（890^2）＆（0.36）


　793881÷800000＝0.99235125％　←ビットレート（99^2）
　792100÷800000＝0.990125％　←ビットレート（178^2）
　774400÷800000＝0.968％　←ビットレート（176^2）
　692224÷800000＝0.86528％　←ビットレート（208^2）
　627264÷800000＝0.78408％　←ビットレート（198^2）


＞　ということで‥再びの全部確認やり直し‥ンゴ！!
＞　しかも確認すべき量が倍になってる（年内に終わらねぇくさっ）

【エンコード日記】ビットレート謎比｛1：9：16｝にしたらダウンコン720pが安定的に

記稿.2023/12/05

＞　ビットレート謎比｛1：4：9｝から｛1：9：16｝に切り替えたところ
＞　1920×1080→60枚構成1920×720pへのダウンコンが安定的になった


　‥そこで、これまで及び腰だったPsy-Trellis強度の耐久テストをしてみたところ
　（1.00）までこれとした副作用を発生せずに耐久力を発揮するものの
　さすがに、ビットレートを持って行かれるのか、細かいテクスチャーが全部剥がれ気味に陥る
　（そこまで行くと1024×576ｐと大した差を感じない）

　‥そんなこんなで、静止画拡大比較した際の見た目の良さげなのが（0.25）らしい（確認中）

　テクスチャーが剥がれまくっても良さげに見える次点が（0.81）になるが
　（0.25）に比べると概ねボケて見えるのでどちらにしても使えない
　（ビットレートをさらに盛り付けたし考えなど有るはずも無し）


＞　基本的に、Psy-Trellis強度が何をしているのかなんて知らんがな


　‥が、ダウンコンの色の取り出しの際には、潰れた解像度の色の中間を心理的に確保するのだろう
　あとは、輝度を優先にする度合いとか‥

　それのビットレート割り当ての度合いに思われるが
　通常概念とした設定だと
　値を増加するほどにビットレートを持って行かれてボケるとか‥そんなの気にする以前に
　壊れたテクスチャーとした副作用が発生して使えなかったわけで
　そこが優恋里小扉だと‥作用そのものが異なっているのだから不思議だ（10ビットを条件とする）


　‥ダウンコンのくせにインターレースを用いない代わりに
　Psy-Trellis強度を試しているわけだが（そもそもの720解像度にインタレースとした仕様が無い）

　その差の違いなのか、盛り付ける値によっては
　解像度潰れとした中身の色をどうにか引き出そうとしたノイズ感を見せる諸々傾向がある

　とくに、（1.00）まで上げると
　部分的な輝度を優先して‥無駄にビットレートのやり繰りをするのか
　妙にそこだけ色が派手で、ノイズにしか見えなかったりとする（静止画だし拡大時）

　それが部分的で無く、線状として現れる場合もある
　大抵は横筋だが、縦筋としたパターンを見せる値もある（静止画だし拡大時）


　‥とはいえ、静止画での拡大にて判別つく度合いでしかないので副作用の範疇では無い
　‥とはいえ、逆に値が小さくても、モヤモヤした感じ傾向を見せてよろしくない
　　（通常はそこの差を、ブロッキングで調整するような案件なんだろうけど）
　　（優恋里小扉では、そこで、何が起きているのかなんて知らんｚ）


＞　｛1：4：9｝｛Psy-Trellis強度（0.09）｝から
＞　｛1：9：16｝｛Psy-Trellis強度（0.25）｝にビットレート謎比を変更した結果


　‥その画質差としては
　初期型の端丸カラーテレビ　→　端角カラーテレビに変わった感ぐらい
　モヤッとしていたのが消えてクッキリしている
　（アニメだと記憶差で気になる場面との違いぐらいでしか判断付かないが、特撮だとよく分かる）
　（とはいえ、ソース次第にある点は変わらないが、取りあえずの目標に到達した感はあるだろう）


　‥確認作業はまだまだ続く（結局、暫定でのレシピ揚げくさっ）

　（ビットレートの割り当て余裕が思っている以上にあるようなのが謎）
　（そこが８ビットと10ビットの差という事なのだろうか？？）

【エンコード日記】ビットレート謎比｛1：9：16｝を一覧にしてみた

↓2)記稿.2023/12/05

＞　ビットレート謎比｛平均ビットレート：バッファ：最大ビットレート｝
＞　これを｛1：4：9｝から｛1：9：16｝にしても
＞　メインとなるビットレート値は変わりません‥変わるのはPsy-Trellis強度どえす（なんでやねん）



＞　好逸ユーザー（シャープネス24）組


　480i（4：3）→解除60枚構成720×480ｐアスペクト比1.36296296‥‥SMPTE170M
　7744(88^2)：69696(264^2)：123904(352^2)‥‥扱いレベル5.2

　480i（4：3）→解除60枚構成アプコン1472×1080ｐアスペクト比1.36296296‥‥BT.709
　26244(162^2)：236196(486^2)：419904(648^2)

　※　(162^2)は参考までで、画質アップの体を満たしません（480iからアプコンする意味が無い）
　　とくにアニメの場合は、作品によってはBT.709ボケを見せたりします
　　エンコード時間も馬鹿にならないので、画質的にも容量増的にも720×480をオススメします


　i解除＆Ｐ（4：3ソース）→60枚構成1472×1080ｐアスペクト比1.36296296‥‥BT.709
　39204(198^2)：352836(594^2)：627264(792^2)‥扱いレベル6.2



＞　好逸リビング（シャープネス24）組


　480i（16：9）→解除704×480→60枚構成1024×576（16:9）‥‥SMPTE170M
　i解除＆Ｐ（16：9）→60枚構成ダウンコン1024×576ｐ（16:9）‥‥SMPTE170M
　8100(90^2)：72900(270^2)：129600(360^2)‥‥扱いレベル5.2

　480i（16：9）→解除704×480→60枚構成アプコン1920×1080（16:9）‥‥BT.709
　i解除＆Ｐ（16：9）→60枚構成ダウンコン1280×720ｐ（16:9）‥‥BT.709
　28900(170^2)：260100(510^2)：462400(680^2)‥扱いレベル6.2

　※　こちらはアプコンする用を満たしますが
　　　480→アプコン1080なのに対して、1080→ダウンコン720になっとります
　　　（それだけ量子化済みの1080ソースは中身が複雑どえす、舐めてはいけません）
　　　‥細かいことを言うと
　　　　1080i→576pダウンコンする際にも此処のポジジョンしか無いので同じなら720pでしょう
　　　　1080p→720pダウンコンなら（135^2）も候補に上がりますが、確認し切れていません


　i解除＆Ｐ（16：9）→60枚構成1920×1080ｐ（16:9）‥‥BT.709
　43264(208^2)：389376(624^2)：692224(832^2)‥扱いレベル6.2



＞　81×81×4＝26244(162^2)
＞　81×81×4.444444‥＝29160≒28900(170^2)

＞　99×99×4＝39204(198^2)
＞　99×99×4.444444‥＝43560≒43264(208^2)

＞　｛90：170｝＝｛135：255｝
＞　135÷90＝1.5，255÷170＝1.5‥‥（参考値）
↓/続きを読む/↓

【エンコード日記】モノトーン、セピアに変わりうる第三の回想パターンを発見した件

記稿.2023/12/02

＞　そろそろ中間まとめレシピをあげないとこちらの話が伝わりにくいのだが
＞　480i→60枚構成1024×576ｐの性能テストをしていたのだが
＞　1920×1080からのダウンコンができるようになってたのでついついやらかしていたのだが


　‥それが以前より細かく拾えるようになっていたというか
　より正確になっていたというか
　その割りには、ソースに依っては、色褪せているような様相を見せて来るので

　‥BT.709から、ちょっとだけ此処の色が違うとか、そういう様相に無くなっており
　ガッチリ、BT.601に変換して来るくさいのだ

　そのあまりにも綺麗に整ってくる精度に（1024×576サイズとして）

　ついつい勢い余って、とあるUHDソースを
　60枚構成1024×576ｐにて、ダウンコンしてみたところ

　あり得ねぇぐらいに色が薄いでやんの
　まるで、色褪せた写真状態のアニメを見ているかのような雰囲気にピンと来てしまった


＞　つまり、BT.2020→BT.601としたダウンコンにこそ
＞　第三の回想パターンを得られるツボがあるらしい（ノイズレス表現にてイケそう）
＞　（これこそが、優恋里小扉なのでは？‥と）


　‥逆から問えば
　色褪せた写真のカラーを復活させられるノウハウが隠れているかも知れないと


　‥とはいえ、それはそれとして
　ダウンコンやらアプコンをする際の色の壁への対処をしなければならない
　という結論でもある

　‥ということで
　｛1：4：9｝から｛1：9：16｝を試してみることに

【エンコード日記】480i→60枚構成1024×576ｐで計算してみたら‥16：9専用で割り切れる‥

↓3)記稿.2023/11/27

＞　まずは、現状の確認をしましょう
＞　フィルムの基本構成を、1472×1080（アスペクト比：136296296‥）内部4：3とした時


BT.709
　1080ｉ,ｐ（内部4：3）→60枚構成1472×1080ｐ、好逸ユーザー（シャープネス：24）
　39204(198^2)：156816(396^2)：352836(594^2)


SMPTE 170M
　480i（4：3）→解除60枚構成‥720×480p（アスペクト比：1.36296296‥）
　7744(88^2)：30976(176^2)：69696(264^2)‥好逸ユーザー（シャープネス：24）

BT.709
　480ｉ（4：3）→解除60枚構成アプコン‥1472×1080ｐ、好逸ユーザー（シャープネス：24）
　26244(162^2)：104976(324^2)：236196(486^2)


　この場合、704×480だと、ソースに依っては横揺れありのままに収録されていたり
　中には、720×480にど合わせて収録してあったりして（謎）
　制作会社毎での判断が、まちまちである次第なので
　どうしたって、720×480とした全部盛りにしてしまうのが手っ取り早くなります


＞　で、調べた結果、フィルムには‥9801（99^2）とした基点からの
＞　480←→1080相互互換（アスペクト比：136296296‥）とした方が適切だと判ってきました


　‥規格のそもそもがフィルム映像を
　アナログ→デジタルへの移行に織り込むことが主目的だったこともあり
　其処がスタートだったはずでしょうし

　720×480÷256＝1350（16×16のマクロブロック数）
　1472×1080÷256＝6075（16×16のマクロブロック数）

　1350×2.25×2倍＝6075‥とした値を醸すのは必然に思われます
　（ならば、フィルムのアスペクト比：1.36296296‥は必然の着目だったはず‥）


＞　ところが、デジタルハイビジョン規格立ち上げ当時に出回っていた
＞　ＰＣモニターの解像度のスタンダードは、1024×756（アスペクト比：1:1）だったと思います
＞　開発を特注モニターにて押し進めていたとしても
＞　結果的に、1024×576解像度での確認が主流だったように思われます
＞　（もしくは、960×720でしょうか‥‥）


　‥そんなこんなの親和性とした痕跡のような是非値を発見しました‥
↓/続きを読む/↓

【エンコード日記】480i（4：3）→480pにもアスペクト比1.36296296を試してみたら‥

追記.2023/11/26...20231125...

＞　‥あんなに画質が上がらなかったのに
＞　アスペクト比1.36296296にしてみたら、ほとんど同じにしか見えねぇ（内部の扱いは4：3）
＞　（勿論、SMPTE 170MとBT.709とした差はありますが‥）


　‥DVDアルプスの少女ハイジ‥の中の残念な二大ガコガコパンにしても
　遂に完治し得たでしょう、360度パンにしても想定内に収まった感じでしょう


　‥ガチで、そこかよォォオオオ!!!
　（VLC（3.0.20）になってデコード画質が上がっているようなのだが、その影響もあるような‥）

　で、肝心のビットレート値なのだが

　99÷2.25＝44
　4×44×44＝7744（88^2）‥来ましたｚ（88）


＞　はいもう一度‥「マジ、そこかよォォオオオ!!!」


　480i（4：3）→解除60枚構成‥720×480p（アスペクト比：1.36296296‥）
　7744(88^2)：30976(176^2)：69696(264^2)‥好逸ユーザー（シャープネス：24）

　（↑これで出すと、拡大意欲が猛烈に萎えるっす）
　（キーの位置は多少変わるところも見られるが‥時間を掛けずにやりたいどえす‥）

　（ちなみに、ハイジの一巻で動画部5.58GBなので、必ずしもソースより減量するとは限りません）


＞　‥どちらにせよ、16：9ソースの方は、704×480なんて嫌だろうから
＞　そこは、704×480→1280×720あたりでやらかしたい

＞　すると、704×480：アスペクト比誤差（-2.2727‥）とした扱いが
＞　実は、480i（16：9）専用だったのではないのか？‥という疑いが浮上するどえむ


　まぁどうしたって、テレビ放送のインターレースが、1440×1080の横幅縮小なもんだから
　いつの間にやらそちらが一人歩きして

　704×480：アスペクト比誤差（-2.2727‥）こそが正しいのだと一本化してしまった


　‥4：3は、1472×1080とした基準でやらかすべきが、どこかに吹き飛んでしまった草っ
　　（フィルムそのまんまの横幅を想定して居るにもかかわらず、無視された？）
　　（折角に、32で割り切れる値なのに‥無視された？）

　1472×1080←→720×480（アスペクト比：1.36296296‥）相互互換こそが正解だった
　（でも、BD規格にしても、その手の仕様には無いですからネ）


＞　なので、まとめると、4：3タイプに、解除720ｐなんてありゃしねぇどえむ
＞　16：9タイプの場合に限り、解除720ｐは、規格想定内の扱いに思われます


　‥いやいやいや、そうなると、後は
　解除480i（16：9）→704×480→1280×720（16:9）の際のビットレート値です
　この辺かなぁ↓と思うもまだ未確認にて不明です（盛りすぎなのでは？）

　19321(139^2)：77284(278^2)：173889(417^2)‥好逸リビング（シャープネス24）


　‥もう1080解像度しかないようです
　480i（16:9）のそもそもの中身は、BT.709なのだから
　フィルムとは違って、見てきてないので
　BT.601からのアプコンに相応しいそれとした印象を覆せない
　なので、基準の想定としてどうしたって1080解像度に寄せるしかありません

　（だってビットレートの割り振りは規格内だとしても、時間に関しては任意だから）
　（テレビで見てきたという社会全体とした説得力としての落とし所が無いに等しい）

　‥その点、480i（4：3）の場合は
　フィルムとした形での相互互換とした落ち着きがある（そんなところに思われます）

【エンコード日記】1472×1080の正確なアスペクト比は（1.36296296296‥）である

記稿.2023/11/23

＞　またまた奇妙な値の関係性を発見してしまった（只のたまたまとは思えない）


　81×81×4＝26244(162^2)
　81×81×4.4444444‥＝29160‥の平方根→（170.7629936490925）

　9801×4＝39204(198^2)
　9801×4.4444444‥＝43560‥の平方根→（208.710325571113）


　↓つまり


＞　480ｉ→60枚構成1080ｐ（4：3比ソース）、好逸ユーザー（シャープネス：24）
＞　26244(162^2)：104976(324^2)：236196(486^2)

＞　480ｉ→60枚構成1080ｐ （16：9比ソース）、好逸リビング（シャープネス：24）
＞　28900(170^2)：115600(340^2)：260100(510^2)



＞　1080ｉ,ｐ→60枚構成1080ｐ（4：3比ソース）、好逸ユーザー（シャープネス：24）
＞　39204(198^2)：156816(396^2)：352836(594^2)

＞　1080ｉ,ｐ→60枚構成1080ｐ （16：9比ソース）、好逸リビング（シャープネス：24）
＞　43264(208^2)：173056(416^2)：389376(624^2)


　‥という想定が浮上しておりまして
　4：3タイプの解像度を‥1472×1080に統一してやらかそうと考えだしまして
　その際の正確なアスペクト比を統一してしまうべきなんじゃねぇの‥とツッコミだしたどえす
　（中には、1552×1080に黒帯ソースもありますが、そういうのはまだ後まわしです）


　‥そもそもこうなったのは
　上下をカットしてある1080ｉ→60枚構成1080ｐに不満があるからです

　（こうなったらもう上下帯をカットして拡大しても好いんじゃねぇの‥と思い立ち）

　細かい計算をしてみたところ
　どうにも‥1418×1064になっているらしい
　（まぁ‥黒帯を大きく取り除くと、字幕データのある際の表示に問題化しそうですが‥）
　‥この場合、1440×1080を想定している事に変わりは無いのだが
　1472×1080の方が割り切りの比率が良いので、1440×1080を敢えて蹴ってます
　（どちらにせよ誤差からは逃れられない状況どえす）


＞　1418×1064（クロップ幅：上下8カット）→（アスペクト比：1.332706766917293）
＞　1064÷1080＝（0.9851851851）
＞　1472×（0.9851851851）＝1450.19259259≒1450（クロップ幅：左右235カット）
＞　1472÷1080＝1.36296296296（この手の誤差-0.9044‥らしい）
＞　‥（スタンダードな誤差-2.2727）とは、異なってきます


　ちなみに、480ｉ（4：3）の解除全部盛り1472×1080のアスペクト比を
　1.36296296296→（≒1.362963）にすると（誤差-2.2222）になります

　ついでに、1080ｐ（4：3）の黒帯カット1472×1080のアスペクト比を
　（クロップ幅：左右224カット）
　1.36296296296→（≒1.362963）にすると（誤差-0.0000）になります



＞　ちなみに、480ｉ（16：9）の704×480→1920×1080の際のアスペクト比なのですが
＞　オリジナルのままよりは（16：9）と切り替えた方が
＞　再生中にイヤンなコマ落ちしにくくなると言う
＞　当方のハード都合によるヘンテコな解を得ております（謎）
＞　（‥なにかがとても違うらしい‥‥バグっぽい中身に思われますが‥）

【エンコード日記】｛平均ビットレート：バッファ：最大ビットレート｝を一覧にしてみた

↓1)記稿.2023/11/21

＞　言わずと知れた十進BASICです


DECLARE STRING X$(208,2),Y$(208,2),Z$(208,2)

FOR I=70 TO 208 STEP 1
　LET A=I^2
　LET B=I^2*4
　LET C=I^2*9

　LET AA=SQR(A)
　LET BB=SQR(B)
　LET CC=SQR(C)

　LET X$(I,1)=STR$(A)
　LET X$(I,2)=STR$(AA)
　LET Y$(I,1)=STR$(B)
　LET Y$(I,2)=STR$(BB)
　LET Z$(I,1)=STR$(C)
　LET Z$(I,2)=STR$(CC)

　LET AAA$=X$(I,1) & "(" & X$(I,2) &"^2)"
　LET BBB$=Y$(I,1) & "(" & Y$(I,2) &"^2)"
　LET CCC$=Z$(I,1) & "(" & Z$(I,2) &"^2)"

　LET amari=MOD(I,10)
　IF amari=0 OR amari=1 THEN PRINT

　PRINT AAA$,BBB$,CCC$

NEXT I

END


※　まず数値を配列に入れて、次に文字列の配列に変換代入しようと思ったのだが
　　諸々とエラーしまくるのでスパッと諦めた（どこで間引けてどこで駄目なのかよく分からん）
↓/続きを読む/↓