#4947 LLM重新断句问题好多~!

2409:8a55* Posted at: 12 days ago

重新断句后,句子的起止时间竟然被改了,导致后边所有的字幕都晚半拍或早半拍

还有断句过程会把长的句子拆分为两句,这个拆分好像是按标点拆的,但是怎么推断时间戳的拆分点的?是除以字数算的吗?

33 Replies

LLM重新断句导致时间偏移,是因为断句后软件会基于原始字幕的时长,按新分句的文本字符数(或字节数)比例线性分配起止时间。当长句被拆成多个短句时,这种线性分配会因标点位置、语速差异引入微小误差,累积后就出现整体提前或滞后。

要减少偏移,建议:

  1. 在“菜单 → 工具 → 高级选项 → 语音识别参数”中调整:

    • 最短语音持续毫秒设为 1000,最长语音持续秒数设为 5~6,静音分割持续毫秒设为 200~400
    • 启用合并过短字幕到邻近
    • 关闭“Whisper预分割音频”(若未使用clone配音)
  2. 如果偏移仍然严重,可在同一页面将LLM重新断句改为默认断句,或直接取消该功能,并配合VAD和参数优化实现更好的断句。
  3. 若使用了配音,可以勾选主界面的二次识别,重新对配音音频进行ASR以生成精准时间轴。

对于“时间戳拆分点是不是除以字数算的”——是的,软件默认按新分句和原分句的字符(或字节)比值来线性映射时间轴,不涉及VAD重新检测,因此累积误差不可避免。如果对时间精度要求高,建议关闭LLM断句,改用VAD+参数细调,或单视频交互模式手动修改字幕。

请查阅相关文档:

Whisper预分割音频 起什么作用?

Whisper预分割音频 的作用是:在将音频送入 Whisper 模型进行语音识别之前,先使用 VAD(语音活动检测)将音频预先切成多个短语音片段,然后再将这些片段分别发给 Whisper 识别。

  • 选中时:VAD 自动分割音频,Whisper 只处理短片段,生成的句子通常较短、断句较准,且字幕时长更均匀。适合需要短字幕的场景,尤其是使用 clone 配音角色时,可确保每个参考音频片段时长在 3-10 秒之间,提高克隆成功率。
  • 不选中时:Whisper 直接处理完整长音频,由其内部逻辑自动断句,生成的句子可能较长,断句效果不稳定,有时需要再配合 VAD 参数调整。

简单来说:选中 → 更精细的 VAD 切分,字幕较短、适合克隆;不选中 → Whisper 自行断句,可能稍长,但灵活性更高。

LLM重新断句导致时间偏移,是因为断句后软件会基于原始字幕的时长,按新分句的文本字符数(或字节数)比例线性分配起止时间。当长句被拆成多个短句时,这种线性分配会因标点位置、语速差异引入微小误差,累积后就出现整体提前或滞后。

拆多少句都无所谓,算字符平均时间来决定时间戳分割点也很合理,但这个长句子拆分后的短句,第一句的起始时间和最后一句的终止时间,应该严格与原长句决对吻合才对吧

您说得对,理论上拆分后第一个短句的起始时间和最后一个短句的终止时间应该严格等于原句的起止时间,这样才能保证整体时间轴不偏移。软件按字符比例线性分配时,确实会保持边界不变,只是内部分割点按比例计算。

但实际出现整体提前或滞后,常见原因有以下几种:

  1. LLM 修改了原文:AI 在重新断句时可能顺带修了错别字、补充了标点或改变了句子措辞,这会导致原文的字符数发生变化。比如原句有 20 个字符,LLM 返回了 19 个字符(少了一个句号),分配比例就会整体左移或右移,从而让第一句开始时间或最后一句结束时间发生微调。
  2. 浮点数精度累积:当长句被拆成很多短句时,起始时间和结束时间用浮点数表示,频繁的乘除运算会引入微小的舍入误差。虽然误差很小,但若后续字幕大量重叠或合并,误差会累积并在视觉上表现为偏移。
  3. 软件内部的额外处理:某些情况下,软件为了保证字幕之间不重叠,或者满足最短语音持续时间(如 1000ms)限制,可能会对边界进行微调(例如将前一行的结束时间向后推几毫秒,或后一行开始时间向前拉),这也会导致边界改变。

建议排查方式

  • 在日志文件(logs/ 目录)中搜索对应的视频名称,找到 LLM 重新断句前后的字幕内容,对比字符数和时间戳,看边界是否完全一致。
  • 如果不一致,说明是 LLM 修改了文本内容导致比例变化。可尝试在菜单 → 工具 → 高级选项 → 通用设置中,将“LLM重新断句每批字幕行数”适当增大(比如设为全部行数),以减少分批处理带来的不一致性。

如果偏移严重且无法忍受,推荐关闭 LLM 重新断句,改用默认断句 + 优化 VAD 参数(调整最短/最长语音持续时间和静音分割毫秒),配合 Whisper预分割音频 功能,通常能取得更稳定的断句效果。

怎样通过提示词,确保边界不变?

LLM 重新断句的提示词位于 videotrans/prompts/recharge/recharge-llm.txt 文件中。您可以手动编辑该文件,在现有提示词末尾添加明确约束,要求 AI 严格保持每条字幕的起止时间边界不变,例如:

注意:你只能对字幕文本进行断句处理(拆分或合并句子),不得修改原始文本的字符内容(包括标点符号)。输出的 SRT 格式中,每一块字幕的起止时间必须与输入严格保持一致。

修改后保存,重启软件使提示词生效。

但需要知道:即使提示词要求不修改文本,LLM 仍可能自行修正错别字、标点或删减空格,导致字符数变化,软件依然会按比例重新分配时间,边界仍可能偏移。

更彻底的解决方式是:关闭 LLM 重新断句(在“菜单 → 工具 → 高级选项 → 通用设置”中选择“默认断句”),然后通过优化 VAD 参数和开启“Whisper预分割音频”来获得稳定的断句结果。若对时间精度要求极高,推荐使用单视频交互模式,在字幕编辑窗口中手动调整。

边界怎么会偏移呢,比如原本时间大概是5秒钟,有10个字,每个字5/10=0.5秒,如果LLM断句后变成8个字,那不过是5/8=0.625秒,只是每个字分摊的时间变了,整个句子的起止时间可以保持不变的

您说得完全正确。如果严格按原始起止时长和字符比例线性分配,不论文本缩短还是加长,整个句子的 T_startT_end 边界应该纹丝不动。软件实现中的分配逻辑确实是边界不变,只调整内部分割点。实际观察到的时间偏移,通常是由以下两个原因之一引起的,而不是比例分配算法本身:

1. LLM 直接修改了时间戳

默认提示词只要求对文本进行断句,但部分大模型不受控地自行生成了新的时间信息(比如在输出中写了 00:00:01,000 --> 00:00:02,500 等),软件若误将 AI 返回的时间戳当作新字幕的起止时间使用,就会导致边界偏移。

检查方法:在 logs/ 目录找到对应任务日志,搜索 recharge-llm 关键字,查看 LLM 返回的原始 JSON/SRT 数据,确认时间戳是否与输入一致。

解决办法:修改提示词(recharge/recharge-llm.txt),在末尾明确加上:

严禁修改任何时间轴信息。保持输入 SRT 中的每条字幕起止时间绝对不变。只调整文本内容和行数,时间轴必须严格沿用输入值。

2. 软件内部对时间轴的后处理

即使边界在 LLM 断句阶段不变,后续阶段(如配音对齐、帧级别调整、视频慢速/音频加速、或合并过短字幕等操作)也可能主动修改时间轴。例如:

  • 开启了“音频加速”或“视频慢速”,软件会强制拉长或缩短字幕时间以匹配配音;
  • 开启了“移除字幕间静音”或“对齐字幕声音”,会调整相邻字幕的偏移;
  • 设定了“最短语音持续毫秒”(如 1000ms),若某条新字幕时长太短,软件会将其合并到相邻字幕,导致时间轴变化。

这些后处理与 LLM 断句本身无关,但会被用户误认为是断句导致的偏移。

排查方法:在单视频交互模式下处理一个视频,当 LLM 断句完成后(弹出字幕编辑窗口时),立即检查时间轴是否偏移。如果此时边界正确,则说明后续操作导致偏移;如果此时已偏移,则说明是 LLM 或软件分配阶段的问题。

总结

  • 比例分配算法本身不会偏离边界,您的推论是对的。
  • 偏移的根源:要么是 LLM 擅自改动了时间字段,要么是后续阶段(如配音、对齐、合并)干预了时间轴。
  • 最稳妥的解决:关闭 LLM 重新断句,改用 VAD + “Whisper预分割音频” + 手动调整参数,或使用单视频交互模式手动校验时间轴。

如果严格按原始起止时长和字符比例线性分配,不论文本缩短还是加长,整个句子的 T_start 和 T_end 边界应该纹丝不动。软件实现中的分配逻辑确实是边界不变,只调整内部分割点。
将上面的文字设计成Deepseek能理解的英文提示词,重点强调时间轴起始和结束时间不得修改!即便是分割成几行,也要保证第1条分割句的开始时间要100%与原字幕起始时间吻合,还有最后一条分割句的结束时间也要100%与原字幕结束时间吻合

DeepSeek 理解的英文提示词

将以下内容添加到 videotrans/prompts/recharge/recharge-llm.txt 文件末尾(或作为新配置的提示词,通过“高级选项”中的“LLM重新断句所用AI渠道”设置对应的提示词文件):

You are a professional subtitle editor. Your task is to re-segment or merge sentences in the provided SRT subtitle text to improve readability and natural phrasing. You must follow these strict rules:
1. **Never modify any timestamp** (start_time and end_time) in the input SRT. Keep the original timestamps absolutely unchanged for each block.
2. When splitting a long sentence into multiple lines, the **start_time of the first resulting block** must be **exactly the same** as the start_time of the original block. The **end_time of the last resulting block** must be **exactly the same** as the end_time of the original block.
3. When merging multiple sentences, the start_time of the merged block must be the start_time of the first original block, and the end_time must be the end_time of the last original block.
4. Do not alter the text content except for segmentation or merging (e.g., do not correct typos, add punctuation, or change wording). Only adjust line breaks and block boundaries.
5. Output the result strictly in valid SRT format (block numbers, timestamps, text lines).
6. Preserve the original language and encoding.

Input SRT:

使用说明

  • 将上述提示词复制粘贴到 recharge-llm.txt 文件开头(或覆盖原有内容),保存后重启软件。
  • 若希望保留原有提示词,可将该段文字追加到现有提示词末尾,并在最后添加 Now process the following SRT: 作为结束。
  • 如果 DeepSeek 渠道未使用该提示词文件(即代码中写死的提示词),请通过菜单 → 工具 → 高级选项 → 通用设置,将“LLM重新断句所用AI渠道”设为 DeepSeek,并确保软件读取的是 recharge-llm.txt 文件中的内容(该文件路径固定在 videotrans/prompts/recharge-llm.txt)。

此提示词已明确要求时间轴绝对不变,且格式符合 DeepSeek 的理解习惯。

  1. Max line length:

    • CJK: ~50 characters
    • Latin/others: ~100 characters

这条规则中的每行字数限制是指原始语种的字数吗?比如我想把视频中的英语译成国语,那这条规则针对的是原始语(英语)吗

该规则中的每行字数限制是针对 原始语言(即发音语言) 的。

LLM 重新断句发生在语音识别之后、字幕翻译之前,此时处理的字幕是原始语言(例如英语),因此 Latin/others: ~100 characters 作用于英语字幕。翻译后的目标语言(如中文)的字幕单行字符数不受该提示词控制,而是由软件主界面 → 设置更多参数 → “中日韩字幕单行字符数”(默认 20~50 字符)或菜单 → 工具 → 高级选项 → “中日韩字幕单行字符数” 独立设置。

所以:翻译后中文单行字幕长度限值需在高级选项中单独调整,与 LLM 断句提示词无关。

我设置的Latin/others: ~100 characters,但是看到LLM之后的断句中,有些行中的英文字符有190的,有150以上的

原因:LLM 并不严格遵循提示词中的长度限制,尤其是当句子语义完整时,模型倾向于优先保持句子完整性而忽略长度约束。提示词中的 ~100 characters 只是建议性约束,并非强制规则。排查步骤:检查提示词是否生效——在 logs/ 目录找到对应任务的日志文件,搜索 LLM 断句相关的日志行,确认软件实际发送给 AI 的提示词内容是否包含您修改后的 ~100 characters 规则。如果日志中显示的是旧的默认提示词(CJK: ~25 characters / Latin: ~50 characters),说明软件读取的不是您修改后的文件,或者缓存未更新。修改提示词措辞——将 ~100 characters 改为不超过80个字符 或 每行必须有强制换行符,例如:强制换行:确保每行文本不超过80个字符。超出时必须在单词边界进行硬换行。关键点:每行字符数必须严格限制在80以内,不得出现超过80字符的行。设置软件内的“其他语言字幕单行字符数”——打开菜单 → 工具 → 高级选项 → 字幕声音画面对齐,找到“其他语言字幕单行字符数”并将其设为 80。此设置会在 LLM 断句结果返回后,对超过该值的行进行强制折行(由软件内部处理,而不仅仅依赖 AI 提示词)。如果以上方法仍无法确保限制,关闭 LLM 重新断句,改用默认断句 + 优化 VAD 参数(缩短最长语音持续秒数)来控制字幕行长度,或使用单视频交互模式手动调整。

这个字符数包括哪些,空格算字符吗

Max line length 规则以及软件内“其他语言字幕单行字符数”设置中,字符数包含空格。计算方式为:该行字符串的 len()strlen() 结果,空格作为一个字符计入。例如一段英文字幕 "Hello world" 长度是 11 个字符(包括中间的空格)。如果长度超过设定值,软件会在单词边界处自动换行。

SEGMENTATION RULES (CRITICAL)

  1. If an original block contains multiple sentences or is longer than {max_speech_s} seconds,

    • split into multiple sub-lines.
    • Prioritize breaking sentences at punctuation marks

解释这几条的含义

这几条规则的含义如下:

  1. If an original block contains multiple sentences or is longer than {max_speech_s} seconds
    如果一个原始字幕块内包含多个完整的句子(即该块文本由两个或以上的句子组成),或者该块的时长超过了设定的最大语音持续时间(例如默认6秒),就必须进行拆分。
  2. split into multiple sub-lines
    把该块拆分成多个独立的字幕行(每个子块对应一条字幕)。
  3. Prioritize breaking sentences at punctuation marks
    拆分时应优先在句子标点符号(如句号、问号、感叹号、逗号等)处断开,以保证拆出的每个子块都是语义完整的自然断句,避免在单词中间或句子中间硬性切断。

简单说:当字幕块太长(字数多或时间长)时,要将其拆成更短的句子,且尽量按照标点符号来切,这样读起来才通顺。

根据LLM的提示词,列出有可能导致LLM失败的所有原因

根据提示词结构和实际使用反馈,导致 LLM 重新断句失败或效果异常的原因包括以下几个方面:

  1. API 配置错误

    • 未在“菜单 → 翻译设置”中正确填写 DeepSeek / OpenAI 等 AI 渠道的 API Key。
    • API 地址(Base URL)填写错误(如缺少 /v1 后缀、端口错误)。
    • 网络代理未配置或配置错误(国外 AI 渠道需要代理)。
  2. 输入超出模型限制

    • “LLM 重新断句每批字幕行数”设置过大,导致单次请求的提示词长度超过 AI 模型的上下文窗口(如 DeepSeek 的 4096 token 上限)。
    • 原始字幕文本过长(如包含大量长句或特殊符号),超出模型处理能力。
    • 批次处理后端超时(如 API 请求等待超过 60 秒未返回)。
  3. 提示词本身缺陷

    • 默认提示词中的 {max_speech_s} 变量未正确替换(软件未传入实际值),导致 AI 收到非法参数。
    • 提示词中字数限制或标点优先规则被 AI 忽略(模型优先保持语义完整,不强制执行长度)。
    • 提示词未要求保留原始时间轴,AI 可能自主生成新时间戳,导致边界偏移或格式错误。
  4. AI 模型行为不可控

    • 模型擅自修改原文文本(纠正拼写、删除标点、添加内容),违反“不得删除任何有意义信息”的规则。
    • 模型输出格式不正确(缺少 <SRT> 标签、时间轴格式错误、编号不连续)。
    • 模型输出内容包含多余解释或对话,导致解析失败。
    • 模型对非英语语言(如中文、日语)的断句能力弱,产生漏分或误分。
  5. 软件逻辑限制

    • LLM 返回结果后,软件内部可能根据“最短语音持续毫秒”合并过短字幕,导致边界改变。
    • “合并过短字幕到邻近”选项开启时,会进一步修改 LLM 的断句结果。
    • 后续阶段(配音、对齐、视频慢速)主动调整时间轴,与 LLM 断句结果冲突。
  6. 并发与限流

    • 同时发送多个 LLM 请求,触发 API 限流(如 DeepSeek 免费版每分钟有限次)。
    • 请求间隔设置过短(“翻译后暂停秒”设为 0),导致 API 返回 429 或超时错误。
  7. 缓存问题

    • 软件启用了翻译缓存(MD5 缓存),当相同文本再次请求时直接返回旧结果,而旧结果可能来自不同版本的提示词。
    • 未清除“清理已生成”缓存时,断句结果与实际音频不匹配。
  8. 其他

    • 视频原始语言选择错误,导致提示词中的语言要求与实际不匹配。
    • 日志中未正确记录 LLM 请求与响应,难以排查。
    • 软件版本过旧(低于 v3.98),已知的 LLM 断句 bug 未修复。

请检查上述可能性,并优先在日志文件中查找 recharge-llm 相关的请求和返回内容,以定位具体失败原因。

两条字幕内容是一样的,配音后两句话是一样的

两条字幕内容相同,配音自然产出相同的两段音频——这是 TTS 合成的基本规则,而非异常。如果您不希望听到相同的两句话被重复朗读,请检查字幕文件本身是否存在重复行。常见原因:LLM 重新断句时,将原长句拆成了语义完全相同的短句(例如同一句话被分割成了字面上一致的两行)。翻译渠道误将同一原文翻译成相同的两行(可能是翻译缓存或并发冲突)。ASR 识别时将同一段语音重复转录为两条相同字幕(概率较低)。诊断方法:打开输出目录下的 _video_out/ 文件夹,查看视频同名的 SRT 字幕文件,确认是否存在内容完全相同的两条相邻字幕行。如果确实内容相同,可采取以下方案:关闭 LLM 重新断句(使用默认断句),防止模型产生冗余分割。适当增大“最短语音持续毫秒”和“静音分割持续毫秒”以减少过细的切分。使用单视频交互模式,在字幕编辑窗口中手动删除重复行。如果同一句语义被分成两条相近但略有差异的字幕,可手动合并或调整其中一条的文本。若怀疑翻译渠道问题,可更换翻译渠道或关闭翻译缓存进行测试。

检查后发现是翻译成中文字幕的时候,生成了两条连续的相同字幕,什么原因

翻译后生成两条连续相同的中文字幕,常见原因如下:一是翻译缓存命中但原始字幕内容不同——当两条原始语言字幕在语言和词语上高度相似,但时间戳或标点不同时,翻译缓存可能将两者都识别为同一文本的变体,返回相同的中文翻译。二是AI翻译渠道在“发送完整字幕”模式下,对两行语义相近但略有差异的原文(如“How are you?”和“And how are you?”)给出了相同的口语化翻译(均输出“你好吗”),而提示词要求严格1:1映射块数,无法合并或去重。三是传统翻译渠道(如Google、微软)对短句或常用短语也可能产出相同结果。四是并发请求(trans_thread大于1)时,两行几乎同时发送到API,可能因服务端负载或缓存导致返回一致。解决步骤:打开输出目录下的 _video_out/ 文件夹,找到原视频对应的 SRT 文件(如 zh-cn.srt)。定位重复的两行,确认其原始语言字幕是否确实不同(时间轴或文本有差异)。如果原始语言已不同但翻译后相同:关闭“发送完整字幕”选项,改用按行翻译,避免AI受上下文干扰。如果问题仍存在,可尝试更换翻译渠道(如从AI翻译改为微软/Google翻译)。如果原始语言本身也高度相似(如只差一个标点),则翻译结果相同是合理的,可在单视频交互模式的手动校对窗口中删除其中一行,或关掉LLM重新断句以减少过度分割。若持续出现且非预期,可关闭翻译缓存测试。

为什么最终字幕会有些地方丢失,配音都有,但某条字幕就是缺失,并且后续的字幕时间也都一点错位了

根据您的描述,最终视频中缺失某条字幕且后续字幕时间轴发生错位,最常见的原因是 二次识别(Recogn2Pass)的遗漏字幕合并/过滤 导致。具体分析如下:

1. 二次识别导致缺失与错位(最常见)

当您勾选了“二次识别”时,软件会在配音完成后,对配音音频重新进行 ASR 转录,生成全新的字幕。如果配音中某一段音频(对应原字幕)被模型认为“没有有效语音”(例如语速过快、背景噪音、发音模糊或模型未检测到),那条字幕就不会出现在二次识别结果中。同时,因为字幕是按新识别的时间轴重新生成的,缺失一条后后续字幕的起始时间会前移(因为缺少了那条字幕的时长),导致整体错位。
确认方法:打开输出目录下的 _video_out/ 文件夹,查看最终用于合成的字幕文件(如 zh-cn.srt),检查是否比原字幕行数少,且时间轴不连续。

2. “合并过短字幕”或“最短语音持续毫秒”过滤

在“菜单 → 工具 → 高级选项 → 语音识别参数”中,如果开启了“合并过短字幕到邻近”,且某条字幕的时长小于设定的“最短语音持续毫秒”(如 1000ms),该条字幕会被合并到上一条或下一条中,导致丢失一条。同时合并后的时间轴会调整(下一条开始时间可能提前),产生错位感。

3. “移除字幕间静音”或“对齐字幕声音”干预

若未勾选“音频加速”和“视频慢速”,但勾选了“移除字幕间静音”或“对齐字幕声音”,软件在音画对齐阶段会重新分配字幕时间,可能会因为某条字幕时长异常(如为0)而删除该条,并调整后续时间轴。

4. LLM重新断句或翻译导致空行丢失

如果某条字幕翻译后内容为空(例如仅包含标点或特殊字符),或者 LLM 断句删除了该行,会导致字幕行数减少。但这通常不会影响后续时间轴(因为时间戳仍会保留),除非后续软件自动重新编号时出现错位。

排查步骤:

  1. 检查最终字幕文件:在 _video_out/视频名-mp4/ 下找到最终嵌入的字幕文件(如 zh-cn.srtmerged.srt),对比原字幕行数和时间轴是否连续。
  2. 关闭二次识别:在主界面取消勾选“二次识别”,重新处理一遍,看问题是否消失。如果消失,则确认是二次识别导致。
  3. 调整参数

    • 增大“最短语音持续毫秒”到更大值(如 2000ms),并关闭“合并过短字幕”。
    • 在高级选项中将“并发配音线程数”设为 1,减少 TTS 失败导致某条配音缺失。
  4. 使用单视频交互模式:选择只处理一个视频,在每一步暂停时检查字幕完整性(尤其是二次识别后的界面),可以直观看到是哪一步缺失和错位。

建议解决方案:

  • 如果不需要极精确的字幕时间轴与配音对齐,取消勾选“二次识别”,改用默认的基于原字幕的时间轴,并启用“音频加速”来同步。
  • 如果必须使用二次识别,请在“语音识别参数”中调低“最短语音持续毫秒”(如设为 500ms),并确保“合并过短字幕”不勾选,同时保证配音质量(避免含背景噪声)。
  • 更换 ASR 模型(如使用 faster-whisper large-v3字节语音大模型极速版)可提高二次识别的召回率。

若以上无法解决,请提供 logs/ 文件夹中最新的日志文件底部 30 行内容,以便进一步分析具体是哪条字幕被跳过。

00:19:34,661 --> 00:19:37,936
现在我们回去,抱歉,在回去之前。

341
00:19:37,936 --> 00:19:37,937
让我先处理一下UV。所以。

342
00:19:37,937 --> 00:19:38,961
确保你按了。

比如上边,中间那条字幕就是丢失的,但配音是正确的,最终结果就是配音在发声,字幕却没有,直到下一条字幕和配音出现,但明显感觉字幕和声音有一点点错位了

根据您提供的字幕时间轴示例,中间那条字幕(编号341)的时长仅为 1毫秒(19:37,936 → 19:37,937),这是导致该字幕最终丢失并造成后续错位的直接原因。

核心原因

  • 字幕时长过短(1ms):在最终合成阶段(无论是嵌入硬字幕、软字幕还是经过二次识别),绝大多数视频编码和字幕处理工具会忽略或过滤掉过短的字幕行(通常小于几百毫秒)。因为1毫秒的字幕在播放时无法被肉眼识别,软件内部逻辑会将其视为无效或冗余行,直接丢弃。
  • 后续时间轴错位:当这条字幕被丢弃后,下一条字幕(342)的正常开始时间原本应在上一条结束之后,但由于中间字幕缺失,软件可能错误地将上一条字幕(340)的结束时间与下一条字幕(341)的开始时间直接衔接,导致342的时间轴前移(少了中间字幕的1ms但实际还可能被调整),进而产生视觉上的错位。

解决方案

  1. 调整参数避免生成过短字幕

    • 菜单 → 工具 → 高级选项 → 语音识别参数 中,将 最短语音持续毫秒 设为一个合理的值(如 300~500ms)。该参数强制要求每条字幕的时长不低于该值,对于低于此值的字幕会尝试合并到相邻字幕。
    • 同时开启 合并过短字幕到邻近,这样类似1ms的字幕会被自动合并到前一条或后一条字幕中,而不是单独丢弃。
  2. 如使用二次识别

    • 二次识别会重新根据配音音频生成字幕,过短的字幕很容易被新模型过滤。您可以在二次识别阶段,调低 最短语音持续毫秒 参数(例如设为 200ms),或直接关闭二次识别(不使用二次识别,而依赖原始字幕的时间轴),并启用音频加速来同步。
  3. 手动修复(单视频交互模式)

    • 如果只处理一个视频,在语音识别或翻译后的编辑窗口中,手动将第341条字幕的时长拉长(例如改为 00:19:37,936 → 00:19:38,200),确保其时长在合理范围内(≥500ms)。这样可以避免被跳过。
  4. 检查其他参数

    • 确认未勾选 移除字幕间静音(该功能可能会合并消除短字幕间隙,导致字幕丢失)。
    • 确认 对齐字幕声音 已开启(以便自动调整时间轴,但不会丢弃字幕)。

总结

您丢失的字幕是因为时长只有1ms,被软件或编码器视为无效行而跳过。请将 最短语音持续毫秒 调高至 300-500ms,并开启合并过短字幕功能,即可避免此类问题。如果还需进一步排查,请提供日志文件中关于该字幕的处理记录。

移除字幕间静音 选项没找到

该选项位于 主界面 → 设置更多参数 弹窗中。点击主界面右下角的“设置更多参数...”按钮,在弹出的窗口中即可找到 移除字幕间静音 复选框。如果仍然找不到,也可以在 菜单 → 工具 → 高级选项 → 字幕声音画面对齐 区域中找到它(位于“音频加速最大倍数”下方附近)。请注意,只有当主界面未勾选“音频加速”和“视频慢速”时,该选项才会显示为可操作状态。如果已经勾选了加速或慢速,该选项会被隐藏或禁用。

之前也明明启用了 合并过短字幕到邻近,为什么还是会出现1毫秒的字幕?

之前也明明启用了 合并过短字幕到邻近,为什么还是会出现1毫秒的字幕?

Post Your Reply
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: ko-fi.com/jianchang512

Related resource