列车靶场音频测试：用音乐验证车载广播系统

如果你路过轨道交通研发基地的试验大厅，看到有同事在“列车靶场”里循环播放某首歌，不要觉得那是在摸鱼。那大概率不是娱乐，而是一次车载广播系统的声学验证。

列车靶场，是轨道交通研发领域对半实物仿真测试环境的通俗叫法，和网络安全里的“攻防靶场”逻辑类似：在一个可控、可复现的环境里，对目标系统进行接近真实工况的测试。把音乐送进列车广播系统，听起来很简单，背后要验证的其实是音频链路完整性、声场覆盖效果、紧急广播优先级切换，以及功放和扬声器在动态音乐信号下的真实表现。

这篇文章就把这件事讲透：在列车靶场上放音乐，到底在放什么、为什么要放、怎么放才能拿到有价值的测试结果，以及哪些坑最容易踩。文章会从测试信号原理、环境搭建、测试流程、代码示例到问题排查逐步展开，适合轨道交通行业软件测试工程师、PIS系统集成工程师，以及所有对车载音频测试感兴趣的开发者阅读。

1. 这篇文章真正要解决的问题

先说一个常见误区：很多人以为在车厢里放音乐，就是把音源接上功放，听个响，能出声就算通过。如果只是这种粒度，根本不需要专门搭一个列车靶场。

真正要解决的问题有三个层面。

第一，验证音频链路的完整性。列车广播系统不是一台普通音响，它包含音源设备、编码模块、网络传输、功放、扬声器、紧急广播联动等多个环节。任何一个环节故障，都可能表现为“有声音但声音不对”或者“有些位置有声音，有些位置没有”。

第二，验证声场覆盖和听感效果。车厢是一个狭长、多反射面的声学空间，扬声器的布局、功放功率、音量设置都会影响真实听感。音乐信号因为频谱复杂、动态范围大，比单纯的正弦波更容易暴露声场问题。

第三，验证紧急广播的优先级和打断逻辑。在轨道交通的PIS系统中，紧急广播必须能够打断或覆盖背景音乐。这个逻辑如果只靠模拟信号测试，很难暴露问题。用真实的音乐流做背景，再切入紧急广播，才能验证系统的优先级处理是否符合要求。

所以，在列车靶场上放音乐的本质，不是“试听”，而是用高动态、宽频谱的复合音频信号，对车载广播系统做一次接近真实使用场景的压力验证。

2. 列车靶场与车载广播系统：先理解测试对象

在展开操作之前，有必要把几个概念讲清楚，否则后面看测试流程容易发晕。

2.1 列车靶场是什么

“靶场”这个词在轨道交通行业里并没有严格的教科书定义，但研发和测试团队经常用它指代那类专门用于系统级验证的试验环境。它的核心特点是：

• 环境可控：温度、供电、负载都可以按测试需求调整。
• 可复现：同一个测试用例可以反复执行，结果可以对比。
• 接近真实：车辆的网络拓扑、电源环境、设备安装位置尽可能与量产车一致。
• 便于排查：所有接口都有测试点，出了问题可以快速定位。

在列车靶场里，你可以把一套完整的PIS系统装上台架，接上真实的功放和扬声器，模拟列车运行时的各种工况，然后在驾驶台或者控制中心触发广播，观察整条链路的表现。

2.2 车载广播系统在列车里的位置

车载广播系统通常属于乘客信息系统的一部分，也叫PIS系统。它负责的事情包括：

• 到站自动广播
• 司机对乘客的临时广播
• 紧急广播
• 背景音乐播放
• 与车门、火灾报警等系统的联动

从音频信号流的角度看，一条典型的链路是：

音源（背景音乐文件 / 麦克风 / 紧急广播音频） → 广播控制主机 → 音频编码与分发 → 功率放大器 → 车厢扬声器

在这个链路里，背景音乐属于相对低优先级的音源，而紧急广播拥有最高优先级。测试时需要通过真实的打断操作来确认系统会从“音乐播放状态”切到“紧急广播状态”，并在一段时间后能正确恢复。

2.3 为什么选音乐而不是只选提示音

如果只是为了验证链路通不通，用一段“叮咚”提示音就够了。但工程测试需要更严苛的信号。

音乐信号的特点，是频谱覆盖范围宽、动态范围大、包含瞬态冲击。一首歌里往往同时有低频鼓点、中频人声、高频镲片，这些成分叠加在一起，对功放的峰值功率、扬声器的失真表现、系统的底噪控制都会形成比单频信号更真实的考验。

所以，测试团队在车上放音乐，本质上是在做“复合信号激励下的系统稳定性验证”。

3. 测试信号选择：标准信号与音乐信号如何配合

在音频测试中，标准信号和音乐信号各有各的用途，正确做法是配合使用，而不是只放音乐。

3.1 标准测试信号

标准测试信号包括正弦扫频、白噪声、粉红噪声等。它们的特点是频谱成分明确、可重复、便于量化分析。

• 正弦扫频信号：频率从低到高连续变化，适合测试系统在某个频段是否出现异常谐振或衰减。
• 白噪声：功率谱密度在整个频带上基本平坦，适合快速检查系统是否存在频响突变。
• 粉红噪声：低频能量更多，更接近实际听感，适合做声压级标定和声场均匀性测试。

标准信号的缺点是“太干净”。它们在频域上虽然覆盖全面，但在时间域上没有音乐那种突发冲击，很难让功放瞬间进入大动态工作状态。

3.2 音乐测试信号

音乐信号最大的价值，是能够同时覆盖“客观指标”和“主观听感”两个维度。

从客观角度看，音乐信号中的低频峰值可以检验功放在大功率输出时的稳定性；高频成分可以检验扬声器是否出现明显衰减；人声部分可以检验中频的清晰度。

从主观角度看，最终乘客听到的就是音乐和广播声。如果测试团队在车间里用耳朵听都觉得声音发闷、发破、发虚，那么上车之后效果大概率也不会好。

3.3 两者如何配合

实际项目中更推荐这种配合方式：

• 先用粉红噪声做声压级标定和扬声器一致性检查。
• 再用扫频正弦查找明显的频响异常。
• 最后用音乐片段做整链路的动态验证和主观听感评估。
• 紧急广播测试则单独使用语音广播信号，验证优先级和清晰度。

只有音乐信号，缺了量化指标，问题不好定位；只有标准信号，缺了真实听感，问题不好还原。两条腿走路才是工程化的做法。

4. 环境准备与测试设备

在列车靶场上做音频测试，环境准备比想象中复杂。下面列出一个最小可行环境，供参考。

4.1 硬件环境

• 被测的广播控制主机或PIS系统样机。
• 功率放大器，连接方式尽量与量产车一致。
• 扬声器，最好安装在台架的模拟车厢结构上，或者使用同等规格的扬声器负载。
• 参考麦克风，用于采集扬声器输出的声音信号。
• 声级计，用于现场声压级测量。
• 音频接口或USB声卡，用于将测试电脑的音频信号送入广播主机，同时采集参考麦克风信号。
• 测试电脑，用于播放测试音频和录制回采信号。

4.2 软件环境

以本文的Python示例为例，建议环境如下：

• Python 3.9 及以上版本。
• numpy、scipy：用于信号生成和分析。
• sounddevice：用于音频播放与录制。
• wave、struct：用于读写WAV文件。
• ffmpeg：用于音频格式转换和简单的文件检查。

安装命令：

pip install numpy scipy sounddevice

# 检查Python音频设备 python -m sounddevice

执行后终端会列出当前系统的音频输入输出设备编号，后面写脚本时要用。

4.3 测试前的检查清单

在接好设备之后，先不要急着播放音乐。按下面的清单检查一遍：

• 功放增益是否设置合理，有没有开到最大。
• 扬声器接线是否牢固，有没有反相。
• 参考麦克风位置是否避开了气流和结构振动。
• 紧急广播触发按钮是否在方便操作的位置。
• 测试电脑音量是否设置在安全的范围内。

这一步省不得。很多测试过程中出现的“破音”和“听不清”，其实都是接错线、参数设置不当导致的，不是被测系统本身的问题。

5. 核心测试流程拆解

下面给出一个在列车靶场进行音乐播放测试的通用流程，每个环节都说明目的和容易出错的地方。

5.1 明确测试目标和边界

开始之前，先问自己三个问题：

• 这次测试是为了验证链路是否正常，还是为了评估音质？
• 是针对某一节车厢，还是全列车的广播系统？
• 需不需要同时测试紧急广播的打断逻辑？

目标不同，测试音频的选择、播放时长、采集位置都会不一样。如果只是验证链路，播放20秒音乐足够；如果要做声场均匀性评估，可能需要在多个位置分别测量。

5.2 准备测试音频文件

准备音频文件时，要遵循几个原则：

• 使用WAV格式，避免压缩格式解压带来的不确定性。
• 文件时长控制在30秒到2分钟之间，太长影响测试效率，太短不利于主观判断。
• 文件内同时包含低频、中频、高频内容，尽量选择动态范围大的片段。
• 不要直接使用带DRM保护的在线音乐，避免播放环节引入额外变量。

如果项目中需要可重复的测试样本，建议用程序生成标准信号，并混入一段固定音乐作为合成测试样本，这样每次测试的输入都是一致的。

5.3 接入音频源并播放

音频接入方式取决于广播主机的接口。常见的有模拟音频输入、网络音频流、USB播放。推荐优先使用与量产车一致的接入方式，避免引入不必要的变量。

播放时，建议从较低音量开始，逐步升到目标音量。注意观察功放的CLIP指示灯或保护状态，如果出现频繁的保护动作，应该立即停止，检查功放和扬声器的配置是否匹配。

5.4 同步采集与记录

如果测试目标是验证链路完整性，建议用参考麦克风同步采集扬声器输出。这样后续可以通过对比原始文件和回采文件，判断系统是否存在明显失真、延迟或频响异常。

同步采集时注意：

• 声道数要与测试信号一致。
• 采样率建议不低于44100 Hz。
• 录音电平不要出现过载，否则回采数据本身就失真了。

5.5 记录主观听感

客观数据不能完全替代人的耳朵。每次测试时，至少安排一名测试人员在车厢内的不同位置试听，并记录以下内容：

• 声音是否清晰，有没有破音。
• 中频人声是否自然。
• 高频会不会刺耳。
• 低频有没有明显共振。
• 车厢前中后位置的音量差异是否在可接受范围。

主观记录可以用简单的表格，也可以录一段现场语音备注。

5.6 恢复系统并归档数据

测试结束后，要将系统恢复到测试前状态，包括音量、优先级配置、功放增益等。然后保存原始音频、回采音频、测试记录到统一的归档目录，方便版本回溯。

6. 完整示例：从生成测试音频到自动化验证

下面用Python写一套最小可用的音频测试脚本。它包含三个部分：生成测试音频、播放并同步录制、回采分析。

6.1 生成标准测试音频

这个脚本会生成两个文件：一个是对数扫频正弦，一个是频域法生成的粉红噪声。它们可以作为客观指标测试的输入信号。

# 文件路径：generate_test_audio.py import numpy as np import wave def write_wav(path, data, sample_rate): data = np.clip(data, -1.0, 1.0) pcm = (data * 32767).astype(np.int16) with wave.open(path, 'wb') as wf: wf.setnchannels(1) wf.setsampwidth(2) wf.setframerate(sample_rate) wf.writeframes(pcm.tobytes()) def log_sweep(f0, f1, duration, sample_rate): n = int(sample_rate * duration) t = np.linspace(0, duration, n, endpoint=False) phase = 2 * np.pi * f0 * duration / np.log(f1 / f0) * ( np.exp(t / duration * np.log(f1 / f0)) - 1 ) return np.sin(phase) def pink_noise_fd(duration, sample_rate): n = int(sample_rate * duration) spectrum = np.random.randn(n // 2 + 1) + 1j * np.random.randn(n // 2 + 1) freqs = np.fft.rfftfreq(n, d=1.0 / sample_rate) freqs[0] = 1.0 spectrum = spectrum / np.sqrt(freqs) spectrum[0] = 0.0 sig = np.fft.irfft(spectrum, n) return sig / np.max(np.abs(sig)) * 0.5 sample_rate = 48000 duration = 30 sweep = log_sweep(20, 20000, duration, sample_rate) pink = pink_noise_fd(duration, sample_rate) write_wav("sweep_20_20k.wav", sweep, sample_rate) write_wav("pink_noise_30s.wav", pink, sample_rate) print("生成测试音频完成")

关键点解释：

• 对数扫频让每个倍频程的持续时间相同，适合检查频响异常。
• 粉红噪声用频域法生成，功率谱密度近似1/f，更接近真实听感。
• 输出统一为单声道WAV，避免多声道文件在回放时出现配置问题。

运行方式：

python generate_test_audio.py

生成成功后，应该能在当前目录看到两个WAV文件。

6.2 播放并同步录制

下面这段脚本负责播放测试音频，同时通过参考麦克风采集扬声器的输出。使用sounddevice的playrec函数，可以做到播放和录制的同步。

# 文件路径：play_and_record.py import sounddevice as sd import numpy as np import wave def read_wav(path): with wave.open(path, 'rb') as wf: sample_rate = wf.getframerate() data = np.frombuffer(wf.readframes(wf.getnframes()), dtype=np.int16) data = data.astype(np.float32) / 32768.0 return data, sample_rate def write_wav(path, data, sample_rate): data = np.clip(data, -1.0, 1.0) pcm = (data * 32767).astype(np.int16) with wave.open(path, 'wb') as wf: wf.setnchannels(1) wf.setsampwidth(2) wf.setframerate(sample_rate) wf.writeframes(pcm.tobytes()) AUDIO_FILE = "pink_noise_30s.wav" OUTPUT_FILE = "recorded_output.wav" INPUT_DEVICE = None # 参考麦克风设备编号，先用默认设备 OUTPUT_DEVICE = None # 输出设备编号，可以用默认设备 audio_data, sample_rate = read_wav(AUDIO_FILE) recorded = sd.playrec( audio_data, samplerate=sample_rate, channels=1, input_device_index=INPUT_DEVICE, output_device_index=OUTPUT_DEVICE, ) sd.wait() write_wav(OUTPUT_FILE, recorded[:, 0], sample_rate) print("播放和录制完成，输出文件：", OUTPUT_FILE)

运行前，需要先通过python -m sounddevice查看设备编号。测试环境的参考麦克风通常通过USB音频接口接入，建议单独指定输入设备编号。

这里的“同步”是声音层面的同步：播放音频的同时开始录音。最终得到的回采文件，在时间轴上对应扬声器输出这段音频的声学信号。

6.3 回采分析：检测削波和粗略频谱

回采数据的主要用途有两个：判断系统是否削波失真，以及判断频响是否存在明显异常。

# 文件路径：analyze_recording.py import numpy as np import wave def read_wav(path): with wave.open(path, 'rb') as wf: sample_rate = wf.getframerate() data = np.frombuffer(wf.readframes(wf.getnframes()), dtype=np.int16) data = data.astype(np.float32) / 32768.0 return data, sample_rate def detect_clipping(signal, threshold=0.98): peak = np.max(np.abs(signal)) clipped = peak >= threshold return peak, clipped def rms_db(signal): rms = np.sqrt(np.mean(signal ** 2) + 1e-12) return 20 * np.log10(rms + 1e-12) RECORD_FILE = "recorded_output.wav" signal, sr = read_wav(RECORD_FILE) peak, clipped = detect_clipping(signal) rms_db_val = rms_db(signal) print("峰值：{:.3f}".format(peak)) print("RMS：{:.2f} dBFS".format(rms_db_val)) print("是否接近削波：{}".format("是" if clipped else "否")) # 粗略频谱检查：用FFT计算平均频谱，观察低频段和高频段的能量比例 n = len(signal) window = np.hanning(n) spectrum = np.abs(np.fft.rfft(signal * window)) freqs = np.fft.rfftfreq(n, d=1.0 / sr) def band_energy(spectrum, freqs, f_low, f_high): mask = (freqs >= f_low) & (freqs <= f_high) return np.sqrt(np.mean(spectrum[mask] ** 2)) low_energy = band_energy(spectrum, freqs, 100, 1000) mid_energy = band_energy(spectrum, freqs, 1000, 4000) high_energy = band_energy(spectrum, freqs, 4000, 12000) print("低频能量：{:.3f}".format(low_energy)) print("中频能量：{:.3f}".format(mid_energy)) print("高频能量：{:.3f}".format(high_energy))

这段脚本的价值在于，把测试者的耳朵变成可量化的数据。如果一个扬声器在高频段明显衰减，high_energy数值会比同型号正常扬声器低很多。如果功放增益设置过高，peak值会接近1.0，此时就需要考虑降低音量后重新测试。

6.4 用ffmpeg做文件检查

在播放之前，可以用ffmpeg快速确认测试文件没有损坏：

ffprobe -show_streams -show_format sweep_20_20k.wav

如果只需要简单查看时长和格式，也可以这样：

ffprobe -v error -show_entries format=duration:stream=codec_name,sample_rate -of default=noprint_wrappers=1 sweep_20_20k.wav

7. 运行结果与效果验证

7.1 如何判断测试音频生成成功

运行generate_test_audio.py之后，脚本会打印“生成测试音频完成”。更稳妥的验证方式是用播放器打开文件，听一下扫频的声音是否从低频平滑过渡到高频，粉红噪声是否听起来像持续的“沙沙”声。

7.2 如何判断播放和录制链路正常

录制完成后，先把recorded_output.wav和原始文件简单对比一下。如果录制结果明显偏小或者出现大片削波，说明测试系统的电平设置有问题。

一个简单的判断方法是看分析脚本的输出：

7.3 如何验证紧急广播优先级

在播放背景音乐的状态下，触发一次紧急广播。需要观察以下几点：

• 背景音乐是否被立即切断或明显压低。
• 紧急广播语音是否清晰可懂。
• 紧急广播结束后，系统是否按设计恢复背景音乐播放。
• 整个过程中，功放是否出现保护动作。

这个测试建议至少做三轮：

• 音乐正常播放时触发。
• 音乐音量较高时触发。
• 音乐播放和广播操作几乎同时发生时触发。

三种情况的时序不同，最容易暴露代码里的竞态问题。

7.4 测试结论的记录

每次测试完，建议记录一份结构化的结论，至少包含：

• 被测系统软件版本。
• 测试音频文件名。
• 功放增益设置。
• 参考麦克风位置。
• 主观听感描述。
• 客观数据（峰值、RMS、频段能量）。

这些信息是后续问题回溯的基础。

8. 常见问题与排查思路

在列车靶场上做音频测试，遇到的问题通常集中在几个区域：电平设置、接线方式、扬声器布局、系统优先级逻辑。

这里真正容易踩坑的地方是：很多人遇到破音，第一反应是换更好的扬声器，但更多时候问题出在功放电平设置上。换设备之前，先用脚本采集数据，确认是不是削波，再决定从哪个环节下手。

9. 最佳实践与工程建议

9.1 把测试当作产品来做

一个可重复的音频测试方案，不应该依赖某个人“听了一下觉得没问题”。建议把测试音频、播放脚本、分析脚本、测试记录模板都纳入版本管理，每次软硬件版本变更之后，跑同一套流程，对比数据变化。

9.2 标准信号和音乐信号分开归档

标准信号用于量化对比，音乐信号用于主观听感。两者不要混为一谈。归档时建议建立以下目录：

audio_test/ case/ generate_test_audio.py signals/ sweep_20_20k.wav pink_noise_30s.wav music_sample_a.wav results/ 20250120_ai_build/ recorded_output.wav test_log.md

这样的目录结构，在项目后期回溯问题时非常有用。

9.3 注意紧急广播测试的安全边界

紧急广播属于安全相关功能，测试时必须在授权环境下进行。在运营线路上随意播放背景音乐或触发紧急广播，会造成严重的运营风险。所有测试都应限定在靶场台架或下线车辆上进行，并且测试前要确认系统没有接入真实运营网络。

9.4 音量标准不要拍脑袋

每套车辆技术规范对背景音乐声压级、广播声压级、最大声压级都有具体约定。测试之前先查阅对应车型的技术规范，按规范值设定音量，而不是凭感觉调到“听着合适”。这样做出来的测试结果才有验收价值。

9.5 回采麦克风的位置要固定

如果每次测试的麦克风位置不固定，回采数据之间就没有可比性。建议在车厢内选择固定的测量点，并记录距离地板、侧墙的相对位置。

9.6 自动化是未来方向

当测试用例数量增加后，手动播放和录制会变得繁琐。可以考虑用Python脚本把“生成音频—播放—录制—分析—生成报告”串成一个测试任务，接入实验室的自动化测试框架，在每次版本构建后自动执行。

10. 总结与后续学习方向

回到开头的问题：在列车靶场上放音乐，到底在做什么？

答案不是“放歌”，而是通过高动态、宽频谱的音乐信号，对车载广播系统的音频链路、声场覆盖、紧急广播优先级做一次接近真实使用场景的验证。这套流程的价值在于，把主观的“听感”和客观的“数据”结合起来，既能快速发现问题，又能定位问题。

如果你想继续深入，建议按下面的顺序学习：

• 先熟悉信号处理基础：FFT、频谱、滤波、声压级计算。
• 再理解PIS系统架构：音源如何接入、优先级如何控制、广播如何分发。
• 然后动手写自动化测试脚本，把今天的示例扩展成完整的测试工具。
• 最后接触声学测量标准，了解声场均匀性、语音可懂度等工程指标。

下次再看到有人在列车靶场里放音乐，不妨多看一眼测试台架上的声压计读数。那才是这件事真正值得关注的地方。