You beatmatch the intro. It locks. Thirty seconds later you are nudging the pitch fader, and by the breakdown you are riding it constantly. The track sounded flawless when you previewed it.
It is not you, and it is not your controller. The track's tempo is moving.
The short version
Most AI music generators do not sequence music to a grid. They generate it the way a band performs it, and performances drift. Suno say so in their own documentation: "The tempo is not consistent over time, just like live music, which characteristically drifts around a little bit in speed."
That is a design choice, not a bug. It is also a nightmare for DJs, because everything in a DJ workflow assumes a fixed tempo exists to be found.
Why you cannot hear it on its own
Tempo drift is invisible in isolation. Your ear has nothing to compare against, so a track sliding from 132 to 134 across four minutes sounds completely natural. Put it next to a rigid 140 and it falls apart within a bar.
This is why the problem gets discovered at the worst possible moment: in a mix, in front of people, rather than while auditioning.
What it looks like when you measure it
We measured 70 generated tracks. The number that matters is how far the beat walks from the start of the track to the end:
| Tempo movement across the track | Share of tracks |
|---|---|
| Under 0.5 BPM, beatmatches cleanly | about 20% |
| 0.5 to 2 BPM, starts in time then slips | about 43% |
| Over 2 BPM, fights you all the way | about 37% |
One track measured 124 to 137 BPM inside a single five minute file. Another held to 0.14 BPM and was perfect. Same generator, same kind of prompt.
That last point matters: **drift is not universal**. Plenty of generated tracks are rock solid. You cannot tell which is which by listening to them alone, which is exactly why it needs measuring.
Why a beat grid cannot save you
This is the part that surprises people, and it is worth being precise about.
A beat grid **annotates** audio. It is a set of lines saying "a beat should be here". Engine DJ, rekordbox, Serato and Traktor all analyse a track and draw one, and they are generally good at it. When we compared, Engine's BPM agreed with our own measurements on all 70 tracks to within 1 BPM.
Engine is not getting the number wrong. The problem is that **no single number is correct for the whole track**. If the audio runs 132 at the start and 134 at the end, a grid at 132 is right at the start and wrong at the end, and a grid at 134 is the reverse.
Sync makes it worse rather than better. When you sync two tracks, the deck picks one playback rate and holds it. To keep a wandering track locked it would have to continuously modulate playback speed, bar by bar, for the length of the track. DJ decks do not do that. They set a pitch and hold it.
So: a grid can tell your deck where the beats are. It cannot move them.
Where the drift actually comes from
We looked at where inside a track the tempo moves, expecting to find seams between generated sections. That is not what it is. Here is one track's tempo, sampled every ten seconds:
| Position | Tempo |
|---|---|
| 0:00 to 2:30 | 132.1 to 132.7, steady |
| 2:36 | 132.7 |
| 3:07 | 133.5 |
| 4:29 | 134.1 |
The track **accelerates**. It holds for the first half and then climbs through the back half, which is precisely what a band does as a track builds. A model trained on recorded music reproduces that, because recorded music does it. What it lacks is a global clock: it keeps time coherently bar to bar, with nothing anchoring minute one to minute five.
How to fix it, properly
The best fix is at the source, before the file ever leaves the generator. Nothing gets time-stretched, so there are no artefacts, and the audio is right rather than repaired.
In **Suno Studio**, the Project Tempo control defaults to "Follow Track", and that default is where the drift comes from. Switch it to **Manual BPM**, pick your tempo, and export again. Suno's engine conforms the audio to a fixed grid.
If you are generating rather than working in Studio, anchoring the style field with terms like "constant tempo, steady groove, no tempo changes, 4/4 time" reportedly reduces drift, though it does not guarantee a fixed tempo the way Manual BPM does.
What about warping it afterwards?
You can. Ableton's warp does exactly this: it places a marker on each transient and time-stretches between them, which is why a drifting track shows a dense row of warp markers when you drop it in.
Two things worth knowing before you rely on it.
First, it is per-track manual work. Fine for one track, painful for a library.
Second, and less obviously, **warping is only as good as the beat detection underneath it**. We built a tool to do this automatically and found that when the detected beats carry even tens of milliseconds of placement error, warping writes that error into the audio. On one track the warp tightened the grid from 768 ms of slip to 53 ms. On another it produced an audible lurch, like a hand pulling back a record, because one badly placed beat needed a 48% stretch to reach.
Fixing it at the source avoids all of that.
How to tell whether a track drifts
Drift is best expressed as **a fraction of a beat**, not in milliseconds. Fifty milliseconds is a twelfth of a beat at 90 BPM and a seventh of one at 175, so a millisecond figure means something different on every track.
A reasonable line is **an eighth of a beat from start to finish**. A blend lasts a minute or two, so an eighth across a whole track spreads to roughly a thirtieth across the part you are actually mixing, which is under what anyone hears on percussive material. A quarter beat is audibly late by the end of a blend.
On Audibase, every release is measured when it is uploaded, and tracks that fail that test are marked so buyers can see it before they pay. If you are selling generated music to DJs, we would rather tell you about it while you can still fix it.
The half-time trap, while we are here
If your Drum & Bass keeps reading as 87 BPM rather than 174, that is a different problem and it is not drift.
DnB has a half-time feel: the kick and snare alternate around 87 while the breaks run at 174. Energy-based tempo detection finds the strongest periodicity, which is the slower one. Spotify's audio features are famous for this, and plenty of tagging software does the same.
Both readings describe the same beats, since the 87 grid is every other line of the 174 grid. It only affects the number displayed. For DJ use you want 174, because that is what every other DnB track in your library says.
The short answer
- AI generators produce music that wanders in tempo, on purpose
- You cannot hear it solo, only against another track
- A beat grid cannot fix it, because grids mark beats rather than moving them
- The clean fix is Manual BPM in Suno Studio, before export
- Warping afterwards works but is manual and can introduce its own artefacts
- Roughly a third of generated tracks are fine, so it is worth measuring rather than assuming