【05/14】gptちゃんによる"mp3-id3-batch-editor"各ファイル解説
GitHubレポジトリ
第5回：notes_mp3_to_csv1.md
―「エラー出さずに動いた」＝スタートライン、という現実 ―
このノートの面白さは、最初にユーザーが言った通りで、
「スクリプトが実行エラーを吐かずに動くようになった状態」
つまり、“動いた”時点の記録なんですよね。
ここ、重要です。
世の中の多くの開発記事は「完成後の美談」から書く。
でも現実の開発って、
まず動かす（最低限）
それからちゃんとさせる（例外・罠・運用）
最後に文書化する（そして気絶）
なんです。
このノートは、その一段目が終わった瞬間に書かれている。
つまり、現場の匂いが一番濃い。
1. いきなり核心：「なぜ分析スクリプトから？」
冒頭でこれを強く押してます。
プログラムはデータを処理するもの。データの形を知らずに書くと、必ず想定外に遭遇する
そして22,477件。
ここでのメッセージはシンプル：
「たぶんこうだろう」で書くと死ぬ
このノート、技術の話をしてるようで、実は生存戦略の話をしてます。
2. 分析で見えた現実：タグは混在、世界は一枚岩じゃない
ここは前のテクニカルノートとも連動してるけど、
開発ノートとしての価値は「設計への直結」を丁寧に書いてるところ。
バージョン混在
v2.3 71%
v2.4 13.8%
v1.1 10.8%
v2.2 3.5%
タグなし 0.9%
そしてここで「年」の地雷に繋がる。
v2.3：TYER（年だけ）
v2.4：TDRC（日付まで）
この一文、地味に怖い。
同じ「年」なのにフレームIDが違う。
つまり「TYERだけ読めばいい」と思った瞬間に、1/7くらいのファイルの年が消える。
だから read_year() を作った、という話になる。
これ、教科書ではなく「手元の現実」から来てるのがデカい。
3. COMM地獄：コメント欄が“人間の言葉”とは限らない
分析結果に出てくるCOMMの一覧が、もう不穏。
COMM::eng
COMM:iTunNORM:eng
COMM:iTunSMPB:eng
...
ここが面白いのは、
「コメント」って聞くと普通は人間の感想だと思うじゃないですか。
でも実際は
人間のコメント
iTunesの内部データ（正規化など）
しかも種類が複数
が同じCOMMに居る。
つまり：
「コメント欄＝自由帳」ではなく
「コメント欄＝アプリの物置」でもある
これをCSVに出したらどうなるか？
列が爆増
しかも人間が編集できない数値が混ざる
表計算ソフトが死ぬ
だから結論：
COMMはCSVに出さない、触らない、保持するだけ
この判断が、設計の正気を守ってます。
4. PRIV地獄：バイナリが“文字列のふり”をしている
PRIVはもっとヤバい。
PRIV:WM/MediaClassPrimaryID:¼}`Ñ#ãâK¡H¤*(D
はい、これがCSVに入った瞬間、文字コード戦争が始まります。
ノートは「ゴミデータの温床」と書いてる。
言い方が強いが、正しい。
そしてここも結論が同じ：
触らない。保持するだけ。
「全部正しく扱う」じゃなく
「触った部分だけ正しく扱う」。
この割り切りが大量処理では勝ち筋です。
5. CSV設計の三案：A/B/C の分岐が渋い
選択肢をちゃんと並べてるのがいい。
A：編集対象だけ出す
B：全部出すが隔離
C：編集対象だけ出し、それ以外は保持して書き戻す
で、ClaudeはC推し。理由が現実的。
AだとCSVに出さなかったタグが消える可能性がある
Cは「CSVにないタグは元のまま」を明示できる
この一文がね、地味に重要。
CSVは“編集対象の表”であって
“タグ全体の完全な写し”ではない。
という設計哲学を固定してます。
そして出てくる名言：
「触らぬ神に祟りなし」
これ、ふざけてるようで、
ID3地獄に対する最適戦略です。
6. file_pathを相対パスにする：運用のリアリティが強すぎる
ここは「分かる人には分かる」系の沼。
HDDを別Macに繋ぐと /Volumes/... が変わる。
だから相対パス。
この判断は、「技術」じゃなく「生活」なんですよ。
机の上の実装じゃなく、
あなたの部屋のHDD移動まで含めた設計。
普通の開発者はここを書かない。
でもこのプロジェクトはここを書いてる。
読者にとってはありがたい。
7. utf-8-sig（BOM付き）を選ぶ：ここが“人間向け設計”の真骨頂
ここ、最高に実務。
Excel/NumbersがUTF-8を誤認して文字化けすることがある
BOMが目印になる
技術的には「BOMなしが標準」でも、
現実のユーザーはExcelを開く。
つまりこの選択は、
標準より、現場で死なない方を取る
という思想。
これ、ユーザーのリポジトリ全体に流れてる哲学です。
8. newline="" をわざわざ書く：CC0公開の“予防接種”
newline="" の話、普通は誰も書かない。
でもここでは書く。
理由がまた現実的で：
将来誰かがWindowsで使うかもしれない
コスト0で防げるなら防ぐ
これ、教育目的のOSSの姿勢が出てる。
「動けばいい」じゃなく
「読んだ人が転ばないようにする」。
9. {col: "" for col in CSV_COLUMNS}：地味だが強い“壊れにくさ”
辞書内包表記の説明が丁寧。
で、ポイントはこれ：
タグなしや読み込み失敗でも、辞書の形を揃えないとCSV書き出しが死ぬ
「例外系こそ先に設計する」ってやつ。
そしてここが“動いた時点”のノートらしい：
まず全部空で作る
値が取れたら入れる
この順番は、大量処理で生き残る順番です。
10. mutagenのTYER/TDRC挙動：実験でしか分からない罠
ここ、ノートの後半に入ってるけど、前編でもう触ってるのが面白い。
API上はTDRCとして扱われるが、v2_version=3で保存するとバイナリはTYERになる
つまり「読んだらTYERじゃない」は正常。
この手の罠は、仕様書読んでも分からない。
動かして、保存して、読み返して、やっと見える。
このノートが価値あるのは、ここを
「現象」→「正体」→「対処」
まで書いてしまっている点。
11. エラーは握りつぶさない：CSVに“故障メモ”を残す
これ、めちゃくちゃ好き。
title列に [READ ERROR: ...] と書く
普通はログに出して終わり。
でもこのツールの主戦場は
表計算ソフト（人間の目）
だから、
CSVを開いた瞬間に
どの行が壊れてるか分かる
ようにする。
ログじゃなく、成果物に印を残す。
これは「運用の設計」です。
12. 目標設定が、ちゃんと現実的で怖い
最後のところ、ユーザーの言葉が引用されてます。
「使い物になる程度まで完成したら、初心者向けにクッソウザいほどコメントしてCC0公開」
これ、軽口に見えて実は戦略的。
完璧を目指さない → 公開できる
教材として価値を出す → 他人も使える
CC0 → 変な遠慮が消える
そしてClaudeがそれをちゃんと理解してる。
総評：このノートの“見どころ”は何か
notes_mp3_to_csv1.md の見どころは、
「動いた」瞬間に、何を根拠に何を捨てたかが全部書いてあることです。
分析ファーストの理由
COMM/PRIV地獄の回避
CSV列設計のC案採用
相対パスという生活設計
BOMという人間対策
newlineという公開対策
例外を成果物に刻む
これ、普通の開発者が書かないところばっかりです。
だから面白い。
この記事のライセンスについて
この記事は「CC0 1.0 全世界 (CC0 1.0 Public Domain Dedication)」の下に提供されています。著作権法上の権利を放棄するとともに、著作者人格権を行使しないことを宣言します。営利・非営利を問わず、複製、改変、再配布など、あらゆる目的で自由にご利用いただけます。許可やクレジット表記も不要です。
CC0の公式ライセンス証（詳細）はこちら
