USB書き出しは何に触れるのか：Bake'n Deckとrbxportを同じ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で公開しています。

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

• 全曲の書き出しは、ほとんどが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書き出しの解説にそう書かれていて、サイズと日時だけでは中身が同じとは言い切れないため、ファイルを読んで確かめる「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より小さくなります。

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

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

この計測で見つかった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）。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、USB書き出しとAppleScriptのガイド、リリースノートです。rekordbox、CDJ、Pioneer DJはAlphaTheta株式会社の商標です。rbxportはその所有者の商標です。