你好，我最近在 Windows 下使用 VoiceTransl 处理较长视频时，遇到几个和日志展示、失败处理相关的小问题。看了已有 issue/PR 后，感觉可能有一部分已经在后续规划中，所以先开 issue 确认一下是否值得拆成小 PR。
相关讨论里我注意到：
我本地试着做了几类改动，但不确定哪些适合 upstream，所以想先确认维护者偏好：
- 听写失败后停止当前流程
当前如果 whisper/faster-whisper 进程失败，或没有生成预期的 .srt，后续仍可能继续执行 make_prompt()、翻译或生成字幕，最后报错会变成缺少 JSON / SRT / gt_output 文件，用户不容易判断真正失败点。
我本地做了一个很小的补丁：等待 whisper 子进程结束后检查退出码和预期 .srt 是否存在；失败时直接报错并停止后续处理。这个改动比较独立，可以单独 PR。
- 日志中的 ANSI 颜色码和子进程日志前缀清理
GalTransl / llama.cpp / faster-whisper 等子进程会输出 ANSI 颜色码、时间戳、日志级别前缀。QPlainTextEdit 不能解释 ANSI 码，所以实时输出里会出现类似：
[06-20 18:30:52]\u001b[37m[INFO]\u001b[0m>>> 开始翻译 ...
我本地做过简单过滤：去掉 ANSI escape sequence、重复的子进程 [INFO] 前缀和 >>> 标记，只保留用户可读内容。但 #28 评论里已经提过“终端仿真 + 日志过滤”，所以不确定是否应该等已有方案，还是先提交一个轻量过滤版。
- 长时间在线翻译的进度提示
较长视频使用在线大模型翻译时，中间可能几十分钟没有明确进度。用户只能看日志滚动，不容易判断是否卡住。我本地试过按 30 秒扫描、60 秒汇报的方式，根据 transl_cache / gt_output 粗略显示：
翻译进度 xxx: 140/576 (24.3%)
这部分改动比失败处理更大，也可能和 #28 的并发流水线有关，所以我倾向于如果需要，也单独开 PR。
想确认一下：
- 是否接受一个最小 PR，只修复“听写失败或未生成 SRT 时停止流程并给出明确错误”？
- ANSI 清理更希望做轻量文本过滤，还是等完整终端仿真/日志过滤方案？
- 在线翻译进度提示是否符合项目方向？如果接受，是否偏好固定间隔，例如 30/60 秒，还是做成可配置项？
如果你愿意，我可以先提交第 1 项的最小 PR，后两项继续按你的偏好拆开。
你好，我最近在 Windows 下使用 VoiceTransl 处理较长视频时，遇到几个和日志展示、失败处理相关的小问题。看了已有 issue/PR 后，感觉可能有一部分已经在后续规划中，所以先开 issue 确认一下是否值得拆成小 PR。
相关讨论里我注意到：
\u001b[37m[INFO]\u001b[0m。我本地试着做了几类改动，但不确定哪些适合 upstream，所以想先确认维护者偏好：
当前如果 whisper/faster-whisper 进程失败，或没有生成预期的
.srt，后续仍可能继续执行make_prompt()、翻译或生成字幕，最后报错会变成缺少 JSON / SRT / gt_output 文件，用户不容易判断真正失败点。我本地做了一个很小的补丁：等待 whisper 子进程结束后检查退出码和预期
.srt是否存在；失败时直接报错并停止后续处理。这个改动比较独立，可以单独 PR。GalTransl / llama.cpp / faster-whisper 等子进程会输出 ANSI 颜色码、时间戳、日志级别前缀。
QPlainTextEdit不能解释 ANSI 码，所以实时输出里会出现类似：我本地做过简单过滤：去掉 ANSI escape sequence、重复的子进程
[INFO]前缀和>>>标记，只保留用户可读内容。但 #28 评论里已经提过“终端仿真 + 日志过滤”，所以不确定是否应该等已有方案，还是先提交一个轻量过滤版。较长视频使用在线大模型翻译时，中间可能几十分钟没有明确进度。用户只能看日志滚动，不容易判断是否卡住。我本地试过按 30 秒扫描、60 秒汇报的方式，根据
transl_cache/gt_output粗略显示：这部分改动比失败处理更大，也可能和 #28 的并发流水线有关，所以我倾向于如果需要，也单独开 PR。
想确认一下：
如果你愿意，我可以先提交第 1 项的最小 PR，后两项继续按你的偏好拆开。