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.