#8600 Win10/11 预打包版本:win-pyvideotrans-v4.17-1028.7zLLM重新断句替换LLM纠错:Bug: although the program did send subtiles to LLM for reseg

5.83**0 Posted at: 1 hour ago

Win10/11 预打包版本:

win-pyvideotrans-v4.17-1028.7z

LLM重新断句替换LLM纠错:

Bug: although the program did send subtiles to LLM for resegmentation, the output video still use the uncorrected subtitles.

LLM Result Never Saved Back to File

16 Replies

#1 DeepSeek reply at 1 hour ago

知识库中未收录该问题的已知缺陷记录,因此无法直接确认为已知 bug。从描述现象(已发送至 LLM,但最终视频仍使用未纠错的字幕)看,问题很可能出在“LLM 返回结果未写回 srt 文件,或合成阶段复用了旧的字幕文件”这两处环节之一。请按顺序排查:

  1. 确认提示词文件存在:检查 软件目录/videotrans/prompts/resegment/llm_re.txt 是否存在且内容完整(该文件缺失或损坏会导致断句流程异常)。
  2. 确认纠错所用 AI 渠道可用:进入 菜单 → 工具/选项 → 高级选项 → 语音识别参数,检查 LLM纠错所用AI渠道 是否已正确配置 API Key 与模型(默认 DeepSeek);密钥错误或余额不足时,LLM 调用会失败,但字幕可能仍按原始结果继续流程。
  3. 强制清理旧缓存重跑:在主界面勾选 清理已生成 后再执行,避免复用上一次已生成的 srt 文件(_video_out/{视频名}-{后缀}/ 内的字幕)。
  4. 不要同时嵌入双字幕:重新断句会改变字幕条数,与原始字幕无法一一对应,选中 嵌入双字幕/双硬字幕 会加剧错位或使用原始字幕。
  5. 定位故障阶段:任务结束后打开输出文件夹 _video_out/{视频名}-{后缀}/,直接查看其中的 srt 内容:

    • 若该 srt 已是重新断句后的结果,而视频内字幕仍是旧的 → 属合成阶段取用了旧文件;
    • 若该 srt 仍是原始未纠错结果 → 属识别阶段 LLM 结果未写回文件。

请补充以下信息以便定位:软件完整版本号、所选 LLM 渠道与模型名称、logs/ 目录下对应日期日志文件 底部约 30 行(尤其是否出现 LLMSegmentError 或 API 返回错误),以及上述第 5 步中输出文件夹内 srt 的实际内容片段。

请查阅相关文档:

#2 5.83**0 reply at 1 hour ago


Application started at 2026-10-31 13:10:02

Loading resources...
Loading main window...
Initializing UI...
SetupUI end...
import recognition ...
import tts ...
import translate ...
Get cache ...
Set default value ...
import voices list ...
Set tts voice ...
[DEBUG] Version: v4.17, Frozen:True, OS: win32
上次缓存的角色:Andrew(Male/US),字幕嵌入类型:0,发音语言:英语,目标语言:英语,目标语言代码:en,模型:large-v3-turbo,TTS渠道[0]
show main window ...
Bind signal...
set cursor...
end
[DEBUG] app_cfg.proxy=''
[DEBUG] 可用 Nvidia 显卡数: 2
[DEBUG] 找到 2 个 Nvidia GPUs, 耗时: 16s
[DEBUG] cpu_count=20,app_cfg.MAX_GPU_PROCESS=1, app_cfg.MAX_CPU_PROCESS=6, task_nums=4
[DEBUG] start 33 jobs
[DEBUG] 无法连接 huggingface.co, 使用镜像替换: hf-mirror.com
[DEBUG] 平台: Windows。正在按优先级检测最佳的 'h264' 编码器: ['nvenc', 'qsv', 'amf']
[DEBUG] 正在测试编码器是否可用: h264_nvenc...
[DEBUG] 硬件编码器 'h264_nvenc' 可用。
[DEBUG] 264已选择硬件编码器: h264_nvenc
[DEBUG] 最终264确定使用的编码器: h264_nvenc
[DEBUG] 上次缓存的265编码器:app_cfg.codec_cache={'Windows-264': 'h264_nvenc
......
UG] [新进程任务 开始:title='Qwen3-ASR 1.7B']
[DEBUG] 新进程任务 参数:kwargs={'cut_audio_list': 'K:/pyVideoTrans/win-pyvideotrans-v4.17-1028/tmp/5688/b83d8ebe35/cut_audio_list_1793425270.9988205.json', 'logs_file': 'K:/pyVideoTrans/win-pyvideotrans-v4.17-1028/tmp/5688/b83d8ebe35/qwen3asrlocal-1793425270.9988205.log', 'model_name': '1.7B', 'local_dir': 'K:/pyVideoTrans/win-pyvideotrans-v4.17-1028/models/models--Qwen--Qwen3-ASR-1.7B-hf', 'local_dir_align': 'K:/pyVideoTrans/win-pyvideotrans-v4.17-1028/models/models--Qwen--Qwen3-ForcedAligner-0.6B-hf', 'hotword': '', 'min_speech_ms': 3000, 'max_speech_ms': 5000, 'force_align': True, 'detect_language': 'en', 'device_index': 0, 'device_name': 'auto'}
[DEBUG] GPU进程池:max_workers=1
[DEBUG] QwenASR:K:/pyVideoTrans/win-pyvideotrans-v4.17-1028/models/models--Qwen--Qwen3-ASR-1.7B-hf,Load 1.7B running on cuda:0,detect_language='en', force_align=True
[DEBUG] [新进程任务 title='Qwen3-ASR 1.7B'] 已返回
[DEBUG] [新进程任务 结束:title='Qwen3-ASR 1.7B'],耗时320.1187393665314s

videotrans\component\onlyone_set_recogn.py:246: RuntimeWarning: Failed to disconnect () from signal "mediaStatusChanged(QMediaPlayer::MediaStatus)".
[DEBUG] line_roles={}
[DEBUG] 文字配音前参数:[{'language': 'en'}, {'uuid': 'b83d8ebe35'}, {'play': False}, {'tts_type': 0}, {'is_cuda': True}, {'is_redubb': False}]
[DEBUG] self.volume='+0%', self.rate='+0%', self.pitch='+0Hz'

[DEBUG] 本次EdgeTTS配音:重试延迟:5,出错将重试:4,并发:10, 代理:None
[DEBUG] 所有配音任务结束。
[DEBUG] 本次配音 88 个成功, 0 个失败
[DEBUG] 本次 Edge-TTS(免费) 配音成功 88 个,失败 0 个
[DEBUG] 配音结束后,移除原始字幕中所有标点

[DEBUG] 开始语音视频字幕对齐处理:音频加速=False, 视频慢速=True
[DEBUG] 原始视频时长:self.raw_total_time=477133ms

#3 DeepSeek reply at 1 hour ago

这份日志显示本次运行中“LLM 重新断句”流程并未真正执行:Qwen3-ASR 1.7B 识别结束后(约 320 秒处返回),日志直接进入配音准备(文字配音前参数、本次EdgeTTS配音),中介没有任何 LLM 请求、提示词发送或断句返回的日志行,也没有 LLMSegmentError。因此配音与后续合成使用的自然是未经纠错的识别文本。你此前看到的“发送字幕给 LLM”可能来自另一次运行或另一个渠道,本次并未触发。

请按以下顺序核查:

  1. 确认主界面已勾选 LLM纠错 复选框。高级选项中的“使用 LLM 重新断句替代 LLM 纠错”只是在该复选框已勾选的前提下“替换”实现方式,不勾选 LLM纠错 则两者都不会执行——这与日志现象完全吻合。
  2. 检查 菜单 → 工具/选项 → 高级选项 → 语音识别参数 → LLM纠错所用AI渠道,确认所选渠道(默认 DeepSeek)的 API Key、模型名、余额均有效;密钥无效或模型名错误时该环节可能被跳过而不产生明显报错。
  3. 删除 tmp/translate_cache/ 下缓存,并在主界面勾选 清理已生成 后重跑,排除复用旧字幕文件。
  4. 若选中“使用 LLM 重新断句替代 LLM 纠错”,不要再嵌入双字幕/双硬字幕,断句会改变字幕条数,与原文无法对应。
  5. 另需注意:日志显示上次缓存的 字幕嵌入类型:0,即“不嵌入字幕”。若本次仍为该值,输出视频内本就不应存在任何内嵌字幕,你看到的“未纠错字幕”实际是配音所读的文本,与上述第 1 点原因是同一问题。

若确认已勾选 LLM纠错 且渠道可用,仍无断句效果,请提供软件安装目录 logs/ 下对应日期日志文件中「语音识别结束」至「文字配音前参数」之间的全部内容(约 50 行),以便判断是提示词环节还是结果写回环节的问题。

请查阅相关文档:

#4 5.83**0 reply at 1 hour ago

我的目的是使用未翻译的字幕,因为目标语言是同一种语言

#5 DeepSeek reply at 1 hour ago

源语言与目标语言相同时,翻译环节会被跳过,但“LLM 纠错/重新断句”属于语音识别阶段,与是否翻译无关,只要勾选了应当照常执行。所以问题不在“同语言”,而在下面三点:

  1. 日志中从未出现 LLM 请求记录:Qwen3-ASR 返回后直接进入“文字配音前参数”。这说明本次运行 LLM纠错 未勾选,或所选 AI 渠道鉴权失败被静默跳过。仅设置“使用 LLM 重新断句替代 LLM 纠错”而不勾选 LLM纠错,两者都不会执行。
  2. 字幕嵌入类型为 0(不嵌入字幕):日志明确写着“字幕嵌入类型:0”。此模式下最终视频本就不含任何内嵌字幕,你看到的只能是配音所读文本。要看到字幕必须选 嵌入软字幕 或 嵌入硬字幕。
  3. 同语言时源/目标字幕路径可能同名冲突:源语言代码与目标语言代码均为 en,识别字幕与目标字幕文件路径相同,存在被相互覆盖、写回丢失的可能,这与你的 “Never Saved Back to File” 现象吻合。

建议改用更可控的流程:

  1. 在左侧面板使用 语音转录 功能处理该视频,勾选 LLM纠错(或高级选项中的“使用LLM重新断句替代LLM纠错”),并在 高级选项 → 语音识别参数 → LLM纠错所用AI渠道 确认渠道、Key、模型可用。
  2. 转录完成后直接打开生成的 srt,确认内容是否为纠错后的结果。此步可独立验证“结果是否写回文件”。
  3. 回到 视频翻译,单视频模式下点击右侧 导入发音语言字幕,导入上一步的 srt,跳过识别环节。
  4. 目标语言设为与发音语言相同,配音角色正常选择,字幕嵌入类型改为 嵌入软字幕 或 嵌入硬字幕。
  5. 重跑前勾选 清理已生成,并清空 tmp/translate_cache/ 内缓存。

若第 2 步转录出的 srt 依旧是未纠错文本,请提供 logs/ 下对应日期日志中「语音识别结束」到「文字配音前参数」之间的全部内容(约 50 行),以判断是提示词环节还是写回环节的问题。

请查阅相关文档:

#6 5.83**0 reply at 1 hour ago

已经勾选 “LLM纠错” 和 “使用LLM重新断句替代LLM纠错”

#7 DeepSeek reply at 1 hour ago

日志已能排除配置遗漏:识别结束(Qwen3-ASR 1.7B 耗时 320s)后立即出现 onlyone_set_recogn.py 的警告,说明单视频编辑窗口随即打开;若 LLM 重新断句真的执行,此处应存在数百秒的 AI 请求耗时与请求日志。因此,要么代码路径在本次运行中跳过了该步骤,要么请求在无日志记录的情况下失败。请按以下顺序排查:确认设置已真正写入。高级选项修改后必须点击保存/确定关闭窗口;仅勾选复选框而未保存,params.json / cfg.json 不会更新。可打开 软件目录/videotrans/cfg.json 搜索 resegment 或 llm 相关键,确认取值为已启用。检查提示词文件是否存在且非空:软件目录/videotrans/prompts/resegment/llm_re.txt(重新断句用)与 llm.txt。文件缺失时该环节会异常或跳过,且不一定在控制台打印。检查 LLM纠错所用AI渠道 的实际可用性:高级选项 → 语音识别参数 → 该渠道(默认 DeepSeek)的 API Key、模型名、余额。密钥为空或鉴权失败时,部分渠道会静默返回原文而不报错。查文件日志而非控制台:打开 logs/ 下当日 .log,全文搜索 llm、resegment、纠错、batch 关键词,确认其中是否存在请求记录或用例异常堆栈。用独立功能验证,绕开单视频模式与同语言因素:左侧面板 语音转录,导入同一视频,勾选 LLM纠错(或重新断句选项),完成后查看生成的 srt 是否为纠错后文本。若此处正常 → 问题限定在“视频翻译 + 源语言=目标语言”这一代码路径;若此处同样无效 → 问题在 LLM 渠道或提示词环节。若上述均确认无误而视频翻译流程仍不执行断句,则高度疑似 v4.17 在源语言与目标语言相同时跳过翻译阶段、连带跳过后续处理环节的缺陷。请将 logs/ 当日日志文件完整内容反馈给开发者,并在标题中注明“源语言=目标语言时 LLM 重新断句未执行”。请查阅相关文档:修改提示词(Prompt)高级选项语音转录功能技术支持

#8 5.83**0 reply at 1 hour ago


Application started at 2026-10-31 13:10:02

Loading resources...
Loading main window...
Initializing UI...
SetupUI end...
import recognition ...
import tts ...
import translate ...
Get cache ...
Set default value ...
import voices list ...
Set tts voice ...
[DEBUG] Version: v4.17, Frozen:True, OS: win32
上次缓存的角色:Andrew(Male/US),字幕嵌入类型:0,发音语言:英语,目标语言:英语,目标语言代码:en,模型:large-v3-turbo,TTS渠道[0]
show main window ...
Bind signal...
set cursor...
end
[DEBUG] app_cfg.proxy=''
[DEBUG] 可用 Nvidia 显卡数: 2
[DEBUG] 找到 2 个 Nvidia GPUs, 耗时: 16s
[DEBUG] cpu_count=20,app_cfg.MAX_GPU_PROCESS=1, app_cfg.MAX_CPU_PROCESS=6, task_nums=4
[DEBUG] start 33 jobs
[DEBUG] 无法连接 huggingface.co, 使用镜像替换: hf-mirror.com
[DEBUG] 平台: Windows。正在按优先级检测最佳的 'h264' 编码器: ['nvenc', 'qsv', 'amf']
[DEBUG] 正在测试编码器是否可用: h264_nvenc...
[DEBUG] 硬件编码器 'h264_nvenc' 可用。
[DEBUG] 264已选择硬件编码器: h264_nvenc
[DEBUG] 最终264确定使用的编码器: h264_nvenc
[DEBUG] 上次缓存的265编码器:app_cfg.codec_cache={'Windows-264': 'h264_nvenc
......
if you want to upload your tutorial or you want to explore that is somebody's already uploaded tutorial, we give you access to that.", start_time=439304, end_time=451487, startraw='00:07:19,304', endraw='00:07:31,487', line=24, time='00:07:19,304 --> 00:07:31,487', spk='', filename=''), SrtItem(text="If you are not able to solve a certain tutorial, you can adapt from that area and go ahead and finish all the tutorials. But make sure, unless you finish the tutorial for all the sessions, number one, don't go towards session two, three, four, five.", start_time=451487, end_time=465857, startraw='00:07:31,487', endraw='00:07:45,857', line=25, time='00:07:31,487 --> 00:07:45,857', spk='', filename=''), SrtItem(text="So, like that way, we're going to proceed. Again, thank you very much for choosing our online training program. Thank you.", start_time=465857, end_time=472416, startraw='00:07:45,857', endraw='00:07:52,416', line=26, time='00:07:45,857 --> 00:07:52,416', spk='', filename='')]

videotrans\component\onlyone_set_recogn.py:246: RuntimeWarning: Failed to disconnect () from signal "mediaStatusChanged(QMediaPlayer::MediaStatus)".
self.video_player.mediaStatusChanged.disconnect(self._on_media_ready)
[DEBUG] line_roles={}
[DEBUG] 文字配音前参数:[{'language': 'en'}, {'uuid': 'b83d8ebe35'}, {'play': False}, {'tts_type': 0}, {'is_cuda': True}, {'is_redubb': False}]
[DEBUG] self.volume='+0%', self.rate='+0%', self.pitch='+0Hz'

[DEBUG] 本次EdgeTTS配音:重试延迟:5,出错将重试:4,并发:10, 代理:None
[DEBUG] 所有配音任务结束。
[DEBUG] 本次配音 59 个成功, 0 个失败
[DEBUG] 本次 Edge-TTS(免费) 配音成功 59 个,失败 0 个
[DEBUG] 配音结束后,移除原始字幕中所有标点

#9 DeepSeek reply at 1 hour ago

根据这段日志可以确认:Qwen3-ASR 1.7B 返回的原始 SrtItem 列表(26 行,含 12 秒以上的长句)被直接打印,紧接着弹出单视频编辑窗口 onlyone_set_recogn,随后进入配音。整个过程中没有任何 LLM 请求、提示词发送或返回记录的日志,也没有异常堆栈。这证明该环节在本次运行中根本没有执行,配置本身可能已经生效。

最可能的两个原因(需按顺序验证):

  1. 识别渠道分支不含 LLM 纠错。你使用的是 Qwen-ASR(内置),而非默认的 faster-whisper。请将语音识别改为 faster-whisper(内置) + large-v3-turbo,保持 LLM纠错 与 使用LLM重新断句替代LLM纠错 勾选,用同一视频重跑。若 faster-whisper 下出现 AI 请求耗时与断句结果、而 Qwen-ASR 下始终没有,即可确定该渠道未接入纠错流程。
  2. 源语言与目标语言相同导致流程跳过。日志显示发音语言与目标语言均为英语(en)。请做一组对照:将目标语言临时设为其他语言(如中文),再跑一次。若此时 LLM 断句出现,则为“同语言”路径的缺陷。

可用规避方案(立即恢复工作):

  • 左侧面板 语音转录 → 导入该视频 → 勾选 LLM纠错(及重新断句选项)→ 完成后打开生成的 srt 检查是否为纠错后文本。
  • 回到 视频翻译,单视频模式下用右侧 导入发音语言字幕 载入该 srt,跳过识别环节,目标语言设为英语,正常配音。
  • 注意日志中 字幕嵌入类型:0(不嵌入字幕),这样输出视频内不含任何字幕。若需看到字幕,请在同步对齐行改选 嵌入软字幕 或 嵌入硬字幕。

若上述两组对照中任一组恢复正常,请将结论反馈给开发者;若两组均无 LLM 断句执行,请附上 logs/ 当日日志完整文件,注明“v4.17 冻结版,已勾选 LLM纠错与重新断句,Qwen-ASR 渠道下该环节未执行”。

请查阅相关文档:

#10 5.83**0 reply at 1 hour ago

我的系统分析结果如下,请判断:

The Safety Check Is Rejecting the LLM Result
The LLM did run (59 → 26 lines), but the safety check in _base.py rejected it:

if srt_list and len(srt_list) > len(raw_subtitles) / 2: # 26 < 29.5 → FAIL

return srt_list

Falls through → returns original raw_subtitles

The LLM merged too aggressively (59 segments → 26), dropping below the 50% threshold. The _save_srt_target fix is correct but irrelevant here because _llmpost never returns the LLM result when the check fails.

Fix: Constrain the LLM's Merging
Edit K:\pyVideoTrans\win-pyvideotrans-v4.17-1028\videotrans\prompts\resegment\llm_re.txt and add this rule to the SEGMENTATION & EDITING RULES section:

  1. Merge Limit: Do NOT merge more than 3 adjacent blocks into a single output block.
    The total output line count must not drop below 50% of the input line count.

This prevents the LLM from over-merging and ensures the safety check passes.

#11 DeepSeek reply at 1 hour ago

该分析方向与知识库中的既有说明相符:知识库明确指出“使用 LLM 重新断句后,字幕的条数必然与原始字幕不匹配”,说明软件内部确实存在针对条数变化的校验逻辑;但知识库未收录 _base.py 中这个 50% 阈值的实现,因此无法确认其具体数值、比较对象(行数还是字数)以及调用位置。

判断:假设成立与否,取决于一项关键证据,而当前日志尚不足以支持该结论。

日志中存在一处矛盾,需先澄清:若 _llmpost 因校验失败返回原始字幕,则随后配音应为 59 条,打印的 SrtItem 列表也应止于 line=59。但实际打印列表止于 line=26,而日志又写“本次配音 59 个成功”。两者若来自同一次运行,则说明配音所用字幕与打印列表不是同一份数据;若来自两次运行拼接,则“59 → 26”的前提不成立。请先确认三者条数是否一致:单视频编辑窗口显示的条数、配音条数、输出 srt 条数。

验证方法(按顺序):

  1. 打开输出文件夹 _video_out/{视频名}-mp4/,查看 en.srt(源语言与目标语言均为 en)的实际行数。若为 59 条,则为原始字幕,支持“LLM 结果被丢弃”的判断;若为 26 条,则 LLM 结果已写入文件,问题出在合成阶段取用了旧字幕。
  2. 进入 软件目录/tmp/,查找本次 uuid b83d8ebe35 目录内的中间字幕文件,对比其行数与最终 en.srt 行数。

可执行的规避手段:

  1. 按你的思路修改 软件目录/videotrans/prompts/resegment/llm_re.txt,在断句规则段加入合并上限与最低保留比例的要求。修改前备份原文件,切勿删除或改动其中被 {} 包裹的变量,否则程序无法正常替换。
  2. 同时降低合并诱因:菜单 → 工具/选项 → 高级选项 → 语音识别参数 → LLM纠错每批字幕行数 由默认 20 调小(如 10),减少模型一次性跨段合并的机会;并在 LLM纠错所用AI渠道 中换用指令跟随更强的旗舰模型。
  3. 该 50% 阈值若确认为硬编码且不可配置,需反馈开发者,建议其提供可调参数或对“重新断句”模式放宽限制。

请反馈结论时附上:输出文件夹内 en.srt 的行数、tmp/ 下对应 uuid 目录内的中间字幕文件、以及 logs/ 当日日志中「语音识别结束」至「文字配音前参数」之间的完整内容(约 50 行)。

请查阅相关文档:

#12 5.83**0 reply at 1 hour ago

Role:
You are an expert Multi-Language ASR Post-Editor and Subtitle Specialist. Your objective is to correct ASR errors, merge/split subtitles for natural reading flow, and precisely recalculate timestamps from the input SRT.


CORE OBJECTIVES

  1. ASR Correction: Correct homophones, typos, and missing punctuation based on audio context/semantics. Remove speech disfluencies (stutters, repeated words caused by recognition errors) without altering the original meaning.
  2. Remove filler words: Remove meaningless filler words in the middle of a sentence.
  3. Lossless Semantic Preservation: Do NOT summarize, shorten, or drop any meaningful information.
  4. Smart Re-segmentation (Merge & Split):

    • Merge fragmented, short (< 1.0s), or grammatically incomplete adjacent blocks.
    • Split overly long blocks (> {max_speech_s} seconds) at natural semantic/syntactic boundaries.
  5. Target Duration: Ensure every output subtitle block ideall
    ......
    sentences at punctuation marks, pauses, or logical phrase boundaries.
  6. One-Line Rule: Every SRT subtitle entry must contain EXACTLY ONE line of text (no internal line breaks \n).
  7. Merge Condition: If an original block is incomplete or < 1.0s, merge it with adjacent blocks to form a complete syntactic unit.
  8. Split Condition: If a block exceeds {max_speech_s} seconds, split it at a clause boundary or comma. Never split compound words, proper nouns, or tightly bound grammatical units.
  9. Merge Limit: Do NOT merge more than 3 adjacent blocks into a single output block.
    The total output line count must not drop below 50% of the input line count.

TIMING CALCULATION RULES (CRITICAL)

LLMs must strictly obey chronological timeline constraints:

  1. Anchor Points:

    • When merging multiple blocks, the StartTime is the StartTime of the first block, and the EndTime is the EndTime of the last block.
  2. Proportional Splitting:

    • When splitting a merged cluster of duration $T_{total}$ into $N$ parts, calculate each sub-block's duration proportionally based on character count (or word count for Latin languages):
      $$\text{Duration} \approx T_{total} \times \frac{\text{Length of Sub-text}}{\text{Total Length}}$$
  3. Timeline Integrity:

    • No Overlaps: Subtitle $N$ EndTime must be $\le$ Subtitle $N+1$ StartTime.
    • Strictly Increasing: Timestamps must always advance forward: 00:00:01,000 --&gt; 00:00:03,500.
    • Standard SRT timecode format is mandatory: hh:mm:ss,mmm (e.g., 00:01:23,456).

OUTPUT FORMAT RULES

  1. Renumber all subtitle indices sequentially starting from 1.
  2. NO explanatory text, NO markdown notes, NO chat.
  3. Enclose the final SRT content entirely within and tags.

Format template:

1
00:00:00,120 --> 00:00:02,450
Corrected text line 1

2
00:00:02,450 --> 00:00:05,100
Corrected text line 2


Input SRT:

#13 DeepSeek reply at 1 hour ago

判断:该改法方向正确,但当前这份提示词文本不能直接整段覆盖进文件,存在三处会导致流程失效的风险,须先修正。

一、必须确认保留动态变量
知识库明确:videotrans/prompts/resegment/llm_re.txt 中以花括号包裹的是动态变量(如 {max_speech_s}、{batch_input} 等),程序运行时自动替换,删除或改写会导致替换失败、输入为空或输出异常。
你贴出的文本中可见 {max_speech_s} 仍在,但正文以 Input SRT: 结尾,未见 {batch_input} 之类的输入占位符;且正文含大量 ...... 省略号。若这段省略文本被写入文件,提示词结构已损坏。

二、正确做法:只插入,不整体替换

  1. 先备份:复制 llm_re.txt 为 llm_re.txt.bak。
  2. 用记事本打开原文件,仅在 SEGMENTATION & EDITING RULES 段落内、原有条目之后,追加两行:

    Merge Limit: Do NOT merge more than 3 adjacent blocks into a single output block.
    The total output line count must not drop below 50% of the input line count.
  3. 不改动任何 {} 变量,不改动文件开头结尾的 <srt> / </srt> 标签结构,不引入省略号或未闭合标签。
  4. 保存为 UTF-8。

三、你贴出的文本中另有两点需注意

  • 若原文件中的变量在正文中间(如 Target Duration ... {max_speech_s} 秒),追加规则时不得打乱其位置。
  • One-Line Rule(每条字幕仅一行)与软件的“中日韩/其他语言字幕单行字符数”换行设置不冲突,但需保证模型不返回内部换行,否则断句结果解析可能失败。

四、单靠提示词不保证通过校验
你推断的 50% 阈值若为硬编码,提示词只是降低触发概率。同时建议:

  1. 高级选项 → 语音识别参数 → LLM纠错每批字幕行数 由 20 调小到 10,减少模型跨段大规模合并的诱因。
  2. LLM纠错所用AI渠道 换用指令跟随更强的在线旗舰模型,避免本地小模型无视合并上限。
  3. 重跑前勾选 清理已生成,并清空 tmp/translate_cache/,防止复用旧字幕。

五、验证是否生效

  1. 重跑后打开 _video_out/{视频名}-mp4/,用文本编辑器查看 en.srt 实际行数。若仍为 59 行(即原始条数),说明 LLM 结果依旧被校验丢弃,提示词未解决根本问题。
  2. 查看 logs/ 当日日志中「语音识别结束」至「文字配音前参数」之间内容,确认是否出现 LLM 请求耗时与返回记录。
  3. 检查 tmp/ 下 uuid 对应目录内的中间字幕文件行数,与最终 en.srt 对比。

六、若确认阈值硬编码且不可调
需反馈开发者,请求为“重新断句”模式提供可配置的条数保留比例,或放宽该下限。反馈时请附:修改后的 llm_re.txt 内容、en.srt 行数、tmp/ 内中间字幕行数、以及日志对应段落。

临时可用方案(不依赖该阈值):

  1. 用左侧 语音转录 功能单独生成 srt,勾选 LLM纠错。
  2. 在 视频翻译 单视频模式下,用右侧 导入发音语言字幕 载入该 srt,跳过识别环节。
  3. 注意日志中 字幕嵌入类型:0 为不嵌入字幕,如需输出视频中显示字幕,请改选 嵌入软字幕 或 嵌入硬字幕。

请查阅相关文档:

#14 Admin reply at 1 hour ago

LLM重新断句后会判断新的字幕行数是否大于原始字幕行数的 1/2,如果是,则视为有效并使用,如果否,说明重新断句与原始字幕差异太大,视为重新断句无效,直接舍弃。

看日志应原始 59行字幕,26低于 29.5,因此舍弃了。

#15 5.83**0 reply at 4 minutes ago

在 视频翻译 单视频模式如何使用

#16 DeepSeek reply at 4 minutes ago

开发者已确认该阈值机制:重新断句后的行数须大于原始行数的一半(59 → 需 ≥ 30 行),否则整份结果被舍弃。26 行必然被丢弃。单视频模式的作用是让这次舍弃变成“可人工介入”的环节。

一、进入单视频模式的前提

  1. 点击 选择视频或音频,只选一个文件(选多个即进入批量模式,不弹编辑窗口)。
  2. 发音语言 与 目标语言 均设为英语。两者相同时翻译阶段被跳过,这是正常的。
  3. 语音识别 选 faster-whisper(内置) + large-v3-turbo(你之前用的 Qwen-ASR 在日志中未体现纠错耗时,改用默认渠道便于观察)。
  4. 勾选 LLM纠错,并勾选高级选项中的 使用LLM重新断句替代LLM纠错。
  5. 把 字幕嵌入类型 从当前的 0(不嵌入字幕) 改为 嵌入软字幕 或 嵌入硬字幕。否则最终视频内不含任何字幕,你无法核对结果。
  6. 勾选 清理已生成,避免复用上次的 srt。

二、阶段一:识别完成后的字幕编辑窗口(核心环节)

识别结束(约 5-8 分钟)后会弹出 onlyone_set_recogn 窗口,此处显示的字幕条数即最终将被采用的结果:

  1. 先点右上角的倒计时按钮关闭倒计时,否则倒计时归零后窗口自动关闭并继续下一步。
  2. 观察行数。若窗口内是 59 行而非 26 行,说明 LLM 结果确已被阈值丢弃,此时有两种处理:

    • 直接在窗口内编辑:带有铅笔图标的列双击可改时间;字幕文本双击可改内容。可用它手动合并邻近短句、修正错词。
    • 用外部编辑器改(更高效):点窗口内 打开字幕文件夹,找到 en.srt,用 Notepad++ 等编辑器手动合并/修正,保存后回到窗口点 不保存只继续。后续流程将使用你修改后的文件。
  3. 若窗口内已是 26 行(说明阈值已通过),无需改动,点 不保存只继续 即可。
  4. 不修改则直接点 不保存只继续。

三、后续阶段

  • 阶段二(配音角色分配):同语言时通常无实质内容,点关闭倒计时后继续。
  • 阶段三(配音校对):每一行有播放、开始时间、结束时间、配音时长、字幕六列。若某行显示 <超出>,可延长结束时间或删减文字后右键 重新配音。
  • 若勾选了 二次识别,结束时会再弹一次字幕编辑窗口,可修正错别字后保存。

四、从根本上避免被丢弃

在 软件目录/videotrans/prompts/resegment/llm_re.txt 中追加约束(仅插入,不改动任何 {} 变量):

Merge Limit: Do NOT merge more than 3 adjacent blocks into a single output block.
The total output line count must not drop below 50% of the input line count.

同时把 高级选项 → 语音识别参数 → LLM纠错每批字幕行数 由 20 调小到 10,减少模型跨批大规模合并的机会。

五、另一条不依赖该阈值的路径

  1. 左侧面板 语音转录 → 导入该视频 → 勾选 LLM纠错 → 完成后打开生成的 srt 核对内容。
  2. 回到 视频翻译,单视频选中同一视频,点击主界面右侧字幕区底部的 导入发音语言字幕(或 导入目标语言字幕),载入上一步的 srt。这会跳过语音识别,也就绕开了阈值校验。
  3. 目标语言设为英语,正常配音并选择字幕嵌入类型后执行。

注意:导入字幕 按钮仅单视频模式有效,批量模式不可用;且导入后不要勾选 清理已生成,否则会清空该字幕文件。

请查阅相关文档:

Thinking...
Post Your Reply
If you have more than 50 messages, you will no longer receive an automatic reply. Please ask a new question!
Open source and free maintenance is not easy. If this project is helpful to you, please consider making a small donation to help the project continue to maintain and update.

Dondate via ko-fi.com

Related resource