【翻译】音游开发速成:音频导入设置(作者:5argon)
【文章原载于https://exceed7.com/native-audio/rhythm-game-crash-course/import-settings.html,授权翻译转载,再次转载请联系原作者获取授权。】
【系列文章目录】
音游开发速成(概论)
背景音轨
游戏设计与制谱
四类音频应用程序
音频导入设置【本文】
与DSP同步
来自Bemuse作者的提示
音频导入设置

及其对音游的意义。
格式
您会注意到有PCM、Vorbis和ADPCM三种可选格式。用Vorbis就行,因为PCM格式的音乐体积大得飞起……
质量
质量设置为100有些过高。您可以在Vorbis格式下选择质量,我认为大多数普通玩家不会注意到40-100之间的差异。实际上您可以把质量调得非常低,我相信Cytus 1所有歌曲的质量都在15-35左右。(这只是一个猜测!请记住,如果别人有无损的wav音频源,而您只有192kbps的音频源,那么您的15-35将不会表现得那么好。)您可能会在试听时觉得这听起来太差了,就像是对最初创作它的曲师的一种冒犯。但是!……如果您对所有歌曲都采用这种质量设置,玩家就不会注意到这首歌的质量很差,哈哈!
VOEZ和Dynamix的歌曲质量更好,因为游戏将通过互联网下载这些歌曲,并能够随意删除和重新下载,所以这些游戏的创作者不必关心应用程序的大小。(如果您有足够的资金来为所有玩家架设一个服务器,那就可以采用这种做法。但如果您不能以足够快的速度扭亏为盈,就存在被服务器成本拖垮的风险。)Deemo的音乐质量也非常糟糕,我猜它是10-25左右。如果您比较一下Deemo和VOEZ的Like Asian Spirit这首歌,将会立刻注意到从外部下载的音频和程序内捆绑的音频(被迫节约存储空间)之间的质量差异。Deemo那一版的高频部分听起来更“暗”,就像被低通软滤波器处理过一样。
质量设置还取决于音乐流派。对于电子感很强的歌曲,您可以将质量设置得非常低而不被注意到。但原声(acoustic)歌曲通常必须设置在25-50左右才能听起来比较好(比如原声吉他在低质量下听起来明显很差)。这是因为原声歌曲的高频区很清晰,几乎没有其他东西干扰。我建议对每首歌曲分别设置质量,不断降低质量并试听,直到听上去不太好为止。请您在降低质量时注意频谱的高频区,因为听感将首先在这里恶化。它将变得更“模糊”,就像您在收听广播时逐渐把频道调整到范围之外。我发现听感恶化的重要步骤通常发生在这些区间内:[100-40] [39-25] [24-20] [19-10] [9-0],取值较高时很难注意到差异。
加载类型
选择内存中压缩(Compressed in memory)、加载时解压(decompress on load)还是音频流(streaming)?本文假定您知道这三个选项的根本区别。音频流可能很诱人,因为整个播放过程中只使用到非常非常少的内存,这可以节约您的内存资源,并且神奇的是音频流几乎没有加载时间。但音频流也有问题。
audioClip.LoadAudioData可以进行阻塞调用,从而确保在游玩前的“加载中”界面里完整地加载音频,这是确保您的精确启动计划顺利推进的正确“准备”。但这种方法不且仅不适用于音频流,只要您选择加载时解压或内存中压缩,它将适用于各种PCM和Vorbis。
所以您的游戏并不会等待加载完成,而是会立即开始。因为从本质上讲,音频流不存在“加载”这一概念,它认为加载是立即完成的(我认为实际上它只加载了一小部分,而不是整个音频)。您的玩家可能会抱怨每次重开时的偏移量并不相同,通常情况下第一次游玩时偏移量比较差,而后面的重开会更好一些。但如果重开时设备发生卡顿,偏移量将重新变差,因为音频流无法以任何方式等待加载。我很确定在对音频流执行LoadAudioData之后,audioClip.loadState会立即被置为Loaded,但实际上它并没有加载完成,因此您无法等待加载。
但音频流在音游中的最大优势表现在音乐选择界面。您可以滚动浏览所有音乐,并非常快速地播放预览音乐。使用其他加载类型将不得不让玩家等到歌曲完全加载后才能听到预览音乐。或者您必须为预览音乐添加独立的音频资源,可将之设置为音频流以尽快预览,并且可以将其质量降到更低。而真正在游玩中使用的那个音频资源可设置为内存中压缩,并具有更高的质量。但预览音乐的独立音频资源会使您的游戏变得更大。预览音乐的平均时长可能在10秒左右,如果1分钟的压缩音频大约是1MB,那么您需要为100首歌曲付出大约16MB的空间代价。
我注意到Dynamix和Tone Sphere这两款游戏中,预览音乐的质量比您在游玩中听到的音乐更低。可能这些游戏正在使用这种将预览独立于实际音频的技术。您可以使用PCM格式导入音效,其加载时间最短但文件尺寸较大;或者使用Vorbis + 加载时解压,其加载时间稍长、尺寸较小且解压后的结果是原始PCM。音效的体积并不大,所以您可能会选择PCM,但对于较长的音效(如吹奏号角和较长的风声环境音),您可能会用到Vorbis+ 内存中压缩。
但如果您真的想用音频流来在音乐选择界面中兼得尽快预览和最优质量(和游玩中一致),而且不想被迫为每首歌添加两段音乐,那应该怎么办?当我们不能依赖audioClip.LoadAudioData时,我处理偏移量变化问题的方法是在0音量下将音频播放1-2秒作为热身,然后重新开始真正播放。这是确保音频流已经加载的唯一方法,即实际播放一下。当您再次播放它(真正播放)时,有可能寄希望于缓冲区中仍然保存了同一段音频数据(但这仍然不是100%可靠)。
采样设置
您可以在Unity音频导入器中选择重采样或保持原采样。我认为这并不重要,因为我在Android平台上发现(https://gametorrahod.com/android-native-audio-primer-for-unity-developers):在Unity将所有音频混音到一个总线上之前,这些音频都会被重采样到24000 Hz(我不清楚其他平台上情况如何)。但我认为您可以通过降低采样率来减少导入的体积。(不确定这种做法是否会影响【译注:此处的动词在原文为chipmunk,不确定具体意义,或许源于某种meme?】您的声音表现,因为低采样率下您所导入的数据更少,但播放头是否会根据这份更少的数据来减慢消耗数据的速度呢?)