CDJ 1000MK3 SD Card File Format Info - rdingwall/cdjmerge GitHub Wiki

Disclaimer: all this information has been reverse-engineered using a CDJ-1000 MK3, a CD-RW, SD card reader, a hex editor, and a lot of patience. Note I have only used MP3 files for my investigations so far (still need to investigate differences with WAV and CD audio). This is an early work in progress and probably contains mistakes.

Overview

The CDJ-1000 MK3 persists the following data on SD cards:

  • cue points (timestamps in a track)
  • wave data (a waveform displayed on the CDJ)
  • loop data (loops within a track)

Physical SD card format

The CDJ-1000 MK3 cannot use SD cards formatted by Windows, nor even the SD Association's official SD Formatter 3.0 tool. In my tests, I had to format them using a Canon digital camera before I was able to store cue points.

Location

CDJ data is stored in a PIONEER\MPJ\ directory on the SD card. (Presumably this is unique to the CDJ-1000 MK3 and not used by other Pioneer DJ devices with SD card support).

File structure

Tracks are stored in an index file (presumably for quickly identifying discs without needing to crawl files) and a entry file for each track.

Index file: MPJINDX0.PDJ

Header

The index file begins with a 16 bytes header, common in all my tests (only tested with MP3 files so far). Represented as an ASCII string, it looks like:

PIONEER INDX....MP3 ..

The 'MP3' string at the end suggests this may be a header/divider between MP3, CD Audio and WAV tracks (?).

Entries

Each entry in the index represents a single track (? todo - can't remember if it is disc-based, or track-based). Each entry is stored as:

  • the filename where cue points, loop points and wave display data is stored for that track as ASCII text (without .PDJ extension or path) e.g. MPJ00001
  • 14 bytes unique track identifier

Todo: What's the max number of discs supported in the index?

Unique track identifier

This is likely either:

  • some sort of hash based on the track's entry in the CD audio table of contents (ToC) (akin to how CDDB identifies CDs)
  • some sort of hash based the physical offset of the track start and/or frame count/data length
  • some sort of CD media/track identifier?
  • a combination of the above, depending on whether it is a Red Book audio CD or CD-ROM with WAV/MP3 tracks

These details are not important for CDJ Merge yet -- we have no plans to generate new IDs/identify discs, only merge entries in existing CDJ data files.

(Todo: if the same track appears on two CDs with different neighbouring tracks, does the CDJ still recognize it, or is its ID contextual and requires the same parent CD?)

Track files: MPJ0xxxx.PDJ

Each track in the index is represented as:

  • 2 byte separator (nul nul)
  • 8 bytes ASCII string - file name without .PDJ file extension or path (same as appears in the index)
  • 14 bytes data (?)
  • ASCII string DISC (or track?)
  • 24 bytes common header (?)
  • 14 bytes unique track identifier (same as appears in the index)
  • ? bytes cue points/wave data/loop points in some order (with some delimiter or fixed data positions)
  • checksum

Todo: What's the max number of cue points/loop points per track?

Checksum

Like any good file format, CDJ disc entries appear to contain a checksum at the end. It appears as

  • 4 bytes, ASCII string CSUM
  • 8 byte right-aligned checksum (?)

Todo: figure out what type of checksum is used (probably something simple/quick as embedded hardware)

Units used for cue points/loop points

The CDJ-1000 MK3 is advertised as supporting 1/75 sec audio frame resolution. This is likely based on the Red Book audio standard, which stores audio CD data in sectors of 2352 bytes each, read at 75 sectors per second.

During early CDJ development, CD audio was likely the only supported audio format, as the first CDJs probably didn't support MP3 or WAV tracks yet. So, when playing audio CDS, the CDJ would simply use the CD's physical sectors as its frame size without any need for remapping to some different block size.

Thus it is likely cue points and loop data are expressed as a 1/75 second frame address.