Beatgrid is shifted when syncing back to Rekordbox6

When I sync my Lexicon Playlist, after adding hot cues and changing the beatgrid on some tracks, it changes the beatgrid on the playlist in rekordbox. Is there anyway to fix this issue? All track in playlist are MP3’s.

Here are two screenshots of what the same track looks like in rekordbox vs lexicon. I will also try to attach the mp3 file


Thanks for providing the file, I can confirm I’m seeing the same ~21ms shift to the right on that file.

The cause of this (called beatshift) is prevalent across most MP3 files and is a result of how different Applications interact with different MP3 encoding types/versions. Lexicon already accounts for and corrects beatshift across most application/encoding combinations but there is still some that we haven’t worked out a good way to detect and correct.

Christiaan will need to review this and he’s not around much for the next two weeks due to a vacation but I’ll pop the debugging info in here for him to review when he’s available.

Summary

Track: 95 - Pascal Junior - Overdose
BeatshiftCase: D
Recorded RB Shift ~21ms right
Encoder: Lavf56.30.100
LAME3.99r

Full Probe Output:

ffprobe version 3.4.2 Copyright (c) 2007-2018 the FFmpeg developers
  built with gcc 7.3.0 (GCC)
  configuration: --disable-static --enable-shared --enable-gpl --enable-version3 --enable-sdl2 --enable-bzlib --enable-fontconfig --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libtheora --enable-libtwolame --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libzimg --enable-lzma --enable-zlib --enable-gmp --enable-libvidstab --enable-libvorbis --enable-libvo-amrwbenc --enable-libmysofa --enable-libspeex --enable-libxvid --enable-libmfx --enable-cuda --enable-cuvid --enable-d3d11va --enable-nvenc --enable-dxva2 --enable-avisynth
  libavutil      55. 78.100 / 55. 78.100
  libavcodec     57.107.100 / 57.107.100
  libavformat    57. 83.100 / 57. 83.100
  libavdevice    57. 10.100 / 57. 10.100
  libavfilter     6.107.100 /  6.107.100
  libswscale      4.  8.100 /  4.  8.100
  libswresample   2.  9.100 /  2.  9.100
  libpostproc    54.  7.100 / 54.  7.100
Input #0, mp3, from 'MP3infotest/95 - Pascal Junior - Overdose.mp3':
  Metadata:
    title           : Overdose
    encoder         : Lavf56.30.100
    track           : 1/1
    disc            : 1
    artist          : Pascal Junior
    album           : Overdose
    album_artist    : Pascal Junior
    publisher       : Epic Tones Records
    comment         : GBKQU1592275
    date            : 2019-08-16
  Duration: 00:05:54.14, start: 0.011995, bitrate: 132 kb/s
    Stream #0:0: Audio: mp3, 44100 Hz, stereo, s16p, 128 kb/s
    Metadata:
      encoder         : LAME3.99r
    Side data:
      replaygain: track gain - -3.100000, track peak - unknown, album gain - unknown, album peak - unknown, 
    Stream #0:1: Video: mjpeg, yuvj444p(pc, bt470bg/unknown/unknown), 640x640 [SAR 37:37 DAR 1:1], 90k tbr, 90k tbn, 90k tbc
    Metadata:
      comment         : Other

I couldn’t find any track in my collection that has this same combination of both Lavf56.30.100 & LAME3.99r which might be what is tripping up the detection.

I individually tested tracks with just Lavf56.30.100 and it got BeatshiftCase B, while a pure LAME3.99r track gets case D, both of those sync correctly.

Makes me think this track should be a B, but is getting mislabeled as a D because of the existence of the LAME3.99r encoder tag.

Thank you. If it helps, I download all my tracks using -

I ran a -15ms shift in all my tracks through lexicon which was super helpful. Its nice to know that I need to add another -6ms to get them all to -21.

Thank you!

I’ve added an extra rule for specifically these tracks, next Lexicon update should export these properly to Rekordbox