Rekordbox XML Is Killing Your Library

The export that erases your work, and why the fix requires going under the hood.

You've been there. You spent two hours tagging a new batch of tracks — energy levels, key, color codes, comments, all of it. Hit export. Loaded the USB. Half your comments are gone. Two BPMs are wrong. A third of your tracks lost their custom ratings. And the worst part: you have no idea when it happened or how to get it back. This isn't a bug. It's a design constraint that's been baked into the rekordbox XML workflow for over a decade. What XML actually does to your tags rekordbox stores an extraordinary amount of metadata: track ratings, color codes, cue point names, playlist hierarchy, comment fields, analysis data like waveform position and beatgrid offsets, and the full history of your preparation activity. When you export to XML, rekordbox makes a choice about what to include. It doesn't export everything.

It exports a view — a flattened, lossy serialization of a subset of your library state. Fields that don't fit the XML schema get silently dropped. Fields that do fit get mangled: Unicode characters in comments become escape sequences, custom rating scales get normalized to a different range, and timestamp fields lose millisecond precision. You don't see it happen. rekordbox loads the XML on the other side and everything looks fine — until you start digging and realize half your prep work vanished somewhere in the translation. The core problem XML is a serialization format, not a database. Every export is a snapshot — not a sync. And snapshots lose writes that happen between the export and the re-import.

The round-trip tax The typical DJ workflow involves at least one XML round-trip per session: export from rekordbox, open in a third-party tool, make changes, export back, re-import into rekordbox. Each round-trip compounds the loss. Comment fields get truncated. Custom cue metadata gets normalized. Energy and danceability ratings — if they're even in the XML at all — get reset. For most DJs, this means either living with the loss or doing meticulous re-tagging after every import. Neither is a reasonable workflow. The software is supposed to serve the DJ, not the other way around. Why the .db file is the answer rekordbox stores everything — every field, every cue, every rating — in a SQLite database called . This is the source of truth. The XML export is just a conveniently formatted excerpt.

Reading and writing the database directly means working at the same level of fidelity as rekordbox itself. No lossy translation. No silent drops. Every field is preserved because you're reading the same data structure the DJ software reads. The complication: the database is encrypted. Pioneer DJ uses SQLCipher to protect the library data, which means a direct read requires understanding the encryption schema — and that part takes some engineering to get right. What Bonk! does differently Bonk! reads the master.db directly via pyrekordbox (a vendored Python bridge that handles the SQLCipher decryption) and writes changes back with the same fidelity. When you update a track's energy score or add a chapter marker, it lands in the database in the exact format rekordbox expects — no XML serialization in between.

The write path is atomic: changes are applied in a transaction and committed only on success. If the process is interrupted — power loss, crash, bad file — the database remains consistent. No partial writes. No corruption. For DJs who want to run audio analysis on their library, Bonk! doesn't require uploading anything anywhere. All feature extraction runs locally: BPM via aubio, key detection via keyfinder-cli (same algorithm Mixxx uses), and energy/danceability via VibeNet — a locally-run ML model. Your library never leaves your machine. The local-first constraint Cloud-first DJ tools have an inherent tension: your library is your most valuable asset, and yet you have to trust a third party to hold it intact. Cloud services can lose data, change terms, get acquired, or simply go offline.

A local-first workflow means your library is always accessible — on a plane, in a venue with poor wifi, or five years from now on whatever hardware you're using then. Bonk! is built on this constraint by default. There is no cloud component. There is no account. There is no sync service. Your library, your machine, your edits. The XML workflow is a workaround for a problem that didn't need to exist. As the DJ software ecosystem evolves, the tools that respect the integrity of your library — and your time — will win. Direct database access isn't a niche technical detail. It's the foundation of everything else.