测试是软件开发的一个组成部分。无论是在开发过程中的代码测试,还是当代码成为整个产品一部分时的结果测试,其重要性对工程师们来说都不言而喻。而对于具有独特性质的音频来说更是如此,这意味着它将给工程师带来特殊的测试挑战。
可以通过代码行并排比较来评估软件的质量和错误,但人们却不能通过同时聆听两组音频来进行音质评估,而必须采用顺序聆听。故音频的比较不仅更困难,也更耗时。而且,由于预期结果可能会引起分歧,从而会使评估工作变得更加复杂。另外,对声音的感知因人而异,这也意味着,不同的客户以及不同的最终用户,都不可避免地对“好声音”有不同的定义。
那么,应该如何通过利用音频评估软件,以使最终产品获得输出好声音的最佳机会呢?
主观与客观评估
也许这个问题的根源在于主观评估和客观评估之间的差异。两者在测试音频方面都很重要,但二者需要极为不同的技术。主观评估是让人去辩听声音,然后给出他们的反应。对于主观评估而言,要么是利用某种打分系统来获得定量结果,要么是通过表达是否喜欢而得到定性结果。客观评估则不同,而是需要通过专门设计的算法对声音进行录音,然后根据预先确定的各种指标进行评判,最后给出一个综合分数。
主观评估和客观评估,哪个更好?答案是,两者都有其用武之地,也都有明显的优缺点。
也许人们可能会认为:“主观评估是音频测试的黄金标准,所以,如果真的有人喜欢你的软件所产生的声音,那么你就会大功告成,你的产品就会受到所有人的喜爱。”真的吗?实际远非如此简单!
首先,需要决定由谁来对音频进行评估。当然可以选择“专家听众”,这类听众在聆听音频方面接受过培训并具有采用行业标准来评估音质的专业能力。他们会给出详细的反馈,这是非常有用的,可以帮助调整和改善音频输出。专家听众知道他们要找什么,并能帮助发现一般人几乎肯定听不出来的问题,比如瑕疵和失真等。
专家听众的局限性
但这里也有一个风险,那就是产品的最终用户大都不是专家级听众,而是普通消费者。普通消费者通常没有受过听力训练,也许对音质评估技术方法不甚了解。然而,他们却知道自己喜欢什么!而让他们愉悦的声音很可能与一组专家听众“认可”的声音相当不同。另外值得提醒的是,取悦最终用户的声音,对工程师自己来说可能也不是那么好听。所以,只利用专家小组进行评估,也许能获得很高的分数,但最终结果可能导致一个没有人真正想要的产品。
另一方面,如果由公众来对音频进行评估,就需要考虑执行什么样的测试协议。例如,可以考虑采用由国际电信联盟(ITU)等机构为正式听觉测试制定的某种协议,或者可以开发私有协议。采用标准协议可以使测试在客户中具有可信度;开发和采用私有测试协议,可能更适合于特殊的使用情况。无论哪种情况,重要的是,要通过观察统计学上的结果,来避免出现解释性问题。
还需要决定谁会参加听音小组,要记住每个人对音频的听觉感受是不同的,而且随着听者年龄的增长,聆听高频的能力也会有所下降。再就是,能招募到多少人?要得到一个合理的结果至少需要10人。那么,是否会招募有某种程度听力障碍的人?如果是的话,听力障碍是什么程度?这里的决策取决于是组建针对一种类型听众的测试小组,还是尝试组建一个包括具有广泛听力类型听众的小组。如果正在开发一种助听产品,那么在测试小组中拥有听力障碍者将是至关重要的。然而,可能无法招募到很多有听力障碍的人。克服这一限制的方法是,给每个人提供一系列具有不同可调参数选择的选项,要求小组成员对每个选项进行评分。
评估质量和可懂度
无论测试小组由什么人组成,都应该要求小组成员评估音频的两个不同方面:音质和可懂度。音质与整体用户体验有关:听起来是舒服还是不舒服?而可懂度指的是,用户在不费力听的情况下,能正确理解多少语义。当设置可调参数时,可能要在这两者之间进行权衡。
例如,可以通过提高某些频率来使某些东西更易懂,这可能会牺牲频率响应的平坦性。平坦的频率响应使音频听起来就像在房间里与人交谈一样,而可懂度的调整可能会减少噪声,从而使音频听起来更有处理过的痕迹。还有降噪问题。对于降噪而言,降噪越狠,就越是会引入明显的副作用,比如在声音里出现“抽气音”。
最后,一些参数调整可能还与产品的使用性能有关,例如涉及电池寿命。用缩短电池寿命来换取音频性能的有限提高是否值得?听力小组会告诉工程师该走哪条路。
当计划采用主观评估时,需要做出的最后决定是选择在什么环境下进行测试。是在线测试还是线下测试?当然,在线是最容易组织的,因为用户在家里就可以参与,而且测试只需要给他们播放用软件处理过的音频。如果是线下测试,是在可以控制背景噪音的实验室这类受控环境中进行测试,还是把产品带到现实世界,让用户在产品实际应用场景中进行测试?其实两者都有自己的定位,并不相互排斥。最佳的做法是先进行受控测试,然后,可能是最后阶段,再把产品带到现实环境中测试。
客观测试的性能指标
放弃主观测试,而采用客观测试,能克服这些问题吗?答案是肯定的!的确能克服其中一些问题。但客观评估也有自己的问题。客观测试完全省去了真人测试,当采用那些算法处理音频时,测试会输出数字得分。通过这些软件算法来测试音频,比招募真人听众更容易,并能能快速了解音频的哪个变体更好。目前常用的指标可以分为性能指标和可懂度指标。前者包括信号失真比(SDR)和信号干扰比(SIR);而后者则包括短时客观可懂度(STOI)、语音质量的感知评估(PESQ)以及感知性客观听觉质量分析(POLQA)。
本质上,所有这些指标都具有“易侵扰”性,这意味着它们需要一个 “真实数据” 即时记录以及处理后的实际结果。在计算这些指标时,采用真实的源映像是公认可接受的做法。因此,无论选择哪种方法,其过程实际上都是一样的,具体如下:
在低噪音环境中,通过对阵列中每个声源作单独记录来创建真实数据,过程中应使其他所有环境因素尽可能保持不变。
通过对各个源映像进行人为混合,创建出一个混合结果。通常,在动态范围内,麦克风的线性度是非常高的,因此只要能避免出现削波和非常小的量化值,所得结果将安全可靠,与实际相近似。
用算法处理混合映像。
通过算法输出和真实数据记录的比较,就可以计算出想要的性能指标。
在采用这些指标进行客观评估时,要记住下面这些要点:
真实数据需要与处理后的版本在时间上保持对齐。即使是几毫秒的差异,也会损害测量结果。因此考虑到处理延迟因素,需要重新调整真实数据的源映像。
像咖啡馆的咿呀声是扩散性的,应该在多个扬声器上进行模拟。最好是利用两倍于麦克风数量的扬声器来模拟。
在繁忙的咖啡馆等地方,所录制的真实世界的咿呀声,可以来验证利用模拟散射噪音所获得的性能。
在一部分(至少有)源映像录音中利用真人是个好主意,因为人与扬声器的特性不同,一般来说不太像一个点声源。
可以改变混合比例,将测试数据集的实用性扩展到不同的声学场景中。
处理一些在现场录制的完整混合的录音,并通过听觉测试,验证人工混合所给出的性能与真实世界是否相当。
然而,从这些指标的名字就可以看出,每一个指标测试都针对特定类型的音质或失真。因此就引出这样的问题,即:如果改变算法以改善某个指标的结果,就可能会连带引起另一个指标得分的改变。所以采用这些测试结果来提高某特定指标的得分,有可能使音频输出整体上听起来不是工程师或客户想要的结果。于是,就需要考虑不同指标的相对重要性,以及它们在产品实际使用环境中的适用性。
最后却又非常重要的是,基于机器学习的这些模型,具有所有已知的、事关训练集限制的问题。例如,有些模型只用英语进行了训练,这将限制其对其他语言的音频进行准确预测的能力。
总之,音频测试的成功与否,与所做出的许多决定有关,包括测试类型、测试环境和实际执行测试人员等方方面面。为了能做出正确的决定,把音频评估看作是在不同环境下、由不同测试组成的层次结构是很有帮助的。
音频测试计划
在整个开发周期过程中,测试应该从下到上,通过图1所示的层次结构,从内部测试直到与现实世界中的最终用户合作。但并不一定需要执行每个阶段列出的所有评估。选择产品最适合的测试,并牢记上述考虑因素。
图1:音频评估可以被视作为不同环境中各种不同层次的测试:测试过程应该是从下到上、从内部测试到与现实世界中的最终用户合作。(来源:AudioTelligence)
不过,在开始之前,就如何进行音频测试、以及大家认为什么是好的结果,工程师应确保与客户达成一致。他们会用自己的指标来衡量音频吗?他们会要求自己的最终用户小组来听吗?如果客户不同意测试方法,不喜欢最终的声音,那么工程师自己认为最终音频究竟有多好,就不那么重要了。
首先,测试将由工程师在内部完成。当代码还在开发中时,可以采用自动的音质评估。有许多不同的算法可用于评估音质,它们或多或少都有点复杂。一旦有了这些评估得出的合理结果,下一步就是准备在产品中使用的阵列上进行录音,并用软件对它们进行处理。确保团队中有尽可能多不同的人,来听取结果并给予反馈。然后,当有了第一条生产线原型,就可以用这些原型来重复这个测试了。
在这之后,还需要考虑外部测试。这里的层次从发送录音给受过训练的听众,转移到了让受过训练的听众在受控环境中进行测试,再转移到在专门的测试环境中用真人进行测试。同样,这些测试不一定需要全部执行:从发送录音给受过训练的听众,直接到在测试环境中用真人进行测试,有时可能就足够了。
真实世界的测试在测试层次结构中处于顶端,因为它可以说是所有测试中最重要的。但在这个层次上的成功,取决于产品至少经历了下面的一些测试阶段。不能通过直接进入真实世界测试来开发一个音频产品,因为在开发的早期阶段,需要做可重复的测试,也只有在这个阶段,才有可能对环境进行控制。
本文小结
考虑各种不同的音频评估方法以及测试的各种环境,可能会让人感到应接不暇。为了克服测试音频软件所带来的挑战,重要的是要记住最终目标:产品能够输出最终用户认为足够好的声音,才能确保产品的商业成功。记住这个目标,把测试过程分成几个阶段。并在开始着手工作之前,根据需要,选定软件开发的每个阶段中最合适和最有用的测试方法。不要忘记,所有这些测试所花的时间,将不可避免地比所想象的要长,故应在任何的项目计划中,确保为测试留出足够的时间。
(参考原文:how-to-assess-audio-software-to-enhance-sound-quality)
本文为《电子工程专辑》2023年11月刊杂志文章,版权所有,禁止转载。点击申请免费杂志订阅