bkmcwdさん、どうもありがとうございます。
なるほど、最大フレームサイズとフレームリミットの「バランス」なのですね。
正直bkmcwdさんがこれまで「このパッチはバランスがいい」とおっしゃっているのがよくわかってませんでしたので、ちょっとだけイメージがわきました。
ということは、今はフレームサイズを最大に保ちつつ、フレーム圧縮が起きない限界点を探っている、という風に捉えればよいのですかね。
（それも一般人にはあまり見えてなかったりする点です。まったく内情を知らずに表面からだけスレを眺めていると、Qの数値は小さければ小さいほどいい、という誤解をする私のような人は多くいると思われます。）
素朴な疑問なのですが、なぜフレームリミットなるものが存在するんでしょうか？　カード速度不足ストップを防ぐため？
ではコマ落ちというのは理論的には何が足りないから起こることで、どうすれば防げるんでしょうか？

あと、もう一点おうかがいしたいのですが、例えば昨晩貼られたQ12や、今まで本家に貼ってあるbkmcwdさんのパッチは、新しい3.63dでそのまま使えるのでしょうか？
DWが3.63dに合わせたバージョンを早々に発表したので、他の方のパッチはどうなんだろう？というのが気になってます。

はじめまして
１週間ほど、ここを参考にしながらやっと理想的な設定が出来上がったので
目の肥えた皆様に改善個所やダメだしを頂こうと、持ってきました。

PTool v3.62d 専用です。v3.63dでは使えません

bureno.hcak@24p40M6GOP 30p32M6GOP 60i32M9GOP QI22 Q0
http://bureno.eek.jp/up/files/setj.ini

メインは60iの、ビットレート節約型です。
一応、高ノイズにも耐えますが、基本的に低ノイズで本領を発揮します。
手持ち自然撮影暗所はＦＳＨ　　三脚人工建造物の長時間撮影はＦＨ

24p80%の30p撮影(30p時は24H→24L)も可能です。

raitankさん、私は専門家ではなく、「本能のテスター」ですってばもうー^^;
本来ならsoruさんの質問に先に答えたいのですが、上手く説明できなくて困っています^^;
実にいい質問なので、もう少し整理させてください。
で、ここからburenoさんのパッチについての解説が始まりますが、その中で気が付くこともあろうかと思います。

で・・・
burenoさん、はじめまして^^
私もここに書き込みをされている数少ない皆さんも、ほとんどが24pしか使わないので、申し訳ありませんが他はよくわからないです^^;

で、ちょっと今時間がないのでパラメータだけ拝見してみるつもりだったのですが、よく見ると今まで見たことない組み合わせになっていて、変な意味で興味が湧いてきました(笑)
結果は予想できるけど、実際どうなの？というレベルで・・・あと、本家をしっかり読んでいない方、読んでいるけど間違って理解している方も多いと思い、あえてこれを解説することでそういう方への参考になるかもしれないので手を着けることにしました^^
というわけで、3.62専用との意味は「ISO12800は想定していない」という意味と思いますので、ISO3200でStrayのテストチャートで私がいつもやっているストレステストをやってみました。

繰り返しますが、あくまでもこれは24pだけの結果です。
そしてここで述べる解説や意見は、私が本家Parsonal Viewをこの数ヶ月読んでテストも実際にしてきて、こういうものだと身に着けてきたことばかりなので、ソースがどこにあるかはその都度示すことが出来ません。ご自分で探してみてください。
逆に、貴兄が確実に理解していて私が間違っている点があればそれを教えて欲しいと思います。

まず結論から言うと、私的にはこのパッチはもしこれが本当の40Mセッティングだとしたら「意味がない」と思います。
なぜならば、この低ビットレートで6GOPにしたら当然フレームサイズが小さくならざるを得ないので、画質が12GOPより悪くなると思われるからです。
細かいところを挙げればキリがないのですが、この6GOPというのがまず意味がないと思われます。
私も過去に低ビットレートの6GOPを作ったことがありましたが、最低でも66M以上で無いと6GOPにするメリットは感じられないのではないかと考えます。
Chrisの44Mの模範パッチは試されましたか？もしこの貴兄のパッチが本当に40M6GOPなら、確実にIフレームサイズはあれよりも小さくなるのは数が倍ですから当然ですよね？
逆に、あれよりも小さいフレームサイズにしないと6GOPは実現できないと言い換えることも出来ます。

「本当に」と断りを入れたのは、これって例の(actual frame rate is half)が表示されていますから、恐らく実際のビットレートは倍の84Mになっていますよね？
私も過去にこのパターンを散々作ってきて、使えりゃいいじゃんと思っている一人ではありますが、こと「ビットレート節約型」というのならこれが表示されるようでは全然節約型ではないことになります。
この辺りは本家のLOWGOPスレで何度もChrisが説明していますので参照してみてください。「偶然使えればいい」というレベルで使うなら問題ないと言われている、わたしにとってはトラウマのようなケースですね(爆)

あと、AQとQ値は私の知る限りでは同時に入れても意味がないものですが、これらを同時にチェックを入れると効果はどうでしたか？
これらはオートかマニュアルかの違いなので、本家で同時にチェックしているものを今まで見たことがありませんでした。どういう変化が出るのか興味があります。
ちなみにQ値は圧縮率をコントロールするパラメータですが、私は今までQ=0でまともに動くパッチを知りません。もしかしたら超高ビットレートで最大フレームサイズを小さくしたら実現可能なのかもしれませんが、意味無いですよね。
この点は私は本家しか見ていませんから、他所にQ=0の素晴らしいパッチがあるとしたら、是非教えていただきたいです。

そして、上で指摘した(actual frame rate is half)が表示される原因である、ビットレートセッティングについてですが、たかだか40Mでこの数値はありえません！(笑)
私も過去に同じことをやっています（66M3GOPAQ3）が、恐らくこの数値から想像すると、見た目は40Mですが本来実質は88Mくらいのパッチということになろうかと思われます。
あと、非常に興味深かったのがこの
1080p24 High Top Setting=21209
1080p24 High Bottom Setting=14846
1080p24 Low Top Setting=15589
1080p24 Low Bottom Setting=10912
の各値には共通の倍数をかけることになっているのですが、この貴兄のパッチではこれがバラバラです。
確かこのデフォルトの数値同士の相対的な関係に意味があるのでまとめて同じ倍数をかけなければならないんだと思いますが、興味は2つ・・・

1.なぜバラバラに設定しているのか？その根拠は？
2.同じ倍数のときと具体的にどう結果が変わったか？

この二つはぜひお聞きしたいです。

とりあえずパッと見で気が付いた点をずらっと書きなぐってしまい、読みにくいかもしれませんが私の今までの認識ではこんな感じです。

44M未満で画質を重視しつつ節約型というなら、Chrisの44M以上のセッティングはなかなか作れないと思いますよ？

まずは既にある模範パッチのどこをどうしたいのか？が明確で無いと、各パラメータをいたずらに変えてもかえって改悪してしまう場合が多いですから、不満が出たところを本家なりここなりでまた相談されたらいかがでしょうか？
でもここだと24p以外は今までのところ得意な人は現れていませんので、本家がいいんですけどね・・・^^;

※注記：
StreamparserチャートのBフレームがガタガタになっているのは、手持ちでカメラを上下または左右に動かし続けることによる、与えられるストレス量の変動によるものです。
恐らくセンサーの読む方向のせいで、横方向の動きよりも縦方向の動きの方がより大きなストレスがかかります。
そして、これらの結果はチャート中の表示では42Mとなっていますが、実質はビットレート84Mです。

これはカメラを左右に動かしたときの結果です。

こちらはカメラを上下に動かしたときの結果です。こちらの方がストレスがかかります。

burenoさん
なるほど、いろいろ事情はわかりました^^
今まで日本人で具体的にセッティングを試している人には会ったことがないのでとても新鮮です。私もまだ半分もわかっていない（というか、経験値から仮説を立てて組み立てているだけ）なので、違う人の意見はとても参考になります。
そういう意味では貴兄のような人がもっとここにカキコミしてくれたら助かるなあと思います。

さて・・・そういうことで、お聞きしたいことがまだまだあります(笑)

私は意識的に「Muxer buffer for other modes」を使ったことがないし、3.63でなくなったので必要性を感じたことがなかったのですが、これをいじると何がどうなるんですか？

あと、Q値が「JPEGの」圧縮云々・・・とのことですが、Q値によって変動するのはBと恐らくPフレームの、Iフレームに対する圧縮率じゃないですか？
コレを正式に何て呼ぶのかわからないんですが、事象としてはQ値が上がれば同じIフレームサイズでもBやPのサイズが相対的に大きくなるという意味です。
つまり、BやPはIの変化分しか記録していないはずですが、この変化分の範囲を広げてより画質を向上させる効果があると私は解釈しているのですがどうでしょう？

私が最近AQを使わないのは、同じ条件で作ったパッチでAQとQ値とをいろいろ入れ替えて試したところ、Q値をマニュアルで設定したほうがAQを使ったときよりも暗所でのフレームサイズが大きくなることに気が付いたからです。
ただし、これは条件によっては逆転する可能性があるとも思っています。
AQを使うと高ストレス時に3GOPだとBフレームが期待以上に大きくなってしまい、結局フレームサイズ圧縮が起きてしまいます。これではせっかくの高ビットレートをフレームサイズに活かし切れません。
しかも0～4とものすごく大雑把なのでこれにあわせると他のパラメータをいじるのが大変なので、Q値を使う方が楽ともいえますが。

ところで貴兄のパッチではAQ=0でQ値も0になっていましたが、貴兄の説明とこの設定との整合性がどうも取れません。
Chris自身が何度も説明しているように、Initial quantizerは単に最初の数フレームにしか関係ないわけで、それ以降メインのQuantizer for 1080 modes=0をAuto Quantizer for 1080 modes=0 - All to motionと組み合わせるって・・・なんか変ですよね？
確かAQ=0はノーマルと変わらない状態だったと思うので、これと超極端なQ=0との組み合わせがどういう意味なのかが私にはわかりません。Q=0の是非はともかく、AQ=0は要らないのではないですか？

ビットレートセッティングはそういえば私も過去少し意識的に変えてみたことがありました。
するとわかりやすくエラーが出て、この数字同士の相対的な関係に意味があるんだなと理解して以降全て揃える様にしているのですが、もしかしたらこれも超高ビットレートの世界だけの話なのかもしれません。
それぞれの理想値から逆算したとのことですが、この4つの数字にどうやってたどり着いたのか、その根拠を教えてもらえないですか？
実はこれが一番興味がありますね(笑)

最後に、私も24pをメインで使いながらも先日長時間撮りっぱなしにしないといけないことがあったときには60iを使いました。
Chrisのセッティングの32Mの部分ですが、24pと不可分の部分はあるにせよ、使用上全く問題なかったので自分のセッティングと組み合わせています。

貴兄の「節約型というのは、６０ｉで目指し、２４ｐ３０ｐは無駄なく限界画質、これが共存できると良いなと思ってます。」という意味では正しくChris44Mこそ全ての面で貴兄にとって理想的に思うのですが、どこに問題があるのですか？
例えば私が貼った貴兄のセッティングのStreamparserでは、下のよりストレス度が高いほうが最大フレームサイズが小さくなっていますよね？これはそのパッチによっていろいろな要素で起こる現象ですが、この場合は第一に、ビットレートを食う6GOPなのに必要なビットレートが足りていないのが大きいと思います。
私の経験ではChrisの模範セッティングではこのようなことは起きえないし、一般的に私たちのようなノイズマニア(笑)以外にはとても理想的だと思うのですが、どうでしょう？
私がもしノイズにこだわらなければ、間違いなくChrisの66Mか44Mを使います。
なぜかというと、mpegの仕組みの中での所謂「画質」と「データサイズ」との比率が最高になる＝コストパフォーマンス？が最高！と思うからです。

burenoさん

なるほど・・・周りに60iに興味がある人がほとんどいないので、それは気が付きませんでした^^;
つまり私には必要ない機能だったというわけで・・・でもなぜ廃止されたのでしょうね？

Initial quantizerの役割に関してはChris自身が説明していましたから間違いないです。
ですから、IQはそのままでQだけ変えてもいいのですが、私が試した感触ではIQとQは同じにしておいたほうが高ストレス時の挙動が安定する「気がした」ので、私は同じにしています。

オススメセッティングはここに集めようということになっているので、ここで入手してください。
http://personal-view.com/talks/discussion/953/gh2-patch-vault-most-popular-patches-in-one-place#Item_19

Chrisのパッチについての詳しくは
http://www.personal-view.com/talks/discussion/699/avchd-maximum-image-quality-settings-and-testing/p1
http://personal-view.com/talks/discussion/1170/avchd-maximum-image-quality-series-2/p1

私の経験上でしかわかりませんが、このIフレームサイズはノーマルの倍はありますよね？で、GOP6であればIフレームの数も倍・・・つまりこれだけでノーマルの4倍は情報量が多いわけです（もちろんいろいろ厳密に言えば違うかもしれませんが、わかりやすく言うと）。
そうすると単純計算でも最低22×4＝88Mは必要ということになりますね？
全く動かなければBやPにビットレートを取られませんから辛うじてこのフレームサイズを維持できるかもしれませんが、当然動けば足りなくなります。
この(actual frame rate is half)が表示される設定、つまり表向きのビットレートは低く設定してあるけれど、ビットレートセッティングでそれを倍する設定にしている場合ですが、これはStreamspeedをvideo bitrateが上回ると表示されるものです。
本家で私は散々ダメ出しされてきましたが、こういうセッティングを使いたくなる動機はとてもよくわかります。
見た目低ビットレートなのにフレームサイズが大きくできるからおいしく見えるんですね。
でも実際フレームサイズが大きくなれば実質のビットレートもそれに伴って大きくなりますし、運が悪ければ(笑)本当にフレームレートが半分になります。
私のテストでは本当にフレームレートが半分になったこともありました。
PToolの下の方にあるビットレートセッティングはとても便利なものではありますが、原則あくまでも上で設定したビットレートを超えて使うことはできないんです。
まさか私がこんなことを説明する側に立つとは思ってもいませんでしたが(爆)、いろいろ試した結果、矢張り本家で彼らが言うように、この(actual frame rate is half)が表示されるセッティングはいいものではないと、アウトローセッティングで散々叩かれたこの私でさえ今は考えています。
本来ならば倍以上のビットレートを元々設定しておけばいいだけですからね。ここでもインチキは通用せず、セオリー通りに作らないと機械側が応えてくれなくなるということですね。

節約型を目指すなら、まずはChrisの44Mと66Mを試すべきです。
そして、もし不満点があればそれを元に改造することはアリだと思います。
私も最初はChrisの66Mを3GOPにするところから始めました。
http://personal-view.com/talks/discussion/comment/15553#Comment_15553
早速この下の私の66M6GOPでは(actual frame rate is half)が表示されていますねｗｗｗ

この程度のビットレートで画質を満足しつつLOWGOPを作ることは物理的に不可能だと今は思っています。

本日、Q14～Q16を連れていつもの林にテストに行きました。
上でも挙げた林の中を上を見上げながら前方に歩くというテストで、ISO3200でSS100という使う可能性がある設定でのテストでしたが・・・結果はやはり「フレーム圧縮は起きる」というものでしたorz
パン方向にカメラを動かしたときとチルト方向のときとでストレスのかかり具合が全然違うという話は何度かしていますが、縦方向に動かしたときのストレスは本当にハンパなくて、あっけなく圧縮されてしまいます・・・
こんな撮り方を絶対しない人には全く関係ない話ですが、私は基本移動撮影で、先日も林の中で家族を撮っていたときに録画が止まった（その後改良済み）トラウマもあって、林の中で止まりもしないしフレームサイズも常に1Mのままで間違いなく撮れるものが欲しいんです。
そのためには今までこだわってきた暗所での特性すら犠牲にしてもいい・・・とは思ってませんが、それくらいこの壁は分厚いです。
わからない人には何のことだかちんぷんかんぷんでしょうが(笑)

ただ、これって恐らく例えば木々の生い茂る山を望遠で捉えて上下に動かしたときにも同じことが起きるということですから、移動撮影する人だけに関係する話でもないと思い、真面目に今対策パッチを作っています。
ここでまた問題なのが、最大フレームサイズをどうするか？なんですが、一応今までの流れで最大フレームサイズは「1M死守ｗ」ということでいきます。

Q14

Q15

Q16

bkmcwdさん、お疲れさまです。なにやら連日、もの凄くマニアックなテストを実行されているようで。くれぐれも、林を徘徊中に職質されたりしないよう、お気をつけくださいませ。(^_^;)

で、新しいパッチも続々誕生しているようですが、ボクはれいの、「Fire, walk with me! （←ふ、古い！）」現象の検証のために、まだしばらくは Gop3zilla Q14+ 入れっぱなしのままテストを続行しますです（Fire, walk with me!｜出典：デビッド・リンチです。念のため… (^_^;)）。

またdriftwoodが最新パッチを公開した直後に、絶妙な間でパッチを貼ってきました。
我ながら、いつも通りの空気読めてなさ加減がいい感じだと思います^^
http://personal-view.com/talks/discussion/comment/25329#Comment_25329
名前何にしますかね・・・なんか森の中を素早く走り回る動物が良いなと思ったんですが、英語の駄洒落は難しいです^^;

soruさん
雲上の世界というか、私のイメージでは元々そこにある実現可能な組み合わせを見つけるパズルのように考えています。
ですから、正確に言うとこれらのパッチは私が作ったのではなく、「見つけた」ということですね。
誰もやる人がいないから、たまたま私が見つけているだけの話なので、探す人が増えたらもっと楽に良質なパッチが手に入るのにな～とは今も思っています。
恐らくdriftwoodとかは仕事にも関係あるでしょうが、私はこれでたとえ目立ったとしても何のメリットもないしそれが目的でもないし(笑)

横と縦の問題は前にも書いたような気がしますが、恐らくセンサーの読み出し方向が上から下（例のローリングシャッター）という「向き」があるので、その違いでここまで差が出るのかなと考えています。
ローリングシャッターであれだけ歪むぐらいタイムラグがあるわけですから、上下の動きだと左右に比べて「より追いつくのが大変」なのかな～？みたいな^^
やはり林の中で上を見上げて止まったことがありますか！？
Q16~12は止まりはしないけれどもフレームサイズが圧縮されてしまって、せっかくの高ビットレートがもったいないので圧縮されないパッチが欲しかったのですが、一方で上下に動かしたときだけ圧縮されるとしてもせいぜい1GOP並みのフレームサイズになるだけだし、他のシーンでよりフレームサイズが大きくなることをメリットと感じてQ16~12を使うのもアリだとは思っています。止まるのは論外ですが・・・

ところで今raitankさんとの間で話題になっているのが、「ISO12800で突然録画が止まる現象」なんですが、私は今までもあれこれGH2をイジメ倒しても止まらないんですよね。で、raitankさんの止まったときのデータを拝見しましたが、全然たいしてストレスかかってるようには見えないものなんです。
これは謎ですが、もしどなたかISO12800で録画が突然止まったら是非そのデータを見せていただきたいですね。
私はコレはパッチの問題ではなく、カメラ側の何かの安全措置ではないかと想像しているのですが、止まったデータと似たような状況を再現しても止まらないんです。唯一違うのは例のHP12mm/f1.6のレンズだけなんですが・・・

名前の件ですが、KAMAITACHIとはまたベタですね(笑)
DRAGOP3NFLYとかダサいですかね？　謙虚さもアピールしつつ・・・
できれば飛ぶものがいいので、KINGOP3FISHERでもいいですが、ちょっと長いかな・・・^^;

今話題の"Driftwood Tune"を加えた最新テストパッチを貼ってきました^^
http://personal-view.com/talks/discussion/comment/25897#Comment_25897
このサンプルでは"Driftwood Tune"はわからないかもしれませんが、ノイズがバリバリ出るシチュエーションなら彼の仕事の結果を堪能できると思います。
LongGOPだとどうなのかはわかりませんが、3GOPだとパッと見はイントラとそんなに変わらない雰囲気に見えると思うのですがどうでしょう？

soruさん
私はほとんど60pは使わないので詳しくないですが、多分driftwoodのものならかなり満足度高いんでしょうね。
ノーマルGOPだと60コマのほとんどがPフレームかBフレームで、Streamparser見ると正直萎えますけど、イントラとかで60pなら正直1080pのLongGOPなんかより綺麗な可能性もありますよね。
あと、バッテリーの話、私も彼ほどではないにせよもうバージョンアップ回数は軽く千回は超してますが、しっかり充電されている状態でバージョンアップしている限りは問題は起きそうもありません。今まで私は一回も彼のようなトラブルは起きていないので。
もちろん私もバッテリーは2個回してテストしてますけどね^^
別にバッテリー切れになるわけではないのに何で故障するのか謎ですね～

追記：
上のサンプルのうち、換算70mmで撮ったボケボケのやつですが、このボケの中のツブツブの細かさが今までと全然違うのでビビリました^^；
もしかしたらこの"Driftwood Tune"が今までで一番すごいかも・・・