H3 Motion Context Seam Probe

Chained H3 clips sound seamless until they don't, and ears lie - the pack's own development history is full of joins that sounded fine while a cross-correlation said the new clip was a cover band rather than a continuation. This node is the measuring stick: it checks a chain join inside the graph and tells you, in numbers, whether clip B genuinely continues clip A's audio and whether the level jumps at the cut. It exists because the pack's command-line probe scripts have to infer where the seam is from file ends, and that inference is off by the audio grid's overhang - which is exactly where the old "phantom ~8 ms lag" reports came from. In-graph, the seam position is known exactly, so there's nothing to guess.

Wiring

It's designed to drop into an existing chain without changing anything. Wire it inline between the audio VAE decode and the Trim node:

audio VAE decode -> H3 Motion Context Seam Probe -> H3 Motion Context Trim

The audio output is the input, unchanged, so the render is bit-for-bit what it would have been without the probe. The report output goes to a Preview Text node.

Inputs, and the ones you can't get wrong:

• clip_b_untrimmed - this clip's audio straight off the VAE decode, before the trim. It still carries the pinned head, which is what gets compared.
• trim_frames - wire this from the Motion Context node's trim_frames output, the same value the Trim node gets. It defines the pinned span being measured.
• clip_a_latent + audio_vae - the previous clip's AV latent (the same one wired into context_latent) and the H3 audio VAE. Without both, the node describes clip B only and measures nothing - it says so in the report.
• fps - must match what you feed Create Video.
• window_ms and search_ms - the correlation analysis window (50 ms) and the maximum lag searched either side (40 ms). Defaults are sane; you'll rarely touch them.

What the report tells you

Four numbers per join. lag_ms is how far B's reconstruction of the pinned span runs behind A's original - positive means B is late. corr is normalised cross-correlation over the pinned span: 1.0 is identical shape, ~0 is unrelated, and a low value means the model is imitating rather than continuing - the exact failure the pack's audio work was built to kill. Then two level steps across the cut, normalised to 0–1: broadband RMS, and floor, which tracks the quiet bed under the content and is the one that catches a clip inventing its own silence. The summary labels the results against the same thresholds the pack's CLI scripts document - you get a verdict, not just raw numbers.

One limitation before you trust a lag figure: cross-correlation can't tell a true alignment from one a whole cycle away, so on strongly periodic content - beat-driven music, exactly what you're likely to be chaining - a large lag reads as its nearest alias, confidently and at high correlation. The tracker follows continuity between windows so drift can't cycle-hop mid-span, and a small lag is reliable. A large one means "at least this much, possibly plus a whole number of cycles." Read it accordingly.

Install

Same as the rest of the NikoDemon80/ComfyUI-H3-Motion-Context pack. ComfyUI Manager, search "H3 Motion Context", or:

cd ComfyUI/custom_nodes
git clone https://github.com/NikoDemon80/ComfyUI-H3-Motion-Context

then restart. No models, no extra dependencies beyond numpy, which you have. It's an output node, so it runs at the end of the graph - which is fine, since it sits inline at the audio decode and its passthrough doesn't touch the render. If you'd rather measure outside ComfyUI, the pack ships the same logic as CLI scripts (tests/seam_probe.py, tests/level_step.py) that work on rendered files with no GPU at all; the node is the version that can't get the seam position wrong.