The Night My Cue Sheet Disagreed With the Waveform

Last spring I was prepping a 74-minute ambient set for a small room with a borrowed CDJ setup. I had ripped the tracks myself from FLAC, converted to 320 kbps MP3 for the USB stick (the club’s players were old enough that I didn’t trust FLAC), and built a cue sheet in a plain text file. Then I loaded everything into mixxx to check the markers before exporting. The cues were all off by roughly 40–90 ms depending on the track. Not enough to hear as a gap, but enough that every transition felt slightly late when I nudged them live.

I had generated the cue times from ffmpeg’s silencedetect against the WAV before encoding. That was the mistake. MP3 encoding adds encoder delay and padding. LAME writes the delay into the LAME tag, but not every decoder honors it, and silencedetect on the decoded MP3 reported different timestamps than the WAV. I confirmed it by decoding back and comparing:

ffmpeg -i track.wav -af silencedetect=noise=-45dB:d=0.4 -f null -
ffmpeg -i track.mp3 -af silencedetect=noise=-45dB:d=0.4 -f null -

The MP3 pass reported starts 0.04–0.09 s later. On a track with a soft attack that’s the difference between a clean blend and a clipped first beat.

My fix was boring. I kept two files per track: the MP3 for playback and the original WAV as the source of truth for markers. In mixxx I set the cue points against the WAV, exported the cue sheet, then remapped the times to the MP3 by subtracting the measured delay. To measure it, I looped the first 200 ms of a 1 kHz tone through the same encoder settings and cross-correlated with sox:

sox tone.wav -n stat
sox tone.mp3 -n stat

The offset was consistently around 0.026 s of encoder delay for that LAME build, plus a few ms of padding at the tail. Not huge, but if you chain 30 cues across a set it accumulates into a half-second of drift relative to what you planned.

The reason this matters is not audiophile anxiety. It’s that cue points are a contract between what you heard when you placed them and what the player does later. Any lossy re-encode breaks that contract unless you account for it. The cost is keeping the WAVs around, which is disk space I’d rather spend elsewhere, and re-measuring every time I change encoder settings.

Where this falls apart: tracks with no silence at the start, or with a fade-in that starts below -45 dB, get no reliable marker from silencedetect at all. I had two of those and ended up placing cues by hand in audacity, zooming to the sample. Also, if the CDJ firmware ignores the LAME tag (some older ones do), the delay is real at playback and my remap is wrong in the other direction. I only caught that because one player in the booth was a different model than the other. I don’t have a clean way to detect it without listening.

What I’d like to know: how do you handle cue drift when the same track exists as WAV for editing and MP3 for the stick? Do you measure per encoder build, or just place cues by ear on the playback file and trust that?