问题
在使用 SmartSub 听写并翻译长视频、极度口语化的音视频（例如 YouTube 主播阅读中国网文的英文听写文本 Reaction 视频）时，目前的工作流在面对长文本语境、网络波动以及主播沉默期时，存在以下四个痛点：
-
翻译语境断裂（术语精分）：目前的字幕翻译分块（Chunking）机制似乎是将 SRT 数组按照固定行数（或 Token 长度）进行了硬截断发送给 LLM。这导致主播前后连贯的口语（如 like, literally, you know）语境被切断，大模型在失去上下文的情况下容易生硬直译；且前后不同的切块容易出现专属术语翻译不一致的问题。
-
翻译失败时破坏 SRT 文件：当前如果大模型 API 翻译失败（比如网络超时、限流、Key 额度不足），API 返回的错误信息（如 Error: 504 或 [Object object]）会被直接作为中文翻译文本写入最终的 SRT 字幕中，导致整段字幕损坏，人工排查极其痛苦。
-
Whisper 在沉默期的“时间轴拉长幻觉（字幕牛皮癣）”：YouTube 直播高频出现主播长达 10-20 秒沉默看视频、思考不说话的空白期。这时候本地 Whisper 引擎经常会把空白期前最后说的 1-2 个单词的时间轴无限拉长（例如：00:01:00 --> 00:01:20 Oh no），导致 2 个单词霸占屏幕 20 秒，画面卡死挂屏，人工极难在几千行字幕中揪出来。
-
Whisper 在嘈杂/高频口癖期的"局部失聪与吞字拉长"：在一段 20 秒的语音中，由于主播情绪激动尖叫、背景音嘈杂或连续使用破碎口癖，导致 Whisper 发生识别错误。主播实际上嘴巴不停说了一大堆词汇（高能量音频），但 Whisper 期间“失聪漏听”，最后只勉强生成了 3-4 个单词，并用这几个残缺的单词霸占了整整 20 秒的时间段。这种“画面嘴不停，字幕死卡住”的吞字现象比纯沉默更隐蔽，同样难以识别。
措施建议
针对上述四个痛点，建议对主进程的 ASR 后处理 和 Translation 服务层 进行以下四项协同优化：
- 建议一：引入带重叠历史的「滑动窗口（Sliding Context Window）」机制在每次向 LLM API 发送当前一批需要翻译的字幕（to_translate）时，在 Payload 中附带上前文已经处理好的若干句字幕作为“历史背景（history）”。
-
- 滑动机制：假设每次翻译 20 句新字幕（ChunkSize = 20），则窗口向前重叠拉取 8~10 句（OverlapSize = 10）作为不输出的 history 语境。
-
- Prompt 示例：通过 和 <to_translate> 标签明确告知大模型，历史内容仅供参考记忆，禁止翻译或重复输出，大模型必须严格保持 to_translate 的行号输出。这能从根本上解决口语化连贯性和术语一致性问题。
- 建议二：实现翻译异常的「降级兜底（Fallback）」机制在程序处理大模型翻译异常（catch (error)）时，绝对不能把 error.message 赋值给字幕文本。
-
- 优化逻辑：若某一块（Chunk）因网络或额度翻译失败，系统应当自动触发 Fallback 机制，直接用它原本的英文听写文本作为中文翻译的填充占位。
-
- 收益：即使接口偶尔断开，字幕也只是暂时保留英文，不会产生破坏性的乱码报错，完全不影响后续播放。同时可在界面上列出失败的行号提示用户一键重试。
- 建议三：引入基于语速密度的「霸屏字幕自动截断」校验在 ASR 听写完成、生成 SRT 文本的后处理环节，加入一个语速密度校验机制（Words Per Second）。
-
- 优化逻辑：算法自动扫描字幕。如果单条字幕持续时间超过安全阈值（如 > 7 秒），且 单词数 ÷ 持续秒数 的密度极低（例如 20 秒只有 2 个词，密度仅 0.1），则判定为 Whisper 引擎的沉默期拉长幻觉。
-
- 修复动作：系统自动根据单词数收缩并修正其结束时间（例如按人类正常语速强制将其截断在第 2-3 秒），把剩下的十多秒空白期重新还给播放器，彻底根除“字幕牛皮癣”挂屏现象。
- 建议四：引入「高能吞字/局部失聪」的智能高亮预警机制：对于同样符合“持续时间长（> 7秒）且单词密度极低（< 0.4 words/s）”的异常字幕，如果后处理算法检测到该段音频不仅不静音，反而处于持续高能量振幅状态（说明主播其实一直在疯狂说话）。
-
- 优化逻辑：100% 判定为 Whisper 因噪音或情绪卡壳导致的“局部失聪与吞字漏听”。
-
- 修复动作：系统保持原有时间轴不动（防止完全丢失定位），但在 SmartSub 的前端字幕编辑列表中，将该行字幕强制高亮标记为红色的「疑似重度漏听区」。并在转写完成后弹窗或侧边栏提醒用户：“检测到第 X 句存在长达 20 秒的持续高能发言，但仅识别出 Y 个单词，可能存在严重吞字漏听，请优先人工核对该段音频。”
-
- 如何识别持续高能量振幅状态？业界已有成熟实践，最精准的算法库 Librosa可以实现该方法：
import librosa
import numpy as np
def check_audio_energy(audio_path, start_time, end_time, silence_threshold=-35.0):
"""
检查指定时间段内的音频是否持续处于高能量状态
:return: True (持续高能说话), False (纯沉默或有大段空白)
"""
# 1. 仅加载指定时间段的音频数据（按采样率采样）
duration = end_time - start_time
y, sr = librosa.load(audio_path, sr=None, offset=start_time, duration=duration)
# 2. 计算短时均方根能量 (RMS)，并将能量转化为人类熟悉的分贝 (dB)
rms = librosa.feature.rms(y=y)
db_frames = librosa.amplitude_to_db(rms, ref=np.max)
# 3. 统计在这段长达 20 秒的时间里，有多少比例的时间音量高于“静音阈值”
high_energy_frames = np.sum(db_frames > silence_threshold)
total_frames = len(db_frames)
energy_ratio = high_energy_frames / total_frames
# 4. 如果有超过 70% 的时间音量都很高，说明主播一直在疯狂输出
return energy_ratio > 0.7如果能在翻译层和后处理层更进一步支持这四项策略，妙幕面对长视频、高频直播、口语化影视等复杂场景的网文/同人翻译质量将迎来真正的质变。最后，感谢作者开发出这么棒的工具！
问题
在使用 SmartSub 听写并翻译长视频、极度口语化的音视频（例如 YouTube 主播阅读中国网文的英文听写文本 Reaction 视频）时，目前的工作流在面对长文本语境、网络波动以及主播沉默期时，存在以下四个痛点：
翻译语境断裂（术语精分）：目前的字幕翻译分块（Chunking）机制似乎是将 SRT 数组按照固定行数（或 Token 长度）进行了硬截断发送给 LLM。这导致主播前后连贯的口语（如 like, literally, you know）语境被切断，大模型在失去上下文的情况下容易生硬直译；且前后不同的切块容易出现专属术语翻译不一致的问题。
翻译失败时破坏 SRT 文件：当前如果大模型 API 翻译失败（比如网络超时、限流、Key 额度不足），API 返回的错误信息（如 Error: 504 或 [Object object]）会被直接作为中文翻译文本写入最终的 SRT 字幕中，导致整段字幕损坏，人工排查极其痛苦。
Whisper 在沉默期的“时间轴拉长幻觉（字幕牛皮癣）”：YouTube 直播高频出现主播长达 10-20 秒沉默看视频、思考不说话的空白期。这时候本地 Whisper 引擎经常会把空白期前最后说的 1-2 个单词的时间轴无限拉长（例如：00:01:00 --> 00:01:20 Oh no），导致 2 个单词霸占屏幕 20 秒，画面卡死挂屏，人工极难在几千行字幕中揪出来。
Whisper 在嘈杂/高频口癖期的"局部失聪与吞字拉长"：在一段 20 秒的语音中，由于主播情绪激动尖叫、背景音嘈杂或连续使用破碎口癖，导致 Whisper 发生识别错误。主播实际上嘴巴不停说了一大堆词汇（高能量音频），但 Whisper 期间“失聪漏听”，最后只勉强生成了 3-4 个单词，并用这几个残缺的单词霸占了整整 20 秒的时间段。这种“画面嘴不停，字幕死卡住”的吞字现象比纯沉默更隐蔽，同样难以识别。
措施建议
针对上述四个痛点，建议对主进程的 ASR 后处理 和 Translation 服务层 进行以下四项协同优化：
如果能在翻译层和后处理层更进一步支持这四项策略，妙幕面对长视频、高频直播、口语化影视等复杂场景的网文/同人翻译质量将迎来真正的质变。最后，感谢作者开发出这么棒的工具！