Split合碟收藏整理指南：用SQLite管理地下碾核与噪音发行物

从上个世纪八十年代的地下噪音运动到九十年代极端碾核的全面爆发，欧洲地下音乐场景始终存在一批刻意拒绝“悦耳”、拒绝商业包装的发行物。2008 年，荷兰地下厂牌整理发行了一张堪称小圈子交流范本的 Split 合碟，将两支乐队拼在同一张唱片里：一支偏向血噪音（Blood Noise / Gore Noise）风格的声响制造者，另一支则属于以恶趣味和极速节拍著称的厕碾（Toilet Goregrind / Toilet Grind）乐队。这张 EP 就是 Multicore Diseases 与 Off-Toilet Ecstasies 的现场记录式合辑。

这篇博客并不是乐评，而是一份面向极端音乐收藏者、地下发行整理者和乐队资料管理者的实操笔记。围绕这张 2008 年的 Split EP，会完整拆解这类发行物“到底包含哪些信息”“为什么年份和厂牌如此重要”“如何整理成可靠的基础数据库”，并给出适合个人收藏管理和乐队归档使用的字段设计、目录规范与去重方法。

如果你正在整理自己手里的一批地下 Split 唱片，或者需要把早年买的实体 CD、磁带、数字文件转成结构化清单，这篇文章会告诉你从哪里下手、保留哪些字段、如何避免最常见的整理错误。

1. 先理解什么是 Split 合碟以及为什么它容易整理出错

1.1 Split 合碟的概念与地下场景中的意义

Split（也写作 split album/split EP/split 7"）指两个或以上乐队共享同一张发行物，各占一部分曲目。它是硬核朋克、碾核、噪音、黑金属场景里最常见的传播形态。

相比乐队全长专辑，Split 有几个鲜明的特征：

• 录制成本分摊，适合无厂牌预算的地下乐队；
• 双方乐迷互相交叉传播，扩大受众；
• 曲目数量少、时长短，经常以 7 英寸黑胶、EP、磁带或数字文件形式出现；
• 同一张 split 可能在不同国家出现多个压制版本，目录号各不相同。

也正是因为“多人参与、多地压盘、多格式流通”，Split 合碟在整理时比普通全长专辑更容易出现字段缺失、乐队顺序颠倒、发行年份错误等问题。像 Multicore Diseases / Off-Toilet Ecstasies 这张 2008 年 EP 就具备典型的碟友整理难点：乐队知名度低、封面信息少、数据库条目可能被合并或拆分错误。

1.2 血噪音和厕碾的基本辨识

在开始整理前，先明确两个风格标签的含义，否则很容易在分类字段里写入错误信息。

血噪音可以理解为噪音/碾核交叉区域的声响风格，强调血腥、病理、肢解主题，听觉上以高失真、快速鼓机或人声咆哮为主，部分作品带有强烈的工业噪音或电子刺耳声。它与“血碾”（Goregrind）有关联，但更强调噪音化表达。

厕碾是碾核中恶趣味分支，主题集中在排泄物、厕所、生理幽默，常用卡通式封面和极低沉的猪吼（pig squeal）人声。它与“色情碾核”（Pornogrind）有一定重叠，但不完全是同一类。这个标签在 Discogs、Encyclopaedia Metallum、Rate Your Music 等平台的使用并不统一，所以整理时最好保留“原始标签”和“整理标签”两个字段，避免数据库自动归类后丢失原始信息。

注意：地下极端音乐的分类标签属于“按需描述”，不是行业标准。不同平台对同一张唱片的风格标记可能完全不同。整理时不要把单一平台的分类当作唯一事实字段。

1.3 一张 Split 唱片需要记录哪些事实

无论风格多极端，整理必须遵循一个基本原则：以发行物实体为记录单位，而不是以“歌单”为单位。一张 Split 实体需要记录：

• 发行标题，即 Split 标题；
• 参与乐队名称及排序；
• 发行格式（CD、7"、LP、磁带、数字）；
• 厂牌名称与目录号；
• 发行年份；
• 曲目列表，以及每首曲目归属哪个乐队；
• 录制信息（录音室、录制年份、录音师等，如果有）；
• 封面/内页是否有额外信息；
• 限量数量、再版情况、版本差异。

针对 Multicore Diseases / Off-Toilet Ecstasies 这张 EP，资料库至少应该有上面这些基本条目的占位。即便暂时没有填全，也要预留字段位置。

2. 环境准备：搭建一个可长期维护的本地音乐资料库

整理地下极端音乐发行物，不推荐把资料全部塞进 Excel 或者纯文本里。虽然 Excel 也能用，但在处理多乐队、多版本、多渠道来源时会遇到以下问题：

• 同一张 split 在 Discogs、MA、RYM 的显示顺序和年份可能不同；
• 不同平台对“血噪音”“厕碾”的归类不一致；
• 同一个乐队可能有多个同名项目；
• 专辑重发、再版、 promo 版、repress 会造成条目拆分困难。

一个可行方案是使用轻量级数据库 SQLite，配合一个简单的 Python 脚本来录入和查询。这套环境不需要部署服务器，也不需要购买任何商业软件，适合个人收藏整理。

2.1 推荐环境

2.2 为什么选择 SQLite 而不是 Excel

Excel 适合“看数据、做简单筛选”，但在以下场景会带来额外麻烦：

• 需要保存同一发行物的多个厂牌/目录号时，单元格内容会变得混乱： 例如Bizarre Leprous Production (BLP 042) / Rotten Music (RM-008)，后期查询时很难按厂牌拆开。
• 需要关联“乐队表”和“发行物表”时，Excel 没有强关系约束。
• 多人协作、长期维护时容易出现版本冲突。

SQLite 是单文件数据库，非常适合个人收藏管理。它不需要安装额外服务，Python 自带支持。当数据量增加后，还可以迁移到 PostgreSQL 或 MySQL，数据结构不用推倒重来。

下面开始搭建库表结构。

3. 设计 Split 发行物数据结构

3.1 核心表结构设计

管理极端音乐发行物，建议至少设计 4 张表：

1. bands：乐队表。
2. releases：发行物主表。
3. release_bands：发行物与乐队的关联表，记录出场顺序与曲目归属。
4. tracks：曲目表。
5. labels与release_labels：厂牌与目录号关联表（可选，但推荐）。

下面是在 SQLite 中的实际建表语句：

PRAGMA foreign_keys = ON; CREATE TABLE IF NOT EXISTS bands ( id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT NOT NULL UNIQUE, country TEXT, status TEXT, genre_tags TEXT, formed_year INTEGER, notes TEXT ); CREATE TABLE IF NOT EXISTS releases ( id INTEGER PRIMARY KEY AUTOINCREMENT, title TEXT NOT NULL, release_type TEXT NOT NULL DEFAULT 'Split EP', format TEXT, release_year INTEGER, country TEXT, notes TEXT ); CREATE TABLE IF NOT EXISTS release_bands ( id INTEGER PRIMARY KEY AUTOINCREMENT, release_id INTEGER NOT NULL, band_id INTEGER NOT NULL, position INTEGER NOT NULL, side TEXT, FOREIGN KEY (release_id) REFERENCES releases(id) ON DELETE CASCADE, FOREIGN KEY (band_id) REFERENCES bands(id) ON DELETE CASCADE ); CREATE TABLE IF NOT EXISTS tracks ( id INTEGER PRIMARY KEY AUTOINCREMENT, release_id INTEGER NOT NULL, band_id INTEGER NOT NULL, title TEXT NOT NULL, track_no INTEGER, duration TEXT, is_cover INTEGER DEFAULT 0, FOREIGN KEY (release_id) REFERENCES releases(id) ON DELETE CASCADE, FOREIGN KEY (band_id) REFERENCES bands(id) ON DELETE CASCADE ); CREATE TABLE IF NOT EXISTS labels ( id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT NOT NULL UNIQUE, country TEXT ); CREATE TABLE IF NOT EXISTS release_labels ( id INTEGER PRIMARY KEY AUTOINCREMENT, release_id INTEGER NOT NULL, label_id INTEGER NOT NULL, catalog_number TEXT, is_primary INTEGER DEFAULT 1, FOREIGN KEY (release_id) REFERENCES releases(id) ON DELETE CASCADE, FOREIGN KEY (label_id) REFERENCES labels(id) ON DELETE CASCADE );

如果只是临时整理少量唱片，不建labels表也可以，把厂牌名称直接放releases.notes里。但如果要长期维护超过 50 张发行物，建议还是拆表。

3.2 字段设计说明

以本 EP 的记录为例，说明每个字段的含义：

3.3 录入数据的基本 SQL 示例

假设要把 Multicore Diseases 与 Off-Toilet Ecstasies 录入库中，先录乐队：

INSERT INTO bands (name, country, genre_tags, formed_year, notes) VALUES ('Multicore Diseases', NULL, 'Blood Noise/Gore Noise', NULL, '乐队背景待补'); INSERT INTO bands (name, country, genre_tags, formed_year, notes) VALUES ('Off-Toilet Ecstasies', NULL, 'Toilet Goregrind', NULL, '乐队背景待补');

再录入发行物：

INSERT INTO releases (title, release_type, format, release_year, country, notes) VALUES ( 'Multicore Diseases / Off-Toilet Ecstasies', 'Split EP', 'CD', 2008, 'Netherlands', '荷兰地下场景合辑，血噪音与厕碾双乐队分碟' );

接着关联乐队顺序：

INSERT INTO release_bands (release_id, band_id, position, side) VALUES (1, 1, 1, 'A'); INSERT INTO release_bands (release_id, band_id, position, side) VALUES (1, 2, 2, 'B');

这里的position字段非常重要。有些数据库会按字典序排列乐队，导致原始顺序丢失。如果实体封面明确写着Multicore Diseases在前、Off-Toilet Ecstasies在后，那position就应该是 1 和 2。

4. 实际整理脚本与 Catalog 编号规则

4.1 为发行物建立 Catalog Number 规则

独立发行的 Split 经常没有正规条形码，甚至目录号也只是手写。如果你打算建立自己的收藏体系，最实用的方法是采用“个人目录号”：

[来源国]-[发行格式]-[厂牌缩写]-[年份]-[序号]

示例：

NL-CD-BLP-2008-001 NL-DIG-NOLBL-2008-014

字段含义如下：

这样设计有几个直接好处：

• 不需要依赖 Discogs ID，即使平台条目被删除，本地记录仍在；
• 可以通过文件名直接判断发行物格式与来源；
• 同一个实体有多个版本时，序号可以继续追加。

4.2 目录结构建议

如果你不只想在数据库里查记录，还想把数字文件按物理实体保存，建议使用下面的目录结构：

D:\ExtremeMusicDB\ 00_INDEX\ 01_NL_CD_2008_001_MulticoreDiseases_OffToiletEcstasies\ 00_cover.jpg 01_front.jpg 02_back.jpg 03_tray.jpg 04_booklet_01.jpg 05_booklet_02.jpg audio\ track01_multicore_diseases_untitled.flac track02_off_toilet_ecstasies_song_name.flac file_info.txt 02_NL_DIG_2009_002_SomeBand_Split\

单张发行物用一个文件夹，文件夹名等于个人目录号加乐队名，既能和数据库对应，又能在资源管理器中快速定位。

注意：文件夹命名不要使用/\:*?"<>|等 Windows 非法字符。乐队名过长时可用缩写。

4.3 Python 录入辅助脚本

用 Python 写一个简单的录入脚本，可以减少手动敲 SQL 的负担。

import sqlite3 import sys DB_PATH = "extreme_music.db" def add_band(conn, name, country="", genre_tags="", formed_year=None, notes=""): cur = conn.execute( "INSERT OR IGNORE INTO bands (name, country, genre_tags, formed_year, notes) " "VALUES (?, ?, ?, ?, ?)", (name, country, genre_tags, formed_year, notes), ) return cur.lastrowid def add_release(conn, title, release_type="Split EP", fmt="CD", year=None, country="", notes=""): cur = conn.execute( "INSERT INTO releases (title, release_type, format, release_year, country, notes) " "VALUES (?, ?, ?, ?, ?, ?)", (title, release_type, fmt, year, country, notes), ) return cur.lastrowid def link_band_to_release(conn, release_id, band_id, position, side): conn.execute( "INSERT OR IGNORE INTO release_bands " "(release_id, band_id, position, side) VALUES (?, ?, ?, ?)", (release_id, band_id, position, side), ) def main(): conn = sqlite3.connect(DB_PATH) conn.execute("PRAGMA foreign_keys = ON;") try: multicore_id = add_band(conn, "Multicore Diseases", genre_tags="Blood Noise") toilet_id = add_band(conn, "Off-Toilet Ecstasies", genre_tags="Toilet Goregrind") release_id = add_release( conn, title="Multicore Diseases / Off-Toilet Ecstasies", release_type="Split EP", fmt="CD", year=2008, country="NL", notes="2008年荷兰地下场景发行", ) link_band_to_release(conn, release_id, multicore_id, 1, "A") link_band_to_release(conn, release_id, toilet_id, 2, "B") conn.commit() print("录入成功") finally: conn.close() if __name__ == "__main__": main()

这里的关键点在于INSERT OR IGNORE，它可以避免重复插入同名乐队。实际使用时，notes字段用于写来源信息，比如“封面写有厂牌网址，但实体上没有明显目录号”这类判断。

5. 查询与验证：怎么确认数据没有录错

5.1 常用查询示例

录入完成后，需要验证。

查询某个发行物包含哪些乐队：

SELECT r.title, b.name AS band_name, rb.position, rb.side FROM releases r JOIN release_bands rb ON rb.release_id = r.id JOIN bands b ON b.id = rb.band_id WHERE r.title LIKE '%Multicore%' ORDER BY rb.position ASC;

查询某个厂牌发行了哪些唱片：

SELECT r.title, r.release_year, r.format, l.name AS label_name, rl.catalog_number FROM releases r JOIN release_labels rl ON rl.release_id = r.id JOIN labels l ON l.id = rl.label_id WHERE l.name LIKE '%label_name%';

查询同一乐队参与的全部 Split：

SELECT r.title, r.release_type, r.release_year, r.format FROM releases r JOIN release_bands rb ON rb.release_id = r.id JOIN bands b ON b.id = rb.band_id WHERE b.name = 'Multicore Diseases' ORDER BY r.release_year DESC;

5.2 数据完整性的核查清单

运行下面的查询能够快速找出明显错误：

-- 查看没有 release_year 的发行物 SELECT id, title FROM releases WHERE release_year IS NULL; -- 查看没有关联乐队的发行物 SELECT r.id, r.title FROM releases r LEFT JOIN release_bands rb ON rb.release_id = r.id WHERE rb.id IS NULL;

这组查询能发现两类最常见问题：字段漏填、关联丢失。

5.3 如何判断 2008 这个年份是否可靠

地下发行物的年份经常被误标。常见原因包括：

• 录制年份与发行年份混为一体；
• 磁带版本与 CD 版本在不同年份发布；
• 厂牌实际出货时间晚于封面印刷时间；
• Discogs 上把数字版上架年份当作原始发行年份。

交叉验证时应遵循“实体优先、印刷信息优先”的原则。在无法确认的前提下，数据库里最好增加一个year_verified字段：

ALTER TABLE releases ADD COLUMN year_verified INTEGER DEFAULT 0;

year_verified = 1表示年份已通过实体印刷或可靠数据库核实；0表示未核实。通过这个字段，可以在查询时自动过滤不准确的数据。

6. 多数据源交叉验证：Discogs、MA 与实体扫描

6.1 不同平台的差异风险

整理极端地下音乐时，常遇到几个资料平台之间互相矛盾的情况。以“血噪音/厕碾”这类标签为例：

对 Multicore Diseases / Off-Toilet Ecstasies 这种低知名度 Split，最可靠的来源是实体封面、封底、内页和磁带/黑胶盘标。数字文件只能作为辅助来源。

6.2 具体交叉验证流程

推荐按以下顺序进行：

1. 先检查实体封面与封底，记录印刷标题、乐队顺序、厂牌名称、目录号、年份、录制信息。
2. 再打开 Discogs 搜索这张 split 的 title，核对 catalog number 和 label。
3. 接着在 Metal Archives 搜索两个乐队，确认乐队的国籍、成立年份、风格标签。
4. 最后检查 Bandcamp 或厂牌官网是否提供数字版与发行说明。
5. 如果多个来源出现冲突，在本地数据库notes字段中记录冲突版本与最终判断依据。

从多平台判断资料的顺序：实体 -> Discogs 发行页 -> MA 乐队页 -> Bandcamp -> 其他论坛。

不要反过来做。论坛和评论区里的年份、顺序信息经常是错的。

6.3 保存资料溯源信息

好的整理者在文件里会保留“依据快照”。

file_info.txt示例：

Release : Multicore Diseases / Off-Toilet Ecstasies Format : CD Country : Netherlands Label : (待确认) Catalog : (待确认) Year : 2008 Verification source: - 封面扫描件: 2008 印刷于封底 - Discogs URL: https://www.discogs.com/release/xxxxxxxx - MA Band URL: https://www.metal-archives.com/bands/xxxx - Notes: 音源来自 CD 抓轨；标签信息待与实体核对。

注意，链接不要作为永久依赖。页面可能被删除，所以要保存扫描件与文字记录，而不是只存 URL。

7. 重复条目与常见整理错误排查

7.1 最容易犯的三个整理错误

整理 Split 发行物时，错误通常集中在以下三类：

错误一：把“歌单顺序”当成“乐队顺序”

有些压制版本中，A 面第一首是 A 乐队的曲目，第二首可能就是 B 乐队。如果只记录曲目列表而不记录每首曲目属于谁，数据库查询时会很混乱。

正确做法：曲目表必须带band_id字段。录入时把每首曲目和对应乐队关联，而不是只填标题。

错误二：扔掉限量编号

很多地下 CD 和磁带带有限量编号，例如“Hand-numbered /100”。这个信息对收藏整理非常重要。单独设limitation字段存放，不要写进notes后就不再关注。

ALTER TABLE releases ADD COLUMN limitation TEXT;

错误三：把不同压制版本合并成一条

同一张 split 在最初发行 5 年后可能被另一个厂牌再版，封面可能几乎一样，但目录号不同。不要把 2008 年首版和 2015 年 reissue 合并到同一个releases.id下。应该在表里增加version_note字段：

ALTER TABLE releases ADD COLUMN version_note TEXT;

示例：

'2008 Netherlands CD first pressing, hand-numbered /100' '2015 US tape reissue, gray shell'

7.2 排查问题时可以按这个列表进行

7.3 批量修复的 Python 示例

如果早期没有录入position，可以写一个小批量修复脚本：

import sqlite3 conn = sqlite3.connect("extreme_music.db") cur = conn.cursor() # 假设 release_id=1 的 A 面第一条是 Multicore Diseases position_data = [ (1, 1, 1, "A"), # release_id, band_id, position, side (1, 2, 2, "B"), ] cur.executemany( "UPDATE release_bands SET position = ?, side = ? " "WHERE release_id = ? AND band_id = ?", [(pos, side, rel_id, band_id) for rel_id, band_id, pos, side in position_data], ) conn.commit() conn.close()

这种脚本适合数据量不大时使用。如果数据已经有几百张，建议先把重复数据导出 CSV，人工确认后再批量处理。

8. 归档策略与长期维护建议

8.1 个人收藏整理应达到什么标准

对地下极端音乐收藏者而言，数据库建设的核心标准不是“信息多全”，而是“以后还能不能看懂当初的记录”。如果每条记录都缺少来源判断，过两年再看时，你很难分清哪些信息来自实体、哪些来自网络。

建议在每条记录的notes字段里至少回答以下问题：

• 实体是否在手上，还是通过音源恢复；
• 封面是否扫描；
• 年份的核实依据；
• 是否曾经和 Discogs 或 MA 条目的信息做过比对；
• 如果比对结果不一致，最终选择了哪个来源、为什么。

8.2 发布前与盘点前的检查清单

周期性维护数据库时，可对照以下清单：

1. 数据库中是否有release_year IS NULL的记录；
2. 是否有release_bands关联少于 2 条乐队的 Split；
3. 是否有tracks未关联band_id的曲目；
4. 是否有直接标题相同、但目录号不同的发行物；
5. 是否在notes中写明来源验证状态；
6. 是否已经备份数据库和封面扫描件；
7. 是否导出 CSV 到另一个存储介质；
8. 是否更新了文件夹中的file_info.txt；
9. 是否将数字文件与物理实体的音轨做了 MD5/FLAC 校验；
10. 是否清理过数据库缓存或临时文件。

注意：不要只备份一个 SQLite 文件。SQLite 在断电、磁盘异常时可能损坏，建议每次全量导出 CSV，再连同 db 文件一起备份到第二块磁盘或网盘中。

8.3 如何用一张汇总表分析收藏构成

Run 以下 SQL 可以快速看到自己收藏库中不同发行类型的数量：

SELECT release_type, format, COUNT(*) AS release_count FROM releases GROUP BY release_type, format ORDER BY release_count DESC;

也可以按年份跨度统计：

SELECT release_year, COUNT(*) AS release_count FROM releases WHERE release_year IS NOT NULL GROUP BY release_year ORDER BY release_year;

这两组查询能帮助你判断资料库中收录的时间分布，同时也能发现异常年份的记录，比如 2008 年的 split 突然出现一条 1970 年的记录，那基本是来源错误。

8.4 为以后可能参与的多人协作预留接口

如果后续想和朋友、同好共建资料库，最好提前考虑多用户写入的问题。SQLite 在本地单机环境中很适合，但多人同时写入会有锁竞争。简易方案是：

• 每个协作者维护自己的 SQLite 数据库；
• 每周导出 CSV；
• 由一个主整理者统一合并导入。

合并导入的基础是唯一键设计。如果早期建表没建 UNIQUE 约束，后期合并时需要使用 title + format + release_year + label_id 组合判重。使用 Python 实现时，先查重再插入即可：

def find_duplicate(conn, title, label_name, catalog_number): row = conn.execute( """ SELECT r.id FROM releases r JOIN release_labels rl ON rl.release_id = r.id JOIN labels l ON l.id = rl.label_id WHERE r.title = ? AND l.name = ? AND rl.catalog_number = ? """, (title, label_name, catalog_number), ).fetchone() return row[0] if row else None

通过这个函数可以在导入前判断目标库里是否已经存在同一条发行物。

9. 数字音源与实体抓轨的规范化

9.1 FLAC 与文件命名

地下发行物数字文件最常见的来源有两种：购买官方数字版，或用自己的 CD/磁带抓轨。无论来源，文件名都应包含完整标识。示例格式：

{个人目录号}_{trackno}_{乐队名}_{曲目标题}.{ext}

例如：

NL-CD-BLP-2008-001_t01_MulticoreDiseases_Intro.flac NL-CD-BLP-2008-001_t02_MulticoreDiseases_Untitled.flac NL-CD-BLP-2008-001_t03_OffToiletEcstasies_ExcrementDream.flac

理由很简单：除非专用标签解析器，否则普通播放器不会显示发行物 ID。文件名里带个人目录号后，即使文件被拖出原目录，也能迅速关联回数据库。

9.2 抓轨规范

CD 抓轨推荐使用 Exact Audio Copy (EAC) 或 XLD，至少开启精确流模式。抓轨后生成.log文件并保留，这样以后可以确认抓轨过程是否没有错误。

EAC extraction logfile from 12. March 2024, 20:33 Used drive : HL-DT-ST BD-RE WH14NS40 Adapter: 1 ID: 1 Read mode : Secure ...

不需要把 log 内容录入数据库，但应随音频文件保存在同一发行物目录中。

9.3 数字文件的校验

为了长期保存，建议对音频文件计算一次校验和：

# 在发行物目录下执行 sha256sum *.flac > checksums.sha256

以后需要校验时：

sha256sum -c checksums.sha256

这项操作对早期抓轨文件尤其有意义。老 CD 可能已出现数据退化或读取不准的问题，完整抓轨加校验可以提前发现问题。

10. 进一步扩展：从本地数据库到共享资料仓库

10.1 本地数据库做数据分析与补全

本地 SQLite 数据库建好后，可以做的事情很多：

• 统计自己的收藏中哪些厂牌占比最大；
• 查出一位乐队成员参与过的全部项目；
• 分析自己收藏年份分布，发现采集空白期；
• 生成 HTML 收藏页面，用脚本直接渲染。

示例如下：

import sqlite3 import html conn = sqlite3.connect("extreme_music.db") rows = conn.execute( """ SELECT r.release_year, r.title, r.format, r.limitation, group_concat(DISTINCT b.name) AS bands FROM releases r JOIN release_bands rb ON rb.release_id = r.id JOIN bands b ON b.id = rb.band_id WHERE r.release_year >= 2000 GROUP BY r.id ORDER BY r.release_year DESC """ ).fetchall() out = [] for year, title, fmt, limitation, bands in rows: out.append( f"<li>{html.escape(str(year))} | " f"{html.escape(title)} | {html.escape(fmt)} | " f"{html.escape(bands)} | {html.escape(limitation or '')}</li>" ) with open("collection.html", "w", encoding="utf-8") as f: f.write("<html><head><meta charset='utf-8'></head><body><ul>") f.write("<li>发行年份 | 标题 | 格式 | 乐队 | 限量</li>") f.write("\n".join(out)) f.write("</ul></body></html>")

这个脚本生成的 HTML 可以放在本地浏览器里查看，也可以作为私人收藏页分享给同好。

10.2 与公开数据库的同步注意事项

如果未来想把本地整理结果同步到 Discogs 等平台，需要额外注意权益与准确性。上传前必须做到：

• 每个发行物有实际来源，不是从论坛听说的“记忆”。
• 目录号必须从实体封底或盘标抄录。
• 风格标签尽量使用平台已有标签，不要引入自定义短语，除非平台允许 free text。
• 同一条记录不要重复提交，以免污染平台数据。

在“本地记录”和“线上数据库”之间，本地记录永远是第一参考。线上平台只是临时展示层。所有扫描件、log、校验文件都应该随本地记录保存。

10.3 面对稀缺版本的特殊处理

部分地下 split 发行量低于 50 张，公共数据库信息很少甚至为空。对这些版本，本地整理者能做的事情是：

• 保留实体照片、音源、封面扫描；
• 标注“此信息来自个人持有实体，尚未与其他来源核对”；
• 不猜测厂牌与年份；
• 在未来可能出现的二手市场拍卖、旧货搜索中，这份准确记录本身就很有价值。

实际经验是，越是小众的极端音乐发行，越容易因为某个平台用户随手填写的错误数据而传播误导信息。个人收藏数据库的准确程度，往往比公共数据库的高。

11. 围绕“血噪音/厕碾”特殊字段的补充建议

11.1 风格标签如何整理才不会丢失原信息

“Blood Noise”“Toilet Goregrind”这类标签不是官方标准。同一个乐队与发行物在不同媒介中的描述可能不同。

推荐字段设计：

ALTER TABLE bands ADD COLUMN raw_genre_tags TEXT; ALTER TABLE bands ADD COLUMN normalized_genre_tags TEXT;

raw_genre_tags保存原始标签字符串，例如Blood Noise/Gore Noise；normalized_genre_tags保存用来检索的标准标签，例如blood noise; goregrind。

这样做的原因：如果你只保留标准标签，以后回头查当年你在某个博客上看到“血噪音/厕碾双乐队”这种叫法时，会完全对不上。如果只保留原始标签，又很难统一筛选。

11.2 相关主题关键词备用表

针对极端音乐标签的检索需求，可单独保留一个genre_alias表：

CREATE TABLE IF NOT EXISTS genre_alias ( id INTEGER PRIMARY KEY AUTOINCREMENT, base_genre TEXT NOT NULL, alias TEXT NOT NULL ); INSERT INTO genre_alias (base_genre, alias) VALUES ('Goregrind', 'Blood Noise'), ('Goregrind', 'Blood Gore'), ('Goregrind', 'Splatter Gore'), ('Toilet Goregrind', 'Toilet Grind'), ('Toilet Goregrind', 'Shitgrind');

在实际使用中，不要把这表当成权威标签树。它只是方便你在曾经使用过模糊名称的情况下依然能定位到正确的基础风格。

11.3 涉及多个国家的厂牌归属判断

像 Multicore Diseases / Off-Toilet Ecstasies 这种荷兰地下合辑，厂牌可能属于荷兰，也可能由北欧或美国的另一个厂牌代为发售。整理时需要区分：

• recording country：录音发生地（如果有录音室信息）；
• pressing country：压制地（黑胶/CD 生产地）；
• label country：厂牌主要国家。

对低预算地下发行来说，压制地和厂牌地经常不一致。比如在欧洲制带但由美国发行。本地数据库至少要在releases.notes中记录这种差异，否则以后查询会出现“荷兰发行物为何目录号像美国公司”的疑惑。

12. 常见问题速查与前期准备清单

12.1 开始整理前要准备的资材

启动一个新收藏库整理任务前，建议先准备好以下内容：

• 一台装有 Python 3.8+ 的电脑；
• SQLite 命令行工具或 DB Browser for SQLite；
• 需要整理的物理实体（CD、磁带、黑胶）；
• 扫描仪或拍照设备，用于封面/封底/内页扫描；
• 一张可信的网络来源清单（Discogs、Metal Archives、Bandcamp 等）；
• 一个独立目录用于保存数据库和扫描文件；
• 一个 Excel/CSV 模板，用于线下先录入再批量导入。

12.2 常见报错与处理方法

12.3 面对大量数据时的分步导入顺序

如果一次要整理 50 张以上发行物，一定不要试图一次性完成。推荐分四个阶段：

1. 先建库建表，录 5 张手上实体最齐全的发行物作为测试；
2. 跑一遍查询与 HTML 导出，确认数据结构满足需要；
3. 再批量补充剩余实体，按“CD -> 磁带 -> 黑胶 -> 数字”分批处理；
4. 每处理完 10 张，做一次完整性查询和文件备份。

这样做的好处是，能够尽早发现表结构缺陷，不需要录入 200 条后才发现缺少关键字段而全部返工。

12.4 风险控制：不要轻信未经核实的公开数据

公共数据库中的用户贡献数据并不一定正确。尤其对“2008 年、荷兰、地下 split、非知名乐队”这类组合，有些平台条目可能来自某个用户多年前的模糊记忆。整理时必须做到：

• 地面字段中至少保留一个可靠来源；
• 多人确认的信息通常比单人信息概率高；
• 当公共数据库之间出现冲突时，优先选择拥有实体封底扫描件的条目；
• 本地记录永远允许NULL，不要为了填满年份而编造。

注意：整理地下音乐发行物是一项长期、低回报、需要耐心的资料工作。不要因为某个平台上没有信息，就在自己的库里编造目录号或年份。缺失本身就是一种真实信息。

13. 这篇文章的最终使用建议

关于 Multicore Diseases / Off-Toilet Ecstasies(2008)这张荷兰 Split EP 的整理，本文给出的并不是一篇“听完后写感想”的内容，而是一套可行的资料管理路径：

• 以实体为记录单位；
• 以 SQLite 数据表保存结构化信息；
• 以个人目录号为文件命名锚点；
• 以封面扫描和来源备注作为事实依据；
• 以多平台交叉验证代替单一平台下载。

把这个流程实践一遍后，你不仅能整理这一张 Split，还能把它迁移到任意极端音乐发行物上，无论是 1987 年的老磁带还是 2024 年的数字分碟，处理逻辑都一样。真正有价值的不是豆瓣或 Discogs 上那几行数据条，而是你自己保存的实体扫描、抓轨日志、交叉验证备注和经过判断后的最终记录。

下一步建议先从手中某一张“信息最不全”的 Split 开始，把本文提到的表建起来，录入那一张唱片，生成一份查询结果，再扫描封面并保存音轨校验值。跑通一次之后，再继续整理第二张、第三张，逐步建立属于自己的极端音乐收藏资料库。