1.本技术涉及用于音频编解码器扩展的装置和方法，但并不排他地涉及用于自动翻译的音频编解码器扩展。


背景技术：

2.沉浸式音频编解码器正被实现，以支持范围从低比特率操作到透明的大量操作点。这种编解码器的示例是沉浸式语音和音频服务(ivas)编解码器，其被设计为适合于在诸如3gpp 4g/5g网络之类的通信网络上使用。这种沉浸式服务包括例如在诸如虚拟现实(vr)、增强现实(ar)和混合现实(mr)之类的应用的沉浸式语音和音频中使用。该音频编解码器被预期处理语音、音乐和通用音频的编码、解码和渲染。此外还被预期支持基于通道的音频和基于场景的音频输入，包括关于声场和声源的空间信息。该编解码器还被预期以低延迟进行操作，以使能会话服务并在各种传输条件下支持高差错鲁棒性。
3.可以使用各种手段来实现自动语言翻译。通常，应用或服务(例如，云中的服务器)接收包括语音的音频信号，识别音频信号中的词语，评估这些词语的含义(例如，各个单词在与其他词语结合的上下文中最有可能的含义)，并创建包括对所期望语言的对应翻译的音频信号。可以给出输入语言和输出语言，或者可以识别输入语言，作为整个识别任务的一部分。自动语言翻译可以利用例如语音到文本(stt)技术和文本到语音(tts)技术。在现代系统中，链中的至少一个任务可以通过诸如深度神经网络(dnn)之类的人工智能(ai)来执行。能够处理这种处理类型的处理器在诸如智能手机之类的现代移动设备和装置中变得越来越普遍。


技术实现要素：

4.根据第一方面，提供了一种装置，其包括被配置为执行以下操作的部件：接收包括至少一个音频信号的主音轨(primary track)；接收至少一个辅助音轨(secondary track)，该至少一个辅助音轨中的每个辅助音轨包括至少一个音频信号，其中，该至少一个辅助音轨是基于主音轨；以及使用空间音频解码来对主音轨和至少一个辅助音轨进行解码和渲染。
5.包括至少一个音频信号的主音轨可以包括以下中的至少一个：至少一个所捕获的麦克风音频信号；基于至少一个所捕获的麦克风音频信号的空间分析而生成的至少一个传输音频信号和空间元数据；包括至少一个音频信号和空间元数据的音频对象；基于至少一个所捕获的麦克风音频信号的空间分析的全景环绕声(ambisonics)格式的音频信号。
6.包括至少一个音频信号的主音轨可以包括包括采用第一语言的至少一个语音分量。
7.基于主音轨的至少一个辅助音轨可以是包括采用第二语言的至少一个语音分量的至少一个音频信号。
8.包括至少一个音频信号的主音轨可以包括采用第一语言的至少一个语音分量，并
且基于主音轨的至少一个辅助音轨可以是与至少一个音频信号的位置相关联的至少一个音频信号。
9.该部件可以进一步被配置为：接收与至少一个辅助音轨和/或主音轨相关联的信息参数，其中，与至少一个辅助音轨和/或主音轨相关联的信息参数可以是以下中的至少一个：主音轨参考时间；主音轨初始讲话时间；主音轨元素长度；辅助音轨相对主音轨的偏移；辅助音轨相对主音轨的延迟；以及辅助音轨元素长度。
10.该部件可以进一步被配置为：接收至少一个用户输入，其中，被配置为使用空间音频解码来对主音轨和至少一个辅助音轨进行解码和渲染的该部件可以进一步被配置为：基于该用户输入，对主音轨和至少一个辅助音轨进行解码和渲染，以修改至少一个辅助音轨和主音轨中的至少一个。
11.被配置为基于用户输入来对主音轨和至少一个辅助音轨进行解码和渲染以修改至少一个辅助音轨和主音轨中的至少一个的该部件可以被配置为执行以下中的至少一个：修改与至少一个辅助音轨和主音轨中的至少一个相关联的音频对象的渲染定位或位置或定向；修改主音轨和至少一个辅助音轨的音量；以及选择渲染至少一个辅助音轨和主音轨中的至少一个。
12.该部件可以进一步被配置为：接收至少一个用户输入，其中，该至少一个用户输入被配置为控制编码器，该编码器被配置为对至少一个辅助音轨和主音轨中的至少一个进行编码。
13.主音轨和/或至少一个辅助音轨可以包括以下中的一个：增强型语音系统编码的多通道音频信号；以及沉浸式语音和音频服务的多通道音频信号。
14.根据第二方面，提供了一种装置，其包括被配置为执行以下操作的部件：获得包括至少一个音频信号的主音轨；以及使用空间音频编码来对主音轨进行编码，其中，该主音轨与基于主音轨而生成的并进一步使用空间音频编码而被编码的辅助音轨相关联。
15.包括至少一个音频信号的主音轨可以包括以下中的至少一个：至少一个所捕获的麦克风音频信号；基于至少一个所捕获的麦克风音频信号的空间分析而生成的至少一个传输音频信号和空间元数据；包括至少一个音频信号和空间元数据的音频对象；基于至少一个所捕获的麦克风音频信号的空间分析的ambisonics格式的音频信号。
16.包括至少一个音频信号的主音轨可以包括包括采用第一语言的至少一个语音分量。
17.该部件可以进一步被配置为：生成至少一个辅助音轨，该至少一个辅助音轨中的每个辅助音轨包括至少一个音频信号，该至少一个音频信号可以包括采用第二语言的至少一个语音分量。
18.包括至少一个音频信号的主音轨可以包括采用第一语言的至少一个语音分量，并且该部件进一步被配置为：生成至少一个辅助音轨，该至少一个辅助音轨是与至少一个音频信号的位置相关联的至少一个音频信号。
19.该部件可以进一步被配置为：生成与至少一个辅助音轨和/或主音轨相关联的信息参数，其中，与至少一个辅助音轨和/或主音轨相关联的信息参数可以是以下中的至少一个：主音轨参考时间；主音轨初始讲话时间；主音轨元素长度；辅助音轨相对主音轨的偏移；辅助音轨相对主音轨的延迟；以及辅助音轨元素长度。
20.该部件可以进一步被配置为：接收至少一个用户输入，其中，被配置为获得主音轨并被配置为生成至少一个辅助音轨的该部件可以进一步被配置为：基于该用户输入，对至少一个辅助音轨和主音轨中的至少一个进行修改。
21.被配置为基于用户输入来对至少一个辅助音轨和主音轨中的至少一个进行修改的该部件可以被配置为执行以下中的至少一个：修改与主音轨和至少一个辅助音轨相关联的音频对象的空间定位或位置或定向；修改主音轨和至少一个辅助音轨中的至少一个辅助音轨的音量；以及选择至少一个辅助音轨中的至少一个辅助音轨和主音轨中的至少一个。
22.该部件可以进一步被配置为：接收至少一个用户输入，其中，该至少一个用户输入可以被配置为控制被配置为使用空间音频编码来对主音轨进行编码的该部件。
23.一种系统可以包括：
24.如上所述的被配置为执行以下操作的装置：接收包括至少一个音频信号的主音轨；接收至少一个辅助音轨，该至少一个辅助音轨中的每个辅助音轨包括至少一个音频信号，其中，该至少一个辅助音轨是基于主音轨；以及使用空间音频解码来对主音轨和至少一个辅助音轨进行解码和渲染；
25.包括被配置为执行以下操作的部件的另一装置：接收主音轨；基于主音轨，生成至少一个辅助音轨；使用空间音频编码来对至少一个辅助音轨进行编码；以及
26.包括被配置为执行以下操作的部件的装置：获得包括至少一个音频信号的主音轨；以及使用空间音频编码来对主音轨进行编码，其中，该主音轨与基于主音轨而生成的并进一步使用空间音频编码而被编码的辅助音轨相关联。
27.根据第三方面，提供了一种方法，其包括：接收包括至少一个音频信号的主音轨；接收至少一个辅助音轨，该至少一个辅助音轨中的每个辅助音轨包括至少一个音频信号，其中，该至少一个辅助音轨是基于主音轨；以及使用空间音频解码来对主音轨和至少一个辅助音轨进行解码和渲染。
28.包括至少一个音频信号的主音轨可以包括以下中的至少一个：至少一个所捕获的麦克风音频信号；基于至少一个所捕获的麦克风音频信号的空间分析而生成的至少一个传输音频信号和空间元数据；包括至少一个音频信号和空间元数据的音频对象；基于至少一个所捕获的麦克风音频信号的空间分析的ambisonics格式的音频信号。
29.包括至少一个音频信号的主音轨可以包括包括采用第一语言的至少一个语音分量。
30.基于主音轨的至少一个辅助音轨可以是包括采用第二语言的至少一个语音分量的至少一个音频信号。
31.包括至少一个音频信号的主音轨可以包括采用第一语言的至少一个语音分量，并且基于主音轨的至少一个辅助音轨可以是与至少一个音频信号的位置相关联的至少一个音频信号。
32.该方法还可以包括：接收与至少一个辅助音轨和/或主音轨相关联的信息参数，其中，与至少一个辅助音轨和/或主音轨相关联的信息参数可以是以下中的至少一个：主音轨参考时间；主音轨初始讲话时间；主音轨元素长度；辅助音轨相对主音轨的偏移；辅助音轨相对主音轨的延迟；以及辅助音轨元素长度。
33.该方法还可以包括：接收至少一个用户输入，其中，使用空间音频解码来对主音轨
和至少一个辅助音轨进行解码和渲染还可以包括：基于该用户输入，对主音轨和至少一个辅助音轨进行解码和渲染，以修改至少一个辅助音轨和主音轨中的至少一个。
34.基于用户输入来对主音轨和至少一个辅助音轨进行解码和渲染以修改至少一个辅助音轨和主音轨中的至少一个可以包括执行以下中的至少一个：修改与主音轨和至少一个辅助音轨相关联的音频对象的渲染定位或位置或定向；修改主音轨和至少一个辅助音轨的音量；以及选择渲染至少一个辅助音轨和主音轨中的至少一个。
35.该方法可以包括：接收至少一个用户输入，其中，该至少一个用户输入可以控制对至少一个辅助音轨和主音轨中的至少一个进行编码。
36.主音轨和/或至少一个辅助音轨可以包括以下中的一个：增强型语音系统编码的多通道音频信号；以及沉浸式语音和音频服务的多通道音频信号。
37.根据第四方面，提供了一种方法，其包括：获得包括至少一个音频信号的主音轨；以及使用空间音频编码来对主音轨进行编码，其中，该主音轨与基于主音轨而生成的并进一步使用空间音频编码而被编码的辅助音轨相关联。
38.包括至少一个音频信号的主音轨可以包括以下中的至少一个：至少一个所捕获的麦克风音频信号；基于至少一个所捕获的麦克风音频信号的空间分析而生成的至少一个传输音频信号和空间元数据；包括至少一个音频信号和空间元数据的音频对象；基于至少一个所捕获的麦克风音频信号的空间分析的ambisonics格式的音频信号。
39.包括至少一个音频信号的主音轨可以包括包括采用第一语言的至少一个语音分量。
40.该方法还可以包括：生成至少一个辅助音轨，该至少一个辅助音轨中的每个辅助音轨包括至少一个音频信号，该至少一个音频信号可以包括采用第二语言的至少一个语音分量。
41.包括至少一个音频信号的主音轨可以包括采用第一语言的至少一个语音分量，并且该方法还可以包括：生成至少一个辅助音轨，该至少一个辅助音轨是与至少一个音频信号的位置相关联的至少一个音频信号。
42.该方法还可以包括：生成与至少一个辅助音轨和/或主音轨相关联的信息参数，其中，与至少一个辅助音轨和/或主音轨相关联的信息参数可以是以下中的至少一个：主音轨参考时间；主音轨初始讲话时间；主音轨元素长度；辅助音轨相对主音轨的偏移；辅助音轨相对主音轨的延迟；以及辅助音轨元素长度。
43.该方法还可以包括：接收至少一个用户输入，其中，获得主音轨和生成至少一个辅助音轨可以包括：基于该用户输入，对至少一个辅助音轨和主音轨中的至少一个进行修改。
44.基于用户输入来对至少一个辅助音轨和主音轨中的至少一个进行修改可以包括以下中的至少一个：修改与主音轨和至少一个辅助音轨相关联的音频对象的空间定位或位置或定向；修改主音轨和至少一个辅助音轨中的至少一个辅助音轨的音量；以及选择至少一个辅助音轨中的至少一个辅助音轨和主音轨中的至少一个。
45.该方法还可以包括：接收至少一个用户输入，其中，该至少一个用户输入可以控制使用空间音频编码来对主音轨进行编码。
46.一种方法可以包括：获得包括至少一个音频信号的主音轨；使用空间音频编码来对主音轨进行编码，其中，该主音轨与基于主音轨而生成的并进一步使用空间音频编码而
被编码的辅助音轨相关联；基于主音轨，生成至少一个辅助音轨；使用空间音频编码来对至少一个辅助音轨进行编码；使用空间音频解码来对主音轨和至少一个辅助音轨进行解码和渲染。
47.根据第五方面，提供了一种装置，其包括至少一个处理器和包括计算机程序代码的至少一个存储器，该至少一个存储器和计算机程序代码被配置为与至少一个处理器一起使该装置至少：获得包括至少一个音频信号的主音轨；以及使用空间音频编码来对主音轨进行编码，其中，该主音轨与基于主音轨而生成的并进一步使用空间音频编码而被编码的辅助音轨相关联。
48.包括至少一个音频信号的主音轨可以包括以下中的至少一个：至少一个所捕获的麦克风音频信号；基于至少一个所捕获的麦克风音频信号的空间分析而生成的至少一个传输音频信号和空间元数据；包括至少一个音频信号和空间元数据的音频对象；基于至少一个所捕获的麦克风音频信号的空间分析的ambisonics格式的音频信号。
49.包括至少一个音频信号的主音轨可以包括包括采用第一语言的至少一个语音分量。
50.该装置可以进一步被使得：生成至少一个辅助音轨，该至少一个辅助音轨中的每个辅助音轨包括至少一个音频信号，该至少一个音频信号可以包括采用第二语言的至少一个语音分量。
51.包括至少一个音频信号的主音轨可以包括采用第一语言的至少一个语音分量，并且该装置可以进一步被使得：生成至少一个辅助音轨，该至少一个辅助音轨是与至少一个音频信号的位置相关联的至少一个音频信号。
52.该装置可以进一步被使得：生成与至少一个辅助音轨和/或主音轨相关联的信息参数，其中，与至少一个辅助音轨和/或主音轨相关联的信息参数可以是以下中的至少一个：主音轨参考时间；主音轨初始讲话时间；主音轨元素长度；辅助音轨相对主音轨的偏移；辅助音轨相对主音轨的延迟；以及辅助音轨元素长度。
53.该装置可以进一步被使得：接收至少一个用户输入，其中，被使得获得主音轨并生成至少一个辅助音轨的该装置可以进一步被使得：基于该用户输入，对至少一个辅助音轨和主音轨中的至少一个进行修改。
54.被使得基于用户输入来对至少一个辅助音轨和主音轨中的至少一个进行修改的该装置可以被使得执行以下中的至少一个：修改与主音轨和至少一个辅助音轨相关联的音频对象的空间定位或位置或定向；修改主音轨和至少一个辅助音轨中的至少一个辅助音轨的音量；以及选择至少一个辅助音轨中的至少一个辅助音轨和主音轨中的至少一个。
55.该装置可以进一步被使得：接收至少一个用户输入，其中，该至少一个用户输入可以控制使用空间音频编码来对主音轨进行编码。
56.根据第六方面，提供了一种装置，其包括至少一个处理器和包括计算机程序代码的至少一个存储器，该至少一个存储器和计算机程序代码被配置为与至少一个处理器一起使该装置至少：接收包括至少一个音频信号的主音轨；接收至少一个辅助音轨，该至少一个辅助音轨中的每个辅助音轨包括至少一个音频信号，其中，该至少一个辅助音轨是基于主音轨；以及使用空间音频解码来对主音轨和至少一个辅助音轨进行解码和渲染。
57.包括至少一个音频信号的主音轨可以包括以下中的至少一个：至少一个所捕获的
麦克风音频信号；基于至少一个所捕获的麦克风音频信号的空间分析而生成的至少一个传输音频信号和空间元数据；包括至少一个音频信号和空间元数据的音频对象；基于至少一个所捕获的麦克风音频信号的空间分析的ambisonics格式的音频信号。
58.包括至少一个音频信号的主音轨可以包括包括采用第一语言的至少一个语音分量。
59.基于主音轨的至少一个辅助音轨可以是包括采用第二语言的至少一个语音分量的至少一个音频信号。
60.包括至少一个音频信号的主音轨可以包括采用第一语言的至少一个语音分量，并且基于主音轨的至少一个辅助音轨可以是与至少一个音频信号的位置相关联的至少一个音频信号。
61.该装置可以进一步被使得：生成与至少一个辅助音轨和/或主音轨相关联的信息参数，其中，与至少一个辅助音轨和/或主音轨相关联的信息参数可以是以下中的至少一个：主音轨参考时间；主音轨初始讲话时间；主音轨元素长度；辅助音轨相对主音轨的偏移；辅助音轨相对主音轨的延迟；以及辅助音轨元素长度。
62.该装置可以进一步被使得：接收至少一个用户输入，其中，被使得使用空间音频解码来对主音轨和至少一个辅助音轨进行解码和渲染的该装置可以进一步被使得：基于该用户输入，对主音轨和至少一个辅助音轨进行解码和渲染，以修改至少一个辅助音轨和主音轨中的至少一个。
63.被使得基于用户输入来对主音轨和至少一个辅助音轨进行解码和渲染以修改至少一个辅助音轨和主音轨中的至少一个的该装置可以被使得执行以下中的至少一个：修改与主音轨和至少一个辅助音轨相关联的音频对象的渲染定位或位置或定向；修改主音轨和至少一个辅助音轨的音量；以及选择渲染至少一个辅助音轨和主音轨中的至少一个。
64.该装置可以进一步被使得：接收至少一个用户输入，其中，该至少一个用户输入可以控制对至少一个辅助音轨和主音轨中的至少一个进行编码。
65.主音轨和/或至少一个辅助音轨可以包括以下中的一个：增强型语音系统编码的多通道音频信号；以及沉浸式语音和音频服务的多通道音频信号。
66.根据第七方面，提供了一种装置，其包括：接收电路，被配置为接收包括至少一个音频信号的主音轨；接收电路，被配置为接收至少一个辅助音轨，该至少一个辅助音轨中的每个辅助音轨包括至少一个音频信号，其中，该至少一个辅助音轨是基于主音轨；以及解码和渲染电路，被配置为使用空间音频解码来对主音轨和至少一个辅助音轨进行解码和渲染。
67.根据第八方面，提供了一种装置，其包括：获得电路，被配置为获得包括至少一个音频信号的主音轨；以及编码电路，被配置为使用空间音频编码来对主音轨进行编码，其中，该主音轨与基于主音轨而生成的并进一步使用空间音频编码而被编码的辅助音轨相关联。
68.根据第九方面，提供了一种包括指令的计算机程序(或包括程序指令的计算机可读介质)，这些指令(或程序指令)用于使装置至少执行以下操作：接收包括至少一个音频信号的主音轨；接收至少一个辅助音轨，该至少一个辅助音轨中的每个辅助音轨包括至少一个音频信号，其中，该至少一个辅助音轨是基于主音轨；以及使用空间音频解码来对主音轨
和至少一个辅助音轨进行解码和渲染。
69.根据第十方面，提供了一种包括指令的计算机程序(或包括程序指令的计算机可读介质)，这些指令(或程序指令)用于使装置至少执行以下操作：获得包括至少一个音频信号的主音轨；以及使用空间音频编码来对主音轨进行编码，其中，该主音轨与基于主音轨而生成的并进一步使用空间音频编码而被编码的辅助音轨相关联。
70.根据第十一方面，提供了一种包括程序指令的非暂时性计算机可读介质，这些程序指令用于使装置至少执行以下操作：接收包括至少一个音频信号的主音轨；接收至少一个辅助音轨，该至少一个辅助音轨中的每个辅助音轨包括至少一个音频信号，其中，该至少一个辅助音轨是基于主音轨；以及使用空间音频解码来对主音轨和至少一个辅助音轨进行解码和渲染。
71.根据第十二方面，提供了一种包括程序指令的非暂时性计算机可读介质，这些程序指令用于使装置至少执行以下操作：获得包括至少一个音频信号的主音轨；以及使用空间音频编码来对主音轨进行编码，其中，该主音轨与基于主音轨而生成的并进一步使用空间音频编码而被编码的辅助音轨相关联。
72.根据第十三方面，提供了一种装置，其包括：用于接收包括至少一个音频信号的主音轨的部件；用于接收至少一个辅助音轨的部件，该至少一个辅助音轨中的每个辅助音轨包括至少一个音频信号，其中，该至少一个辅助音轨是基于主音轨；以及用于使用空间音频解码来对主音轨和至少一个辅助音轨进行解码和渲染的部件。
73.根据第十四方面，提供了一种装置，其包括：用于获得包括至少一个音频信号的主音轨的部件；以及用于使用空间音频编码来对主音轨进行编码的部件，其中，该主音轨与基于主音轨而生成的并进一步使用空间音频编码而被编码的辅助音轨相关联。
74.根据第十五方面，提供了一种包括程序指令的计算机可读介质，这些程序指令使装置至少执行以下操作：接收包括至少一个音频信号的主音轨；接收至少一个辅助音轨，该至少一个辅助音轨中的每个辅助音轨包括至少一个音频信号，其中，该至少一个辅助音轨是基于主音轨；以及使用空间音频解码来对主音轨和至少一个辅助音轨进行解码和渲染。
75.根据第十六方面，提供了一种包括程序指令的计算机可读介质，这些程序指令使装置至少执行以下操作：获得包括至少一个音频信号的主音轨；以及使用空间音频编码来对主音轨进行编码，其中，该主音轨与基于主音轨而生成的并进一步使用空间音频编码而被编码的辅助音轨相关联。
76.一种装置，包括用于执行如上所述的方法的动作的部件。
77.一种装置，被配置为执行如上所述的方法的动作。
78.一种计算机程序，包括用于使计算机执行如上所述的方法的程序指令。
79.一种被存储在介质上的计算机程序产品可以使装置执行本文所述的方法。
80.一种电子设备可以包括如本文所述的装置。
81.一种芯片组可以包括如本文所述的装置。
82.本技术的实施例旨在解决与现有技术相关联的问题。
附图说明
83.为了更好地理解本技术，现在将通过示例的方式参考附图，其中：
84.图1a和图1b示意性地示出适于实现自动翻译操作的装置系统；
85.图2示意性地示出如在图1b中所示的系统中实现的按次序翻译的示例用户体验；
86.图3示意性地示出根据一些实施例的第一示例编码器架构；
87.图4a和图4b示意性地示出根据一些实施例的第二和第三示例编码器架构；
88.图5示出根据一些实施例的用于第一示例编码器架构的示例操作流程；
89.图6示出根据一些实施例的用于第二和第三示例编码器架构的示例操作流程；
90.图7a和图7b示出根据一些实施例的示例元数据结构；
91.图8示出适于实现所示装置的示例设备。
具体实施方式
92.下面更详细地描述了用于诸如实时语言翻译(rtlt)之类的目的的音频编解码器的扩展的合适装置和可能机制。
93.本发明涉及语音和音频编解码器，特别是沉浸式音频编解码器，其支持范围从低比特率操作到透明的大量操作点以及一系列服务能力，例如，从单声道到立体声到完全沉浸式音频编码/解码/渲染。这种编解码器的示例是3gpp ivas编解码器，针对该编解码器的标准化过程已于2017年10月在3gpp tsg
‑
sa4中启动。目前预计该标准在2020年底完成。
94.ivas编解码器是3gpp增强型语音服务(evs)编解码器的扩展，并且旨在用于4g/5g上的新的沉浸式语音和音频服务。这种沉浸式服务包括例如用于虚拟现实(vr)的沉浸式语音和音频。预期多用途音频编解码器能处理语音、音乐和一般音频的编码、解码和渲染。预期它能支持基于通道的音频和基于场景的音频输入，包括关于声场和声源的空间信息。预期它还能以低延迟进行操作，以使能会话服务并在各种传输条件下支持高差错鲁棒性。
95.输入音频信号以所支持的格式(或以所支持格式的某一所允许组合)被呈现给ivas编码器。类似地，例如，对于给定的扬声器配置或直接耳机呈现(其中可以应用双耳化方法，诸如头部相关传递函数(hrtf)的使用)，解码器可以以所支持的格式(或其组合)输出或渲染音频信号。直通模式(pass
‑
through mode)(其中在传输(编码/解码)之后以其原始格式提供音频信号)可以是编解码器操作的一部分。
96.图1a和图1b示出了通过运营商网络实现的实时语言翻译(rtlt)系统的当前示例。客户端设备101被配置为尝试建立从客户端到客户服务设备105的语音呼叫(在此示例中，为了简化起见，仅示出了一个方向)。例如，在国外旅行的汽车租赁客户其所租赁的车有问题。该用户使用他们的设备101在运营商网络103上经由专用客户服务号码进行语音呼叫以解决该问题。如图1a中所见，该呼叫被连接102到网络103，然后被连接104到客户服务设备105。
97.图1b示出了专用客户服务号码用于音频翻译服务的情况。如先前在图1a中所示，客户端设备101被配置为通过运营商网络103向客户服务设备105发出语音呼叫。如图1b中所见，该呼叫被连接102到网络103，然后被连接124到客户服务设备105，但也被路由114到转码数据中心107。转码数据中心107可以被配置为将该语音呼叫转换成脉冲编码调制(pcm)音频数据格式，并经由连接116将此pcm音频信号传递给语言翻译数据中心109。语言翻译数据中心109接收转码后的音频数据，并执行音频信号的语言翻译。在此示例中，可以具有与具体实现对应的多数据中心链(chain of data centres)。可替代地，可以具有单个
语言翻译数据中心109(或更长的多数据中心链)。进而，语言翻译数据中心109经由连接118将翻译传递回转码数据中心107。转码数据中心107可以将该翻译的pcm音频信号转码成采用一些合适/可用的比特率的合适的编码形式，诸如例如evs或自适应多速率宽带(amr
‑
wb)或自适应多速率(amr)比特流，以经由连接120传递给运营商网络103，然后运营商网络103可以经由连接134将翻译音频信号传递给客户端设备101，并经由连接124将其传递给客户服务设备105。
98.图1b的自动翻译场景与多方电话会议类似，它产生“按次序的语音体验”：首先，第一用户讲话，而第二用户听到正在说什么。这种体验与传统语音呼叫的不同之处在于：第二用户不应在此时开始讲话，而应等待翻译。进而，第一用户和第二用户两者都会听到翻译。随后是第二用户所进行的响应以及再次被提供给这两个用户的翻译，以此类推。
99.在图2中在时间线上示出了按次序的语音体验。在此示例中，用户1设备101、用户2设备105和服务器109通过网络进行通信。在此示例中，操作用户1设备101的用户讲话，而用户2设备105以来自在其间的服务器109的翻译播放进行响应。
100.因此，例如，用户1设备101被示出为具有初始讲话时间201，其由用户2设备在聆听时间211(其基本上与初始讲话时间201相同，并且考虑了网络上的编解码器算法延迟和传输延迟203)进行聆听。
101.在初始讲话时间201与翻译讲话时间225之间也存在延迟，其是由以下延迟所导致的：用户1设备与服务器之间的算法和传输延迟203；此外，与翻译的开始(例如，在语音活动检测在服务器处检测到使用用户1设备的讲话者已停止说话(以便防止翻译“盖过(talking over)”用户1设备101的用户)之后)有关的延迟200；以及任何算法翻译延迟。进而，翻译被传递给具有相关联的聆听翻译时间205的用户1设备101，并且被传递给具有相关联的聆听翻译时间215的用户2设备105。相关联的聆听翻译时间205和相关联的聆听翻译时间215被从翻译讲话时间225的开始延迟，其是由网络上编解码器算法延迟和服务器与用户设备之间的传输延迟203所导致的。在此示例中，假定用户1设备101与用户2设备105之间以及服务器109与用户1设备101(以及服务器109与用户2设备105)之间的网络延迟相同，尽管在实践中未必如此。
102.用户2设备105的用户被示出为具有“响应”讲话时间217，其由用户1设备在聆听时间207(其基本上与初始讲话时间217相同，并且考虑了编解码器算法延迟和网络上的传输延迟)进行聆听。
103.进而，在响应讲话时间217与翻译讲话时间229之间存在延迟，其是由以下延迟所导致的：用户2设备与服务器之间的算法和传输延迟；此外，与在语音活动检测在服务器处检测到使用用户2设备的讲话者已停止说话(以便防止翻译“盖过”用户2设备105的用户)之后的翻译的开始有关的延迟200；以及任何算法翻译延迟。进而，翻译被传递给具有相关联的聆听翻译时间209的用户1设备101和具有相关联的聆听翻译时间219的用户2设备105。相关联的聆听翻译时间209和相关联的聆听翻译时间219被从翻译讲话时间229的开始延迟，其是由网络上编解码器算法延迟和服务器与用户设备之间的传输延迟203所导致的。
104.这两个用户之间的这种交流(经由翻译)所消耗的时间实际上翻了一番，并且对于每个用户来说，大部分时间被花费在收听上。这是因为最活跃的讲话者实际上是提供翻译的服务器109。在传统的语音呼叫中，如两个人之间的任何现实生活会话中，可以预期每个
讲话者平均有接近50％的时间在讲话(考虑停顿等)，而在本文中对应的数字将低于25％。
105.如在下文所讨论的实施例中进一步详细讨论的概念是提供辅助(以及在一些实施例中是进一步的)“音轨”或音频信号，其可以被认为是交替的音频信号(alternate audio signals)。这些辅助“音轨”可以基于原始音频信号或主音轨而生成，并且可以被编码并被发送到接收机。另外，在一些实施例中，可以基于主音轨和/或辅助音轨来生成其他信息，并且此信息也被传递给接收机。在一些实施例中，被配置为接收主音轨、辅助音轨和该信息的接收机可以被配置为修改辅助音轨，例如，以在主音轨与辅助音轨的解码和/或渲染之间进行切换或交替。此外，在一些实施例中，可以在空间处理中修改辅助音轨。例如，当渲染时，可以改变与辅助音轨相关联的音频对象的位置、定向或距离，可以改变相干性，或者可以改变对象的(相对)大小，或者可以改变音频对象的音量。
106.在以下示例中，辅助“音轨”的使用是为了实现如先前所讨论的实时语言翻译(rtlt)。在rtlt应用中使用辅助“音轨”可以尝试在用户之间生成更自然的讨论流程(否则其会不断被图1b和图2中所示的按次序翻译方法打断)。另外，所讨论的实施例可以使系统能够显著减少呼叫时间(因为按次序的方法由于翻译回声效应而实际上使呼叫所花费的时间长度加倍)。当用户“几乎相互理解”同时仍然需要从翻译中获得一些对其理解的支持时，这种翻译回声可能尤其没有效果并且令人沮丧。例如，至少一个用户可能知道第二用户的语言的基础。
107.这种实施例描述了会话空间音频编码。一些实施例主要适用于并且可实现在包括带内信令的空间音频编解码器中，诸如3gpp ivas(沉浸式语音和音频服务)编解码器。在一些实施例中，翻译可以经由网络单元的外部支持来实现，其中，所添加的功能涉及分组化和带外信令(例如，rtp——实时传输协议报头)。另外，在一些实施例中，至少在渲染空间音频(其例如可以由外部渲染器执行)时可以具有直接的用户接口输入。在一些实施例中，接收方的用户接口还可以控制编码器侧操作的至少一些方面。
108.因此，如本文中所讨论的实施例公开了一种用于使用会话空间音频编码的rtlt的系统。在这种实施例中，用空间再现来使能rtlt以利用所谓的鸡尾酒会效应(cocktail party effect)。在空间渲染中，如在现实生活中一样，用户通常能够专注于许多音频源之一，而不管它们的时间上的重叠。因此，这些实施例允许多于一个的语音的同时播放。通过引入rtlt“音频对象元数据”，在编码系统中实现了对附加的控制和特征的支持。在一些实施例中，还包括具体时间同步信息，从而允许在翻译音频与原始语言音频信号之间的同步。
109.在一些实施例中描述了替代的实现，其针对各种输入格式、信令时间偏移同步、以及请求包括用于停止部分本地播放的指示的新编解码器模式，扩展了ivas编解码器的功能。
110.如下文中所讨论的实施例的优势在于：所提出的rtlt特征可以被集成到(通过使用现有语音服务的扩展/或更新)现有语音服务(诸如mtsi——ip多媒体子系统的多媒体电话服务)中，并因此使能快速部署并且易于使用。因此，该特征可以成为常规(沉浸式)语音呼叫的一部分。在一些实施例中，rtlt特征可以被设置为非对称翻译(换句话说，可以在仅一个方向上发送rtlt)。此外，在一些实施例中，用户可以将本文中所描述的设备配置为通过添加合适的音频对象输入(例如，通过在他们的设备上选择翻译用户接口)而在呼叫期间添加语音翻译传输。
111.在一些实施例中，rtlt(自动翻译)功能可以在本地设备或任何合适的网络服务(例如，边缘计算服务)上实现。在一些实施例中，对于一对一呼叫，用户的设备上的本地翻译服务被配置为执行自动翻译。在这种实施例中，本地翻译提供具有处理未压缩的音频信号(其可能会影响翻译的质量)的能力的低延迟翻译。在一些实施例中，网络服务可以被用于翻译。这些实施例可以允许用户设备是低功率的设备(例如，这些实施例可以由具有比执行本地翻译的设备更低的处理器和存储器配置的设备使用)。此外，这种实施例使设备能够具有改进的电池寿命(其中不发生额外处理)，此外，由于在服务器处(或在云中)可用的高得多的计算能力，翻译可以更准确。在网络服务上，可以提供更大的语言集合，在这些语言集合之间进行翻译和语音合成是可能的。此外，如所讨论的，这些实施例具有更低的延迟，因为原始语言音频信号不需要经过转码过程。
112.在针对具有若干参加者和若干语言的电话会议的一些实施例中，可以在服务器处(或在云中)执行翻译以便节省带宽并利用可用的更高的计算能力。
113.在针对具有若干参加者和若干语言的电话会议的其他实施例中，一些语言翻译可以在本地用户设备上执行，而一些语言翻译可以在服务器处(或在云中)执行。因此，接收用户的设备可以例如接收至少四个音频信号，这四个音频信号对应于：采用第一语言的第一讲话者的语音及其到第三语言的翻译，采用第二语言的第二讲话者的语音及其到第四语言的翻译。可替代地，接收用户的设备可以例如接收至少两个音频信号，这两个音频信号对应于：从第一语言翻译成第三语言的第一讲话者的语音、以及从第二语言翻译成第四语言的第二讲话者的语音。在本文中，接收用户的设备设置(诸如服务偏好)或呼叫协商信令可以指示接收用户理解第三语言和第四语言(但可能不理解第一和第二语言中的任何一个)。
114.在下文进一步详细讨论的实施例中，至少一个输入音频信号或“音轨”被翻译并且至少第二(翻译的)音频信号或“音轨”被合成。在一些实施例中，这些音轨以不同的方式被组合以用于传输。
115.在一些实施例中，时间偏移信息(其可以是二分量偏移信息)可以与音频信号一起被创建并被发送。
116.在以下讨论中，可以引入先前在专利申请gb1811847.1和pct/ep 2018/079980中引入和定义的术语。
117.关于图3，示意性地示出了一些实施例的高级视图。在此示例中，分别操作第一用户设备或用户1设备101和第二用户设备或用户2设备105的两个用户能够通过音频呼叫实现彼此之间的实时语言翻译。在图3中，示出了用于执行本地rtlt处理的装置，其被配置为将由用户1输入到用户1设备101中的语音音频信号翻译成被用户2理解的的语言，并且其由用户2设备105接收。
118.因此，在一些实施例中，用户1设备包括被配置为接收采用第一语言的语音音频信号302的输入端。此语音音频信号可以被视为主音轨或第一音轨。该输入端可以被连接到本地实时语言翻译器(rtlt)301和(ivas)编码器303。在以下实施例中，采用第一语言的语音音频信号302(以及采用第二语言的语音音频信号304)是单声道音频信号。然而，在一些实施例中，采用第一语言的音频信号302是多通道音频信号。在这种实施例中，采用第二语言的语音音频信号304可以是单声道音频信号或多通道音频信号。例如，用户设备可以基于正被捕获的一个或多个原始语言信号而生成多于一个的同声翻译(采用不同的语言)。另外，
在一些实施例中，采用第一语言的语音音频信号302不是从一个(或多于一个的)麦克风捕获的音频信号，而是根据来自两个或更多个音频信号的音频信号的空间分析而生成的。在一些实施例中，空间分析可以导致音频环境内一个或多于一个的语音音频信号的确定和隔离。例如，用户1设备可以被用作音频会议系统的一部分，并且包括被配置为生成多通道音频信号输入的麦克风阵列。进而，可以对该多通道音频信号进行分析以确定是否存在一个或多个语音音频源，并针对每个语音音频源生成音频信号(例如，通过对多通道音频信号进行波束成形或以其他方式处理音频信号)。
119.本地实时语言翻译器(rtlt)301被配置为接收采用第一语言的语音音频信号302，并输出翻译音频信号。采用第二语言的翻译音频信号或语音音频信号304被输出到(ivas)编码器303。本地实时语言翻译器(rtlt)301可以被实现为任何已知的实时翻译器，并且可以在基于翻译的软件和/或硬件(例如，ai或深度学习处理器或在设备内实现的处理器)上实现。在具有多于一个的语音音频信号输入的实施例中，进而可以翻译每个语音音频信号，并生成采用第二语言的单独的语音音频信号。在具有多于一个的语音音频信号输入的一些实施例中，可以例如基于用户指示来选择多个语音音频信号输入中的至少一个，以用对应生成的至少一个第二语言语音音频信号进行翻译。
120.在以下示例中，两个用户使用两个语言讲话。在系统中用户使用多于两个语言讲话(例如，其中三个或更多个用户经由系统进行通信)的一些实施例中，那么rtlt 301被配置为生成采用更多语言的语音音频信号，并将这些采用更多语言的语音音频信号传递给编码器303。
121.(ivas)编码器303被配置为接收采用第一语言的语音音频信号302和采用第二语言的语音音频信号304。进而，编码器303被配置为基于所确定的编码方法来对这些语音音频信号进行编码，并生成编码比特流306。编码比特流306可以通过网络被发送。在一些实施例中，编码器303可以是计算机(运行存储在存储器和至少一个处理器上的合适的软件)，或者可替代地可以是使用例如fpga或asic的特定设备。
122.在以下示例中，编码器被配置为接收单声道语音音频信号，但在一些实施例中，这些语音音频信号包括多通道音频信号。在这种实施例中，多通道音频信号在一些实施例中可以被处理以生成合适的“传输”音频信号(诸如包括单声道、立体声、一个或多个下混合的或一个或多个所选择的通道音频信号的编码音频信号，以及编码的立体声或多通道参数作为与编码的单声道音频信号相关联的元数据)。
123.在一些实施例中，编码器303是沉浸式语音和音频服务(ivas)核心编码器。ivas核心编码器可以被配置为接收音频信号，并根据ivas标准来对这些音频信号进行编码。
124.在一些实施例中，编码器303还包括元数据编码器。该元数据编码器被配置为接收空间元数据和/或其他元数据(例如，标识与语音音频信号相关联的语言)，并以任何合适的方式对其进行编码或压缩。
125.在一些实施例中，编码器303包括复用器，其被配置为在被发送之前，对由编码器生成的编码的音频信号和/或元数据进行组合或复用。
126.用户1设备101进一步被配置为控制编码比特流的发送。在一些实施例中，用户1设备101包括被配置为发送比特流的发射机。
127.用户2设备105可以包括(ivas)解码器307。(ivas)解码器307被配置为接收比特流
306，并解码(和渲染)采用第一语言的语音音频信号312和采用第二语言的语音音频信号314以用于空间音频呈现。因此，用户2设备105可以被配置为输出原始音频和翻译音频信号。
128.关于图5，示出了与图3中所示的装置的实现对应的用户体验的第一示例，其中，rtlt被实现为在用户设备上的本地服务。此示例示出了缺少服务器“讲话”，代替地存在来自用户设备的两个单独的语音音轨。
129.首先，操作用户1设备101的第一用户“讲话”，或者换句话说，用户1设备101获得采用第一语言的语音音频信号，其以初始讲话时间501示出。此语音音频信号被编码(并且在一些实施例中被编码为空间音频信号)并被发送，其被用户2设备105接收。进而，此语音音频信号在聆听时间511被渲染(在一些实施例中被渲染为空间音频信号)，该聆听时间511基本上与初始讲话时间501相同，但被延迟了算法和传输延迟时间502。
130.用户1设备101进一步被配置为基于采用第一语言的语音音频信号，生成采用第二语言的语音音频信号。该采用第二语言的语音音频信号在图5中由翻译讲话时间503示出，该翻译讲话时间503在初始讲话时间501结束之后开始并且可以进一步被延迟翻译延迟时间573(其可以被测量或被确定，并以其他方式被发信号传送到用户2设备105)。此延迟可以包括系统确认活动语音段结束的等待时间。另外，在一些实施例中，可以确定翻译时长575(与初始讲话时间相关联的翻译的开始到结束之间的时间)，并将其发信号传送到用户2设备105。
131.语音音频信号可以由用户1设备101进行渲染，该用户1设备101具有相关联的聆听(2)翻译时间513。另外，用户1设备101对采用第二语言的语音音频信号进行编码，并将其发送到用户2设备105。
132.用户2设备105的用户可以接收采用第二语言的编码语音音频信号，并对其进行渲染，其以相关联的聆听(2)翻译时间523示出，该聆听(2)翻译时间523基本上与翻译讲话时间503相同，但被延迟了算法和传输延迟时间502。如在上面所讨论的，在此示例中，为了简化起见，示出的所有算法和传输延迟502是相同的，但是由于传输路径、用户设备的处理能力的差异、以及其他变量，算法和传输延迟将可能会有所不同。
133.进而，用户2设备105的用户可以生成响应。这在图5中由响应讲话时间505示出，其中，用户2设备105获得采用第二语言的语音音频信号。此语音音频信号被编码(并且在一些实施例中被编码为空间音频信号)并被发送，其被用户1设备101接收。进而，此语音音频信号在聆听时间515被渲染(在一些实施例中被渲染为空间音频信号)，该聆听时间515基本上与响应讲话时间505相同，但被延迟了类似的算法和传输延迟502。
134.用户2设备105进一步被配置为基于采用第二语言的响应语音音频信号，生成采用第一语言的语音音频信号。该采用第一语言的语音音频信号在图5中由响应翻译讲话时间507示出，该响应翻译讲话时间507在响应讲话时间505结束之后开始并且可以进一步被延迟翻译延迟时间(其可以被测量或被确定，并以其他方式被发信号传送到用户1设备101)。如上所示，此延迟可以包括系统确认活动语音段结束的等待时间。另外，在一些实施例中，可以确定翻译时长(与响应讲话时间相关联的翻译的开始到结束之间的时间)，并将其发信号传送到用户1设备。
135.语音音频信号可以由用户2设备101进行渲染，该用户2设备101具有相关联的聆听
(2)翻译时间527。另外，用户2设备105对采用第一语言的语音音频信号进行编码，并将其发送到用户1设备101。
136.用户1设备101的用户可以接收编码的采用第一语言的响应语音音频信号，并对其进行渲染，其以相关联的聆听(2)翻译时间517示出，该聆听(2)翻译时间517基本上与翻译讲话时间507相同，但被延迟了算法和传输延迟时间502。
137.在这种示例中，示出了存在两个音轨正被第二用户收听(即，两个单独的语音音轨渲染)。这些可以是空间渲染。
138.关于图6，示出了与图3中所示的装置的实现对应的用户体验的另一示例，其中，rtlt被实现为在用户设备上的本地服务。在此示例中，翻译在原始语音段落/话语结束之前开始。这可以在其中rtlt操作以逐词地或逐句地进行翻译而不是一次一活动段落的实施例中实现。在这些实施例中，语音音频信号语音段与翻译段之间的时间偏移不需要是固定的，并且可以与图6中所示的延迟不同。例如，在一些实施例中，触发第一翻译激活的段的长度可以不同。为了简化起见，在图6中并没有明确地示出诸如算法和传输延迟以及翻译延迟之类的延迟，但是实施例将会受到这些延迟的影响。
139.首先，操作用户1设备101的第一用户“讲话”，或者换句话说，获得采用第一语言的语音音频信号，其以初始讲话时间601示出。此语音音频信号被编码(并且在一些实施例中被编码为空间音频信号)并被发送，其被用户2设备105接收。进而，此语音音频信号在聆听时间611被渲染(在一些实施例中被渲染为空间音频信号)，该聆听时间611基本上与初始讲话时间601相同，但被延迟了算法和传输延迟时间。
140.用户1设备101进一步被配置为在辅助音轨偏移时间602(其可以被发信号传送到用户2设备105)之后开始基于采用第一语言的语音音频信号来生成采用第二语言的语音音频信号。该采用第二语言的语音音频信号在图6中由翻译讲话时间603示出，该翻译讲话时间603还具有辅助音轨结束偏移值612(其可以被测量或被确定，并以其他方式被发信号传送到用户2设备105)。
141.翻译语音音频信号可以由用户1设备101进行渲染，该用户1设备101具有相关联的翻译聆听(2)时间615，作为活动信号尾部再现604。换句话说，当用户1设备的用户在初始讲话时间601结束时停止讲话时，用户1设备通过渲染活动信号尾部再现604来向用户指示用户2设备105的用户正在收听翻译。另外，用户1设备101对采用第二语言的语音音频信号进行编码，并将其发送到用户2设备105。
142.由此，用户1设备101被配置为提供两个向外发出的音轨610，采用第二语言的编码语音音频信号和采用第一语言的编码语音音频信号。
143.用户2设备105的用户可以接收采用第二语言的编码语音音频信号，并将其渲染给用户2设备的用户。这在图6中由相关联的翻译聆听(2)时间613示出。
144.进而，用户2设备105的用户可以生成响应。这在图6中由响应讲话时间607示出，其中，用户2设备105获得采用第二语言的语音音频信号。此语音音频信号被编码(并且在一些实施例中被编码为空间音频信号)并被发送到用户1设备。用户1设备101接收采用第二语言的编码语音音频信号，并且被配置为渲染(在一些实施例中渲染为空间音频信号)采用第二语言的语音音频信号，诸如在图6中由响应聆听时间617所示，该响应聆听时间617基本上与响应讲话时间607相同，但被延迟了类似的算法和传输延迟时间。
145.用户2设备105进一步被配置为基于采用第二语言的语音音频信号，生成采用第一语言的语音音频信号，该采用第一语言的语音音频信号在采用第二语言的语音音频信号结束之前开始(并且在一些实施例中，被延迟了如与辅助音轨偏移602时间相同的延迟)。采用第一语言的语音音频信号在图6中由翻译响应讲话时间609示出，该翻译响应讲话时间609在响应讲话时间607开始之后的一段时间后开始(其可以被测量或被确定，并以其他方式被发信号传送到用户1设备101)。另外，在一些实施例中，可以确定翻译时长(与响应讲话时间相关联的翻译的开始到结束之间的时间)，并将其发信号传送到用户1设备。
146.翻译的语音音频信号可以由用户2设备105渲染为活动信号尾部再现625。换句话说，当用户2设备的用户在响应讲话时间607结束时停止讲话时，用户2设备通过渲染活动信号尾部再现625来向用户指示用户1设备105的用户正在收听翻译。另外，用户2设备105对采用第一语言的语音音频信号进行编码，并将其发送到用户1设备101。
147.用户1设备101的用户可以接收采用第一语言的编码响应语音音频信号(翻译的或辅助音轨)并对其进行渲染，如以相关联的翻译响应聆听时间619所示。
148.如图6中所示，采用第一语言的编码响应语音音频信号和采用第二语言的编码响应语音音频信号是到来的或本地再现的音轨618。这些到来的或本地再现的音轨的渲染可以是空间渲染。
149.可以看出，采用第一语言的语音音频信号(所捕获的音轨)、采用第二语言的语音音频信号(rtlt音轨)与它们的“可见性(visibility)”之间存在关系。在响应信号中发现类似的关系，为了清楚起见，在此不再进一步详细讨论。
[0150]“可见性”受到“辅助音轨偏移”、辅助音轨结束偏移以及活动信号尾部再现的影响，该辅助音轨偏移定义了采用第一语言的语音音频信号的开始与采用第二语言的语音音频信号的开始之间的时间；该辅助音轨结束偏移定义了采用第一语言的语音音频信号的结束与采用第二语言的语音音频信号的结束之间的时间。
[0151]
如上所述，辅助音轨偏移和辅助音轨结束偏移可以被发信号传送到另一个设备并且被用于控制音频信号的渲染。(在一些实施例中，此信令还可以用于控制用户接口特征(诸如，例如空间音频或信号活动指示的可视化)以及控制设备屏幕上的功能可用性。)活动信号尾部再现是本地生成的针对用户的下游音频指示的示例。翻译的尾部可以例如基于时间偏移和时长信令而在空间上被渲染给讲话者。以这种方式，设备可以接收关于至少第二用户将要收听到来的音频多长时间的指示。
[0152]
在一些实施例中，可以具有指示接收用户希望结束当前的替代音轨播放的信令。这也可以被用于通过在接收方请求时结束再现来控制在发送侧的尾部再现。
[0153]
在一些实施例中，与音频信号相关联的参数或信息(诸如时间偏移和时长信息)的确定或测量可以根据实现或实施例而不同。类似地，用于对此信息或参数进行编码和信令的方法可以根据实现或实施例而不同。在一些实施例中，可以例如基于诸如平均句子长度(或平均翻译段落长度)和平均讲话速度之类的信息来得出这些信息或参数。典型的慢语速(采用英语)可以是每分钟大约100个单词，快语速甚至可以是每分钟200个单词。(例如，亨利
·
基辛格(henry kissinger)已经被引述在他的公开演讲中的平均讲话速度为每分钟90个单词，而拍卖师每分钟可以达到250个单词以上。)如果一个句子通常例如是5
‑
25个单词的长度，那么自动翻译很可能落后10
‑
20个单词。
[0154]
关于图4a，示出了另一系统配置。图4a中所示的系统与图3中所示的系统的不同之处在于：rtlt不是本地(以其他方式位于用户设备内)rtlt，而是网络rtlt服务器。
[0155]
因此，在一些实施例中，用户1设备101包括被配置为接收采用第一语言的语音音频信号400的输入端。该输入端可以被连接到(ivas)编码器303。在以下实施例中，采用第一语言的语音音频信号400是单声道音频信号。然而，在一些实施例中，音频信号400是多通道音频信号。另外，在一些实施例中，采用第一语言的语音音频信号302不是从一个(或多于一个的)麦克风捕获的音频信号，而是根据来自两个或更多个音频信号的音频信号的空间分析而生成的。在一些实施例中，空间分析可以导致音频环境内一个或多于一个的语音音频信号的确定和隔离。例如，用户1设备可以被用作音频会议系统的一部分，并且包括被配置为生成多通道音频信号输入的麦克风阵列。进而，可以对该多通道音频信号进行分析以确定是否存在一个或多个语音音频源，并针对每个语音音频源生成音频信号(例如，通过对多通道音频信号进行波束成形或以其他方式处理音频信号)。
[0156]
(ivas)编码器401被配置为接收采用第一语言的语音音频信号400，并被配置为基于所确定的编码方法来对音频信号进行编码，并生成编码比特流402。在一些实施例中，编码器401可以是计算机(运行存储在存储器和至少一个处理器上的合适的软件)，或者可替代地可以是使用例如fpga或asic的特定设备。
[0157]
在以下示例中，编码器被配置为接收单声道语音音频信号，但在一些实施例中，这些语音音频信号包括多通道音频信号。在这种实施例中，多通道音频信号在一些实施例中可以被处理以生成合适的“传输”音频信号(诸如包括单声道、立体声、一个或多个下混合的或一个或多个所选择的通道音频信号的编码音频信号，以及编码的立体声或多通道参数作为与编码的单声道音频信号相关联的元数据)。
[0158]
在一些实施例中，编码器401是沉浸式语音和音频服务(ivas)核心编码器。ivas核心编码器可以被配置为接收音频信号，并根据ivas标准来对这些音频信号进行编码。
[0159]
在一些实施例中，编码器401还包括元数据编码器。该元数据编码器被配置为接收空间元数据和/或其他元数据(例如，标识与语音音频信号相关联的语言)，并以任何合适的方式对其进行编码或压缩。
[0160]
在一些实施例中，编码器401包括复用器，其被配置为在被发送之前，对由编码器生成的编码的音频信号和/或元数据进行组合或复用。
[0161]
用户1设备101进一步被配置为控制编码比特流的发送。在一些实施例中，用户1设备101包括被配置为发送比特流402的发射机。
[0162]
网络实时语言翻译器(rtlt)403被配置为接收包括采用第一语言的编码语音音频信号400的比特流，对采用第一语言的语音音频信号400进行解码，将采用第一语言的语音音频信号400翻译成采用第二语言的语音音频信号，对采用第二语言的语音音频信号进行编码，组合采用第一语言的编码语音音频信号400和采用第一语言的语音音频信号，并输出包括编码的原始和翻译的音频信号的编码比特流404。网络实时语言翻译器(rtlt)403可以被实现为任何已知的实时翻译器，并且可以在基于翻译的软件和/或硬件(例如，ai或深度学习处理器或在设备内实现的处理器)上实现。在一些实施例中，网络rtlt服务器403被配置为至少对采用第二语言的语音音频信号进行编码，并将该音频重新打包以用于传输。因此，在一些实施例中，一个或两个语音音频信号流被发送到解码器。
[0163]
用户2设备105可以包括(ivas)解码器405。(ivas)解码器405被配置为接收比特流404，并解码(和渲染)采用第一语言的语音音频信号410和采用第二语言的语音音频信号411以用于空间音频呈现。因此，用户2设备105可以被配置为收听原始音频和翻译音频信号。
[0164]
关于图4b，示出了另一示例，其中，此示例与图3和图4a中的示例之间的区别在于解码和渲染。图4b中所示的系统与图3中所示的系统的不同之处在于：rtlt不是本地(以其他方式位于用户设备内)rtlt，而是外部rtlt服务器453。此外，图4b中所示的系统与图4a中所示的系统的不同之处在于：编码器401被配置为将包括采用第一语言的语音音频信号的比特流以比特流连接452输出到rtlt服务器435，并以比特流连接456输出到解码器405。rtlt服务器453被配置为输出包括采用第二语言的语音音频信号的比特流，并且解码器被配置为接收包括采用第二语言的语音音频信号的比特流454，该比特流454与来自编码器401的包括采用第一语言的语音音频信号的比特流456是分开的。
[0165]
在图3、图4a和图4b所示的示例中，通信仅在一个方向上示出，可以实现用于第二用户的翻译音频的传输(在图3所示的示例中通过在用户2设备105处添加另一本地rtlt，而在图4a和图4b所示的示例中通过使用网络或外部rtlt服务器)。在一些实现中，用户1还可以向用户1呈现至少一些翻译的语音。在一些实施例中，rtlt功能可以是非对称的，即，可以在仅一个方向上使用rtlt服务(本地、网络或外部)和/或获得到它的连接。另外，在一些实施例中，针对系统中各方的rtlt功能可以在不同的rtlt位置处实现。因此，例如，从用户1设备到用户2设备的翻译可以在用户1设备上实现，而从用户2设备到用户1设备的翻译可以使用外部或网络rtlt服务器来实现。
[0166]
在一些实施例中，可以在用户2设备上实现外部rtlt或网络rtlt(换句话说，在“收听者”设备上执行翻译)。
[0167]
图3的系统相对于图4a和图4b的系统的益处涉及：
[0168]
1)原始语音(第一语言)与翻译(第二语言)之间减少的延迟；以及
[0169]
2)用户控制。
[0170]
延迟减少有两个原因。首先，在一些实现中，本地rtlt可以绕过常规ivas输入将会经受的至少一些音频处理(其可能会引入延迟)。这可以涉及例如麦克风信号的均衡等等。对于rtlt输入可以绕过这种处理，因为来自rtlt的输出是可以被自动控制的合成语音。因此，rtlt输入不需要听起来对人类收听者来说是最佳的。其次，在路径中没有额外的解码/编码延迟。这通过比较图3和图4a和图4b的高级框图而被示出，其中，已知ivas处理操作会引入针对信号的延迟。此外，允许用编码器侧的操作和带内信令来控制特征。对于如随后讨论的除了rtlt以外的使用实例，这将变得显而易见。
[0171]
在一些实施例中，至少两个语言的音频信号(采用第一语言的语音音频信号、采用第二语言的语音音频信号等等)被编码器视为至少两个单独的音频对象。在这种实施例中，针对至少两个音频对象中的至少一个定义音频对象，并且该定义(例如，音频对象的位置、方向、距离、“相干性”或音频对象的相对宽度)可以由编码器作为元数据来提供(并且可以由合适的用户接口输入来定义，或者由一些自动或半自动确定来定义)。
[0172]
在一些实施例中，实现了与采用第一语言的语音音频信号相关联的第一音频对象以及与采用第二语言的语音音频信号相关联的第二音频对象。在这种实施例中，第二音频
对象被定义为用于第一音频对象的替代。在一些实施例中，这两个音频对象都被发送到接收机/解码器，其中，向接收用户提供用户接口以控制播放。在这种实施例中，接收设备的用户可以被配置为经由用户接口控制是播放这两个音频对象还是只播放这两个音频对象之一。
[0173]
在一些实施例中，这两个音频对象都被发送到接收机，其中，可以向接收用户提供用户接口以控制播放。在这种实施例中，接收用户可以被配置为经由用户接口控制解码器或渲染器以在其中一个音频对象被渲染给用户时在音频对象之间切换播放。
[0174]
在一些实施例中，至少两个语言的音频信号(采用第一语言的语音音频信号、采用第二语言的语音音频信号等等)被编码器视为至少一个基于通道的音频(例如，5.1)或基于场景的音频(例如，masa——元数据辅助空间音频或ambisonics)以及在编码器输入处的至少一个音频对象。
[0175]
在这种实施例中，针对至少一个音频对象定义音频对象“角色”，并将其提供为元数据(或者，例如，经由命令行)。
[0176]
在一些实施例中，实现了第一音频对象与采用第一语言的语音音频信号相关联以及第二音频对象与采用第二语言的语音音频信号相关联。在这种实施例中，第二音频对象被定义为用于第一音频对象的替代。在一些实施例中，这两个音频对象都被发送到接收机/解码器，其中，向接收用户提供用户接口以控制播放。在这种实施例中，接收设备的用户可以被配置为经由用户接口控制是播放这两个音频对象还是只播放这两个音频对象之一。在一些实施例中，这两个音频对象都被发送到接收机，其中，可以向接收用户提供用户接口以控制播放。在这种实施例中，接收用户可以被配置为经由用户接口控制解码器或渲染器以在其中一个音频对象被渲染给用户时在音频对象之间切换播放。
[0177]
在一些实施例中，至少两个语言的音频信号(采用第一语言的语音音频信号、采用第二语言的语音音频信号等等)被编码器视为至少两个基于通道的音频(例如，5.1)或至少两个基于场景的音频(例如，masa或ambisonics)或其合适的组合。在这些实施例中，针对至少一个空间音频输入而定义“角色”，并将其提供为元数据(或者，例如，经由命令行)。
[0178]
在一些实施例中，实现了与采用第一语言的语音音频信号相关联的第一音频通道或场景以及与采用第二语言的语音音频信号相关联的第二音频通道或场景。在这种实施例中，第二音频通道或场景被定义为用于第一音频通道或场景的替代。在一些实施例中，这两者都被发送到接收机/解码器，其中，向接收用户提供用户接口以控制播放。在这种实施例中，接收设备的用户可以被配置为经由用户接口控制是播放这两者还是只播放其中一个。
[0179]
在一些实施例中，这两组通道或场景都被发送到接收机，其中，可以向接收用户提供用户接口以控制播放。在这种实施例中，接收用户可以被配置为经由用户接口控制解码器或渲染器，以在其中一个被渲染给用户时，在采用第一语言的语音音频信号所关联的该组通道或场景与采用第二语言的语音音频信号所关联的该组通道或场景之间切换播放。
[0180]
在一些实施例中，由于处理延迟，因此，至少一个rtlt语言音频信号(或场景或音频信号)落后于至少一个原始语言音频信号(或场景或音频信号)。换句话说，至少一个rtlt语言音频信号被延迟了至少开始翻译所花费的时间(例如，输入要被翻译的至少一个单词)。另外，至少一个rtlt语言音频信号可以具有与至少一个原始语言音频信号不同的长度(总时长)。这是因为单词/句子/话语在两个不同的口语中可具有非常不同的长度/时长(还
至少部分取决于翻译的准确度)。在一些实施例中，系统可以发信号传送此信息，例如，以用于用户控制的目的。虽然真实用户的活动语音段落的时长只能在该段落结束之后被计算(例如由于背景噪声、呼吸噪声等等的存在而具有与活动信号的确切开始和结束有关的歧义)，但是可以在该段落结束之前预先计算合成信号(“计算机语音”)的长度，并且可以在没有诸如呼吸、背景噪声等之类的歧义的情况下定义活动部分。
[0181]
因此，在一些实施例中，在至少一个第一音轨上执行本地信号活动性确定，例如，语音活动检测(vad)操作。基于活动检测，以及在一些实施例中基于来自生成至少一个第二语言音频信号的音频处理的指示，指示采用第一语言的语音音频信号所关联的第一音频通道或场景与采用第二语言的语音音频信号所关联的第二音频通道或场景之间的偏移的信息/参数被生成并被发送。另外，在一些实施例中，可以确定并发送指示至少一个第二语言音频信号(相对于至少一个第一语言音频信号)的结束时间偏移和/或时长的信息/参数。
[0182]
在一些实施例中，rtlt处理被配置为确定并指示采用第一语言的语音音频信号所关联的第一音频通道或场景与采用第二语言的语音音频信号所关联的第二音频通道或场景之间的延迟，并将其流传输给解码器。
[0183]
在一些实施例中，rtlt处理器被配置为确定并发送指示与采用第二语言的语音音频信号(翻译的合成音轨)相关联的第二音频通道或场景的时长的参数。
[0184]
在一些实施例中，rtlt处理器被配置为生成并发送仅流结束时间偏移/时长信息。
[0185]
用于结束时间偏移/时长信息信令的实现的示例关于下表被示出。
[0186]
码0(1)00(1)01(1)10(1)11值无更新250+帧51
‑
250帧最多50帧段结束
[0187]
在此示例中，基于上述讨论考虑了音频编解码器和用户接口(ui)的实际数量。具有典型句子或话语长度的平均语速(在下限与上限之间的速度的两倍)可能会导致辅助音轨落后少至大约1秒或者多至10秒或更长时间。对于在20毫秒帧上操作的诸如ivas之类的典型会话音频编解码器，这对应于大约50
‑
500帧的延迟。当使用带内信令时，它通常将会是逐帧地或以特定更新间隔进行的。在上面所示的表格中，示出了可以是逐帧的或特定更新帧的一部分的码信令。应当理解，当前信息的逐帧信令可能是浪费的，并因此实施例可以被配置为不在每帧中都发送信息。
[0188]
在上面的示例中，第一比特指示更新(0/1)。其后跟随两个比特，提供关于剩余帧数的信息(如果进行了更新，则第一比特为1)。需要注意，当段的长度未知时，可以首先提供“无更新”。“无更新”也可以被用于节省比特率。在一些实施例中，“段结束”信号可以不是必需的。在一些实施例中，可以单独地发信号传送段的结束，或者，例如可以使用活动检测来推断没有音频信号内容剩余。在一些实施例中，计数器可以被用于对自上次已知更新帧以来的帧进行计数。内容音轨的时长对于渲染中的信号处理可以是有用的(例如，对于存储器更新、复杂性降低)，并且对于可以从解码器/渲染器接收信息并向渲染器提供至少控制信息(并且在一些实现中也可以将其发信号传送到发送端的编码器)的用户接口(ui)也可以是有用的。
[0189]
不同的值和实现是可能的。例如，在上面被定义为采用第二语言的语音音频信号302或辅助音轨的音频信号或音轨可以旨在用于除了rtlt之外的其他使用实例。在一些实施例中，时长范围可以与以上所讨论的那些不同。
[0190]
在一些实施例中，可以发送关于采用第一语言的语音音频信号(至少一个原始语言音轨)的参考信息(诸如活动段落定时信息)。
[0191]
在一些实施例中，基于接收方的本地语音活动检测(vad)，可以生成并发送请求，诸如编解码器模式请求(cmr)，或者，例如替代的音轨请求(atr)。具体地，该模式请求可以涉及停止当前活动的辅助替代(语言)音频的传输。
[0192]
在一些实施例中，基于接收方的ui指示，可以创建用于编解码器模式请求(cmr)的信令。具体地，该模式请求涉及停止当前活动的辅助替代(语言)音频的传输。
[0193]
同样在一些实施例中，基于接收方的ui指示，可以创建用于编解码器模式请求(cmr)的信令。具体地，该模式请求涉及重新开始当前活动的或先前的辅助替代(语言)音频的传输。在这些实施例中的“当前活动”可以依据流时间偏移和结束时间同步信令来定义。
[0194]
在一些实施例中，在编码之前，采用第二语言的语音音频信号被插入/被混合到masa空间床(masa spatial bed)中。例如，至少一个masa输入提供原始音频，而至少一个音频对象提供翻译。在ivas编码器内执行音频混合，其中，新的下混合masa传输通道代替原始masa传输通道和至少一个翻译的音轨，并且翻译的音频由第二音频方向表示。如果masa元数据已经包含两个方向，那么在编解码器内表示可以被扩展为三个方向，或者翻译音频方向可以代替第二方向。在一些实施例中，向解码器发送指示此操作的信令标志。
[0195]
因此，例如在一些实施例中，在编码之前，采用第二语言的翻译语音音频信号被插入/被混合到masa空间床中。例如，至少一个masa输入是与采用第一语言的语音音频信号相关联的第一音频通道或场景，并且采用第二语言的语音音频信号(或音频通道或场景)被提供为至少一个音频对象。进而可以在ivas编码器内执行音频混合。进而，下混合masa传输信道可以代替原始masa传输信道，并且替代的masa传输信道代替至少一个音频对象。在一些实施例中，masa元数据包括翻译音频通过第二音频方向的表示。在masa元数据已经包含两个或更多个方向的一些实施例中，在编解码器内表示可以被扩展为三个或更多个方向，或者翻译音频方向可以代替第二方向。在一些实施例中，附加信令标志被发送到解码器。
[0196]
在一些实施例中，音频信号被预先混合并被转换成除了masa以外的一些空间格式。例如，音频信号被转换成ambisonics格式。在这种实施例中，声音场景内的翻译音频信号(音轨)空间位置进而被发信号传送到解码器。
[0197]
在一些实施例中，预先混合在编码器外部执行。
[0198]
在一些实施例中，可以使用包括一个或多个音频信号的单独的输入音频“音轨”以用于提供附加功能。
[0199]
先前已经在专利申请gb1811847.1和pct/ep2018/079980中讨论了经由ivas的音频焦点(audio focus)。根据专利申请gb1811847.1和pct/ep2018/079980，音频焦点对象可以与主空间信号一起被传送。这些对象具有相对于收听位置和声音场景(空间床)的空间位置。以这种方式，提供了一种特定的音频信号，其可以根据由其方向(或坐标)给出的空间位置而与空间床信号一起被混合。音频焦点对象在给定方向上对空间声源进行强化。它可以通过ui提供，其中，收听者能够例如开启/关闭音频焦点效果或更改其强度，即，使用音频焦点对象来应用源特定的音量控制。音频聚焦的一个使用实例是在嘈杂的周围环境中捕获说话者或讲话者。收听者可能对环境感兴趣，但是由于背景信号电平，讲话者可能难以被听到。借助于音频焦点，收听者可以控制音量平衡并更好地听到讲话者，同时还能听到环境音
频。
[0200]
在专利申请gb1811847.1和pct/ep2018/079980中，描述了与音频焦点对象的角色有关的示例信令。在一些实施例中，在rtlt实施例中被描述为语音音频信号的“辅助音轨”可以被定义为更多的角色。
[0201][0202][0203]
在这种实施例中，编码器/解码器可以具有表示个体/独立声源的通用默认音频对象类型。例如，会议桥可以具有许多上游连接(例如，使用evs和ivas)并且(使用ivas)对下游场景进行空间渲染，其中，各个源由对象表示。作为具体示例，evs上游可以被赋予空间位
置并作为音频对象向下游发送。应当理解，用户可以完全控制用于这种音频对象的空间位置和其他渲染参数(例如，增益)。音频场景可以与仅一个音频对象相关。
[0204]
在一些实施例中，这种实现还可以支持更加受限的音频对象的使用。以不准许(接收方)用户修改或改变与音频对象的空间渲染有关的至少一些参数的方式，可以对更加受限的对象进行定义。例如，艺术意图可涉及不允许用户改变的音频源的空间定位。在一些实施例中，音频场景可以与仅一个音频对象相关。
[0205]
在一些实施例中，音频场景可以与仅某种单个音频对象不相关。例如，特定类型的受限音频对象是附加音频对象，例如，音频焦点对象。这种音频对象可以被认为是仅附加的，换句话说，它不可以被单独地传送。通常可存在其他限制，例如，在音频焦点对象的情况下，接收用户不能任意地控制对象的空间位置。
[0206]
在一些实施例中，替代的并发音频对象类型是允许例如rtlt采用如在上面实施例中所描述的方式的音频对象类型。在这种实施例中，准许同时呈现至少两个音频对象。然而，它们可以被认为是替代方案，并且在一些实施例中可以基于用户输入来进行选择或不选择(或移除/去激活)。例如，在rtlt操作用户的情况下，可以向用户传送原始语言音轨和一个或多个翻译音轨(对应于一个或多个不同的语言)。
[0207]
在一些实施例中，用于替代的并发音频对象的另一个使用实例示例是将增强现实(ar)音频流嵌入到ivas呼叫中。
[0208]
在这种实施例中。ar使用实例可以被概括为以下步骤：
[0209]
用户1在旅游中并在历史悠久的市中心散步；
[0210]
操作用户设备的用户1打电话回家，并向用户2(接收方)描述他看到了什么；
[0211]
用户2对历史遗址感兴趣，并请求(询问)以了解更多信息；
[0212]
用户1所使用的用户设备具有增强现实应用，并选择有关他们正在经过的建筑物的音频故事；
[0213]
ar音频被输入到ivas编码器中，并且作为替代音频对象与相对于主音频(用户1的语音)的偏移和时长信令一起被发送；
[0214]
使用他们的用户设备，ar音频被发送并被空间渲染给用户2；
[0215]
用户1听到(或在他们的设备上看到)用户2是否继续播放ar音频；
[0216]
当用户2已经听够了当前的建筑物时，他们取消ar音频。这被发信号传送给用户1；
[0217]
用户1现在能够选择将要被发送的下一个ar音频。
[0218]
替代的交替音频对象允许在播放中在(通常)两个音频对象之间直接进行切换。发信号传送一个音频对象是优选(默认)音频对象，以及用户可以从一个音频对象切换到另一个音频对象，由此，激活第二音频对象会去激活第一音频对象，反之亦然。还可以支持多于两个的这种音频对象的轮询型“轮播”(round
‑
robin type“carousel”)。例如，在rtlt操作的情况下，可以向用户传送原始语言音轨和两个翻译音轨(对应于两个不同的语言)，用户可以被允许在这些音轨之间切换。
[0219]
可以允许在上表中给出的角色的一些类型组合。例如，ar服务可以借助替代的并发音频对象来提供话外音(voice over)，该替代的并发音频对象它本身就实现了用于语言选择的替代的交替音频对象。
[0220]
还应理解，接收用户例如可以被发送由若干音频对象(或音频对象组)组成的音频
场景，该若干音频对象可以具有独立于其他音频对象(或音频对象组)的各种角色。例如，被传送给用户的音频场景可以由诸如会议系统之类的服务或由任何其他合适的服务基于至少一个音频输入来创建。音频场景可以包括例如至少两个独立的讲话者(例如，用户从他们各自的家进行呼叫)或来自同一捕获空间(例如，共享会议室)的至少两个讲话者，其中，每个讲话者可以由至少一个音频对象表示，并且可以使用rtlt。例如，每个讲话者可以借助替代的并发或替代的交替音频对象来表示。因此，对于接收用户，音频场景可以被呈现以使得：在第一方向上用户听到采用第一语言的第一讲话者的语音，在第二方向上用户听到采用第二语言的第二讲话者的语音，在第三方向上用户听到采用第三语言的第一讲话者的语音，以及在第四方向上用户听到采用第四语言的第二讲话者的语音。可替代地，对于接收用户，音频场景可以被呈现以使得：用户在第一方向上听到采用第一语言的第一讲话者的语音或者在第三方向上听到采用第三语言的第一讲话者的语音，以及在第二方向上听到采用第二语言的第二讲话者的语音或在第四方向上听到采用第四语言的第二讲话者的语音。在后一种情况下，第一和第三方向可以是相同的方向，第二和第四方向可以是相同的方向。
[0221]
音频对象角色或类型可以是明确的，或者可以具有伴随音频对象的单独的元数据。例如，音频对象位置可以作为绑定位置(不允许接收用户更改)而被发送到接收机，或者它可以是用户可改变的默认位置。此外，还可以具有附加的控制元数据。这种元数据可以指示例如用于编码的优先级规则或流依赖性规则(如在专利申请gb1811847.1和pct/ep2018/079980中所讨论的)或其他流定时相关信息，诸如可以被发信号传送的rtlt音轨/对象相对于主(原始语言)语音音轨/对象的时间偏移和时长。
[0222]
在一些实施例中，音频对象角色被定义为各个性质的组合。因此，可以发信号传送例如音频对象应当或必须在解码器/渲染器处可分离。这定义了至少一个性质，诸如“可分离性(separability)”或“可分离度(degree of separability)”。进而，可以另外发信号传送例如音频对象被链接到至少第二音频对象。这定义了至少一个附加性质，以此类推。例如，角色可以在音频编码器输入端处被表达为性质列表或性质矩阵。在前一种情况下，与音频对象有关的所有性质都是单独提供的。在后一种情况下，基于性质矩阵(或列表)指示音频对象是否具有各个性质(如果是，则指示其值)。在一些实施例中，可以使用这些方法的合适组合。
[0223]
在一些实施例中，由执行编码的用户设备确定并由解码器/渲染器传送和使用(并且在一些实施例中，通过执行解码/渲染的设备ui进行控制)的信息是替代音频的时长。该时长可以是总时长或剩余时长。
[0224]
在一些实施例中，可以具有多个相关音频段落，例如，多个替代的并发音频对象。在这种实施例中，可以发送参考信息。例如，在多个并发音频对象的示例中，发送指示参考音频对象何时可以为活动的定时信息。
[0225]
在具有多于一个的并行辅助音轨的一些实施例中，所允许的信令需要考虑这一点。空间呈现允许声源(音轨)的同时呈现，以使得用户可以专注于对于接收用户最关键或最感兴趣的那一点处的声源。在这种实施例中，接收机所经历的任何等待时间或延迟可以在声源之间进行切换时被消除。例如，当用户1(当前正在讲话的人)听到rtlt音轨的结束或结尾时，因此可以(在其结束之前)“要求发言权(claim the floor)”并继续讲话。在一些实施例中，这可以扩展现有的rtlt音轨或创建进一步的rtlt音轨。在此示例中，可以存在从用
户1到用户2的rtlt音频的两个同时呈现。第一个呈现对应于第一段的尾部，而第二个呈现对应于新开始的第二段。在一些实施例中，这些可以被呈现为空间分离的。
[0226]
另一方面，当用户1没有在讲话并且rtlt仍在被呈现时，用户2可以取消音频，并在完成rtlt音频呈现之前为他们自己“要求发言权”。这对于用户1来说是清楚的，因为他们会听到用户2(及他们的rtlt音轨)，以及根据信令和可能的音频播放修改。
[0227]
在如上所述的这些实施例中，用户之间的交互更加灵活，并且会话更加自然。
[0228]
在一些实施例中，可以通过使用元数据来从一个用户设备向另一个用户设备发信号传送信息，在一些实施例中，元数据可以是或包括masa格式的元数据。
[0229]
例如，如图7a中所示，其示出了元数据格式700，其中，具有通用元数据元素701、具有每tf(时间
‑
频率)子帧/图块一个方向的(masa)元数据元素、以及通用空间元数据705。
[0230]
类似地，图7b示出了元数据格式750，其包括通用元数据元素701、每tf(时间
‑
频率)子帧/图块第一方向的元数据元素753、每tf(时间
‑
频率)子帧/图块第二方向的元数据元素755、以及通用空间元数据757元素。在这两种示例格式中，通用元数据可以包括定义通道数量和通道描述(其例如可以被称为通道音频格式参数)以及定义方向数量的信息。
[0231]
在一些实施例中，方向性元数据可以采用以下格式：
[0232][0233]
通用空间元数据可以是取决于方向(的数量)。通用空间元数据的示例可以是：
[0234][0235]
这些格式只是一些示例，并且信息可以采用任何合适的方式用信号发送，并因此可以包括新的参数或者例如移除距离参数。
[0236]
在一些实施例中，编解码器内的编码和解码以及编解码器的能力可以基于发生的协商而被配置为在至少两方之间建立音频呼叫。由此，在一些实施例中，这种协商可以明确地包括这些特征，例如，rtlt和/或音频焦点特征(或任何其他合适的特征)，或者它可以隐含地允许这种特征。例如，音频对象角色及它们的时间依赖性信令可以在不同的应用和服务中以各种方式被使用。
[0237]
除了rtlt和ar应用之外，辅助或进一步的(或替代的)并发音轨的实现可以被用于任何合适的应用或使用实例。这些应用或使用实例包括：
[0238]
‑
实时语言翻译(rtlt)
[0239]
‑
增强现实(ar)
[0240]
‑
广告
[0241]
ο例如，基于本地语音分析而选择的上下文相关广告。
[0242]
‑
警报
[0243]
ο例如，网络服务向下游中插入提供本地警报的音频对象(基于用户的位置/小区)。
[0244]
关于图8，示出了可用作分析或合成设备的示例电子设备。该设备可以是任何合适的电子设备或装置。例如，在一些实施例中，设备1400是移动设备、用户设备、平板计算机、计算机、音频播放装置等。
[0245]
在一些实施例中，设备1400包括至少一个处理器或中央处理单元1407。处理器1407可被配置为执行诸如本文所描述的方法的各种程序代码。
[0246]
在一些实施例中，设备1400包括存储器1411。在一些实施例中，至少一个处理器
1407被耦合到存储器1411。存储器1411可以是任何合适的存储部件。在一些实施例中，存储器1411包括用于存储可在处理器1407上实现的程序代码的程序代码部分。此外，在一些实施例中，存储器1411还可包括用于存储数据(例如，根据本文所描述的实施例的已被处理或将要处理的数据)的存储数据部分。无论何时只要需要，处理器1407就可经由存储器
‑
处理器耦合来获取存储在程序代码部分中的实现程序代码和存储在存储数据部分中的数据。
[0247]
在一些实施例中，设备1400包括用户接口1405。在一些实施例中，用户接口1405可被耦合到处理器1407。在一些实施例中，处理器1407可控制用户接口1405的操作并从用户接口1405接收输入。在一些实施例中，用户接口1405可使得用户能够例如经由键盘将命令输入到设备1400。在一些实施例中，用户接口1405可使得用户能够从设备1400获得信息。例如，用户接口1405可包括被配置为将信息从设备1400显示给用户的显示器。在一些实施例中，用户接口1405可包括触摸屏或触摸界面，其能够使得信息被输入到设备1400并且还向设备1400的用户显示信息。在一些实施例中，用户接口1405可以是用于与如本文所描述的位置确定器通信的用户接口。
[0248]
在一些实施例中，设备1400包括输入/输出端口1409。在一些实施例中，输入/输出端口1409包括收发机。在这种实施例中，收发机可被耦合到处理器1407并且被配置为使得能够例如经由无线通信网络与其他装置或电子设备进行通信。在一些实施例中，收发机或任何合适的收发机或发射机和/或接收机装置可被配置为经由有线或有线耦合与其他电子设备或装置通信。
[0249]
收发机可通过任何合适的已知通信协议与其他装置通信。例如，在一些实施例中，收发机可使用合适的通用移动电信系统(umts)协议、诸如例如ieee 802.x的无线局域网(wlan)协议、诸如蓝牙的合适的短距离射频通信协议、或者红外数据通信路径(irda)。
[0250]
收发机输入/输出端口1409可被配置为接收信号，并且在一些实施例中通过使用执行合适的代码的处理器1407来确定如本文所描述的参数。此外，设备可生成合适的下混合信号和参数输出以发送到合成设备。
[0251]
在一些实施例中，设备1400可被作为合成设备的至少一部分。这样，输入/输出端口1409可被配置为接收下混合信号，并且在一些实施例中接收如本文所描述的在捕获设备或处理设备处确定的参数，以及通过使用执行合适的代码的处理器1407来生成合适的音频信号格式输出。输入/输出端口1409可被耦合到任何合适的音频输出，例如被耦合到多通道扬声器系统和/或耳机(其可以是头戴跟踪式或头戴非跟踪式耳机)或类似物。
[0252]
通常，本发明的各种实施例可以采用硬件或专用电路、软件、逻辑或其任何组合来实现。例如，一些方面可以采用硬件实现，而其他方面可以采用可由控制器、微处理器或其他计算设备执行的固件或软件实现，但是本发明不限于此。虽然本发明的各个方面可被示出并描述为框图、流程图或使用一些其他图示表示来示出或描述，但是应当充分理解，本文所描述的这些框、装置、系统、技术或方法可以作为非限制性的示例采用硬件、软件、固件、专用电路或逻辑、通用硬件或控制器或其他计算设备、或其一些组合来实现。
[0253]
本发明的实施例可由计算机软件、或由硬件、或由软件和硬件的组合来实现，计算机软件是移动设备的数据处理器可执行的，诸如在处理器实体中。此外，在此方面，应当注意附图中的逻辑流程的任何框都可表示程序步骤、或互连的逻辑电路、块和功能、或程序步骤和逻辑电路、块和功能的组合。软件可存储在物理介质上，诸如存储器芯片、或在处理器
内实现的存储器块、诸如硬盘或软盘的磁介质、以及诸如dvd及其数据变体、cd的光学介质。
[0254]
存储器可以是适合于本地技术环境的任何类型，并且可使用任何合适的数据存储技术来实现，诸如基于半导体的存储器设备、磁存储器设备和系统、光存储器设备和系统、固定存储器、以及可移动存储器。数据处理器可以是适合于本地技术环境的任何类型，并且作为非限制性示例可包括通用计算机、专用计算机、微处理器、数字信号处理器(dsp)、专用集成电路(asic)、门级电路、以及基于多核处理器架构的处理器中的一个或多个。
[0255]
本发明的实施例可在诸如集成电路模块的各种组件中实践。集成电路的设计基本上是高度自动化的过程。复杂且功能强大的软件工具可用于将逻辑级设计转换成准备在半导体衬底上蚀刻和形成的半导体电路设计。
[0256]
程序，诸如由加利福尼亚州山景城的synopsys公司和加利福尼亚州圣何塞的cadence design所提供的程序，可以使用完善的设计规则以及预先存储的设计模块库来自动对导体进行布线并将组件定位在半导体芯片上。一旦完成了半导体电路的设计，就可以将标准化电子格式(例如，opus、gdsii等)的所得设计传送到半导体制造设施或“fab”进行制造。
[0257]
前面的描述已经通过示例性和非限制性示例提供了本发明的示例性实施例的完整和有益的描述。然而，当结合附图和所附权利要求书阅读时，鉴于以上描述，各种修改和改编对于相关领域的技术人员而言将变得显而易见。但是，本发明的教导的所有这些和类似的修改仍将落入所附权利要求书所限定的本发明的范围内。