FastH3 V2 · Verify Accepted Two-Segment Source (T8 EXP)

What it is

The cheapest node in this whole pack, and one of the more useful ones: give it a chain_id and it re-reads the chain from disk and tells you whether the thing you're about to compose is actually composed of what you think.

Two accepted segments - the 124-frame first and the 68-frame continuation - their retained source-bound candidates, the media and context hashes, and the current job SHA. It reports. It doesn't fix, doesn't compose, and by its own description isn't a quality review. It's the pre-flight check for the last step.

Why a separate node for this

Because the failure it catches is expensive and invisible. You accepted segment one. You accepted segment two three days later after a detour through a different experiment. Somewhere in there a candidate file got moved, or a sidecar didn't come along, or you're about to compose a chain where one segment's media no longer matches its recorded hash. Nothing about that is obvious from filenames. The composer would happily blend 192 frames out of whatever it found.

The pack is very consistent about this pattern, and it's arguably the most useful thing about it: every irreversible step gets a read-only verification step in front of it. There's no cleverness here - it's one input, two outputs, and a report. That's the point. Verification you actually run beats verification that's theoretically available.

How it works

It walks the accepted-chain records for the given ID. For each retained segment it re-checks that the candidate is still source-bound (the sidecar relationships still hold), that the media hashes on disk match what was recorded at acceptance, and that the context hashes line up. Then it confirms the current job SHA ties the two together as one chain.

What it explicitly does not do is judge the video. If the seam is ugly, this node says the chain is fine, because structurally it is. Its job is provenance, not taste. That division is worth internalising across the pack: attestation nodes answer "is this what it claims to be," and your eyes answer everything else.

Ports

One input: chain_id (string, blank by default). Two outputs: chain_id (passed through, so it can feed the composer's own string input) and report_json.

The pass-through is a small nicety that saves a wire - you can chain the output straight into whatever consumes the chain ID downstream rather than fanning one string into two places.

Where it fits

Segment accepted → chain verify → compose. The pack's own numbered example workflows put it right before the composer: FastH3_V2_Split_06_Compose_Accepted_EXP.json is the last graph in the six-graph set, and it only stitches when both segments have been accepted.

If you're building the graph yourself rather than importing the examples, the ordering temptation is to skip this because "I already accepted them, obviously it's fine." The cases where it isn't fine are precisely the cases you didn't notice.

Install

ComfyUI Manager → MiniMax H3 Audio T8, or:

cd ComfyUI/custom_nodes
git clone https://github.com/T8mars/comfyui-minimax-h3-audio-T8.git minimax-h3-audio-T8

Fully quit ComfyUI, restart, refresh. Nothing to pip-install: the pack's requirements.txt is deliberately empty so installation can't replace ComfyUI's Torch/CUDA stack, and optional EXP features check their own dependencies only when used. You need a recent ComfyUI with native H3 support, the H3 weights in models/diffusion_models, Qwen in models/text_encoders, and both VAEs in models/vae.

Where it goes wrong

The common failure is a blank chain_id, or a chain ID that doesn't match what the accepted candidates recorded. If you copied the ID out of the review node's output rather than retyping it, you're fine; if you retyped it from memory, you're probably not, and the report will say the chain has no verified segments.

The second one: running this against a chain where only one segment was accepted. That's not a bug, it's a legitimate state - you simply can't compose yet, and the report tells you which segment is missing rather than throwing a vague error at the composer.

And if the report flags a media hash mismatch, do not go looking for a way around it. Something on disk changed since acceptance - a moved file, a re-encode, a different candidate - and the correct move is to re-review and re-accept, which regenerates the binding honestly. Composition is the one step in this pipeline where you really don't want to be arguing with the checks.