Any programmers?

[Patch]

But it doesn't have to be accurate.

[Ryan Ruel]

But it doesn't have to be accurate.

It's still the same problem. You would need to obtain data about the BPM at various sample points throughout the track, and then make some decision based on a statistical algorithm whether the BPM was consistent throughout the track.

It's an interesting problem, but not necessarily an easy one.

[JayRuss]

I'm not a programmer but, Im assuming (big assumption) tracks that dont have a steady bpm would show up in traktor as a bpm like 128.86/ have a weird decimal at the end, could a programmer write something that reads the traktor bpm data and gives you results that show all traks that dont have a bpm as an interger or close to an interger ? so for example a bpm of 127.99 would still be classed as a steady bpm but 127.84 wouldnt ?

[Chaser720]

I'm not a programmer but, Im assuming (big assumption) tracks that dont have a steady bpm would show up in traktor as a bpm like 128.86/ have a weird decimal at the end, could a programmer write something that reads the traktor bpm data and gives you results that show all traks that dont have a bpm as an interger or close to an interger ? so for example a bpm of 127.99 would still be classed as a steady bpm but 127.84 wouldnt ?

I was thinking along these lines as well. If you analyzed the track in Traktor, I wonder if Traktor throws any flags that you could look for similar to the BPM being a weird decimal point. If you could identify that then you could do a simple ID3 tag search and be done. Finding that flag is the fun part though. ha

[deathy]

Nah, the fractional component in Traktor isn't because of changing BPM, it's just that some folks like to work in fractional tempos.

[ImNotDedYet]

Nah, the fractional component in Traktor isn't because of changing BPM, it's just that some folks like to work in fractional tempos.

Could actually be both.

[Chubby Racer]

But it doesn't have to be accurate.

Yes it does. How else is software going to know that the BPM changed if it doesn't accurately know the BPM in the first place?

[Patch]

Think about it. Transition tracks usually go from one tempo to a much higher, or much lower tempo.

So the software would only need to take the tempo from 2 or 3 different parts of the track, and compare them. If they're within 5%, you can assume that there is not a tempo change - but anything greater than a 5% change would indicate a significant tempo change.

5% of 130BPM is about 6.5bpm. Now, a BPM checker with only 5% accuracy is pretty useless. But, a piece of software that can detect changes greater than ~5% is useful to a lot of us...

[mostapha]

You still have to solve the "what is a beat" problem first, which is the only hard part. After you do that, the BPM analyzer is almost trivial, and the "does the BPM change, significantly, at some point" is an extension.

It's a lot easier to just listen to them.

[Chaser720]

Think about it. Transition tracks usually go from one tempo to a much higher, or much lower tempo.

So the software would only need to take the tempo from 2 or 3 different parts of the track, and compare them. If they're within 5%, you can assume that there is not a tempo change - but anything greater than a 5% change would indicate a significant tempo change.

5% of 130BPM is about 6.5bpm. Now, a BPM checker with only 5% accuracy is pretty useless. But, a piece of software that can detect changes greater than ~5% is useful to a lot of us...

Think you're onto something here.

You could have the software slice all the tracks in a folder into 30 second pieces and check the tempo of each slice against the others. Could also use Traktor or whatever to analyze the slices for BPM and write to the ID3 tag (I think traktor does this automatically). Compare slice's ID3 tags and you're done. I think thats pretty doable for someone with basic programming knowledge.