@tushile928 #73 这个报错是引擎发现内存不够时的主动安全停止，不会输出错误结果，文件没有损坏。

麻烦提供几个信息帮定位：

daemon.log 和 desktop.log （设置 → 打开日志文件夹，两个文件都要）
电脑内存多大、什么操作系统
音频多长、什么格式，是文件转写还是实时功能
用的哪个模型（报错看是 FireRedASR2 AED ，确认下具体尺寸）
临时绕过：先试小一点的模型（比如 X-ASR 或 SenseVoice ），或者转写前关掉一些占内存的程序。方便的话到 https://github.com/QuintinShaw/openasr/issues 提一个 issue ，我帮你排查

@wm5d8b #62 这个取舍确实存在，说下考虑。.oasr 内核就是标准 GGUF ，外面加了一层容器：签名校验 + 把权重、tokenizer 、配置打成一个完整可运行的包。不是自研张量格式，是"GGUF + 供应链安全 + 开箱即用"的信封。

转换这个事本地推理赛道谁都绕不开——llama.cpp 转 GGUF 、sherpa 转 ONNX ，因为上游模型本来就没统一格式。区别是我们把转换做在发布侧，用户端一键装，不用自己折腾。真正限制支持范围的是引擎有没有实现该架构，格式反而不是瓶颈——目前十几个不同架构的模型族都跑通了。转换管线和格式文档都在 Apache-2.0 开源里，想接新模型欢迎提 issue 或直接 PR

@undefine2020 #61 两个原因。第一，电话链路本身是 8kHz 窄带 + 有损编码，高频辅音信息物理上就没了，而 ASR 模型基本都是 16kHz 宽带语料训练的，天然吃亏。第二，如果是手机外放被麦克风拾取，还要叠加空气传播、环境噪声和混响。本质是输入音频质量差异，不是模型能力问题。

如果是电脑上的网络通话（ Teams 、微信之类），确认字幕工具用的是系统音频采集而不是麦克风，效果会好很多。OpenASR 的实时字幕也支持系统音频采集，可以试试

@Explr #60 感谢推荐，VibeVoice-ASR 的说话人识别我还没接入过，后面研究一下

@iyuanyi #57 不简陋啊，产品做得挺完整的。方向不太一样，你这个是云端方案用起来更方便，OpenASR 主打本地离线，各有各的场景

@B4a1n #57 日语长音频目前已经接入了好几个支持的模型，可以看场景选：

长视频字幕最稳的先试 Whisper Large v3 ，长音频切片和时间戳最成熟，直接导出 SRT 没什么坑。

纯识别准确率更高的可以试 Cohere Transcribe ，Cohere 官方日语盲测胜率领先 Whisper 和 Qwen ，不过它没有原生时间戳，目前配合 VAD 切片来实现的时间戳。

动漫、综艺、带 BGM 的内容推荐对比 Qwen3-ASR 1.7B ，官方明确支持带背景音乐的场景。

幻听这个问题跟静音切片和 VAD 质量关系很大，我后面会专门做一轮日语长音频对比，有结论了更新，后面也会考虑接入专门针对日语优化的模型（其实上述三个模型应该有不错的体验了），如果你有什么发现，欢迎反馈

@hellodigua #56 支持的，CLI 是最早做的入口。另外如果你在用 Claude Code 之类的 agent ，可以一行装个 skill 让 agent 直接帮你调 CLI 转写：

npx skills add QuintinShaw/openasr --skill openasr --agent claude-code

@skills #55 感谢推荐！翻译确实在计划中，转写完接 LLM 做实时翻译是下一步想做的方向

@aaxx2xx #54 剪辑场景断句关键在 VAD （语音活动检测）切得准不准。OpenASR 目前用的就是 FireRedVAD ，公开数据上全面领先 Silero/FunASR 等方案（ F1 97.57%，误报率只有 2.69%）。断句和时间戳质量应该能满足剪辑需求，可以试试看

Metric\Model FireRedVAD Silero-VAD TEN-VAD FunASR-VAD WebRTC-VAD
AUC-ROC↑ 99.60 97.99 97.81 - -
F1 score↑ 97.57 95.95 95.19 90.91 52.30
False Alarm Rate↓ 2.69 9.41 15.47 44.03 2.83
Miss Rate↓ 3.62 3.95 2.95 0.42 64.15

数据来自 https://huggingface.co/FireRedTeam/FireRedVAD

@ningxing #45 dots.tts / CosyVoice 3 也都是 TTS 模型（文字转语音），并且有很好的语音克隆效果

@tingjiannishuo #48 dots.tts / CosyVoice 3 这类模型在跨语种声音克隆上都有不错的效果 fyi

@ccvip #47 这四点都很实在：

1. 批量处理目前 CLI 支持，桌面端的批量导入在做了
2. 说话人识别已经接了，录音转写可以用 --diarize 开启，桌面端预计本周上线
3. 热词功能目前大部分模型已经支持了，可以在模型设置里添加行业术语。多模型交叉校验筛易错词这个思路挺好，记下了
4. 本地跑的好处就是没有这些计费坑，跑多少都不花钱，其实像现在大多数人的设备都有很强的计算能力，完全可以胜任这些工作

此外目前 FireRedASR2-LLM 遇到一个图复用的问题，我在修复中，当前可能运行速度较慢。FireRedASR2-AED 目前是正常的，可以先试试，我会尽快修复这个问题。之后会对所有模型进行全方位性能检测，确保每个模型在各种设备上都可以利用到设备性能的物理极限

@Mithril 感谢试用和建议！分离推理这个方向我们架构上已经是这么设计的——引擎和前端是分开的，目前 openasr serve 可以起一个本地 OpenAI 兼容 API ，办公室里一台性能好的机器跑推理，其他设备调 API 就行。后续移动端上线后，也会支持连远程服务端转写，不用每台设备都跑模型

@yiranw09 #46 目前核实应该是 I 卡兼容的问题（ metal N 卡 A 卡都没问题），正在修复中，0.1.17 版本正在走签名发布流程（会对报错自动回退到 CPU 上），稍晚时候会彻底修复 I 卡的问题

@ccvip 感谢 star 和详细的测试反馈！豆包在工业专属词汇上强确实符合预期，毕竟背后有字节的行业数据。

FireRedASR2 在中文上确实很猛，附一组 FireRedASR2 论文里的公开 benchmark 数据供参考：

模型 普通话 CER% 方言 CER% aishell1 CER% aishell2 CER%
FireRedASR2-LLM 2.89 11.55 0.64 2.15
FireRedASR2-AED 3.05 11.67 0.57 2.51
Doubao-ASR 3.69 15.39 1.52 2.77
Qwen3-ASR 3.76 11.85 1.48 2.71

其中 aishell1/aishell2 覆盖了智能家居、自动驾驶、工业生产等十几个领域的词汇，是公开集里最接近行业应用场景的。不过这两个集还是安静环境下的朗读语音，跟你的涂料行业真实录音肯定有差距，期待你试完 FireRedASR2 的反馈

@yiranw09 #40 这个看起来是 Windows 上实时会话没正确启动的问题，麻烦到 GitHub Issues （ https://github.com/QuintinShaw/openasr/issues ）提一个，把那条报错信息贴上，再打开设置 → 高级设置 → 日志目录，把 daemon.log 也附上，我帮你排查

@yiranw09 #36 会议纪要这个场景确实是刚需。录音转写的说话人分离目前已经支持了（即将上线）。实时字幕的说话人分离难度要大不少——线上会议软件是靠“谁的麦克风在说话”来区分的，但线下录音只有一路混合音频，要实时区分不同说话人挑战还是很大的，在努力中

@12wk34 之前是这样，今年 2 月小红书团队的 FireRedASR2 AED 也很能打，对性能要求不高，嘈杂的音乐歌词的 CER 1.17% ，小红书团队说是工业级别模型，唯一的缺点是没有标点符号，需要搭配 FireRedPunc （小红书团队的文字断句和加标点模型） 使用，在模型设置里可以开启

@chendahui007 #24 soniox 看了一下是云端方案，效果确实不错。OpenASR 主打本地，定位不太一样（实际上像 Qwen / FireRed 系的模型在中文能力上还是不错的，FireRedASR2 LLM 的普通话 CER 可以达到 2.89%，恐怖如斯