The Cue Sheet Is the Mix: Rebuilding 1,100 Track Marks From a Bad Export

A friend handed me a 6-hour recording of a festival set, exported from a DJ app that shall remain unnamed, plus a CSV of cue points. Version matters here: the app’s export wrote times as mm:ss:ff where ff was hundredths, not frames, and the CSV header said frames. 1,100 cue points across 6 hours, and every mark after the first hour landed early by a growing amount. The recording itself was fine; only the map was wrong.

The symptom is easy to miss because the start of the set looks correct. If you check the first few transitions by ear, they line up. Then around 1:04:00 the marks drift, and by the last hour every cue is several seconds ahead of the actual drop. My first guess was a sample-rate mismatch. It wasn’t. I opened the CSV in a text editor and did the arithmetic on one row:

00:59:30:00 -> 00:59:30.00?  or 00:59:30.00 as 30 frames = 30/30 s

Once I treated the third field as hundredths and rebuilt the timestamps, the drift vanished. The parsing was the bug, not the audio.

What I actually did, in order:

# 1. Preserve the original export untouched
cp cues.csv cues.csv.bak

# 2. Convert mm:ss:ff (ff = hundredths) to seconds
awk -F: '{ printf "%.2f\n", ($1*60)+$2+($3/100) }' cues.csv > cues_sec.txt

# 3. Cross-check against the recording length
ffprobe -v error -show_entries format=duration -of csv=p=0 set.flac

Then I used those corrected seconds to split the recording into per-track chunks with ffmpeg -ss <start> -to <end> -c copy, keeping the codec untouched so nothing was re-encoded. 1,100 marks collapsed to about 140 actual tracks; the rest were loop points and hot cues, which is why the count looked wrong at first. I kept the hot cues in a separate file rather than deleting them, because they’re useful if anyone wants to reconstruct the transitions.

The tradeoff: -c copy cuts on keyframe boundaries, so a few splits start a fraction late. For a listening archive that’s fine. If you need sample-accurate edits, you have to re-encode, and then you’re paying in generation loss. I chose speed and fidelity to the source over exact cut points, and documented that choice in the README next to the files.

Where this fails: the hundredths assumption only holds for this app’s export. Another tool wrote ff as actual frames at 25 fps, and the same script produced marks that were consistently late. I now check one known transition by ear before trusting any bulk conversion. Also, if the CSV has mixed formats from different sessions, a single awk pass will silently mangle half the rows. I got lucky that this export was internally consistent.

What I’d like to know: when you inherit someone else’s cue sheet, do you verify against a known landmark first, or do you convert in bulk and fix the outliers after? I’ve done both, and the second one has burned me more than once.