LeventureTecTips

IIR 与 FIR 濾波器对音频相位的影响 先前我有写过一个简单的文章分析过两种滤波器对音频相位的影响，但是我只是知其然不知其所以然。对于音频，我虽然知道相位是一个很重要的概念，但是我始终不知道相位对实际音频的印象是什么水平的。这个问题在这些年的开发过程中始终萦绕在心头。虽然不做音频了，但是我仍然对这个问题保持好奇，综上，这也是为什么有了这个文章。 一、从一个问题开始 假设我们有一个 1kHz 的正弦信号，经过一个低通滤波器之后，输出还是 1kHz 的正弦信号，幅度变小了——这很好理解，滤波器嘛，该衰减的衰减。 但仔细看输出波形，会发现它相对于输入信号产生了一个时间上的延迟。这个延迟不是简单的"整体往后挪了 N 个采样点"，而是不同频率的信号延迟不一样。 1kHz 的信号延迟了 0.5ms，500Hz 的信号延迟了 0.8ms，2kHz 的信号延迟了 0.3ms——每个频率成分的延迟都不一样。 这就是相位失真。 对于音频处理来说，这个问题比听起来严重得多。人耳对相位差的感知不如幅度那么直接，但当不同频率成分的延迟差异大到一定程度时，会导致： 瞬态信号（比如鼓点、齿音）的波形被"模糊化" 立体声声像偏移 某些频段的"堆叠"或"空洞" 所以，理解滤波器的相位特性，是做音频处理的基本功。 先说结论，IIR 的相位响应受幅度响应约束（最小相位特性），无法独立控制；FIR 可以独立控制幅度和相位，因此能实现线性相位或任意指定相位。 但是至于为什么音频行业常用IIR滤波器，这个问题我将在补充后说明。 二、先回顾一下：FIR 和 IIR 是什么 FIR（有限脉冲响应） FIR 滤波器的差分方程： $$y[n] = \sum_{k=0}^{M} b_k , x[n-k]$$ 输出只依赖于当前和过去的输入，没有反馈。脉冲响应是有限长的（长度 M+1）。 IIR（无限脉冲响应） IIR 滤波器的差分方程： $$y[n] = \sum_{k=0}^{M} b_k , x[n-k] - \sum_{k=1}^{N} a_k , y[n-k]$$ 输出同时依赖于输入和过去的输出（反馈）。脉冲响应理论上是无限长的。 两者的核心区别在于有没有反馈。这个结构上的差异，直接决定了它们的相位特性。 三、相位响应的推导 从频率响应说起 一个 LTI（线性时不变）系统的频率响应可以写成： ...

Minecraft 工业2 实验版核反应堆计算 强化学习模块训练路径 最近在玩Minecraft IC2 Classic，但是对于摆核反应堆总是感觉不是很得心应手，不管怎么摆效率都很低，为了解决这个问题，所以我写了一个强化学习的模块，让神经网络自己去学习如何摆弄这个网络。 不过看了下，IC2 Classic 的核反应堆因为似乎不涉及中子流，所以任务是比较简单的，为了节目效果，我准备研究一下IC2 experiment版的核电站，这个玩起来更有趣，学习的深度也更深。 任务简单分为三步： 明确任务目标和行为 搭建网络 训练 一、任务目标和行为指南 这一步往往是比较重要的，因为这一步决定了AI到底要学什么，以及怎么学。 1.1 问题定义 IC2E的核反应堆设计本质上是一个组合优化问题。你有一个9×6的网格，54个位置，每个位置可以放18种不同的组件（包括空槽位）。理论上有18^54种可能的配置，这个数字大到宇宙中的原子都数不过来。 但问题是，这些配置里99.99%都是垃圾——要么发电量低得可怜，要么直接爆炸。我们要找的是那0.01%既能高效发电，又不会炸的设计。 1.2 核反应堆的物理机制 在开始训练之前，得先搞清楚IC2E核反应堆到底是怎么工作的。不然AI学出来的东西可能完全不符合物理规律。 核脉冲机制： 燃料棒工作时会向四周发射核脉冲 相邻的燃料棒接收到核脉冲后，发电量会成倍增加 中子反射板可以把核脉冲反射回去，相当于"虚拟"的燃料棒 举个例子，一个单铀棒（U）： 单独放置：发电5 EU/t 旁边有1个燃料棒：发电10 EU/t 旁边有2个燃料棒：发电15 EU/t 旁边有4个燃料棒：发电25 EU/t 所以燃料棒越密集，发电效率越高。但问题来了—— 热量产生机制： 燃料棒产生的热量跟相邻的燃料棒/反射板数量有关，公式是： 热量 = 倍数 × (n+1) × (n+2) 其中n是相邻的燃料棒或反射板数量（0-4）。 这个公式很狠，是二次增长的。比如单铀棒（倍数=2）： n=0（孤立）：2×1×2 = 4 HU/tick n=1（1个邻居）：2×2×3 = 12 HU/tick n=2（2个邻居）：2×3×4 = 24 HU/tick n=4（4个邻居）：2×5×6 = 60 HU/tick 看到没？发电量是线性增长（5→25），但热量是二次增长（4→60）。这就是核反应堆设计的核心矛盾：你想要高功率，就得承受高热量。 散热系统： 热量如果散不出去，反应堆温度就会一路飙升，到10000 HU就爆炸。所以必须有足够的散热系统： 散热片（H）：自身散热6 HU/tick 反应堆散热片（R）：从堆温吸热5 HU/tick，然后自己散热5 HU/tick 高级散热片（A）：自身散热12 HU/tick 超频散热片（O）：自身散热20 HU/tick 还有热交换器，可以在组件之间转移热量，把热量从燃料棒转移到散热片上。 ...

前言 项目上遇到了double类型数据精度问题，嵌入式开发和算法争论了一会有关double和float的精度问题，究竟是强转造成的精度损失更多，还是在计算的过程中精度损失更多？这个问题很显然是使用float在计算过程中造成的精度损失更多，但是面对这样的问题，不能只靠猜测，而是需要进行一系列量化的测算。 IEEE754标注中的浮点数表达公式 $$ value = (-1)^{sign} \times 2^{exponent} \times (1 + mantissa) $$ 其中，sign为符号位，exponent为指数位，mantissa为尾数位。 float float类型通常占用4个字节（32位）的内存。具体分配如下： 符号位（Sign bit）：1位 指数位（Exponent）：8位 尾数位（Fraction/Mantissa）：23位 内存布局示例 假设我们有一个单精度浮点数3.14，它的二进制表示如下： 符号位：0 指数位：10000000 尾数位：10010001111010111000011 0 10000000 10010001111010111000011 double 符号位（Sign bit）：1位 指数位（Exponent）：11位 尾数位（Fraction/Mantissa）：52位 内存布局 假设我们有一个双精度浮点数3.14，它的二进制表示如下： 符号位：0 指数位：10000000000 尾数位：1001000111101011100001010001111010111000010100011110101110000101 float与doule之间的转换 float转double 这种转换称为扩展转换（promotion），因为double有更多的位数来表示数字。 1.内存模型变化： float使用32位存储，而double使用64位存储。 在将float转换为double时，计算机会将float的值复制到double的尾数部分，并扩展指数部分。 由于double的尾数部分更长，可以精确表示的有效数字更多，所以这种转换通常不会损失精度。 2.转换过程 符号位保持不变。 指数位从float的8位扩展到double的11位，计算机会根据需要调整指数的偏移量。 尾数位从23位扩展到52位，不足的部分用0填充。 double 转 float 这种转换称为缩减转换（narrowing），因为float有较少的位数来表示数字。 1. 内存模型变化： double使用64位存储，而float使用32位存储。 在将double转换为float时，计算机会将double的值截断或舍入以适应float的尾数部分和指数部分。 由于float的尾数部分较短，这种转换可能会损失精度。 2.转换过程 符号位保持不变。 指数位从double的11位缩减到float的8位，计算机会调整指数的偏移量，并可能会进行舍入。 尾数位从52位缩减到23位，超出的部分会被截断或舍入，这可能导致精度损失。 这里需要注意的是，在C++中，并不是做了简单的截断，而是做了舍入操作，这也是为什么我们在实际操作中，可以观测到逢7进1 例子： float转换double 假设我们有一个float值3.14： float: 0 10000000 10010001111010111000011 ...

ONNX - 它到底快在哪，又慢在哪 一、ONNX 是什么 ONNX（Open Neural Network Exchange）本质上是一种模型的中间表示格式（IR），类似于编译器里的 LLVM IR。 用 PyTorch 训练完一个模型之后，模型的计算逻辑是用 Python 描述的，跑推理的时候要经过 Python 解释器、PyTorch 的调度器、再到底层的 CUDA kernel。这条链路很长，开销不小。ONNX 做的事情是：把模型的计算图从 PyTorch 的世界里"导出"成一个独立的、与框架无关的静态计算图，然后交给专门的推理引擎（比如 ONNX Runtime）去执行。 打个比方：PyTorch 训练出来的模型像一份 Python 脚本，每次执行都要解释器逐行翻译；ONNX 导出后的模型像一份编译好的二进制文件，直接跑就行。 一个典型的 ONNX 文件（.onnx）里面存的是： 计算图的拓扑结构（哪些算子、怎么连接） 每个算子的类型和参数（Conv、MatMul、Relu 等） 模型的权重（以 protobuf 格式序列化） 输入输出的 shape 和数据类型 这里要注意一点：ONNX 本身只是一个格式规范，它不负责执行。真正跑推理的是 ONNX Runtime（简称 ORT）或者其他兼容 ONNX 的推理引擎（TensorRT、OpenVINO 等）。说"用 ONNX 加速"，实际上是"用 ONNX Runtime 加速"。 二、ONNX Runtime 为什么能快 理解了 ONNX 是什么之后，关键问题来了：为什么换个引擎跑就能快？ 2.1 去掉了 Python 开销 PyTorch 推理时，即使模型本身的计算是在 GPU 上跑的，Python 层面仍然有大量开销： ...

从 HiFi-GAN 到 NSF-HiFi-GAN：声码器学习笔记 本文基于 RVC（Retrieval-based Voice Conversion）项目的实际代码，从零开始梳理 HiFi-GAN 声码器的原理，再过渡到 RVC 中真正使用的 NSF-HiFi-GAN 变体。 代码位置：infer/lib/infer_pack/models.py 和 infer/lib/infer_pack/modules.py 一、先搞清楚声码器在干什么 在语音合成或语音转换的流程里，声码器处在最后一环。它的上游会输出某种"中间表示"——可能是 mel 频谱图，也可能是某个隐空间的向量。声码器要做的事情就一件：把这个中间表示变回可以听的音频波形。 说得直白点：频谱图是一张"图"，声码器要把这张图"念"出来。 传统做法（Griffin-Lim 之类的）靠数学迭代来恢复相位信息，结果通常比较糊。HiFi-GAN 走的是神经网络的路线——用一个生成器直接输出波形采样点，同时用判别器来监督生成质量。 二、HiFi-GAN 的基本结构 HiFi-GAN 的论文是 2020 年发的（Jungil Kong 等人），核心思路可以用一句话概括： 转置卷积做上采样，残差块做波形精炼，多尺度判别器做质量监督。 2.1 生成器的整体流程 在 RVC 的代码里，标准 HiFi-GAN 生成器对应的是 Generator 类（models.py:204）。它的结构其实很规整： HiFi-GAN 生成器结构（40kHz 配置为例） ┌─────────────────────────────────────────────────────────────┐ │ 输入：隐变量 z │ │ [batch, 192, T帧] │ └────────────────────┬────────────────────────────────────────┘ │ ▼ ┌────────────────────┐ │ 预处理卷积层 │ │ Conv1d(192→512) │ ← 把输入投射到高维空间 │ kernel_size=7 │ └────────┬───────────┘ │ ┌────────────┴────────────┐ │ 上采样 Stage 1 (×10) │ │ ConvTranspose1d(512→256)│ ← 时间轴拉长到 T×10 └────────┬─────────────────┘ │ ┌────────┴──────────────────────────────────┐ │ MRF (多感受野融合) │ │ ┌──────────┐ ┌──────────┐ ┌──────────┐│ │ │ResBlock │ │ResBlock │ │ResBlock ││ │ │kernel=3 │ │kernel=7 │ │kernel=11 ││ │ └──────────┘ └──────────┘ └──────────┘│ │ 输出取平均 │ └────────┬──────────────────────────────────┘ │ ┌────────┴────────────┐ │ 上采样 Stage 2 (×10)│ │ ConvTranspose1d(256→128)│ ← 时间轴拉长到 T×100 └────────┬─────────────┘ │ ┌────────┴──────────────────────────────────┐ │ MRF 融合 │ │ ResBlock×3 (kernel=3/7/11) → 平均 │ └────────┬──────────────────────────────────┘ │ ┌────────┴────────────┐ │ 上采样 Stage 3 (×2) │ │ ConvTranspose1d(128→64)│ ← 时间轴拉长到 T×200 └────────┬─────────────┘ │ ┌────────┴──────────────────────────────────┐ │ MRF 融合 │ │ ResBlock×3 (kernel=3/7/11) → 平均 │ └────────┬──────────────────────────────────┘ │ ┌────────┴────────────┐ │ 上采样 Stage 4 (×2) │ │ ConvTranspose1d(64→32) │ ← 时间轴拉长到 T×400 └────────┬─────────────┘ │ ┌────────┴──────────────────────────────────┐ │ MRF 融合 │ │ ResBlock×3 (kernel=3/7/11) → 平均 │ └────────┬──────────────────────────────────┘ │ ┌────┴────────────┐ │ 后处理卷积层 │ │ Conv1d(32→1) │ ← 压缩到单声道 │ kernel_size=7 │ └────┬─────────────┘ │ ▼ ┌────────────┐ │ Tanh │ ← 限幅到 [-1, 1] └─────┬──────┘ │ ▼ ┌──────────────────┐ │ 输出波形 │ │ [batch, 1, T×400]│ └──────────────────┘ 上采样的总倍率 = 10 × 10 × 2 × 2 = 400。这个数字等于 hop_length（帧移），含义是：输入的每一帧对应输出的 400 个采样点。对于 40kHz 采样率来说，一帧就是 10ms。 ...

RVC结构简介 推理流程 输入音频 (16kHz) │ ▼ ┌─────────────────┐ │ HuBERT │ 提取内容特征，输出256维(v1)或768维(v2) └────────┬────────┘ │ ▼ ▼ ┌─────────────────┐ │ F0 Extractor │ 提取基频，支持RMVPE/CREPE/Harvest/PM └────────┬────────┘ │ ▼ ▼ ┌─────────────────┐ │ Index Search │ 可选，用faiss做音色检索，混合特征 └────────┬────────┘ │ ▼ ▼ ┌─────────────────┐ │ Synthesizer │ VITS架构，生成目标音色波形 └────────┬────────┘ │ ▼ 输出音频 (32k/40k/48k) Synthesizer结构 主类是SynthesizerTrnMs256NSFsid（v1）和SynthesizerTrnMs768NSFsid（v2），区别只在输入维度。 SynthesizerTrnMs*NSFsid ├── enc_p (TextEncoder) │ ├── emb_phone: Linear(256/768 → hidden) │ ├── emb_pitch: Embedding(256, hidden) # pitch量化到256级 │ ├── encoder: Transformer Encoder │ └── proj: Conv1d → (mean, log_var) │ ├── flow (ResidualCouplingBlock) │ └── 4层 ResidualCouplingLayer + Flip │ 每层内部是WaveNet结构 │ ├── dec (GeneratorNSF) │ ├── m_source (SourceModuleHnNSF) │ │ └── SineGen: 根据F0生成正弦激励信号 │ ├── conv_pre │ ├── ups: 多级上采样 (ConvTranspose1d) │ ├── resblocks: HiFiGAN残差块 │ └── conv_post │ └── emb_g: Embedding(spk_num, gin_channels) # speaker embedding 推理时的数据流： ...

GTCRN 演进路径 记录 v1 → v2 → v3 → v3.1/v3.2 → v4 → v4.1 的改动和原因。 版本概览 版本 改动点 参数量 质量指标 内存 实时 v1 baseline 基线 139K DNSMOS 3.15 — × v2 transient 换损失函数 139K DNSMOS 3.15 — × v3 causal 因果化改造 145K DNSMOS 2.98 — √ v3.1 precision KD + QAT 压缩 41.6K PESQ 2.041 228 KB (INT8) √ v3.2 transient 宽度1.5× + 瞬态损失 ~83K PESQ ~2.15 ~355 KB (INT8) √ v4 network opt 架构精简 (4层GTConv) ~87K PESQ 2.147 683 KB (FP32) √ v4.1 int8 INT8 混合精度 C 推理 ~87K PESQ 2.037 464 KB √ 网络结构 (v1/v2 共用) 输入 spec (B, 513, T, 2) │ ├─ 可学习频带权重 (513,) │ ▼ ERB_48k.bm(): 513 → 219 │ 低频171保留，高频342→48 ERB band │ ▼ SFE_Lite: DWConv(1×5) → PWConv → BN │ ▼ ┌─ Encoder ─────────────────────────────┐ │ DSConv: 219→110 (stride=2) ← skip1 │ │ DSConv: 110→55 (stride=2) ← skip2 │ │ GTConvLite×6 (d=1,2,4,8,4,2) ← skip3-8 │ SubbandAttention │ └───────────────────────────────────────┘ │ ▼ DPGRNN_Enhanced × 2 │ intra: 双向GRU (频率轴) │ inter: 单向GRU (时间轴) │ ▼ ┌─ Decoder ─────────────────────────────┐ │ GTConvLite×6 + skip (逆序) │ │ DSDeconv: 55→110 + skip2 │ │ DSDeconv: 110→219 + skip1 │ └───────────────────────────────────────┘ │ ▼ ERB_48k.bs(): 219 → 513 │ ▼ CRM掩码 → 输出 GTConvLite 内部 x → DWConv(3×3, dilation) → PWConv → BN → PReLU → TRALite (时序注意力) → SEBlock (通道注意力) → + x (残差) DPGRNN 内部 x (B,C,T,F) → reshape (B*T, F, C) → Linear → 双向GRU (频率轴) → Linear → reshape + LayerNorm → reshape (B*F, T, C) → Linear → 单向GRU (时间轴) → Linear → reshape + LayerNorm → 输出 v1 → v2: 换损失函数 问题 v1 用的是标准 SpecRIMAGLoss，对所有帧一视同仁。但实际听感上，键盘敲击、鼠标点击这类突发噪音处理得不好。DNSMOS 是整段平均，掩盖了这个问题。 ...

GTCRN-Light v3 技术说明书 0. 扼要（Executive Summary） GTCRN-Light v3（以下简称 v3）是在原生 GTRCN 基础上进行的等价轻量化实现：完整保留“ERB→SFE→Encoder（频轴两次 /2）→DPGRNN（intra→inter）→Decoder（镜像+跳连）→ERB⁻¹→复域 CRM”的主干数据流与功能语义，通过算子级设计收缩参数与 MACs，同时增强形状稳定性与工程可部署性。 核心收益： 结构等价：无语义重构、无路径删减；对齐原版的时/频建模顺序与接口。 计算瘦身：卷积 DW-Separable 化、RNN 低秩瓶颈、门控去 RNN 化、ERB 固定权重化。 工程稳态：严格的频轴上/下采样闭环（33→65→129），对齐安全，易于导出与部署。 1. 设计目标与边界（Design Goals & Constraints） 不改变 GTRCN 的任务假设与编解码语义：复域 CRM、ERB 子带、频轴二次下采样、DPGRNN（先 intra 后 inter）、镜像解码与跳连。 降低参数与 MACs，但不牺牲 DPGRNN 的双路径长程/跨频建模。 形状稳定：频轴整数对齐，杜绝奇偶差累积；跳连前天然同维。 部署友好：避免难以量化/导出的算子（极小化状态化 RNN、减少不必要的线性层）。 2. 与原生 GTRCN 保持一致的“架构不变量” 数据流： (B,F,T,2) → [|S|, Re, Im] → ERB(bm) → SFE → Encoder(freq /2 ×2) → DPGRNN(intra→inter) → Decoder → ERB(bs) → CRM × S(复域) 采样策略：ERB 后 F=129；编码两次在频轴 /2：129→65→33；解码反向：33→65→129（确保 33→65→129 的闭环）。 时/频耦合：瓶颈处严格遵循 intra-(per time, across F) → inter-(per freq, across T) 的双路径顺序。 输出语义：预测 CRM（实/虚） 并在复域与输入逐点相乘。 3. 轻量化的四大支柱（Pillars of Lightweighting） 3.1 卷积主干 DW-Separable 化 + 轻量 GT-ConvLite 动机：将 2D 卷积的通道耦合与空间（T/F）卷积解耦，保留感受野与局部子带建模能力的同时，将参数与 MACs 近似按 1/通道数 降低。 ...