北京
一个YouTuber在发布前最怕什么？不是波形看起来不够"大"，而是导出的文件到了另一个平台上直接翻车。响度、峰值余量、削波、直流偏移，这四个指标回答的是四个不同的问题，但大多数创作者只盯着其中一个看。
Creator Audio Pre-Publish Health Check 这个工具做的事情很直接：把这几项测量放在一起，让创作者在上传之前就能发现明显的问题。它的目标用户是YouTuber、播客剪辑师和音乐人，定位是一个快速的浏览器端预检工具，而不是替代母带电平表。真正有价值的地方在于：这些测量值是怎么算出来的，以及为什么一个绿色的结果仍然需要结合上下文来判断。
先解码，再逐样本检查
上传入口接受音频和视频的MIME类型，另外还支持FLAC、OGG和OPUS扩展名。分析流程从读取文件开始：把选中的文件读成ArrayBuffer，在48kHz下创建AudioContext，然后调用decodeAudioData。
解码完成后，代码用getChannelData收集每一个声道。直流偏移只从第零个声道计算，但削波检查会覆盖所有声道。削波的判定阈值非常接近归一化的0 dBFS上限，这是一个样本级的削波指标，适合用来发现平顶的数字音频，但它不能证明模拟环节或编解码器永远不会产生失真。
界面上的"True Peak"其实是最大解码样本
分析器会在所有声道中搜索绝对值最大的样本，然后把这个振幅转换成分贝值。界面上把这个值标为"True Peak"，并建议保持在-1.0 dBTP或以下。对于有损编码来说，这是一个实用的安全目标。
但实现上测量的是最大解码样本，它没有做超采样，也没有重建样本间峰值。这个区别在跟专业真峰值表对比时很关键。一个文件可以通过这个浏览器检查，但在格式转换之后仍然暴露出样本间峰值。
LUFS走的是离线滤波通道
响度计算方面，calcLufs会构建一个OfflineAudioContext，最多复制两个声道到缓冲区，然后让它们通过两个Biquad滤波器：一个高架滤波器，频率1681.974，增益3.999843853；一个高通滤波器，频率38.13547，Q值0.5003270373。
渲染完滤波后的缓冲区，对样本平方取平均，返回-0.691加上10乘以meanSquare的对数。这个结果是对ITU-R BS.1770风格K加权积分响度的近似。平台对比则使用配置好的目标值：
- YouTube和Spotify：-14 LUFS
- Apple Music：-16 LUFS
- 播客：-16 LUFS，容差更宽
- Instagram、TikTok、Facebook：-14 LUFS
- EBU R128：-23 LUFS
状态逻辑刻意做得简单。-16到-12 LUFS之间标记为良好，低于-24是警告，中间区域是超限。这让预检界面变得可操作，同时平台卡片会展示不同的目标和容差选择。
结果对象还会保留时长、声道数和采样率，跟主要指标放在一起。这些字段不是装饰：一个意外的声道数可以解释响度不匹配，采样率则告诉你浏览器实际解码成了什么。进度值只是界面检查点，不是剩余CPU时间的测量——读取前是5，缓冲区加载后是20，解码后是50，分析完成是100。所以一个很长的文件在离线渲染还在跑的时候，看起来像是卡住了。
发布前需要知道的诚实边界
所有东西都在浏览器里运行，但解码一个长时、多声道的文件仍然需要内存来容纳完整的AudioBuffer和一次离线渲染。浏览器可能拒绝一个编解码器，即使它的扩展名看起来是支持的，catch块只会报告一个通用的解码失败。这个工具不会归一化或修复文件，它只测量解码后的数据。
直流偏移从第一个声道计算，当绝对平均值达到0.01时会被标记。削波是达到或超过阈值的样本百分比，不是按持续时间加权的感知测量。最重要的一点是：LUFS滤波和样本峰值计算可能跟DAW不一致，原因包括浏览器精度、采样率行为、声道处理方式，以及缺少真峰值超采样。这个报告用来决定下一步该检查什么，然后还需要在专用电平表上交叉核对播出或发行母带。
我把这套实现做成了一个小型免费工具：Creator Audio Pre-Publish Health Check。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
