I use Traktor as my master library, as I use timecodes on my 1210s, but also have my denons. My workflow is that I build any playlists or sets in Traktor and then each time I add some new tunes or playlists I will remove the crate and playlists from Engine Prime, then refresh my Traktor library in Engine Prime, then re-add my whole library as a crate, then the playlists as playlists. This works great and is pretty quick so not too much of a pain, though I noticed I need to - re-analyse the whole library every time this happens as the waveforms disappear. Not a problem but would be nice if I could just re-sync to the refreshed traktor library rather than having to delete and re-add everything.
Anyway, the problem is that when I do this, 95% of tunes without a problem, but then when I go and play on the SC5000s I thought I was going mad as some tunes read right on the BPM but were fast or slow in my ear. I realised after a while that it’s ALWAYS 1bpm wrong up or down, so I’ve now learned to compensate quickly if I hear something running out, but it is REALLY annoying as it’s hard to ignore the bpm when it’s so big on the screen but I can’t trust it. Every time I now make a set list I have to line up traktor vs engine prime and look through each and every tune to check the bpm of one against the other and manually edit the wrong ones so I don’t get tricked. This is obviously a bug but has been in the software for a long time now, I was hoping it would be fixed with 1.5.0 but doesn’t seem to have happened.
Does anyone else get this? Is there a fix? I tried re-analysing the tunes but no change. For info this happens both on house 130ish bpm and drum & bass 174ish in equal amounts.
Traktor writes its analyzed BPM value to the track’s file tags, which is strictly cosmetic in Traktor because the grid and actual BPM are based on proprietary data.
Could’ve sworn one of the conditions of you being allowed a presence on here was not promoting certain tools… The last couple of your posts advertising an “alternative” don’t exactly conform to that condition imo.
As for the tag, I had a feeling Traktor did this and if it wrote the wrong value to the tag then EP 1.5.0 will use the tag value over the new BPM algorithm, leading to an incorrect value in EP, hence my advice to wipe the tags, reimport track information then reanalyse.
I wasn’t, as you well know. However you yourself did give some details including that specific one out in your introduction thread sooo…
Anyway this is offtopic - my point is that I had already replied, offered support to the OP and was waiting on a reply, so we really didn’t need the suggestive spam in this case.
your “solution” really isn’t because EP is not capable to read the grid from any DJ software, including Traktor. As I said, Traktor writes its analyzed BPM value to the track’s tag, so if his grid is good in Traktor then EP should be good to go off the track’s BPM tag.
The (much) improved BPM analysis of EP 1.5 doesn’t change that either. OP’s problem is not the BPM value, but the warping that happens in the grid.
Your “solution” would ony be valid if the BPM tag had the wrong BPM value, which EP then prioritises over its own analysis.
If I talk about alternatives I include Rekord.cloud that will include EP compatibility and Rekordbuddy, where Damian just announced that beta 2.2 will have EP compatibility.
Until those 2 materialize my tools are the only option to the problem at hand, and have been for over 3 years now. But yes you need to be on MacOS. The new kids around the block will fulfill the Windows needs as well as MacOS so you have choice.
[Edit] if the actual BPM value needed to be rounded then indeed what you say might work. the BPM tag is always an integer, if the actual BPM is not a round number or was wrongfully rounded off then EP prioritizes a wrong value. Which might be fixed by resetting the bpm tag to none. That won’t effect Traktor’s functioning. and force EP to rely on its own analysis. However that would also mean that the original BPM is NOT a round number, which isn’t EP’s stronghold in the first place.
Thanks for the replies everyone! Sadly I use windows not mac so cannot use the tools you refer to. I actually also use Rekordbox and Serato when I play out sometimes which is even more annoying but that’s another story. My main two are Traktor and EP.
The BPMs are always spot on in Traktor which is why I line the two softwares up to check and correct the errors in EP so it seems unlikely that EP is pulling the wrong values from the id3 tag but I will have a look and see…
So how do I go about clearing the bpm from the id3 tags to reanalayse? I have about 3000ish tunes so hopefully not manually!
Whatever you do, don’t batch edit them in Traktor, which is technically a possibility.
Traktor, like EP and most other DJ software has 2 kind of BPM values. The exact one for the grid and the tag which Traktor doesn’t read, but only write when the grid is created/modified. Editing the BPM in Traktor will reset both those BPM values which is not what you want.
Editing the BPM tag outside Traktor does not effect the Traktor grid, but holds one big typical Traktor risk.
The Traktor metadata is stored in 2 places: The collection.nml (Traktor’s database) and a propriatery file tag. This metadata isn’t always in identical!
Which metadata Traktor uses is decided by a time stamp and this decision is only made the moment Traktor loads a track in the deck, of if you preform a “check consistency” on the collection. This time stamps are derived from a field in the nml (you can read it yourself if you open the nml with a text editor) and the modification date of the track.
Changing BPM will change the track file’s modification date. Which can cause Traktor to use old metadata from the Traktor tags. Typical symptoms are artwork no longer being displayed en old (or no) cues and loops.
So before you continue have backups! not only of your collection file but also of the audio files!
Traktor is my DJ preparation software of choice as well
And this Traktor behavior is the main reason why I always oppose against any DJ software writing to the track’s file tags without the possibility to disable that.
Now on your BPM issue I’m interested in is these points:
What is the EXACT true BPM of the troubled track (just pick one as an example) in Traktor.
Does that track has a stead grid (one marker) or do you reset the grid with a new beatmarker in Traktor?
What is the BPM tag value when you read that track in a tag editor (iTunes or what @kradcliffe suggested will show you the value)
What is the BPM value Engine Prime displays if you analyze that track in EP and you load it in a deck?
The 86.5 is without the tempo ID3 tag and doubled is 173 (I don’t have my range set that high so for me it will choose the halved value, which is intended).
So without the Traktor library these are analysed correctly - The steps you provided are not what most would consider a “usual” workflow in that there is a reanalyse step at the end, I’m not too surprised that was missed in testing, it’s a very specific set of steps. I would suggest raising this as a bug report here https://community.enginedj.com/c/software/bug-reports-engine-prime/102
Like I already suspected. If I run the test the problem is not the BPM, which is recognized in EP as 173 from a straight Traktor import of that test file.
However your GRID is shifted. Look at the beatmarker in Prime (the 2 white arrows). It’s not where the cue Beatmarker is at.
and of course because I couldn’t resist. the results how my tools handle that exact same track (straight conversion NO manual tweaking, tag editing/doubling or cheating)
It’s not as much a bug but how the Prime ecosystem works.
Thanks for checking guys! MixMG, I’m not exactly following you here but I’m close - can you help me understand what is the cause of the issue? It sounds like you’re saying it’s because the beat grid is being set wrong in EP? So is this an error caused by EP taking the 173 BPM and the wrong beat grid starting position and not being able to reconcile the two?
Is there a fix for this then or is it just a bug until it can be fixed? If so then I’ll log it in the bug forum…
in general these kind of tracks are hard for any software to analyze. Traktor happens to be pretty good at auto analysis, which is one of the reasons why its still my preferred DJ software.
The grid you get at EP doesn’t start at the first kick, it starts a beat behind it. The 2 vertical white triangles indicate the start of the grid in EP.
The start of the first kick (or beat 1.1.1 in Traktor) is where you also have your Traktor cue named “beatmarker”.
In my tool’s converted track the beatmarker cue and actual beatmarkers overlap, but you can see at the 5th beat (2nd bar, the red veritcal line or beat 1.2.1 in Traktor) that this is indeed the grid you want.
In my test with your track (MacOS) EP 1.5 did get the BPM correct from the track’s file tag. It’s beyond me why it should make yours 172 BPM, since you and I both used the same track processed through Traktor (3.3.)
The only way you can fix the grid is to manually adjust it. This means delete the EP’s beatmarker set a new one. Don’t set extra beatmarkers in EP, because this will make things worse.
If you want to know more about Prime grids, I explain most of it here
Thanks very much for your explanation MixMG! Really cool stuff you’re doing there. Ok so the root cause here is that this type of track is plain hard to analyse, and to get the downbeat to sit where it should do on the very first beat is not easy for the algorithm of any software to do. I guess if this can be solved then no problem should occur.
In the short term though, the major issue is that there is no indication that this has happened until I’m in the middle of a mix and realise that a track has the wrong bpm on it, and with this happening only 5% of the time or less, and with a lot of tunes in my library, scanning through to compare Traktor BPM to EP is not practical, so for now there is no fix for this bug. That said, you said that your setup is not producing a BPM of 172, so I don’t understand that part given that we are using the same software, albeit windows and mac versions…
In any case, I’ve logged this in the bug forum so let’s see what they say…
And this Traktor behavior is the main reason why I always oppose against any DJ software writing to the track’s file tags without the possibility to disable that.
