I’ve just got a Prime 4 and am getting problems with wrong BPM detection on tracks.
Particularly a faster track 146 BPM being detected slower, like 109 BPM.
Is there any way to override the detection? I’m unable to use “Engine” and only have the Prime 4.
Not without Engine. If your tracks have BPM values written by another software (Serato, Rekordbox) then you can run ‘Analyze’ in Engine and your Prime 4 will recognize the existing BPM value. Do not run ‘Re-Analyze’ as this will run Engine’s BPM Analyzation and will prioritize Engine’s BPM over the existing BPM.
Hmm although this is annoying, it’s not a deal breaker for me, since I can just mix by ear/visual, and the horizontal waveform display really helps with that. The beat grids etc are so wrong on most of my psytrance tracks, it’s close to pointless. House music seems to be well-recognized/understood by the player, but once I get into >145bpm things begin to fall apart. I’ve tried setting the Beat Detection settings to higher BPM but it hasn’t improved anything.
So what I’ve noticed is on my tracks the ones that are off are usually off by exactly one beat per minute.
Sorry this doesn’t help OP, but it is related to what @djdminer mentioned.
I looked into the off by one bpm misdetections a bit, by playing with it and watching what engine prime does in it’s sqlite dbs to see what’s going on when it comes to these specific misdetections.
tl;dr analyze your tracks twice to fix these.
I don’t have access to prime’s code, but the problem appears to primarily hit tracks with a bpm like say 122.995. I can accurately find (at least many) tracks that are problematic with a sql query like this in m.db:
select * from Track where bpmAnalyzed LIKE "%.99%"
When your track is analyzed the first time since (any) import (including library updates), if the BPM ends is, say, 122.995 then engine will effectively remove the decimals to 122 and copy that incorrect value into another db field (one way this can happen is by coercing a float into an int, better to not use an int though imo) that it appears to take into consideration when reanalyzing them.
Analyze them once to get the off by one bpm. Re-analyze them and the bpm will fix itself.
I have to re-analyze my tracks twice now every time I import from traktor, which I only do to sync cue points from mixed in key because I’m lazy. Doing this overwrites at least some changes I’ve made locally in engine, without warning me. ugh.
I don’t foresee this getting better in the near term, so I started writing a barebones importer from traktor to engine prime that only imports new tracks and adds cue points if none exist. It kind of works, but I want my time back as I shouldn’t have to do this.
Anyway, this bpm detection problem is such an annoying and obvious bug, I’d be extremely surprised if Denon didn’t catch this before release.
I plan on looking into updating the column myself during import to the rounded number, will report back if it works.
I’d love to have access to denon employees to ask very technical questions to help speed me along, hint hint @DenonDJ
Back in 2017, 2018 and 2019 EP struggled with bpm calculation, as a work around the devs allowed EP to use bpm values in new tracks id tags for analysis.
At some stage during this process eg
Original analysis program eg Serato writing BPM as INTEGERS into the id tags whilst maintaining correct bpm in DECIMALS in its own DB
and/or
EP there is a rounding up or rounding down DECIMALS, hence the 1 beat off in some tracks.
This is my understanding…i could be wrong
I too had noticed this story but I thought I was crazy. 
When I imported a bunch of songs into the collection at the same time, they were all analyzed one after the other. Then when I went to check them one by one to put the hot cues or to check the grid, in some I found the wrong grid and/or wrong bpm. At that point I right-clicked on the track and clicked on “re-analyze track”: at that point many times the grid and bpm calculations got right.
Now that you’ve written this thing, I feel more relieved. 
That sounds like prime is using INT for one calculation but allowing decimals in subsequent calculations. That sound like there’s two pieces of code being used internally.
Yes.
If track contains BPM information during import EP uses that when you click Analyse
If you feel it’s incorrect then use Reanalyse
If you prefer EP BPMs algorithm then Reanalyse all new tracks after import, don’t use Analyse.
Yea I don’t know how to write code but thanks for the detailed explanation. Sounds like you should have the software coding job not whoever wrote the first one.
Hey I’m sure they’re fantastic engineers! Bugs slip through in code all the time, it’s part of the process! I only hope for a speedy fix!