Incorrect Waveform Loading & Playback

Please fill in this bug report template:

Lexicon version: 1.3.9
Operating system (remove one): Windows

Bug description: Loading and playing a song sometimes creates a stuttered playback near the beginning of the song which shows up in the waveform but the same file loaded into both Engine Prime 3.0.0 and Rekordbox 6.6.11 do not exhibit the same behavior.

Step by step to reproduce:

  1. Load track (it seems to happen more often with tracks that have a kick/snare intro with little other instruments.)
  2. Play the track, usually within the first 8 measures/bars this problem occurs. You will see the waveform is incorrect and the playback is also incorrect. In the screenshots it’s just prior to measure/bar 5.




So I’ve done some additional troubleshooting. I restarted Lexicon and the issue resolved itself with the track’s I’ve noted this behavior. However, after using it for a while, I saw the same behavior come back. A restart, once again seems to resolve the issue. This seems to be a stability issue, as I am in the process of cueing and tagging many files in my collection - I am flying through loading tracks, skipping through them as I set the cue points and add my tags.

I’ll update here if I can get some consistent timing on when it occurs post-restart.

Check if this happens during “track loading” which is when you still see the waveform getting built up. That is when the CPU is busy reading the track and generating the waveform. Once the top overview waveform is 100% done, there is no more CPU usage going on.

This is definitely an issue on mac and there are some specific fixes in there for the mac, but maybe I have to add those fixes for Windows too.

Cool, thank you for replying. It does seems to be during the waveform build process. I’ve also noted it tends to lose about 3 measures/bars. I haven’t been tracking the consistency of that specifically, but I’ve found I can go about 90 minutes before I need to restart. I checked on my CPU utilization and I don’t think I’m running into a contention/wait condition, but I can check more judiciously.

Possibly of note, I do sometimes see multiple lexicon processes running (which in and of itself isn’t necessarily surprising) but I have seen some lag (minutes) in some of those processes post shutdown using the “X” to close, as opposed to the “Lexicon → Quit Lexicon” options.

Using the X to close will keep Lexicon active in the tray (next to your clock). That is so you can keep listening to music while it is closed.

Quitting Lexicon will shut it down entirely.

What do you mean when you lose 3 bars?
I have a report from another user where the music rarely skips a few seconds (could be 3 bars, don’t know) at the start of the track so maybe this is related. That’s something that definitely needs to be fixed though.

So, when I see the problem with the display/playback, it appears to be doing this.

  1. It starts loading the song left-to-right. When the issue occurs, it seems that it stops processing the waveform at an arbitrary point.
  2. As the waveform continues to load, it then seems to pickup from where it stopped about 3 bars later and continues loading the rest of the waveform as if it were a contiguous load (which it is not.)

I was able to determine this when I was loading a song that had an easily identifiable transient every other measure for only 16 bars. By looking for that specific transient (and know that section should only contain 8 instances of it, I was able to count the transients and was missing two of them, but where the break happened I had two next to each other (which never happens if loaded correctly.) I then just counted the measures from the beginning to the change in phrase when that transient stop and found I was a bit more than 2.75 short, but not exactly. That’s how I came up with the “about 3 measures/bars.”

I also know this song very well and knew the beat grid was off from the proper transients but had the correct bpm. That’s generally when I look for the problem.)

Does that happen at roughly 4 seconds into the track?

I think it should always happen in the first 10 seconds of the track, that is the first segment being loaded

Always within the first 10 seconds.

And it seems to be about 4 or so seconds in most cases. I’ll pay more attention to that timing.

It was definitely about 4 seconds in in the last case.

The other user had 4 seconds too. Maybe coincidence or maybe something for me to go on

I’ll keep a closer eye on that timing.

1 Like

OK, it’s not consistently four seconds.

In the image below, the play head is at the point where the transient should NOT be, and it’s within the first two seconds ( just did some stopwatch timing and am coming consistently within 1.5 to 1.9 sec):

In this image, it’s the same song (from the same loading the song.) The play head is where the red cue to the right of the play head should be (about 17.5 beats later than it should be.) All cues are exhibiting the same shift.

Don’t know if this helps, but just in case…

I’ve been tracking the CPU and disk utilization of all the Lexicon processes and I don’t see anything concerning - periodic spikes to the capacity of the core the process is running on but no hangs at 100%, but, to be fair, I am limited in sample rate to 1 second polls.

Is this problem consistently happening for all your tracks or just a small number?

I can make a special build for you with the same fixes that Mac has, let’s see if that helps on Windows too

It seems to appear after I’ve been working in it for about 60-90 minutes. When I exit and re-load the same track, it’ll load correctly, so it isn’t track-specific.

I’m happy to try out a fix, as I am working through about 4000 songs right now.

Try this version please

Downloaded and installed, thank you! Will report back.

The problem remains. It was about an hour in, I processed 17 tracks ahead of this occuring, no CPU or other resource contention. Play head is at the skip point.

Can you try this build?

And once you notice it, please make a screenshot and upload logs right away, so I know the last track in the logs had the issue.

This build just has more logging so I can track down where to look, since I can’t reproduce it here :confused:

Will do. I’ve been really busy with work, but I should be able to restart testing later today.

1 Like