JS在线录音录制MP3音频导出：getUserMedia到lamejs完整实现

简介面向Web前端开发者与音视频处理学习者这套基于JavaScript的录音代码包主要解决在浏览器页面中实时采集麦克风声音并把音频编码为MP3格式后下载或上传的问题。压缩包共6个文件包括3个JavaScript脚本录音主逻辑、MP3编码库、实时处理线程、1个HTML入口页面以及ashx与cs服务端处理文件整体大小仅58KB部署轻便已有949人浏览学习。代码完整覆盖了录音与导出的关键环节先通过获取用户媒体设备getUserMedia申请麦克风权限并创建音频流再使用脚本处理节点ScriptProcessorNode监听音频数据借助数组缓冲区ArrayBuffer和浮点数组Float32Array读取样本随后调用lamejs编码库将PCM数据转换为MP3最后支持前端下载或上传至服务器。通过这份代码开发者能直观理解Web音频APIWeb Audio API中音频节点的协作方式也能掌握音频数据处理、格式转换以及前后端交互的实用技巧既适合直接复用为在线录音工具也可作为学习参考应用于语音留言、网页录制等多种场景。代码包内的网页入口与上传接口示例把前端录制和后端接收串联起来方便直接运行验证省去自行搭建环境的成本。1. js在线录音录制MP3音频导出代码到底在解决什么问题刚接手录音类前端需求时多数人默认浏览器里一行getUserMedia加MediaRecorder就能拿到 MP3实际跑一遍才知道原生录音只能拿到 webm、ogg 或 mp4 封装MP3 编码器压根不在浏览器标准实现里。这份「js在线录音录制MP3音频导出代码」要解决的就是「浏览器采集麦克风 → 编码成 MP3 → 触发下载」这条完整链路。我用这个方案做过客服质检录音、语音笔记工具和前端面试答题录制它不需要后端参与纯前端就能交付可播放的 MP3 文件。适合谁前端日常开发、录音类 Web 应用、需要把录音文件导出给业务系统使用的团队。2. 方案选型浏览器录音到 MP3 的三条路哪条最稳2.1 为什么浏览器不直接给 MP3MediaRecorder 的 mimeType 黑匣子MediaRecorder能录出什么格式完全取决于浏览器编译时内置了哪些编码器。Chrome 一般支持audio/webm;codecsopusSafari 给的是audio/mp4Firefox 偏向audio/ogg。至于audio/mp3MediaRecorder.isTypeSupported(audio/mp3)在不同版本里时灵时不灵灵的时候录出来的文件时间戳也偶尔是坏的。这层兼容代码写起来有点像在做 js 逆向全靠实测翻老底。const types [ audio/mp3, audio/mpeg, audio/webm;codecsopus, audio/ogg;codecsopus, audio/mp4 ]; const supported types.filter(type { try { return MediaRecorder.isTypeSupported(type); } catch (e) { return false; } }); console.log(supported); // Chrome 常见结果[audio/webm;codecsopus, audio/mp4]这段代码的价值不是「探测完选第一个」而是让你亲眼确认原生路径几乎拿不到 MP3。isTypeSupported返回的是布尔值其中audio/mpeg是 MP3 的正式 MIME 名称audio/mp3则是民间惯用写法。如果这两项都不在名单里就别赌 MediaRecorder 了老老实实走自建编码链路。2.2 自建编码链路getUserMedia AudioContext lamejs 的三段式稳定拿到 MP3 的通用做法是放弃MediaRecorder的封装自己接麦克风原始数据。链路分三段getUserMedia拿麦克风流AudioContext把流变成可编程的音频节点回调里拿到 Float32 的 PCM 数据转成 Int16 后喂给 MP3 编码器。编码器目前最常用的是 lamejs它是 LAME 编码器的 JavaScript 移植纯前端能在浏览器里把 PCM 编码成 MP3。新版本也提供了 wasm 版移动端老设备上性能更好一点但普通短录音用 JS 版完全够。选它的理由很简单MP3 是交付格式里播放器兼容性最好的录音上传给后端质检系统、微信里直接点开听、甚至发给不装播放器的同事都不会出幺蛾子。2.3 边录边转还是录完再转时延与内存怎么取舍这两个架构我分别在生产环境里用过。录完再转的意思是录音过程只攒 Float32 数组停止录音后一次性交给编码器边录边转则是在每次音频回调里立刻调用encodeBuffer把编码后的碎块收集起来。选型看录音时长和内存预算。对比项录完再转边录边转内存占用时长 x 采样率 x 2 字节5 分钟单声道约 28MB只保留编码后数据长录音优势明显编码延迟停止后一次性编码可能卡顿几百毫秒分散到每次回调UI 不卡暂停续录简单暂停时切分数组即可需要维护独立的编码器实例或时间戳边界实现复杂度低适合新手高调试时更容易出隐性 bug我的取舍习惯短录音5 分钟以内一律录完再转省心客服热线、在线面试这类可能长达半小时的录音用边录边转但编码器实例要做好销毁和重建否则长时间运行后内存会缓慢上涨。3. 最小可跑通的录音导出 MP3 代码直接抄这份3.1 权限与音频上下文getUserMedia 和 AudioContext 的连接方式先说一个新手最容易踩的点getUserMedia必须由用户主动操作触发比如点击「开始录音」按钮不能页面加载后自动弹权限框。下面这份代码从点击到出文件全流程能跑通。!DOCTYPE html html langzh-CN body button idrecordBtn开始录音/button button idstopBtn disabled停止并导出/button audio idpreview controls styledisplay:none/audio script srchttps://unpkg.com/lamejs1.2.1/lame.min.js/script script const recordBtn document.getElementById(recordBtn); const stopBtn document.getElementById(stopBtn); const preview document.getElementById(preview); let mediaStream null; let audioContext null; let scriptProcessor null; let pcmChunks []; recordBtn.addEventListener(click, async () { mediaStream await navigator.mediaDevices.getUserMedia({ audio: { channelCount: 1, sampleRate: 48000 } }); audioContext new (window.AudioContext || window.webkitAudioContext)(); const source audioContext.createMediaStreamSource(mediaStream); scriptProcessor audioContext.createScriptProcessor(4096, 1, 1); scriptProcessor.onaudioprocess (event) { const inputData event.inputBuffer.getChannelData(0); pcmChunks.push(new Float32Array(inputData)); }; source.connect(scriptProcessor); scriptProcessor.connect(audioContext.destination); recordBtn.disabled true; stopBtn.disabled false; }); /script /body /html这里两个关键参数要解释。createScriptProcessor(4096, 1, 1)第一个参数是缓冲区大小4096 表示每约 85 毫秒回调一次对普通录音足够调成 2048 延迟更低但老机型容易爆音后面两个 1 分别表示输入声道数和输出声道数因为麦克风采集通常只要单声道。sampleRate: 48000只是给浏览器的性能提示不是硬性保证实际采样率要以audioContext.sampleRate为准后面编码环节必须用它来计算。注意上面代码还没接编码器pcmChunks先按 Float32 原样攒着这样录完再转的架构更直观。如果你要做长时间录制把pcmChunks.push换成直接调encodeChunk就行第 4 章我会给边录边转的改造。3.2 把 Float32 PCM 转成 Int16 并交给 lamejs 编码停止录音后要做四件事拆平所有 Float32 块、转成 Int16、调用 lamejs 编码、取回编码后的字节。Float32 转 Int16 是这里最容易出错的环节直接乘 32767 会溢出必须先用Math.max(-1, Math.min(1, value))裁剪。stopBtn.addEventListener(click, () { // 1. 拆平 Float32 数组 const length pcmChunks.reduce((sum, chunk) sum chunk.length, 0); const floatData new Float32Array(length); let offset 0; for (const chunk of pcmChunks) { floatData.set(chunk, offset); offset chunk.length; } // 2. Float32 - Int16 const int16Data new Int16Array(floatData.length); for (let i 0; i floatData.length; i) { const sample Math.max(-1, Math.min(1, floatData[i])); int16Data[i] sample 0 ? sample * 0x8000 : sample * 0x7FFF; } // 3. lamejs 编码 const sampleRate audioContext.sampleRate || 48000; const mp3Encoder new lamejs.Mp3Encoder(1, sampleRate, 128); const mp3Chunks []; const mp3Data mp3Encoder.encodeBuffer(int16Data); if (mp3Data.length 0) { mp3Chunks.push(new Int8Array(mp3Data)); } const endData mp3Encoder.flush(); if (endData.length 0) { mp3Chunks.push(new Int8Array(endData)); } pcmChunks []; // 4. 组装 Blob 交给导出函数 const blob new Blob(mp3Chunks, { type: audio/mpeg }); downloadBlob(blob); });encodeBuffer接收的是 Int16Array这是 lamejs 的硬性要求直接传 Float32 会得到一堆乱码。encodeBuffer返回的Int8Array要逐段收集因为编码器内部有缓冲最后必须调用flush()把尾部数据推出来。lamejs.Mp3Encoder(1, sampleRate, 128)三个参数分别是声道数、采样率、码率128 表示 128kbps语音场景够用音乐场景建议提到 192。3.3 Blob 导出下载与 URL.revokeObjectURL 的一次性资源导出环节其实只有三行代码但资源释放和浏览器兼容是隐藏考点。Blob的 MIME 类型写audio/mpeg比audio/mp3更规范部分播放器对audio/mp3这个临时类型识别有问题。function downloadBlob(blob) { const url URL.createObjectURL(blob); const a document.createElement(a); a.href url; a.download recording_${Date.now()}.mp3; document.body.appendChild(a); a.click(); document.body.removeChild(a); setTimeout(() { URL.revokeObjectURL(url); }, 1000); }URL.createObjectURL创建的是一个指向浏览器内存中 Blob 的临时地址如果不调revokeObjectURL页面会一直持有这段内存引用。为什么用setTimeout延迟 1 秒再释放因为某些浏览器在a.click()触发的下载还没建立连接时就调 revoke会导致下载失败。a.download属性里带上时间戳避免连续录制时浏览器给同名文件自动加「(1)」后缀。整个最小方案到这里已经完整从点击开始到拿到 MP3 文件大约 30 行核心代码。下面进入参数调优这部分决定了录音文件是「能听」还是「能用」。4. 把录音质量调到可用采样率、码率与前端降噪的取舍4.1 采样率、码率、单双声道的三个参数到底怎么填很多人第一次调参是按「音质越高越好」的思路来结果 5 分钟录音导出来 20 多 MB上传和播放都难受。采样率、码率、声道这三个参数必须跟业务场景绑定不是越高越好。场景采样率码率声道每分钟文件大小约语音笔记 / 会议纪要16000 或 2400064kbps单声道0.5MB客服质检 / 话术分析24000128kbps单声道1MB在线面试 / 答辩录制48000128kbps单声道1MB音乐翻唱 / 音色分析48000192kbps双声道2.3MB语音场景没必要上 48k 采样率人说话的有效频谱集中在 300Hz-3400Hz24k 采样率足够覆盖。采样率降下来Int16Array的长度直接变少编码耗时和文件大小同步下降。另一种常见做法是在getUserMedia里直接请求 16000但要注意这仍只是 hint部分浏览器会忽略所以编码前一定要读audioContext.sampleRate以它为准做重采样。如果采集到的采样率和编码目标不一致可以在onaudioprocess回调里做线性插值重采样。简单场景用这个公式按比例在原数组中取值目标位置srcIndex dstIndex * (srcLen / dstLen)然后取邻近整数。要求音的再引入AudioContext的OfflineAudioContext做正规重采样但代码量会上一个台阶不建议短录音场景这么做。4.2 音量增益与前端降噪的轻量处理麦克风灵敏度和说话人距离不同同一套参数录出来的音量可能差异很大。前端能做的轻量处理有两个自动增益和高通滤波。自动增益用 Web Audio API 的GainNode实现先测一帧的 RMS 音量目标 RMS 与实测值的比值就是增益系数。function getRms(data) { let sum 0; for (let i 0; i data.length; i) { sum data[i] * data[i]; } return Math.sqrt(sum / data.length); } // onaudioprocess 内部 const rms getRms(inputData); let gain 1; if (rms 0.01) { gain 2; } else if (rms 0.5) { gain 0.5; } for (let i 0; i inputData.length; i) { inputData[i] Math.max(-1, Math.min(1, inputData[i] * gain)); }这段自动增益是「事后增益」只对信号弱的帧放大不会在静音时无限放大底噪因为rms低于阈值就停止放大了。它解决的是「忽大忽小」的体验问题不是音质问题。至于降噪纯前端深度降噪比如谱减法、AI 降噪在移动端性价比很低跑起来耗电又发热。我的经验是前端只要守住两点静音时把音量压到 0遇到突发爆音时做限幅。真正的降噪放后端预处理前端录好原始 PCM 上传后端做 VAD 和降噪后转 MP3。如果你必须纯前端出 MP3牺牲一点静音段是值得的录到大量静音底噪远不如录到轻微音量波动。4.3 暂停与续录控制段落时长和导出前裁剪录音功能上线后用户第一个提的需求一定是「忘词了能不能暂停」。暂停续录的实现分两层暂停和续录都只是切断onaudioprocess的数据累积真正的难点在导出时去掉开头和结尾的静音段以及记录每个暂停点的时间戳。let segments []; // 每段录音的起止时间 let segmentStart 0; scriptProcessor.onaudioprocess (event) { // 暂停时不推进 pcmChunks if (!isPaused) { pcmChunks.push(new Float32Array(event.inputBuffer.getChannelData(0))); // 记录当前段已录时长 const chunkDuration 4096 / audioContext.sampleRate; segments[segments.length - 1].end chunkDuration; } }; stopBtn.addEventListener(click, () { // 导出时往前裁剪 0.3 秒去掉「啪」的点击声 const trimStart 0.3; const trimEnd 0.2; // 用 segments 计算有效时长裁剪对应的 PCM 索引 // 这里结合第 3.2 节的编码函数即可 });暂停时不要disconnect整个节点链断开再重连会出现短暂爆音。正确做法是设置isPaused标志回调照常触发但不攒数据。导出前裁剪的 0.3 秒和 0.2 秒不是拍脑袋点击停止按键瞬间麦克风会收到按键机械声去掉这零点几秒能显著提升听感。同时要注意createScriptProcessor的回调频率不是精确定时器暂停到恢复之间的最后一块数据可能包含暂停后的杂音。裁剪时把每段开头固定砍掉 50 个采样点成本极低但体验收益很明显。5. 在线录音录 MP3 的常见问题排查这些坑我全踩过5.1 时长错乱MP3 文件播放时长比实际录音长或短现象录了 1 分钟导出后播放器显示 1 分 20 秒播放到 1 分钟处变静音或者显示 50 秒结尾被截断。原因lamejs 的encodeBuffer是分批编码的每批之间编码器内部状态会引入 padding填充帧。边录边转时如果最后没有正确调用flush()尾部的编码缓冲数据直接丢失时长变短如果音量静音段全被编码成有效帧播放器读到的是包含填充帧的总时长时长变长。解决统一「先攒 PCM停止后一次性编码」的路径最后强制flush()并收集返回值。同时用audio元素的duration属性跟本地计时器对比偏差超过 300ms 就检查编码链路。我习惯在stopBtn回调里加一行console.log(期望时长, expectedDuration, 实际时长, audio.duration)把偏差位置暴露出来。5.2 iOS Safari 上点击录音无反应或录到空白现象Android Chrome 一切正常iPhone 打开页面点击录音没弹权限框或者弹了权限但录音导出后是静音文件。原因iOS Safari 有两个限制。第一getUserMedia必须直接挂在用户手势的调用栈里中间隔了setTimeout或async函数的无关await都会导致静默失败第二iOS 的AudioContext初始状态是suspended必须用户点击后调用audioContext.resume()才会真正开始采集。解决把权限申请逻辑直接写进click事件处理函数的最前面不要await无关请求并且录音开始前显式执行await audioContext.resume()。另外 iOS 只认 HTTPS 或 localhostHTTP 环境下getUserMedia直接抛NotAllowedError上线前先用真机测一次。5.3 Chrome 录到一半页面卡死或内存爆掉现象录音正常但两三分钟之后页面明显变卡点停止要等好几秒打开任务管理器看到内存持续上涨。原因最常见的是pcmChunks数组无限制增长同时scriptProcessor没有正确处理旧块引用。另一种情况是每次onaudioprocess都创建新的数组对象老数组未被及时 GC造成 GC 停顿。解决优先切到边录边转架构把pcmChunks从 Float32 数组改成Int8Array的收集列表编码完立刻置空引用。代码层面注意inputData是 AudioBuffer 的只读视图不能直接push原对象必须new Float32Array(inputData)复制一份否则浏览器底层缓冲区复用会导致录音数据被覆盖。5.4 导出的文件电脑能播手机播放器不认现象MP3 文件在 Windows 播放器和 Chrome 里正常播放发到微信或 iPhone 自带播放器里提示格式不支持。原因MIME 类型写成了audio/mp3或application/octet-streamBlob 缺少正确的文件头信息。部分播放器靠文件头识别格式不认 MIME。另外 lamejs 编码时如果采样率用了 44100 以外的值比如 48000老型号手机的解码器可能对 MPEG-1 Layer 3 的采样率字段支持不全。解决Blob 类型固定写audio/mpeg文件扩展名固定.mp3采样率优先用 44100。如果业务要求 48000先用OfflineAudioContext把 PCM 重采样到 44100 再编码兼容性覆盖最好。5.5 用户拒绝麦克风权限后怎么让错误提示不白屏现象用户点了「禁止」页面没有任何变化再点开始录音也毫无反应控制台报NotAllowedError。原因getUserMedia的 Promise reject 没有被捕获后续代码全部跳过UI 停在「已点击但无反馈」状态。解决给getUserMedia包一层 try-catch根据错误码区分三类提示。NotAllowedError提示用户去浏览器地址栏右侧重新开启麦克风权限NotFoundError提示没检测到麦克风设备NotReadableError提示设备被其他应用占用。同时把「开始录音」按钮在失败后恢复到可点击状态避免用户想重试却点不了按钮。try { mediaStream await navigator.mediaDevices.getUserMedia({ audio: true }); } catch (err) { if (err.name NotAllowedError) { alert(麦克风权限被拒绝请点击地址栏图标重新开启); } else if (err.name NotFoundError) { alert(未检测到麦克风设备); } else if (err.name NotReadableError) { alert(麦克风被其他应用占用请关闭后重试); } recordBtn.disabled false; stopBtn.disabled true; return; }权限错误处理是最容易被忽略的一环但它直接影响录音功能的上线体验。客服团队录质检样本时经常遇到业务人员电脑上权限被企业安全策略锁死这时候前端提示越具体返工成本越低。6. 进阶录音段落对齐和导出文件的验证技巧6.1 用识别接口给录音做段落时间轴对齐录音导出的下一步通常是转文字客服质检要把每段对话对应到人。前端能配合做的是把录音分段信息和后端识别的返回结果做时间轴对齐。常见做法是录制时通过静音检测切分段落把每段的开始时间和结束时间记录成 JSON跟音频一起上传后端识别后把文字按段填回去。需要注意的是前端记录的本地时间戳和音频编码后的真实时长基准不同差几十毫秒就可能导致文字和声音错位。稳妥的做法是后端转写时返回带时间戳的 segments前端只负责展示。像 Whisper 这类模型返回的{start, end, text}结构直接映射到音频播放器的currentTime就能实现点击文字跳转播放。6.2 用段时长交叉验证导出的 MP3 文件另外有一个小技巧值得养成习惯导出前先用AudioContext.decodeAudioData把 MP3 解回来对比解码后的时长和本地计时的偏差超过 1% 说明编码参数有问题不要再往上传。测试文本可以先用网上找的 mp3 测试文件验证播放链路确认无误后再跑真实录音。async function verifyMp3(blob) { const arrayBuffer await blob.arrayBuffer(); const audioCtx new (window.AudioContext || window.webkitAudioContext)(); const decoded await audioCtx.decodeAudioData(arrayBuffer); console.log(解码时长:, decoded.duration); }做录音功能这几年我最大的教训是别把这件事想简单录音只是开始编码质量、权限提示、时长对齐都关系到用户能不能顺利交出文件。现在每次接这类需求我都会先问清楚交付格式和播放环境再决定是走 MediaRecorder 还是自建链路。如果读完这篇你能少走一次「录出来不是 MP3」的弯路这份笔记就没白写希望帮到你。本文还有配套的精品资源点击获取