CoachBateTrimShotOutput

The last step nobody remembers until the audio drifts

Video models generate in blocks, not in whatever length you asked for. H3's grid is 17k+5 pixel frames, so a 6-second shot at 24fps (144 frames) comes back as 158, or whatever the next grid multiple is, and if the shot continues from a previous one there's a context prefix in front of that too. Add it up and your "8 second shot" is 8.9 seconds with the first two thirds of a second being a re-run of the shot that came before.

CoachBateTrimShotOutput cuts that back off. Inputs: images, audio, shot_payload, trim_frames (the integer from CoachBatePrepareShotContinuity), no_master_audio. Outputs: images and audio - a matched pair, which is the point. It computes the intended length as ceil(edit_duration_seconds × 24) (falling back to duration_seconds) and slices both streams by exactly that, from the same offset.

Trim the picture and not the audio, and your dialogue is a third of a second out of sync for the entire shot. That's the bug this exists to prevent, and because H3 generates video and audio in one pass, it's an easy bug to make - the two streams have different sample rates and different ideas about where the frame boundary is.

How the audio side decides

no_master_audio (default true) means "the recorded source audio was my master", so the audio is sliced from trim_frames forward, in samples: round(trim_frames / 24 × sample_rate) to the same plus round(count / 24 × sample_rate). Picture offset and audio offset stay the same distance apart, which is what keeps lipsync intact.

With it off - the song-master case - the audio is sliced from sample 0 instead, because the master audio was never prefixed with continuation audio and only the picture has padding to remove. Get this setting wrong in either direction and you'll hear it immediately, which is at least a fast feedback loop. This node is also what discards the invented conditioning tail that CoachBatePrepareShotContinuity padded onto the audio to satisfy the model grid - the README calls that out explicitly: the recorded master is untouched, the temporary tail is discarded here.

If there isn't enough material to trim, it says so rather than truncating quietly: "Generated video is too short for context trim and complete editorial audio", or "Final audio is too short; refusing a silent/truncated replacement". Both mean the same thing - the shot didn't render the length the shotlist asked for. Refusing beats shipping a shot with a silent half-second on the end.

Wire it here

Put it between the decode and Video Combine: images and audio both come out of it, and both go into the save. trim_frames must come from PrepareShotContinuity rather than being typed as 0 - it's 0 in the non-continuation case and the grid padding otherwise, and it's the only node that knows which.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/CoachBate/ComfyUI-CoachBate.git

Or ComfyUI Manager → search "CoachBate" → restart. Category CoachBate. Nothing to install beyond the pack for this one; the shot pipeline around it wants VideoHelperSuite, and continuity wants the H3 nodes plus PyAV (which ComfyUI ships).

Where people get burned

• "Generated video is too short for context trim and complete editorial audio." - the render came back shorter than the grid maths expected, usually because the frame count in the workflow isn't derived from duration_seconds. Fix the length where it's computed.
• Audio out of sync after a continuation. no_master_audio on the wrong setting for the mode you're rendering in.
• trim_frames typed in by hand. It's an output of the continuity node, not a setting.
• The shot is 0.4s short. Somebody trimmed twice - this node and a downstream trim both running on the same stream.