I'm a producer/composer and I've been tasked with fixing a MIDI file. I'm using Reason 7. There are a number of things not done right, but this one has me stumped.

I've been told the BPM is 130.100 but it doesn't line up, as you get further into the song in particular. This is what it looks like early on:

enter image description here

It's slightly off but still fixable. But as you get further into the song, it just wanders about its merry way, getting way off the tempo. For example, the notes at 45.3.25 should be on 46.0.00:

enter image description here

I'm wondering... Is there some fix or magic bullet to detect the actual tempo and apply it to the MIDI file, that you guys know of? I've tried several alternate tempos, like 130.050, 130.000, etc but they all wander off pretty quickly... Or do I need to just scrub the whole file by hand and spend precious hours getting this to line up right?

PS: I guess "Lost in time" is an appropriate song title, all things considered!

  • In Ableton you can use the "quantize" function to do this. Should be able to do the same in Reason. It won't be perfect but it might help you get the bulk of it in time then fix the smaller bits by hand: youtu.be/7yOv0Hx8eds?t=2m55s
    – charlie
    Commented Sep 24, 2014 at 3:24

4 Answers 4


I've never seen any software that can do this without a lot of human help. Quantizing, even with a performance that is very near the beat, will ruin the musician's expression. And if someone has recorded a MIDI performance without adhering to a tempo reference like a click track, simply quantizing will destroy the data.

If you really want a mechanical performance, enter the score into something like Sibelius or Finale, export to MIDI and you'll have it perfect.

If you want to preserve the human interpretation but want everything to land on its feet, you have a lot of work ahead of you. It will require detailed, subjective decision-making and tedious data entry. In the screenshots you've shown, it looks like simple triads. This will make your job easier.

I find it's best to work one phrase at a time. Timing differences compound over time, but you'll find that each phrase will tend to have integrity relative to itself. By working one phrase at a time, you'll drill into the first phrase, fix it, move to the next phrase and line it up with the first and so on.

Begin by lining up the first note or chord with the absolute beat but keep the rest of the phrase relative to the first note. Fix any glaring timing problems manually. By "timing problems", I mean single note mistakes that are obviously wrong. If the phrase is slower or faster than the target tempo, use an "adjust selection time" feature to lengthen or shorten the phrase so it matches the target tempo. Use trial and error to find the right amount. This will keep the expression that quantizing would ruin. Only when the phrase fits into its measures can you quantize safely. Only do it if it's necessary and start with just a little bit of quantization, like 40%. Then line the next phrase up with the next measure and repeat the process.

  • Sounds like I got my work cut out for! Next time this happens I will make sure to get the file first and listen to it before I commit to charging my standard rates lol. Thanks for your great answer.
    – Phrancis
    Commented Sep 24, 2014 at 15:54

If the piece is supposed to already have a uniform tempo, (i.e., it's not a recording of a human performance, as trw mentions) and the question is a merely a matter of discovering which tempo it is, you might be able to use some type of "tap tempo" tool. I'm sure there are lots of these, but the one I'm familiar with is in Reaper. You can probably find one on a website online.

Essentially, while the music is playing, you click a button (either on the mouse or keyboard) every beat, on the beat. Try to be as accurate as possible. Over a short period of time, the software will be able to determine the current tempo from your average rate of clicking. This will also allow you to check if the tempo varies, or remains constant, over the course of the song (If it varies, your work will be much more difficult).


If Reason has the capability: you can use the beats in the existing MIDI file to set the actual tempo to that of the unaltered MIDI performance. This means that the tempo itself will vary slightly to suit the music, not the other way around. If the project calls for a hard 130.1bpm tempo, this is not your solution.

What you're trying to do is to actually adjust the tempo as the song plays to match the human tempo of the midi file. If you can tell Reason where the downbeats in the MIDI file are, it might be able to generate a new tempo track that will adjust the tempo in little bits while the song is playing. This will completely eliminate any 'machine' effect from quantizing, but still let you use the tempo-based functions of your DAW.

  • Welcome to Music Stack Exchange. Your answer is clear and to the point. One concern might be that your details sound like they are based on a generic MIDI knowledge, rather than a specific knowledge of Reason, which perhaps makes the overall answer less helpful than it might be if you knew a specific fix, but I would think it would still be helpful to the OP. Again, welcome.
    – L3B
    Commented Mar 12, 2017 at 16:44

A glance at the file suggests that it IS quantised, and therefore probably was created at a fixed tempo. I'm not sure how it slipped out of synch, but you might be able to stretch it back. I can only describe how I'd do it in Cubase though.

There's a function where you can select an object - in this case it would be the whole song - and drag the endpoint to re-size it. The content is proportionately stretched. Do this so that a note at the end DOES align with a barline. All may be solved, or at least close enough so that a very small quantisation value makes it perfect.

But didn't the MIDI file import along with its tempo information? You shouldn't have had to be TOLD the tempo was 130.1. This setting should have been imported automatically. Though note that tempos often are interpreted slightly differently by different programs. A song made in Cubase at q=120 may well import to Logic as e.g. q=119.0177. Be careful you don't mess things up by 'correcting' this.

It's also possible that it isn't quantised. Does it need to be? What sort of 'fixing' have you been tasked with?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.