MiniMax H3 が整数秒で返す唯一の設定：192 フレーム

MiniMax H3 に 8 秒を頼むと、8.000 秒が返ってきます。7 秒を頼むと 7.292 秒。12 秒を頼むと 12.250 秒。モデルの丸め方が下手なのではありません。そもそも秒で動いていないのです。

H3 は秒ではなく、フレームのブロックで生成する

H3 の生成は必ず整数個の潜在ブロックで、フレーム数は常にここに着地します。

frames = 17n + 5

24 fps では、これで尺が決まります。画面にある尺の指定は要求であって、実際に生成されるのは格子のほうです。あなたの指定した値は、いちばん近い正規のブロックへ吸い寄せられます。ComfyUI はこの吸着が目に見えます。尺を動かすと、フレーム数の欄が飛ぶのが分かります。

API が受け付ける 4〜15 秒の範囲なら、格子は全部書き出せる大きさです。

太字が 1 行だけあります。太字にする必要があるのは、その 1 行だけです。

なぜ整数秒に着地するのが 1 つだけなのか

フレーム数が整数秒に割り切れるのは、それが 24 の倍数のときです。つまり求めたいのは、

17n + 5 ≡ 0  (mod 24)
17n     ≡ 19 (mod 24)

17 はたまたま mod 24 で自分自身が逆元になっています。17 × 17 = 289 = 12 × 24 + 1 です。両辺に 17 を掛けると、

n ≡ 17 × 19 ≡ 323 ≡ 11 (mod 24)

解は n = 11, 35, 59, …。11 の次は 35 で、これは 600 フレーム、つまり 25 秒。15 秒の天井をはるかに超えています。

H3 が実際に生成してくれる範囲の中では、n = 11 が唯一の答えです。 192 フレーム。8.000 秒。ほかに頼めるものは、すべて端数の秒です。

これが効いてくる場面と、効いてこない場面

そのままフィードに流す 1 本なら、まったく関係ありません。ループを見ている人に 8.708 秒と 9 秒の区別はつきません。

効いてくるのは、その 1 本が単独でなくなった瞬間からです。

• 音に合わせて切るとき。 120 bpm の 1 小節は 2.000 秒です。10 秒を頼むと 7.292 か 8.708 が返り、どちらも格子からずれます。そしてそのずれは、並べるほど積み上がります。
• クリップをつなぐとき。 5.167 秒のショット 6 本は 31.002 秒であって、31 秒ではありません。小さな差ですが、自分で置いたマーカーと最後まで合わないタイムラインになります。
• 枠が決まっているもの。 6 秒のプレロールは、H3 に出せる尺ではありません。いちばん近いのは 6.583 秒で、これは尺をはみ出します。

尺の制約が少しでもある案件なら、8.000 秒のブロックで組み立てて、編集で詰めてください。モデルがきれいな形で返してくれる長さは、これだけです。

実務での結論

持ち帰る価値があるのは 3 つです。

1. 選べるなら 8 秒を頼む。 これはただで手に入る精度です。出力 1 秒あたりの費用はどの値でも同じで、そのうち整数で届くのがこれだけです。
2. 秒の欄ではなく、フレーム数を読む。 モデルが約束したのはフレームのほうです。秒は、そのあとであなたが割り算した結果です。
3. プロンプトで格子と戦わない。 プロンプトに「ちょうど 6 秒」と書いても、ブロックの大きさは変わりません。ショットの中の時間指定——たとえば 00:04.500 の一拍——は効きますが、全体の尺は交渉できません。

上の計算は、自分で一度やってみる価値があります。1 分で終わりますし、17n + 5 の規則と 24 fps 以外に出典は要りません。そして、放っておくと「モデルの挙動が読めない」に見えてしまう疑問が、それで片付きます。