CN1217317C - 音频信号编码 - Google Patents

Abstract

一种通过远程通信链路对音频信号进行传输的系统，其生成这些信号作为，例如，不同数据率下的两种或更多的备选输入。使用具有不同帧长度的帧结构的编码方法对这两种输入进行编码。为了便于在这两种输入之间进行切换，在概念上将输入信号划分为多个时间部分，通过将其本身加上足够多的下一个(或者前一个)部分，从而构成整数个帧，并且对其进行编码，从而至少对于一个输入，编码部分是交叠的。在解码时，通过丢弃重复的资料而消除交叠。

Description

音频信号编码

技术领域

本发明涉及通过远程通信链路对数字编码资料进行传输，从而呈示给用户。

发明内容

根据本发明的一个方面，提供了一种对音频信号进行编码的方法，包括：

在概念上将输入信号划分为连续的时间部分；

使用具有第一帧长度的第一编码算法，对所述的输入时间部分进行编码，以生成编码时间部分的第一编码序列；

使用第二帧长度，对所述的输入时间部分进行编码，以生成编码时间部分的第二编码序列；

其中，至少一个编码步骤包括将一个输入时间部分与前一个时间部分的末尾部分和/或后一个时间部分的起始部分一起进行编码，该末尾部分和/或起始部分与所述的一个时间部分一起构成整数个帧。

另一方面，本发明提供了一种对输入音频信号进行编码的方法，包括：使用具有第一帧长度的第一编码算法，对输入信号的各个连续的第一时间部分进行编码，以生成第一编码序列，该第一时间部分对应于所述第一帧长度的整数数目，是邻接的或者交叠的；使用具有第二帧长度的第二编码算法，对输入信号的各个连续的第二时间部分进行编码，以生成第二编码序列，使得第二编码序列的各个交叠区域至少部分地围绕对应于输入信号连续时间部分的第一编码序列之间的边界或者重叠区域部分，该第二时间部分对应于所述第二帧长度的整数数目，但不对应于所述第一帧长度的整数数目，并且是交叠的。

注意，下面的描述和附图与我们待审批的标题为“Delivery of Audioand/or Video Materiall(音频和/或视频资料的传输)”的国际专利申请中包含的描述和附图相同，其与本申请在同一天提交，要求GB 0030706.6的优先权。

附图说明

下面参照附图对本发明的一些实施例进行描述，附图中：

图1显示的是所要描述的系统的总体结构；

图2显示的是用于此类系统中的终端的方框图；

图3显示的是典型的索引文件的内容；

图4是一个时序图，解释了一种改进的子文件生成方法；

图5显示的是一种改进的结构。

具体实施方式

图1所示系统的目标是通过远程通信网络向用户传输数字编码音频信号(例如，所记录的音乐或者语音)，传输给用户终端，在此处，将相应的声音播放给用户。但是，如同将在下面将要详细描述的，该系统可以用于传输视频信号，而不是，或者附加于音频信号。在本例中，网络是互联网或者根据超文本传输协议(请参考RFCs 1945/2068)进行操作的其它分组网络，虽然在原理上，也能够使用其它的数字链路或者网络。同时假设音频信号是使用ISO MPEG-1第三层标准(“MP3标准”)以压缩形式进行记录的。然而，也不必要使用此特别的格式。实际上，也不必使用该压缩形式，虽然事实上其是很可取的，尤其是如果可用的比特率有限，或者存储空间有限。在图1中，通过互联网2将服务器1连接到用户终端3，仅显示了其中之一。服务器1的功能是存储数据文件，从用户终端接收传输所要求数据文件的请求，响应于此请求，通过网络将文件传输到用户终端。通常，此类请求的第一部分指示网络传输机制(例如，对于超文本传输协议或者文件传输协议分别是http://或者file://)，后面跟着服务器的网络地址(例如，www.serverl.com)，后面为所请求文件的名称。注意，在给出的实例中，由于打字的原因，此类名称中由“\\”代替“//”。

在这些实例中，假设使用超文本传输协议；这并非是必要的，但是有益于允许使用由该协议所提供的验证和安全特征(诸如安全套接层)。

通常，用于传输MP3文件的服务器采用所谓的流服务器的形式，其包括根据用户终端处的播放要求对数据传输速率进行动态控制、掩蔽由于分组丢失所导致的错误、以及如果允许用户交互操作，则控制服务器和客户机之间的数据流的处理机制。但是此处，服务器1无需具有这些。因此，其仅仅是一个普通的“网络服务器”。

现在描述数据文件在服务器1上的存储方式。假设已经创建了MP3格式的文件，并且要存储在服务器上。假设其是D小调的J.S.巴赫的Toccata(BWV565)的录音，其通常的演奏时间为9分钟。最初，将其创建为一个单独的数据文件，在普通的流服务器上存储为一个单独的文件。但是，此处，在将其存储到服务器1上之前，将该文件分割为多个较小的文件。我们希望这些较小文件中的每一个都具有与可能是4秒的固定演奏时间相对应的大小。使用诸如MP3的压缩格式，这可能意味着这些文件实际包含不同大小的比特数目。因此，将9分钟时间的巴赫文件分为135个小的文件，每一个具有4秒钟的演奏时间。在本实例中，这些文件的名称包括用于指示其在原始文件中的顺序的序号，例如：

000000.bin

000001.bin

000002.bin

000003.bin

.

.

000134.bin

将文件分为这些较小的子文件的操作，通常由准备将该文件装载到网络服务器1上的人员来完成。(这里使用术语“子文件”，以将其与包含整个记录的原始文件区分开来，然而必须强调的是，对于服务器而言，各个“子文件”就是一个与任何其它文件一样的文件)。下面将更为详尽的对其精确的生成方式进行描述。一旦创建完毕，就以通常的方式将这些子文件上载到服务器上去，就像上载到网络服务器上的任何其它文件一样。当然，文件名也可以包含用于识别特定记录的字符(子文件也可以使用附加信息进行“标签”——当你播放MP3文件时，你能够得到关于作者、版权等的信息)，但是在此实例中，将这些子文件存储在服务器上的专用于该特定记录的目录或者文件夹中，例如，mp3_bwv565。因此，当需要的时候，可以以下面的形式请求子文件：

http:\\www.serverl.com/mp3_bwv565/000003.bin

其中，www.serverl.com是服务器1的URL。

对于准备将子文件上载到服务器上的人员而言，针对各个记录，创建一个同样存储在服务器上的链接页面(通常是HTML格式的)也是很方便的(或许其文件名为mp3_bwv565/link.htm)。将在后面对其结构和目的进行描述。

对于网络服务器而言，存储一个或多个包含可用记录列表的(html)菜单页面(例如，menu.htm)也是很方便的，其具有到相应链接页面的超级链接。

对于终端，其通常是传统的台式计算机，但是具有用于处理接收所讨论的音频文件的附加软件。如果需要，终端也可以是便携计算机，或者甚至可以嵌入到移动电话中。因此，图2显示了这样的一个终端，其具有中央处理器30，存储器31，磁盘存储器32，键盘33，视频显示器34，通信接口35，以及音频接口(“声卡”)36。对于视频传输，可以使用视频卡代替卡36，或者在其基础之上进行添加。以通常的方式，程序存储在磁盘存储器中，能够由存储器31进行读取，由处理器30运行。这些程序包括通信程序37，用于对html页面进行调用和显示，即诸如NetscapeNavigator或者Microsoft Explorer的“网络浏览器”；还有程序38，此处称为“播放器程序”，其提供了播放根据本发明实施例的音频文件所需的功能。同样，还显示了存储器31的区域39，其用作缓存器。这是一个解码音频缓存器，包含等待播放的数据(通常，缓存器的播放时间为10秒)。音频接口或声卡36可以是通常的板卡，仅用于接收PCM音频，并且将其转换成为模拟音频信号，例如，用于通过扬声器进行播放。首先，我们对使用HTTP和嵌入式或“插入式”客户机时终端读取和播放所需记录的操作进行概述。

1、用户使用浏览器，从服务器1上对菜单页面menu.htm进行读取和显示；

2、用户在菜单页面中选择一个超级链接，其使得浏览器从服务器上读取所需记录的链接页面，并且进行显示，在本例中，该文件是mp3_bwv565_link.htm。该页面的实际显示并不重要(除了其可能会包含消息，用于使用户放心，系统正在正常工作)。对此页面，重要的是其包含一个命令(或者“嵌入标签”)，用于在处理器30中调用次级进程，在其中运行播放器程序37。以此方式对次级进程进行调用是众所周知的(此类进程在Netscape系统中称为“plug-in”，而在Microsoft系统中称为“ActiveX”)。此命令还可以包含要传递到次级进程的参数，而在图1中的系统中，该命令包含记录的服务器URL，对于巴赫的记录，其为http:\\www.serverl/mp3_bwv565。

3、播放器程序37包括MP3解码器，其操作本身采用通常的方式。这里更重要的其控制功能，如下所述。

4、接收到URL的播放器程序将第一个子文件的文件名添加到该URL，以生成子文件的完整地址，例如，www.serverl/mp3_bwv565/000000.bin。注意到，本系统是基于以上述方式对子文件进行命名而构建的，从而不必将文件名通知给终端。该程序构建对具有此URL的文件的请求消息，并且通过通信接口35和互联网2，将其传输给服务器1。(将URL翻译为IP地址，以及对无效、不完整或者不可用URL的错误报告的处理，采用通常方式，此处不再赘述)。我们设想播放器程序将请求直接发送到通信接口，而不是通过浏览器。服务器通过传输所请求的子文件而进行响应。

5、播放器程序从文件中确定此子文件中使用的音频编码，并且根据相关的标准(在本例中为MP3)，将文件解码还原为最初的PCM值，对此子文件的播放时间作出标记。通常，音频文件在文件的开始包含标识符，其说明所使用的编码方式。然后将解码的音频数据存储在音频缓存器38。

6、播放器程序具有称为播放时间Tp的参数。在本实例中，将其设定为10秒(如果需要，可以由用户进行选择)。其决定了终端所执行的缓冲级别。

7、播放器程序将文件名递增为000001.bin，并且按照上述(4)、(5)步骤，对此第二个子文件进行请求、接收、解码和存储。其重复此处理，直到缓存器的内容到达或者超过播放时间Tp。注意，不必要在缓存器之前进行解码，但是这样简化了处理，因为在将音频解码还原为PCM之后，缓存部分的持续时间就会很清楚。如果各个子文件都是相同的音频播放规格，则可以简化音频缓存器的控制。

8、当到达播放阈值Tp后，将解码的数据从缓存器发送到音频接口36，其通过扬声器(未显示)而播放声音。

9、当在上述的(8)中播放声音时，播放器程序连续地对缓存器的满存状态进行检测，当其低于Tp时，其再次递增文件名，并且从服务器获得下一个子文件。重复这个过程，直到返回“错误：未找到文件”。

10、在此过程中，如果缓存器变空，则播放器程序停止播放，直到又有数据到达。

此处优选使用的命名规则是从零开始的固定长度的序号，原因是易于实现，但是只要播放器程序包含(或者被传送了)第一个子文件的名称和能够使其计算后续子文件的算法，或者被传送了文件名的列表，就可以使用任意的命名规则。

注意到，上述的系统没有为用户提供在播放过程中进行干预的机会。也没有提供对缓存器下溢(例如，由于网络拥塞)的补救。因此，现在描述本发明的第二个更为完善的实施例，其提供了下述更多的特征：

a)服务器存储两个或者更多版本的记录，其以不同的压缩率进行记录(例如，分别以8、16、24、和32KB/s的(连续)数据率进行压缩)，而播放器程序能够自动地在它们之间进行切换。

b)播放器程序为用户提供控制面板，从而用户可以开始播放，暂停，重新播放(从开始，或者从其暂停处开始)，或者跳转到该记录的不同点(向前或者向后)。

注意，由于无需数据率切换即可进行用户控制，反之亦然，所以这些功能不是相互依赖的。

为了提供数据率切换，准备将文件装载到服务器上的人员通过以不同的数据率对同一个PCM文件进行多次编码，从而准备好数个源文件。然后，他按照前面的方式，将各个源文件分为子文件。可以将这些子文件装载到服务器对应于不同数据率的单独目录中，在下面的示例结构中，目录名中的“008k”、“024k”指的是8KB/s和24KB/s的数据率，其它依此类推。

他也可以创建索引文件(例如，index.htm)，其主要目的是提供可用的数据率目录。

目录	子目录	文件名
			mp3_bwv565	无	link.htmindex.htm
mp3_bwv565	008k_11_m	000000.bin000001.bin000002.bin000003.bin..000134.bin
			mp3_bwv565	016k_11_m	000000.bin000001.bin000002.bin000003.bin..000134.bin
mp3_bwv565	018k_11_s	000000.bin000001.bin000002.bin000003.bin..000134.bin

Mp3_bwv565	024k_11_s	000000.bin000001.bin000002.bin000003.bin..000134.bin
			Mp3_bwv565	032k_11_s	000000.bin000001.bin000002.bin000003.bin..000134.bin

注意，如上所述，由于子文件的长度对应于固定的时间长度，所以各个目录的子文件数目相同。子目录名称包括以KB/s为单位的数据率(三位数字)，加上字母“k”；在本例中，附加了音频采样率(11.025kHz)和单/双声道标记，用于验证。

索引文件包括下面格式的语句：

<！--Audio＝“024k_11_s 032k_11_s 018k_11_s 016k_11_m008k_11_m”-->

(在html文件中(或者可以使用简单的文本文件)，<！--…-->指的是语句作为注释而嵌入)。在图3中显示了典型的索引文件，其中包含了其它的信息：LFI是最大子文件数目(即，有45个子文件)，而SL是总播放时间(178秒)。“Mode(模式)”指的是“recorded(录制)”(如此处所示)或者“live(现场)”(将在下面进行描述)。其它的条目或者是不需加以说明的，或者是标准的html命令。

开始，播放器程序从链接文件所指定的目录中请求索引文件，并且将可用数据率的列表进行本地存储，以备将来之用。(其可以清楚地请求此文件，或者仅仅指定目录：如果没有指定文件名，则大多数服务器缺省指向index.htm)。然后，其按照前面所述的方式，从索引文件中第一个提到的“数据率”目录-即024k_11_s中，开始请求音频子文件(或者通过将其修改为该终端指定的缺省数据率，该终端能够越过此步骤)。从此开始，播放器程序对从服务器获得的实际数据率进行测量，对一段时间进行平均(例如，30秒)。其通过对每一个URL请求进行计时而实现这一功能；确定客户端和服务器之间所达到的传输率(每秒钟的比特数目)。随着请求数目的增加，此数字的精确度也得到提高。播放器保持两个所存储的参数，其分别指示当前数据率和测量的数据率。

下列情况会引发数据率的改变：

a)如果缓存器为空并且测量数据率小于当前数据率，并且测量的缓存器低百分比大于下调阈值(如下所述)，则降低当前数据率；(在缓存器已经为空时，进行改变是有利的，因为声卡没有播放任何声音，并且如果改变了音频采样率、双/单声道或者比特宽度(每个采样中的比特数目)，则有必要进行重新配置)。

b)如果测量的数据率不仅大于当前数据率，而且在给定的时间段中(例如，120秒：如果需要，这可以由用户进行调整)，也大于后面的较高的数据率，则提高当前数据率。

缓存器低百分比指的是缓存器容量所占时间小于播放时间的25％(即，缓存器接近于空)的时间百分比。如果将下调阈值设定为0％，则当缓存器为空时，当满足其它条件的时候，系统总是下调。将下调阈值设定为5％(这是我们优选的缺省值)，表示如果缓存器为空，而所测量的缓存器低百分比大于5％时，不进行下调。进一步的缓存器空显然将导致提高所测量的数据率，并且如果不能保持该数据率，则最终缓存器会再次为空，同时缓存器低百分比大于5％。将该值设定为100％表示客户端将永不下调。

实际的数据率改变仅受到由播放器程序改变子文件地址的相关部分的影响，例如，将“008k”改变为“024k”，以将数据率从8增加到24kbit/s，并且改变当前的数据率参数以进行匹配。结果，下一个对服务器的请求就变为请求更高的(或者更低的)数据率，并且从新的目录中读取子文件，进行解码，并且输入到缓存器。在下面的流程图中总结了上述的过程：

用户	终端	服务器
			选择菜单页面
	请求http:\serverl.com/menu.htm
					发送

		http:\serverl.com/menu.htm
				显示menu.htm
从菜单中选择项目(巴赫)
				从menu.htm中提取超级链接URL(mp3_bwv565/link.htm)
	请求http:\serverl.com/mp3_bwv565/link.htm
					发送http:\serverl.com/mp3_bwv565/link.htm
	显示link.htm
				使用在link.htm(http:\serverl.com/mp3_bwv565)中所指定的参数，运行在link.htm中所指定的次级进程(播放器程序)
	将Stem设定为所指定的
				设定URL＝Stem+“index.htm”
	请求此URL
					发送所请求的文件
	将数据率列表设定为index.htm中所指定的数据率；将LFI设定为在index.htm中所指定的值
				设定Stem＝Stem+“/”+RateList(iteml)设定CurrentRate(当前数据率)＝数据率列表中所指定的值(item 1)设定RateU＝列表中下一个更高的数据率，如果没有，则设定为0；设定StemU＝Stem+“/”+在数据率列表中对应于此数据率的项目；设定RateD＝列表中下一个更低的数据率，如果没有，则设定为0；设定StemD＝Stem+“/”+在数据率列表中对应于此数据率的项目
	设定Current Subfile(当前子文件)＝000000.bin
				J1：设定URL＝StemC+Current Subfile
	请求此URL
					如果所请求的子文件存在，则发送所

		请求的子文件；否则发送错误消息。
				如果接收到错误消息则结束
	对所接收的子文件进行解码
				写入缓存器
	J1A：如果Buffer Fullness(缓存器容量)＞Tp秒，则跳转到J3
				J2：递增Current Subfile
	跳转到J1
				J3：通过声卡，开始/继续播放缓存器的内容
	J4：如果Buffer Fullness＜Tp，跳转到J3
				如果BufferFullness＝0，并且Mrate＜CurrentRate，并且BufferLow％(缓存器低百分比)＞Td，跳转到Stepdown
	如果Mrate＞NextRate(下一个数据率)，并且NextRate＜＞0，则跳转到Stepup
			用户命令输入	如果UserCommand(用户命令)＝Pause(暂停)，那么：停止从缓存器进行读取；循环，直到UserCommand＝Resume(重新开始)；跳转到J3
	如果UserCommand＝Jump(j％)(跳转)，则：清除缓存器；设定CurrentSubfile＝Integer[(LFI+1)*j/100]；跳转到步骤J1
				跳转到步骤J1A
	Stepup：清除缓存器；设定RateD＝RateC；设定StemD＝StemC；设定RateC＝RateU；设定StemC＝StemU设定RateU＝列表中下一个更高的数据率，如果没有，则设定为0；设定StemU＝Stem+“/”+在数据率列表值对应于此数据率的项目；跳转到步骤J1A
				Stepdown：清除缓存器；设定RateU＝RateC；设定StemU＝StemC；

设定RateC＝RateD；设定StemC＝StemD设定RateD＝列表中下一个更低的数据率，如果没有，则设定为0；设定StemD＝Stem+“/”+在数据率列表值对应于此数据率的项目；跳转到步骤J1A

用户控制由用户通过在屏幕上所提供的下列选项而实现，用户可以通过键盘或者诸如鼠标的其它输入设备进行选择：

a)开始：从步骤4开始，执行上述指定数目的步骤。开始选择了一个记录时，是自动播放，还是需要用户的“开始”指令，这是可选的；实际上，如果需要，可以通过链接文件中附加的“自动播放”参数的方式作出选择。

b)暂停：由对MP3解码器的指令实现，用于暂停从缓存器读取数据；

c)恢复：由对MP3解码器的指令实现，用于恢复从缓存器读取数据；

d)跳转：由用户实现，指出他希望跳转到记录的哪一部分，例如，通过将光标移动到代表记录总持续时间的显示条上的预定点；然后，播放器确定该点为显示条方向上的x％，并且计算所需的下一个子文件的数目，将其用于下一个请求。在具有125个子文件的巴赫实例中，请求播放记录的20％点，导致请求第26个子文件——即000025.bin。很明显，如果各个子文件均对应于同样的固定持续时间，则此计算就相当简单。我们希望，对于跳转的情况，要暂停解码，并且清空缓存器，从而能够立即发送新的请求，但是这并不是很必要的。

下面对将原始文件分割为子文件的处理作进一步的讨论。首先，应该说明的是，如果子文件之后跟着的子文件不会超出原始顺序(如上所述)，则子文件之间的边界位置并不重要。在此情况下，子文件的大小可以是固定的比特数目，或者是固定的播放时间长度(或者二者皆非)，真正的决定仅仅是子文件的大小。当需要考虑跳转时(在时间上，或者在不同的数据率之间)，则有其它的考虑。其中，如同很多类型的语音或者音频编码(包括MP3)一样，按照帧对信号进行编码，子文件应当包含完整数目的帧。对于数据率切换的情况，如果确实不必要，很希望对于各个数据率子文件的边界是相同的，从而所接收到的用于新数据率的第一个子文件，在记录中，是从旧的数据率结束处的最后一个子文件处继续的。为了使得各个子文件播放相同的固定时间间隔(例如，上面提到的4秒)，这并不是实现此目的的唯一方法，但是其的确是最方便的。需要说明的是，根据所使用的编码系统，子文件应当包含完整数目的帧意味着子文件的播放时间会稍有不同。说明，在本发明的实施例中，尽管可用的数据率使用不同的量化级别，并且根据是否以单声道或者双声道进行编码而有所不同，但是所有的数据率均使用相同的音频采样率，从而具有相同的帧规格。下面对使用不同的帧规格时需要说明的问题进行描述。

对于实际的子文件长度，最好应当避免过短的子文件，原因是(a)它们导致更多的请求，从而产生额外的网络业务量；(b)在某些类型的分组网络中(包括IP网络)，由于它们需要由更小的分组来进行传输，从而使得请求处理所占用的系统开销和分组报头相应较大，从而导致浪费。另一方面，在开始播放和/或调用跳转或数据率改变时，过大的子文件需要较大的缓存器，产生额外的延迟，所以也是不利的。介于播放时间的30％到130％之间的子文件大小，或者优选的为播放时间的一半的子文件大小是令人满意的。

根据所讨论的标准，使用计算机编程的方式，能够实现转换子文件的实际处理。或许在单独的计算机上进行这个操作是比较方便的，从该计算机上可以将子文件上载到服务器。

另外一个能够添加的改进是使用更加复杂的子文件命名规则，使未授权人员更难于对子文件进行拷贝并在另一台服务器上提供这些子文件，从而提高安全性。一个例子是通过使用伪随机序码发生器，例如，生成下列形式的文件名称：

01302546134643677534543134.bin

94543452345434533452134565.bin

…

在此情况下，播放器程序将包含相同的伪随机序码发生器。服务器发送第一个文件名，或者可能为4位的“种子”，而播放器中的发生器能够使其同步，并且以正确的序列生成所需要的子文件名。

在数据率切换的上述例子中，所使用的索引数据率具有相同的帧规格，具体而言，他们使用11.025KHz下采样的PCM音频的MP3编码以及1152个采样的(PCM)帧规格。如果要在具有不同帧规格的MP3(或者其它)记录之间实现数据率切换，由于要求子文件应该包含完整数目的帧，从而会引发问题，原因是此时的帧边界不一致。通过下面改进的创建子文件的处理，能够解决此问题。尤其应当说明的是，此处理能够用于需要数据率切换的任何情况，并且不限于上述讨论的特定的传输方法。

图4示意地显示了音频采样序列，基于此，通过边界标记(在图中)B1、B2等，对连续的4秒段进行划分。在11.025KHz的采样率下，在各个段中有44,100个采样。

1.对音频进行编码，在边界B1处开始，逐帧进行，以创建MP3子文件，连续进行，直到对具有至少4秒的总持续时间的完整数目的帧编码完毕。使用1152个采样的帧规格，4秒对应于38.3个帧，所以实际上对代表39个帧的子文件S1进行编码，代表总的持续时间为4.075秒。

2、从边界B2开始，以相同的方式，对音频进行编码。

3、每次从4秒边界开始重复上述操作，从而，以此方式，为所要编码的整个音频序列生成一组重叠的子文件。最后的段(其将短于4秒)之后当然不跟随任何东西，所以填入零(即静音)。

以相同的方式，对使用不同帧规格的其它数据率进行编码处理。

在终端，控制机理不变，但是对解码和缓存处理进行修改：

1、接收子文件S1；

2、对子文件S1进行解码；

3、仅将解码音频采样的第一个四秒写入缓存器(丢弃其它的)；

4、接收子文件S1；

5、对子文件S1进行解码；

6、仅将解码音频采样的第一个四秒写入缓存器；

7、继续对子文件S3等进行处理。

以此方式，确保所有数据率的子文件集的子文件边界对应于原始PCM采样序列的相同点。

因此，在进行编码之前，除了最后一个4秒之外，利用后续4秒的音频采样对每个4秒进行填充，从而使子文件大小变成完整数目的MP3帧。如果需要，所填充的采样可以从前一个4秒的末端取，而不是(或者同时)从下一个4秒的开始取。

注意，MP3标准允许将某些信息从一个音频帧转移到另外一个音频帧(通过众所周知的“比特蓄积(bit reservoir)”方案)。在此，即使在子文件内部可以接受该方法，而在子文件之间就不可接受了。然而，由于该标准本质上不允许在记录末尾或者开始进行这样的转移，所以通过分别对各个子文件进行单独编码，就好像其是单个的记录一样，可以很容易地解决此问题。

对于音频接口36的操作而言，采样率的改变(以及在单声道和双声道之间的切换)具有一些实际的意义。尽管很多通常的声卡能够在不同的设定范围内进行操作，但是需要重新设定，以改变采样率，从而这必然会引起音频输出的中断。因此，在进一步的改进中，我们认为声卡能够在所期望的最高采样率下连续工作。当播放器程序在较低的采样率下为缓存器提供数据时，在缓存器之前或者之后，将此数据上采样为此最高数据率。类似的，如果通常以双声道模式对声卡进行操作，则并行地输入解码单声道信号，以为声卡输入端的左、右信道同时提供信号。还有，如果解码信号的每个采样中的比特数目低于声卡所期望的，则通过插入零而增加比特的数目。

前面早时所讨论的用于将数据率自动向下转换的标准，仅在缓存器下溢的时候才引起数据率的降低(从而引起输出中断)，我们注意到，在这个改进中能够避免此类中断，最好有一种标准，能够预测下溢并在大多数情况下避免下溢。在此情况下，将忽略上面提到的三个“与”条件中的第一个(即，缓存器为空)。

可以将相同的原则应用于视频记录的传输，或者，具有伴随声道的视频记录。在较为简单的情况下，当只有一个记录时，该系统与音频情况有所不同，仅仅在于该文件为视频文件(例如，H.261或者MPEG格式)，并且播放器程序包含视频解码器。将文件分割为子文件的方式没有改变。

对于音频的情况，与不同的数据率相对应，有两个或者更多的记录，由上述的控制机制进行选择。同样，可以提供另外的记录，对应于诸如快进和快退之类的不同重放模式，该模式可以由上述的用户控制程序的扩展进行选择。同时，可以遵循文件和目录命名的系统惯例，例如，使得播放器程序能够通过修改子文件地址而对快进命令作出反应。

然而，如果允许切换或者跳转，那么对于文件分割而言，视频记录的传输具有更多的含义。对于对图像的各个帧单独进行编码的记录情况，子文件包含完整数目的图像帧就足够了。但是，如果使用了涉及帧间技术的压缩方法，情况就更加复杂了。一些此类系统(例如，MPEG标准)生成独立编码帧(“内帧”)和预测编码帧的混合帧；在此情况下，各个子文件应当优选的以内帧开始。

对于诸如ITU H.261标准的帧间编码系统(其不包含频繁的、规律的内帧)，这是不可能的。这是因为，以数据率切换为例，如果某人要请求较高比特率记录的子文件n，其后紧跟较低比特率记录的子文件n+1，则较低比特率子文件的第一个帧会在帧间的基础上，利用较低数据率记录的子文件n的最后一个解码帧进行编码，但终端当然不会有这个解码帧，其具有较高数据率记录的子文件n的最后一个解码帧。从而，会产生解码器的严重错误跟踪。

对于在正常播放和快放模式之间进行转换的情况，事实上情况有所不同。例如，在以正常速度的5倍进行快放时，每隔5帧进行解码。从而，大大降低了帧间的相关性，而帧间编码就毫无吸引力了，所以通常把快放序列编码为内帧。所以，从正常播放到快放进行转换没有问题，原因是可以很容易地对内帧进行解码。但是，当转换到正常播放时，会再次出现错误跟踪问题，原因是此时终端以预测编码帧进行工作，而其不具有先前帧。

在任一情况下，通过利用在我们的国际专利申请WO98/26604(在美国授权为6,002,440)中记载的原理，能够解决这个问题。这包括对帧的中间序列进行编码，该中间序列在前一序列的最后一帧和新序列的第一帧之间起到了联系作用。

现在，在快进操作(快退操作与此类似，但是恰恰相反)的目录中，对本操作进行描述。在本实例中，假设根据H.261标准，以96kbit/s，对9分钟的视频序列进行编码，同时，以H.261内帧，以正常数据率的5倍进行编码，从而，将文件分为了4秒的子文件。此处，4秒指的是初始视频信号的播放时间，而不是快进播放时间。使用与上面所使用的命名规则类似的命名规则，这些子文件为：

目录	子目录	文件名
			mpg_name	096k_x1	000000.bin
		000001.bin
					…
		000134.bin
				096k_x5	000000.bin
		…
					000134.bin

其中，“name(名称)”指的是用于识别特定记录的名称，“x1”指的是正常数据率，而“x5”指的是正常数据率的5倍，即快进。

对于播放器程序，为了从正常播放转换到快进，所必需的仅仅是将子文件地址修改为指向快进序列，例如：

Request mpg_name/096k_x1/000055.bin

后面跟着

Request mpg_name/096k_x1/000056.bin

为了构建用于转换回正常播放的连接序列，有必要为每一个可能的转换构建一个连接子文件。如同在上面提到的，在我们的国际专利申请中，对于连接而言，三个或者四个帧的序列通常就足够了，所以简单的实现方法就是，构建仅有4帧时间长度的连接子文件，例如

目录	子目录	文件名
			mpg_name	096K_5＞1	000001.bin
		…
					000133.bin

从而，通过一系列的请求而实现切换，例如

Request mpg_name/096k_x5/000099.bin

Request mpg_name/096k_5＞1/000099.bin

Request mpg_name/096k_x1/000100.bin

按照如下方式生成连接子文件：

●对快进序列进行解码，以获得子文件99的最后一帧的解码版本，(每秒25帧，这将成为原始视频信号的第100,000帧)。

●对正常序列进行解码，以获得子文件100的第一帧(即，第100,001帧)的解码版本。基于所解码的帧100,000，利用H.261帧间编码将这一帧重新编码4次，作为初始的参考帧。

●因此，当解码器已经对快进子文件进行解码时，后面紧跟连接子文件，其将正确地重新构建帧100,000，并且能够对正常(x1)帧进行解码。顺便提及，将同一帧进行数次编码是因为如果仅作一次，那么会由于H.261的量化特性而导致生成很差的图像质量。

可以将同样的处理用于数据率切换(虽然现在在两个方向上均需要连接子文件)。然而，注意到，如上所述，连接子文件将导致四帧时间的图像冻结，即(以每秒25帧)160ms。在从快进转换到正常播放时，这是可以接受的，事实上，此时可能正要选择清空缓存器。对于数据率切换，这可能会，也可能不会被主动的接受。因此也可以构建4秒的连接序列。此时请求序列如下：

mpg_name/096k_x1/000099.bin

mpg_name/096/128_x1/000100.bin

mpg_name/128k_x1/000101.bin

在该情况下，可以通过以解码的96KB/s帧100,000作为参考帧，对解码的128KB/s序列的第五个解码帧进行四次重新编码，而构建连接子文件；或者以解码的96KB/s帧100,000作为参考帧，对解码的128KB/s序列的前4帧进行编码，而构建连接子文件。在两种情况下，连接子文件的其余96帧将是128KB/s子文件的拷贝。

所要传输的文件称为“记录”。然而，在开始传输之前，对所有的音频或者视频序列进行编码，或者所有的音频或者视频序列均已存在是不必要的。因此，需要计算机，用于接收有效输入，使用选定的编码方法对其进行编码，并且不停地生成子文件，将其上载到服务器，从而，当在服务器上有子文件时，就可以开始传输。

本传输系统的一个应用是语音消息系统，如图5所示，其中再次显示了服务器1，网络2，和终端3。语音消息接口4用于接收电话呼叫，例如，通过公共交换电话网络(PSTN)5，以对消息进行记录、编码，并且将其分割为子文件，并且将子文件上载到服务器1，在此，能够通过上述的方式对其进行访问。可以选择的是，可以使用第二接口6，其以与终端3类似的方式进行操作，但是由远程电话5通过PSTN进行远程控制，然后，将要播放的音频信号发送给该接口。

可以将同样的系统用于实时音频(或者视频)输入。在某种程度上，这也是一种“记录”，差别主要是在结束记录之前，就开始了传输和播放，尽管实际上，由于在对至少一个子文件进行记录并且上载到服务器1之前，必须进行等待，从而造成了固有延迟。

该系统能够以上述方式进行工作，除了不能满足用户所希望的从现在开始进行播放，即从最新创建的子文件开始播放，而是从开始处进行播放之外，还是很令人满意的。

对于长的音频序列，可以选择删除旧的子文件，以节省存储空间：对于连续的输入(即，每天24小时)，这将是不可避免的，不仅如此，还需要对子文件名进行重新使用(在我们的原型系统中，使用000000.bin到009768.bin，然后重新从000000.bin开始)，从而使用新的子文件连续地覆盖旧的子文件。确保从最新的子文件进行传输的一个简单方法是，在索引文件中包含附加命令，用于引导播放器程序通过请求合适的子文件而开始播放。然而，这也有缺点，即必须对索引文件进行频繁的修改，理论上，每生成一个新的子文件，就修改一次。因此，我们提出了一种方法，其中，播放器程序按照下面的方式对服务器进行扫描，以寻找开始的子文件。在索引文件中，将“Mode(模式)”参数设定为“live(实时)”，以触发播放器程序调用此方法。对LFI进行设定，以指示所可以存储的子文件的最大数目，即9678。该方法包括下面的步骤，并假定(约定的)已经确定了各个子文件的“最后修改的”时间和日期。当使用HTTP协议时，可以通过使用HEAD请求实现此目的，其不会导致对所请求的子文件进行传输，而是仅仅对用于指示将子文件写入服务器的时间的HEAD(报头)信息进行传输，如果不存在，则为零。将此时间表示为GetURL(LiveIndex)，其中LiveIndex是所述的子文件的序号。在“//”之后是注释。

　　1   LFI＝9768//从index.htm文件中读取

　　    LiveIndex＝LFI/2

　　    StepSize＝LFI/2

　　    LiveIndexModifiedAt＝0；//开始时间

　　10  ThisIndexWasModifiedAt＝GetURL(LiveIndex)；

　　20  If(StepSize＝1)[was If(StepSize＝＝1)]

　　    {

　　    ∥LiveIndexModifiedAt包含文件写入时间，如果没有文件，

　　    则为零。LiveIndex包含索引。

　　    goto 30[was FINISH]

　　    }

　　    StepSize＝StepSize/2

　　    If(ThisIndexWasModifiedAt＞LiveIndexModifiedAt)

　　    {

　　    LiveIndexModifiedAt＝ThisIndexesModifiedAt；

　　    LiveIndex＝LiveIndex+StepSize

　　    }
				
				<dp n="d20"/>
　　else

　　  {

　　LiveIndex＝LiveIndex-StepSize

　　}

　　Goto 10

　　30    FINISH

在找到LiveIndex之后，就要跳返Tp(播放时间)，开始作出请求，以从该处填充音频缓存器。以正常方式开始进行播放。

一旦结束记录，如果需要，对索引文件进行修改，以将“Mode(模式)”设定为“recorded(记录)”，以及任意的长度参数。

如果需要，播放器程序能够周期性地进行检查，以查看索引文件是否从“live(实时)”改变为“recorded(记录)”，如果经过改变，则转换到“recorded(记录)”播放模式。

现在，对一种更为简单和快速的对“最新的”子文件进行识别的方法进行描述，首先假设单一连续的子文件编号序列。

1.终端对第一个子文件(例如000000.bin)发出HEAD(报头)请求；

2.服务器通过发送该文件的报头而作出应答，并且包含该文件最后修改的日期和时间(MODTIME)，以及发送应答的日期和时间(REPLYTIME)(这两者均为标准的http字段)。

3.终端通过对两个时间进行相减(ELTIME＝REPLYTIME-MODTIME)，而对经过时间(ELTIME)进行计算，并且根据子文件的播放时间(在这些实例中，为4秒)，对其进行分割，以得到LIVEINDEX＝ELTIME/4。

4.终端计算具有此索引的子文件的文件名。

5.终端发送具有此文件名的HEAD(报头)请求，如果需要，则接着请求各个文件名，直到其接收到零(未找到文件)，基于此，则认为已经找到了最新的子文件，即“当前子文件”。

6.终端开始从点J1(在前面的流程图中所给出的)开始，开始请求文件。

本方法比上述用于循环计数的子文件的方法要快。注意，只要保存了开始的子文件，则可以删除旧的子文件，以降低存储要求。然而，能够对本方法进行修改，以适应重新使用的文件名(循环地址)，但是需要：

(i)不重新使用开始的子文件名(例如，000000.bin)，从而，总能够在步骤2提供报头信息。因此，对于子文件009768.bin的情况，子文件009768.bin后面跟的是子文件000001.bin。

(ii)在步骤3所计算的LIVEINDEX采用模9768(即ELTIME/4的值除以9768的余数)。

(iii)删除子文件后总会生成新的子文件，从而，在最新的子文件和最早删除的子文件之间不存在新的子文件名，从而在步骤5会发生所期望的“未找到文件”应答。

当以比记录操作稍快或者慢的速度对播放进行操作时，可能会有危险。为了防止前面所说的危险，可以安排播放器程序对其所接收的各个子文件进行检查，以确认其是否具有比其前一个子文件更新的时间，如果不是，则丢弃该子文件，并且重复进行请求(或许3次)。如果这些请求不成功，则检查索引文件。

如果播放滞后于记录，这可以通过播放器对服务器进行随机的检查，以确认存在大量的比当前所请求的子文件更新的子文件而进行识别，而如果存在这样的子文件，则启动“紧追”处理，即有规律地丢弃少量的数据。

Claims (5)

1.一种对音频信号进行编码的方法，包括：

在概念上将输入信号划分为连续的时间部分；

使用具有第一帧长度的第一编码算法，对所述的输入时间部分进行编码，以生成编码时间部分的第一编码序列；

使用第二帧长度，对所述的输入时间部分进行编码，以生成编码时间部分的第二编码序列；

其中至少一个编码步骤包括将一个输入时间部分与前一个时间部分的末尾部分和/或后一个时间部分的起始部分一起进行编码，该末尾部分和/或起始部分与所述的一个时间部分一起构成整数个帧。

2.根据权利要求1的方法，其特征在于，第一和第二编码算法对应于不同的输出数据率。

3.根据权利要求1或者2的方法，包括将一个编码时间部分的序列提供给输出端，并且响应于切换命令，进行切换使得向输出端提供另外一个编码时间部分的序列，该切换发生在一个编码时间部分及其下一个之间的交界处。

4.一种传输音频信号的方法，包括：

使用根据权利要求1、2或者3的方法，对信号进行编码；

对离散的部分进行解码；以及

抛弃对应于所述末尾部分和/或起始部分的解码信号部分。

5.一种对输入音频信号进行编码的方法，包括：使用具有第一帧长度的第一编码算法，对输入信号的各个连续的第一时间部分进行编码，以生成第一编码序列，该第一时间部分对应于所述第一帧长度的整数数目，是邻接的或者交叠的；使用具有第二帧长度的第二编码算法，对输入信号的各个连续的第二时间部分进行编码，以生成第二编码序列，使得第二编码序列的各个交叠区域至少部分地围绕对应于输入信号连续时间部分的第一编码序列之间的边界或者重叠区域部分，该第二时间部分对应于所述第二帧长度的整数数目，但不对应于所述第一帧长度的整数数目，并且是交叠的。

Images