arkennemasis Avatar Frames (clip length from the voice)

ArkAvatarFrames solves the dumbest-looking problem in the avatar pipeline and one that will cost you a wasted render if you skip it: the video model needs a frame count, but the narration doesn't exist in frame counts - it exists in seconds of audio. This node measures the rendered voice-over and returns the number of frames that covers it, snapped to Wan's 4k+1 frame grid. Wire it between your TTS node and the video model, and the clip is always at least as long as the voice. Skip it and you get a presenter whose mouth stops moving halfway through - or, if you guess long, a clip that costs you render time for nothing.

How it works

It takes the actual AUDIO waveform, not a word count. The node reads the audio's sample rate, divides the sample count by it, and gets the real spoken length in seconds. That's the crucial bit: it measures what was rendered, not what was estimated from the script, so an ad-libbing model or a slower read doesn't leave you holding a too-short clip.

From there it's arithmetic with judgment:

• Add tail_seconds (default 0.4) - the beat of picture held after the last word. The tooltip nails it: cutting on the syllable reads as a mistake; a beat reads as editing.
• Cap at max_seconds (default 45). Render time grows faster than linearly with length, so this is the difference between a long render and an overnight one. If the voice exceeds the cap, the picture is truncated - and the node's report says so loudly.
• Snap to Wan's 4k+1 frame grid (fps default 25), so the frame count is one the video model will actually produce.

It also refuses to proceed on garbage. A zero-length narration raises immediately, because spending a render on silence is exactly the failure the whole node exists to prevent.

Inputs and outputs

The one you must get right is fps. The tooltip is blunt: it must match the audio-embedding node and the muxer, or the lips drift from the voice. This is a classic "everything worked, nothing synced" failure mode, and it's always a frame-rate mismatch somewhere in the chain.

Outputs are num_frames (the INT you wire into the video model), seconds, a passthrough fps, and report - a human-readable line you can eyeball, e.g. "voice 12.30s (+0.40s tail) → 319 frames = 12.76s at 25 fps". When the cap kicks in the report appends a note telling you to shorten the script or raise max_seconds.

Installing

This one's part of the pack, so the standard dance applies:

cd ComfyUI/custom_nodes
git clone https://github.com/Hishamahmer/comfyui-arkennemasis
pip install replicate httpx

Restart ComfyUI. ComfyUI Manager also finds it by the pack title arkennemasis. No models or keys needed for this node alone.

Troubleshooting

• Lips don't match the voice: check fps is identical on this node, the audio-embedding node, and the muxer. This is the whole job of that setting.
• Clip ends while the voice keeps talking: you hit max_seconds and the report's CAPPED note is showing. Shorten the script or deliberately raise the ceiling - just know the render cost goes up faster than the length.
• "The narration is zero-length": the TTS produced no audio. Fix it upstream; this node is correctly refusing to burn a render on nothing.