(deforum) Beat Detection v2
The librosa-powered upgrade when the simple detector wobbles
- audio
- beat_times
The pack has two beat detectors, and this is the serious one. (deforum) Beat Detection v2 swaps the simple envelope-threshold approach for librosa's beat_track, the workhorse onset-and-tempo tracker from audio research. Where the v1 node just flags energy peaks, this one estimates a global tempo and then finds the beats that fit that pulse - which makes it dramatically more robust on real music. It's the node you reach for when the basic detector gives you a scatter of false beats and you actually want your animation locked to the groove.
How it works
The node takes the AUDIO input (first channel if stereo), runs it through librosa.beat.beat_track at the sample_rate you specify, then converts the detected frame indices to wall-clock times with librosa.frames_to_time. What comes out is an AMPLITUDE series of beat timestamps in seconds, just like the v1 node - but the process is fundamentally different: beat_track computes an onset strength envelope and a dynamic tempogram, estimates tempo, and places beats on a regular grid that matches that tempo. So instead of "everything loud enough," you get "the musical pulse." That's why it handles vocals, off-beat snare hits, and messy mixes so much better - the tempo model filters out transients that don't belong to the beat.
The inputs that matter
audio- requiredAUDIOinput. First channel is used for stereo files.sample_rate- required, default 44100, range 8000–200000. This is the one thing to get right: it must match the sample rate the audio was decoded at, or the tempo estimate is wrong (a 48k file analyzed as 44.1k reads ~9% slow). If your audio came out of a loader that already reports its rate, match it.
The single output beat_times is an AMPLITUDE series - beat number as index, seconds as value. Feed it into whatever converts timestamps into frame-length strength curves, or straight into a schedule mapper.
Why the sample_rate input exists
This is the practical difference between v1 and v2. The v1 detector trusts the audio's internal sample rate; v2 lets you tell it what to assume. That's useful when you've resampled audio upstream or when a loader hands over a slightly-off rate. Get it wrong and your "beats" drift off the actual hits by a consistent factor - a very distinctive failure that looks like the whole track is out of sync, and it's always the rate, not the music.
Installing it
Part of Deforum Nodes (XmYx). ComfyUI Manager → "Deforum Nodes", or:
cd ComfyUI/custom_nodes
git clone https://github.com/XmYx/deforum-comfy-nodes.git
First launch runs install.py, which installs librosa (the whole point of this node), scipy, opencv-contrib-python, moviepy, numpy<2.0.0 and the deforum-studio backend. Python 3.10 per the README.
Where people get burned
Two things. The sample-rate mismatch described above is the big one - a 10% sync drift is subtle enough to be maddening. And there's a cultural note: beat_track assumes a steady tempo, so tracks with wild tempo changes (progressive buildups, rubato sections) will place beats confidently but wrongly. For steady-BPM electronic music this node is excellent; for tempo-shifting material, neither detector is a great fit and you may want to tap beats manually instead.
Inputs (2)
| Name | Type | Default | Description |
|---|---|---|---|
| audio | AUDIO | — | |
| sample_rate | INT | 441008000–200000 | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| beat_times | AMPLITUDE | — |