So the BPM is actually wrong in Engine? That would cause the desync.
The BPM is 103.19 in LXC, for both markers? And then in Engine it is 101.65 for both markers?
Not quite, The BPM is correct for the final marker in engine DJ. All other markers have their BPM changed to a value that lands a beat exactly on the new beatmarker - although it’s not the nearest value. Notice that in Lexicon 72 bars pass until the new marker is set, in engine it’s 75. Really strange. In LXC, all markers have the correct tempo, in Engine DJ, only the last has the correct tempo.
Engine has a weird way internally how they set up their markers so maybe there is something wrong there. It also depends on the correct bitrate so if that is wrong in LXC, then the grid will be off.
Can you check if the bitrate in LXC is the same in Engine and also in the file properties?
Then I will need your library (upload from the Help menu) and the file itself, so I can test it here.
I uploaded my database. If you look for Testa/multimarker, you will find a couple of files that exhibit the problem. It’s worth noting, that so far for me all files with multiple markers had this problem to varying degrees. I’m also currently uploading those files along with the exported engine database.
The bitrates in LXC and file properties match, I was suprised to not find a way to view the bitrate via Engine DJ. However, once the bpm is set correctly on the last marker, all tracks are in sync from there.
Thanks, I will take a look this weekend
1 Like
I’ve corrected this. On your Macarena track it now goes from 103.2 BPM to 103.1 BPM then back to 103.2. There is a minor difference there that I can’t quite explain, maybe the beat marker isn’t exactly on point. But the minor difference becomes 0.1 BPM due to rounding.
Thanks a lot. 0.1 seems negligible. I’ll test with my other tracks tomorrow or so so and let you know.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.
Revisiting this problem as it turns out that my fix here caused grids to lock on Denon devices.
Now that I’m looking into it further, my thought is that Engine can’t handle partial beats at all.
For example, I have a DNB track of 174 BPM. It starts at 174 and then I add a second marker in Engine with 87 BPM. Then a third marker (not on the beat but between beats) at 174 BPM again.
Now my 87 BPM marker has turned into 86.93 BPM.
Lower BPM means that the time between beats is greater so what Engine did here was adjust the BPM so there is no “gap” of half a beat anymore. Which is totally wrong to do because now your BPM is wrong and you can’t change it (greyed out).
So the fix I put out for this is getting reverted because it breaks other things. And as for this issue… I don’t know if there is a fix for it since Engine doesn’t seem to support partial beats.
What do you mean by “partial beats”?
Is it 1-2-3-4-2-3-4-1-2-3-4
Try adding a beat marker on beat 4.5 and look at the BPM of both markers. The first marker should get a reduced BPM
Isn’t this more an interpretation thing? You could either view this issue as "a new marker will always land on a “1”, if it doesn’t, the previous beat marker is adjusted (I think Engine and Serato (?) do this, and it allows to sync tracks determistically; or you could view it as “a new marker just opens a new count”, which causes problems in auto sync (but the solution I prefer since I’m not syncing).
Engine does the former, I believe, that’s why I had the problem that adding new markers in lexicon changed the bpm of the marker at the very beginning of the song.
Edit: It’s also why my workaround of adding an extra marker exactly one bar before the tempo change works: Then the shift explicitly happens between the “helper” marker and the “true” marker. I though I described that on the forums already, but I seem to be wrong.
I’m not sure how the beat sync behaves in both cases, but I think this is the way Engine does it so it’s something we have to accept unless Engine changes it. Maybe it just means the slightly incorrect BPM is not a big deal, just an annoyance.
As I said, I don’t think either option is wrong, it’s just to ways to represent a shift in tempo. I’m fine with placing explicit helper markers in lexicon, so this matter is sufficiently addressed for me, but we should keep in mind that this is something that users might stumble over.
I have double-checked how engine does it in detail. It simply edits the BPM of the previous marker to fit to a full beat. I wonder whether that has to do with my crash issue? if there are some weird internals here, It might be worth a shot for lexicon to automatically add a beatmarker exactly 4 beats (according to the old grid) in front of a new marker. This way it is assured that this ghost-marker lands absolutely perfectly on a “One” of the old grid, and then engine can do it’s weird marker manipulation in peace. Just a thought
That was the fix that was in place, although with 1 beat. But that caused grids on Denon devices to always be locked, I guess Engine didn’t like something in those grids.
It could be done with 4 beats but you’d get 4 beats with a different BPM and I think that gives a higher chance of weird beat sync issues.
Let’s leave it like this for now, makes it easier to address other issues too.
I’m absolutely fine with leaving being like this, as long as the crash is fixed 
Just to possibly save you trouble: it seemed to me that engine always works with the nearest downbeat (“One”) not with the nearest beat (4 in this case), so the problem might possibly come from exactly that. It makes sense from a Denon perspective even, if the “ghost” marker that LXC sets does not have the correct bpm to sync up to the next full bar. Just a thought.
Edit: The crash that happens with flexible beatgrids sometimes:
Does that crash still happen in the latest version? With a clean USB, just to make sure it has the latest grids.
I wasn’t able to reproduce it earlier, but if we can reproduce it now then I can look into it again
Alright, I did some in depth testing. No crashes, but the wrong bpm is used for previous marker again (as expected).
I’m having a 100% success rate at mitigating this by placing a beat marker 4 beats before the tempo change. Actually, there is no problem with desync for the following reason: After the export the following happens:
1st marker has original BPM
2nd marker that was placed with original bpm has it’s bpm adjusted to something that syncs up with the 3d marker
3rd marker has the correct bpm.
I’m pretty sure that the problem here is that engine treats every marker as a downbeat marker, and engine hat to like quadruple the speed (400%!) to put four beats between the ghost marker and the next marker. In fact, if I recreate that manually, the resulting beatgrids on engine are broken after the ghost upon export.
Interestingly, this is different when using engine to place the markers. Engine does treat them as beatmarkers there, not downbeat markers.
well, whatever. The “set ghost marker manually in advance” seems to work, so why not use it. Maybe I’ll try reimporting beatgrids from engine tonight and see what weirdness comes from that 
1 Like