MCEBuddy 2.6.7
Windows 11 x64 24H2
大家好,
我在使用 MCEBuddy 2.6.7 的“MKV 未处理”任务时遇到了一个持续问题。处理完成后,我的 MKV 文件音频延迟显示为约 -1.997 秒(通过 MediaInfo 确认)。这会导致:
• VLC 会立即播放音频,而视频滞后约 2 秒,屏幕为黑屏。
• Apple TV(通过 Infuse 或 Plex)无法播放,除非通过 MKVToolNix 重新封装。
• Plex 在直接播放和/或直接串流时出现问题——朋友用 Apple TV 确认,这些文件在重新封装前无法流畅播放。
以下情况不会出现此延迟:
• 原始 MKV 文件
• 经过 HandBrake(NVENC x265)处理后的文件
只有 MCEBuddy 输出会引入延迟。
复现步骤
- 从一个干净的 MKV 文件开始
→ 在 VLC、Apple TV 和 Plex 中播放正常。
- 通过 HandBrake(NVENC x265)处理
→ 仍然正常,无延迟。
- 使用 MCEBuddy 2.6.7 的“MKV 未处理”任务处理
→ 启用元数据下载和文件重命名(默认设置,以及使用 Cut Start xx)。
- 在 MediaInfo 中打开最终 MKV
→ 观察到音频流显示 相对于视频的延迟:-1 秒 997 毫秒。
- 在 VLC 中播放
→ 音频立即开始,视频滞后并黑屏。
- 尝试 Apple TV 或 Plex
→ 播放失败或无限缓冲,除非用 MKVToolNix 重新封装。
额外说明
• 将 MCEBuddy 文件夹中的 mkvmerge.exe 替换为最新版本无法解决问题。
• 可能是 MCEBuddy 调用了 ffmpeg 或使用了旧参数,导致流时间变化?
• 用 MKVToolNix 对最终 MKV 重新封装(不调整音频延迟)可在所有平台正常播放。
如有需要,我很乐意分享 MediaInfo 日志或示例文件。想知道是否有人遇到同样问题,以及是否有办法阻止 MCEBuddy 引入延迟。
谢谢!
——John
抱歉,我忘了附上
Audio Delay and Black Screen in VLC.7z (121.8 KB)
Damcis
(Daniel Mullings)
2
我在 2.6.7 和 2.6.6 也遇到類似問題,但使用的是 MP4 高畫質。影片播到一半時,音訊會與影片不同步。之前的版本並沒有發生這種情況。
Goose
(Goose)
3
我在我们的示例测试视频中并未看到该问题。请两位都将原始视频连同转换日志一起上传到服务器(以便我们复现每一个设置),供我们分析并查明原因。
檔案與新日誌現在都放在 '\upload.mcebuddy2x.com\JohnFreiman'
這種情況發生在 99% 或 100% 的檔案上。
Chopped S63E09.mkv -- 原始檔
Chopped - s63e09 - In Cod We Trust.mkv -- MCEBuddy 輸出
srt subs.7z -- 外部字幕
Plex 要能辨識強制字幕以及非 SDH 與 SDH 字幕,就必須有外部 srt 字幕。
我不確定是否相關,但我有外部字幕(每部影片都有),它們會被加入輸出檔。
logs.7z -- "mcebuddy.log" 與 "Chopped S63E09.mkv-TV to Television-2025-08-21T00-55-38.log"
更新
我剛剛又加了一個 zip,裡面是 .conf 檔案,以防我這幾年搞壞了什麼設定……
"conf files.7z"
更新 2
我上傳的這集 Chopped 雖然有音訊延遲,但沒有我今天稍早上傳到原帖的 Countdown 日誌那麼嚴重——這只是我能保留原始檔的最新轉碼檔案,不過的確能看出音訊延遲的開始。
Goose
(Goose)
5
在转换文件时遇到音频延迟实际上并不少见。它们可能由各种原因引起。
MCEBuddy 可以检测到这些音频延迟并在需要时进行补偿(默认情况下它不会)。大多数情况下,延迟信息存储在转换后的视频中,因此播放软件应该能够在运行时纠正延迟。如果您的播放器没有这样做,您可以要求 MCEBuddy 通过编辑您的配置文件来自动纠正这些延迟。
请参阅此链接:MCEBuddy - Advanced Settings, Commands and Tweaking
John,从您的日志中我看到您的配置文件中是:
ffmpeg-audiodelay=skip
请将其更改为:
ffmpeg-audiodelay=auto
这样它应该会在转换时自动纠正音频延迟。请注意,这仅适用于基于 ffmpeg、handbrake 和 mencoder 编码器的配置文件,不适用于使用 copy 编码器的配置文件。
或者,如果您在所有视频中都看到固定数量的偏差,您也可以从“转换任务 - > 专家设置 → 音频延迟”中进行纠正。
感谢您的跟进。
我已在上传中包含了输入文件以及 MCEBuddy 创建的文件。输入/原始视频没有延迟,并且在我尝试过的所有设备和应用程序上都能正常播放,没有任何音频问题。
- MediaInfo 显示原始文件中没有音频延迟。
- MCEBuddy 的输出文件报告存在延迟,导致视频在 Apple TV 上无法播放,或在 VLC 等视频播放器上视频开始时延迟。
- 如果我使用 mkvtoolnix 对 MCEBuddy 的视频进行重新封装,视频则没有音频延迟,并且可以完美播放——没有延迟、故障等。
输出视频中没有一致的音频延迟。每次都不一样。
MKV Unprocessed 配置文件不应该使用 Handbrake。此配置文件除了可能修剪视频外,不应进行任何视频或音频转换。
我只是使用配置文件来获取我现有的系列剧集,集成字幕,如有必要,进行修剪,然后重命名和移动它们。
所以,我认为只使用了 ffmpeg,很可能还有 mkvmerge。- 如果我错了,并且没有使用 mkvmerge,我能否让 MCEBuddy 在移动文件之前使用 mkvmerge 写入带有字幕的文件?
不,我看到的偏差小到零点几秒,大到将近 2 秒——那些绝对是 Apple TV 无法播放的视频。
我使用 MCEBuddy 处理的每个视频在输入时都没有报告的音频延迟。MCEBuddy 输出的每个视频都引入/发现了延迟——而这在之前似乎并不存在。
我很难相信我拥有的每个视频都存在某种未被发现/无法检测的音频延迟问题。我指的是过去 5 个月内的数万个视频。(我正在从源媒体重新翻录我的电视库中的所有内容)
MCEBuddy 合并的所有视频在 VLC Media Player 在 Windows 上出现视频之前都会延迟一两秒——无论音频偏差有多小或多大。
更正一下,我只是想获取我在过去 24 小时内通过 MCEBuddy 处理的视频的当前样本,而我检查的第一个视频的延迟远远超过 2 秒
相對於影片的延遲 : -7 秒 600 毫秒

我刚拿了昨天我用 MCEBuddy 添加字幕和整理的一个季度的文件夹——那个延迟为 -7 秒 600 毫秒的剧集,我把文件从我的 Plex TV 文件夹中移出,然后重新放回 MCEBuddy 的队列中,设置 audiedelay=auto,现在 MCEBuddy 输出的视频完全不同步了。
即使是上面那个 -7.6 毫秒延迟的剧集,现在也变成了 -10.88 毫秒——所以它甚至没有使用 7.6 这个数字,而是把音频又推迟了大约 3 秒。
谢天谢地,我备份了而不是替换。
我剛用 MCEBuddy 處理了一些直接來自藍光的新劇集,並在其中加入了 ffmpeg-audiodelay=auto 的更改,然後處理了該影片(以及其他幾部沒有音訊延遲的影片),結果它們都出現了「引入」的延遲。
Goose
(Goose)
10
我懷疑延遲是由於 ffmpeg 在主要為提高與其他程式的相容性而進行的重新封裝中間步驟中引入的。鑑於您的設定,您可能不需要該中間步驟。
請嘗試在轉換任務中勾選「跳過重新封裝」(Skip remuxing) 選項 → 專家設定頁面,看看這是否能解決您的問題。
哈利路亞!就是這個問題!謝謝您!!
我還有一個後續問題……
我實際上有一萬兩千四百多集,其中大部分集數/影片都有這些(是人為的嗎?)音訊延遲——有些延遲導致它們無法在 Apple TV 設備上播放,而其餘的則在 VLC 等播放器上播放影片時出現延遲。
目前,我正在使用「MKV 未處理 (MKV Unprocessed)」,並將中繼資料查找設定為優先考慮季/集標題,並使用 TVDB 覆寫中繼資料檔名以保持一致性,同時防止重複使用劇集標題的節目被錯誤地匹配到錯誤的季度(我認為 MCEBuddy 總是使用該系列中最早的集數 S/E……)。
那麼,您建議使用哪種最佳/最簡單的方法來重新封裝這些劇集,同時又不會破壞劇集順序?
另外,我最近沒有太注意,但我認為預設的「未處理 (Unprocessed)」會從每個影片的開頭修剪掉一點點,以確保影片開頭沒有錯誤或丟失的影格。
如果我再次對這些檔案重新執行「MKV 未處理 (MKV Unprocessed)」,它會從開頭再修剪「一點點」,這可能會「抹去」每個影片中可能重要的資訊。
由於所有檔案都已命名並附有適當的中繼資料,是否有更好的方法來修復/修復所有這些影片——而不是使用「MKV 未處理 (MKV Unprocessed)」設定檔?
如果沒有從影片開頭進行修剪,我的外部字幕(帶有 .forced .sdh 等)就可以保持不變,只需要重新封裝 mkv 檔案即可。
Goose
(Goose)
13
这不应该发生,那个问题多年前就解决了。除非您在专家设置中专门配置了转换任务以进行修剪,或者您正在使用旧的或自定义的配置文件,否则使用默认的 profiles.conf 和默认的 mcebuddy.conf 不应进行任何修剪。
我建议就元数据(metadata)开启一个新主题,我不清楚您想做什么。
Goose
(Goose)
14
我们找到了问题所在,问题似乎是 ffmpeg 的一个错误,即使我们告诉 ffmpeg 不要剪切/跳过任何内容(-ss 0),如果它遇到一个,它也会尝试同步音轨,在这个过程中会丢失同步。
因此,如果在转换过程中的任何地方(重新封装、配置文件等)存在 -ss 0,它都会产生这种同步问题。
我们将进行修补(目前我们的大多数配置文件也包含 -ss 0,所以即使您跳过重新封装但使用了默认配置文件,仍然会产生问题)。
感谢您的报告。
Goose
(Goose)
15
請嘗試今天的 2.6.7 BETA 版本(保持開啟 remuxing 以進行測試),這應該可以解決音訊同步問題。您現有的設定檔或設定不需要進行任何更改。
谢天谢地!我正要登录告诉你我再次遇到了这个问题——我测试的另外两个文件可能没有代表这个问题。
我不確定這是 Beta 版的問題,還是我在搜尋/取代重新封裝設定時弄錯了什麼,但 srt 字幕不再合併到 mkv 中——然而,外部字幕正在被複製到目標資料夾。
我剛把一個新的 zip 檔案丟到上傳資料夾中,供您查看。
包含:日誌和設定檔
《Longmire》 的劇集是我在 2022 年 10 月建立的,它們也有這個問題。
《Forgive Me》 的劇集是我剛才用 Handbrake 轉碼的——已驗證,沒有音訊延遲。
谢谢。
我重新安装了,文件夹和可执行文件都在。
好的,我已经重新发送了昨天的剧集(约 60 个),这些文件看起来没问题。
以 MCEBuddy 在 2022 年处理过的一些剧集(《Longmire》)为例,使用新的构建并默认设置“Remux”和“Skip”再次通过 MCEBuddy 处理,仍然保留了先前文件的“相对于视频的延迟”。
如果我将 2022 年的同一个文件放入 MKVToolNix 中,不对音频轨道设置任何延迟,输出文件在 MediaInfo 中显示没有延迟,并且在 VLC 中播放时视频立即开始,没有延迟。
您认为有没有办法使用 MCEBuddy 来“修正”和/或消除延迟?
我刚刚检查了一下,说实话,查看我从至少 2022 年开始的所有系列剧集的随机样本,它们都有延迟——值得庆幸的是,我检查过的 2014 年和 2015 年的剧集似乎没有延迟(但那些 a) 没有外部字幕,b) 它们是通过 MCEBuddy 使用 Handbrake 转换的)。
其中任何一个
我的担忧和恐惧是,我从去年秋天开始替换了无数系列的剧集(30,000、60,000?集),用新的数字母版替换我的 WMC 录制和其他内容。
请告诉我您面前有哪些选择……如果这在您的考虑范围之内的话。
Goose
(Goose)
20
嗯,我現在看不到您之前上傳的檔案在轉換後有任何延遲了。
您可以上傳顯示延遲的轉換日誌和原始檔案嗎?