把 400 首現場曲目建成可搜的演出紀錄：我的 SQLite 做法

上個月整理自己十年來的現場錄音，資料是 412 首曲目，散在 38 場演出裡，格式從 16bit/44.1k 的 WAV 到手機錄的 m4a 都有。原本用資料夾分類，想找「某首歌在哪些場次出現過」只能一場一場翻。後來改成一個 SQLite 檔，把演出、曲目、來源檔分三張表，用 sqlite3 直接查。

做法很土。先把每場演出建成一列，欄位是日期、場地、 lineup、錄音設備；曲目表存 track_no、曲名、開始秒數、結束秒數、是否翻唱；來源表存檔案路徑、格式、取樣率、檔案大小。建表用：

CREATE TABLE show(id INTEGER PRIMARY KEY, date TEXT, venue TEXT, source TEXT);
CREATE TABLE track(id INTEGER PRIMARY KEY, show_id INT, no INT, title TEXT, start_s REAL, dur_s REAL, cover INT);
CREATE TABLE file(id INTEGER PRIMARY KEY, track_id INT, path TEXT, fmt TEXT, sr INT, bytes INT);
CREATE INDEX idx_track_title ON track(title);

填入靠一個 Python 腳本，掃資料夾裡我手寫的 _setlist.txt，一行一場、格式固定成「序號|曲名|開始秒|長度|是否翻唱」。跑完之後最常用的查詢是：

SELECT s.date, s.venue, t.no FROM track t JOIN show s ON s.id=t.show_id
WHERE t.title LIKE '%關鍵字%' ORDER BY s.date;

這樣查一首歌跨場次的出現頻率，比翻資料夾快很多。代價是前期要手動補 setlist；我 38 場裡有 5 場是事後憑記憶補的，日期和曲序一定有錯，所以我在 show 表加了一個 confidence 欄位，憑記憶的標 low，查詢時自己知道要打折。

會失效的地方很具體：曲名沒有正規化。同一首歌可能寫成「夏夜晚風」「夏夜晚風 (live)」「夏夜晚風-安可」，LIKE 查詢就會漏。我後來加了一個 alias 表做手動對照，但只補了常查的二十幾首，其餘放著。另一個坑是秒數：早期錄音是整場一個檔，start_s 是相對檔案開頭，換場地重錄之後時間軸對不上，這批我乾脆只存曲序不存秒數，查得到歌、但跳不到位置。

現在這個庫最大的用途不是聽，是回頭看自己這十年聽了什麼、哪些歌重複出現在不同場次。你如果也做過類似的事，曲名正規化是手動對照表，還是有更省力的做法？