Lexicon version: 1.1.4 Operating system: Windows / Mac (Both)
Bug description:
Several of my tracks with multiple beatmarkers export badly to engine dj. Only the last beatmarker is actually in sync. The others start in sync, but then quickly run out of sync. This is especially pronounced if the new beatmarker does not fall on a 1 of the previous marker. What appears to be the case is the following: The new Beatmarker in lexicon just starts a new grid wherever it is dropped (even if the previous grid only counted to two or three until then). Afer export to engine DJ, the grid of the previous marker seems to be shifted so that the new beatmarker lands on a 1, which obviously causes the track to desync over time. I can upload examples if that helps (I made a test playlist) but that probably won’t be of much help without the database I guess?
Update: The tracks in question used 2-3 beatmarkers.
Finally got to it. I noticed the Problem already appears in ENgine DJ Desktop, no need to switch to a player.
I’ll be using our favorite controversial wedding track, Macarena.The track starts with an offbeat count, but once the beat comes in, it’s perfectly on time in LXC
Towards the end, there’s a minor pause, and the track kicks back in with a slight delay. Tempo stays the same though, still 103.19 BPM. A new beatmarker is dropped on the “One”
The desync ends up landing a beat marker perfectly. However the downbeat is shifted one beat to the left. However, the new marker is set and the tempo is correct. The beat stays in sync for the remainder of the track
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.
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.
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.
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.
