H3 Trim (alpha)
Throw away the hidden prefix without throwing away your timeline
- images
- audio
- images
- audio
- global_end
- global_span
- report
- prefix_images
- prefix_audio
H3 Trim is the cleanup node for chained MiniMax-H3 segments, and it exists because every continuation ships with hidden baggage. When you extend a segment, the model renders a hidden handle prefix of context frames at the start - frames that exist only so the generation knows where it is. And because H3 works on a 17k+5 grid, the recovered output carries surplus padding past the requested length. You don't want either in the final clip. Trim drops both, cuts the audio sample-exact to match, and tells you where the kept material landed on the global timeline - which is the part people underestimate.
What it does
Required inputs are images (the recovered segment) and plan (the segment plan - the same plan object the other assembly nodes read, which encodes where the handle and grid surplus are). global_start is the one number you must actually think about: the frames already on the assembled timeline before this segment's new material starts. It defaults to 0, which is right for the first segment and wrong for every one after it.
The outputs are where the value is:
images/audio- the trimmed segment and its sample-exact audio, ready to concatenate.global_endandglobal_span- where the kept material sits on the one global clock. The README's framing is worth repeating: "All trims map to ONE global clock; the final requested duration is one trim after assembly." Every segment trims against the same ruler, so the chain can't drift frame-by-frame.report- what was dropped and where things landed.prefix_images/prefix_audio- the hidden handle, kept as outputs rather than destroyed. That's the calibration gift: the prefix is what H3 Seam Normalize'sgenerated_prefixinput wants, so you can measure the drift the handle introduced before you discard it.
Why the prefix matters even though it's invisible
The hidden handle is the same frames the accepted world already has - the continuation just rendered them differently. That's a free A/B test of your pipeline's stability, and it's the exact calibration data the seam-correction nodes eat. Trim is the only node that surfaces it at all. If you're chaining segments and skipping Seam Normalize, you're literally throwing away the measurement that tells you whether your seams are drifting.
Install
Ships with matlowai/ComfyUI-MAINodes:
cd ComfyUI/custom_nodes
git clone https://github.com/matlowai/ComfyUI-MAINodes
Restart, under MAINodes/alpha. No extra Python deps; you need MiniMax-H3 weights and ComfyUI's H3 support (mind the licence's US/EU/UK/Korea carve-out).
The trap to name: global_start is frames already on the timeline, not the previous segment's end index. Get it wrong and every subsequent global_span lies to you. Wire it from the previous Trim's global_end and the bookkeeping becomes someone else's problem.
Inputs (4)
| Name | Type | Default | Description |
|---|---|---|---|
| images | IMAGE | — | |
| plan | STRING | — | |
| global_start | INT | 00–10000000 | frames already on the assembled timeline before this segment's new material |
| audioopt | AUDIO | — |
Outputs (7)
| Name | Type | Description |
|---|---|---|
| images | IMAGE | — |
| audio | AUDIO | — |
| global_end | INT | — |
| global_span | STRING | — |
| report | STRING | — |
| prefix_images | IMAGE | — |
| prefix_audio | AUDIO | — |