抖音怎么拍合唱(抖音怎么拍一半人一半歌词)

作者:洪洋

原文链接:https://mp.weixin.qq.com/s/EmS5WfBS61qG4CpKW37PyA

就在上周末，我们见证了一个全球性的音乐活动，一个世界在家里一起。整场活动聚集了大量的名人大咖，他们在家门口以网络直播的形式向全球观众献唱。其中有很多艺人同屏演唱歌曲，但这其实是被录制播出的。来自世界各地的数百名歌手，现场设备和网络条件存在差异，要进行实时合唱难度极大。

著名音乐电台DJ、SoundArio音乐基金会创始人加菲尔德说:

几百个歌手时差、现场录音、网络技术条件都不一样，不存在在线实时协作进行直播的可能。两个人连弹带唱都不可能，因为0.17秒的延迟足以抵消世界顶级音乐人的现场技巧。

这段话的延迟，《为什么》足以抵消世界顶级音乐人的现场技巧。我们举个例子来说明。以《稻香》这首歌为例。它的钢琴乐谱是4/4拍，标准音乐速度是80拍/分钟。合唱团每小节唱8到12个词，主要由八分音符和十六分音符组成，基本上每个音符对应歌词中的一个词。粗略来说，唱一个词大概需要200-300ms。

在不考虑伴奏的情况下，假设两个合唱A和B之间的端到端延迟为100ms。从声音传播过程来看:

A先唱，B听到A的歌声。此时产生100ms延时；B在听到A的歌声后开始加入合唱，歌声传到A端。此时又产生100ms延时；

那么A永远听不到B的歌也要200ms。按照之前唱每个词所用的时间计算，听起来至少会慢半个词，这是错位的。

如果考虑到伴奏的传递，以及伴奏与演唱的混合，情况就更复杂了。一般只要端到端延迟小于150ms，听者就感知不到。所以以“稻香”的速度唱一首歌，可以合唱，延迟不超过80ms。如果你唱一首歌词比较快，歌词比较密的歌，延迟要求会比较低，否则两人合唱永远得不到合适的时间，歌手的体验会很不好。中国距离美国一万多公里，光速30万km/s，光纤传输会有一些损耗，可以按照20万km/s计算，粗略按照中美之间15000km的物理距离计算，单向延迟约75ms，不可逾越的双向物理延迟约150 ms，而且一个世界的四人合唱场景一起涉及多方协作所以以目前的技术水平，很难实现远距离的多方合唱。在《同一个世界》中，我们看到的基本上都是录播。但无论是录音还是实时合唱，给观众带来最好的体验才是最重要的。

很多社交应用都有合唱的功能。是怎么做到的？

合唱中的延时

首先，我们来解释一下延迟是如何产生的。该场景中的延迟包括两部分:设备端延迟和端到端延迟。我们需要根据延迟的不同阶段来分析如何降低延迟。

音频采集端和回放端的时间延迟

图：音视频传输流程流程 图:音频和视频传输流程

在这里，音频=唱歌，或者说音频=唱歌+伴奏。

设备端上的延时包括采集端的采集、前处理、编码，播放端的接收、解码、后处理过程产生的延时，以及两端在编码后和解码前产生端网络延时。端上的延时主要与硬件性能、采用的编解码算法、音视频数据量相关，设备端上的延时可达到 30~200ms，甚至更高。

音频设备侧的延迟也可以细分为以下几点:

音频采集延时：采集后的音频首先会经过声卡进行信号转换，声卡本身会产生延时；音频播放延时：这部分延时与播放端设备性能相关；音频处理延时：前后处理，包括 AEC，ANS，AGC 等前后处理算法都会带来算法延时，通常这里的延时就是滤波器阶数；端网络延时：这部分延时主要出现在解码之前的 jitter buffer 内。

此外，合唱场景通常为用户提供各种KTV音效，即在语音编码传输前会增加一步预处理，这也会增加音频在结尾的延迟。

如果想降低音频在终端上的延迟，就需要针对不同的机型优化编解码算法，减少音频采集、编解码、音频处理带来的延迟。结束延迟也与设备性能和系统密切相关，如果其中一个歌手设备性能不好，也会影响合唱效果。

从终端到服务器的延迟

除了端到端的延迟，音频数据从端到服务器、从服务器到服务器的传输过程也会有较大的延迟，这也是阻碍“实时合唱”功能实现的重要因素。

影响采集端与服务器、服务器与播放端之间延迟的因素有几个:客户端与服务的物理距离、客户端与服务器的网络运营商、终端网络的网速、负载、网络类型等。如果服务器部署在服务区附近，服务器和客户端的网络运营商相同，那么影响上下游网络时延的主要因素是终端网络的负载和网络类型。一般来说，无线网络环境下的传输时延波动较大，传输时延通常在10 ~ 100ms不等，在有线宽带网络下，同城传输时延可低至5ms~10ms。而国内中小运营商多，还有一些跨网环境，跨国传输，所以时延会更高。

服务器之间的延迟

这里，我们要考虑两种情况。第一，两端连接到同一个边缘节点，所以作为最优路径，数据通过边缘节点直接转发到播放端；其次，采集端和播放端不在同一个边缘节点覆盖范围内，所以数据会通过“靠近”采集端的边缘节点传输到骨干网，再发送到“靠近”播放端的边缘节点，但此时服务器之间的传输和排队会造成延迟。

在实时合唱的场景下，为了解决网络不畅和网络抖动的问题，需要在采集设备、服务器和播放中加入缓冲策略。一旦触发缓冲策略，就会造成延迟。如果情况比较多，延迟会逐渐累积。要解决停滞和累积延迟的问题，需要优化整个网络状况。

合唱也要高音质

所有的歌手都有一个共同的心理需求，就是希望别人夸自己唱得好。在合唱场景中，音质尤为重要。影响实时合唱质量的因素主要包括:音频采样率、码率和时延。

采样率:是每秒钟从连续信号中提取的由离散信号组成的样本数。采样率越高，音频声音越接近真实声音。

比特率:指每秒传输编码(压缩)音频数据所代表的数据量(比特)。比特率越高，每秒采样的信息量越大，对这个样本的描述就越准确，音质就越好。

假设网络状态稳定，采样率和比特率越高，音质越好，但单个样本的信息量越大，传输时间可能就越长。换句话说，高音质也可能影响延迟。

敲黑板：解题思路

我们前面提到“音频”因解决方案不同而有不同的含义，这与你的实现逻辑有关。

1.音频=唱歌+伴奏

在采集端，如果我们传输的音频包括演唱和伴奏。那么就意味着这样的逻辑，如下图所示。

歌手A先获得伴奏；A 将歌声与伴奏在本地混音后传输给 B；B 根据A的音频进行演唱，这时 B 可以听到合唱的效果；B 将合唱后的混音传输给 A，A 就可以听到合唱效果了。

在这种传输模式下，如果要保证A能听到合唱效果，会有两个“端到端延迟”，即步骤2和3。因为B听到的是A的演唱和伴奏，这个方案可以保证B的体验。但是因为伴奏传到B，B的歌声需要传回A，A听到的伴奏和B的声音之间实际上有很大的延迟。根据上面的延迟推断，你需要付出更多的努力，将端到端的延迟降低到歌手a可以接受的水平。

2.音频=唱歌

在这里，不是不想陪。为了解决伴奏和演唱之间的时间延迟问题，我们还有另外一个方法，就是通过云端同时给A和B传输伴奏，基本上保证了两个人在同一秒钟都能听到同一个音符。接下来要解决的只是歌曲的传输。基本实现逻辑如下，这也是我们自己的实现方法:

声网从服务器或本地获取合唱伴奏；声网通过 SD-RTN™ 将伴奏，实时同步发送给歌手 A 和 B；歌手 A 和 B 会同时听到伴奏，然后根据伴奏开始自己的演唱；SD-RTN™ 会实时的将A的歌声传给B端，同样，B 的歌声也会被实时的传输到 A 端；歌手A和B都能实时听到伴奏和对方的歌声；同时，观众可以实时听到两个歌手的合唱效果。

这种实现逻辑的好处是A和B可以同时听到伴奏和唱歌，可以实时听到对方的声音。要解决的问题是减少彼此传输各自歌曲的端到端延迟。相对来说，更简单。

除此之外，其实大家在在线场景中也可以看到，很多歌手平时唱歌的时候都会带着耳罩，而这个耳罩的效果在在线实时场景中也是非常关键的:

(1)歌手是用来监听自己的声音和伴奏，调节自己的音色和情绪的，需要特别高的延时。

(2)通过音效和美声的叠加，让演唱者听到极致的声音体验。

Agora SDK通过统一的接口提供低延迟的卡拉ok功能。通过与手机厂商的深度技术合作，可以为卡拉ok和直播app提供适用于不同手机品牌和型号的耳罩。我们将传统耳罩100-300ms的延迟降低到50ms以下，结合Agora的整体音频解决方案，实现超低延迟、超低噪音、极致音效的耳罩体验。

在github上获取我们的合唱演示，并亲自尝试一下。

https://github.com/AgoraIO-Usecase/Online-Chorus/

提到了哪些知识点？我给你做了一些有组织有系统的地图和信息视频。有需要的朋友可以私信我【NDK】，我会分享给你。如有错误，请指出。让我们一起交流，共同进步。

NDK模块开发

音频和视频的发展往往是困难的，而这种困难的技术就是NDK的技术。音频/视频/高清大图/人工智能/直播/Tik Tok等都是今年离用户最近的，和我们生活最相关的技术，总是在寻找最终的技术落地平台。以前是windows系统，现在是移动系统，而移动系统中Android占了绝大多数，所以AndroidNDK技术已经是我们的必备技能了。要学好NDK，需要学习C/C++、jni、Linux的基础知识。除此之外，音视频编解码技术，流媒体协议，ffmpeg都是音视频开发的必备技能。