紧急车辆警报器声音数据集构建：采集、清洗与识别模型训练

简介：面向深度学习音频分类与紧急车辆识别任务，这份3秒波形音频数据集涵盖救护车、消防车警报声及纯交通噪声三个类别，每类各200段wav文件，并配套由每个音频转换得到的声谱图图像，适合用于训练车辆警报检测、环境声音分类等模型。数据集共1203个文件，其中600个wav音频、600个png声谱图、3个python转换脚本，压缩包大小约281.76MB，目录结构清晰，可直接基于脚本批量生成与扩展样本。目前已有294人学习下载，适合相关方向研究者、学生以及智能交通、自动驾驶场景下的算法工程师使用。借助声谱图与原始波形两种形式，可灵活用于CNN、ResNet等图像分类模型或LSTM等序列模型实验，省去自行采集与预处理时间，便于快速聚焦模型调参和方案对比。

1. 紧急车辆警报器声音数据集：先把“鸣笛声”从城市噪声里分出来

城市环境里最容易被乘客感知、却最难被机器识别的声音，就是紧急车辆的警报器声。车载麦克风距离声源往往有几十米，道路噪声、风噪和旁边车的发动机声混在一起，救护车的警笛实际是一种周期性扫频信号，进入麦克风后却像被埋进噪声里的一段模糊频谱。做一个紧急车辆警报器声音数据集，本质上是把这种信号从环境声音里剥离出来，让模型学会的不是“这是鸣笛声”，而是“这是一辆正在执行任务的车辆，方向和距离需要被估计”。这个标题下的读者通常是做自动驾驶感知、智能座舱安全提醒、路侧感知或城市声学监测的工程师，而数据集的质量直接决定识别模型能否在实车上站稳脚跟。下面按从录音素材到模型验证的完整链路来拆解。

2. 紧急车辆警报器声音数据集的原始素材与格式选型

2.1 录音方案里的采样率、声道与信噪比取舍

先定录音设备和使用场景。车载场景建议用 16kHz 采样率、单声道就够了，因为警报器主能量集中在 500Hz 到 3500Hz 之间，16kHz 采样率对应的奈奎斯特频率是 8kHz，完全覆盖警报器基频和主要谐波，还能把文件体积和后续特征提取的计算量压下来。路侧固定监测节点可以用 48kHz 立体声，方便事后做波束形成或声源定位分析，但要注意，两声道的相位差如果没用上，反而会在特征阶段引入冗余计算。

信噪比是比采样率更重要的指标。同一辆救护车在 10 米和 50 米外录制，整体响度差 20dB 以上，如果只用单一信噪比的素材训练，模型在远场场景几乎必然漏检。所以录音方案里要刻意覆盖三个距离档位：近距离（5-10 米）、中距离（20-30 米）、远距离（50 米以上）。每段录音同时记录 GPS 坐标和车头朝向，方便后续按距离和入射角度做分桶评估。

2.2 标注格式：整段打标与事件级时间戳

数据集下载到手后，最常见的标注格式有两种：整段打标和事件级时间戳。整段打标指每条音频文件只带一个类别标签，比如 siren_ambulance、siren_fire_truck、no_siren，适合做粗粒度分类；事件级时间戳则记录每一段警报声的起止时间，例如 start=12.5s, end=18.3s, type=ambulance，适合做检测和定位。紧急车辆警报器的实际需求属于后者，因为模型输出不仅要回答“有没有警报声”，还要告诉下游模块“声音从第几秒开始出现”。

从训练角度看，事件级时间戳可以直接切成短片段当分类样本用，也可以保留完整上下文做序列标注，灵活性比整段打标高得多。推荐用 JSON Lines 格式作为主标注文件，每行一个事件：

{"audio": "rec_2024_06_01_0930.wav", "duration": 60.0, "events": [{"start": 12.5, "end": 18.3, "label": "ambulance"}, {"start": 41.0, "end": 47.2, "label": "fire_truck"}]}

逻辑说明：顶层记录音频文件名和总时长，events 数组里是警报事件的时间区间和类别。这样设计的好处是，后续做数据清洗时只修改 events 字段而不影响音频文件本身；做训练集划分时也可以按事件去重，避免同一辆车的声音在训练集和测试集里同时出现。

2.3 一个可复现的素材整理脚本

录完素材后，第一步不是急着标注，而是先做一轮格式统一。下面的脚本遍历原始目录，读取每个 wav 的采样率、声道数、时长和峰值电平，输出一个 manifest.csv：

import os import csv import wave def scan_audio_dir(src_dir, out_csv): rows = [] for root, _, files in os.walk(src_dir): for fname in files: if not fname.lower().endswith('.wav'): continue path = os.path.join(root, fname) with wave.open(path, 'rb') as wf: params = wf.getparams() n_frames = params.nframes framerate = params.framerate sample_width = params.sampwidth channels = params.nchannels duration = n_frames / framerate rows.append({ 'path': path, 'sr': framerate, 'channels': channels, 'duration': round(duration, 3), 'peak_db': 0 }) with open(out_csv, 'w', newline='') as f: writer = csv.DictWriter(f, fieldnames=rows[0].keys()) writer.writeheader() writer.writerows(rows) scan_audio_dir('raw_recordings', 'manifest.csv')

逻辑说明：用wave模块读取头部信息，不需要把整段 PCM 数据载入内存。scan_audio_dir遍历目录时只收.wav后缀文件，输出字段里sr和channels用来筛掉不符合规格的录音，duration用来过滤过短或过长的文件。peak_db 这一列先置 0，下一轮清洗时再回填。

参数说明：如果你的素材里有.flac或.mp3，需要换成soundfile库的sf.info()读取，返回值里有samplerate和frames字段，逻辑一致。注意.mp3存在编码延迟，时长会有几十毫秒误差，做事件级时间戳时不要用压缩格式。

3. 数据清洗与平衡：警报器数据集里的标签噪声和样本分布

3.1 标签噪声的三大来源

紧急车辆警报器数据集的标签噪声比普通环境声音数据集更隐蔽。第一个来源是混叠：城市里改装车的低音炮、大型卡车气刹声、甚至某些电动公交的电机提示音，频率范围都能覆盖警报器的主频段，标注员很容易把非警报声标成警报声。第二个来源是远场弱信号：50 米外的救护车警报声和风声混在一起，人耳能勉强听到，但标注时无法确定精确的起止时间，导致事件边界漂移几百毫秒。第三个来源是标注工具的对齐误差：用 Web 标注工具拖动进度条时，鼠标松开的一瞬间和音频实际播放位置之间常有 200-500ms 的偏差。

对比一下音频数据集和图像数据集在清洗上的差异：yolov8 训练自己的数据集时，检查的是边界框是否超出图像范围、类别是否填错；音频数据集检查的则是时间戳边界是否落在静音区、事件长度是否短到不合理的程度。清洗逻辑完全不同，不能套用。

3.2 用能量检测做第一轮过滤

推荐先做一层全自动过滤：对每条录音按 50ms 分帧计算 RMS 能量，找出能量明显低于全片平均值的区域，再和标注事件做重叠判断。如果标注事件与能量低谷区间的重叠比例超过 30%，说明该条标注大概率有问题，进入人工复核队列：

import numpy as np import soundfile as sf def rms_envelope(audio, frame_len=0.05, hop_len=0.025): sr = audio.shape[0] frame_n = int(frame_len * sr) hop_n = int(hop_len * sr) n_frames = (len(audio) - frame_n) // hop_n + 1 env = [] for i in range(n_frames): segment = audio[i * hop_n : i * hop_n + frame_n] env.append(np.sqrt(np.mean(segment ** 2))) return np.array(env), hop_n audio, sr = sf.read('rec_2024_06_01_0930.wav') env, hop_n = rms_envelope(audio) threshold = np.percentile(env, 20) low_energy_ratio = np.mean(env < threshold)

逻辑说明：rms_envelope按 50ms 帧长、25ms 帧移计算能量包络，返回的能量序列长度约为duration / 0.025。阈值取能量分布的 20 分位数，low_energy_ratio表示整段录音中处于低能量区域的时间比例。如果全程有超过一半时间处于低能量，说明这段录音要么麦克风灵敏度有问题，要么录制距离太远导致有效信号基本丢失。

参数调整建议：阈值分位数可以按录制场景调整。车内静态录音建议 20 分位数；路侧动态录音风噪大，可以放宽到 30 分位数，但要注意放宽后会把部分弱警报事件也误判为噪声区。

3.3 按事件去重划分训练、验证和测试集

划分数据集时只按文件名切分会造成严重的实验污染。同一辆救护车从你车旁经过，录下来可能是连续 3 分钟的一条 wav，如果这条 wav 被切成 30 条 6 秒的片段，其中一部分进了训练集、另一部分进了测试集，模型实际上是在记忆这段路的路况噪声模式，而不是在识别警报器。正确做法是：先按录音文件分组，同一录音的所有片段必须全部落在同一个集合里。

更严格的方案是按声源分桶。如果录音时记录了 GPS 或车辆编号，就按事件级联关系把同一辆车的声音归到同一个 group_id，按 group_id 做 GroupShuffleSplit。这样测试集里的警报声来源在训练阶段完全没见过，评估出来的准确率才接近线上效果。

4. 特征提取与增强：MFCC 和梅尔谱的参数怎么定

4.1 为什么不让模型直接吃原始波形

原始波形直接输入模型在理论上可行，但实际训练时有两个问题：一是采样点之间的时间依赖关系太长，轻量 CNN 需要堆很深的层才能捕捉到扫频信号的周期性；二是波形域的平移不变性差，同样的警报声起点偏移几百个采样点，CNN 的特征响应就会错位。梅尔频谱把 16kHz 的信号压缩成 64 或 128 个频率槽，既保留了警报器的谐波结构，又把输入维度降了一个数量级，是声音事件检测任务里更稳妥的起点。

对于警报器识别，MFCC 的反而是次优选择。MFCC 的 DCT 去相关操作会丢掉部分谐波细节，而警报器扫频特征恰恰依赖基频和次谐波之间的相对关系。直接用 log-mel 频谱比 MFCC 更适合这个任务。

4.2 特征参数表与具体代码

在 torch 生态里，torchaudio提供了完整的特征提取管线。下面是推荐参数和对应代码：

import torch import torchaudio def audio_to_mel(path, sr=16000, n_fft=1024, hop=320, n_mels=128): waveform, sample_rate = torchaudio.load(path) if sample_rate != sr: resampler = torchaudio.transforms.Resample(sample_rate, sr) waveform = resampler(waveform) if waveform.shape[0] > 1: waveform = torch.mean(waveform, dim=0, keepdim=True) mel_spec = torchaudio.transforms.MelSpectrogram( sample_rate=sr, n_fft=n_fft, hop_length=hop, n_mels=n_mels, power=2.0 )(waveform) log_mel = torch.log(mel_spec + 1e-6) return log_mel

逻辑说明：torchaudio.load返回的waveform形状是[channels, samples]，先检查采样率是否匹配，不匹配就用Resample做重采样；多声道数据直接取平均，避免训练时把声道信息当成有效特征。MelSpectrogram 输出的形状是[channels, n_mels, time]，加1e-6是为了防止零值取对数产生负无穷。

4.3 时序增强：噪声叠加和速度扰动

警报器数据集的场景增强有两个方向。一是加环境噪声：用城市道路噪声作为背景，按 5 到 15dB 的随机信噪比叠加到干净警报声上，模拟不同距离和车窗开闭状态。二是做速度扰动：警报器的扫频周期本身有差异，救护车和消防车的音调变化速率不同，把同一段警报声的采样率改成 0.9x 和 1.1x，相当于让模型见过更多扫频律动。

注意数据泄露问题。增强时用的城市噪声文件如果和测试集来自同一段录音，会让评估结果虚高。噪声库要单独准备，和警报器录音素材来源完全隔离。

5. 模型选型与训练流程：从轻量 CNN 到预训练模型

5.1 选型起点：小模型先跑通，再考虑预训练

对紧急车辆警报器识别来说，模型的首要约束是延迟。车载或路侧设备的推理预算通常在 50ms 以内，所以模型参数量控制在几百万级别比较合适。一个四层卷积的轻量 CNN 就能跑通基线，每层卷积后接 BatchNorm 和 ReLU，最后用全局平均池化替代 Flatten，减少过拟合。

如果手头的数据量不足，比如事件级标注样本不到 5000 条，用 AudioSet 预训练模型做迁移学习是性价比更高的路线。常见做法是加载预训练的torchaudio.models.Wav2Letter或ASTModel，冻结前几层卷积，只微调最后两层和分类头，训练轮数可以压缩到 2 个小时以内。

5.2 训练配置与关键超参

训练时的数据加载器要做在线增强，每轮迭代对同一个样本生成不同的噪声版本，这比离线生成增强数据集省磁盘空间，也不容易让模型记住增强模式。

5.3 评估不能只看准确率

分类任务的准确率在警报器识别里是误导性指标。背景类（无警报声）往往占 80% 以上，模型全输出“无警报”就能拿到 80% 准确率，但对急救场景毫无意义。正确做法是报告事件级召回率和每小时的误报次数，并单独按距离分桶统计。

代码里常用滑窗 + 后处理来把片段级预测转成事件级结果。滑窗长度与训练输入一致，均采用 3 秒，每次滑动 1 秒，保证相邻窗口有重叠、事件边界的预测不会被生硬切开。后处理用一个简单的滞回机制：只有连续 3 个窗口都预测为警报才触发事件，事件结束要连续 2 个窗口预测为无警报才终止。这套逻辑可以消除单帧抖动造成的误报。

def sliding_infer(model, log_mel, win_len=300, hop_len=100, threshold=0.7): model.eval() n_frames = log_mel.shape[-1] preds = [] for start in range(0, n_frames - win_len + 1, hop_len): segment = log_mel[:, :, start:start + win_len] with torch.no_grad(): prob = torch.sigmoid(model(segment.unsqueeze(0))) preds.append((start / 100.0, prob.item())) return preds

逻辑说明：输入 log_mel 的最后一维是时间帧，win_len=300对应 3 秒（每帧 10ms），hop_len=100对应 1 秒滑动步长，返回的preds是一个包含“中心时间戳和警报概率”的列表，供后续滞回判断使用。

6. 在设备端验证警报器识别效果的三个关键动作

拿到一个训练好的紧急车辆警报器声音数据集模型，最先做的不是堆指标，而是拿着真实场景数据去做盲测。车载场景里把录音设备放在前挡风玻璃下方，路侧场景则放在灯杆或路侧单元上，连续录制 1 个小时以上，再人工标注这段真实录音的事件区间，与模型输出做对齐。这个验证的动作要优先于调模型，因为它能揭示训练集与真实环境的分布差异，比如车内空调风声、轮胎压过减速带的声音，这些都会造成特征偏移。

验证时重点关注误报集中在哪些非警报声音上。如果误报多来自金属碰撞声，说明模型在频率硬度上还没有分清警报器扫频与突发噪声的本质区别；如果误报多来自远处汽笛声，说明事件级时序特征利用得不够。

此外，在部署端对输出做平滑处理是性价比最高的优化手段。滞回阈值从 0.7 调到 0.8，误报率往往能下降一半；代价是部分弱信号的召回率降低 2-3 个百分点。对急救场景，宁可多报警不可漏报，阈值取向低值，但对输出加一条去抖动逻辑，同一事件 10 秒内不重复触发，减少对驾驶员的干扰。

最后一个实践技巧是给模型留一个“未知声音”的拒识出口。在分类层之外增加一个能量异常检测分支，当输入声音的频谱结构与所有已知类别都匹配不上时，输出 low confidence 而不是强行归类，这样的模型在真实部署时更稳定。

本文还有配套的精品资源，点击获取