本文共计3600字，阅读大概需要5分钟
创作者的马斯洛需求层次
据不完全统计，创作者对音频剪辑工具的马斯洛需求层次大致分为以下几个阶段：
1、基本剪辑需求：
录音、本地上传、波形绘制、多轨道、音频切割、音频拖放、播放试听、合成导出
此类需求是一款音频剪辑工具的必备技能，借助这类需求，创作者便可以完成小到一期播客，大到一整个系列的有声书制作。由于是必备技能，市面上的剪辑工具基本都涵盖这些范围。
2、效率提升需求：
音频打标、音频多选、混响、音频调音、云端协作等
此类需求对于经常做高强度剪辑的创作者来说较为熟悉，比如打标可以帮助创作者标记声音高光片段，在动辄几十个音频中快速定位，再比如多选可以帮助创作者在剪辑过程中快速对轨。不同剪辑工具对此类功能的实现和体验各有千秋，比如打标由某知名客户端剪辑工具推出和推广开来，随后被大家借鉴，而云端同步和协作对于在线类的剪辑工具来说有着天然的优势。
3、大模型时代需求：
TTS， AI配乐，AI包装，文本剪辑、一键成片
这是一个充满想象力的阶段，算法模型的百花齐放给音频剪辑工具也带来无限可能，比如TTS提供了把文本转为声音的能力、NLP和文生图提供了为声音生成标题大纲还有封面的能力、ASR提供了通过可视化的文本来剪音频的能力。
4、终极需求：
“我没有音频素材，但是我想要生成一期播客作品”
这是我到了交稿期限但是还没开始做时的需求...
云剪辑
作为喜马创作者生态主推的音频剪辑工具，云剪辑诞生之初就以“为创作者打造一站式音频剪辑解决方案”为己任，在音频剪辑和主播创作工具的道路上越走越远。
鉴于我们正处于并可能将长期处于模型时代阶段，我们希望云剪辑的一系列智能化解决方案被大家所认识，并从功能使用和代码实现中获取一点点思考，顺便增加一些没用的知识。
这期我们先来介绍云剪辑的文字剪辑。
文字剪辑应用场景
音频剪辑过程中的痛点有很多，其中之一就是相对于文本和视频，声音是不可见的，声音波形不像文字或者视频帧可以快速有效预览，剪音频的过程就是一个剪辑、试听、再剪辑的无限循环，只要音频够长或者录制的质量够差，那这“剪辑-试听-再剪辑”的循环便没有了尽头。
那有没有一种方式可以“可视化”的剪音频呢？比如：
•可以快速点击定位到音频中的某句话或某个字，而不是凭感觉反复在音频上定位试听查找
•可以通过文字搜索声音中的片段，而不是依赖试听
•可以一键清除口水词和气口，而不是试听查找再剪掉
•可以通过拖选快速删除录制过程中的说错话片段，而不是在错误的开始剪一刀，然后在错误的结束剪一刀，最后把错误删掉，最最后把后面错位的音频往前移
答案是有，那就是文字剪辑。
功能使用
文字剪辑涵盖了按字剪辑、搜索、速选、口癖检测和移除、气口检测和移除、标记等功能，上手使用较为简单，这里就不多介绍了，小伙伴们感兴趣的话可以在云剪辑里体验一下，这一Part我们跳过。
功能实现
模型能力
实现文字剪辑的前提条件是ASR能力，它可以将人类语音内容转为对应的文字，比如下方的数据结构，就是基于ASR能力生成的：
工程化
有了ASR基础，接下来就是工程化。文字剪辑本质上是在传统的音频剪辑基础之上新增一个平行的文字剪辑模块，并使音频和文字模块联动起来，由此可得，我们需要先实现一个文本模块，负责如下事项：
•渲染声音所对应的文字：方便剪辑时对音频内容一览无余
•文字支持点击定位并高亮：方便快速定位音频播放光标
•文字支持搜索高亮：方便快速查找定位
•文字支持拖选并弹出删除框：方便一键删除文字对应的声音内容
•句子支持高亮：方便播放音频时用户实时了解到当前播放到哪里了，内容是什么
•段落支持快速选择：方便快速删除内容连续的声音
•口癖词识别：方便根据用户给出的口癖词列表标记出全文范围内的口癖词，待后续删除
•气口识别：方便根据检测出的气口的时间点，在对应位置插入气口标识，待后续删除
•标记识别：方便识别打过的标记，并插入到文本中对应位置
看起来很复杂，其实一点也不简单。
比如点击大段文本中某个字的时候字要高亮，同时把播放光标移到字对应在声音中的位置，大家第一时间会想到用元素把那个字包起来，并通过css让它高亮，至于字对应的时间，可以使用Selection API获取该字在文本中的索引，然后通过索引去ASR数据中取它在音频中对应的时间。
一动手发现不管是额外元素的包裹还是跨段拖选场景，Selection API获取索引的效果都会受影响，而且由于剪辑过程中文本在不停的被删除，索引的准确性是无法保证的。
架构设计
经过漫长的5分钟思考我们悟出：最小的dom单位或者组件单位要落在字上。
分层
字层面
每个字都可以抽象为一个Word组件，将自己的开始、结束时间保存在state中，并注入dom的data-attribute中。Word可以根据当前播放光标时间点计算自己是否是那个定位高亮的天选之字，根据拖选时间范围计算自己是否被拖选了，根据props里的标识得知自己是否为口癖词的一部分。
句层面
N个Word组件可以组成一个Sentence组件，根据当前播放光标时间点计算自己是否是那个播放中需要高亮的天选之句，还会检测当前句中是否包含口癖词或搜索词，如果有则告诉对应Word组件它是口癖词或搜索词的一部分。
段层面
N个Sentence组件可以抽象为一个Paragraph组件，同上。唯一不同的是Paragraph承载了一部分性能优化的任务，后面讲。
由此文本模块便成为了段-句-字的三级结构，在此基础上我们加入一些通用能力：
比如文本的拖选：通过SelectionAPI或取范围内的第一个字的开始时间和最后一个字的结束时间，即拖选的文本/音频时间范围。
和处理一些边界case：
比如拖选内容跨了两个音频对应的文本，则需要通过补上前一个音频的结束时间和后一个音频的开始时间，组成两个区间，才能分别去对应的两个音频上删除
再比如从文本上开始拖，然后拖出了浏览器窗口，此时是检测不到结束字的，所以要通过开始字查找所在Paragraph中的结束字来形成有效的封闭时间范围。
通道
说完文本模块，来说说通道。从上面文字剪辑的gif或者实际体验下来可以发现音频板块和文字板块之间是有联动的，这些联动由通道传递。通道负责共享方法（如删除、定位等）和传递数据（如光标所在时间、拖选区间范围等），以及计算工作（如删除一段音频时，自动计算出剩余音频所对应的文本）。通道包含一系列store和util等，共同完成数据的同步工作：
比如在音频时间轴或文本上点击定位的时候，另一方的光标也会定位到对应时间点。
比如删除音频或文本时，另一方的内容也会同步删除。
比如在文本上拖选时，音频上对应的区间也会有拖选高亮标识。
比如音频或文本上打标记，在另一方也是完全同步的。
比如随着播放光标持续移动，屏幕外的文本会被拉到屏幕中，哦这个和通道关系不大...
总之声音面板、文本面板、通道，共同组成了一个完整的文字剪辑模块，来看下最终的架构图：
性能优化
性能问题
大家应该已经发现了以字为最小单位的模式会产生非常多的组件和dom节点，这对于性能有着巨大的负担。事实上早期的云剪辑不支持按字剪辑，而是以句为最小单位，在长音频/长文本场景下已暴露性能问题，按字剪辑上线后组件数量急剧膨胀，使得这一问题暴露的更为直接，以至于在文本上点击定位、拖选、删除等操作时伴随着明显的卡顿。（配图为早期按句剪辑在长音频下的体验，gif展示有点问题，只会展示前几帧，看不到完整过程）。
优化方案
解决方向有两个：
1、减少dom数量
Paragraph组件通过IntersectionObserver检测自己是否在视窗内，在视窗内时启用完整功能，在视窗外时，将内部的众多Sentence和Word降级为纯文本（样式和真实组件一致），并以低性能消耗的方式实现口癖词和搜索词的高亮，以保证搜索词、口癖词的数量统计展示以及快速跳转能力。
2、优化拖选检测
早期版本为了解决拖选跨文本（拖选了不同音频对应的文本）等问题，在拖选时每个最小单位都通过绑定事件，判断自己是否被拖选，被拖选者依次后去store中更新拖选范围起止时间，然后根据store中传下来的拖选时间范围判断自己是否要高亮，这其中存在执行次数过多和组件无效渲染问题，后来改为鼠标抬起时检测选区首尾两个字的时间来确立选区时间，并单独处理跨文本拖选等问题，然后去store中设置选区时间，触发对应文字的拖选高亮。
优化效果
（gif展示有点问题，只会展示前几帧，看不到完整过程）
以一个3小时，约4.5w字的音频为例，优化前后耗时对比如下，详细对比视频可参考ASR剪辑重构总结
| 旧版 | 新版 | |
| 渲染 | 2000 | 600 |
| 拖选 | 3000 | 400 |
| 删除 | 2000 | 500 |
| 文本定位 | 2000 | 200 |
| 音频定位 | 1000 | 100 |
| 撤销 & 重做 | 1500 | 100 |
结语
文字剪辑是云剪辑在提升音频剪辑效率道路上的一次尝试，我们相信在算法和工程小伙伴们的共同努力之下，创作者马斯洛需求层次的最高层次终将到来。
作者:zhenjiang
来源-微信公众号:喜马拉雅技术团队
出处:https://mp.weixin.qq.com/s/wWnMwYKBPaEk_5CJsTAR5A