做一个纯浏览器端的音频分析工具，听起来像是要把数据库和音频引擎两种毫不相干的东西凑在一起，但实际上这个组合在本地化工具、离线分析和音频素材管理这类场景里非常实用。SQLite负责把结构化的音频元数据和分析结果存下来，WebAudio负责解码音频文件并提取采样数据，两者通过WASM和标准Web API在前端协同工作，全程不需要服务器参与。这篇文章就围绕这样一个实战项目，把存储层选型、音频数据处理、批量写入优化和查询联动几个环节完整讲一遍。
一、SQLite在浏览器中的落地方式与选型
SQLite本身是C语言编写的嵌入式数据库，要跑在浏览器里必须借助WebAssembly编译版本。目前主流的方案有两个：sql.js和wa-sqlite。sql.js出现得更早，使用简单，整个数据库在内存中运行，提供导出二进制文件的能力；wa-sqlite则更灵活，它是一个SQLite的JS封装层，支持把后端存储插拔成IndexedDB、Origin Private File System或者内存。
对于音频数据管理这种需要持久化、数据量会持续增长的场景，我推荐wa-sqlite配合IndexedDB后端。sql.js的问题在于所有数据都驻留内存，页面刷新前必须手动导出再重新导入，一旦忘记保存数据就丢了，而且音频分析产生的频谱数据量往往不小，全部放在内存里压力很大。wa-sqlite的IndexedDB后端基于虚拟文件系统实现，写入时按页落盘，刷新页面后数据自动恢复，体验上更接近原生SQLite。
初始化代码如下，先通过CDN引入wa-sqlite的WASM模块，再创建IndexedDB后端的数据库连接：
import { SQLiteESMFactory } from 'wa-sqlite';
import { IDBBatchAtomicVFS } from 'wa-sqlite/src/examples/IDBBatchAtomicVFS.js';
const factory = new SQLiteESMFactory('wa-sqlite.wasm');
const sqlite3 = await factory.getSQLite3();
// 创建基于IndexedDB的虚拟文件系统
const vfs = await IDBBatchAtomicVFS.create('audioDB', sqlite3.module);
sqlite3.vfs_register(vfs, true);
// 打开数据库并建表
const db = await sqlite3.open_v2('audio.sqlite');
await sqlite3.exec(db, `
CREATE TABLE IF NOT EXISTS tracks (
id INTEGER PRIMARY KEY AUTOINCREMENT,
name TEXT NOT NULL,
duration REAL,
sample_rate INTEGER,
created_at TEXT DEFAULT (datetime('now'))
);
CREATE TABLE IF NOT EXISTS spectrum_data (
id INTEGER PRIMARY KEY AUTOINCREMENT,
track_id INTEGER REFERENCES tracks(id),
time_offset REAL,
freq_bin INTEGER,
magnitude REAL
);
`);
表结构上做了两张表分离：tracks存音频文件的元信息，spectrum_data存逐帧的频谱数据。这样设计的好处是查询元数据列表时不用扫过海量分析数据，聚合统计也可以利用外键索引加速。
二、用WebAudio解码音频并提取频谱数据
WebAudio的核心入口是AudioContext。拿到音频文件后，先用decodeAudioData把它解码成AudioBuffer，这一步浏览器会自动处理MP3、WAV、OGG等常见格式，解码后的AudioBuffer包含PCM采样数据和采样率信息。
提取频谱用AnalyserNode配合OfflineAudioContext。很多人习惯用实时的AudioContext去分析，但这需要真实播放音频、等待时间流逝，处理一批文件会非常慢。正确做法是用OfflineAudioContext做离线渲染，它不需要实时播放，可以在极短时间内完成整段音频的快速傅里叶变换处理。
不过要注意一个细节：AnalyserNode在离线渲染时，getByteFrequencyData的行为和实时模式略有差异，直接依赖它有时拿不到完整数据。更稳妥的方案是自己实现分帧加窗，通过getChannelData读取原始PCM数据，手动做FFT。下面的代码演示了从文件解码到分帧提取频谱的完整流程：
async function analyzeAudio(file) {
const arrayBuffer = await file.arrayBuffer();
const audioCtx = new AudioContext();
const audioBuffer = await audioCtx.decodeAudioData(arrayBuffer);
await audioCtx.close();
const channelData = audioBuffer.getChannelData(0); // 取左声道
const sampleRate = audioBuffer.sampleRate;
const fftSize = 2048;
const hopSize = 1024; // 百分之五十重叠
const frameCount = Math.floor((channelData.length - fftSize) / hopSize);
const analyserNode = audioBuffer;
const results = [];
for (let i = 0; i < frameCount; i++) {
const start = i * hopSize;
const frame = channelData.slice(start, start + fftSize);
// 这里可以接自实现的FFT或第三方库如fft.js
// 返回每个频段的幅值数组
const magnitudes = computeFFT(frame, fftSize, sampleRate);
results.push({ timeOffset: start / sampleRate, magnitudes });
}
return {
name: file.name,
duration: audioBuffer.duration,
sampleRate,
frames: results
};
}
分帧时建议加汉宁窗（Hann Window）减少频谱泄漏，帧与帧之间保留百分之五十的重叠能让后续可视化的时间轴更平滑。fftSize取2048是一个平衡点：频率分辨率够用，计算量也可控。如果只需要做节奏检测这类低频敏感的分析，1024也够。
三、批量写入SQLite与性能优化
频谱数据的特点是行数极多。一首三分钟的歌，按1024采样点跳步、44100采样率计算，大约会产生七千多帧，每帧如果存几百个频段，总量轻松突破百万行。这种量级如果逐条INSERT，在虚拟文件系统上的开销会非常夸张，页面可能直接卡死。
解决方案是三个手段叠加：显式事务、预编译语句、分批提交。事务把大量单条写操作合并成一次磁盘同步；预编译语句避免重复解析SQL的开销；分批提交则避免单次事务过大导致内存峰值过高。实测下来，开启事务后写入速度能有几十倍的提升。
async function saveAnalysis(sqlite3, db, analysis) {
// 插入元数据
const trackId = await sqlite3.exec(db, `
INSERT INTO tracks (name, duration, sample_rate)
VALUES ('${analysis.name}', ${analysis.duration}, ${analysis.sampleRate})
`);
// 实际项目中建议用预编译语句绑定参数，避免拼接SQL
const BATCH = 5000;
let buffer = [];
sqlite3.exec(db, 'BEGIN TRANSACTION;');
try {
for (const frame of analysis.frames) {
for (let bin = 0; bin < frame.magnitudes.length; bin++) {
buffer.push([trackId, frame.timeOffset, bin, frame.magnitudes[bin]]);
}
if (buffer.length >= BATCH) {
await flushBatch(sqlite3, db, buffer);
buffer = [];
}
}
if (buffer.length) await flushBatch(sqlite3, db, buffer);
sqlite3.exec(db, 'COMMIT;');
} catch (e) {
sqlite3.exec(db, 'ROLLBACK;');
throw e;
}
}
另一个值得做的优化是降采样存储。频谱可视化通常用不到全部2048个频段，人耳对高频的分辨率本身也在下降，可以在写入前做对数分组的降维，把每帧压缩到64或128个频段，数据量直接缩小一个数量级，查询和渲染都会轻快很多。同时在spectrum_data表的(track_id, time_offset)上建复合索引，按时间范围查询时速度有明显差别。
四、查询联动与音频回放
数据存好之后，就能做元数据列表、统计聚合和回放联动了。典型交互是：点击列表中某首歌，从SQLite按时间偏移查询频谱数据画波形图或热力图，同时用AudioContext播放音频，播放进度与频谱图上的光标联动。
进度联动可以用requestAnimationFrame不断读取AudioContext.currentTime减去播放起始时刻得到当前进度，再从预加载的频谱数组中定位对应帧。如果频谱数据已经做了降维，整个热力图数据可以一次性从SQLite读出放在内存里，几万行的读取在wa-sqlite上通常几百毫秒就能完成，交互体验没问题。
async function loadSpectrum(sqlite3, db, trackId) {
const rows = [];
await sqlite3.exec(db, {
sql: 'SELECT time_offset, freq_bin, magnitude FROM spectrum_data WHERE track_id = ? ORDER BY time_offset, freq_bin',
bind: [trackId],
rowMode: 'array',
callback: (row) => rows.push(row)
});
return rows;
}
function playWithVisualize(audioBuffer, spectrumRows) {
const ctx = new AudioContext();
const source = ctx.createBufferSource();
source.buffer = audioBuffer;
source.connect(ctx.destination);
source.start();
const startAt = ctx.currentTime;
function draw() {
const elapsed = ctx.currentTime - startAt;
const binCount = 128;
const frameIndex = Math.floor(elapsed / 0.023); // 跳步对应的时间
renderHeatmap(spectrumRows, frameIndex, binCount);
requestAnimationFrame(draw);
}
draw();
}
这套架构的扩展空间还很大。比如可以给频谱数据做指纹提取，实现简单的听歌识曲；也可以结合SQLite的FTS5全文索引给音频做文本标注检索。整个方案完全跑在浏览器里，数据不离开本地，对音频素材管理和个人分析工具来说，是一条成本低且完全可控的技术路线。