Audio Duration (mtb)

Tiny node, single job: hand it an audio clip and it tells you how long the clip is. That's the whole thing. It's the kind of utility you don't think about until you're building an audio-driven workflow and suddenly need a number to key everything else off of.

Why would you want that? Because more and more ComfyUI work is timed to audio - lip-sync, talking-head video, music-driven animation, subtitle generation. Once you're generating video that has to match a piece of audio, the first question is always "how long is this?" and the second is "so how many frames do I render?" This node answers the first. It gives you a hard number you can compute against instead of eyeballing a waveform.

How it works

There's no model and no processing here - it reads the metadata of the ComfyUI AUDIO object (its sample data and sample rate) and returns the length. Instant, free, runs on CPU.

The one input, the one output

• audio - any ComfyUI AUDIO signal: a loaded file, TTS output, a track pulled from a video, whatever's upstream.

The single output is duration_ms, an INT. Note the units: milliseconds, not seconds. A three-second clip reads as 3000, not 3. This trips people up constantly, so bake the conversion into whatever you do next - divide by 1000 for seconds.

That conversion is exactly where this node earns its keep. Say you're rendering at 24fps and you want your video to run the length of the audio: frames = duration_ms / 1000 * 24. Feed duration_ms into MTB's own Math Expression node (or convert and route it) and you've got your frame count derived automatically, so changing the audio changes the render length with no manual retyping. That's the pattern - this node is a source of truth that the rest of the graph can do arithmetic on.

How to install it

ComfyUI Manager: search MTB Nodes (comfy_mtb), install, restart. Or manually: cd ComfyUI/custom_nodes && git clone https://github.com/melMass/comfy_mtb and restart. This one is pure Python with nothing to download and no exotic dependency, so if the rest of MTB loaded, this node loaded.

Common issues

There's very little to go wrong. The only real gotcha is the units - if your downstream math is off by a factor of 1000, this is why. Divide duration_ms by 1000 before you treat it as seconds.

The other thing to sanity-check is that you're actually feeding it a proper AUDIO object. If the upstream node produced empty or malformed audio, the duration you get back will be nonsense (zero, usually), which is a useful early warning that your audio load or extraction step is the real problem, not this node. In practice this is a stable little building block - you wire it in once and forget it exists until you need a number.