录音到免费转录——健全日记第一步
起因是在4月到6月,我基本已经习惯了使用小守日记的过程,特别是使用小守记录我和家人的互动沟通内容。但最近和家人的沟通大部分集中到了线下场景。这导致我很难有精力抽出来记录大量日记,也不好像之前直接复制粘贴就可以把线上的互动信息导入到小守日记中去。
我之前就在有个持续的想法,把我所见、所闻的一切数据化,都产生日志原始数据,再由AI帮我记录和分析。所以基于最近生活中日记这个问题的痛点,我开始思考解决方案。很容易想到,把生活全程录音,然后将录音转为原始生活沟通对话记录,扔给AI,是目前相对容易实现的一个路径。
由此我开始不断和AI头脑风暴思考如何实现。最开始考虑了较为成熟的商业录音设备和转录软件,但核对成本的话很快就能发现,购买AI录音硬件设备就需要几百到一千,而这类厂商提供的转录服务也是有时间额度限制的,要实现7*24小时录音,可以说成本很大。
我也有尝试直接使用手机安装app进行录音和转录,但手机本身有其他的功能,例如接打电话、微信语音等等,不可能用于长时间录音工作。而测试的讯飞听见之类的商业app,我发现不管在音频转写文本的准确性还是在说话人的识别的准确性上都堪忧,让我肯本不好使用。最后我开始和AI思考自建DIY方案。包括自己找板子、写固件、写云端和手机app等,各自点子我都和AI讨论核对了下实现难度和成本。
最后基于AI推荐的基于成本、硬件素质和可玩性的分析,我买了一支搜狗E1录音笔。曾经大概2020年的时候市场售价上千元,但随着2024年搜狗放弃录音笔云端的转写等功能,现在这个设备咸鱼二手只需要80元。
设备参数上,2100mAh 电池,连续录音 10 小时,待机 20 天;32GB 存储,可存约 200 小时录音;8 麦阵列 + clairVoice 算法 + AGC 自动增益;4 种录音模式:会议(360°全向)、听课(哈曼指向麦)、采访(全向)、音乐(Hi-Res 96kHz/24bit)。RK3308四核A35,已经有人在github上面研究搜狗E1刷Armbian,刷了之后就可以编译写程序进去。也有人ADB进原厂系统,进去写一些小的功能,例如推上传之类的。
当然,我一贯认为,能满足需求的话,我们能少造轮子就少造,利用现有的轮子,站在巨人身上解决问题,才是最有效率的解决方案。录音笔有了,下一步就是解决便捷、低成本的转写和说话人识别的问题了。AI总是喜欢给我秀他多能写程序,反复给我说不难,这个功能几十行,那个功能几十行,几百行核心代码解决功能云云。AI写代码是不难,调试和改BUG费人哦。
基于简化需求,少造轮子,录音笔录音 → 手机端能看文本的需求。我们开始继续推进调研和实践的步伐。
第一反应:看看有没有现成的轮子
御坂和人讨论的第一个问题是——有没有人已经搞过这个?
答案是:有人在搞,但都不太够。
微信公众号上有篇文章,讲了一位大佬用DeepSeek + 自建服务器逆向复活了E1的全链路。做法是:DNS劫持 + 逆向搜狗的RSA-1024私有加密协议 + SiliconFlow STT + DeepSeek做摘要。架势很漂亮,问题是他没开源代码。等于只给思路不给轮子,御坂看着这7-8个环节的脆弱链路,果断跳过(运维成本比买个新录音笔都高好吧)。
GitHub上也有个Hermes-Language/Armbian_E1项目,尝试在E1上跑完整Armbian系统,但目前还卡在设备树适配阶段。还不太成熟。
再就是直接在社区网站WhyCan上看到有人在用IDA Pro逆向E1的核心可执行文件,纯研究性质,离”能用”还远。
结论:社区有动静,但没有能直接用的。
那换个录音笔呢?
御坂查了一下讯飞录音笔的二手价格和转写政策——
H1 Pro闲鱼300-450元,SR302在400-550元。价格不算贵,而且讯飞自带”终身免费每天24小时转写额度”。
听起来很香。但御坂对这一类”终身免费”承诺有天然的不信任——毕竟搜狗当年也是这么说的,三年就跑路了。把核心需求绑在厂商的承诺上,和现在的处境一模一样。
否决。
自己做一个转写工具?
于是御坂开始认真考虑自建方案。
硬件:GTX 1065 4GB专用显存(从任务管理器再三确认过),Windows。需求收敛为四个点:
| 要求 | 说明 |
|---|---|
| 中文转写 | 不要翻译腔的那种 |
| 区分说话人 | 通常是2-3个熟人对话 |
| 显存友好 | 4GB显存不能崩 |
| 输出MD | 说话人+时间戳+内容,方便用Obsidian多端看 |
技术上跑了一圈对比:
| 转写引擎 | 中文效果 | 生态 |
|---|---|---|
| Whisper large-v3 int8 | 85-90% | 最成熟 |
| SenseVoice(阿里FunASR) | 93%+ | 中文最优,但自己整合费劲 |
| medium int8 | 85% | 显存稳妥 |
最初选定的方案是WhisperX一体化:faster-whisper large-v3 int8 做转写 + pyannote 3.1 做说话人分离 + wav2vec2 做时间对齐 + tkinter 写个简单GUI。大约500行Python,打包成exe。看起来是可以的。
第一次实测——当场翻车
基于少重复造轮子,根据上面的转写技术路线,我让AI最后找到了实现相似技术路线的软件——Buzz(18.8k星的开源Whisper桌面工具,准备先做一波验证。
第一刀:large-v3 直接报 OOM。
4GB显存跑large-v3是钢丝,CTranslate2 int8量化后理论上峰值~3.5GB,实际跑到一半就爆了(后来用whisper.cpp + large-v3-turbo-q5_0才勉强跑通,Q5量化的turbo版)。
第二刀:转写文字本身还行。 用Q5量化的模型转了段中文对话,内容基本可读,没有离谱的识别错误。
第三刀——也是最致命的一刀:说话人分离不准确。
Buzz内置的diarization把对话里的人分得乱七八糟。而且一旦开启说话人识别,4GB的显存更加不够用了,只能完全用CPU跑转写和识别,速度很慢。
技术深潜:说话人分离为什么这么难?
还是回到先把问题搞清楚。
一查才发现,说话人分离(Speaker Diarization)是语音领域公认的硬骨头,难度远高于转写本身。 五个根本性障碍:
声纹漂移——同一个人早上刚醒和下午兴奋时声音不一样,感冒了不一样,离麦克风30cm和1.5m不一样。声纹不是指纹,它是个会动的靶子。
重叠语音——单麦录音下两人同时说话 = 两段声波在同一个声道叠加。数学上欠定,无法完美分离。
说话人数未知——系统得自己判断录音里有几个人。K值不定,多分少分都让错误率飙升。
远场 + 单麦——便携录音笔离声源0.5-2m,混响+环境噪音污染了本就不稳定的声纹特征。
短片段无法建声纹——“嗯””对””好的”只有0.3秒,不够提取稳定的声纹嵌入。
业界最好水平:DER(Diarization Error Rate)~10-15%,而且是在实验室AMI多麦近场数据集上。 换到便携录音笔的真实场景,只会更差。
御坂认识到:追求”全自动100%准确的说话人分离”在当前技术条件下是不现实的。Buzz不行,讯飞也不行,自建WhisperX+pyannote大概率也不行。
关键决策:放弃全自动,转向人工标注
既然自动分离的准确率天花板就摆在那,不如换个思路——
把自动分离当作草稿,把精力放在”让修正草稿这件事变得极其方便”上。
需求从”全自动区分说话人”变成了”转写+粗分离+便捷的编辑器人工标注”。
这一转,方向也转了——不再自己写转写工具(那是重复造轮子),而是找「转写+说话人分离+编辑器」一体化的现成方案。
峰回路转:发现 noScribe
顺着”转录编辑器”、”人工标注说话人”这个方向重新搜索,AI又帮忙找到了一个神器 noScribe。
它的定位恰好是御坂需要的:
| 维度 | 细节 |
|---|---|
| 转写引擎 | faster-whisper(precise模型),底层和御坂原先想自建的一模一样 |
| 说话人分离 | 内置pyannote系列模型 |
| 编辑器 | 波形图+文本双栏,点击任意文本即跳转到音频对应位置 |
| 说话人编辑 | 搜索”Speaker A”→ 全部替换为”张三”,几秒钟的事 |
| 输出 | HTML/VTT/TXT |
| 隐私 | 全本地离线 |
| 价格 | 开源免费 |
CPU版不依赖CUDA,御坂那4GB显存的问题直接不存在了。
一顿操作下载安装,测试了noScribe的precise模型——中文转写效果很好,说话人识别也可用,编辑器校对体验流畅。 一波带走。AI原计划的造轮子行动,直接归零。
落地:VToT 工作流
最终方案不是”一个软件”,而是「noScribe + 目录约定 + 配套脚本」的完整工作流。便宜强大的录音笔录音,免费开源的软件转写识别,但我还需要把两者的流程合并起来,让每次新增的录音能够便捷的转为我需要的文本,一方面存档到了我的obsidian云上去,另一方面也方便我同步给日记小守。要形成操作工作流:
1 | D:\1\coding\VToT\ |
日常操作只要七步:
- E1录音笔USB连电脑
- 复制WAV到
V\目录 - 打开noScribe → 导入WAV → precise模型 → 转写
- 在编辑器里对照波形逐句核对,搜索替换说话人名字(Speaker A → “张三”)
- 审完的HTML复制到
html\目录 - 双击
一键转MD.bat→ 自动将新增的HTML转为MD输出到outMD\ - 把MD拖进Obsidian仓库 → 坚果云/COS同步 → 手机端多端可查
主要还是因为音频转文本和说话人识别这两处,目前还是没办法做到100%的准确,导致必然需要4-5人工审核这两步。要不然最后喂给我的日记小守AI,咬文嚼字的AI肯定理解错误。
convert.py是让AI用Python内置html.parser写(零依赖,不怕环境崩),解析noScribe的HTML结构,提取每条语句的说话人、时间戳、文本内容,输出格式:
1 | # 2026-07-22-会议讨论 |
并且做了增量去重——outMD中已有同名MD自动跳过,不会重复转换。
总结
整个项目的演进路径:
1 | "能不能逆向复活?" → 社区方案不全 |
核心经验一句话:先找成品再动手,先验证再投入。 御坂差点就要写一个完整的桌面应用了,结果发现一个免费开源工具把事情全干了。
现在搜狗E1从一个被厂商抛弃的”哑巴”变成了完整可用的录音转录系统——零费用、零联网、零换设备。转写出来的MD结构化文本,后续喂给日记助手「小守」做每日摘要也极其方便(说话人、时间戳、内容三个维度天然对齐)。
这个方案目前就暂定这样执行一阵子了。如果后面使用起来觉得繁琐,到时候优化的方向可能是看如何便捷的让录音从录音笔中导出出来,以及可能让转写和说话人识别放到云端做服务去。不过这些就会增加成本。先继续现状跑跑看看了。