製品版発売おめでとうございます。さっそく使っております。

ただ、No.50619でも報告しましたが、24fps化すると仕上がりサイズがばらつくという症状は改善されていない様です。
これは、そのとき指摘された「VBRの値が安定しない」という不具合の一種だと思っていたので、
製品版では修正されているだろうと考えていたのですが、そうではなかったのでしょうか。

また、うちではその症状はでていない、というレスもいただいたので再試験したところ、
同条件でアスペクト比を16:9に、解像度を720x480にすると、仕上がりサイズはばらつきませんでした。
なので、この症状が起こるのは特定の条件が関係しているのだと思います。
検証担当様、これはこちらの環境固有の問題なのでしょうか。検証をお願いできないでしょうか。

(No.50619が半分埋もれかけていたので新規に投稿させていただきました。よろしくお願いします)

どうも出来上がりサイズがものすごく縮みやすかったり、ものすごく膨らみやすかったり
すると、収拾がつきにくくなるようですね。
Plusの時からですがVBRで1pass目と2pass目の処理をCQでやるから誤差がでるんじゃないかなぁと思います。

Plusの時のログですが
※MPEG-2 720x480 29.97fps VBR 7000kbps　←7000kbpsを目指してる

---- 1 パス目
フレーム= 0 ( 16.0) ビットレート: 2104 kbps 動き: 0.47 動き係数: 0.00 CQ値: 65.54
フレーム= 16 ( 16.0) ビットレート: 1755 kbps 動き: 0.19 動き係数: 0.00 CQ値: 65.54
〜〜
中略
〜〜
フレーム= 120 ( 6.0) ビットレート: 1721 kbps 動き: 0.18 動き係数: 0.00 CQ値: 65.54
実測ビットレート: 2194 kbps 平均CQ: 65.54

---- 2 パス目
要求ビットレート=7542.76 kbps オリジナル要求品質 = 86.29 要求品質 = 86.29 品質補正率 = 1.00 (org 1.00)
現在のビットレート = 4084.59 kbps
要求ビットレート=7440.75 kbps オリジナル要求品質 = 86.29 要求品質 = 86.90 品質補正率 = 1.03 (org 1.12)
現在のビットレート = 4286.83 kbps
〜〜
中略
〜〜
要求ビットレート=5454.04 kbps オリジナル要求品質 = 86.29 要求品質 = 92.81 品質補正率 = 1.54 (org 2.00)
現在のビットレート = 5257.96 kbps


※映像の平均ビットレート = 5016.36 kbps
Plusでも特定の映像だと2000kbpsほど外しました。

1pass目がCQ65で2pass目がシーン毎にCQ値を変えてエンコードする可変CQなエンコードですね。
CQの方が映像的にはビットレート指定でVBRエンコードを行うよりも画質は安定します。
しかしCQではサイズ予想が付きにくいと言う欠点があります。

この指定されたビットレートの画質を実現するCQを割り出し、そのCQ値を与え、エンコード
を行った。が、その画質は目標ビットレートが無くともそのCQで達成された。
って事なんだと思います。
逆のパターンで膨らむ場合は困り物ですが、縮む場合は微妙ですね。
エンコードエンジンが高性能化されて、縮みやすくなってるんじゃないかな(^^;

実は3.0.0.7でエンコードしていてビットレートが狂っていたソースがあってずっと残していたんですが（NHKの新撰組）
今回体験版で試して見た所、これは2G程度になるはずが1.5Gになっていたんでが。
これは治っていました。
おそらくこっちの問題は計算ミスだったんでしょう。

映像パターン毎にVBRの収束の具合が違うんでしょうね。

製品版で実際にやってみましたが、うちではばらつくことはありませんでした。もしか
してソースに依存する動きではないでしょうか？　たとえば、ビットレートを4000kbps
あたりにしてその他の設定は同様でエンコードして、ビットレートの上昇分程度ファイ
ルサイズは増えますか？　また他のソースでも同様の傾向を示しますか？

以前私が経験したのは、352x480出力で1800/2500/3500kbpsと指定してエンコードした
ときに2500と3500の出来上がりサイズに誤差以上の差が出なかったことです。この
ソースを検証すると、テストしたエンコード設定では2400kbps付近でファイルサイズが
頭打ちになっていました。CQ-99でも2500kbps付近で頭打ちになりましたので動作と
しては正しいんじゃないかと思います。

皆さん、レスありがとうございます。
追試やってみました。
エンコード設定はNo.50619で示した通りですがVBR平均を2400Kbpsにして、ソースは25分のアニメです。
予想サイズは459MB、出来上がりは284MBになりました。別の2つのソースに変えても、357MB、334MBになってしまいます。

そこで予想サイズとの誤差が最も大きい284MBになったプロジェクトを標本として、3つコピーし、
部分的に設定を変えてエンコードすると以下のようになりました。

　　　　平均レート　DC成分　タイプ　　予想サイズ　出来上がりサイズ
標本 　　2400Kbps　　 9bit　再生時3:2　　459MB　　　284MB
その1　　4800Kbps　　 9bit　再生時3:2　　884MB　　　744MB
その2　　2400Kbps　　10bit　再生時3:2　　459MB　　　284MB
その3　　2400Kbps　　 9bit　プログレ 　　459MB　　　458MB

その1は、ご指摘のあった、平均レートを2倍にすると、その上昇分ファイルサイズが増えるか、「頭打ち」になるのかの確認。
その2は、目標CQを達成するのに設定レート以下ですんでしまったからでは、というご意見から、
だったらDC成分を厳しくすれば目標値も上がるだろうから、出来上がりサイズも増えるんじゃないか、と考えて確認のため。
その3は、2と同様、だったらプログレッシブ(30fps)にしたらその分のフレーム増加分、サイズも増えるんじゃないか、と考えて確認のため。


結果を見るとご意見通り、設定ビットレートの画質を実現すべく割り出したCQ値が、実際には設定値以下のビットレートで達成された、
と考えるべきだと思われます。
ただ、その1の結果のように、ビットレートの上昇分ファイルサイズは増えるので、必ずしも「頭打ち」が起こるとも言えないようです。
(というか、「指定されたビットレートの画質を実現するCQを割り出す」とき、フレームレートが少ないことを計算にいれずに、
30fpsで割り出してしまい、実際に処理したら24fpsだったからその分余ってしまった、とも考えられませんか。
No.50619のレスでも指摘がありましたよね。 :-)

ともあれ、わたし個人のレベルではこれ以上の進展(改善)は望めないので、ひとまずこの症状が起こる可能性がある
ということを前提に使っていこうと思います。

しかし、24fps化(再生時3:2プルダウン)すると予想サイズより小さくなってしまうというのは、非常に不便です。
DVDにできるだけ長時間の映像を高画質で収録しようと、ぎりぎりのエンコード設定をしているのに、
実際にできたものが予想より小さいサイズなのでは、正直とても困ってしまいます。
この症状がプログラムに起因するものなら、なんとか改善していただけるよう、強く希望します。
検証担当様、よろしくお願いします。長文失礼しました。

思いついたことがあり、もう1パターン追試しました。

　　　　サイズ　　平均レート　DC成分　タイプ　　予想サイズ　出来上がりサイズ
標本 　　352x480　2400Kbps　　 9bit　再生時3:2　　459MB　　　284MB
その4　　720x480　2400Kbps　　 9bit　再生時3:2　　459MB　　　458MB

その4は、「設定レートの画質を実現するCQを割り出す」とき、サイズが小さいことを計算にいれずに、
Full-D1のつもりで割り出したのに、実際にはHalf-D1だったからその分余ってしまったのでは、と考えてその確認です。

結果は、なんと予想通り。
これだけ見ると、
指定されたビットレートの画質を実現するCQ値を割り出しそのCQ値でエンコードする、
という処理をしているのだとすると、24fps化して、なおかつサイズが352x480のときは、
割り出すべきCQ値の計算に問題がある(甘めに評価されてしまう)のではないか、と思えてしまいます。

たびたびすみません、追加報告です。
(これでおしまいにしますのでご容赦を... :-)


最初2400Kbpsでエンコードしたけど、サイズが縮むので2900Kbpsでやり直した結果の出来上がりサイズの違い。
音声AC-3 192Kbps 34MBも含んだサイズです。

　　2400Kbps(予想サイズ459MB)　2900Kbps(予想サイズ547MB)
01　　357MB　　　　　　　　　　　501MB
02　　334MB　　　　　　　　　　　455MB
03　　284MB　　　　　　　　　　　487MB
04　　327MB　　　　　　　　　　　401MB

03のように2400Kbpsで圧縮効率がよいからといって、2900Kbpsでもよいとは限らないようです。

TMPGEnc 3.0 XPress使用ありがとうございます。
検証担当です。

もし宜しければ、ぶる〜さんの現象の発生する映像ソースをお送りいただけませんか？
弊社で現象の再現テストを行い、可能であれば修正したいと思います。
出力、フィルターの設定を保存したテンプレートやプロジェクトファイルを
同梱していただければより再現率が上がるかと思います。
また、環境設定での値等もわかりましたらお教え願えますでしょうか？
（CPU設定、2passキャッシュ設定など）

住所は下記でお願いします。
----------------------------------------------------
〒130-0026 東京都墨田区両国2-16-5 あつまビル5F
株式会社ペガシス
TEL 03-5624-1901
----------------------------------------------------

これからもTMPGEnc 3.0 XPressをよろしくお願いします。

ぶる〜さん>その4　　720x480　2400Kbps　　 9bit　再生時3:2　　459MB　　　458MB

Half D1でしか24fps可したことがなかったのですが、FULL D1だと予想に近いファイルサイズになるんですね。
私も、一度やってみよう。

いろいろお騒がせして申しわけありません。
検証担当様に提出するデータを揃えるため、この際徹底的に再現試験をしたところ、
この症状はかなり限定した条件で起こることがわかりました。

今まで報告した条件は
1.インターレース解除で24fps化すること。
2.出力設定のサイズを352x480にすること。
3.同ビデオタイプを再生時3:2プルダウンにすること。
でしたが、さらに
4.SONY VAIOのGigaPocketでのキャプチャを外部ライン入力から行い、
　映像はアニメーションなどの元が24fpsものであること。
が必要なようです。

特定のソースに依存するのではとご指摘いただいていたのに、
すっかり頭に血が上ってしまい、また地上アナログ放送の映像ソースを24fps化することもなかったため、
ソースのキャプチャ方法の違いが影響することに気がまわらず、大変失礼しました。

(4)の条件ですが、これがわたしの環境独自のものなのか、それともVAIOのこの機種に特有のものなのか、
これ以上の追求は難しいですが、確実に症状が起こるデータは用意できましたので明日にでも発送させていただきます。
よろしくお願いします。
また何か新しいことがわかりましたら報告させていただきます。

本日リリースされたver3.0.2.19でこの症状が解消されていることを確認いたしました。
これで安心して作業を進めることができます。
ありがとうございました。