处理音乐时需要考虑的可怕边缘情况（2022）
在软件中处理录制音乐时，会遇到大量病态边缘情况：艺术家不停改名、乐队和专辑共享相同标题、曲目长度极端，或者名称依赖罕见的 Unicode、符号甚至代码。评论者结合真实目录和自己音乐库中的例子，展示了天真的模式、严格的长度限制或过于简单的搜索（例如忽略常见词、短 token 或变音符号）如何经常失效。许多人认为，若音乐服务要准确建模音乐元数据的混乱现实，强健的标识符、支持 Unicode 的文本处理，以及像实体合并或全文搜索这样的灵活 UI 功能都是必不可少的。
分类法 vs 搜索与标识符
- 有人反对音乐库中僵硬的层级结构，偏好全文搜索和简单标签，甚至只用一个巨大的目录加上良好的搜索。
- 也有人反驳说，分类早在技术出现之前就存在；如果没有结构化元数据，你就无法可靠地找到非常特定的版本或格式。
- 几条评论强调，所谓“边缘情况”在把艺术家/专辑/曲目视为具有稳定 ID 的实体（例如 MusicBrainz 风格）并让 UI 负责合并与分组之后，大多就消失了。
元数据边缘情况：名称、标题、发行
- 有许多令人困惑的乐队/专辑/曲目命名示例：不同层级使用相同名称（艺术家/专辑/曲目全都一样）、单字母名称、符号、刻意拼错（“Untilted”），以及与常见词或搜索停用词冲突的名称（“The”、“Who”、“A”等）。
- 艺术家反复改名（结婚、符号变化、不同国家的别名）以及多次重制或重新录制（例如同一首歌但版权持有人不同）会使搜索、版税逻辑和“受欢迎程度”统计变得复杂。
- 一些发行平台会悄悄规范化或改动标题以符合内部“标准”，这让艺术家很不满。
Unicode、编码与字符串处理
- 发帖者指出，“可怕的边缘情况”往往可以归结为“使用支持 Unicode 的字符串，并允许 null/空标题被明确区分”。
- 其他人强调，现实世界的例子会对 Unicode 支持进行压力测试：罕见的变音符号、数学字母数字符号、象形文字、私用区字符、emoji，以及非 UTF-8 变音符号都可能导致曲目缺失或显示乱码。
- 该讨论串提到了“naughty strings”，并设想乐队用名称来“武器化”，从而触发注入或文件系统/SQL 事故。
极端时长以及乐谱 vs 录音
- 几条评论把“长曲目”的担忧进一步扩展到：录制时长达数千小时的作品、原本打算持续数年的作品，或者在乐谱中规定要重复数百次的短作品。
- 还有人指出，记谱音乐和乐谱生成的边缘情况甚至比录制音乐的元数据更棘手。
审核、审查与法律焦虑
- 专辑封面和有争议的封面引发了对合法性（例如在英国）以及审查机构和 ISP 历史上如何封锁访问的担忧。
- 有人安慰说，很多人访问知名争议页面会让单独的“标记”不切实际，但对监视的焦虑依然存在。