H3 Locked Audio Duration Align
Line up locked audio with the decoded video
- images
- audio
- audio
When you lock audio into an H3 generation (easy minimaxH3AudioLock), the delivered video is decoded at a frame count and the audio is a separate waveform. Those two lengths don't always agree to the sample - H3's audio latent runs at 40fps and its VAE rounds temporal lengths, so a 5-second segment can come back as video that's a few milliseconds shorter than the locked audio, or longer. easy h3LockedAudioDurationAlign is the internal node that eats those few milliseconds so the exported clip stays in sync. It's a dev-only correction node, part of the project pipeline's lock-audio path, and you will almost never wire it by hand.
What it does
It's a sub-frame duration fixer. Given the decoded video (images), the locked audio, and the timeline fps:
- it counts the video frames and computes what the audio should be:
target_samples = round(frame_count / fps × sample_rate); - it compares that to the audio's actual sample count;
- if they're within a small allowed window (bounded by one audio-latent frame at the VAE rate - around 25ms at 40fps), it linearly resamples the waveform (
F.interpolate) up or down by that tiny amount so the audio ends exactly where the video does; - if the mismatch is bigger than the safety window, it refuses and raises an error instead of stretching audio into audible drift.
Output is just the corrected audio. The video isn't touched - the node's job is to fit the audio to it, not the other way around.
The safety limit is the interesting design choice. A few milliseconds of resampling is inaudible; twenty is a warble. So the node only corrects within the sub-frame window and bails beyond it, leaving you a clear error ("Locked H3 audio/video duration mismatch is too large to align safely: +48.200 ms (limit 25.000 ms)") rather than a subtly corrupted export.
Why you'd meet it
It's an internal of the MultiTrack Project lock-audio path. When you lock audio in the editor and the project runs, the pipeline decodes the segment and passes it through this node so the locked audio matches the delivered video exactly. The practical lesson for your own graphs: if you lock audio outside the pipeline and skip this step, you're betting that the audio VAE's temporal rounding and your video decode come out exactly equal - and they often don't, by a few milliseconds that will eventually show up as lip-sync drift or a skipped beat.
Installation
Part of ComfyUI-Easy-Media:
# FFmpeg first (the README's hard requirement)
cd ComfyUI/custom_nodes
git clone https://github.com/yolain/ComfyUI-Easy-Media
Restart ComfyUI or install via Manager (search "ComfyUI-Easy-Media"). No extra dependencies - waveform interpolation only.
Troubleshooting
- "Locked H3 audio/video duration mismatch is too large to align safely" - the drift is bigger than a sub-frame correction should ever be. Something structural is wrong (wrong frame rate, or audio that's a full latent frame short because it was cropped/looped incorrectly upstream). Fix the source rather than stretching the audio.
- Audio and video still drift after this node - the node only handles sub-frame alignment; if you're seeing seconds of drift, the problem is upstream (frame-rate mismatch between encode and decode, or a wrong
fpsinput). - "images must contain at least one decoded frame" - you fed it an empty tensor; it needs real decoded frames to count against.
It's the node that turns "sounds about right" into "actually frame-accurate," and its refusal to stretch audio beyond a safe window is exactly the kind of discipline that keeps a long project from accumulating sync rot across segments.
Inputs (3)
| Name | Type | Default | Description |
|---|---|---|---|
| images | IMAGE | — | |
| audio | AUDIO | — | |
| fps | FLOAT | 24.0001–240 | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| audio | AUDIO | — |