MP3 のタグをデータベースに入れる前に、実データで全部調べた話 ― 62 項目のフィールドと、列の決め方

家の NAS にためている MP3 を管理するデータベースを作っています。表を設計する前に、まず今の MP3 のタグに、実際に何が入っているかを調べました。規格の上では入れられる項目がたくさんありますが、実データを見ると「使われていない項目」「規格外の値」「ソフトごとの独自データ」がいろいろ出てきます。その調べ方と、そこから決めたデータベースの列の考え方をまとめます。まだ決まっていないことも、そのまま書いています。

ジャンルの分け方は前の記事にまとめたので、今回はジャンル以外のタグの話です。

全体の考え方

• よく使う項目（曲名・アーティスト・アルバム・ジャンル・日付・BPM など）は、曲の表（tracks）の列にする
• それ以外の項目は、予備の列を用意せず「追加情報の表」（track_extra_tags）に1項目1行で入れる
• 1曲に複数のアーティストがいる曲は、対応の表（track_artists）で分けて持つ
• 元の値は加工せずに残す。画像はデータベースに入れない

1. 調べ方

Python の mutagen（MP3 などのタグを読み書きするライブラリ）で、NAS の MP3 のタグを読み出しました。

• 抜き取り：6つのフォルダから最大300曲ずつ、計1,441曲。タグの元の形（フレームの種類・文字コード）まで記録
• 集計：抜き取りに2つのフォルダの全曲を足した9,993曲（全体の約7％）
• 速さ：家の中のネットワークで1曲約0.09秒。300曲で約28秒、今の全曲で約3.6時間の見積もり

結果は Excel にまとめました。62項目について、出現率・実際の値の形・最大文字数・値の例・規格（ID3 のバージョン・形式・文字コード）と、データベースの列の案を並べています。

2. タグを調べて分かったこと

分かったこと	内容
バージョンが混在	ID3v2.3（日本語は UTF-16）と ID3v2.4（UTF-8）が混ざっていて、フォルダの中でもばらばら
日付の形が違う	v2.3 は年（TYER）と日月（TDAT）が別々、v2.4 は TDRC 1つ。2022-03-04 00:00 のような規格外の形（日付と時刻の間が T でなく空白）もあった
BPM が小数	Serato が 108.070000 のような小数で書いている（規格は整数）。0.000000（未解析と思われる）も多い
ソフトの独自データ	Windows Media Player・iTunes・Traktor・Serato がそれぞれ独自のデータを書いている。Traktor のデータは1曲で最大約130KB
最大文字数	ファイルのパス287文字、曲名147、アルバム132、アーティスト115、Apple Music の URL 421（抜き取りの範囲。全体では要確認）
入っていないもの	曲を世界で1つに特定する番号（ISRC）は0件。評価（★）・再生回数のフレームも1,441曲で0件

1つ注意があって、mutagen は標準の設定だと v2.3 の日付を自動で v2.4 の形（TDRC）に変換して読みます。元の形を見たいときは、変換しない設定（translate=False）で読む必要がありました。

ファイル名の付け方もフォルダによって違い（01_01_曲名.mp3 と 1-01 曲名.mp3）、ファイル名が .mp3 だけになっている曲も見つかりました。

3. DJ ソフトのライブラリも見た

評価や再生回数は MP3 ではなく DJ ソフトのライブラリ（ソフト側のデータベース）に入っているはずなので、rekordbox・Traktor・Serato のライブラリも書き出して確かめました。

• rekordbox：約12万8千曲が登録されていたが、評価が付いているのは16曲だけ、再生回数は全曲0
• Traktor・Serato：評価・再生回数はほとんど記録されていなかった
• rekordbox では、年が0（＝無し）の曲が4,450曲、ディスク番号が0の曲が11,762曲あった
• 編集の履歴（いつ・何を変えたか）は、どのソフトも持っていない

このため、評価・再生回数はデータベースを正として、これから記録していくことにしました。DJ ソフトに書き出すときは、★0〜5 を rekordbox の 0〜255 に変換します（×51。方針案）。編集の履歴も、データベースで持つ予定です。

4. 列の決め方

曲の表（tracks）に列として持つ主な項目です。

分類	列の例	元のタグ
ファイル	パス・大きさ・更新日時・ビットレート・CBR か VBR か・曲の長さ・エンコーダー名	（ファイル・音声データ）・TSSE
基本のタグ	曲名・アーティスト・アルバムのアーティスト・アルバム・トラック番号・ディスク番号	TIT2・TPE1・TPE2・TALB・TRCK・TPOS
日付	年・年月日・どこまで分かるか	TYER・TDAT・TDRC
ジャンル	元の値・主ジャンル	TCON
DJ 向け	BPM（小数2桁）・キー・Serato や Traktor の解析データの有無	TBPM・TKEY・GEOB・PRIV
画像	有無・形式・縦横の大きさ・バイト数（画像そのものは入れない）	APIC
新しく記録	評価・再生回数・最後に再生した日時	—

• トラック番号：タグには 1・01・1/12 などいろいろな形があるので、「番号」と「全体の数」の2つの数値に分ける
• 予備の列は作らない：将来使うかもしれない項目のために空の列を並べるのではなく、追加情報の表に入れておき、よく使うものが出てきたら正式な列に移す
• ファイルの場所：NAS の中の決まったフォルダからの相対パスにし、文字の形（濁点を1文字にした形）をそろえる（方針案）

アーティストは、タグの文字列（例 A Feat. B）はそのまま残し、対応の表で「主」「共演」「客演」「リミックス」などの役割を付けて分けます。区切りに / は使いません（AC/DC のように名前に含まれるため）。& も、Simon & Garfunkel のように分けない名前の一覧と突き合わせてから分けます。

5. 日付は3つの列に分ける

バージョンによって日付の持ち方が違い、年だけの曲も多いので、「年」「年月日」「どこまで分かるか（年だけ・年月まで・年月日まで）」の3つの列に分けました。年月日が分からない曲に、1月1日のような仮の日付を入れずに済みます。

6. 容量の見積もり

• 曲の表：1曲あたり約390バイト（検索用のインデックス込みで2.5倍と仮定）→ 50万曲で約460MB
• 追加情報の表：1曲あたり約15項目 → 50万曲で約1.3GB
• 合計：50万曲で約1.7GB
• ジャケット画像（平均約410KB）を入れると、50万曲で約194GB → 画像はデータベースに入れず、形式・大きさと画像の URL だけを持つ

データベースの文字コードは utf8mb4（絵文字やまれな漢字も入る UTF-8）にする方針です。

7. タグのバージョンを v2.3 にそろえられるか試した

タグを直す段階では、バージョンをそろえたくなります。そこで、日本語を UTF-16 で持つ v2.3 にそろえられるか、時間と失われる情報を試しました（元の曲は書き換えず、コピーや読み取りだけで確認）。DJ ソフトや Windows で問題なく読めるかは、まだ確認していません。

• 388曲のコピーを変換：約1.4秒（1曲約0.003秒）。タグの空き領域に収まり、ファイル全体の書き直しは0件
• 変わったのは日付だけ（TDRC → TYER＋TDAT）。ほかの値・ジャケット画像・Serato の解析データ・音声部分は変換前と同じ
• 1,409曲を読み取りだけで試すと、中身が空のコメント（158曲）が消えることも分かった
• 時間はほぼ NAS との読み書きで決まり、今の全曲で数時間程度と見込んでいる（要実測）

8. まだ決まっていないこと

• タグを書き戻すときに、v2.3（UTF-16）と v2.4（UTF-8）のどちらにそろえるか
• 検索で、大文字・小文字や全角・半角を同じものとして扱う方法（データベースの照合順序）
• 客演の書き方を、曲名の側（(feat. B)）にするか、アーティストの側（A Feat. B）にするか
• 最大文字数を確定するために、全曲のタグ（約3.6時間）を読むかどうか
• DJ ソフトのキューを表に持つかどうか

まとめ

• 表を作る前に実データを読むと、規格外の値・ソフトの独自データ・使われていない項目が分かる
• よく使う項目だけを列にし、それ以外は1項目1行の追加情報の表に入れると、予備の列を並べずに済む
• 評価・再生回数は MP3 にも DJ ソフトにもほとんど無いので、データベースで新しく記録する
• 日付は「年・年月日・精度」に分けると、バージョンの違いと年だけの曲の両方を扱える