线性加权导致听感机械且易损扬声器，因人耳对响度感知呈非线性，指数或正弦平方曲线更自然；还需防范采样率换算错误、通道错位及整型饱和等实现细节问题。
淡入淡出为什么不能直接线性加权？
直接用 for (int i = 0; i 做线性淡入，听起来会“咔哒”或“噗”一声——人耳对幅度变化敏感，线性 ramp 在低电平段变化太慢、高电平段又太陡，导致瞬态失真。真正可用的淡入淡出必须满足：起始/结束处一阶导数为 0（即平滑衔接静音），否则会引入高频杂音。
推荐用正弦平方（sin²）或多项式实现平滑过渡
最常用且计算开销低的是 sin² 形式：淡入段第 i 个采样点权重为 sin(PI/2 * i / fade_len) * sin(PI/2 * i / fade_len)；淡出则用 sin(PI/2 * (fade_len - i) / fade_len)²。它在 i=0 和 i=fade_len 处导数均为 0，过渡自然。
- 若需更高阶连续性（如避免极低频调制），可用
i³*(3-2*i)（归一化到 [0,1] 的三次贝塞尔），但sin²对绝大多数音频已足够 - fade_len 至少取 20ms（44.1kHz 下约 882 个采样点），低于 5ms 容易听出截断感
- 务必确保 fade_len ≤ 音频总长度，否则越界访问
audio[i]导致崩溃或静音异常
C++ 实现时要注意采样格式与缓冲区边界
淡入淡出必须作用于原始 PCM 数据，且要区分有符号整型（如 int16_t）和浮点型（如 float）处理方式：前者需先转 float 做乘法再裁剪回范围，否则溢出失真。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
for (int i = 0; i < fade_len; ++i) {
float gain = sinf(M_PI_2 * i / fade_len);
gain *= gain; // sin²
float sample = static_cast<float>(pcm16[i]) / INT16_MAX;
pcm16[i] = static_cast<int16_t>(sample * gain * INT16_MAX);
}- 使用
sinf()而非sin()，避免 double 转换开销 - INT16_MAX 是 32767，不是 32768 —— 符号位占一位，这个细节漏掉会导致最大值削波
- 如果音频是 interleaved stereo（左右声道交叉存储），需对每个声道单独应用 fade，即步长为 2，而非逐采样点操作
淡出段容易覆盖错误导致静音失效
常见错误是把淡出起点设成 len - fade_len 后，循环写成 for (int i = 0; i 却用 <code>pcm[i + start]，结果实际只处理了后半段——但更隐蔽的问题是：当 fade_len 接近总长时，start 可能为负，或 i + start >= len，此时必须截断。
立即学习“C++免费学习笔记（深入）”；
- 安全写法：淡出起始索引
start = std::max(0, len - fade_len)，循环上限取std::min(fade_len, len - start) - 不要复用淡入的 gain 表——淡出增益序列是反向的，硬拷贝或 reverse 会多一次内存遍历，直接算
sin²(M_PI_2 * (fade_len - 1 - i) / fade_len)更快 - 若音频带 metadata（如 ID3），淡入淡出只改 PCM 数据，别动 header 或 padding 区域
真正麻烦的从来不是公式本身，而是采样率不匹配时 fade_len 换算错误、立体声通道错位、以及整型饱和裁剪没做对——这些地方一出错，声音就不是“淡”，而是“炸”。
