Anymatix Frame Count
Turn 'however long the clip is' into the exact frame count LTX will accept — 8n+1, no rejections
- frames
- duration
Video models are finicky about their math. LTX, for instance, doesn't accept just any number of frames - it wants a count of the form 8×n+1, so 97, 121, 161, and so on. Feed it 120 frames and it won't round for you; it refuses. That's the problem AnymatixFrameCount exists to solve: you give it a desired duration and it returns the nearest valid frame count, snapped to whatever arithmetic your model demands, so your sampling starts instead of dying at validation.
It's the sibling of AnymatixAudioDuration and pairs with it beautifully. Audio duration gives you the file's real length; this node turns that length into the exact number of frames your model will accept. And because the snap can move the count slightly off what you asked for, the node also reports the duration that count actually represents - feed that back into your audio trim and the audio and video end up the same length, not almost the same.
The inputs that matter
- duration (FLOAT, default 5s) - how long you want the clip. Wire in
AnymatixAudioDuration's output and it stops being a guess. - frame_rate (FLOAT, default 24) - how many frames per second you're running.
- multiple_of (INT, default 8) and offset (INT, default 1) - together they define the allowed family: the model accepts
multiple_of * n + offset. The default 8 and 1 is the LTX setting; the tooltip spells it out. Other models have other rules - some want 16n+1, some just powers of two. - minimum (default 9) and maximum (default 257) - the clamp range. Your model has a shortest and longest clip it'll generate; these keep the answer inside the envelope.
Outputs: frames (INT) - the count to hand your empty-latent node - and duration (FLOAT), the true length at your frame rate after the snap.
How it works
The arithmetic is simple in principle: frames = duration × frame_rate, then round to the nearest value of the form multiple_of × n + offset. The useful detail is in the clamping - the node clamps into the valid family, not past it. If your minimum sits at 9 and the math lands on 8, it rounds up to the nearest valid count at or inside each end rather than handing back something the model would reject. It's a "snap into the grid" node, and that's a genuine convenience.
Install
The usual pack routine:
cd ComfyUI/custom_nodes
git clone https://github.com/Anymatix/anymatix-comfy-nodes
then restart, or ComfyUI Manager → search "anymatix-comfy-nodes". No models involved.
Issues to expect
The main trap is copying the defaults onto a model that doesn't share LTX's math. If your model wants a different family, you must change multiple_of/offset - the defaults are LTX-shaped and nothing else. And remember the output duration is not your input duration: if you feed that number onward to an audio trim, you're lining everything up exactly, which is the intent - but it will surprise you the first time you see 10.04 instead of 10.0.
Inputs (6)
| Name | Type | Default | Description |
|---|---|---|---|
| duration | FLOAT | 5.000–3600 | Length in seconds. |
| frame_rate | FLOAT | 24.000.01–1000 | — |
| multiple_of | INT | 81–1024 | Frame counts must be multiple_of * n + offset. LTX wants 8n+1. |
| offset | INT | 10–1024 | — |
| minimum | INT | 91–100000 | — |
| maximum | INT | 2571–100000 | — |
Outputs (2)
| Name | Type | Description |
|---|---|---|
| frames | INT | — |
| duration | FLOAT | — |