Prompt Studio Trim H3 Context
Cutting the repeated head out of a continued MiniMax H3 clip
- images
- audio
- images
- audio
- assembly_images
- assembly_audio
When MiniMax H3 continues a video, the new render literally replays the last 39 frames of the parent as protected context before branching into new content. That's exactly what you want inside the sampler - it's how the model knows where it is - but it's a problem once you decode: your "new" clip starts with 39 frames you've already seen. Prompt Studio Trim H3 Context (PSV_H3TrimContext) is the post-render cleanup node that fixes that. It takes the decoded extension frames and audio, cuts off the repeated head, and hands you two versions of the result.
How it works
It sits between the VAEDecode / VAEDecodeAudio outputs and the CreateVideo node in the extension graph. Given the decoded images and audio, plus trim_frames (default 39) and fps (default 24), it:
- drops the first
trim_framesframes and the matching amount of audio at the given fps, sample-rate-aligned so nothing drifts; - pads or truncates the trimmed audio to exactly match the shortened clip's duration, so the playable result stays in sync.
The four outputs are really two pairs. images and audio are the trimmed, separately playable extension - this is what feeds the main CreateVideo and becomes the clip you watch. assembly_images and assembly_audio keep the full frame count and a full-length audio track aligned to the original render duration - that's the "overlap" version, saved as a separate assembly segment so it can be blended against the parent's tail with its audio release intact.
Why two versions?
This is the pack's Soft AV audio design in action: the model's final eight audio steps use a half-cosine "release" into the future, and that release only lands in the final soundtrack if the extension segment owns the overlapping audio. So you get one trim for previewing and sharing, and one overlap-bearing assembly used to build the cumulative output where the parent's tail meets the child's head seamlessly. Both are produced from the same decode - you don't sample twice.
Inputs and what wires where
images/audio- decoded video frames and audio, straight fromVAEDecodeandVAEDecodeAudio.trim_frames- how many repeated context frames to cut; defaults to 39, and it must be smaller than the total frame count (it errors otherwise). In the automatic flow this is fed directly from the Motion Context node'strim_framesoutput, so it always matches the context length.fps- defaults to 24 and should match the fps on theCreateVideonode; if it doesn't, the audio cut lands in the wrong place.
Output images/audio (indices 0–1) go to the main CreateVideo; assembly_images/assembly_audio (indices 2–3) go to a second CreateVideo that the pack titles "Soft AV Assembly" and saves under a _soft_av_overlap filename prefix.
The honest framing
Like its two siblings (Save H3 Context and Motion Context), you'll almost never wire this by hand - Video Studio's Build full extension flow injects it automatically whenever you continue a render, right after it rewires the guider and sampler through the Motion Context node. If you're building the continuation graph manually, the chain is: decoded video/audio in, trimmed pair to your playable save, assembly pair to the overlap save. The failure modes are mundane - trim_frames at or past the clip length, an fps mismatch, or audio shorter than expected - and each raises a clear error instead of producing a subtly broken file. It's the least glamorous node in the trio, and the one that keeps your continued clips from looking like a badly edited loop.
Inputs (4)
| Name | Type | Default | Description |
|---|---|---|---|
| images | IMAGE | — | |
| audio | AUDIO | — | |
| trim_frames | INT | 390–56 | — |
| fps | FLOAT | 24.001–120 | — |
Outputs (4)
| Name | Type | Description |
|---|---|---|
| images | IMAGE | — |
| audio | AUDIO | — |
| assembly_images | IMAGE | — |
| assembly_audio | AUDIO | — |