MKV Unprocessed Task fügt Audioverzögerung hinzu – stört Wiedergabe in VLC, Apple TV und Plex

MCEBuddy 2.6.7
Windows 11 x64 24H2

Hallo zusammen,
ich bin auf ein durchgehendes Problem mit MCEBuddy 2.6.7 gestoßen, wenn ich den Task „MKV Unprocessed“ nutze. Nach der Verarbeitung weisen meine MKV-Dateien eine negative Audio-Verzögerung von etwa -1,997 s auf (laut MediaInfo). Das führt dazu, dass:
• VLC die Audiospur sofort startet, während das Video ~2 Sekunden lang mit schwarzem Bild hinterherhängt.
• Apple TV (über Infuse oder Plex) die Wiedergabe komplett verweigert, es sei denn, die Datei wird mit MKVToolNix neu gemuxt.
• Plex mit Direct Play und/oder Direct Stream Probleme hat – ein Freund mit Apple TV bestätigt, dass diese Dateien erst nach einem Remux sauber laufen.

Diese Verzögerung tritt NICHT auf bei:
• der originalen MKV-Datei
• der Datei nach HandBrake (NVENC x265)
Nur die MCEBuddy-Ausgabe führt zur Verzögerung.

:white_check_mark: Schritte zur Reproduktion

  1. Saubere MKV-Datei als Ausgangspunkt
    → läuft in VLC, Apple TV und Plex einwandfrei.
  2. Über HandBrake (NVENC x265) laufen lassen
    → weiterhin ohne Verzögerung.
  3. Mit MCEBuddy 2.6.7 und „MKV Unprocessed“ verarbeiten
    → Metadaten-Download und Umbenennung aktiv (Standardsowie mit Cut Start xx).
    – Skip Copying und Skip remux sind NICHT aktiviert.
  4. Finales MKV in MediaInfo öffnen
    Delay relative to video: -1 s 997 ms bei der Audiospur.
  5. In VLC abspielen
    → Audio sofort, Video hängt mit schwarzem Bild nach.
  6. Apple TV oder Plex testen
    → Wiedergabe bricht ab oder puffert endlos, außer nach Remux mit MKVToolNix.

:test_tube: Zusätzliche Hinweise
• Der Austausch von mkvmerge.exe im MCEBuddy-Ordner gegen die aktuelle Version behebt das Problem nicht.
• Möglicherweise ruft MCEBuddy ffmpeg mit veralteten Flags auf, die die Stream-Timing verändern?
• Ein Remux des fertigen MKV mit MKVToolNix (ohne Audio-Delay-Korrektur) behebt das Problem auf allen Plattformen.

Ich stelle gern MediaInfo-Logs oder Beispieldateien zur Verfügung. Würde gern wissen, ob andere das auch beobachtet haben und ob es eine Möglichkeit gibt, MCEBuddy daran zu hindern, die Verzögerung einzufügen.
Danke!
—John

Sorry, ich habe vergessen den Anhang mitzuschicken
Audio Delay and Black Screen in VLC.7z (121,8 KB)

Ich habe ein ähnliches Problem mit 2.6.7 und 2.6.6, aber bei Verwendung von MP4 Hohe Qualität. Etwa in der Mitte des Films gerät der Ton außer Synchronisation mit dem Video. In früheren Versionen ist dies nicht passiert.

Ich sehe dieses Problem bei unseren Beispieltestvideos nicht. Könnt ihr beide eure Originalvideos zusammen mit den Konvertierungsprotokollen auf den Server hochladen (damit wir jede einzelne Einstellung replizieren können), damit wir analysieren können, was vor sich geht.

Dateien und neue Logs befinden sich nun in ‘\\upload.mcebuddy2x.com\JohnFreiman\’
Dies passiert bei 99 oder 100 % der Dateien.

Chopped S63E09.mkv  --  Original
Chopped - s63e09 - In Cod We Trust.mkv  --  MCEBuddy-Ausgabe
srt subs.7z   --  externe Untertitel

Externe SRT-Untertitel sind erforderlich, damit Plex sowohl Forced- als auch Non-SDH- und SDH-Untertitel erkennt.

Ich bin mir nicht sicher, ob es zusammenhängt, aber ich habe externe Untertitel (bei jedem Video), die der Ausgabe hinzugefügt werden.

logs.7z  --  „mcebuddy.log“ & „Chopped S63E09.mkv-TV to Television-2025-08-21T00-55-38.log“

Update
Ich habe gerade eine ZIP mit den .conf-Dateien hinzugefügt, falls ich über die Jahre etwas verpfuscht habe…

„conf files.7z“

Update 2
Obwohl die hochgeladene Chopped-Folge eine Audioverzögerung aufweist, ist sie nicht so stark wie die Countdown-Logs, die ich heute früher in meinem OP hochgeladen habe – es ist einfach die neueste transkodierte Datei, bei der ich noch das Original habe, sie zeigt jedoch den Beginn der Audioverzögerung.

Es ist tatsächlich nicht ungewöhnlich, Audioverzögerungen beim Konvertieren von Dateien zu sehen. Sie können aus verschiedenen Gründen auftreten.

MCEBuddy kann diese Audioverzögerungen erkennen und sie bei Bedarf kompensieren (standardmäßig tut es dies nicht). Meistens sind die Verzögerungsinformationen in der konvertierten Video-Datei gespeichert, sodass die Wiedergabesoftware die Verzögerungen zur Laufzeit korrigieren können sollte. Wenn dies bei Ihrem Player nicht geschieht, können Sie MCEBuddy bitten, diese Verzögerungen automatisch zu korrigieren, indem Sie Ihr Profil bearbeiten.

Siehe dies: https://discussion.mcebuddy2x.com/t/mcebuddy-advanced-settings-commands-and-tweaking/30#audiodelay

John, aus Ihren Protokollen sehe ich in Ihrem Profil:

ffmpeg-audiodelay=skip

ändern Sie dies zu

ffmpeg-audiodelay=auto

und es sollte die Audioverzögerungen während der Konvertierung automatisch korrigieren. Beachten Sie, dass dies nur für Profile funktioniert, die auf den Encodern ffmpeg, Handbrake und MEncoder basieren. Es funktioniert nicht bei Profilen, die den Copy-Encoder verwenden.

Alternativ, wenn Sie bei allen Videos eine feste Abweichung feststellen, können Sie diese auch über die Konvertierungsaufgabe → Experten-Einstellungen → Audioverzögerung korrigieren.

image

Vielen Dank für die Prüfung dieser Angelegenheit.

Nun, ich habe die Eingabedatei sowie die von MCEBuddy erstellte Datei in meinen Upload aufgenommen. Das Eingangs-/Originalvideo hat keine Verzögerung und wird auf jedem Gerät und in jeder App, die ich ausprobiert habe, ohne Audioprobleme wiedergegeben.

  • MediaInfo zeigt keine Audioverzögerung in der Originaldatei an.
  • Die Ausgabedatei von MCEBuddy meldet eine Verzögerung und führt dazu, dass das Video entweder nicht abspielbar ist (Apple TV) oder die Videowiedergabe auf Mediaplayern wie VLC verzögert beginnt.
  • Wenn ich das MCEBuddy-Video nehme und es mit mkvtoolnix neu muxe, zeigt das Video keine Audioverzögerung und spielt perfekt ab – keine Verzögerungen, Fehler usw.

Es gibt keine konsistente Audioverzögerung bei der Ausgabevideodatei. Sie sind jedes Mal anders.

Das Profil MKV Unprocessed sollte Handbrake nicht verwenden. Dieses Profil sollte nichts anderes tun, als möglicherweise das Video zuzuschneiden, ohne das Video oder den Ton zu konvertieren.

Ich verwende lediglich Profile, um meine vorhandenen Serienepisoden zu nehmen, die Untertitel zu integrieren, bei Bedarf am Anfang zuzuschneiden, sie umzubenennen und zu verschieben.

Ich glaube also, dass nur ffmpeg und wahrscheinlich mkvmerge verwendet werden. – Wenn ich falsch liege und mkvmerge nicht verwendet wird, kann ich MCEBuddy anweisen, mkvmerge zu verwenden, um die Dateien mit Untertiteln zu schreiben, bevor sie verschoben werden?

Nein, ich habe Abweichungen von nur einem Bruchteil einer Sekunde bis zu fast 2 Sekunden festgestellt – das sind definitiv Videos, die von Apple TV nicht abgespielt werden können.

Jedes Video, das ich mit MCEBuddy verarbeite, beginnt ohne gemeldete Audioverzögerung. Jedes Video, das von MCEBuddy ausgegeben wird, hat eine Verzögerung, die eingeführt/gefunden wurde – die vorher anscheinend nicht vorhanden war.

Ich halte es für sehr unwahrscheinlich, dass jedes Video, das ich habe, irgendein unentdecktes/unentdeckbares Audioverzögerungsproblem hatte. Ich spreche von Zehntausenden von Videos in den letzten 5 Monaten. (Ich rasiere derzeit meine gesamte TV-Bibliothek von den Quelldateien neu.)

Alle Videos, die von MCEBuddy zusammengeführt werden, benötigen ein oder zwei Sekunden, bevor das Video in VLC Media Player unter Windows erscheint – unabhängig davon, wie gering oder groß die Audioabweichung ist.

Korrektur, ich wollte nur eine aktuelle Stichprobe der Videos erhalten, die ich in den letzten 24 Stunden durch MCEBuddy laufen ließ, und das erste, das ich überprüft habe, ist weit über 2 Sekunden hinaus

Verzögerung relativ zum Video: -7 s 600 ms

:cry:

Ich habe gerade den Ordner mit einer Staffel genommen, die ich gestern mit MCEBuddy mit Untertiteln versehen und organisiert habe – die Serie mit der -7 s 600 ms Verzögerung, und ich habe die Dateien aus meinem Plex TV-Ordner verschoben und sie wieder in MCEBuddy in die Warteschlange gestellt, mit audiedelay=auto, und jetzt sind die von MCEBuddy ausgegebenen Videos komplett unsynchronisiert.

Sogar die oben genannte Episode mit den -7,6 ms hat jetzt -10,88 ms – es hat also nicht einmal die 7,6-Zahl verwendet und den Ton um weitere ca. 3 Sekunden verschoben.

Zum Glück habe ich ein Backup erstellt, anstatt zu ersetzen. :slight_smile:

Ich habe gerade einige neue Episoden, die direkt von Blu-ray stammten, durch MCEBuddy mit der Änderung ffmpeg-audiodelay=auto laufen lassen, und dieses Video (sowie ein paar andere, bei denen keine Audioverzögerung angezeigt wurde) durch MCEBuddy laufen lassen, und alle kamen mit „eingeführten“ Verzögerungen heraus.

Ich vermute, dass die Verzögerungen durch ffmpeg während des Zwischenschritts des Remuxing verursacht werden, der hauptsächlich erforderlich ist, um die Kompatibilität mit anderen Programmen zu verbessern. Angesichts Ihres Setups benötigen Sie diesen Zwischenschritt möglicherweise nicht.

Versuchen Sie, die Option „Remuxing überspringen“ auf der Seite „Experteneinstellungen“ der Konvertierungsaufgabe zu aktivieren und zu prüfen, ob dies Ihr Problem löst.

Ich habe mir gestern Abend genau diese Einstellung angesehen, aber ich habe auf eine Rückmeldung gewartet.

Danke, ich werde es versuchen.

Halleluja! Das war es! Vielen Dank!!

Ich habe nur noch eine Nachfrage…

Ich habe buchstäblich über 124.000 Episoden, wobei die Mehrheit dieser Episoden/Videos diese (sind sie künstlich?) Audioverzögerungen aufweist – einige davon machen sie auf Apple TV-Geräten unspielbar, und der Rest hat Verzögerungen bei der Wiedergabe des Videos auf Playern wie VLC auf anderen Geräten.

Derzeit verwende ich MKV Unprocessed mit der Metadaten-Suche auf Priorisierung von Staffel-/Episodentitel und dem Überschreiben des Metadaten-Dateinamens unter Verwendung von TVDB zur Konsistenz und auch um zu verhindern, dass Shows, die Episodentitel wiederverwenden, falsch der falschen Staffel zugeordnet werden (ich denke, MCEBuddy verwendet immer die frühesten Episoden S/E der Serie…).

Was würden Sie also als die beste/einfachste Methode vorschlagen, um diese Episoden neu zu muxen, ohne möglicherweise die Reihenfolge der Episoden durcheinander zu bringen?

Außerdem habe ich in letzter Zeit nicht genau darauf geachtet, aber ich glaube, dass das Standard-Unprocessed ein wenig vom Anfang jedes Videos abschneidet, um sicherzustellen, dass am Anfang des Videos keine Fehler oder verworfenen Bilder vorhanden sind.

Wenn ich MKV Unprocessed erneut auf diese Dateien anwende, schneidet es von jedem Video ein „bisschen mehr“ vom Anfang ab, und das könnte potenziell wichtige Informationen aus jedem Video „löschen“.

Da alle Dateien bereits benannt sind und die entsprechenden Metadaten an jede Datei angehängt sind, gibt es eine bessere Möglichkeit, all diese Videos zu korrigieren/reparieren – anstatt das Profil MKV Unprocessed zu verwenden?

Wenn kein Zuschnitt am Anfang der Videos vorgenommen wird, könnten meine externen Untertitel (mit .forced .sdh usw.) unverändert bleiben und nur die mkv-Datei(en) müssten neu gemuxt werden.

Das sollte nicht passieren, dieses Problem wurde vor Jahren behoben. Es sollte KEIN Zuschneiden mit der Standardeinstellung profiles.conf und der Standardeinstellung mcebuddy.conf stattfinden, es sei denn, Sie haben die Konvertierungsaufgabe in den Experteneinstellungen speziell so konfiguriert, dass sie zuschneidet, oder Sie verwenden ein altes oder benutzerdefiniertes Profil.

Ich würde empfehlen, ein neues Thema bezüglich der Metadaten zu eröffnen, ich bin mir nicht klar darüber, was Sie versuchen zu tun.

Wir haben das Problem gefunden, und es scheint sich um einen Fehler in ffmpeg zu handeln. Selbst wenn wir ffmpeg anweisen, nichts zu schneiden/überspringen (-ss 0), versucht es, die Spuren zu synchronisieren, wenn es auf ein Problem stößt, und verliert dabei die Synchronisation.

Wenn also irgendwo im Konvertierungsprozess (Remuxing, Profile usw.) ein -ss 0 enthalten ist, führt dies zu diesem Synchronisationsproblem.

Wir werden es beheben (im Moment enthalten die meisten unserer Profile auch -ss 0, sodass das Problem auch dann auftritt, wenn Sie das Remuxing überspringen, aber ein Standardprofil verwenden).

Vielen Dank für die Meldung.

Versuchen Sie den heutigen 2.6.7 BETA Build (behalten Sie das Remuxen aktiviert, um es zu testen), und dies sollte die Probleme mit der Audiosynchronisation beheben. Es sollten keine Änderungen an Ihren bestehenden Profilen oder Einstellungen von Ihrer Seite erforderlich sein.

Oh, Gott sei Dank! Ich wollte mich gerade anmelden, um Ihnen mitzuteilen, dass ich das Problem wieder sehe – die anderen beiden Dateien, die ich getestet habe, waren wohl nicht repräsentativ für das Problem.

Ich bin mir nicht sicher, ob dies ein Problem mit der Beta-Version ist oder ob ich beim Suchen/Ersetzen der Remux-Einstellungen etwas vermasselt habe, aber die SRT-Untertitel werden nicht mehr in die MKV integriert – die externen werden jedoch in den Zielordner kopiert.

Ich habe gerade eine neue ZIP-Datei in den Upload-Ordner fallen lassen, damit Sie einen Blick darauf werfen können.
Enthält: Protokolle und Konfigurationsdateien.
Die Longmire-Episoden habe ich bereits im Oktober 2022 erstellt, die dieses Problem ebenfalls haben.
Die Forgive Me-Episoden habe ich gerade in Handbrake transkodiert – verifiziert, keine Audioverzögerung.

Sie haben eine beschädigte Datei oder eine beschädigte Installation

FEHLER> 2025-08-27T06:05:47 MCEBuddy.AppWrapper.MKVMerge → Anwendungsdatei nicht gefunden oder nicht zugreifbar: C:\Program Files\MCEBuddy2x\MKVMerge\MKVMerge.exe

Vielleicht MCEBuddy neu installieren

Danke.
Ich habe neu installiert und der Ordner sowie die EXE-Datei sind vorhanden.

Ok, ich habe die Episoden von gestern (~60) erneut gesendet und diese Dateien scheinen in Ordnung zu sein.

Wenn ich einige Episoden (Longmire), die 2022 durch MCEBuddy verarbeitet wurden, mit dem neuen Build erneut durch MCEBuddy laufen lasse, wobei Remux standardmäßig auf „Überspringen“ eingestellt ist, behalten sie immer noch die vorherige Datei „Verzögerung relativ zum Video“.

Wenn ich dieselbe Datei von 2022 nehme und sie ohne Verzögerung für die Audiospur durch MKVToolNix laufen lasse, zeigt die Ausgabedatei in MediaInfo keine Verzögerung an und spielt sofort in VLC ohne Verzögerung beim Videostart ab.

image

Glauben Sie, dass es eine Möglichkeit gibt, die Verzögerung mit MCEBuddy zu „korrigieren“ und/oder zu entfernen?

Ich habe gerade nachgesehen und, ehrlich gesagt, wenn ich eine zufällige Auswahl aller meiner Serienepisoden zurück bis mindestens 2022 betrachte, weisen diese Verzögerungen auf – glücklicherweise scheinen die Episoden, die ich von 2014 und 2015 überprüft habe, keine Verzögerungen zu haben (aber diese a) haben keine externen Untertitel und b) wurden über MCEBuddy mit Handbrake konvertiert).

Eines von beiden

image

Meine Sorge und Befürchtung ist, dass ich letzten Herbst damit begonnen habe, unzählige Serien (30.000, 60.000? Episoden) durch neue digitale Master zu ersetzen, um meine WMC-Aufnahmen und andere zu ersetzen.

Lassen Sie mich wissen, welche Optionen ich habe… Wenn das in Ihrem Ermessen liegt.

Hmm, ich sehe nach der Konvertierung mit den Dateien, die Sie früher hochgeladen haben, keine Verzögerung mehr.
Können Sie das Konvertierungsprotokoll und die Originaldatei hochladen, die Verzögerungen anzeigt?