音乐数据压缩方法和执行它的程序的制作方法

专利名称：音乐数据压缩方法和执行它的程序的制作方法
技术领域：
本发明涉及一种压缩演奏事件信息格式的音乐数据压缩方法，演奏事件信息由诸如音调音高信息、发声定时、发声持续时间和相应于一部分的声道数形成，本发明尤其涉及一种音乐数据压缩方法，例如适于分配音乐数据，诸如蜂窝电话的来电曲调。
然而，随着这种乐曲的再现时间和/或部分数量的增加，数据大小也增大，这导致通信时间和下载来电曲调等的音乐数据所需的成本增加。而且，终端装置需要大的存储容量用来在装置中存储音乐数据。为了克服这些问题，要求压缩音乐数据。
日本专利特许公开(Kokai)No.8-22281公开了一种压缩MIDI信号的方法，通过分析作为音乐数据的MIDI信号来检测连续重复出现的音调或模式，删除相应测得的重复出现的音调或模式的部分音乐数据，并在音乐数据中插入代表要连续重复出现的音调或模式的信号，代替删除的部分。日本专利特许公开(Kokai)No.9-153819中公开了另一种方法，它利用数据重排过程，把每个音调的MIDI数据(由音调音高(tone pitch)、持续时间、音调长度、速度和声道数这5个数据元素组成)分解成5个数据元素，然后把这5个数据元素的多条数据均重组为一组数据元素的数据，从而提高下一阶段中可逆(无损)压缩器的压缩比。
然而，根据日本专利特许公开(Kokai)No.8-22281所提出的方法，例如在考虑键开(key-on)事件时，在由代表键开事件的信息和代表声道的信息形成的状态信息、键号信息(7位)、速度信息(7位)和选通时间信息(在某些情况下有持续时间信息)组成的MIDI数据中，在所有各种信息中相同的音调很少连续出现，导致压缩效率低。而且，虽然可预期以高压缩比来压缩包含预定模式或通道的类型的音乐数据，但是，这要求使用复杂的算法来检测长重复的段。
另一方面，日本专利特许公开(Kokai)No.9-153819中提出的技术用于在通信卡拉OK系统中压缩卡拉OK内容。根据该技术，一旦把进行了数据重排过程的卡拉OK内容下载到安装在卡拉OK室或家中的终端装置内，那么，就再把5个数据元素的各个组重排为每个音调的初始MIDI数据，用作卡拉OK数据。因而，该技术不适于流(stream)再现，流再现中执行音乐数据的再现同时经网络从服务器接收数据。而且，日本专利特许公开(Kokai)No.9-153819只公开了重排数据元素而没有提出任何新的压缩方法。
为了实现上述目的，在本发明的第一方面，提供了音乐数据压缩方法，包括步骤接收包含多条演奏事件信息的序列的音乐数据，每个演奏事件信息由音符信息形成；把音乐数据的每条演奏事件信息转换为另一种形式的演奏事件信息，它包含状态信息和音符信息，状态信息相应于一条演奏事件信息和前一条演奏事件信息之间的音符信息中匹配或错配模式，根据相应于状态信息的匹配或错配模式需要所述的音符信息。
根据本发明第一方面的方法，由于音乐数据的每条演奏事件信息转换为另一种形式的演奏事件信息，所以与前一条演奏事件信息相比，其它形式的演奏事件信息只包含错配音符信息而包含匹配音符信息，这就有可能减小音乐数据的数据大小，另一种形式的演奏事件信息包含状态信息和音符信息，状态信息相应于一条演奏事件信息和前一条演奏事件信息之间的音符信息中匹配或错配模式，根据相应于状态信息的匹配或错配模式需要所述的音符信息。在解压压缩后音乐数据时，可以根据其状态信息所示的匹配或错配模式，通过参考前一条演奏事件信息的音符信息，把压缩后演奏事件信息解压为其压缩之前的初始形式。
音符信息最好包含音调音高(tone pitch)信息，转换步骤包含用于预定初始音调音高的差来表示包含在音符信息中的音调音高信息。
根据这种最佳形式，压缩后的音调音高信息(差)是初始音调音高的相关值，因此有可能使音乐数据的数据大小比在整个音符范围用其绝对值表示音调音高时更小。
初始音调音高是包含在音乐数据中的任何一条演奏事件信息的音调音高就更好了。
由于初始音调音高可以就这样设为音乐数据的第一音调的音调音高、音乐数据的规定音调的音调音高或者音乐数据的最高音调和最低音高之间的中间音调音高，所以，有可能使音乐数据的数据大小更小。
在接收步骤中收到的音乐数据包括多个声道的一系列多条演奏事件信息就更好了，转换步骤包含以时序顺序为所有声道配置多条演奏事件信息；和检测以时序顺序为所有声道配置的每条演奏事件信息和前一条演奏事件信息之间的音符信息中的匹配或错配。
用根据第一方面的更佳方法，由于根据对以时序顺序为所有声道配置的每条演奏事件信息和前一条演奏事件信息之间的音符信息中匹配或错配的检测来压缩音乐数据，所以，压缩后音乐数据还包含以时序顺序为所有声道配置的多条演奏事件信息。结果，例如当分配压缩后音乐数据时，有可能从音乐数据再现音乐同时接收音乐数据(即，执行流再现)。
或者，在根据第一方面的方法中，在接收步骤中收到的音乐数据包括用于多个声道的多条演奏事件信息的序列，转换步骤包含在声道-声道基础上以时序顺序排列多条演奏事件信息；和检测在声道-声道基础上以时序顺序排列的每条演奏事件信息和前一条演奏事件信息之间的音符信息中的匹配或错配。
由于就这样根据对基于声道-声道以时序顺序排列的每条演奏事件信息和前一条演奏事件信息之间音符信息中匹配或错配的检测来压缩音乐数据，所以在声道-声道基础上包含在音乐数据中的每条演奏事件信息不必包含声道信息，它能减小音乐数据的数据大小。
把初始音调音高设定用于每个声道就更好，用每个声道的来表示音调音高信息。
根据这种最佳形式，即使在对于所有声道用于单个初始音调音高的差表达音调音高信息的情况下，音乐数据包含一条不能用预定数据长度来表示的音调音高信息，也为每个声道设定初始音调音高，结果，可以用于为相应声道设定的初始音调音高的差表示这种音符信息的可能性增大了，这能进一步减小音乐数据的数据大小。
初始音调音高包括单个音调音高就更好了，用于单个初始音调音高的差来表示用于以时序顺序配置的所有声道的每条演奏事件信息的音调音高信息。
由于初始音调音高包括单个音调音高，所以可简化压缩处理。
每条演奏事件信息的音符信息包含间隔信息以及与这条演奏事件信息有关的演奏事件的发声持续时间信息就更好了，间隔信息代表与前一条演奏事件信息的间隔，转换步骤包含用预定音符长度表示的间隔信息和发声持续时间信息。
由于就这样用于其相应的预定音符长度来表示间隔信息和发声持续时间信息，或使其与预定音符长度近似，所以有可能减小音乐数据的数据大小。
为了实现上述目的，在本发明的第二方面，提供了一种程序，用于使计算机执行音乐数据压缩方法，该程序包括接收模块，用于接收包含多条演奏事件信息的序列的音乐数据，每个演奏事件信息由音符信息形成；和转换模块，用于把音乐数据的每条演奏事件信息转换为另一种形式的演奏事件信息，它包含状态信息和音符信息，状态信息相应于演奏事件信息和前一条演奏事件信息之间的音符信息中匹配或错配模式，根据相应于状态信息的匹配和错配模式需要所述音符信息。
结合附图，从下文的详细描述，本发明的上述和其它目的、特点和优点会更明了。
先看图4，显示应用了根据本发明实施例的音乐数据压缩方法系统基本构成。如图4所示，诸如分配服务器(计算机)的数据产生和分配侧以标准MIDI文件(SMF)格式压缩音乐数据，或者以本实施例所利用的格式(SMAF格式)压缩音乐数据，压缩成本实施例指定格式的压缩后音乐数据。
诸如蜂窝电话的数据接收和再现侧下载在数据产生和分配侧压缩的音乐数据，以便把音乐数据存储在数据接收和再现侧的存储器中。再现音乐数据期间，作为数据接收和再现侧的蜂窝电话等解压存储在存储器中的音乐数据，并执行音序器(sequencer)处理以便把键开数据、音符数数据、键关数据等传送到音调发生器的预定声道，用于使音乐数据发声。在下面的描述中应当注意，数据产生和分配侧称为“分配服务器”，数据接收和再现侧称为“蜂窝电话”，音乐数据称为“来话呼叫曲调数据”。
图5说明了图4系统的构成的实例。图5中，用于分配来话呼叫曲调数据的分配服务器1、通过无线与用户的蜂窝电话2连接的站3以及与网络兼容的个人计算机4与网络10连接，网络10是电话交换网络。
图6是显示设在图5中分配服务器1中的计算机的硬件构成框图。如图6所示，CPU1a在安装在外部存储1b中的OS上工作，用ROM1c和RAM1d执行多种过程。外部存储1b由例如大容量HDD(硬盘驱动器)来实现，并存储诸如SMF格式和SMAF格式的多种音乐数据的多种数据、多种信息(HTML形成的多个WWW页的源)等。而且，通信接口1e与网络10连接，分配服务器1提供服务用来把来话呼叫曲调的音乐数据分配到用户的蜂窝电话2等。在分配音乐数据时，CPU1a执行用于压缩音乐数据的压缩处理、通信处理等，如下文详细描述的那样。分配服务器1还包含显示器1f、键盘1g和鼠标1h，作为操作者的输入/输出装置。
图7是显示图5中蜂窝电话2的硬件构成的框图。如图7所示，CPU2a通过执行存储在ROM2b中的程序来控制蜂窝电话2的整体操作。RAM2c用作CPU2a的工作区域、用于存储分配服务所下载的音乐数据的存储区域以及用于存储用户设定的构成数据的存储区域。通信部件2d解调(demodulate)由天线2e收到的信号，调制(modulate)用于传输的信号，把解调后信号供应到天线2e。语音处理部件2f解码由通信部件2d解调接收语音信号，音乐再现部件2g经接收语音扬声器2i输出解码后接收语音信号作为声音。而且，音乐再现部件2g从来话呼叫曲调的音乐数据再现音乐，然后经来话呼叫扬声器2j输出来话呼叫曲调的音乐。经麦克风2h输入的语音信号由语音处理部件2f来压缩和编码，编码后语音信号由通信部件2d发射。
接口(I/F)2k用于从诸如个人计算机的外部装置或设备下载音乐数据、音色数据等。蜂窝电话2包含输入部件2m，由拨号按钮和多种操作元件组成；显示部件2n，根据用于选择分配服务的操作和拨盘按钮等操作执行预定显示；振动器2p，用于使蜂窝电话的主体振动来代替在收到电话时产生来话呼叫声音。
音乐再现部件2g通过从设在部件2g中的音乐数据缓冲器读取演奏事件数据来再现乐曲。当在再现乐曲期间在音乐数据缓冲器中产生预定大小的空闲或可用区域时，把中断请求信号传送到CPU2a。响应请求信号，CPU2a从存储在RAM2c中的压缩后音乐数据读取仍在音乐数据缓冲器中的音乐数据，把从RAM2c读取的压缩后音乐数据传输到音乐再现部件2g。在供应到音乐再现部件2g之前，音乐数据由CPU2a解压。执行解压的定时取决于下面要用的格式。应当注意，音乐再现部件2g包含音调发生器，音调发生器通过时分复用产生用于多个声道的音乐信号，按照音乐数据中的演奏事件以与自动演奏的音乐再现相同的方式再现来话呼叫曲调。已知根据音乐数据再现自动演奏音乐的技术，因此不再赘述。
图3A和3B显示了要根据本实施例压缩的两种音乐数据格式。图3A和3B均显示了用于相同单个乐曲音乐数据的单个文件。通常，如图所示的音乐数据由用于相应于各个部分的多个声道(在SMF的情况下是16声道)数据。在本实施例中，假设音乐数据由用于4个声道的数据形成，因此有可能产生最大4种音色的音乐。而且，在本实施例中，音乐数据形成为两种声道格式之一，即，单声道程序块格式和多声道程序块格式，它们在声道管理上彼此不同。
在图3A所示的单声道程序块格式中，“数据长度”、“节奏”和“音色”的数据记录为标题，相应于乐曲音调的“演奏事件”数据(演奏事件信息)记录在标题之后。“数据长度”是代表整个数据长度的8位数据，“节奏”是代表音乐再现节奏的4位数据，每个“音色”是代表分别分派给声道ch1到ch4的音色的6位数据。
每个“演奏事件”数据由“声道”、“音符数”、“持续时间”和“选通时间”的数据(音符信息)组成。“声道”数据是代表声道声道数的2位数据，演奏事件属于该声道，“音符数”数据是代表音调音高的6位数据，“持续时间”数据是代表与先前事件的时间间隔2字节数据(即，音符长度)，“选通时间”数据是代表发声持续时间的1到2字节数据。
在如图3B所示的多声道程序块格式中，“数据长度”和“节奏”的数据记录为标题，在标题后在声道-声道(channel-by-channel)基础上记录数据的4个特定声道组(程序块)用于4个声道。声道指定程序块的数量可以是少于4个。数据的每个程序块包含代表程序块的声道数的“声道”数据、代表程序块的整个数据长度的“数据长度”数据以及代表分派给程序块(声道)音色的“音色”数据，它们作为标题来记录，相应于乐曲的各个音调的“演奏事件”数据记录在标题之后。
每个“演奏事件”数据由“音符数”、“持续时间”和“选通时间”数据组成，与图3A的单声道程序块格式类似。然而，在多声道程序块格式的情况下，在程序块-程序块基础上设定声道数，因此每个“演奏事件”数据不包含“声道”数据。每个持续时间数据表示与先前事件的时间间隔，因此，相应于整个乐曲的第一音调(演奏事件)持续时间采取0值。另一方面，不是整个乐曲第一音调的其它声道的第一音调持续时间数据采取非0值。
应当注意，以如下表1所示的单声道程序块格式或多声道程序块格式，每个“音符数”数据由代表八音度的2位“块”数据和代表音高名的4位“音符”数据组成。
表1

具有上述格式结构的音乐数据由分配服务器1用以下方式处理分配服务器1存储多种乐曲的音乐数据作为以单声道程序块格式和多声道程序块格式记录的源。这些音乐数据压缩和转换为单声道程序块格式的压缩数据和多声道程序块格式的压缩数据。在本实施例中，包含在每个演奏事件中的音符数转换为代表在压缩音乐数据之前与初始音符数差的数据。
在下文中，描述根据本实施例的第一音乐数据压缩方法。
首先，检测相同声道的第一演奏事件的音符数并设为初始音符数(初始音调音高)。然后，相同声道的第二和以下演奏事件的各个音符数均转换为代表与初始音符数差(音高差)的差形式。在可以用5位来表示所有演奏事件的音符数之差的声道(下文中也称为“允许的音符范围内的声道”)上执行音符数到各个差形式的转换，但是不在其音符数与初始音符数的差无法用5位来表示的至少一个演奏事件声道上执行该转换。这种情况下，为了区别不执行音符数到各个差形式的转换的声道，只要求使用预定指定种类的数据(除了音符数)，来代替声道的初始音符数。然后，每个演奏事件的“持续时间”和“选通时间”数据都调为表2中与演奏事件最接近的预定音符长度之一，并转换为相应于预定音符长度的3位数据。
表2

上述处理把图3A和图3B中的音乐数据转换为例如图2A和2B所示的各个格式。更具体地说，在图2A所示压缩数据的单声道程序块格式中，把声道(ch1到ch4)各个第一音符的音符数作为“初始音符数”加到标题数据。每个“演奏事件”数据由2位“声道”数据、代表演奏事件的音符数与初始音符数之差的5位“音符消息”数据、“持续时间”的3位数据和“选通时间”的3位数据组成。
另一方面，在图2B所示压缩数据的多声道程序块格式中，在每个声道的程序块中，声道第一音调的音符数作为“初始音符数”加到标题数据上。而且，每个“演奏事件”数据的组成有代表与初始音符数的音符数之差的5位“音符消息”数据，3位“持续时间”的数据，和3位“选通时间”数据。不用说，在相应于第一音调的“演奏事件”数据中，“音符消息”数据记录为“00000b”(意味着差是0)。
虽然在上述处理中每个声道中第一演奏事件的音符数设为初始音符数(初始音调音高)，但是，这不是限制性的，而是可以把每个声道中的任意音符数设为初始音符数。或者，附加输入和设定的音符数可以用作初始音符数。
在下文中，描述本实施例的第二音乐数据压缩方法。
第二音乐数据压缩方法与在声道-声道基础上压缩音乐数据的第一音乐数据压缩方法不同，区别在于对所有声道压缩音乐数据。更具体地说，首先，检查所有声道的演奏事件，检测所有声道第一演奏事件的音符数并设为初始音符数(初始音调音高)。然后，把每个声道演奏事件的音符数都转换为代表与初始音符数差(音高差)的差形式。只在所有声道的所有演奏事件的音符数的差都可以用5位来表示时才执行音符数到各个差形式的转换。然后，与第一方法类似，每个演奏事件的“持续时间”和“选通时间”数据都调为表2中的最接近演奏事件音符长度的一个预定音符长度，并转换为相应于预定音符长度的3位数据。
也是在第二音乐数据压缩方法中，可以把所有声道的任意音符数设为初始音符数(初始音调音高)，或者，可以把任意输入和设定的音符数用作初始音符数。
通过上述处理，在单声道程序块格式中，添加所有声道的“初始音符数”作为标题数据，与图2A的格式类似，每个演奏事件数据的组成有2位“声道”数据，代表与初始音符数的演奏事件音符数之差的5位“音符消息”数据，3位“持续时间”数据，和3位“选通时间”数据。
由于音符数均转换为与上述初始音符数的差，所以，与用整个音符范围的绝对值(音符数)来表达音高的情况相比压缩每个音乐数据。而且，用调为预定音符长度的值表达每个“持续时间”和“选通时间”数据，这就有可能进一步压缩音乐数据。此外，当单声道程序块格式转换为多声道程序块格式时，多声道程序块格式的每个演奏事件的数据不需“声道”数据，这就有可能获得压缩数据。
在本实施例中，执行上述多种压缩过程，而且，有可能通过以下面的方式对演奏事件数据序列执行压缩处理来更显著地压缩音乐数据比较两个相邻演奏事件的数据用来检测以下演奏事件与先前演奏事件的每种数据中的匹配或错配。然后，把相应于测得的匹配/错配的模式的3位“状态”数据加到下面的演奏事件数据，使得只按照匹配/错配模式把所需的数据(错配数据)留在下面的演奏事件数据上，从而压缩该演奏事件数据。
应当注意，在单声道程序块格式中，压缩整个文件中演奏事件数据的序列(即，所有声道演奏事件数据的序列)，而在多声道程序块格式中，在声道-声道(程序块-程序块)基础上压缩每个声道(每个程序块)的演奏事件数据序列。如上所述，对于至少一个音符数与初始音符数的差无法用5位来表达的声道，音符数不转换为差形式，以与其它声道不同的方式对这种类型的声道，尤其是单声道程序块格式的声道执行上述压缩处理。这种情况下，执行相邻演奏事件数据之间的比较，用于检测其音符数(块和音符)之间的匹配或错配。
表3显示了状态、匹配/错配条件、状态之后的数据以及相应于每个状态的演奏事件数据的总位数。应当注意，表3的实例显示了音符数均转换为差形式的情况。
表3

A声道(2位)B音符消息(5位)
C持续时间(3位)D选通时间(3位)例如，当演奏事件在最上一行例举的“音符消息”、“持续时间”和“选通时间”上与先前演奏事件相同时，就只在“状态”数据之后余下“声道”数据以便形成压缩演奏事件。这种情况下，通过向3位“状态”数据添加2位“声道”数据来获得5位的演奏事件总位数。类似地，在第二行和其它行，只在“状态”数据之后余下所需的数据(错配数据)以便形成压缩演奏事件。结果，每个演奏事件压缩为最大16位，最小5位。应当注意，诸如“B，C，D”的用一个或多个逗号相互连接的条件是“AND”条件，在表的条件列中显示。
表4显示了状态、匹配/错配条件、状态之后的数据和演奏事件数据的总位数。表4的实例还显示了把音符数转换为差形式的情况。
表4

B音符消息(5位)C持续时间(3位)D选通时间(3位)表4的每个表元素与表3类似，因此不再赘述。然而，从表4会知道，在多声道程序块格式中，每个演奏事件不包含“声道”数据，这就使演奏事件数据比单声道程序块格式更短。


图1A和图1B均说明了用本实施例执行的演奏事件序列压缩前后的音乐数据实例。在图中，“A”表示“声道”数据，“B”表示“音符消息”数据，“C”表示“持续时间”数据，“D”表示“选通时间”数据，“St”表示“状态”数据。在图1A所示的单声道程序块格式中，“声道”数据、“音符消息”数据、“持续时间”数据以及“选通时间”数据构成了压缩前的一个演奏事件的数据，演奏事件的数据总共13位。如果在图1A的第一演奏事件中，其“状态”数据根据与先前演奏事件的匹配或错配条件(模式)而采取“000”(相应于表3中的最上一行)，演奏事件只由“状态”数据和其余“声道”数据来表示，因此压缩为5位演奏事件。而且，其“状态”数据采取“001”的演奏事件压缩为10位数据，而其“状态”数据采取“010”的演奏事件压缩为9位数据。
另一方面，在图1B所示的多声道程序块格式中，“音符消息”数据、“持续时间”数据和“选通时间”数据构成了压缩前的一个演奏事件的数据，演奏事件总共11位。如果在图1B的第一演奏事件中其“状态”数据根据与先前演奏事件的匹配或错配条件(模式)而采取“000”(相应于表4中的最上一行)，演奏事件就只用“状态”数据来表示，因此，它压缩为3位演奏事件。类似地，其“状态”数据采取“001”的演奏事件压缩为6位数据，而其“状态”数据采取“010”的演奏事件压缩为8位数据。
图8是显示由图5所示分配服务器1执行的音乐数据压缩过程的主要部分流程图。图9是显示用于执行单声道程序块压缩过程的子程序流程图，而图10是显示用于执行多声道程序块压缩过程的子程序流程图。而且，图11是显示音乐数据分配过程的主要部分流程图。应当注意，这些流程图所示的过程利用了第一音乐数据压缩方法。先看图8，当起动音乐数据压缩过程时，在步骤S1中指定预定SMF或SMAF数据，在步骤S2中，对预定数据执行图9所示的单声道程序块压缩过程用来存储压缩数据。然后，在步骤S3，对预定数据执行图10所示的多声道程序块压缩过程，用来存储压缩数据。在下面的步骤S4中，确定是否完成该过程，如果需要的话，重复执行上述步骤以便在外部存储1b中存储压缩后音乐数据。
在图9所示的单声道程序块压缩过程中，在步骤S21确定所要压缩的音乐数据格式。当在步骤S21确定音乐数据是多声道程序块格式时，过程进行到步骤S22，而如果音乐数据是单声道程序块格式，过程就进行到步骤S23。在步骤S22，会聚了所有声道的数据，根据所有声道演奏事件的持续时间数据，所有声道演奏事件以时序顺序排列。然后，把相应初始声道的声道数添加到每个演奏事件，改变演奏事件的持续时间以便与排列所有声道的数据所造成的演奏事件之间的间隔相对应。简言之，在步骤S22中，多声道程序块格式转换为单声道程序块格式。然后，过程进行到步骤S23。
在步骤S23，检测和存储每个声道的初始音符数，在步骤S24，在声道-声道基础上检测每个声道数与相应初始音符数的差是否可以用5位来表达。简言之，检测每个声道是否在允许的音符范围之内。然后，在步骤S25，允许音符范围内的每个声道音符数转换为代表与相应初始音符数的差的数据(音符消息)，并存储它们。然后，在步骤S26，通过比较演奏事件和先前演奏事件，根据表3中的相应条件转换每个演奏事件数据。更具体地说，如果演奏事件包含任何与先前演奏事件匹配的数据，就从当前演奏事件删除该数据，添加相应于通过比较两个演奏事件来满足的条件(匹配/错配模式)的状态，从而形成一个演奏事件。对音乐数据的所有演奏事件执行该处理，当完成所有演奏事件的处理时，过程返回图8所示在主例程(routine)。
在图10所示的多声道程序块压缩过程中，在步骤S31检测所要压缩的音乐数据格式。当在步骤S31确定音乐数据是单声道程序块格式时，过程进行到步骤S32，而如果音乐数据是多声道程序块格式，过程就进行到步骤S33。在步骤S32，根据包含在各个演奏事件中的声道数据，演奏事件分类为多个声道程序块，它们均形成一组相同声道，从而把数据分到用于各个声道的数据的组中。然后，改变每个演奏事件的持续时间，使得它等于与相同声道的先前演奏事件间隔。简言之，在步骤S32，单声道程序块格式转换为多声道程序块格式。然后，过程进行到步骤S33。
在步骤S33，检测和存储每个声道的初始音符数，在步骤S34，检测每个声道是否在允许的音符范围内。然后，在步骤S35，把允许音符范围内的每个声道音符数转换为代表与相应初始音符数差的数据(音符消息)，并存储它们。下面，在步骤S36，通过比较演奏事件和先前的演奏事件，根据表4中的相应条件转换每个声道的每个演奏事件数据。更具体地说，如果演奏事件包含任何与先前演奏事件的匹配数据，就从当前演奏事件删除该数据，添加相应于通过比较两个演奏事件来满足条件的状态，从而形成一个演奏事件。对音乐数据的所有演奏事件执行该处理，当完成所有演奏事件的处理时，过程返回图8所示的主例程。
蜂窝电话2访问分配服务器1例如用来接收分配多种内容的服务时，随时执行图11所示的音乐数据分配过程。首先，在步骤S41确定(监控)用户(蜂窝电话2)是否请求分配来话呼叫曲调。如果已经进行了分配请求，在步骤S42，就把用于显示存储在外部存储1b中压缩后音乐数据的曲名列表Web页文件和所选的输入屏幕发送到蜂窝电话2。结果，在蜂窝电话2的显示器上显示曲名列表和所选输入屏幕，从而使用户能用蜂窝电话2选择性地输入他/她预期的乐曲名称以及所要求的压缩类型，即，单声道程序块压缩和多声道程序块压缩之一。
这种状态下，在步骤S43监控乐曲名和压缩类型的选择性输入，如果进行了选择性输入，就在步骤S44确定所选压缩类型。如果所选压缩类型是多声道程序块压缩，就在步骤S45分配或发送由多声道程序块压缩方法压缩的所选乐曲，之后，过程进行到步骤S47。另一方面，如果所选压缩类型是单声道程序块压缩，就在步骤S46分配或发送由单声道程序块压缩方法压缩的所选乐曲的音乐数据，之后过程进行到步骤S47。然后，在步骤S47执行包含记账过程的其它处理，之后终止分配过程。
虽然在图9所示的单声道程序块压缩过程中以与第一音乐数据压缩方法一致的方式把初始音符数用于各个声道，但是，这不是限制性的，而是可以把诸如从所有声道任意选择的音符数的单个音符数、预定音符数、外设音符数或者所有声道最高音调音高同最低音调音高之间的平均音符数设为所有声道的公用初始音符数(初始音调音高)。而且，虽然在图10的多声道程序块压缩过程中，初始音符数用在各个声道中，但是，这不是限制性的，而是，可以把任何一个初始音符数用作上述初始音符数。
当如上所述把压缩后音乐数据分配到蜂窝电话2时，音乐数据存储在蜂窝电话2的RAM2c中。在蜂窝电话2中，当执行用于确认来话呼叫曲调的操作或在常规模式中出现来话呼叫时，从音乐数据再现乐曲。为了再现乐曲同时从RAM2c读取音乐数据的演奏事件，CPU2a执行以下处理当从用单声道程序块压缩方法压缩的音乐数据再现音乐时，读取各个声道ch1到ch4的“音色”数据并设到音乐再现部件2g的音调发生器，然后读取各个声道的“初始音符数”。然后，读取由“声道”、“音符消息/音符数”、“持续时间”和“选通时间”形成的第一演奏事件。然后，把第一演奏事件数据的“音符消息”加到相应于包含在第一演奏事件中的“声道”数据的声道“初始音符数”，把该加法获得的数据作为“音符数”数据与“声道”、“持续时间”和“选通时间”数据一起传送到音乐再现部件2g。应当注意，如果用于演奏事件的声道不在允许音符范围之内，就这样把演奏事件数据传送到音乐再现部件2g。
第一演奏事件之后的演奏事件位长不同，因此，读取每个演奏事件的状态数据用来区别或确定形成演奏事件的数据。然后，把压缩处理所删除的每个数据恢复(解压)为包含在先前演奏事件中的相应数据相同数据。而且，把“音符消息”加到“初始音符数”，而后把“声道”、“音符数”、“持续时间”和“选通时间”数据传送到音乐再现部件2g。对演奏事件重复执行该处理，同时顺序读取其数据直到把预定量的数据写入音乐再现部件2g的数据缓冲器中。
当从用多声道程序块压缩方法压缩的音乐数据再现音乐时，设定相应于各个声道ch1到ch4的4个指示器，而后在声道-声道基础上读取“音色”数据并把它设定到音乐再现部件2g的音调发生器，然后读取用于各个声道的“初始音符数”。下面，更新声道的各个指示器，以便在声道-声道基础上读取演奏事件。与用于单声道程序块压缩方法压缩的音乐数据的上述处理，即包含根据状态恢复每个演奏事的恢复(解压)处理类似，执行“音符消息”和“初始音符数”的相加，而后把“声道”、“音符数”、“持续时间”和“选通时间”的数据传送到音乐再现部件2g。
由于如上所述以压缩状态分配音乐数据，所以有可能减少下载音乐数据所需的通信时间和通信成本。而且，如上所述，在再现时解压音乐数据，因此，蜂窝电话2的RAM2c可以构成为有用于存储音乐数据的小容量。或者，可以在存储在RAM2c中之前把压缩后音乐数据解压(为其初始大小)。这种情况下，要求RAM2c有某种较大容量，但是，还是有可能减少下载音乐数据所要求的通信时间和通信成本。由于用存储在ROM2b中的程序来执行解压和再现处理，所以，程序可以配置成使用户可以选择在再现之前解压音乐数据或者在再现期间顺序解压音乐数据。
而且，可以在下载音乐数据时再现音乐数据的音乐。这种情况下，如果用单声道程序块压缩方法压缩音乐数据，就可以几乎在收到第一演奏事件同时起动解压/再现，这样，适于流再现。应当注意，只可以在开始接收最后声道的演奏事件之后再现多声道程序块压缩方法压缩的音乐数据。
在上述实施例中，由于用于初始音符数的差表达音调音高，所以有可能减小数据的大小。然而，如同与初始音符数之差无法用5位来表达的情况下那样，可以用还没处理的音符数来执行演奏事件序列的数据压缩。而且，音符数的构成和声道数量不限于实例方式的上述实施例，而是可以自由设定。
虽然在上述实施例中，用于解压处理的程序存储在蜂窝电话2的ROM2b中，但这不是限制性的，程序可以从分配服务器1分配到蜂窝电话2。
虽然在上述实施例中，来话呼叫曲调的音乐数据分配到蜂窝电话2，但是，本发明可以用于把音乐数据分配到与网络兼容的个人计算机4情况，如图5所示。这种情况下，音乐数据可以用于例如个人计算机4或电子乐器5的自动演奏。而且，本发明也可以用于把卡拉OK音乐数据分配到卡拉OK设备或者把游戏软件中所使用的音乐数据分配到游戏机。
虽然在上述实施例中利用SMAF格式，但是，本发明可用于包含由音符信息形成的演奏事件序列的任何音乐数据。因而，不用说，本发明可以应用于普通SMF格式的音乐数据。
本发明可以应用于由多个设备组成的系统或单个设备。要知道，也可以通过向系统和设备供应存储媒体来实现本发明的目的，存储媒体中存储有实现了上述实施例的功能的软件的程序代码，使系统或设备的计算机(或CPU或MPU)读取和执行存储在存储媒体中的程序代码。
这种情况下，从存储媒体读取的程序代码本身实现了上述实施例的功能，因此，存储有程序代码的存储媒体构成了本发明。用于向系统或设备供应程序代码的存储媒体可以是例如软盘、硬盘、光盘、磁光盘、CD-ROM、CD-R、CD-RW、DVD-ROM、DVD-RAM、DVD-RW、DVD+RW、磁带、非易失性存储卡或ROM的形式。也可以利用经网络下载。
而且，要知道，不仅可以通过执行计算机所执行的程序代码来实现上述实施例的功能，而且可以通过在计算机上操作的OS(操作系统)等根据程序代码的指令执行部分或全部实际操作来实现这些功能。
而且，要知道，可以通过把从存储媒体读取的程序代码写入插在计算机中的解压板或设在与计算机连接的解压单元中的存储器，然后使设在解压板中的CPU等根据程序代码的指令执行部分或全部实际操作，以此来实现上述实施例的功能。
权利要求
1.一种音乐数据压缩方法，包括步骤接收音乐数据，音乐数据包含多条演奏事件信息的序列，每个演奏事件信息由音符信息形成；和把音乐数据的每条演奏事件信息转换为另一种形式的演奏事件信息，该演奏事件信息包含状态信息和音符信息，状态信息相应于一条演奏事件信息和前一条演奏事件信息之间的音符信息中匹配或错配模式，根据相应于状态信息的匹配或错配模式需要所述的音符信息。
2.如权利要求1所述的音乐数据压缩方法，其中，所述转换步骤包含用于预定初始音调音高的差表示包含在音符信息中的音调音高信息。
3.如权利要求2所述的音乐数据压缩方法，其中，初始音调音高是包含在音乐数据中的任何一条演奏事件信息的音调音高。
4.如权利要求2所述的音乐数据压缩方法，其中，在所述接收步骤中收到的音乐数据包括与多个声道的多条演奏事件信息序列，和其中，所述转换步骤包含以时序顺序排列用于所有声道的多条演奏事件信息，和检测以时序顺序为所有声道排列的每条演奏事件信息和前一条演奏事件信息之间音符信息中的匹配或错配。
5.如权利要求2所述的音乐数据压缩方法，其中，在所述接收步骤中收到的音乐数据包括用于多个声道的多条演奏事件信息序列，和其中，转换步骤包含在声道-声道基础上以时序顺序排列多条演奏事件信息，和检测在声道-声道基础上以时序顺序排列的每条演奏事件信息和前一条演奏事件信息之间音符信息中的匹配或错配。
6.如权利要求4所述的音乐数据压缩方法，其中，为每个声道设定初始音调音高，音调音高信息由用于每个声道的差来表示。
7.如权利要求4所述的音乐数据压缩方法，其中，初始音调音高包括单音调音高，以时序顺序排列的用于所有声道的每条演奏事件信息的音调音高信息与单初始音调音高的差来表示。
8.如权利要求1所述的音乐数据压缩方法，其中，每条演奏事件信息的音符信息包含间隔信息和与多条演奏事件信息相关的演奏事件的发声持续时间信息，间隔信息代表与前一条演奏事件信息的间隔，和其中，转换步骤包含用预定音符长度表示的间隔信息和发声持续时间信息。
9.一种使计算机执行音乐数据压缩方法的程序，包括接收模块，用于接收音乐数据，音乐数据包含多条演奏事件信息的序列，每条演奏事件信息由音符信息形成；和转换模块，用于把音乐数据的多条演奏事件信息转换为另一种形式的演奏事件信息，它包含状态信息和音符信息，状态信息相应于一条演奏事件信息和前一条演奏事件信息之间的音符信息中匹配或错配模式，根据相应于状态信息的匹配或错配模式需要所述的音符信息。
全文摘要
提供了一种新的音乐数据压缩方法，能显著减小音乐数据的尺寸。接收包含演奏事件数据的序列的音乐数据，每个演奏事件数据由音符信息形成。把音乐数据的每条演奏事件信息转换为另一种形式的演奏事件信息，它包含状态信息和音符信息，状态信息相应于一条演奏事件信息和前一条演奏事件信息之间的音符信息中匹配或错配模式，并且根据相应于状态信息的匹配或错配模式需要所述的音符信息。
文档编号G10K15/02GK1445747SQ0310742
公开日2003年10月1日 申请日期2003年3月20日 优先权日2002年3月20日
发明者川岛隆宏, 鸟羽伸和 申请人:雅马哈株式会社