I put a post and a bug report up back in June of last year (BPM Reading wrong on some tracks - always 1bpm out) which outlined a problem with beat detection on 5-10% of drum & bass tunes - always 1bpm out.
It still does it on a lot of tracks in my library and it’s REALLY annoying when mixing and having to second guess every beat readout. I’ve taken to making some little cardboard pieces to put over the beat readout to stop myself inadvertently reading it. If the beat grids can’t be fixed in a hurry, could we please add an option to TURN OFF the beat readout on the SC5000? It’s been like 2 years of this now - surely the beat detection will be improved soon? Super hoping for an Engine Prime update that will finally fix this - Engine Prime is the only library software that does this (I also have Rekordbox, Traktor, Serato).
I use Rekordbox for my main library then convert to Engine using Rekord Cloud. TBH, Rekordbox has the same issue (not to mention the terrible down beat detection). As always, it is important to go through and fine tune your beatgrids as part of the track prep process. It’ll save you tons of headache, especially when using loops and quantized fx.
Ah I use Traktor as my master library and it is always spot on with bpm detection - almost never had a problem. Sometimes with drop beat detection but that doesn’t really matter - I drop the tunes with the platter in vinyl mode anyway. Having the bpm detection wrong that often just makes the readout useless as you can never trust it. It’s also a nightmare like you say if you try to run a loop or beat jump.
I have thousands of tunes in my library though and I’m definitely not going to go through each of them to check which ones are wrong and adjust them manually - it’d take weeks.
It goes by quicker than you think. But, since you already have traktor, just use rekord.cloud to convert your library to engine then use re-analyze in engine Prime once converted (so EP will use the bpms tagged by traktor).
What do you mean convert the library? I checked out rekord.cloud and it doesn’t support Engine Prime…? The bpm detection is perfect in Traktor but Engine Prime doesn’t import it correctly, in fact it is Engine Prime importing the Traktor incorrectly that seems to be the issue… From memory someone identified the issue and I think it was when importing the Traktor library it uses the right BPM but gets the drop beat wrong and results in a BPM 1 beat out…?
I have a rather large D&B library and 9/10 times the bpm is detected correctly, but 3/10 times I need to adjust the grid one beat to left or right.
Rekordcloud actually works with Prime, although there some (known) issues you can avoid easily. If you import from Traktor and sure that BPM is correct in Traktor, you can disable Auto Analysis in EP, import tracks, and then press Analize (it will only create grid, not re-detect bpm) as far as I am aware. If you press Re-Analize - it will try to detect everything regardless of BPM tag.
This is interesting… I’ll try it, yeah the BPM is always right in traktor, I’ve only see it go a little bit wrong on some really old jungle tunes that probably aren’t consistent anyway.
So what’s the benefit of Rekordcloud then? My workflow is normally:
add tunes in Traktor
Sort them into mood/genre playlists and build any sets in Traktor
Import Traktor library into Engine Prime (or Rekordbox using another bit of software)
Move Playlists into playlist section and crates into crate section
Re-Analyse everything in Engine Prime
If I were to use RekordCloud what changes and what benefit does it bring? I’m struggling to see it…
Don’t choose “Re-Analyze” - just turn off auto-analyze in options in Engine Prime and then “Analyze” after you got tracks in EP. But this requires that Traktor writes BPM to tags.
Rekordcloud has other nice tools to help you organize and maintain your library, it’s not just for transferring libraries.
I used it to transfer my EP library back to Traktor as I mostly use EP for everything now, but want to have my Traktor library up to date.
If the BPM is correct, then the grid is also correct, because the two are linked. The BPM is determined by the grid. Your sentence implied that you were adjusting the grid to correct the BPM.
If the position of the grid (not the timing) needs adjusting, the BPM is not wrong. The grid is just badly aligned.
I do not consider misaligned grid as correct but now I understand what you mean. Bottomline is I have to realign grid one beat left/right much more often than I need to fix improperly detected BPM.
Ok I tried this on a track that I know is 173 BPM that Traktor has listed as 173. I cleared out engine prime and re-imported the Traktor library, turned off auto analyse as you said and then selected all tracks and pressed analyse. It has re-analysed every track and when imported the track showed 173BPM, it now shows 172. It seems there isn’t a way to prevent it messing with the BPM - unless I missed something?
I understood that’s what you meant, and they are two different statistics, so you are correct in what you said, if you did say it a little confusingly!!
So does Rekord.cloud also generate beatgrids and bpm for EP so you can just import it ready to do into EP or do you still need to do the analysis in EP?
It does it on lots of tracks but this is a good example…It’s 173 in Traktor (correct) and 172 in EP (incorrect). Apparently when run in EP not imported from Traktor is is 173 and correct. The problem comes in it trying to take the BPM from traktor with an incorrectly calculated beatgrid and it not fitting so it ends up with 172bpm. So to fix the problem I think EP needs better downbeat selection or to prioritise BPM over drop beat. If it can’t fit the grid that’s less of a problem and can be fixed on the fly if needed.
