H3 Repair Splice

H3 Repair Window cuts a piece out of a finished clip and lets you sample it again. This is the half that puts it back. It's a two-input, two-output node that does one unglamorous thing extremely carefully: it replaces exactly the latent rows and audio steps the window redrew, and carries every other byte of the clip through untouched.

How it works

The clip from H3 Extend Window isn't a flat batch of frames - it's latent rows on the model's 5k+2 token grid, plus audio steps at 40 a second, plus the records the extend loop accumulated: which scene ends where, which frames each cut trimmed, and where each segment came from. A naive inpainting pass that re-decodes and re-encodes the whole clip destroys all of that, and the sound drifts by a few frames while the scene boundaries quietly move.

Splice doesn't re-encode anything. It knows where the window sat, so it writes the sampler's output into the rows and steps that window covered and leaves everything else as it was found - including the segments and scene cuts. Does your repair need to cover sound as well? The window's sound_strength decided that; splice just honours it.

The two inputs, and what comes out

Two inputs, both required and both obvious: latent, the same clip you wired into H3 Repair Window, and sampled, whatever the sampler returned for that window's latent.

Two outputs. latent is the repaired clip - decode it like any finished clip, or feed it into another Repair Window to fix the next thing. report names what changed, in the format the pack uses everywhere:

picture frames 68-118 (2.83-4.96 s, tokens 20-34) at 1.00, sound kept

That line is worth reading rather than dismissing. It tells you the frame range, the seconds, the latent tokens, the strength that was applied, and whether the sound came along. If your "repair" seems to have done nothing, the report will usually show that the span snapped somewhere you didn't expect.

Where it goes wrong

You spliced into a different clip. latent must be the same clip the window was cut from. It's easy to wire the sampler's output instead of the original clip and get a result that decodes to a mess, because splice writes rows at positions that no longer mean the same thing.

Repairing repeatedly and the picture drifts. Each pass is a generation; a chain of five repairs on the same seconds will wander. Repair once, well, and if it's still wrong, go back to the original clip from disk with H3 Load Clip rather than repairing the repaired.

The sound doesn't change even at a high sound_strength. Check what the window actually asked for - splice implements the window's decision. If sound_strength was 0.0 (the default) the picture was redrawn under the original audio on purpose, which is usually the better result anyway.

It looks right in the report and wrong on screen. Decode the latent output, not the one that went into the window. Same trap as every inpainting workflow since 2023.

Installing it

WAS Node Suite v3, via ComfyUI Manager (search WAS Node Suite v3) or by hand:

cd ComfyUI/custom_nodes
git clone https://github.com/WASasquatch/was-node-suite-comfyui.git

ComfyUI 0.14.0+ and Python 3.10+. Nothing is installed, nothing is downloaded, and features.network is off by default, so a missing model file is an error with a filename in it rather than a surprise download.