DigDeeper · experiments›all projects

Rekordbox bridge — the folder is the library

A test rig for the Rekordbox integration, run entirely in the browser. The question it answers: how few times does a DJ have to do anything for us to import their collection and keep it in sync. Answer: once. One XML export names the folders and the crates; after that the music folder alone carries the audio, the tags and — through file size and modified date — everything needed to spot what changed. No agent to install, and no second export.

Nothing leaves this page. No upload, no server call, no analytics — the folder, the tags and the audio are read, measured and thrown away in the tab. The only thing stored is the folder handle plus a size/date fingerprint per file, in this browser's IndexedDB. That storage is what makes the rescan in step 1 a real sync test instead of a mock-up.

1The XMLonce, and never again

Export it once: in Rekordbox, File → Export Collection in xml format. This is the only manual step in the whole flow, and it is a one-off — not something to repeat whenever the library changes. It buys two things: the exact folders your music lives in, which is how step 2 knows what to ask for, and the crates and ratings, which no folder on disk can tell us.

Drop rekordbox.xml here — or click to choose

2The folderthe sync source, from here on

The paths from step 1 appear below — drag that folder in, and from then on this is the only source. The page keeps the handle, fingerprints every file by size and modified date, and Rescan reports exactly what a sync run would touch. No second export, ever.

Drag your music folder here from Finder or Explorer

no path to type, no dialog to navigate

Skipped step 1? Then pick the folder yourself — the dialog opens in your Music folder. Folders add up rather than replace, so a library split over an internal drive and an SSD just needs each one dropped in turn.

3The tagsis folder-only enough?

Without the XML, everything known about a track before analysing it comes out of the file's own tags — ID3 in MP3 and AIFF, Vorbis comments in FLAC, atoms in M4A. This coverage is the number that decides the design: it is all the catalogue match has to work with, and it is what says how many files need analysing at all.

files to read

4The transcodewhat an upload weighs

The analyser eats 16 kHz mono. So the browser decodes the file, resamples it (OfflineAudioContext) and encodes Opus (WebCodecs) — which is what would actually go over the wire. Measured per track: decode time, encode time, bytes out.

tracks to test kbps

5What a real run costs

Extrapolated from the measurements above. The share already in the catalogue is the biggest lever — those tracks are never uploaded, so the metadata match has to run before any transcoding.

already in DigDeeper % parallel workers

—run the benchmark

Caveats, so the numbers are read right

Only Chromium can remember the folder. showDirectoryPicker does not exist in Safari or Firefox, so those fall back to a plain folder chooser that cannot be stored — no rescan, and a re-pick on every visit. The capability row at the top says what this browser has.
Rescan sees changes, not moves. A file renamed or moved inside the folder reads as one removal plus one addition. Fine for costing a sync run, wrong if per-track state has to survive — that needs a content-based fingerprint, not size and date.
Tag coverage is the whole folder-only bet. Thin artist and title tags mean a thin catalogue match and more files to analyse. Read enough files for the number to mean something — the default 300 is a sample, not a census.
A music folder is not a library. It can hold samples, unfinished rips, a partner's music, and duplicates the DJ deleted from Rekordbox years ago. The XML is the only thing that states the real boundary, which is worth knowing before treating every file on disk as part of someone's collection.
Decode times are this machine's, on these files, with nothing else running. A DJ's laptop mid-set is not this machine. Treat the extrapolation as a floor.
Folder Type is inverted between the two Rekordbox sources. In the XML a NODE of Type=0 is a folder and Type=1 a playlist; in master.db, djmdPlaylist.Attribute reads 0 = playlist, 1 = folder. An easy way to build the tree upside down.

Released as /rekordbox-bridge/ in digdeeper-experiments. No network calls. Clear site data to make it forget the folder.