具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述。其中，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。

并且，在本申请实施例的描述中，除非另有说明，″/″表示或的意思，例如，A/B可以表示A或B；文本中的″和/或″仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况，另外，在本申请实施例的描述中，″多个″是指两个或多于两个。

以下，术语″第一″、″第二″仅用于描述目的，而不能理解为暗示或暗示相对重要性或者隐合指明所指示的技术特征的数量。由此，限定有″第一″、″第二″、的特征可以明示或者隐含地包括一个或者更多个该特征，在本申请实施例的描述中，除非另有说明，″多个″的含义是两个或两个以上。

随着计算机技术的发展、每个音乐爱好者都可以采用相应的音乐制作工具自制专辑文件。尤其针对无损专辑，因其音质质量高广受用户的喜爱。但是目前还没办法播放没有解析文件的专辑文件，因此在自制无损专辑文件时，用户也需要自制相关的解析文件配合无损专辑文件来使用。然而实际应用中，用户自制解析文件往往会比较困难。其主要原因是因为解析文件对于格式要求比较严格，而非专业人员自己制作解析文件时经常达不到相关要求。

有鉴于此，本申请实施例提供了一种生成专辑文件的解析文件的方法和终端设备。本申请实施例中首先获取包含多首单曲的专辑文件，通过相邻两首单曲之间的音频特征，从专辑文件中提取每首单曲的起始播放时间，这样可以对专辑文件进行拆分，将一个完整专辑解析成多个单曲，然后按照解析文件模板的格式要求生成包含单曲信息的解析文件。通过本申请提供的生成解析文件的方法，对解析文件的格式要求降低，能够使得用户自制解析文件时更加便捷，提升用户体验。

在介绍完本申请的发明构思之后，下面先对本申请提供的终端设备进行说明。图1A示出了一种终端设备100的结构示意图。应该理解的是，图1A所示终端设备100仅是一个范例，并且终端设备100可以具有比图1A中所示的更多的或者更少的部件，可以组合两个或多个的部件，或者可以具有不同的部件配置。图中所示出的各种部件可以在包括一个或多个信号处理和/或专用集成电路在内的硬件、软件、或硬件和软件的组合中实现。

图1A中示例性示出了根据示例性实施例中终端设备100的硬件配置框图。如图1A所示，终端设备100包括：射频(radio frequency，RF)电路110、存储器120、显示单元130、摄像头140、传感器150、音频电路160、无线保真(Wireless Fidelity，Wi-Fi)模块170、处理器180、蓝牙模块181、以及电源190等部件。

RF电路110可用于在收发信息或通话过程中信号的接收和发送，可以接收基站的下行数据后交给处理器180处理；可以将上行数据发送给基站。通常，RF电路包括但不限于天线、至少一个放大器、收发信机、耦合器、低噪声放大器、双工器等器件。

存储器120可用于存储软件程序及数据。处理器180通过运行存储在存储器120的软件程序或数据，从而执行终端设备100的各种功能以及数据处理。存储器120可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。存储器120存储有使得终端设备100能运行的操作系统。本申请中存储器120可以存储操作系统及各种应用程序，还可以存储执行本申请实施例所述专辑文件的解析文件的生成方法的程序代码。

显示单元130可用于接收输入的数字或字符信息，产生与终端设备100的用户设置以及功能控制有关的信号输入，具体地，显示单元130可以包括设置在终端设备100正面的触摸屏131，可收集用户在其上或附近的触摸操作，例如点击按钮，拖动滚动框等。

显示单元130还可用于显示由用户输入的信息或提供给用户的信息以及终端设备100的各种菜单的图形用户界面(graphical user interface，GUI)。具体地，显示单元130可以包括设置在终端设备100正面的显示屏132。其中，显示屏132可以采用液晶显示器、发光二极管等形式来配置。显示单元130可以用于显示本申请中专辑文件信息或者单曲信息的界面。

其中，触摸屏131可以覆盖在显示屏132之上，也可以将触摸屏131与显示屏132集成而实现终端设备100的输入和输出功能，集成后可以简称触摸显示屏。本申请中显示单元130可以显示应用程序以及对应的操作步骤。

摄像头140可用于捕获静态图像或视频。物体通过镜头生成光学图像投射到感光元件。感光元件可以是电荷耦合器件(charge coupled device，CCD)或互补金属氧化物半导体(complementary metal-oxide-semiconductor，CMOS)光电晶体管。感光元件把光信号转换成电信号，之后将电信号传递给处理器180转换成数字图像信号。

终端设备100还可以包括至少一种传感器150，比如加速度传感器151、距离传感器152、指纹传感器153、温度传感器154。终端设备100还可配置有陀螺仪、气压计、湿度计、温度计、红外线传感器、光传感器、运动传感器等其他传感器。

音频电路160、扬声器161、麦克风162可提供用户与终端设备100之间的音频接口。音频电路160可将接收到的音频数据转换后的电信号，传输到扬声器161，由扬声器161转换为声音信号输出。终端设备100还可配置音量按钮，用于调节声音信号的音量。另一方面，麦克风162将收集的声音信号转换为电信号，由音频电路160接收后转换为音频数据，再将音频数据输出至RF电路110以发送给比如另一终端设备，或者将音频数据输出至存储器120以便进一步处理。本申请中麦克风162可以采集音频数据，从而使得用户制作专辑文件，扬声器161可以用于播放单曲。

Wi-Fi属于短距离无线传输技术，终端设备100可以通过Wi-Fi模块170帮助用户收发电子邮件、浏览网页和访问流媒体等，它为用户提供了无线的宽带互联网访问。

处理器180是终端设备100的控制中心，利用各种接口和线路连接整个终端设备的各个部分，通过运行或执行存储在存储器120内的软件程序，以及调用存储在存储器120内的数据，执行终端设备100的各种功能和处理数据。在一些实施例中，处理器180可包括一个或多个处理单元；处理器180还可以集成应用处理器和基带处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，基带处理器主要处理无线通信。可以理解的是，上述基带处理器也可以不集成到处理器180中。本申请中处理器180可以运行操作系统、应用程序、用户界面显示及触控响应，以及本申请实施例所述的专辑文件的解析文件生成方法。另外，处理器180与显示单元130耦接。

蓝牙模块181，用于通过蓝牙协议来与其他具有蓝牙模块的蓝牙设备进行信息交互。例如，终端设备100可以通过蓝牙模块181与同样具备蓝牙模块的可穿戴电子设备(例如智能手表)建立蓝牙连接，从而进行数据交互。

终端设备100还包括给各个部件供电的电源190(比如电池)。电源可以通过电源管理系统与处理器180逻辑相连，从而通过电源管理系统实现管理充电、放电以及功耗等功能。终端设备100还可配置有电源按钮，用于终端设备的开机和关机，以及锁屏等功能。

图1B是本申请实施例的终端设备100的软件结构框图。

分层架构将软件分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实施例中，可将Android系统分为四层，从上至下分别为应用程序层，应用程序框架层，安卓运行时(Android runtime)和系统库，以及内核层。

应用程序层可以包括一系列应用程序包。

如图1B所示，应用程序包可以包括相机，图库，日历，通话，地图，导航，WLAN，蓝牙，音乐，视频，短信息等应用程序。

应用程序框架层为应用程序层的应用程序提供应用编程接口(applicationprogramming interface，API)和编程框架。应用程序框架层包括一些预先定义的函数。

如图1B所示，应用程序框架层可以包括窗口管理器，内容提供器，视图系统，电话管理器，资源管理器，通知管理器等。

窗口管理器用于管理窗口程序。窗口管理器可以获取显示屏大小，判断是否有状态栏，锁定屏幕，截取屏幕等。

内容提供器用来存放和获取数据，并使这些数据可以被应用程序访问。所述数据可以包括视频，图像，音频，拨打和接听的电话，浏览历史和书签，电话簿、短信息等。

视图系统包括可视控件，例如显示文字的控件，显示图片的控件等。视图系统可用于构建应用程序。显示界面可以由一个或多个视图组成的。例如，包括短信息通知图标的显示界面，可以包括显示文字的视图以及显示图片的视图。

电话管理器用于提供终端设备100的通信功能。例如通话状态的管理(包括接通，挂断等)。

资源管理器为应用程序提供各种资源，比如本地化字符串，图标，图片，布局文件，视频文件等。

通知管理器使应用程序可以在状态栏中显示通知信息(例如短信息的消息摘要，消息内容)，可以用于传达告知类型的消息，可以短暂停留后自动消失，无需用户交互。比如通知管理器被用于告知下载完成，消息提醒等。通知管理器还可以是以图表或者滚动条文本形式出现在系统顶部状态栏的通知，例如后台运行的应用程序的通知，还可以是以对话窗口形式出现在屏幕上的通知。例如在状态栏提示文本信息，发出提示音，终端设备振动，指示灯闪烁等。

Android Runtime包括核心库和虚拟机。Android runtime负责安卓系统的调度和管理。

核心库包含两部分：一部分是java语言需要调用的功能函数，另一部分是安卓的核心库。

应用程序层和应用程序框架层运行在虚拟机中。虚拟机将应用程序层和应用程序框架层的java文件执行为二进制文件。虚拟机用于执行对象生命周期的管理，堆栈管理，线程管理，安全和异常的管理，以及垃圾回收等功能。

系统库可以包括多个功能模块。例如：表面管理器(surface manager)，媒体库(Media Libraries)，三维图形处理库(例如：OpenGL ES)，2D图形引擎(例如：SGL)等。

表面管理器用于对显示子系统进行管理，并且为多个应用程序提供了2D和3D图层的融合。

媒体库支持多种常用的音频，视频格式回放和录制，以及静态图像文件等。媒体库可以支持多种音视频编码格式，例如：MPEG4，H.264，MP3，AAC，AMR，JPG，PNG等。

三维图形处理库用于实现三维图形绘图，图像渲染，合成，和图层处理等。

2D(一种动画方式)图形引擎是2D绘图的绘图引擎。

内核层是硬件和软件之间的层。内核层至少包含显示驱动，摄像头驱动，音频驱动，传感器驱动。

本申请实施例中的终端设备100可以为包括但不限于移动终端、平板电脑等电子设备。

下面对本申请实施例的技术方案能够适用的应用场景做一些简单介绍，需要说明的是，以下介绍的应用场景仅用于说明本申请实施例而非限定。在具体实施时，可以根据实际需要灵活地应用本申请实施例提供的技术方案。

参考图1C，其为本申请实施例提供的应用场景示意图。该应用场景中包括采集设备101、终端设备102、网络103、智能终端设备104。采集设备101为用于采集音乐的设备，例如声频采集卡、录音笔、麦克风等。终端设备102包括但不限于桌面计算机、移动电脑、平板电脑、智能电视等电子设备。智能终端设备104包括但不限于数字会议桌面智能终端、可视电话、会议终端、内置多媒体功能的个人计算机、掌上电脑、智能手机等。

采集设备101和终端设备102之间通过无线或有线网络连接。本申请实施例可以适用于用户可以采用采集设备101录制音乐生成专辑文件，通过终端设备102制作解析文件，然后上传到网络103供远端的智能终端设备104播放。

当然，本申请实施例提供的方法并不限于图1C所示的应用场景，还可以用于其它可能的应用场景，本申请实施例并不进行限制。对于图1C所示的应用场景的各个设备所能实现的功能将在后续的方法实施例中一并进行描述，在此先不过多赘述。

本申请实施例提供的生成专辑文件的解析文件的解析方法里需要替换预设的解析文件模板的内容，因此需要提前创建了一个格式正确的解析文件模板。

下面结合图1D对本申请实施例提供的解析文件模板格式进行说明，以便于本领域技术人员理解。参考图1D，其中：

FILE：指的是专辑文件的文件名。

TRACK(单曲)，每个单曲都具有一个对应的TRACK，用于标识一首单曲的单曲信息在解析文件中的起始位置。

专辑Title(标题)：在第一个TRACK之前的TITLE用于指示专辑标题。

单曲Title：在每个TRACK的下一行中的TITLE为该TRACK的单曲标题。

专辑Performer(作者)：在第一个TRACK出现之前的PERFORMER用于指示专辑作者。

单曲Performer：在每个TRACK的下一行中的PERFORMER用于指示单曲作者。

INDEX：每个INDEX均会对应一个TRACK，用于指示该TRACK的起始播放时间。

为了便于理解本申请实施例提供的专辑文件的解析文件生成方法，下面结合附图对此进行进一步说明。

图2为本申请实施例提供的一种专辑文件的解析文件生成方法的流程示意图。尤其适用于无损专辑，如图2所示，该方法包括以下步骤：

步骤201：获取包含多首单曲的专辑文件。

在一些实施例中，在生成解析文件之前需要判断专辑文件中没有解析文件的存在。若专辑文件中已经存在解析文件，则不需要生成解析文件，若专辑文件中不存在解析文件，则需要生成解析文件。图3为判断解析文件是否存在的流程示意图，具体包含以下步骤：

首先获取包含多首单曲的专辑文件，然后在步骤301中，播放专辑文件里的音乐A。在步骤302中，查数据库信息获取音乐A的完整路径。之后在步骤303中，判断音乐A的路径中是否存在和音乐A同名的后缀为.cue的文件，若存在，则说明专辑文件中已经有解析文件，在步骤304中，操作结束。若不存在，则说明专辑文件中没有解析文件，在步骤305中，根据本申请实施例提供的方法生成专辑文件的解析文件。

步骤202：从专辑文件中提取指定音频特征。

其中，指定音频特征用于描述相邻两首单曲之间的间隔。一种可能的实施方式中，音频特征可以是静音时长。基于静音时长提取指定音频特征可实施为：获取专辑文件的波形数据，从波形数据中获取表示静音状态的音频量级的字节；若指定时长内表示静音状态的音频量级的字节数量满足预设条件，则确定提取到所述音频特征。其中，指定时长指的是上一首音乐播放完毕到下一首音乐起播所需的切歌时间，可由用户自行设定也可以为固定值。指定时长中包括n个单位时长，n为大于1的正整数。

基于静音时长中的单位时长提取指定音频特征的方式可实施为如图4所示的步骤：

首先播放专辑文件，在步骤401中，打开Visualizer(可视化工具)。然后在步骤402中，将Visualizer与正在播放的专辑文件进行连接。

其中，可以在启动可视化工具之后，在可视化工具界面写入可执行指令，将正在播放的专辑文件放入可视化工具中，将可视化工具与正在播放的专辑文件进行连接。

在步骤403中，获取专辑文件的波形数据。

在步骤404中，从波形数据中获取表示静音状态的音频量级的字节。

在步骤405中，判断指定时长内表示静音状态的音频量级的字节数量是否满足预设条件，若满足，则在步骤406中，提取指定音频特征，若不满足，则继续执行步骤404，直至专辑文件播放结束。

其中，预设条件包括连续n个单位时长均为静音状态且指定时长内表示静音状态的音频量级的字节数量超过预设数量阈值。

在一些实施例中，判断指定时长内表示静音状态的音频量级的字节数量是否满足预设条件可以实施为统计每个单位时长内的表示静音状态的音频量级的字节数量的占比，再将统计的占比和预设占比作比较。具体步骤如图5所示：

在步骤501中，统计每个单位时长内的表示静音状态的音频量级的字节数量的占比。

在步骤502中，将统计的占比与预设占比做比较，若超过预设占比，则执行步骤503中，确定当前单位时长为静音状态，若没有超过预设占比，则返回执行步骤501。

在步骤504中，判断是否连续n个单位时长均处于静音状态，若是，则在步骤505中，满足预设条件，若否，则在步骤506中，不满足预设条件。

在另一实施方式中，可以对待提取的音频段进行预处理和离散傅里叶变换得到二维谱图信号，并将其送入神经网络进行计算，得到要生成的音频特征。将生成的音频特征与指定音频特征进行对比，若对比相似度超过指定阈值，则确定提取到指定音频特征。

由此，通过以上方式，能够确定从专辑文件中提取到指定音频特征，以便于后续可以根据指定音频特征从专辑文件中切分出单曲。

步骤203：基于指定音频特征，从专辑文件中提取每首单曲的起始播放时间。

其中，专辑文件的第一首单曲的起始播放时间可设定为默认值，例如为专辑文件的起始播放时间。而后每一首单曲的起始播放时间的确定方式可实施为，获取指定音频特征在专辑文件的播放时间轴上的结束时间点，将该结束时间点记录为下一首单曲的起始播放时间。例如两首单曲之间有4秒的时间处于静音状态，则将第4秒的时间点作为第二首单曲的起始播放时间。如图1D中第一首单曲TRACK01的INDEX 01为00：00：00，切分出第二首单曲TRACK02的INDEX 01为04：19：28。

当然，在另一实施例中也可以从指定音频特征占用的时间区间中任取一个时间点作为下一首单曲的起始播放时间，同样适用于本申请实施例。

由此，通过以上方式，能够根据指定音频特征提取出每首单曲的起始播放时间，完成对专辑文件的拆分，使得在播放专辑文件时可以显示专辑中单曲的时长，同时也可以使用户在切歌时可以切换一首单曲而不是整首专辑。

步骤204：基于专辑文件的文件名称和提取的每首单曲的起始播放时间，按照预设的解析文件模板的格式要求，生成专辑文件的解析文件。

在一些实施例中，在专辑文件播放完成后，根据预设的解析文件模板的格式要求，生成解析文件，可实施为如图6所示的步骤：

在步骤601中，将预设的解析文件模板的名称修改为专辑文件的文件名称。

在步骤602中，基于专辑文件的文件名，生成解析文件中专辑文件的描述信息。

在步骤603中，基于每首单曲的起始播放时间，生成解析文件中每首单曲的描述信息。

本申请实施例中对以上三个步骤执行的先后顺序不做要求，可以根据步骤601-603的顺序执行，可以同时执行，也可以先执行步骤602，再执行步骤601，然后执行步骤603，依次类推。

其中，单曲的描述信息中包括单曲的标题。解析文件中每首单曲的单曲标题可以针对每首单曲，按照每首单曲在专辑文件中的播放顺序进行命名。单曲的描述信息中还包括单曲的作者名称，解析文件中每首单曲的单曲作者名称可以针对每首单曲，按照每首单曲在专辑文件中的播放顺序进行单曲作者名称的命名。其中播放顺序根据每首单曲的起始播放时间决定。

由此，通过以上方式，能够根据预设的解析文件的模板生成新的解析文件，解决生成解析文件困难的问题。

例如，专辑文件M中包含了3首单曲，通过指定音频特征提取了专辑文件的文件名M，专辑文件的专辑标题M，专辑文件的作者名称M1，单曲的单曲标题X、Y、Z，单曲的作者名称X1、Y1、Z1，单曲的起始播放时间00：00：00、04：22：18、08：25：34。然后按照图1D所示的模板格式生成解析文件。具体操作是将专辑文件的文件名M替换图1D所示的模板格式中FILE″2007.B.flac″中的″B″；将专辑文件的专辑标题M替换图1D所示的模板格式中TITLE″2007.B″中的″B″；将专辑文件的作者名称M1替换图1D所示的模板格式中PERFORMER″A″中的″A″。然后根据单曲的起始播放时间顺序，将单曲标题X、单曲X的作者名称X1、单曲X的起始播放时间00：00：00替换图1D所示的模板格式中TRACK01下面TITLE″B″、PERFORMER″B1″、INDEX 01 00：00：00中的″B″、″B1″、″00：00：00″；将单曲标题Y、单曲Y的作者名称Y1、单曲Y的起始播放时间04：22：18替换图1D所示的模板格式中TRACK 02下面TITLE″C″、PERFORMER″C1″、INDEX 01 04：19：28中的″C″、″C1″、″04：19：28″；将单曲标题Z、单曲Z的作者名称Z1、单曲Z的起始播放时间08：25：34替换图1D所示的模板格式中TRACK 03下面TITLE″D″、PERFORMER″D1″、INDEX 01 08：29：40中的″D″、″D1″、″08：29：40″。

另外，为了在解析文件中将每个单曲区分开，让用户可以快速找到自己想要的单曲，同时可以让用户修改对应位置的单曲标题和作者名称，方便用户。在一些实施例中，生成专辑文件的解析文件之后，可以在用户界面中展示解析文件中的单曲标题和单曲作者名称；同时响应于在用户界面触发的针对目标单曲和目标单曲的作者名称的命名请求，获取目标单曲的自定义标题和自定义作者名称作为目标单曲的最终名标题和最终作者名称；并采用最终标题和最终作者名称更新解析文件中目标单曲的单曲标题和单曲作者名称。

下面结合图7对本申请实施例的提供的专辑文件的解析文件生成方法进行进一步的详细介绍，具体步骤如下所示：

在步骤701中，播放专辑文件内的音乐。

在步骤702中，判断专辑文件内解析文件是否存在。若专辑文件内存在解析文件，在步骤703中，播放单曲；若专辑文件内不存在解析文件，则执行步骤704。

在步骤704中，播放完整的专辑文件。

在步骤705中，打开Visualizer(可视化工具)。

在步骤706中，将Visualizer与正在播放的专辑文件进行连接。

在步骤707中，设置波形监听，获取专辑文件的波形数据。

在步骤708中，从波形数据中获取音频量级数组。

在步骤709中，计算音频量级数组各个音频量级的数据。

由于音频量级的值是有误差的，音频量级数组内除了包含表示静音状态的音频量级数据，也可能包含其他的音频量级数据，但是如果其他的音频量级数据较少，则不会影响整体的静音状态。因此在步骤710中，获取每秒内表示静音状态的音频量级的字节，统计每秒内的表示静音状态的音频量级的字节数量的占比。然后在步骤711中，比较占比是否超过预设占比。若超过预设占比，则说明该秒时间内处于静音状态，继续执行步骤712，否则继续执行步骤710。

在步骤712中，判断处于静音状态的连续时长是否超过设定的时长阈值。若超过设定的时长阈值，则执行步骤713，否则继续执行步骤710。

在步骤713中，记录设定的时长阈值的最后时间点A1-An。

在步骤714中，判断单曲是否播放结束。若没有结束，则重复执行步骤710-714直至单曲播放结束，若播放结束，则在步骤715中，会提示用户是否进行保存。若用户不保存，则在步骤716中，操作结束。若用户保存，则在步骤717中，重命名预设的解析文件模板。

在步骤718中，打开重命名后的解析文件模板，并将解析文件模板里的各个字段保存为String(字符串)类型。

在步骤719中，将A1(An)写入TRACK01(TRACK n)的起始播放位置。

在步骤720中，将生成的新String写入解析文件中。

在步骤721中，保存解析文件。

基于前文的描述，通过对专辑文件中两首单曲之间的静音时长的提取，从而提取出每首单曲的起始播放时间，对专辑文件进行拆分。再根据预设的解析文件的模板生成新的解析文件，能够实现在播放专辑文件时，可以显示专辑文件中的单曲时长，使得用户在切歌时可以切换一首单曲而不是整个专辑，同时还可以将专辑中的单曲添加到歌单、收藏、随机播放中，随机播放时不需要播完整首专辑才能随机播放下一首单曲，方便了用户。最终解决制作专辑文件的解析文件困难的问题。

本申请提供的实施例之间的相似部分相互参见即可，以上提供的具体实施方式只是本申请总的构思下的几个示例，并不构成本申请保护范围的限定。对于本领域的技术人员而言，在不付出创造性劳动的前提下依据本申请方案所扩展出的任何其他实施方式都属于本申请的保护范围。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。