Bake'n Deck (baken)

What you prep in rekordbox is what plays on the deck.

rekordbox does three things in software that never survive the trip to a CDJ. Bake'n Deck bakes each one into the files themselves:

Subcommand	The gap it fills	What it does
baken headroom	Auto Gain is ignored on USB export	Measures LUFS / True Peak and bakes safe gain into the audio file — no limiter, dynamics preserved, cues stay linked
baken rbsort	No compound Key+BPM sort in rekordbox	Sorts every playlist by Camelot Key (1A→12B) then BPM inside your exported XML — CDJs play it in that exact order
baken cdjsafe	Pre-NXS2 CDJs only play MP3 reliably	Transcodes a whole playlist to 320 kbps CBR MP3 with cues and beatgrid carried over — the emergency-backup USB
baken expressport	Exporting to USB means launching rekordbox and waiting	Writes the stick directly from collection.xml: device library, analysis files, audio, My Settings (beta since v3.5.0)

🌐 baken.ravers.workers.dev — full docs, workflow guides, and FAQ.

Bake'n Deck for Mac

Bake'n Deck for Mac is the native app edition, on the Mac App Store. The same baken-core engine and the same numbers, in a window: Headroom for a whole folder or for a single rekordbox playlist, with a review table and audio preview; a sorted-order preview before Sort writes anything; a CDJ Safe pre-flight check; per-run timestamped backups with one-click restore; and Mac Tune-up for the macOS settings that slow rekordbox down. One-time purchase, no subscription, no account, no network access. English and Japanese, macOS 14 or later, Apple silicon and Intel.

The baken command line stays free and MIT-licensed on macOS, Windows and Linux, and always will.

If rekordbox is slow on your Mac, the five macOS settings behind most of it are written up in docs/mac-tuneup.md, with the manual steps (日本語版). No tool required, and nothing to buy.

Installation

The Mac app bundles its own ffmpeg, so there is nothing else to install. The command line requires ffmpeg; package managers install it automatically.

Platform	Command
macOS (Homebrew)	brew install M-Igashi/tap/baken
Windows (winget)	winget install M-Igashi.baken
Arch Linux (AUR)	yay -S baken-bin
Cargo	cargo install baken (ffmpeg must be installed separately)

Pre-built binaries are available on the Releases page (ffmpeg must be installed separately). To build from source: git clone https://github.com/M-Igashi/baken.git && cd baken && cargo build --release.

The processing logic is a separate library crate, baken-core, so other front-ends can embed it without the terminal UI.

Quick Start

baken headroom ~/Music/DJ-Tracks                # analyze & bake loudness gain (interactive)
baken rbsort collection.xml                     # sort every playlist by Key+BPM, in place
baken cdjsafe collection.xml --playlist "Sets/Friday" --out-dir ~/Music/cdjsafe

Run baken --help or baken <subcommand> --help for the full reference.

Note

Renamed from headroom at v3.0.0 (#60). The old headroom install channels (brew/winget/cargo/AUR) no longer receive updates — reinstall via the baken packages above. The loudness analyzer now lives under the baken headroom subcommand.

Highlights

• Single binary — mp3rgain built in; only ffmpeg required (and rbsort doesn't even need that)
• Truly lossless MP3/AAC gain — global_gain header modification in 1.5 dB steps, no re-encode
• Uniform True Peak ceiling — every track lands at -0.5 dBTP by default (AES TD1008 §7B): quiet tracks are raised, loud ones lowered. Tunable via --tp-target, or --boost-only to never turn anything down
• Non-destructive — automatic backups; rbsort/cdjsafe only ever touch an exported XML, never your rekordbox library
• Metadata preserved — files overwritten in place and every tag carried across verbatim, so rekordbox cues, hot cues, and beatgrids stay linked
• Interactive or scriptable — guided two-stage confirmation, or flags/globs for pipelines and CI

Loudness Normalizer (baken headroom)

How It Works

1. Scans the target directory for audio files (FLAC, AIFF, WAV, MP3, AAC/M4A, ALAC/M4A)
2. Measures LUFS (Integrated Loudness) and True Peak per ITU-R BS.1770-4, decoding in-process (ffmpeg is used for files the built-in decoder cannot open)
3. Computes the gain that puts each file's True Peak at the ceiling (-0.5 dBTP by default). Quiet files get a positive gain, loud files a negative one; --boost-only restricts this to positive gains.
4. Categorizes files by processing method:
   • Green: Lossless files (ffmpeg)
   • Yellow: MP3/AAC files with enough headroom for native lossless gain
   • MP3/AAC files already within one 1.5 dB step of the ceiling are left alone: nothing is re-encoded to move a file by less than a step
5. Displays categorized report
6. Confirmation: "Apply lossless gain adjustment?" (lossless + native MP3/AAC)
7. Creates backups and processes files

Example

Full interactive session (28 files analyzed → 8 processed)

$ cd ~/Music/DJ-Tracks
$ baken headroom

╭─────────────────────────────────────╮
│            baken v3.0.1             │
│   Bake'n Deck — CDJ Prep Toolkit    │
╰─────────────────────────────────────╯

▸ Target directory: /Users/xxx/Music/DJ-Tracks

✓ Found 28 audio files
✓ Analyzed 28 files

● 3 lossless files (ffmpeg, precise gain)
  Filename        LUFS    True Peak    Target        Gain
  track01.flac   -13.3    -3.2 dBTP   -0.5 dBTP   +2.7 dB
  track02.aif    -14.1    -4.5 dBTP   -0.5 dBTP   +4.0 dB
  track03.wav    -12.5    -2.8 dBTP   -0.5 dBTP   +2.3 dB

● 3 MP3 files (native lossless, 1.5 dB steps)
  Filename        LUFS    True Peak    Target        Gain
  track04.mp3    -14.0    -5.5 dBTP   -0.5 dBTP   +4.5 dB
  track05.mp3    -13.5    -6.0 dBTP   -0.5 dBTP   +4.5 dB
  track11.mp3     -6.8     0.3 dBTP   -0.5 dBTP   -1.5 dB

● 2 AAC/M4A files (native lossless, 1.5 dB steps)
  Filename        LUFS    True Peak    Target        Gain
  track08.m4a    -13.0    -4.0 dBTP   -0.5 dBTP   +3.0 dB
  track09.m4a    -12.5    -4.5 dBTP   -0.5 dBTP   +3.0 dB

▸ TP target: -0.5 dBTP (uniform delivery ceiling, AES TD1008 §7B)
▸ Gain mode: normalize (raise quiet files, lower loud ones)

✓ Report saved: ./baken_report_20250109_123456.csv

? Apply lossless gain adjustment to 3 lossless + 3 MP3 (lossless gain) + 2 AAC/M4A (lossless gain) files? [y/N] y

? Create backup before processing? [Y/n] y
✓ Backup directory: ./backup

✓ Done! 8 files processed.
  • 3 lossless files (ffmpeg)
  • 3 MP3 files (native, lossless)
  • 2 AAC/M4A files (native, lossless)

Usage

Interactive Mode

Run baken headroom without further arguments to use the guided workflow in the current directory:

cd ~/Music/DJ-Tracks
baken headroom

The tool will guide you through:

1. Scanning and analyzing all audio files
2. Reviewing the categorized report
3. Confirming lossless processing
4. Creating backups (recommended)

Scriptable Mode

Pass paths, globs, or flags to run non-interactively (useful for pipelines and scripts):

# Analyze a directory without modifying anything
baken headroom --analyze-only ~/Music/DJ-Tracks

# Apply only lossless gain, with backup, save report to a specific path
baken headroom --lossless --backup ./bak --report results.csv ./album/

# Operate on specific files
baken headroom --lossless track1.mp3 track2.flac

# Glob patterns
baken headroom --lossless --no-report "./music/**/*.mp3"

# Tighter ceiling for streaming-platform delivery (Spotify / Apple / YouTube max)
baken headroom --lossless --tp-target -1.0 ./album/

# Restore the legacy bitrate-dependent split (pre-v1.10 behaviour)
baken headroom --lossless --tp-split-bitrate ./album/

# Only raise quiet tracks, never lower loud ones (pre-v3.3 behaviour)
baken headroom --lossless --boost-only ./album/

Non-interactive defaults (when any flag or path is provided):

• --lossless is on unless --no-lossless
• --reencode and --no-reencode are accepted for compatibility and do nothing: no file is re-encoded for gain
• --backup is off unless provided; bare --backup uses <target>/backup
• CSV report is written unless --no-report; --report PATH sets a custom location
• --analyze-only runs analysis + report only, skips processing
• --boost-only skips files above the ceiling instead of lowering them

Run baken headroom --help for the full flag reference.

Processing Methods

baken selects the optimal method for each file based on format and headroom:

Format	Method	Precision	Quality Loss
FLAC, AIFF, WAV	ffmpeg	Arbitrary	None
MP3, AAC/M4A	mp3rgain (built-in)	1.5dB steps	None (global_gain modification)
ALAC/M4A	ffmpeg (re-encoded as ALAC)	Arbitrary	None (lossless codec)

A lossy file closer to the ceiling than one 1.5 dB step is left alone rather than re-encoded, so no MP3 or AAC ever loses a generation to a gain change.

Lossless files are written back in their original sample format — a 16-bit AIFF stays 16-bit, a 32-bit float WAV stays 32-bit float — so file size does not grow and float masters are not truncated. FLAC is the one partial exception: ffmpeg's FLAC encoder only accepts 16- and 24-bit output, so an 8-bit FLAC becomes 16-bit and a 20-bit FLAC becomes 24-bit.

Raising and Lowering

The gain for each file is ceiling − measured True Peak. Files below the ceiling get a positive gain, files above it (loudness-war masters, inter-sample overs from lossy encoding) get a negative one, so every track ends up at the same True Peak with no limiter involved. Pass --boost-only to keep the pre-v3.3 behaviour of raising quiet files only and leaving loud files untouched.

Two-Tier Approach for Lossy Formats (MP3/AAC)

Each MP3 and AAC/M4A file is categorized into one of two tiers:

1. Native Lossless — the gain is at least one 1.5 dB step in either direction

   • Truly lossless global_gain header modification in 1.5dB steps
   • Uses built-in mp3rgain library
   • Raising rounds down to whole steps (never overshoots the ceiling); lowering rounds up (the result never exceeds the ceiling, e.g. TP +0.3 dBTP → -1.5 dB → -1.2 dBTP)
   • Applied automatically (no user confirmation needed)

2. Skip — True Peak within 0.05 dB of the ceiling; a lossy file less than one 1.5 dB step below it; or above the ceiling with --boost-only

   • A raise smaller than one step could only be applied by re-encoding, and a lossy generation to move a file already within 1.5 dB of the ceiling is not a trade worth making
   • It is also exactly where every lossy file lands after a native step, since lowering rounds up. Re-encoding there meant offering a third of a processed library up for another lossy generation on every later run (#138)
   • Lowering never re-encodes either: small overshoots take one full native step instead

True Peak Ceiling

Default — uniform delivery target

Every file targets -0.5 dBTP by default. This is the maximum-aggression value that AES TD1008 §7B describes for high-rate codec inputs ("may work satisfactorily with as little as -0.5 dBTP for the limiting threshold").

File class	Ceiling	Native lossless raise requires
Lossless (FLAC, AIFF, WAV)	-0.5 dBTP	—
MP3 (any bitrate)	-0.5 dBTP	TP ≤ -2.0 dBTP (any TP above the ceiling is lowered natively)
AAC/M4A (any bitrate)	-0.5 dBTP	TP ≤ -2.0 dBTP (any TP above the ceiling is lowered natively)

Why a single ceiling — pre-encode vs delivery

TD1008 has two related but distinct numbers:

1. Generic delivery recommendation (§4) — "Maximum True Peak level not exceed -1 dBTP at the codec input of lossy-encoded streams." This is the pre-encode limiter threshold.
2. High-rate codec relaxation (§7B) — "High-rate (e.g., 256 kbps) coders may work satisfactorily with as little as -0.5 dBTP" — also a codec-input threshold; "the limiting threshold may need to be reduced below the recommended -1.0 dBTP" for lower bit rates.

Both bullets describe the limiter that sits in front of the encoder. baken operates in the opposite position: on already-encoded delivery files. There is no further codec stage downstream to absorb additional overshoot, so the bitrate-dependent slack TD1008 grants the pre-encode limiter does not transfer to the end product. A single, codec-agnostic delivery ceiling is the correct interpretation. -0.5 dBTP is chosen because it is the most aggressive value TD1008 sanctions for any limiter in the chain; lossless and high-rate lossy files were already at -0.5, and low-rate files now stop giving up an unnecessary 0.5 dB of loudness.

See docs/true-peak-ceiling.md for a longer walk-through with citations.

Tuning the ceiling

Goal	Flag	Resulting ceiling
Default (max-aggressive delivery)	(none)	-0.5 dBTP for all files
Match Spotify / Apple Music / YouTube delivery max	--tp-target -1.0	-1.0 dBTP for all files
Conservative master with extra player headroom	--tp-target -2.0	-2.0 dBTP for all files
Mirror TD1008's pre-encode interpretation	--tp-split-bitrate	-0.5 dBTP ≥256 kbps, -1.0 dBTP <256 kbps

--tp-target and --tp-split-bitrate are mutually exclusive. --tp-split-bitrate reproduces the pre-1.10 default exactly.

The native-lossless raise threshold scales with the chosen ceiling: it is always target − 1.5 dB (e.g. -0.5 → TP ≤ -2.0; -1.0 → TP ≤ -2.5; -2.0 → TP ≤ -3.5). Files above the ceiling are always lowered natively.

Output

CSV Report

Filename	Format	Bitrate (kbps)	LUFS	True Peak (dBTP)	Target (dBTP)	Headroom (dB)	Method	Effective Gain (dB)
track01.flac	Lossless	-	-13.3	-3.2	-0.5	+2.7	ffmpeg	+2.7
track04.mp3	MP3	320	-14.0	-5.5	-0.5	+5.0	mp3rgain	+4.5
track06.mp3	MP3	320	-12.0	-1.5	-0.5	+1.0	none	0.0
track08.m4a	AAC	256	-13.0	-4.0	-0.5	+3.5	native	+3.0
track10.m4a	AAC	256	-12.5	-1.2	-0.5	+0.7	none	0.0

Backup Structure

./
├── track01.flac             ← Modified
├── track04.mp3              ← Modified
├── track08.m4a              ← Modified
├── subfolder/
│   └── track06.mp3          ← Modified
└── backup/                  ← Created by baken
    ├── track01.flac         ← Original
    ├── track04.mp3          ← Original
    ├── track08.m4a          ← Original
    └── subfolder/
        └── track06.mp3      ← Original

Notes & Technical Details

• Files are overwritten in place after backup — rekordbox metadata remains linked
• Tags survive the rewrite: MP3/AAC native gain never rewrites the container, and where ffmpeg does (the lossless formats) the source's raw tags are put back over the output byte for byte. That covers the payloads DJ software writes and ffmpeg has nowhere to put: ID3v2 GEOB/PRIV frames on MP3, AIFF and WAV, and free-form ---- atoms on ALAC and AAC in .m4a (#117)
• Only files whose True Peak is more than 0.05 dB away from the ceiling are shown and processed
• MP3/AAC native lossless raising requires at least 1.5dB headroom; lowering always uses whole native steps
• MP3/AAC files closer to the ceiling than one step are left alone; nothing is re-encoded for gain
• macOS resource fork files (._*) are automatically ignored

Why 1.5dB Steps?

Both MP3 and AAC store a "global_gain" value as an integer. Each ±1 increment changes the gain by 2^(1/4) = ±1.5 dB. This is a format-level constraint, not a tool limitation.

baken uses the built-in mp3rgain library to directly modify this field — no decoding or re-encoding involved.

Native Lossless Threshold

Since native lossless gain only works in 1.5 dB steps, raising a file requires at least 1.5 dB of headroom to the configured target ceiling. The threshold scales automatically:

Target	Requires TP ≤
-0.5 dBTP (default)	-2.0 dBTP
-1.0 dBTP (--tp-target -1.0)	-2.5 dBTP
-2.0 dBTP (--tp-target -2.0)	-3.5 dBTP

Example: 320 kbps file at -3.5 dBTP, default target → 2 steps (+3.0 dB) → -0.5 dBTP (optimal).

Lowering has no such threshold: a file at +0.3 dBTP takes one step down (-1.5 dB) and lands at -1.2 dBTP, slightly under the ceiling rather than re-encoded to hit it exactly.

Why files under the threshold are left alone

A lossy file within one step of the ceiling can only be moved by re-encoding it, and that costs a generation of quality to gain less than 1.5 dB. It is also where every file ends up after a native step, so re-encoding there would mean re-encoding a large part of the library again on every later run. Both directions therefore stop at whole steps, and a run over a library that has already been processed finds nothing left to do.

rekordbox Playlist Sorter (baken rbsort)

rekordbox does not expose a "sort by Key AND BPM" option in its UI. baken rbsort takes an exported rekordbox XML and rewrites every playlist in it so its tracks run Camelot Key (1A → 12B) ascending then BPM ascending. Playlists keep their names and folder positions; only the track order inside each one changes. rekordbox reads the sorted file back as its rekordbox xml tree, so you end up with a Key+BPM-sorted mirror of your Playlists sitting next to the originals.

This is the same idea as baken headroom applied to playlist order: rekordbox's software-only features (Auto Gain, multi-column sort) don't follow your tracks to the CDJ. rbsort bakes Key+BPM order into the playlist itself — so when you export to USB in rekordbox's EXPORT mode, the CDJ plays the set in that exact order with no on-deck reordering.

Step-by-step, with the sort rules, a comparison against single-column sort and the questions people ask: How to sort a rekordbox playlist by key and BPM (日本語).

Workflow

1. Set key display to Alphanumeric (1A..12B notation) in rekordbox: Preferences > View > Key display format > Alphanumeric.
2. Export: File > Export Collection in xml format. Always save to the same path, e.g. ~/Music/rekordbox/collection.xml.
3. Run rbsort on that file. It is sorted in place:

   baken rbsort ~/Music/rekordbox/collection.xml
   
   # Only one playlist (top-level: just the name; nested: "Folder/Playlist")
   baken rbsort ~/Music/rekordbox/collection.xml --playlist "Sets/Friday"
   
   # Keep the export untouched and write elsewhere
   baken rbsort ~/Music/rekordbox/collection.xml -o ~/Music/rekordbox/sorted.xml

4. One-time setup: Preferences > Advanced > Database > rekordbox xml > Imported Library → select that same file.
5. Restart rekordbox (it only re-reads the XML on startup) and open the rekordbox xml tree in the left sidebar. It is a separate tree from your main library — switch to it from the sidebar icon column on the far left. It mirrors your Playlists folder structure, every playlist already in Key+BPM order: 1A (lowest BPM) → 1B → 2A → … → 12B (highest BPM).
6. Use it: drag any playlist from the rekordbox xml tree into your main Playlists (it lands as a new playlist; your original is unchanged), switch to EXPORT mode, plug in your USB / SD, then right-click the playlist → Export Playlist. CDJs read tracks in playlist order by default — your Key+BPM sort plays back on the deck in that exact order.

Keeping it in sync: whenever your playlists change, repeat steps 2, 3 and the restart. The file path never changes, so the Imported Library setting keeps pointing at the freshly sorted export and the rekordbox xml tree stays an always-sorted copy of your library.

The sorted playlists live only in the rekordbox xml tree, not in your main Playlists. If you only see unsorted originals, you're looking at the local library — switch sidebar trees.

Usage

baken rbsort <XML> [--playlist <PATH>] [-o <PATH>]

Argument / Flag	Description
<XML>	Exported rekordbox XML (required). Sorted in place unless --output is given; the file is replaced in one step (temp file + rename), so an interrupted run never leaves a truncated XML
--playlist <PATH>	Sort only this playlist. Top-level playlists: just the name (e.g. "Happy House and Trance"). Nested: /-separate folder/playlist names (e.g. "Folder/SubFolder/MyPlaylist"). Omitted: every TrackID-referenced playlist is sorted
--output <PATH> (-o)	Write the result here instead of overwriting the input XML

Sort Rules

• Primary: Camelot Key ascending — 1A → 1B → 2A → 2B → … → 12A → 12B
• Secondary: BPM ascending within each key group
• Tracks with no Camelot key sort after all known keys; within a key group, tracks with BPM 0 / unanalyzed sort last

See docs/rbsort-sort-comparison.md for a 6-track walk-through showing how this compound sort differs from rekordbox / CDJ's single-column Sort by Key and Sort by BPM. The same walk-through, with the workflow around it, is at baken.ravers.workers.dev/sort.

Notes

• Requires the Tonality field to be exported as 1A..12B (rekordbox's "Alphanumeric" key display format). Non-matching values (e.g. Am, C#) are silently sorted last.
• Only KeyType="0" (TrackID-referenced) playlists are sorted. In all-playlists mode, other playlists pass through unchanged; for a single target, rbsort errors out.
• Only the order of <TRACK Key="…"/> references changes. Playlist names, folder structure, Count/Entries attributes, whitespace and everything else in the XML are preserved byte-for-byte, so running rbsort twice on the same file is a no-op.
• baken rbsort does not require ffmpeg — only the headroom and cdjsafe subcommands do.

CDJ-safe Transcoder (baken cdjsafe)

Added in v3.0.0. Design discussion: #40.

Pre-NXS2 CDJs (CDJ-2000NXS, CDJ-2000, CDJ-900NXS, CDJ-850, …) have inconsistent or absent support for anything that isn't MP3: FLAC needs an NXS2 (2016+), and ALAC/AIFF/WAV/AAC fail on specific firmware combinations — sometimes mid-set. baken cdjsafe is the emergency-backup path: it takes a gig playlist and produces a USB-ready set of files that will play on any CDJ, with your cues and beatgrid intact.

baken cdjsafe ~/Music/rekordbox/collection.xml \
  --playlist "Sets/Friday" \
  --out-dir ~/Music/cdjsafe-friday

What it does

1. Reads the target playlist from your exported collection.xml.

2. Converts every track whose file exists to the CDJ-safe profile. Tracks whose files are missing on disk, or whose Location is not a decodable file:// URL (a hand-edited row), are listed as skipped with the reason and left out (the emergency stick still gets everything that is there); only a playlist with nothing reachable at all is an error. Profile: — 320 kbps CBR MP3 @ 44.1 kHz, ID3v2.3 tags, artwork kept (JPEG, capped at 500×500):

   Source	Action
   FLAC, WAV, AIFF, ALAC	Re-encode
   AAC/M4A (any bitrate)	Re-encode
   MP3 not exactly 320 kbps CBR @ 44.1 kHz	Re-encode (lossy→lossy, reported)
   MP3 already 320 kbps CBR @ 44.1 kHz	Byte-identical copy (no generation loss, LAME header untouched)

3. Emits an updated XML (default: <input>-out.xml) where each converted track is a new entry with a fresh TrackID that inherits the source's beatgrid (TEMPO) and hot/memory cues (POSITION_MARK) verbatim, grouped in a CDJ-safe (MP3)/<playlist>-CDJ-safe folder. The -CDJ-safe suffix keeps the imported playlist from colliding with the original. New entries get a [cdjsafe] marker appended to their Comments so they're distinguishable after import.

4. Reports every lossy→lossy re-encode so you can refresh those tracks from lossless masters before the next gig.

If any track fails to convert, no XML is written — a partial USB defeats the point. The XML is written through a temp file and a rename, so an interrupted run never leaves a truncated file either. The same applies if the collection XML changed while the transcodes ran (a rekordbox export made mid-run): the MP3s already converted are kept and the command tells you to re-run, which only copies them.

Importing back into rekordbox

1. Preferences > Advanced > Database > rekordbox xml > Imported Library → select the output XML, restart rekordbox.
2. Open the rekordbox xml sidebar tree → CDJ-safe (MP3)/<playlist>-CDJ-safe.
3. Right-click the imported tracks → Import to Collection. Cues and beatgrid come with them — no re-analysis needed.
4. Export the playlist to USB in EXPORT mode as usual.

Usage

baken cdjsafe <XML> --playlist <PATH> --out-dir <DIR> [-o <PATH>]

Argument / Flag	Description
<XML>	Exported rekordbox XML (required)
--playlist <PATH>	Playlist to convert (required). Top-level: just the name; nested: Folder/Playlist
--out-dir <DIR>	Directory for the MP3 files (required; created if missing)
--output <PATH> (-o)	Output XML path. Defaults to <input-stem>-out.<ext> next to the input

Notes

• The output profile is locked (320 kbps CBR / 44.1 kHz / ID3v2.3) — it's the only combination that plays reliably across the whole CDJ fleet, and CBR sidesteps rekordbox's VBR cue-offset problem.
• ffmpeg writes a valid Xing/LAME header, so rekordbox compensates the LAME encoder delay and cues stay sample-aligned.
• Filenames are FAT32/exFAT-sanitized; collisions get a numeric suffix.
• Requires ffmpeg (with libmp3lame; soxr resampling is used when available).

Direct USB Export (baken expressport) — beta

Added in v3.5.0 as a beta. The implementation is complete (design record: #115) and byte-checked against real rekordbox exports, and a CDJ-2000NXS2 has read a first stick written by baken. What would end the beta, and how to help with a stick and a player, is in #116. Use a spare stick.

expressport writes the USB stick itself, straight from your exported collection.xml: the device library (export.pdb), the analysis files (PIONEER/USBANLZ), the audio under Contents/, and your CDJ/DJM My Settings. No rekordbox launch, no re-import, no waiting for analysis. rekordbox's own database is never read.

baken expressport ~/Music/rekordbox/collection.xml --device /Volumes/MYUSB --playlist "Sets/Friday" --playlist "Sets/Warmup"

How it works

• Title, artist, BPM, key, colour, rating, playlists, beat grid and cues all come from the XML.
• Waveforms are copied, not computed: every track should have been analysed in rekordbox once, and its .DAT/.EXT/.2EX files are copied from rekordbox's local analysis cache (~/Library/Pioneer/rekordbox/share/PIONEER/USBANLZ, or PIONEER/Master/share/PIONEER/USBANLZ on a library drive). On the way the path is rewritten, the cue sections are filled from the XML and the phrase analysis is masked exactly as rekordbox does at export time. Tracks with no analysis are listed and left out.
• --generate-analysis computes the analysis files from the audio instead, for tracks rekordbox has never seen (a Mixxx or Traktor library converted to collection.xml, or a machine without rekordbox). The beat grid and the cues come from the XML as always, so a track whose XML has no TEMPO gets no beat grid (the plan says how many; the player then detects the BPM while playing, and quantize and beat sync cannot use it); the waveforms are decoded and measured by baken (#147). The scrolling waveform reproduces rekordbox's own to the pixel on the tracks it was checked against; the colour, three-band and preview waveforms are close approximations. Phrase analysis cannot be generated and is left out. Tracks that do have a rekordbox analysis are still copied, because copying is exact.
• Audio is copied only when missing or of a different size, so re-running after a playlist change is quick. export.pdb is rebuilt every run.
• The My Settings files MYSETTING.DAT, MYSETTING2.DAT and DJMMYSETTING.DAT are copied from rekordbox's settings directory into PIONEER/ on the stick (not its root; that is where rekordbox puts them too) and are required unless --no-settings is given, which writes none so the player keeps its own settings (what a DJ without rekordbox usually wants from a club's CDJs). rekordbox writes them once Preferences > DJ System > My Settings has been opened, a page that only exists in EXPORT mode. DEVSETTING.DAT is copied too when it is there; players write their own, and a real rekordbox 7 export does not always carry it.
• --cdjsafe transcodes every track to 320 kbps CBR MP3 on the way and ships it with the source track's analysis, for pre-NXS2 players.

Usage

baken expressport <XML> --device <DIR> [--playlist <PATH>]... [--anlz-dir <DIR>]... [--settings-dir <DIR> | --no-settings] [--device-name <NAME>] [--generate-analysis] [--cdjsafe] [--prune] [--dry-run]

Flag	Description
--device <DIR>	Root of the stick (required)
--playlist <PATH>	Playlist to export; repeatable. Omitted: every TrackID-referenced playlist
--anlz-dir <DIR>	rekordbox analysis directory when auto-detection fails
--settings-dir <DIR>	Directory holding the *SETTING.DAT files (default: rekordbox's own)
--no-settings	Write no My Settings; the player keeps its own settings
--device-name <NAME>	Name shown on the player (default: the stick's directory name)
--generate-analysis	Compute the analysis files from the audio for tracks with no rekordbox analysis (grid and cues still from the XML; no phrase data)
--cdjsafe	320 kbps CBR MP3 for every track (needs ffmpeg)
--prune	Delete audio and analysis on the stick this export no longer references
--dry-run	Resolve and report, write nothing

Notes

• A rekordbox install is normally required, on the same machine or on an attached library drive: the waveforms and the My Settings files are copied from rekordbox's own. A collection.xml produced by another tool (Mixxx, Traktor, a converter) needs --generate-analysis for the waveforms (see #145 and #147) and either --settings-dir pointing at the *SETTING.DAT files from any stick rekordbox once exported, or --no-settings; nothing in the XML can stand in for the settings.
• Built into the binaries; cargo install baken --no-default-features leaves it out.
• Legacy device library only (export.pdb): CDJ-3000, CDJ-2000NXS2, XDJ-XZ and older. Players that need OneLibrary (exportLibrary.db: CDJ-3000X, XDJ-AZ, OPUS-QUAD, OMNIS-DUO) are not supported yet.
• Format the stick as FAT32 with an MBR partition table. A CDJ-2000NXS2 or older reads neither exFAT nor a GPT disk and does not show such a stick at all; a CDJ-3000 also reads exFAT.
• Use a stick dedicated to expressport; it is not meant to be layered over a stick rekordbox wrote. Files players leave behind (PIONEER/CDJ, RBFLTR.DAT, ...) are never touched.
• Check a finished stick on a player, not by opening it in rekordbox: rekordbox rewrites a device library it opens, and even changes a stick that is only mounted while it runs. rbsync measured it deleting 768 of 5,825 playlist entries from a stick it opened and adding an exportLibrary.db. If that happened, run expressport again (it rewrites export.pdb) and delete PIONEER/rekordbox/exportLibrary.db.
• On macOS 26, which mounts ExFAT and FAT sticks through FSKit, the files on the stick keep the NFC names rekordbox puts in export.pdb, and Terminal's rm cannot remove files under such names (#154); Finder and --prune can.
• Artwork is not exported yet.

License

MIT