# USB書き出しは何に触れるのか：Bake'n Deckとrbxportを同じUSBで計測

**rekordbox自身の書き出しを使わずにCDJ用のUSBを作る方法は、いま2つあります。**1つはrekordboxが外に出すもの、つまり書き出したコレクションのXMLと解析ファイルを読む方法で、Bake'n Deckはこちらです。もう1つはrekordboxのライブラリのデータベース`master.db`を直接開く方法で、[rbxport](https://github.com/chrisle/rbxport)はこちらです。rbxportは自らを「rekordboxに着想を得た音楽ライブラリ管理アプリ」と説明し、rekordboxのライブラリをその場で編集します。

Bake'n Deckは前者の考え方で作り、どのページでもそう書いてきました。主張ではなく計測で示すため、同じrekordboxのプレイリストを2つのツールで同じUSBスティックに書き出しました。すべての実行の時間を測り、USB以外で変わったファイルをすべて記録しています。

## 計測の条件

- **マシン：**MacBook Air 13インチ（M3、24 GB）、macOS 27.0.1、電源接続。どちらのツールもテスト用に新しく作ったmacOSのユーザーで動かし、普段使っているrekordboxのライブラリには届かないようにしました。
- **USBスティック：**SanDisk USB 3.2 Gen 1、61.5 GB、MBRのFAT32。再書き出し以外の回は毎回空にしてから書き出しました。
- **ライブラリ：**テスト用ユーザーのrekordbox 7.2.18に、実際に使っているDJライブラリから200曲（9.0 GB）をコピーして読み込み、解析し、200曲すべてを1つのプレイリストに入れました。形式はそのライブラリのとおりで、FLAC 91曲（16/24ビット、44.1/48 kHz）、AIFF 82曲、MP3 16曲、M4A 10曲、WAV 1曲です。M4Aのうち4曲は壊れたファイルだと分かり、これも結果の一部になりました。
- **Bake'n Deck：**Bake'n Deck for Mac 1.4.0と同じエンジンであるコマンドライン版の`baken expressport` 4.8.0で、rekordboxが書き出したコレクションのXMLを読みました。変換にはHomebrewのffmpeg 9.0.2を使いました。Mac版は独自にビルドしたffmpegを同梱しています。
- **rbxport：**1.9.0を既定の設定（Library Protectionオン）で使い、書き出しが終わると戻るrbxport自身のAppleScriptの`export`コマンドで動かしました。rbxportはOneLibraryとDevice Libraryの両方を必ず書くので、Bake'n Deckも`--onelibrary`付きで書き出しました。
- **回数：**各シナリオ3回です。どちらのツールを先に動かすかは回ごとに入れ替え、実行の間に45秒の休みを入れました。変換の回の前には毎回rbxportの変換キャッシュを消し、すべての変換をキャッシュなしで測りました。
- **監査：**各実行の前後に、rekordboxのライブラリのフォルダ（`master.db`と解析ファイル）、rekordboxの設定フォルダ、200曲の音楽ファイルのSHA-256を取りました。テスト用ユーザーのホームフォルダで変わったファイルもすべて一覧にしました。

計測に使ったスクリプトと生データは[GitHubで公開しています](https://github.com/M-Igashi/baken/tree/main/bench)。

## 速度

3回の中央値で、かっこ内は範囲です。時間はコマンドを実行してから、ツールが書き出しの完了を返すまでです。

| シナリオ | Bake'n Deck | rbxport |
| --- | --- | --- |
| 空のUSBへ全曲を書き出す | **818.6秒**（735.1〜821.8）、197曲、9.68 GB | 959.5秒（955.5〜1071.9）、200曲、9.71 GB |
| 全曲書き出しのCPU時間 | 4.8秒 | 32.5秒 |
| 直後の再書き出し（変更なし） | 3.6秒（2.8〜3.6） | **0.6秒**（0.6〜0.6） |
| 古い機種向けの変換つきで空のUSBへ | **382.7秒**（365.1〜415.8）：188曲を320 kbpsのMP3に変換、MP3 9曲をコピー、2.68 GB | 1913.3秒（1899.3〜1916.4）：97曲を320 kbpsのMP3に変換、99曲をそのままコピー、6.52 GB |
| 変換の回のCPU時間 | 638.6秒 | 1093.9秒 |

- **全曲の書き出しは、ほとんどがUSBへの書き込み待ちです。**どちらも約9.7 GBをUSBに書く時間が大半で、速度はBake'n Deckが毎秒11.8 MB、rbxportが毎秒10.1 MBでした。Bake'n Deckは141秒（15%）早く終わり、CPU時間は約7分の1でした。rbxportは3曲多く書き（後述）、データベースのファイルも1つ多く書くので（`exportExt.pdb`）、合計で約37 MB多くなります。
- **再書き出しはrbxportが速いです。**変更がないとき、rbxportは0.6秒で「Already up to date」を返しました。Bake'n Deckも音声は1曲もコピーし直しませんでしたが、2つのデータベース（`export.pdb`とOneLibrary）を書き直して3.6秒かかりました。
- **差は、前回の書き出しの記録を持つかどうかです。**rbxportは記録（`PIONEER/rbxport/manifest.json`）をUSBに残します。中身は依頼内容のダイジェストと、元のファイルとUSBに書いた全ファイルのサイズと更新日時です。これがすべて一致すると何も作らずに終わるので、変更のない再書き出しはほぼファイルの情報を読むだけで済みます。rbxport自身の[USB書き出しの解説](https://github.com/chrisle/rbxport/blob/main/docs/reference/usb-export-pipeline.md)にそう書かれていて、サイズと日時だけでは中身が同じとは言い切れないため、ファイルを読んで確かめる「Verify all files」も用意されています。Bake'n DeckはUSBにもほかの場所にも記録を残しません。毎回、各曲の音声の先頭、中央、末尾と解析ファイルをUSB上のものと読み比べ、同じものは書きませんが、`export.pdb`とOneLibraryは毎回作り直し、USBへの書き込みを終えてから古いものと置き換えます。3.6秒のうちCPU時間は約0.3秒で、残りはUSBの読み書きを待つ時間でした。
- **変換の回は2つのツールで仕事の量が違います。**Bake'n DeckのCDJセーフは、条件どおりのMP3でない曲をAIFFやWAVも含めてすべて320 kbps CBRのMP3にします。rbxportのMaximum CDJ compatibilityはMP3を選ぶと、互換性がないと判断した曲（今回はFLACとM4A）だけを変換し、MP3、AIFF、WAVはそのままコピーします。Bake'n Deckはほぼ2倍の曲を変換しながら、複数のCPUコアを同時に使って5分の1の時間で終えました。USBの中身もすべてMP3なので2.68 GBで、rbxportの6.52 GBより小さくなります。

## USB以外に書いたもの

|  | Bake'n Deck | rbxport |
| --- | --- | --- |
| `master.db` | 一度も開きません。ソースコードにも参照がありません | 開きます。初回起動で横に`master.db-wal`（0バイト）と`master.db-shm`（32 KB）を作り、終了後も残ります |
| 9回の書き出し中の`master.db`の中身 | 変化なし | 変化なし |
| rekordboxの解析ファイルと設定 | 変化なし | 変化なし |
| 200曲の音楽ファイル | 変化なし | 変化なし |
| ホームフォルダのそのほかの場所 | なし | 自身の記録を`~/Library/Application Support/rbxport`に書きます。全曲の書き出しで362ファイル、変換の回で約590ファイル（変換キャッシュ） |

既定のLibrary Protectionがオンのままなので、rbxportは書き出し中にrekordboxのデータベースを変更しませんでした。これが計測の結果で、そのとおりに報告します。残る違いは2つの方式そのものです。rbxportはrekordboxの暗号化されたデータベースを開き、Library Protectionをオフにするとそこに書き込みます。曲の編集や、USBからキュー、ビートグリッド、再生履歴、レーティングをライブラリに取り込むImportがそうで、rbxport自身のドキュメントにも書かれています。Bake'n Deckは保護の有無にかかわらず、そのデータベースを開くことがありません。開く必要がないからです。

## 壊れたファイル

実際に使っているライブラリは、きれいとは限りません。サンプルのM4Aのうち3曲は途中で切れていて（`moov`アトムがなく、どのソフトでも再生できません）、もう1曲は普通に開けるものの音声データが壊れていて、ffmpegではノイズとしてデコードされます。

|  | Bake'n Deck | rbxport |
| --- | --- | --- |
| 途中で切れたM4A 3曲、全曲の書き出し | 1曲ずつ警告して外す | USBにコピー |
| 途中で切れたM4A 3曲、変換 | 1曲ずつ警告して外す | 失敗として報告 |
| 音声データが壊れたAAC、全曲の書き出し | そのままコピー | そのままコピー |
| 音声データが壊れたAAC、変換 | **警告なしでノイズに変換（不具合、修正済み）** | 失敗として報告 |

**この計測で見つかったBake'n Deckの不具合。**CDJセーフは壊れたファイルをffmpegに渡し、ffmpegはそれをノイズとしてデコードして1,667件のデコードエラーを記録しながら、正常に終了しました。Bake'n Deckはその終了コードを信じて、変換できた曲として数えていました。できたMP3は平均-9.5 dBで334秒のノイズで（元の曲は373秒）、CDJで再生すればブースに大きなノイズが流れます。rbxportは同じファイルを失敗として報告しました。見つけた日に修正し、baken 4.10.0からはffmpegが10件を超えるデコードエラーを報告した変換を失敗として扱い、その曲を理由とともに表示して外します（[#299](https://github.com/M-Igashi/baken/pull/299)）。Bake'n Deck for Mac 1.4.1にもこの修正が入っています。

## 計測から言えること

- ライブラリをrekordboxのものにしておき、書き込むのはrekordboxだけにしたいなら、Bake'n Deckはそのために作っています。rekordboxが書き出したXMLを読み、`master.db`は開きません。
- 今回のマシンとUSBでは、全曲の書き出しはBake'n Deckが15%速く、古い機種向けの変換は約5倍速く終わりました。変更のないUSBへの再書き出しは、rbxportが6倍速く終わりました。
- rbxportは既定の保護のまま、これらの書き出しの間データベースに触れませんでした。Bake'n Deckが4.10.0まで見逃していた壊れたファイルも、正しく失敗として扱いました。

## この計測の限界

マシン1台、USB1本、200曲のサンプル1つで、各3回の計測です。今回はUSBを実機で再生していません。Bake'n Deckが書いたUSBは、これまでにCDJ-3000とCDJ-2000NXS2で読めることを確かめています。Bake'n Deckはコマンドライン版で計測しましたが、Mac版と同じエンジンです。メモリ使用量は、一方が画面のあるデスクトップアプリで、もう一方がコマンドラインなので比べていません。rbxportは1.9.0での計測で、更新の速いソフトです。同じスクリプトで誰でも計測し直せます。

2026年11月5日と6日に計測。rbxportの動作の出典は、2026年11月5日に読んだ[README](https://github.com/chrisle/rbxport)、USB書き出しとAppleScriptのガイド、リリースノートです。rekordbox、CDJ、Pioneer DJはAlphaTheta株式会社の商標です。rbxportはその所有者の商標です。

## Bake'n DeckのUSB EXPORT

Bake'n Deck for MacはMac App Storeで配信中です。rekordboxが書き出したXMLから、rekordbox自身の解析データごとUSBに書き込み、HEADROOMとSORTも同じプレイリストにかけられます。コマンドライン版のbakenはMITライセンスで無料です。

[Mac App Storeでダウンロード](https://apps.apple.com/app/baken-deck/id6808813823)

[rekordboxを開かずにUSBに書き出す方法](https://baken.ravers.workers.dev/ja/usb-export) →

## 関連ガイド

- [rekordboxのAuto GainがCDJに届かない理由](https://baken.ravers.workers.dev/ja/auto-gain): 数値がどこで止まるのか、ゲインをファイルに焼き込むと何が変わるのか。
- [DJのラウドネスノーマライズ：LUFSの目標値か、True Peakの天井か](https://baken.ravers.workers.dev/ja/loudness-normalization): ファイルの中で音量をそろえる2つの方法。それぞれが変えるもの、DJに残すもの、rekordboxのAuto Gainの位置づけ。
- [rekordboxのプレイリストをKey + BPM順に並べる方法](https://baken.ravers.workers.dev/ja/sort): Key順（1A→12B）、同じKeyの中はBPM順。並びをプレイリスト自体に書き込むので、CDJもその順で再生します。
- [rekordboxを開かずにプレイリストをCDJ用のUSBに書き出す方法](https://baken.ravers.workers.dev/ja/usb-export): CDJがUSBから読むもの、bakenがcollection.xmlから書き出す仕組み、rekordbox 7のライブラリ不整合の警告。
- [HeadroomはラウドネスとTrue Peakをどう測っているか（Zenn）](https://zenn.dev/jphfa/articles/baken-in-process-bs1770-measurement): ffmpeg loudnormをやめ、プロセス内でBS.1770-4を計算。1ファイルあたり15倍速く、1,036曲を20秒で解析。一致性の検証値つき。
- [DJアプリでApple Music Understandingを使う（英語）](https://baken.ravers.workers.dev/music-understanding): Swiftのコード、100曲でのrekordboxとのBPM・Key比較、paceをエナジーに、ボーカル判定、速度、つまずいた点。macOS 27。

---

Source: https://baken.ravers.workers.dev/ja/usb-export-measured