RoninSaniShipibo
Very much of my music over 160 BPM is detected with half BPM, from 160 and above. 160 -> 80 ... Is this something with the BPM-detector that is hardcoded with something from 160 as a limit in any way?
Posté Thu 29 Nov 18 @ 6:38 pm
PhantomDeejay
No, it's not hardcoded, nor a limit exists. However since the vast majority of tracks is NOT higher than 160BPM, the BPM scan algorithm has to be 100% sure that the track is 160+ BPM to write this value. If it doubts, it uses the half value which is much more common...
Posté Thu 29 Nov 18 @ 7:24 pm
grenno
If you highlight all the tracks that have been analysed, right click - tag editor, and select the [x2] button by the bpm, it will double the tempo of all the selected tracks simultaneously.
Hope this helps!
Hope this helps!
Posté Fri 30 Nov 18 @ 1:10 am
Don Moir
I have said some of this before, but it has evolved for me over time. I work on it periodically. I will add some notes about halving and doubling in second post. For me these post about BPM help me to keep it fresh in my mind and some of you may have some useful insight.
When I first started trying to code software to do BPM detection, I downloaded several popular BPM detection programs to see how accurate they were. Well first thing I noticed was they don't agree much are using a variety of files. Sometimes some of the programs would be close but not exact. So given that I start thinking maybe ball park is ok.
Then I start studying code. (supposed to be good). First week, I can see there is no way this can be dead on accurate. Not counting doubling or having. I could see this code could never be all that accurate. Again I am thinking maybe accuracy is not so important. After all, a human is not going to be able to detect if a BPM value is a little off.
So then start looking at doubling and halving. Mostly a guess based on some number crunching and looked pretty funky to me for the particular code I was looking at. I looked a bunch at other code to see how they were dealing with halving and doubling issues. Some just an simple decision to half or double. Others more complex. None of it set well with me. Either clumsy or too simplified and not right.
I studied the the papers written by the scholarly people. Funny, everyone I read started out by saying something like: "we all know the state of BPM detection is pretty weak". Expecting to find better answers after I read their paper :) Always at the end of the paper they would state what was wrong with their method and what further work needed to be done. geeze. Some of these I implemented and found them to be no real solution.
All the stuff I read and no one ever mentioned accuracy. I thought that was odd and still assuming accuracy within a BPM or so is not that important. From a human perspective I can't see it mattering that much. But from a computer perspective that is doing matching, it can become important.
So after researching for quite awhile, testing files over and over, I kept the things I found useful and dumped most of the code I had used etc. Start from scratch now knowing some things I learned along the way.
I follow the notes about BPM on these forums. You guys use it in practice and that is useful. Sometimes I see people are confused about software BPM detection and that is understandable. I don't know any BPM detection software that is good from what I have used. Good BPM detection software may exist, but I can't check everything. I have already spent a lot of time on it. You can only compare one program to another and one may be better than another. Does not mean it is good though. Just one is better than something else perhaps. In that respect, VDJ does pretty good when compared. Nothing I have found is what I would call good. Poor is a better word compared to a persons expectation. Keep in mind that this problem is being worked on by people all over the world. There are contest to see who can do best etc. Not an easy problem to solve in the general sense. I had noticed sometimes I am coming up with fractional values that seem to have a pattern. like 140.998, 90.003, and similar values. I had no clue what that was and my only though is something is wrong with the BPM code.
So I started at square one and thought to tackle the exact accuracy issue first. The thing that no one had mentioned in stuff I had read. People here have mentioned it though. One guy was complaining about VDJ coming up with values like 140.998 and saying it was wrong and some other program came up with the right answer, in his mind anyway, which was 141. I noted that and though it was strange especially with a pattern like that. Though it was probably some digital computer thing but did not know what. So thinking the best way to do that, is to start with files that only have beats in them with no noise. Ok cool, should be the easiest case and I will absolute know what is right and how my code can deal with the simplest case and how accurate. So I go up on the net and get a collection of files that only have digital beats and for a variety of BPMs. Looking ok for the most part but I am still seeing the odd fractional values when it should be exact. First thinking the code was wrong. Then started graphing the beats and BPM markers. Those files were indeed wrong and encoded incorrectly with the fractional values instead of integer BPMs. You just can't trust anybody :) So now I know about that. Just those files are encoded probably (just bad code) at the wrong BPM or some compression or something along the way has changed it. I think just encoded wrong in the first place. So can't trust those files and I start to create my own and they are EXACT. I am using 48k 16 bit stereo wav files with no compression. I can tell the software to create a 6 minute file with any BPM value. I have chosen to also have it create some with fractional values on purpose. This helps to test for precision. I created some much simpler BPM detection software for the purpose of accurately measuring the BPM for simple beat only files.
So in this sample I had my software create an 80.003 BPM file.Then I plotted it with the exact 80.003 value and also the incorrect 80.000 value. You can see how it drifts.
Well not too big a deal audio wise. No one will notice with just listening and it is so close that mix will be fine. If this file played for a long time instead of just 6 minutes it would eventually get where the offbeat drift could be heard. For relatively short files not a big deal but it is confusing to user. He may see the markers are not lining up. Sure he knows something is wrong even if he can't hear it. The user above claimed VDJ was wrong because of the fractional values and some other program was right because it showed an integer value. In his eyes it was absolutely integer even though it was not. VDJ was right with the fractional value.
I have a lot more to say about this...
When I first started trying to code software to do BPM detection, I downloaded several popular BPM detection programs to see how accurate they were. Well first thing I noticed was they don't agree much are using a variety of files. Sometimes some of the programs would be close but not exact. So given that I start thinking maybe ball park is ok.
Then I start studying code. (supposed to be good). First week, I can see there is no way this can be dead on accurate. Not counting doubling or having. I could see this code could never be all that accurate. Again I am thinking maybe accuracy is not so important. After all, a human is not going to be able to detect if a BPM value is a little off.
So then start looking at doubling and halving. Mostly a guess based on some number crunching and looked pretty funky to me for the particular code I was looking at. I looked a bunch at other code to see how they were dealing with halving and doubling issues. Some just an simple decision to half or double. Others more complex. None of it set well with me. Either clumsy or too simplified and not right.
I studied the the papers written by the scholarly people. Funny, everyone I read started out by saying something like: "we all know the state of BPM detection is pretty weak". Expecting to find better answers after I read their paper :) Always at the end of the paper they would state what was wrong with their method and what further work needed to be done. geeze. Some of these I implemented and found them to be no real solution.
All the stuff I read and no one ever mentioned accuracy. I thought that was odd and still assuming accuracy within a BPM or so is not that important. From a human perspective I can't see it mattering that much. But from a computer perspective that is doing matching, it can become important.
So after researching for quite awhile, testing files over and over, I kept the things I found useful and dumped most of the code I had used etc. Start from scratch now knowing some things I learned along the way.
I follow the notes about BPM on these forums. You guys use it in practice and that is useful. Sometimes I see people are confused about software BPM detection and that is understandable. I don't know any BPM detection software that is good from what I have used. Good BPM detection software may exist, but I can't check everything. I have already spent a lot of time on it. You can only compare one program to another and one may be better than another. Does not mean it is good though. Just one is better than something else perhaps. In that respect, VDJ does pretty good when compared. Nothing I have found is what I would call good. Poor is a better word compared to a persons expectation. Keep in mind that this problem is being worked on by people all over the world. There are contest to see who can do best etc. Not an easy problem to solve in the general sense. I had noticed sometimes I am coming up with fractional values that seem to have a pattern. like 140.998, 90.003, and similar values. I had no clue what that was and my only though is something is wrong with the BPM code.
So I started at square one and thought to tackle the exact accuracy issue first. The thing that no one had mentioned in stuff I had read. People here have mentioned it though. One guy was complaining about VDJ coming up with values like 140.998 and saying it was wrong and some other program came up with the right answer, in his mind anyway, which was 141. I noted that and though it was strange especially with a pattern like that. Though it was probably some digital computer thing but did not know what. So thinking the best way to do that, is to start with files that only have beats in them with no noise. Ok cool, should be the easiest case and I will absolute know what is right and how my code can deal with the simplest case and how accurate. So I go up on the net and get a collection of files that only have digital beats and for a variety of BPMs. Looking ok for the most part but I am still seeing the odd fractional values when it should be exact. First thinking the code was wrong. Then started graphing the beats and BPM markers. Those files were indeed wrong and encoded incorrectly with the fractional values instead of integer BPMs. You just can't trust anybody :) So now I know about that. Just those files are encoded probably (just bad code) at the wrong BPM or some compression or something along the way has changed it. I think just encoded wrong in the first place. So can't trust those files and I start to create my own and they are EXACT. I am using 48k 16 bit stereo wav files with no compression. I can tell the software to create a 6 minute file with any BPM value. I have chosen to also have it create some with fractional values on purpose. This helps to test for precision. I created some much simpler BPM detection software for the purpose of accurately measuring the BPM for simple beat only files.
So in this sample I had my software create an 80.003 BPM file.Then I plotted it with the exact 80.003 value and also the incorrect 80.000 value. You can see how it drifts.
Well not too big a deal audio wise. No one will notice with just listening and it is so close that mix will be fine. If this file played for a long time instead of just 6 minutes it would eventually get where the offbeat drift could be heard. For relatively short files not a big deal but it is confusing to user. He may see the markers are not lining up. Sure he knows something is wrong even if he can't hear it. The user above claimed VDJ was wrong because of the fractional values and some other program was right because it showed an integer value. In his eyes it was absolutely integer even though it was not. VDJ was right with the fractional value.
I have a lot more to say about this...
Posté Fri 30 Nov 18 @ 10:38 am
grenno
Of all the software I've used, I'd say VDJ is the best.
ESPECIALLY for acapellas. It's nigh on witchcraft how well it does on acapellas. Rekordbox is all over the place.
Like you said though, you can only compare it to other software trying to achieve the same goal.
ESPECIALLY for acapellas. It's nigh on witchcraft how well it does on acapellas. Rekordbox is all over the place.
Like you said though, you can only compare it to other software trying to achieve the same goal.
Posté Sat 01 Dec 18 @ 11:01 pm
Don Moir
For a long time I was trying to ask how close is close enough. I sure could not tell with any software I was initially comparing test with.
When I first started with this (years ago), my initial thought about having just one BPM describing the BPM for entire song was silly. I had also asked some of the DJs here about that and they gave reasonable answers. If all the music you want to mix is very robotic then maybe it works ok. May fail even then. Some files are even being written incorrectly. Mentioned above and finally was able to verify that. I still think it's crazy to rely on one or 2 bpms for entire song. I am just going by the numbers. You guys use it in practice. If it gets the job done for you then that is one measurement you can use. People can't deal with fractional BPMs. Most probably can't tell the difference plus or minus a few whole BPMs from the actual BPM by listening. Most people have no problem tapping to the music. I read that is it rare for someone not to be able to do that in time with the music. Those people that cannot tap out to the music are wanted by researches for testing. Software that is using just one BPM is looking for the most prominent BPM value in the song. Then that value is used for the entire song. Too easy to be wrong like that (and often is wrong). I don't listen to anyone who says some software does really good beat detection. 'good' is a measure that could mean how well does it do the job for you. I only can only rate some BPM detection based on graphs. I don't know anyway else to do it. If the graph does not match up then something is not right.
Geeze getting too tired now and still lots more to say later :) There are loose ends that I have not finished out yet. fractional, half and double, peoples expectations, mixing, single bpm values per file, etc.
When I first started with this (years ago), my initial thought about having just one BPM describing the BPM for entire song was silly. I had also asked some of the DJs here about that and they gave reasonable answers. If all the music you want to mix is very robotic then maybe it works ok. May fail even then. Some files are even being written incorrectly. Mentioned above and finally was able to verify that. I still think it's crazy to rely on one or 2 bpms for entire song. I am just going by the numbers. You guys use it in practice. If it gets the job done for you then that is one measurement you can use. People can't deal with fractional BPMs. Most probably can't tell the difference plus or minus a few whole BPMs from the actual BPM by listening. Most people have no problem tapping to the music. I read that is it rare for someone not to be able to do that in time with the music. Those people that cannot tap out to the music are wanted by researches for testing. Software that is using just one BPM is looking for the most prominent BPM value in the song. Then that value is used for the entire song. Too easy to be wrong like that (and often is wrong). I don't listen to anyone who says some software does really good beat detection. 'good' is a measure that could mean how well does it do the job for you. I only can only rate some BPM detection based on graphs. I don't know anyway else to do it. If the graph does not match up then something is not right.
Geeze getting too tired now and still lots more to say later :) There are loose ends that I have not finished out yet. fractional, half and double, peoples expectations, mixing, single bpm values per file, etc.
Posté Sun 02 Dec 18 @ 9:38 am
groovindj
I agree - I think it's ridiculous that DJ software (generally) only allows for one BPM and one key per track.
The late James Hamilton of Record Mirror was famous for meticulously listing BPMs for many years. Example: Shakit by Brass Construction = 121-122-123-120-124-120-124-120-124-123 bpm - and he was doing this manually in the 70s and 80s, and publishing them for DJs in a popular magazine, long before DJ software.
VDJ lists it as just 121 bpm. Any unsuspecting DJ trying to mix that with another 121 bpm track is going to struggle, as there's no obvious display onscreen of a tempo change i.e. a live bpm readout.
Also that VDJ cannot automatically analyse and grid tracks with wavering tempos. We're expected to do it manually, yet this is something that computers should excel at (see Ableton Live's warp mode).
Ableton's software can do this "with its eyes closed", often with very little intervention required. Even better, it allows the track tempo to be locked / corrected, so that it becomes possible to mix the track far easier, without needing to ride the pitch.
The late James Hamilton of Record Mirror was famous for meticulously listing BPMs for many years. Example: Shakit by Brass Construction = 121-122-123-120-124-120-124-120-124-123 bpm - and he was doing this manually in the 70s and 80s, and publishing them for DJs in a popular magazine, long before DJ software.
VDJ lists it as just 121 bpm. Any unsuspecting DJ trying to mix that with another 121 bpm track is going to struggle, as there's no obvious display onscreen of a tempo change i.e. a live bpm readout.
Also that VDJ cannot automatically analyse and grid tracks with wavering tempos. We're expected to do it manually, yet this is something that computers should excel at (see Ableton Live's warp mode).
Ableton's software can do this "with its eyes closed", often with very little intervention required. Even better, it allows the track tempo to be locked / corrected, so that it becomes possible to mix the track far easier, without needing to ride the pitch.
Posté Sun 02 Dec 18 @ 10:04 am
Don Moir
A person does not deal with fractional BPM values. I think it is unlikely people intentionally record music with fractional BPM values.For the most part, the fractional BPM values come from trying to use one or a few BPM values per file.
What does a person listening to music do to keep up with the beat? He adjust with hardly a thought. We want to model what people do don't we? How can it ever be right if we don't?
If you use variable BPM, then some good things just happen. 1) models what people do 2) allows for accuracy for a greater variety of music. 3) you can throw away the fractional BPM values which only have meaning because of the weakness with a single or few BPM values. The computer will self adjust and no one will give a rats ass even if something is off by a full BPM value. 1 BPM is 0.0166666666666667 beats per second.
The downside of variable BPM is it can be more difficult to adjust if it is detected incorrectly. In general it should be more accurate. The software can also track the prominent BPM value as a fall back but that brings back the same old sh... If people would spend the enormous amount of time spent researching single BPM, on variable BPM, I would think things would get much better.
If you can throw away fractional values, then beat detection becomes easier and faster. I know since I have experimented a lot with accuracy. from 1 to 1/1000, Greater accuracy requires more compute time. My BPM detection uses reverse logic to hone in on accuracy. But now I say through that notion away. People don't deal with that. Does not matter if you are out there dancing or trying to mix. It is a computer thing. Let the computer figure it out instead of putting insane demands on people.
If you have a problem with anything I have said about this so far, please let me know. This is a difficult topic and I make mistakes and I don't learn anything if I am just rambling on. I can say I have spent a lot of time coming up with what I believe on this. It all looks like crap to me as it stands after spending endless hours coding and researching and graphing till my eyes were about to fall out. I will work on it some and then pause for awhile and let things sink in. I have more to do and only spend some time on it occasionally these days.
What does a person listening to music do to keep up with the beat? He adjust with hardly a thought. We want to model what people do don't we? How can it ever be right if we don't?
If you use variable BPM, then some good things just happen. 1) models what people do 2) allows for accuracy for a greater variety of music. 3) you can throw away the fractional BPM values which only have meaning because of the weakness with a single or few BPM values. The computer will self adjust and no one will give a rats ass even if something is off by a full BPM value. 1 BPM is 0.0166666666666667 beats per second.
The downside of variable BPM is it can be more difficult to adjust if it is detected incorrectly. In general it should be more accurate. The software can also track the prominent BPM value as a fall back but that brings back the same old sh... If people would spend the enormous amount of time spent researching single BPM, on variable BPM, I would think things would get much better.
If you can throw away fractional values, then beat detection becomes easier and faster. I know since I have experimented a lot with accuracy. from 1 to 1/1000, Greater accuracy requires more compute time. My BPM detection uses reverse logic to hone in on accuracy. But now I say through that notion away. People don't deal with that. Does not matter if you are out there dancing or trying to mix. It is a computer thing. Let the computer figure it out instead of putting insane demands on people.
If you have a problem with anything I have said about this so far, please let me know. This is a difficult topic and I make mistakes and I don't learn anything if I am just rambling on. I can say I have spent a lot of time coming up with what I believe on this. It all looks like crap to me as it stands after spending endless hours coding and researching and graphing till my eyes were about to fall out. I will work on it some and then pause for awhile and let things sink in. I have more to do and only spend some time on it occasionally these days.
Posté Sun 02 Dec 18 @ 3:19 pm