音乐 - 基础属性

artistList

表演者列表

星球发行数据库中存储的纯文本。但是分隔符没有统一，以下情况在数据库中都真实存在：

坡上村乐队/常石磊
Y-Man,Ono,Fat B,Vyan
王嘉尔

在用户使用的录入交互中，使用的是输入框列表，所以在接口层目前使用数组，如 ['Slash', 'Rose', 'Duff']。发行或者展示时，自行根据实际需求处理。

后面的 arrangerList、composerList、lyricistList、featList、producerList 同格式。

据说 DB 中 ',' 分隔的是脏数据，统一使用 '/' 分隔

参考 DDEX: DisplayArtistNames for Releases and Resources

arrangerList

编曲者列表，格式同 artistList

composerList

作曲者列表，格式同 artistList

版权系统中，作曲权和编曲权是两个独立的版权类型，且版权拥有方（作曲者/编曲者） 不一定 是同一个人。

featList

featuring/ft. 列表，格式同 artistList

在音乐领域，"featuring" 是指某位歌手或艺人在一首歌曲中的特别合作表演。这个词通常出现在歌曲的标题或艺人名称中，表示该歌曲是由多位艺人合作演唱或演奏的。

例如，一首名为 "Beautiful" 的歌曲的完整标题可能是 "Beautiful (feat. Christina Aguilera)"，这里的 "feat." 就表示该歌曲中特别邀请了 Christina Aguilera 参与表演。

此处 "featList" 即用于描述歌曲中邀请的特别合作表演者。

genre / subGenre

专辑和歌曲的风格（流派）信息，由主风格 genre 和子风格 subGenre 组成，如

{
  genre: 1, // 流行
  subGenre: 1001 // 流行舞曲
}

音乐风格没有通行的行业标准。星球发行有自己的音乐风格选项列表，格式为两层的树结构，参见中台系统风格选项树和 SOP 系统风格选项树

用户通过星球发行 Web 系统维护歌曲时，需要通过二级级联菜单录入风格信息，且主次二级都是必选；如果是大客户合作走批量入库，则需要上下游约定数据对标信息，入库写入时以星球发行的风格为准。

前端相关

因为有 i18n 的需求，后端返回的数据，只包含数字类型的 ID，不包含展示名，前端需要通过选项树自行格式化
存量数据有脏数据，比如 只有一级没有二级，或者 一二级都缺失，展示时需要做兼容
不少系统中，前后端约定使用 genreList: [genreId, subGenreId] 的数据格式。这种数据格式和级联菜单天然友好

实际情况中，除了单曲专辑之外，专辑的风格设定，和专辑内歌曲的风格未必一致，所以两者需要分开填写。

isExplicit

脏标，欧美系内容年龄分级系统下的产物，代表了是否包含暴力、脏话甚至宗教敏感话题等内容。

可选值：

无
有
纯净版（原本包含不适宜内容的歌曲，顺应发行市场所在地法律要求，过滤掉不合适的内容，独立发行的版本）

早期的产品设计，概念定义为 有无脏标，系统字段定义为布尔值，取值分别为 0 和 1。

后来改成选项，取值扩充为 0、1、2，但是 字段名仍旧延续了布尔值的命名

参见 https://zh.wikipedia.org/wiki/家长指导标识

isrc

国际标准音像制品编码 (International Standard Recording Code)

简单理解为唱片工业领域，每首发行的歌曲都需要分配的唯一识别 ID。

未发行过的歌曲，使用星球发行的服务发行上架，我们需要在发行前协助申请并赋予 ISRC。

参见 https://zh.wikipedia.org/zh-cn/国际标准音像制品编码

language

歌曲的语言（即歌词语言）

后端存储数字类型的 languageId。界面呈现有 i18n 的需求，前端需要自行格式化语言对应的文本展示。

注：有一个固定 id === 1000 的选项，含义为 "无歌词"，会和作词者、歌词等存在逻辑关联，比如选中后，lyricistList 强制重置为 []

参见 SOP 系统歌曲语言选项

关联字段：lyricistList

lyrics

歌词

纯文本，有些歌词会包含时间戳信息。会包含 \n 换行符。

lyricistList

作词者列表，格式同 artistList

如果 language 选择了 1000，则自动重置为空数组

关联字段：language

musicType

音乐类型

当前系统中，日常提到的 音乐 是一个广义的称呼，具体到商业应用场景，细分为 音乐、采样、音效 三种类型。

音乐：常规歌曲，一般以专辑形式发行，面向最终消费者
采样：某些原始的声音片段素材，一般面向音乐制作人，大多供下游音乐制作使用
音效：通常面向工业领域，如电影、游戏中的刀剑、风雨雷电等声音

曲库中现有枚举：

enum MusicType {
  // 音乐
  MUSIC,
  // 采样
  SIMPLE,
  // 音效
  SOUND_EFFECT,
}

name

歌曲名称

当前数据库中，存在 name、english_name 、name_list 三种歌曲名称数据，分别对应了中文名、英文名、多语言自定义名称列表三种数据。系统设计角度，存在合并和优化的空间。

不同系统中，名称的展示字段 没有统一，比如

系统	中文名字段	英文名字段	默认名称（映射）	其他规则名称
SOP	`chineseName`	`englishName`	`name`
MusicHub	`chineseName`	`englishName`	`name`
MusicVerse			`defaultName`	`nameList`

其中，仅在 MusicVerse 中，使用了 nameList 的数据作为呈现。数据格式为：

{
  nameList: [
    { language: 1, name: '高级动物' }, // 国语名称
    { language: 3, name: 'The higher being' } // 英语名称
  ]
}

展示为：

<p>国语：高级动物 </p>
<p>英语：The higher being<p>

position

歌曲在专辑内的序号，自然数

producerList

制作人列表，格式同 artistList

仅在 MusicVerse 中存在

src

音频文件地址，数据库中存储的只有 OSS 相对于根目录的路径，接口层多为签发好的 OSS 文件访问地址。

以后可能考虑统一抛出 OSS 路径，由前端调用 OSS SDK 或者后端提供独立接口签发地址，避免缓存控制问题

version

歌曲版本。包含了固定的选项 通用版本、Live 现场版、DEMO，和用户自定义版本。

最初系统设计时，界面只有文本录入，没有分拆固定选项和自定义文本，所以数据库存了纯字符。

这导致了后续支持选项式交互和 i18n 时出现了格式化问题，比如：

用户选择了自定义录入
录入内容为 Live 现场版 / Live / Live 現場版

这样前端无法区分是自定义还是通过固定选项录入，只能强制对标为固定选项。

版本类型	版本展示中文	展示英文	展示繁体
0	`通用版本`	`Studio`	`通用版本`
1	`Live 现场版`	`Live`	`Live 現場版`
2	`DEMO`	`Demo`	`DEMO`
3	用户自定义内容	用户自定义内容	用户自定义内容

星发前台展示时，分拆了 versionType 和 versionText 两个字段作为辅助信息，走格式化函数完成 i18n 展示。

不同的后台系统中，版本的展示字段则 没有统一

系统	版本字段	格式
SOP	`version`	`{ id: number; name: string; }`
Musichub	`version`	`{ id: number; name: string; }`
MusicVerse	`originVersion`	`string`

SOP 系统和 Musichub 系统， version 使用了对标前台 versionType 和 versionText 的键值对，格式：

{
  id: 0, // versionType
  name: '', // versionText
}

界面上统一视作中文展示，但是保留了 i18n 的能力。而 MusicVerse 没有考虑 i18n 的需求，输出了文本类型的版本信息，前端直接打印。

关联字段：cleanedVersion

音乐 - 基础属性 ​

artistList ​

arrangerList ​

composerList ​

featList ​

genre / subGenre ​

isExplicit ​

isrc ​

language ​

lyrics ​

lyricistList ​

musicType ​

name ​

position ​

producerList ​

src ​

version ​