CN113873085A - 一种语音开场白的生成方法及相关装置 - Google Patents

Abstract

本申请实施例公开一种语音开场白的生成方法及相关装置，新增语音录制功能入口，在自定义语音开场白时，展示语音录制功能入口。若需要通过语音录制功能定义语音开场白，第一用户触发针对语音录制功能入口的选择操作，开始录制第一用户的语音。若接收到录制停止指令，则完成录制，根据录制的第一用户的语音生成初始音频文件。终端设备向服务器提交初始音频文件，以便服务器利用该初始音频文件确定语音开场白，在通过电话接听助理接听到第二用户呼叫第一用户的来电时，向第二用户播放该语音开场白。该语音开场白具有人声的抑扬顿挫，符合第一用户的正常语言表达方式，从而使得第二用户愿意继续沟通，便于电话接听助理更好的获取第二用户的来电意图。

Description

一种语音开场白的生成方法及相关装置

技术领域

本申请涉及通信技术领域，特别是涉及一种语音开场白的生成方法及相关装置。

背景技术

随着移动通信电子设备的快速发展以及服务商资费的逐步降低，使得用户之间通过移动通信设备进行沟通变的更加便捷，也更加频繁。用户之间通过移动通信电子设备可以随时随地进行通话联系。

但是，有时可能会出现用户没空或不方便接电话、占线、无人接听或没信号的状态，在这种情况下，可以通过智能接听助理接听其他用户来电，智能接听助理可以通过和来电方进行对话，获取对方来电意图，并在通话结束后，生成聊天记录以供用户查看。

然而，相关技术中提供的智能接听助理发出的语音开场白缺少人声的抑扬顿挫，所以听起来会十分生硬，来电用户的体验相对较差，进而导致来电用户缺少沟通意愿，进而挂断电话，使得电话接听助理的功能无法真正发挥预期的作用。

发明内容

为了解决上述技术问题，本申请提供了一种语音开场白的生成方法及相关装置，播放的语音开场白是对第一用户的语音进行录制得到的，具有人声的抑扬顿挫，符合第一用户的正常语言表达方式，从而提高来电用户例如第二用户的体验，使得第二用户愿意继续沟通，便于电话接听助理更好的获取第二用户的来电意图。

本申请实施例公开了如下技术方案：

第一方面，本申请实施例提供一种语音开场白的生成方法，所述方法包括：

在语音开场白创建界面中，展示语音录制功能入口；

响应于针对所述语音录制功能入口的选择操作，开始录制第一用户的语音；

若接收到录制停止指令，根据录制的所述第一用户的语音生成初始音频文件；

向服务器提交所述初始音频文件，所述初始音频文件用于确定语音开场白，所述语音开场白用于在接听到第二用户呼叫所述第一用户的来电时，向所述第二用户播放。

第二方面，本申请实施例提供一种语音开场白的生成方法，所述方法包括：

获取终端设备提交的初始音频文件，所述初始音频文件是所述终端设备根据第一用户的语音录制得到的；

对所述音频文件进行音频转码压缩，得到符合播放条件的目标音频文件；

验证所述目标音频文件中是否存在敏感词，得到验证结果；

若验证结果指示验证通过，将所述目标音频文件作为语音开场白，所述语音开场白用于在接听到第二用户呼叫所述第一用户的来电时，向所述第二用户播放。

第三方面，本申请实施例提供一种语音开场白的生成装置，所述装置包括展示单元、录制单元、生成单元和提交单元：

所述展示单元，用于在语音开场白创建界面中，展示语音录制功能入口；

所述录制单元，用于响应于针对所述语音录制功能入口的选择操作，开始录制第一用户的语音；

所述生成单元，用于若接收到录制停止指令，根据录制的所述第一用户的语音生成初始音频文件；

所述提交单元，用于向服务器提交所述初始音频文件，所述初始音频文件用于确定语音开场白，所述语音开场白用于在接听到第二用户呼叫所述第一用户的来电时，向所述第二用户播放。

第四方面，本申请实施例提供一种语音开场白的生成装置，所述装置包括获取单元、生成单元、验证单元和确定单元：

所述获取单元，用于获取终端设备提交的初始音频文件，所述初始音频文件是所述终端设备根据第一用户的语音录制得到的；

所述生成单元，用于对所述音频文件进行音频转码压缩，得到符合播放条件的目标音频文件；

所述验证单元，用于验证所述目标音频文件中是否存在敏感词，得到验证结果；

所述确定单元，用于若验证结果指示验证通过，将所述目标音频文件作为语音开场白，所述语音开场白用于在接听到第二用户呼叫所述第一用户的来电时，向所述第二用户播放。

第五方面，本申请实施例提供一种设备，所述设备包括处理器以及存储器：

所述存储器用于存储程序代码，并将所述程序代码传输给所述处理器；

所述处理器用于根据所述程序代码中的指令执行第一方面或第二方面所述的方法。

第六方面，本申请实施例提供一种计算机可读存储介质，所述计算机可读存储介质用于存储程序代码，所述程序代码用于执行第一方面或第二方面所述的方法。

由上述技术方案可以看出，本申请在原有的语音开场白创建的界面中新增语音录制功能入口，这样，在自定义语音开场白时，可以展示语音录制功能入口。当需要通过语音录制功能定义语音开场白时，第一用户可以触发针对语音录制功能入口的选择操作，开始录制第一用户的语音。若接收到录制停止指令，则完成录制，根据录制的第一用户的语音生成初始音频文件。终端设备可以向服务器提交该初始音频文件，以便服务器利用该初始音频文件确定语音开场白，在通过电话接听助理接听到第二用户呼叫第一用户的来电时，向第二用户播放该语音开场白。可见，本申请在通过电话接听助理接听来电时，播放的语音开场白是对第一用户的语音进行录制得到的，具有人声的抑扬顿挫，符合第一用户的正常语言表达方式，从而提高来电用户例如第二用户的体验，使得第二用户愿意继续沟通，便于电话接听助理更好的获取第二用户的来电意图。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术成员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为相关技术中一种自定义语音开场白的界面示意图；

图2为本申请实施例提供的一种语音开场白生成方法的系统架构示意图；

图3为本申请实施例提供的一种语音开场白生成方法的流程图；

图4为本申请实施例提供的一种自定义语音开场白的界面示意图；

图5为本申请实施例提供的语音录制界面的示意图；

图6为本申请实施例提供的录制第一用户的语音的流程图；

图7为本申请实施例提供的向第一用户展示初始音频文件的界面示意图；

图8为本申请实施例提供的向第一用户展示初始音频文件的界面示意图；

图9为本申请实施例提供的一种语音开场白生成方法的流程图；

图10为本申请实施例提供的一种对目标语音文件进行验证的流程图；

图11为本申请实施例提供的语音开场白设置成功的界面示意图；

图12为本申请实施例提供的一种轮询过程的详细流程图；

图13为本申请实施例提供的一种语音开场白生成方法的流程图；

图14为本申请实施例提供的一种语音开场白的生成装置的结构图；

图15为本申请实施例提供的一种语音开场白的生成装置的结构图；

图16为本申请实施例提供的一种设备的结构图；

图17为本申请实施例提供的一种服务器的结构图。

具体实施方式

下面结合附图，对本申请的实施例进行描述。

目前，电话接听助理的语音开场白是使用自定义文本的方式，参见图1所示，用于可以在文本框中输入开场白文本，例如“您好，我是他的接听助理，他现在在忙，不方便接电话，请问您是哪位？有什么事？”，通过用户自己定义自己的开场白文本，上传到服务器，服务器在转接时将文本转化为语音向来电用户播放，达到用户自定义开场白的效果。

但是，这种文本转语音的开场白在用户体验上相对较差，因为生成的语音缺少人声的抑扬顿挫，所以听起来会十分生硬。由于生成的语音听起来十分生硬，同时由于文字长度也只能限制在50字以内，能表达的信息相对较少，进而导致来电用户缺少沟通意愿，进而挂断电话，使得电话接听助理的功能无法真正发挥预期的作用。

另外，由于每个用户的文字都不一样，所以电话接听助理的语音是根据用户文本即时生成的，所以在转接时，生成较多文字会导致接听助理播放语音开场白的反应速度下降，从而降低了用户体验。

为了解决上述技术问题，本申请实施例提供一种语音开场白的生成方法，该方法在原有的语音开场白创建的界面中新增语音录制功能入口，这样，用户可以录制自己的语音作为语音接听助手的语音开场白。由于播放的语音开场白是对用户的语音进行录制得到的，具有人声的抑扬顿挫，符合第一用户的正常语言表达方式，且表达的信息相对较多，从而提高来电用户例如第二用户的体验，使得第二用户愿意继续沟通，便于电话接听助理更好的获取第二用户的来电意图。

另外，接听助理在接听时，直接播放的就是语音，在此之前无需做多余的处理，实时性较好，反应较快，进一步提高用户体验。

本申请实施例所提供的方法涉及到云技术领域，例如涉及大数据(Big data)，大数据是指无法在一定时间范围内用常规软件工具进行捕捉、管理和处理的数据集合，是需要新处理模式才能具有更强的决策力、洞察发现力和流程优化能力的海量、高增长率和多样化的信息资产。随着云时代的来临，大数据也吸引了越来越多的关注，大数据需要特殊的技术，以有效地处理大量的容忍经过时间内的数据。适用于大数据的技术，包括大规模并行处理数据库、数据挖掘、分布式文件系统、分布式数据库、云计算平台、互联网和可扩展的存储系统。例如生成的语音开场白可以存储在服务器上，以便在接听到来电方的来电时，可以向来电方播放存储在服务器上的语音开场白。

参见图2，图2为本申请实施例提供的语音开场白生成方法的系统架构示意图。该系统架构中包括终端设备201和服务器202，终端设备201上可以安装具有语音接听助理服务的客户端，可以开通语音接听助理服务，使得终端设备201具有通过语音接听助理接听来电的功能。该系统架构中可以包括多个终端设备201，终端设备201对应的用户可以作为接听方(例如第一用户)，终端设备201对应的用户可以作为来电方(例如第二用户)。终端设备201以及服务器202可以通过有线或无线通信方式进行直接或间接地连接，本申请在此不做限制。

服务器202可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器。终端设备201可以是智能手机、平板电脑、笔记本电脑、智能手表等具有语音通信功能的设备，但并不局限于此。

在需要自定义语音开场白时，终端设备201可以展示语音开场白创建界面，该语音开场白创建界面上可以展示语音录制功能入口。当第一用户需要通过录制语音的方式自定义语音开场白时，第一用户可以针对语音录制功能入口执行选择操作，使得终端设备201开始录制第一用户的语音。

若终端设备201接收到录制停止指令，则完成录制，终端设备201可以根据录制的第一用户的语音生成初始音频文件。

终端设备201向服务器202提交初始音频文件，以便服务器202可以根据初始音频文件确定语音开场白。这样，当第二用户通过终端设备201呼叫第一用时，由于第一用户对应的终端设备201开启了语音接听助理服务，则服务器202可以在接听到第二用户呼叫第一用户的来电时，向第二用户播放语音开场白，从而吸引第二用户与语音接听助理进行沟通，更好的获取第二用户的来电意图。

在本申请实施例中，通过语音录制的方式生成语音开场白的过程中，包括终端设备录制语音生成初始音频文件，以及服务器根据初始音频文件生成语音开场白的过程，接下来，将结合附图分别从终端设备和服务器的角度对本申请实施例提供的语音开场白的生成方法进行详细介绍。

首先，从终端设备的角度对本申请实施例提供的语音开场白的生成方法进行介绍。参见图3，所述方法包括：

S301、在语音开场白创建界面中，展示语音录制功能入口。

本申请实施例在原有的语音开场白创建界面中新增语音录制功能入口，如图4中“使用个人录音”这一功能，在这一功能下，提供了“立即录入”按钮即语音录制功能入口。当用户例如第一用户需要字定义语音开场白时，终端设备可以在语音开场白创建界面中向第一用户展示语音录制功能入口，以便用户可以根据自己的需求选择生成语音开场白的方式。

当然，语音开场白创建界面中除了包括语音录制功能入口外，仍然保留了通过自定义文本的方式自定义语音开场白的方式，参见图4所示。第一用户可以自由的选择“使用个人录音”或“自定义文本”的方式自定义语音开场白。

除了上述两种自定义开场白的方式，还提供了自带统一的语音，例如图4中“使用助理语音”位置所展示的，该语音可以是“您好，主人不方便接听，有什么事吗？”。

S302、响应于针对所述语音录制功能入口的选择操作，开始录制第一用户的语音。

为了使得播放的语音开场白具有人声的抑扬顿挫，符合第一用户的正常语言表达方式，且表达的信息相对较多，从而提高第二用户的体验，使得第二用户愿意继续沟通，第一用户可以在自定义语音开场白时选择“使用个人录音”，当第一用户点击“立即录入”，即第一用户可以对语音录制功能入口的选择操作，则可以开始录制第一用户的语音。

其中，向第一用户展示的语音录制界面可以参见图5所示。在语音录制时，可以在图5所示的界面中“你可以这样说”的位置提示可以录制的语音内容，例如“您好，我是***，我可能在玩耍，也有可能在工作，暂时没有时间接听电话，你有什么事就和我的接听助理说吧”，这样，第一用户便可以录制与该语音内容类似的语音。

需要说明的是，在第一用户选择“立即录入”后，终端设备可以先初始化录音相关组件，准备录音。录音考虑到音频质量与上传大小，将使用m4a作为音频文件格式，其中，m4a是动态图像专家组(Moving Picture Experts Group，MPEG)4音频标准的文件的扩展名，采样率为44100赫兹(HZ)，录音质量为中等质量。另外，时长15秒的音频文件大概大小在100千字节(Kilobyte，kb)左右，在普通网络环境下能够快速上传到服务器中，故，通常情况下最大录音时长为15s。

录制第一用户的语音的流程图可以参见图6所示，第一用户开始录音(参见图6中S601，相当于S302)，为了可以控制录音时长，终端设备可以启动录音计时器，并开始计时(参见图6中S602)。在录音计时器没有达到最大录音时长前，第一用户能够通过图5所示的“录制停止控件”主动停止录音，或者，终端设备可以确定录音计时器记录的时长是否达到最大录音时长(参见图6中S603)，在录音计时器达到最大录音时长后，终端设备可以自动停止录音(参见图6中S604，相当于S303)。

S303、若接收到录制停止指令，根据录制的所述第一用户的语音生成初始音频文件。

在S302中介绍了停止语音录制的方式可以包括多种，即在录音计时器达到最大录音时长后，终端设备可以自动停止录音，或者第一用户通过图5所示的“录制停止控件”主动停止录音。因此，在本实施例中，录制停止指令触发条件是录制时长达到第一阈值(即录音计时器达到最大录音时长，此时，最大录音时长为第一阈值)，或接收到用户针对录制停止控件的触发。

在停止录音后，可以生成初始音频文件，向第一用户展示初始音频文件的界面可以参见图7所示，该初始音频文件为录音时长为12秒的音频文件。在该界面中还提供了“播放”控件，该“播放”控件用于在第一用户点击“播放”控件时，向第一用户播放初始音频文件，以便第一用户可以试听初始音频文件，从而决定是否向服务器提交该初始音频文件。该界面中还提供了“提交”控件，该“提交”控件用于在第一用户点击提交”控件时，向服务器提交该初始音频文件。

S304、向服务器提交所述初始音频文件。

当完成语音录制，生成初始音频文件后，可以向服务器提交该初始音频文件，例如第一用户可以通过点击图7中所示的“提交”控件，触发终端设备向服务器提交初始音频文件，以便服务器可以根据初始音频文件确定语音开场白，语音开场白用于在接听到第二用户呼叫第一用户的来电时，向所述第二用户播放。

在一些可能的实施例，为了保证向服务器提交的初始音频文件是第一用户满意的，第一用户在通过终端设备向服务器提交初始音频文件前，可以试听初始音频文件，判断初始音频文件是否满足要求，再决定是否向服务器提交该初始音频文件。因此，当第一用户需要试听该初始音频文件时，第一用户可以触发音频播放指令，终端设备在接收到音频播放指令，向所述第一用户播放初始音频文件。

其中，音频播放指令可以是通过图7所示的“播放”控件触发的。在第一用户试听完初始音频文件后，第一用户可以确定是否重新录制，即终端设备确定是否接收到重新录制指令(参见图6中S605)。若第一用户不满意，则可以通过点击图8所示的“重新录制”控件，即终端设备接收到重新录制指令，触发终端设备重新执行S302开始录制第一用户的语音(也是图6中S601)的步骤。若第一用户满意，则第一用户可以点击图8所示的“提交”控件(与图7中的“提交”控件功能相同)，触发终端设备执行S304中向服务器提交初始音频文件(也是图6中S606)的步骤。

向服务器提交初始音频文件的过程中如果出现错误，将重试，如果达到最大重试次数，将认为上传失败，并重新执行S301-S304的步骤。

由上述技术方案可以看出，本申请在原有的语音开场白创建的界面中新增语音录制功能入口，这样，在自定义语音开场白时，可以展示语音录制功能入口。当需要通过语音录制功能定义语音开场白时，第一用户可以触发针对语音录制功能入口的选择操作，开始录制第一用户的语音。若接收到录制停止指令，则完成录制，根据录制的第一用户的语音生成初始音频文件。客户端可以向服务器提交该初始音频文件，以便服务器利用该初始音频文件确定语音开场白，在通过电话接听助理接听到第二用户呼叫第一用户的来电时，向第二用户播放该语音开场白。可见，本申请在通过电话接听助理接听来电时，播放的语音开场白是对第一用户的语音进行录制得到的，具有人声的抑扬顿挫，符合第一用户的正常语言表达方式，从而提高来电用户例如第二用户的体验，使得第二用户愿意继续沟通，便于电话接听助理更好的获取第二用户的来电意图。

在服务器接收到终端设备提交的初始音频文件后，服务器可以根据初始音频文件生成语音开场白，以实现对语音开场白的设置。其中，服务器根据生成语音开场白的方式可以包括多种，第一种方式可以是服务器将初始音频文件进行简单处理，将符合要求的初始音频文件作为语音开场白；第二种方式可以是服务器获取第一用户的语音数据(即初始音频文件)，通过深度学习的方式学习第一用户的音频特征，进而根据第一用户的音频特征生成类似于第一用户本人声音的语音开场白。

接下来，将从服务器的角度，以第一种方式为例对本申请实施例提供的语音开场白的生成方法进行详细介绍。参见图9，所述方法包括：

S901、获取终端设备提交的初始音频文件，所述初始音频文件是所述终端设备根据第一用户的语音录制得到的。

服务器在接收到终端设备提交的初始音频文件后，服务器根据初始音频设备生成语音开场白，在这一过程中，为了可以得到符合要求，提高用户体验的语音开场白，服务器需要对初始音频设备进行验证，并在验证结果指示验证通过后生成语音开场白。具体验证流程参见图10所示，终端设备在通过对第一用户的语音进行录制得到初始音频文件后，提交初始音频文件至服务器。

S902、对所述音频文件进行音频转码压缩，得到符合播放条件的目标音频文件。

服务器在接收到终端设备上传的初始音频文件后，可以先对初始音频文件进行音频转码压缩，得到符合播放条件的目标音频文件。符合播放条件可以是使得录音格式符合语音转文字的要求，同时满足不同操作系统的终端设备的播放要求。此步骤相当于图10中S1001。

例如，服务器可以与多个终端设备连接，这些终端设备的操作系统可以是苹果操作系统(即iOS操作系统)，也可以是安卓操作系统，而安卓操作系统使用的是aar(AndroidArchive)格式，aar格式是安卓操作系统下的二进制归档文件，所以服务器在接收到安卓操作系统的终端设备的初始音频文件时，需要将初始音频文件统一转换成m4a格式，同样格式将被转化为采样率为44100HZ，录音质量为中等质量的m4a音频。

S903、验证所述目标音频文件中是否存在敏感词，得到验证结果。

为了保证得到的语音开场白符合要求，提高听见语音开场白的用户体验，可以对目标音频文件中是否存在敏感词，得到验证结果，从而避免提交的初始音频文件中包括涉黄、反动等言论信息，影响用户体验。

验证目标音频文件中是否存在敏感词的方式可以包括多种，第一种方式是直接根据语音即目标音频文件进行敏感词检测(参见图10中S1003，相当于S903)，第二种方式是使用语音转换接口，对目标音频文件进行语音转文字处理(参见图10中S1002)，再进行敏感词检测(参见图10中S1003)。

根据敏感词检测确定是否含有敏感词(参见图10中S1004)，得到的验证结果，该验证结果标识了目标音频文件中是否含有敏感词，即标识了初始音频文件中是否含有敏感词。

S904、若验证结果指示验证通过，将所述目标音频文件作为语音开场白。

服务器在得到验证结果后，若验证结果指示验证通过，即目标音频文件中未包含敏感词，则可以将目标音频文件作为语音开场白，保存至服务器的数据库中(参见图10中S1005)。该语音开场白用于在接听到第二用户呼叫所述第一用户的来电时，向第二用户播放。若验证结果指示验证失败，即目标音频文件中包含敏感词，则服务器清除目标音频文件。

在一些可能的实施例中，服务器还可以向终端设备返回验证结果，通过该验证结果终端设备可以知晓其提交的初始音频文件是否包含敏感词，故该验证结果可以指示终端设备是否重新录制第一用户的语音。若该验证结果表示初始音频文件未包含敏感词，则无需重新录制，若该验证结果表示初始音频文件包含敏感词，则提示第一用户重新录制，并提示用户哪些是敏感词，以避免重新录制过程中再次出现敏感词。

在一些可能的实施例中，可能会出现由于网络状况不佳等原因，导致终端设备提交的初始音频文件与服务器接收到的音频文件不一致，例如，初始音频文件提交过程中，若网络中断，可能导致服务器仅接收到初始音频文件中的一部分。在这种情况下，为了避免服务器生成的语音开场白与终端设备提交的初始音频文件不一致，服务器还可以根据目标音频文件生成第一音频标识，第一音频标识可以唯一标识目标音频文件，由于目标音频文件与初始音频文件的内容是一致的，因此，第一音频标识可以唯一标识该初始音频文件。服务器向终端设备返回第一音频标识，根据所述第一音频标识与根据所述初始音频文件生成的第二音频标识的一致性，以便终端设备可以确定语音开场白是否设置成功。若设置成功，则展示图11所示的界面，显示“设置成功”；否则，重新录制或重新提交初始音频文件。

其中，第一音频标识和第二音频标识可以是消息摘要算法5(Message DigestAlgorithm 5，MD5)值。

需要说明的是，由于一些用户可能没有开启其对应终端设备上的推送(push)功能，即服务器不能主动下发验证结果和/或第一音频标识，因此，在一些可能的实现方式中，终端设备可以通过轮训的方式获取验证结果，以确定是否验证成功。

终端设备上传初始音频文件后，将进入轮询流程，开始轮询服务器的验证结果。终端设备可以向服务器发送轮询请求，轮询请求用于向服务器请求验证结果，验证结果是服务器对目标音频文件中是否存在敏感词进行验证得到的，服务器接收到轮询请求后，向终端设备发送轮询结果，终端设备可以根据轮询结果中包括的验证结果确定语音开场白是否设置成功。其中，轮询过程的详细流程图可以参见图12所示，终端设备每向服务器发送一次轮询请求，可以认为进行一次轮询。

在本实施例中，为了避免由于网络状况不佳等原因，导致长时间的轮询而未获取到验证结果，进而影响语音开场白的设置，可以预先设置轮询最大时长即第二阈值，第二阈值例如可以设置为18秒，以及轮询最大次数即第三阈值，第三阈值例如可以设置为5次。每次轮询的间隔时间并不相同，因为越到后期，越有可能服务器已经结束了验证，所以轮询时间将类似于正弦函数，轮询间隔例如可以为2s、3.5s、6s、3.5s、2s。

在终端设备进入轮询流程后，终端设备向服务器发送轮询请求(参见图12中S1201)，确定轮询时长是否达到第二阈值(参见图12中S1202)，若轮询时长尚未达到第二阈值，则确定轮询次数是否达到第三阈值(参见图12中S1203)，若轮询次数尚未达到第三阈值，终端设备接收都服务器发送的轮询结果，根据轮询结果可以确定服务器是否验证完成(参见图12中S1204)，即若在轮询时长未达到第二阈值，且轮询次数未达到第三阈值的情况下，终端设备可以获取到服务器发送的轮询结果，根据轮询结果中包括的验证结果确定语音开场白是否设置成功。

若轮询时长达到第二阈值，以及轮询次数达到第三阈值，则确定验证失败，上传失败(参见图12中S1205)。

其中，轮询结果的结果类型可以为验证中，即未完成验证，此时返回执行S1201。轮询结果的结果类型还可以是验证完成，此时，服务器向终端设备返回验证结果(参见图12中S1206)，即终端设备接收到服务器发送的轮询结果中包括验证结果，验证结果指示验证通过，上传成功(参见图12中S1207)，否则，执行S1205，结束轮询流程，语音开场白设置失败，并通知第一用户重新上传初始音频文件。

若验证结果指示验证成功，则结束轮询流程，并将本地初始音频文件的MD5与服务器返回的MD5进行比对，如果比对成功则认为开场白已经设置成功。若指示验证成功，但MD5比对失败，则开场白设置失败，并通知服务器清空对应初始音频文件和目标音频文件。至此，完成语音开场白设置的整个流程。

接下来，将结合实际应用场景对本申请实施例提供的语音开场白的生成方法进行介绍。参见图13，标签展示方法包括：

S1301、第一用户打开语音接听助理服务。

S1302、终端设备展示语音开场白创建界面。

S1303、第一用户点击“立即录入”。

S1304、第一用户结束录音，得到初始音频文件。

S1305、第一用户点击“播放”控件试听初始音频文件。

S1306、第一用户点击“提交”控件向服务器提交初始音频文件。

S1307、服务器对初始音频文件进行音频转码压缩得到目标音频文件。

S1308、若服务器对目标音频文件验证成功，根据目标音频文件生成语音开场白并保存。

S1309、终端设备通过轮训从服务器得到指示验证成功的验证结果，语音开场白设置成功。

S1310、当接听到第二用户呼叫第一用户的来电，向第二用户播放该语音开场白。

基于图3对应实施例提供的语音开场白的生成方法，本申请实施例还提供一种语音开场白的生成装置，参见图14，所述装置包括所述装置包括展示单元1401、录制单元1402、生成单元1403和提交单元1404：

所述展示单元1401，用于在语音开场白创建界面中，展示语音录制功能入口；

所述录制单元1402，用于响应于针对所述语音录制功能入口的选择操作，开始录制第一用户的语音；

所述生成单元1403，用于若接收到录制停止指令，根据录制的所述第一用户的语音生成初始音频文件；

所述提交单元1404，用于向服务器提交所述初始音频文件，所述初始音频文件用于确定语音开场白，所述语音开场白用于在接听到第二用户呼叫所述第一用户的来电时，向所述第二用户播放。

在一种可能的实现方式中，所述装置还包括播放单元：

所述播放单元，用于在所述提交单元1404向服务器提交所述初始音频文件之前，接收音频播放指令，向所述第一用户播放所述初始音频文件。

在一种可能的实现方式中，所述录制单元1402，还用于：

在所述播放单元接收音频播放指令，向所述第一用户播放所述初始音频文件之后，接收重新录制指令，重新执行所述开始录制第一用户的语音的步骤。

在一种可能的实现方式中，所述录制停止指令触发条件是录制时长达到第一阈值，或接收到用户针对录制停止控件的触发。

在一种可能的实现方式中，所述装置还包括发送单元和获取单元：

所述发送单元，用于向所述服务器发送轮询请求，所述轮询请求用于向所述服务器请求验证结果，所述验证结果是所述服务器对所述目标音频文件中是否存在敏感词进行验证得到的；

所述获取单元，用于获取所述服务器发送的轮询结果，根据所述轮询结果中包括的所述验证结果确定所述语音开场白是否设置成功。

在一种可能的实现方式中，所述获取单元，用于：

若在轮询时长未达到第二阈值，且轮询次数未达到第三阈值的情况下，获取到服务器发送的轮询结果，则根据所述轮询结果中包括的所述验证结果确定所述语音开场白是否设置成功。

在一种可能的实现方式中，所述获取单元还用于：

获取所述服务器发送的第一音频标识，所述第一音频标识是所述服务器根据所述目标音频文件生成的；

根据所述第一音频标识与根据所述初始音频文件生成的第二音频标识的一致性，确定所述语音开场白是否设置成功。

基于图9对应实施例提供的语音开场白的生成方法，本申请实施例还提供一种语音开场白的生成装置，参见图15，所述装置包括获取单元1501、生成单元1502、验证单元1503和确定单元1504：

所述获取单元1501，用于获取终端设备提交的初始音频文件，所述初始音频文件是所述终端设备根据第一用户的语音录制得到的；

所述生成单元1502，用于对所述音频文件进行音频转码压缩，得到符合播放条件的目标音频文件；

所述验证单元1503，用于验证所述目标音频文件中是否存在敏感词，得到验证结果；

所述确定单元1504，用于若验证结果指示验证通过，将所述目标音频文件作为语音开场白，所述语音开场白用于在接听到第二用户呼叫所述第一用户的来电时，向所述第二用户播放。

在一种可能的实现方式中，所述装置还包括返回单元：

所述返回单元，用于向所述终端设备返回所述验证结果，所述验证结果用于指示所述终端设备是否重新录制所述第一用户的语音。

在一种可能的实现方式中，所述生成单元1502还用于：

根据所述目标音频文件生成第一音频标识；

所述返回单元，还用于向所述终端设备返回所述第一音频标识。

在一种可能的实现方式中，所述装置还包括清除单元：

所述清除单元，用于若所述验证结果指示验证失败，清除所述目标音频文件。

本申请实施例还提供了一种设备，该设备用于语音开场白的生成。下面结合附图对该设备进行介绍。请参见图16所示，本申请实施例提供了一种设备1600，该设备1600还可以是终端设备，以终端设备为智能手机为例：

图16示出的是与本申请实施例提供的终端设备相关的智能手机的部分结构的框图。参考图16，智能手机包括：射频(英文全称：Radio Frequency，英文缩写：RF)电路1610、存储器1620、输入单元1630、显示单元1640、传感器1650、音频电路1660、无线保真(英文全称：wireless fidelity，英文缩写：WiFi)模块1670、处理器1680、以及电源1690等部件。本领域技术人员可以理解，图16中示出的智能手机结构并不构成对智能手机的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

存储器1620可用于存储软件程序以及模块，处理器1680通过运行存储在存储器1620的软件程序以及模块，从而执行智能手机的各种功能应用以及数据处理。存储器1620可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等；存储数据区可存储根据智能手机的使用所创建的数据(比如音频数据、电话本等)等。此外，存储器1620可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。

处理器1680是智能手机的控制中心，利用各种接口和线路连接整个智能手机的各个部分，通过运行或执行存储在存储器1620内的软件程序和/或模块，以及调用存储在存储器1620内的数据，执行智能手机的各种功能和处理数据，从而对智能手机进行整体监控。可选的，处理器1680可包括一个或多个处理单元；优选的，处理器1680可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，调制解调处理器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器1680中。

在本实施例中，所述终端设备1600中的处理器1680可以执行以下步骤；

在语音开场白创建界面中，展示语音录制功能入口；

响应于针对所述语音录制功能入口的选择操作，开始录制第一用户的语音；

若接收到录制停止指令，根据录制的所述第一用户的语音生成初始音频文件；

向服务器提交所述初始音频文件，所述初始音频文件用于确定语音开场白，所述语音开场白用于在接听到第二用户呼叫所述第一用户的来电时，向所述第二用户播放。

用于语音开场白的生成的设备还可以包括服务器，本申请实施例还提供服务器，请参见图17所示，图17为本申请实施例提供的服务器1700的结构图，服务器1700可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上中央处理器(CentralProcessing Units，简称CPU)1722(例如，一个或一个以上处理器)和存储器1732，一个或一个以上存储应用程序1742或数据1744的存储介质1730(例如一个或一个以上海量存储设备)。其中，存储器1732和存储介质1730可以是短暂存储或持久存储。存储在存储介质1730的程序可以包括一个或一个以上模块(图示没标出)，每个模块可以包括对服务器中的一系列指令操作。更进一步地，中央处理器1722可以设置为与存储介质1730通信，在服务器1700上执行存储介质1730中的一系列指令操作。

服务器1700还可以包括一个或一个以上电源1726，一个或一个以上有线或无线网络接口1750，一个或一个以上输入输出接口1758，和/或，一个或一个以上操作系统1741，例如Windows ServerTM，Mac OS XTM，UnixTM,LinuxTM，FreeBSDTM等等。

在本实施例中，所述服务器1700中的中央处理器1722可以执行以下步骤；

获取终端设备提交的初始音频文件，所述初始音频文件是所述终端设备根据第一用户的语音录制得到的；

对所述音频文件进行音频转码压缩，得到符合播放条件的目标音频文件；

验证所述目标音频文件中是否存在敏感词，得到验证结果；

若验证结果指示验证通过，将所述目标音频文件作为语音开场白，所述语音开场白用于在接听到第二用户呼叫所述第一用户的来电时，向所述第二用户播放。

本申请实施例还提供一种计算机可读存储介质，所述计算机可读存储介质用于存储程序代码，所述程序代码用于执行前述各个实施例所述的语音开场白的生成方法。

本申请实施例还提供一种包括指令的计算机程序产品，当其在计算机上运行时，使得计算机执行前述各个实施例所述的语音开场白的生成方法。

本申请的说明书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例例如能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-Only Memory，简称ROM)、随机存取存储器(Random Access Memory，简称RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术成员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。

Claims (15)

1.一种语音开场白的生成方法，其特征在于，所述方法包括：

在语音开场白创建界面中，展示语音录制功能入口；

响应于针对所述语音录制功能入口的选择操作，开始录制第一用户的语音；

若接收到录制停止指令，根据录制的所述第一用户的语音生成初始音频文件；

向服务器提交所述初始音频文件，所述初始音频文件用于确定语音开场白，所述语音开场白用于在接听到第二用户呼叫所述第一用户的来电时，向所述第二用户播放。

2.根据权利要求1所述的方法，其特征在于，所述向服务器提交所述初始音频文件之前，所述方法还包括：

接收音频播放指令，向所述第一用户播放所述初始音频文件。

3.根据权利要求2所述的方法，其特征在于，所述接收音频播放指令，向第一用户播放所述初始音频文件之后，所述方法还包括：

接收重新录制指令，重新执行所述开始录制第一用户的语音的步骤。

4.根据权利要求1-3任一项所述的方法，其特征在于，所述录制停止指令触发条件是录制时长达到第一阈值，或接收到用户针对录制停止控件的触发。

5.根据权利要求1-3任一项所述的方法，其特征在于，所述方法还包括：

向所述服务器发送轮询请求，所述轮询请求用于向所述服务器请求验证结果，所述验证结果是所述服务器对所述目标音频文件中是否存在敏感词进行验证得到的；

获取所述服务器发送的轮询结果，根据所述轮询结果中包括的所述验证结果确定所述语音开场白是否设置成功。

6.根据权利要求5所述的方法，其特征在于，所述获取服务器发送的轮询结果，根据所述轮询结果中包括的所述验证结果确定所述语音开场白是否设置成功，包括：

若在轮询时长未达到第二阈值，且轮询次数未达到第三阈值的情况下，获取到服务器发送的轮询结果，则根据所述轮询结果中包括的所述验证结果确定所述语音开场白是否设置成功。

7.根据权利要求5所述的方法，其特征在于，所述方法还包括：

获取所述服务器发送的第一音频标识，所述第一音频标识是所述服务器根据所述目标音频文件生成的；

根据所述第一音频标识与根据所述初始音频文件生成的第二音频标识的一致性，确定所述语音开场白是否设置成功。

8.一种语音开场白的生成方法，其特征在于，所述方法包括：

获取终端设备提交的初始音频文件，所述初始音频文件是所述终端设备根据第一用户的语音录制得到的；

对所述音频文件进行音频转码压缩，得到符合播放条件的目标音频文件；

验证所述目标音频文件中是否存在敏感词，得到验证结果；

若验证结果指示验证通过，将所述目标音频文件作为语音开场白，所述语音开场白用于在接听到第二用户呼叫所述第一用户的来电时，向所述第二用户播放。

9.根据权利要求8所述的方法，其特征在于，所述方法还包括：

向所述终端设备返回所述验证结果，所述验证结果用于指示所述终端设备是否重新录制所述第一用户的语音。

10.根据权利要求8或9所述的方法，其特征在于，所述方法还包括：

根据所述目标音频文件生成第一音频标识；

向所述终端设备返回所述第一音频标识。

11.根据权利要求8或9所述的方法，其特征在于，所述方法还包括：

若所述验证结果指示验证失败，清除所述目标音频文件。

12.一种语音开场白的生成装置，其特征在于，所述装置包括展示单元、录制单元、生成单元和提交单元：

所述展示单元，用于在语音开场白创建界面中，展示语音录制功能入口；

所述录制单元，用于响应于针对所述语音录制功能入口的选择操作，开始录制第一用户的语音；

所述生成单元，用于若接收到录制停止指令，根据录制的所述第一用户的语音生成初始音频文件；

所述提交单元，用于向服务器提交所述初始音频文件，所述初始音频文件用于确定语音开场白，所述语音开场白用于在接听到第二用户呼叫所述第一用户的来电时，向所述第二用户播放。

13.一种语音开场白的生成装置，其特征在于，所述装置包括获取单元、生成单元、验证单元和确定单元：

所述获取单元，用于获取终端设备提交的初始音频文件，所述初始音频文件是所述终端设备根据第一用户的语音录制得到的；

所述生成单元，用于对所述音频文件进行音频转码压缩，得到符合播放条件的目标音频文件；

所述验证单元，用于验证所述目标音频文件中是否存在敏感词，得到验证结果；

所述确定单元，用于若验证结果指示验证通过，将所述目标音频文件作为语音开场白，所述语音开场白用于在接听到第二用户呼叫所述第一用户的来电时，向所述第二用户播放。

14.一种设备，其特征在于，所述设备包括处理器以及存储器：

所述存储器用于存储程序代码，并将所述程序代码传输给所述处理器；

所述处理器用于根据所述程序代码中的指令执行权利要求1-11任一项所述的方法。

15.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质用于存储程序代码，所述程序代码用于执行权利要求1-11任一项所述的方法。

Images