在麻省理工学院媒体实验室的资格考试中，特里斯坦·杰罕（Tristan Jehan）博士问我：
“ 21世纪的“音乐录音机”会是什么样？
许多公司正在为此进行工作，并提供了一些有趣的选择。 许多功能具有机器学习，云协作或区块链的功能。 这些技术已经在改变音乐的创作和消费方式，我希望它们的影响在将来只会越来越强大。 但是，我的建议没有任何特定技术的特征。
在回答问题之前，我添加了一个额外的约束条件：我们如何以一种有助于音乐和音乐产业蓬勃发展的方式来设置这项技术？
新的录音技术不仅可以使创作者受益，还可以使音乐家，歌迷，制作人，研究人员，唱片公司以及整个音乐产业受益吗？ 可能吧 我在这里发布我的答案，希望反馈会引起讨论并加强想法。 也许通过合作，我们可以朝着积极的方向推动音乐和音乐制作的未来。
将DAW翻过来
录音音乐在20世纪产生了巨大的影响，模拟和数字录音技术随着音乐品味和可能性的变化而共同发展。 录音技术的发展将在下个世纪继续。 制作和录制音乐的过程将如何变化？ 我们开始看到云计算，流媒体，机器学习和社交网络如何改变音乐创作过程。 本文介绍了一种投机性的下一代声音记录和音乐制作技术，并提出了如何在今天创建这种技术的技术蓝图。
互联网已经改变了音乐的作者，所有权，发行和消费。 我们将不讨论许多道德，财务或法律影响。 相反，目标是探索一种乐观的方式，使音乐和技术可以在二十一世纪共同发展，并为开始朝着这个未来奠定基础。
我们首先比较一下软件开发工具git。 Git既是一个开源软件项目，又是一个协议。 它使许多用户可以在一个软件项目上一起工作，并使分支和分支变得无关紧要。 通过GitHub，GitLab和Bitbucket等组织提供基于git基础构建的商业产品。 我为下一代音频工具设想了这种模型。 但是，音频比代码更复杂，音乐比音频更抽象。 我们可以从git的体系结构中学到东西，但是构建二十一世纪音乐创作所需的模块是不同的，即使复杂得多。
有哪些模块和协议对21世纪的音乐家有价值？ 在回答这个问题之前，我将逐步进行一个假设的（科幻小说）录音会议，介绍它与当今传统录音会议有何不同。
科幻小说工作室
乐队的制作人和贝斯手Jordan参加了她选择的DAW中的会议，以审查拉动请求。 几天前，乐队在录音室里挤塞，发现了乔丹想成为曲目基础的凹槽。 在工作室会议之后，她向几个朋友发送了指向会议的链接，以征求反馈。 这首歌收到了一些评论，并从歌曲作者那里请求拉人声。 她查看评论，并记下稍后与乐队分享的评论，并合并拉取请求以供乐队其余成员进行评论。
乔丹还订阅了歌曲编曲服务。 乐队完成录制后，自动化服务会分析整个三小时的果酱时段，并确定乐队演奏的三首不同的歌曲。 该服务在Jordan的帐户中创建了三个新会话，这些会话被组织成歌曲结构，包括前奏，诗歌，合唱和尾声。 约旦本地DAW生成的速度图相当准确，但是商业服务部门可以更好地处理时间签名更改，并且可以将耗时一个小时的素材准确地重新组织为三分半钟。 该服务还添加了表演的象征性转录：和弦的转录以及单个音轨的MIDI音符转录。
乔丹插入她的贝司吉他，点击DAW中的播放按钮，并录制一些录音和配音以组成贝司音轨，以在三分钟的安排中用上光版本替换上周果酱会议记录的刮擦音轨。 当她按下DAW中的“播放”时，来自低音的音频被记录并缓存在本地计算机上，并且还可以发送到云端，以便对其进行处理，存档和分析。 当她感到满意时，可以将结果转发给乐队的其他成员，以进行更多的配音。 自动化服务可以发送报价，以便在高端录音棚中对专业弦乐合奏进行配音。 乐队准备发行歌曲时，可以对其进行指纹识别，并附带版权和作者身份。 从那里，艺术家和机器人程序可以对最终曲目进行采样和重新混合，同时保留对权利和归属信息的引用。
Jordan可以为多个服务提供对她的词干的读取访问权限，并为目录进行混合写权限。 这些机器人可能是自动混音的机器人，单个混音工程师或两者的组合。 然后，Jordan可以将对混音目录的读取访问权授予流服务，如果这首歌很流行，它将对她，她的乐队以及混音和母带制作工程师进行补偿。 流服务使用回放统计信息注释主混音。 其他服务可以读取统计数据，这些数据可以推动进一步的融合，或者建议Jordan如何组织乐队的下一首单曲。
在此过程中的任何时候，Jordan都可以将新曲目的粗略组合发布到流服务。 混音可能不会非常优美，但仅可用于乐队的直接支持者。 如果Jordan允许，听到初始混音的支持者可以提出拉取请求，分叉项目或请求采样的许可。
我们可以想象很多服务可以适合这样的系统。 和弦进行和安排推荐服务。 音乐教育理论或编曲辅助工具。 机器人会抓取网络中的非法复制材料。 当今市场上有许多可能适合这种系统的组件。 Splice允许用户备份，共享和分派DAW会话，iZotope Neutron将尝试生成通道条预设，从而尝试自动缓解混合伪影（如遮罩）。 Hooktheory通过数以千计的歌曲数据库可视化和比较和弦进程。 Propellerhead和其他公司提供集中的“应用商店”，出售或出租音频效果和合成器。 Ohm Studio和Soundtrap是基于实时协作云的DAW。 这些服务利用了当前的互联网平台化趋势，其中成功是由市场份额来衡量的。 遵循这些服务以得出合理的结论会导致用于创作音乐的工具趋同，并且音乐本身趋于趋同。
另一种未来是从git的成功中获得启发的。 在这个未来，许多开发人员可以在开源协议的基础上构建模块，而不必陷入围墙花园中。 遵循此模式的逻辑结论揭示了用于各种协作和音乐创作的工具的丰富多样的生态系统。 在关于可以建立这样的系统的技术基础的建议中所遵循的内容。
术语
在下面的技术说明中，明确定义了以下术语：
注释 -有关会话，曲目或资产的时间戳信息或说明。
艺术家 —正在创作音乐的用户。
音频资产 -波形的原始数字编码。
DAW —数字音频工作站
元数据 -有关曲目和资产的数据。 例如，“作曲家”，“表演者”，“导体”。
插件 —由DAW托管的扩展。
资源访问接口（RAI） -用于访问艺术家的会话和资产的服务的软件接口。
服务 -服务是用于处理和注释音频会话的模块化工具。 服务可以接受和返回音频，音频会话，符号音频或元数据。 例如，服务可能接受音频会话作为输入，并返回带有时间戳的和弦变化列表（注释）。 另一项服务可能接受歌曲会话作为输入，并提供流媒体访问该歌曲的母版，以供粉丝收听。
会话 -由DAW保存的文件，包括布置，路由，插件，资产，资产引用。
Symbolic Audio Asset-原始音乐资产，以符号编码。 例如，一个MIDI文件。
轨道 —渲染的会话，通常是立体声音频文件。
技术要求
像上述系统那样的系统如何工作？ 本文的目的不是设计每个模块化构建块，例如自动音乐分析，转录和混音。 相反，其目的是描述可以在其上构建这些模块的系统。 理想情况下，这样的系统将为音乐创作者提供在其创作过程中使用各种工具的自由，同时激励研究人员和开发人员创建可以创造性和有趣的方式一起工作的模块化工具和插件。
传统上，音乐制作工作流程中使用的工具遵循一个顺序（例如：作曲，录制，制作和发行）。 当所有这些操作都在支持云的工具链中执行时，我们可能会停止将它们视为一个序列：即使将轨道发布到流服务中，轨道的组成和生产仍可以继续。 该曲目可以被其他艺术家和合作者采样，覆盖或混音。 每个步骤都可以自动化，每个创意和技术决策都可以由数据驱动。 所有这些功能都可以集成到工具链中。
下一代合成和录制工具如何才能利用协作和数据驱动的功能，同时促进结果的创造力和多样性？ 这种创建和录制音乐的方法代表了与传统方法相比发生的重大转变。 这些工具将需要大量发展。
我们的内部设计师可能会想像一下使用未来DAW的用户体验。 有了经验，我们便可以向后进行技术实施。 这种方法具有风险，因为它迫使我们同时回答许多不同的设计问题。 设想和设计完整的体验还为时过早。 我们必须先创建git才能创建Github。
与其尝试重新构想整个音乐流程，不如让我们从可以在其之上构建新音乐工具的基础模块开始。 从本质上讲，这涉及将DAW内翻，并将其内容暴露给云，艺术家和服务可以在其中进行采样，重新混合和交互。 如果我们做对了，新的创意工作流程将自然而然地出现。 我们可以评估艺术家如何使用这些工具，并利用我们学到的知识为进一步的开发提供信息。
Git对象
返回到我们之前的比较，请考虑git构建的基础对象：
- Blob-二进制数据存储，通常是文件的内容。
- Tree —具有指向其他树和Blob对象的命名指针的树数据结构
- 标记 —指向对象。 包括注释以及对象，类型和标记头。
- 提交 -指向树。 包括评论和标题：
- tree —树对象
- parent-所有父提交的sha1
- 作者 -进行更改的人的姓名
- committer —提交者的姓名
git存储库使用主机的文件系统来存储这些对象，并通过其sha1哈希进行寻址。 基本的git命令负责创建新对象，并根据现有对象更新本地和远程文件系统。 这些简单的原语使复杂的各种命令和协作工作流成为可能。 请注意，提交对象封装了属性，并且在将对象推入或拉出远程存储库时，属性随对象一起移动。 另外，git不会尝试解决依赖关系和程序包管理，而是将其留给其他兼容或互补的服务，例如pip和npm。
音乐系统看起来像什么？ Git对象旨在描述代码库演进中的状态。 编写代码的方式与编写音乐的方式非常不同。 因此，此处提出的音乐图元的角色与git对象的角色不同。 这不是模仿git（版本控制）的功能并将其应用到音乐中，而是针对基础架构的设计建议，该基础架构可以启用上述简介中描述的各种协作和计算音乐创建过程。 考虑到这一点，请考虑以下对可以整合到音乐创作过程中的音乐资产“对象”的描述。
音乐对象
音乐对象的作用是创建从资产到注释和元数据的可寻址连接。 例如，考虑架子鼓的立体声混音。 有许多不同的使用方式。 对于过度配音，它可能是从头开始的曲目。 可以将其转换为样本库。 可以将其解构为Rex样本。 可以将其转录并转换为符号资产。 它可以用作将格罗夫模板应用于其他轨道的基础。 以任何这些形式，它都可以用作生成音乐或音乐信息检索的数据点。 如果音乐资产库可以通过其注释和元数据进行保存和搜索，则可以构建任何数量的作曲辅助工具，采样和混音工具。
与资产有关的所有信息都可以通过内容可寻址系统访问。 像git一样，资源将通过其40个字符的十六进制sha1哈希来标识。 这使它们可以保存在本地存储库中的git对象之类的文件系统中，或被URI明确引用。 如果本地文件的内容发生更改，则元数据可能不再准确，必须重新计算。 如果本地资产文件名更改，则哈希将保持不变，并且仍可以通过其哈希来识别文件。
音乐元数据和注释序列化
在诸如Facebook之类的服务中代表用户的文档将包括通常包装在HTML或JSON中的属性和关系的集合。 对于诸如Facebook之类的常规Web服务，定义了组成用户个人资料数据的属性和关系的逻辑示意图不应缩进外部使用。 每个实现用户帐户的常规Web服务都负责定义和维护内部“用户”示意图。
使用这种常规方法可以设计基于云的音乐制作工具。 每个服务可以设计自己的数据模型，并负责解析上游服务的注释。 和弦注释服务将实现自己的数据结构，以对歌曲时间轴进行建模。 该服务将访问客户的音频资产，以自定义格式保存和弦注释，然后将结果返回给客户。 这实际上是当今存在的模型，并被Splice.com等服务所采用。 这种方法并非没有优势。 首先，它很简单。 每个服务开发人员都可以定义最适合其需求的模型。 因为服务开发人员将编写自己的原理图，所以他们毫无困难地理解它。 这种方法得益于“关注点分离”设计原则。 单独的服务开发人员不需要了解任何一种特定的资源定义语言，而可以使用他们最熟悉的任何方法。
但是，目标是促进彼此交互的许多服务。 现有的基于平台的模型促进了我们已经拥有的生态系统：每个平台都通过其市场份额来衡量成功。 每个用户只有在其用户独占时才能从“网络效应”中受益。
由W3C创建的Web本体语言（缩写为OWL）和资源定义框架（RDF）提供了一种标准化的语言，用于显式定义本体示意图和关系，并在这些示意图中描述数据。 W3C语言在设计时就牢记此用例：本体和知识图不由任何一项特定服务拥有或管理。 相反，可以将诸如资源类和关系之类的本体原语分布在许多不同的Web服务器上，并使用URI进行引用。 例如，考虑以下三个方面：
RDF将这一知识分为三个部分：一个主题（JS Bach），一个谓词（是它的作曲者）和一个对象（Goldberg变体）。 使用RDF，这三个部分的每一个都可以由URI引用。 这样，许多Web资源可以访问相同的谓词，从而在人员和作品之间分配公理和机器可读的关系。 设计语义网，以便可以使用现有的DNS和HTTP协议以分布式方式定义本体结构。
MIR研究人员提出了一种描述音频功能（包括注释和元数据）的标准化方法。 Gyorgy Fazekas的一篇论文描述了软件应用程序（例如DAW）如何以标准化但可扩展的方式读取和写入元数据（Fazekas，2009年）。 该格式利用了RDF和W3C为Web上语义“链接数据”提出的标准（加拿大，2010年）。 本体标准为DAW，服务和插件开发人员提供了主要好处。 拟议的本体将元数据描述符（如“艺术家姓名”，“作曲者”）以及音乐时间轴功能（如节拍位置和和弦变化）标准化。 这允许许多不同的服务识别彼此的注释和贡献。 RDF为开发人员提供了一种方便的机制来创建其他注释类型，并将这些规范发布到Web。
语义方法有很多优点。 在上面的示例中，许多不同的服务都对艺术家的资产，注释和元数据执行操作。 如果以明确定义的明确格式编写逻辑示意图，则开发人员可以围绕共享逻辑示意图组织服务，从而消除冗余并提高互操作性。 如果现有音乐本体所支持的音乐注释不足，则服务也可以设计，记录和发布替代或扩展现有本体的新注释。 这意味着原理图必须是通用的，开发人员必须学会使用RDF。
请考虑本文档开头的示例。 艺术家的会话和资产被提供给几种不同的服务。 每个服务都添加和更新了自己的资产。 所有服务都必须能够解析彼此的元数据和注释。 同时，每个服务都可以定义其自身对现有原理图的扩展。
资源访问接口
在本文开头的示例中，Jordan允许第三方服务访问和更新其DAW会话。 另一个服务获得了对其会话和曲目的读取访问权限，并为她提供了附加注释。 她如何控制对会话的访问并跟踪资产？ 她的所有资产都需要在互联网上访问。 使资产可访问的服务器需要对服务和个人的读写访问请求进行身份验证和授权。
上载资产
该服务的实际实现可以按以下方式进行。 首先，在录制过程中创建的资产必须上载到资源服务器。 录音工程师计算机上的软件守护程序监视DAW的资产目录，类似于Dropbox和Google Drive这样的服务。 检测到更改后，所有新创建或更新的资产都将上载到资产服务器。 可以使用一种由rsync实用程序完成的单向文件同步算法来完成（Tridgell，1999）。
录制音乐的过程会产生大量的元数据，包括但不限于表演的时间和地点，所涉及的音乐家，所使用的录制技术，所有这些都可以在语义上与音乐作品和安排联系在一起。 个人表演，表演。 多轨本体（Fazekas，2008）详细描述了用于创作由录制会话产生的元数据的语义属性和工作流程。 录音室本体（也由Gyorgy Fazekas撰写）也可以描述诸如麦克风类型和放置之类的录音技术。 理想情况下，将在录制会话时添加录制会话中所有可用的元数据，并且可以由录制工程师以及艺术家对其进行编辑和更新。 这给我们带来了资源服务器的另一项技术要求：它必须公开一个接口来创建，读取，更新和删除（CRUD）资产，注释和元数据。
CRUD操作
有两个选项可以对链接的数据执行CRUD操作。 首先是通过SPARQL查询。 SPARQL是一种查询语言，专门用于链接数据，并由W3C进行了标准化。 它具有非常灵活的查询语法，可以对链接的数据进行复杂的查询。 专用查询语言的确要付出代价：因为用SPARQL编写的查询具有灵活的遍历链接数据图的灵活性，所以写得不好的查询会淹没服务器资源。 可以通过使用D2RQ之类的中介来缓解这种情况，该中介将SPARQL查询转换为SQL，以在链接了数据的传统关系数据库上运行。
第二种选择是使用标准的HTTP方法和标头，类似于传统的REST接口。 在社交链接数据（SOLID）规范中提出了此方法。 SOLID REST规范包括一些其他要求，例如，在使用HTTP GET方法检索数据时支持通配符“ glob”。 SOLID项目还包括基于组的身份验证和授权的声明性规范，称为Web访问控制。 许多现有的实现方式以及完善的基于中间件的身份验证和授权请求方法，使开发REST风格的接口变得更加容易。 但是，它不能支持SPARQL提供的更复杂的查询，这些查询是为搜索和操纵链接数据而明确提出的。
元数据存储
与未压缩的音频资产相比，注释和元数据消耗少量存储空间。 在服务器上保存链接数据的最简单选择是使用服务器的文件系统。 在此模型中，元数据将保存为W3C支持的链接数据文件.rdf或.n3格式。 例如，一个使用时间轴和音乐本体对音乐注释进行编码的.n3文件（Raimond，2007年）可以通过以下方式引用：
https://example.com/m/46eee28edc90bef1cd58f2db9d626ec8cb350546/timeline.n3
其中40个字符的十六进制字符串是时间轴所指音频资产的sha1哈希。 使用此模式可使Apache或Nginx服务器以最少的配置运行简单的服务。
但是，与基于文件系统的方法相比，现代Web服务需要更高级的身份验证，授权，数据验证，备份，查询和扩展。 因此，常规方法是将HTTP服务器放在数据库的前面，这样可以提供更大的灵活性和定制性。 围绕链接数据和数据库的问题的完整讨论超出了范围。 我们将重点介绍一些关键因素。
如果整个链接的数据集足够小以适合单个服务器，则可以使用集中式数据存储。 例如，Jena2是一个基于Java的工具包，用于在集中式SQL数据库中存储和查询主谓谓三元组（Wilkinson，2003年）。 Jena2支持RDF序列化格式（包括N3和RDF / XML）的输入和输出。 它还支持SPARQL查询。 如果链接的数据集不能容纳在一台计算机上，则必须使用分布式RDF存储。 D-SPARQ是一个基于MongoDB的RDF查询引擎，该数据库是一个NoSQL数据存储，旨在跨多个服务器垂直和水平扩展（Mutharaju，2013年）。 D-SPARQ使用MongoDB内置的Map / Reduce功能，但不接受SPARQL查询。 Amazon Web Services提供了另一个可扩展的选项。 AWS Neptune是一个受管理的分布式图形数据库，支持RDF对象和SPARQL。 在链接数据：存储，查询和推理 （Sakr，2018）中可以找到有关许多其他RDF就绪数据库选项的最新讨论。
储存资产
音频资产比元数据大，应通过不同的机制进行存储和公开。 在提出的模型中，服务可以查询注释和元数据。 如果服务需要查询音频本身，则可以直接请求音频。 艺术家应该控制哪些服务可以访问哪些资产，元数据和注释。
在Web服务器上存储诸如音频资产之类的大型二进制文件的简单方法是使用该服务器的文件系统。 但是，通常会避免这种情况，因为它对最佳实践（例如版本控制和自动冗余分布式备份）提供的支持有限。 更加灵活的开源选项是GridFS，这是用于在MongoDB集合中存储大文件的官方规范和API。 这利用了为MongoDB进行的内置复制和备份过程。 或者，商业服务可以提供交钥匙服务，以节省大型二进制Blob，并将这些Blob暴露给万维网。 AWS S3允许Web客户端代表服务上传和下载大型资产。 对存储在AWS S3存储桶中的资产的访问可以受可自定义的身份验证和授权参数的约束。
DAW会议
我们已经描述了启用云的服务如何充当资产，注释和元数据的存储库。 那DAW会话文件呢？ RDF与音乐本体相结合，为元数据和注释提供了功能强大的标准集合。 但是，引言中介绍的服务不仅可以编辑元数据，还可以集成到数字音频制作工作流程中。 提议的服务之一自动解析Jordan的DAW会话，并通过自动将乐队的果酱编辑成前奏，诗歌，合唱等内容来重新组织会话。为此，服务必须能够访问和反序列化会话信息。 访问并不复杂。 会话文件可以以类似于音频资产的方式通过云上传和分发。 但是，修改DAW会话的服务必须能够解析会话文件。 会话文件格式非常不同，不同DAW支持的格式之间的互操作性受到限制。
一种选择是考虑到基于云服务的工作流程从头开始创建新的DAW，并发布会话规范。 它使我们能够直接在DAW中建立支持，从而使更复杂的功能（例如实时流协作）更加容易。 这样可以确保兼容性，但是这意味着我们需要创建DAW，并激励艺术家使用它。 这似乎是不可取的，因为DAW是一个竞争非常激烈的领域，但是许多新的基于平台的协作DAW正在开发中。 示例包括Soundtrap，Ohm Studio，BandLab和Amped Studio。 但是，我们的目标不是创建常规意义上的新平台，因此将更好地支持现有的音频制作工具。
另一种选择是编写会话格式规范。 RDF兼容格式的“编辑决策列表本体”是一种可能的格式。 这将允许我们创建会话转换器，例如，将Reaper保存的.RPP会话格式转换为我们的可移植格式。 我们还可以要求DAW开发人员包括对导出到我们的自定义格式的支持。
或者，我们可以使用现有的会话文件规范。 开放的DAW标准具有历史先例。 1993年，Avid Technologies发布了开放媒体框架，该框架旨在允许不同DAW之间实现互操作性（Lamaa，1993）。 出于相同目的而分别创建于2000年和2004年的两个后续标准AES31（Yonge，2000）和AAF（Tudor，2004）。 不幸的是，真正的DAW互操作性并不简单。 AAF格式包括对样本精确编辑决策列表的支持，淡入淡出以及某种程度上的自动化。 但是，它不支持路由，总线，MIDI和音频插件配置。 由于不同音频工具的众多功能正在不断发展，因此创建一个精确再现DAW中每个可能参数的标准是不切实际的。 现有的商业DAW会话翻译器（例如AATranslator和Vordio）建议，对某些功能的显式有限支持是一种更为现实的方法。
Studio One，Pro Tools，Logic，Nuendo，Digital Performer，Final Cut Pro和Premier支持AAF编码，但是Reaper，Ableton Live，FL Studio，Bitwig Studio，Ardor或Reason不支持AAF编码。 我们能否期望云服务采用AAF格式？ 有一些障碍。 与W3C发布的RDF标准不同，没有用于扩展或维护该规范的过程。 此外，与RDF不同，AAF等旧格式不包含任何以分布式方式发布对给定规范的扩展的方法。 RDF的定义功能是支持不断发展的可扩展定义。 仅存在用于解析AAF文件的C ++库。 同时，诸如协议缓冲区之类的现代通用二进制格式具有许多不同编程语言的库，以及对版本控制和向后兼容的内置支持。
无论是编写自己的规范还是使用旧格式，标准化DAW会话文件格式都会遇到障碍。 通过将解析会话文件的问题完全留给服务开发人员，可以避免这些挑战。 为了创建将乔丹的会话文件组织成歌曲部分的会话重组服务，每个服务都可以准确地宣传其支持的会话文件格式。 这将分散服务的互操作性，但也会鼓励DAW开发人员向服务开发人员公开其会话文件规范。
最后的选择涉及为了简化操作而对服务功能进行交易。 我们可以将服务交互限于原始音频资产。 在这种情况下，对音乐感兴趣的艺术家可以在上传音频文件以供云服务处理之前，从会话中渲染音频文件。 这极大地限制了可用服务的类型。 例如，服务无法以编程方式更改混合，而是将这些混合自动发布给面向流服务的客户。
摘要
我们描述了给定基于云的重新设计，分布式体系结构以及对开放和可扩展标准的关注，音乐创作，录制和制作过程将如何发展。 可视化此方法的一种方法是“将DAW内翻”，并将其内容暴露给一系列人工和自动协作者，目的是鼓励新的和以前难以想象的音乐制作过程。 这与传统的DAW相反，传统的DAW通过嵌入资产和插件，集中工作流以及（通常）通过将用户锁定到特定平台来工作。
我们描述了如何构建服务的技术基础，并在可能的情况下使用现有标准。 一些实现细节留给以后的工作。 艺术家需要一种强有力的授权策略来指定哪些服务可以访问哪些资产。 我们讨论了将元数据与资产捆绑在一起的含义，即当艺术家对现有曲目进行采样或重新混合时，可以在制作过程中建立归属。 这是一个好步骤，但是我们仍然需要使上游艺术家得到补偿的付款或交易系统。
全面的愿景考虑了在我们不再需要明确音乐创作，录制，制作和消费之间的界限的时代，创作音乐如何继续发展。
