Hallo allemaal,
Ik ben een consistent probleem tegengekomen met MCEBuddy 2.6.7 bij gebruik van de taak “MKV Unprocessed”. Na verwerking vertonen mijn MKV-bestanden een negatieve audiovertraging van ongeveer -1,997 s (bevestigd via MediaInfo). Dit veroorzaakt:
• VLC speelt direct audio af terwijl de video ongeveer 2 seconden achterloopt met een zwart scherm.
• Apple TV (via Infuse of Plex) kan het bestand helemaal niet afspelen, tenzij het opnieuw wordt gemuxed met MKVToolNix.
• Plex heeft moeite met Direct Play en/of Direct Stream – een vriend met Apple TV bevestigde dat deze bestanden pas schoon afspelen na een remux.
Deze vertraging komt niet voor in:
• Het originele MKV-bestand
• Het bestand na HandBrake (NVENC x265) Alleen de MCEBuddy-uitvoer introduceert de vertraging.
Stappen om te reproduceren
Begin met een schoon MKV-bestand
→ Speelt probleemloos af in VLC, Apple TV en Plex.
Verwerk met HandBrake (NVENC x265)
→ Speelt nog steeds goed, geen vertraging.
Verwerk met MCEBuddy 2.6.7 via “MKV Unprocessed”
→ Schakel metadata-download en bestandshernoeming in (standaardinstellingen én met Cut Start xx gebruikt).
Skip Copying en Skip remux zijn niet aangevinkt/ingeschakeld
Open het uiteindelijke MKV in MediaInfo
→ Observeer Delay relative to video: -1 s 997 ms op de audiostroom.
Speel af in VLC
→ Audio start direct, video loopt achter met zwart scherm.
Probeer Apple TV of Plex
→ Afspelen mislukt of blijft oneindig bufferen, tenzij opnieuw gemuxed met MKVToolNix.
Aanvullende opmerkingen
• Het vervangen van mkvmerge.exe in de MCEBuddy-map door de nieuwste versie lost het probleem niet op.
• Mogelijk roept MCEBuddy ffmpeg aan of gebruikt het verouderde flags die de stream-timing wijzigen?
• Remuxen van het uiteindelijke MKV met MKVToolNix (zonder audio-delay-correctie) lost het probleem op alle platforms op.
Ik deel graag MediaInfo-logs of voorbeeldbestanden als dat helpt. Ik hoor graag of anderen dit ook hebben gezien en of er een manier is om te voorkomen dat MCEBuddy de vertraging introduceert.
Bedankt!
—John
Sorry, ik vergat bij te voegen Audio Delay and Black Screen in VLC.7z (121,8 KB)
Ik ondervind een vergelijkbaar probleem met 2.6.7 en 2.6.6, maar met MP4 Hoge Kwaliteit. Halverwege de film raakt de audio uit sync met de video. Dit gebeurde niet in eerdere versies.
Ik zie dat probleem niet met onze voorbeeldtestvideo’s. Kunnen jullie beiden jullie originele video’s uploaden naar de server samen met de conversielogs (zodat we elke instelling kunnen repliceren) zodat we kunnen analyseren wat er aan de hand is.
Bestanden en nieuwe logboeken bevinden zich nu in ‘\\upload.mcebuddy2x.com\JohnFreiman\’
Dit gebeurt bij 99 of 100% van de bestanden.
Chopped S63E09.mkv -- Origineel
Chopped - s63e09 - In Cod We Trust.mkv -- MCEBuddy-uitvoer
srt subs.7z -- externe ondertitels
Externe srt-ondertitels zijn vereist zodat Plex forced, non-sdh én sdh-ondertitels herkent.
Ik weet niet zeker of het ermee te maken heeft, maar ik heb externe ondertitels (bij elke video) die aan de uitvoer worden toegevoegd.
logs.7z -- "mcebuddy.log" & "Chopped S63E09.mkv-TV to Television-2025-08-21T00-55-38.log"
update
Ik heb zojuist een zip met de .conf-bestanden toegevoegd, voor het geval ik door de jaren heen iets heb verknoeid…
"conf files.7z"
update 2
Hoewel de geüploade aflevering van Chopped de audiovertraging heeft, is deze niet zo erg als bij de Countdown-logs die ik eerder vandaag in mijn OP heb geüpload — het is simpelweg het laatst getranscodeerde bestand waarvoor ik het origineel nog heb, maar het laat wel het ontstaan van de audiovertraging zien.
Het is eigenlijk niet ongebruikelijk om audiovertragingen te zien bij het converteren van bestanden. Ze kunnen om verschillende redenen optreden.
MCEBuddy kan deze audiovertragingen detecteren en deze indien nodig compenseren (standaard doet het dit niet). Meestal wordt de vertragingsinformatie opgeslagen in de geconverteerde video, zodat de afspeelsoftware de vertragingen tijdens runtime kan corrigeren. Als dit niet gebeurt met uw speler, kunt u MCEBuddy vragen om automatisch voor deze vertragingen te corrigeren door uw profiel te bewerken.
en het zou automatisch moeten corrigeren voor de audiovertragingen tijdens het converteren. Merk op dat dit alleen werkt voor profielen gebaseerd op ffmpeg, handbrake en mencoder encoders, het werkt niet op profielen die de copy encoder gebruiken.
Als alternatief, als u een vaste hoeveelheid afwijking in alle video’s ziet, kunt u hier ook voor corrigeren via de Conversion task → Expert settings → Audio delay
Nou, ik heb zowel het invoerbestand als het bestand dat MCEBuddy maakt in mijn upload opgenomen. De invoer-/originele video heeft geen vertraging en speelt prima af op elk apparaat en elke app die ik heb geprobeerd zonder enige audio problemen.
MediaInfo toont geen audiostoring in het originele bestand.
Het uitvoerbestand van MCEBuddy meldt dat er een vertraging is, en zorgt ervoor dat de video ofwel niet afspeelbaar is (Apple TV) of dat de video later begint met afspelen bij mediaspelers zoals VLC.
Als ik de MCEBuddy-video neem en deze opnieuw mux met mkvtoolnix, vertoont de video geen audiostoring en speelt deze perfect af - geen vertragingen, fouten, enz.
Er is geen consistente audiostoring op de uitvoervideo. Ze zijn elke keer anders.
Het profiel MKV Unprocessed zou geen Handbrake moeten gebruiken. Dit profiel zou niets anders moeten doen dan mogelijk de video bijsnijden zonder enige conversie van de video of audio.
Ik gebruik alleen profielen om mijn bestaande serie-afleveringen te nemen, de ondertitels te integreren, indien nodig aan het begin bij te snijden, ze te hernoemen en te verplaatsen.
Dus, ik geloof dat alleen ffmpeg en waarschijnlijk mkvmerge worden gebruikt. – Als ik het mis heb en mkvmerge niet wordt gebruikt, kan ik MCEBuddy dan laten mkvmerge gebruiken om de bestanden met ondertitels te schrijven voordat ze worden verplaatst?
Nee, ik heb afwijkingen gezien van slechts een fractie van een seconde tot bijna 2 seconden - dat zijn zeker video’s die niet door Apple TV kunnen worden afgespeeld.
Elke video die ik door MCEBuddy laat verwerken, gaat erin zonder gerapporteerde audiostoring. Elke video die door MCEBuddy wordt uitgevoerd, heeft een storing die wordt geïntroduceerd/gevonden – die er voorheen niet leek te zijn.
Ik acht het zeer onwaarschijnlijk dat elke video die ik heb een soort van onopgemerkt/onopgemerkte audiostoring heeft gehad. Ik heb het over tienduizenden video’s gedurende de afgelopen 5 maanden. (Ik ben mijn hele tv-bibliotheek opnieuw aan het rippen vanaf de bronmedia)
Alle video’s die door MCEBuddy worden samengevoegd, hebben een seconde of twee nodig voordat de video verschijnt in VLC Media Player op Windows - ongeacht hoe klein of groot de audio-afwijking is.
Correctie, ik wilde gewoon een actueel voorbeeld krijgen van video’s die ik de afgelopen 24 uur door MCEBuddy heb gehaald en de eerste die ik controleerde is ruim langer dan 2 seconden
Ik heb zojuist de map met één seizoen die ik gisteren met MCEBuddy heb gebruikt om ondertitels toe te voegen en te organiseren – de serie met de -7 s 600 ms vertraging – genomen, en ik heb de bestanden uit mijn Plex TV-map verplaatst en ze opnieuw in de wachtrij van MCEBuddy geplaatst met audiodelay=auto en nu lopen de door MCEBuddy uitgevoerde video’s totaal niet meer synchroon.
Zelfs de aflevering hierboven met de -7,6 ms is nu -10,88 ms – dus het heeft niet eens het 7,6 nummer gebruikt en de audio met nog eens ongeveer 3 seconden verschoven.
Gelukkig heb ik een back-up gemaakt in plaats van te vervangen.
Ik heb zojuist enkele nieuwe afleveringen die rechtstreeks van Blu-ray kwamen, door MCEBuddy gehaald met de wijziging ffmpeg-audiodelay=auto, en die video (evenals een paar andere die geen audiodelay vertoonden) door MCEBuddy gehaald en ze kwamen allemaal met ‘geïntroduceerde’ vertragingen tevoorschijn.
Ik vermoed dat de vertragingen worden veroorzaakt door ffmpeg tijdens de tussenliggende remuxingstap, die voornamelijk nodig is om de compatibiliteit met andere programma’s te verbeteren. Gezien uw configuratie heeft u die tussenliggende stap mogelijk niet nodig.
Probeer de optie Skip remuxing (Overslaan van remuxen) op de conversietaak → expertinstellingenpagina aan te vinken en te kijken of dat uw probleem oplost.
Ik heb letterlijk meer dan 124.000 afleveringen, waarvan de meerderheid van die afleveringen/video’s deze (zijn ze kunstmatig?) audiostoringen heeft - sommige maken ze onspeelbaar op Apple TV-apparaten, en de overige hebben vertragingen bij het afspelen van de video op spelers zoals VLC op andere apparaten.
Momenteel gebruik ik MKV Unprocessed met de Metadata lookup ingesteld op het prioriteren van Seizoen/Afleveringstitel en het Overschrijven van de Metedata Bestandsnaam met TVDB voor consistentie en ook om te voorkomen dat shows die afleveringstitels hergebruiken verkeerd worden gematcht met het verkeerde seizoen (ik denk dat MCEBuddy altijd de vroegste afleveringen S/E in de serie gebruikt…).
Dus, wat zou u aanraden als de beste/eenvoudigste methode om deze afleveringen opnieuw te muxen zonder de volgorde van de afleveringen mogelijk te verpesten?
Ook heb ik er de laatste tijd niet veel aandacht aan besteed, maar ik denk dat de standaard Unprocessed een beetje van het begin van elke video afsnijdt om er zeker van te zijn dat er geen fouten of weggevallen beelden aan het begin van de video zijn.
Als ik MKV Unprocessed opnieuw op deze bestanden uitvoer, zal het van elk een “klein beetje meer” van het begin afsnijden en dat zou potentieel belangrijke informatie van elke video kunnen ‘wissen’.
Aangezien alle bestanden al een naam hebben en de juiste metadata aan elk bestand is gekoppeld, is er dan een betere manier om al deze video’s te repareren/herstellen - in plaats van het MKV Unprocessed profiel te gebruiken?
Als er geen inkorting aan het begin van de video’s wordt gedaan, zouden mijn externe ondertitels (met de .forced .sdh, etc.) ongewijzigd kunnen blijven en hoeven alleen de mkv-bestanden opnieuw gemuxt te worden.
Dat zou niet moeten gebeuren, dat probleem is jaren geleden opgelost. Er zou GEEN bijsnijden mogen plaatsvinden met de standaard profiles.conf en standaard mcebuddy.conf, tenzij je de conversietaak specifiek hebt geconfigureerd om bij te snijden in de expertinstellingen of een oud of aangepast profiel gebruikt.
Ik zou aanraden om een nieuw onderwerp te starten met betrekking tot de metadata, ik ben niet duidelijk wat je probeert te doen.
We hebben het probleem gevonden en het lijkt erop dat het een bug is met ffmpeg, zelfs als we ffmpeg vertellen om niets te knippen/overslaan (-ss 0), probeert het de sporen te synchroniseren als het er een tegenkomt en verliest het daarbij de synchronisatie.
Dus als ergens in het conversieproces (remuxen, profielen, enz.) een -ss 0 staat, zal dit het synchronisatieprobleem veroorzaken.
We zullen het patchen (momenteel bevatten de meeste van onze profielen ook -ss 0, dus zelfs als je het remuxen overslaat maar een standaardprofiel gebruikt, zal het nog steeds het probleem veroorzaken).
Probeer de 2.6.7 BETA-build van vandaag (houd remuxing aan om te testen) en dit zou de problemen met de audiosynchronisatie moeten oplossen. Er zouden geen wijzigingen van uw kant aan uw bestaande profielen of instellingen nodig moeten zijn.
Oh, gelukkig maar! Ik was net aan het inloggen om u te laten weten dat ik het probleem weer zie - de andere twee bestanden die ik heb getest, waren waarschijnlijk niet representatief voor het probleem.
Ik weet niet zeker of dit iets met de bèta te maken heeft, of dat ik iets verkeerd heb gedaan tijdens het zoeken/vervangen van de remux-instellingen, maar de srt-ondertitels worden niet langer samengevoegd in de mkv – de externe ondertitels worden echter wel naar de doelmap gekopieerd.
Ik heb zojuist een nieuw zip-bestand in de uploadmap geplaatst, zodat u het kunt bekijken.
Bevat: logs en conf-bestanden
De Longmire-afleveringen zijn degene die ik in oktober 2022 heb gemaakt en die dit probleem ook hebben.
De Forgive Me-afleveringen zijn degene die ik zojuist in Handbrake heb getranscodeerd - geverifieerd, geen audiovertraging.
U hebt een beschadigd bestand of een beschadigde installatie
FOUT> 2025-08-27T06:05:47 MCEBuddy.AppWrapper.MKVMerge → Applicatiebestand niet gevonden of niet toegankelijk: C:\Program Files\MCEBuddy2x\MKVMerge\MKVMerge.exe
Bedankt.
Ik heb opnieuw geïnstalleerd en de map en de uitvoerbare bestanden zijn aanwezig.
Oké, ik heb de afleveringen van gisteren opnieuw verzonden (~60) en die bestanden lijken in orde te zijn.
Als ik enkele afleveringen (Longmire) die in 2022 via MCEBuddy zijn verwerkt, opnieuw door MCEBuddy laat gaan met de nieuwe build waarbij Remux standaard is ingesteld en Overslaan, behouden ze nog steeds de eerdere bestanden “vertraging ten opzichte van video”.
Als ik datzelfde bestand uit 2022 neem en het via MKVToolNix verwerk zonder enige vertraging voor het audiospoor, vertoont het uitvoerbestand geen vertraging in MediaInfo en speelt het onmiddellijk af in VLC zonder vertraging in het begin van de video.
Denkt u dat er een manier is om de vertraging te “corrigeren” en/of te verwijderen met behulp van MCEBuddy?
Ik heb net gecontroleerd en, eerlijk gezegd, als ik naar een willekeurige steekproef van al mijn serie-afleveringen kijk die teruggaan tot minstens 2022, hebben ze vertragingen – gelukkig lijken de afleveringen die ik heb gecontroleerd uit 2014 en 2015 de vertragingen niet te hebben (maar die a) hebben geen externe ondertitels en b) werden ze geconverteerd via MCEBuddy met Handbrake.
Een van die
Mijn zorg en angst is dat ik afgelopen herfst ben begonnen met het vervangen van talloze series (30.000, 60.000? afleveringen) met nieuwe digitale masters ter vervanging van mijn WMC-opnames en andere.
Laat me weten welke opties ik heb… Als dat binnen uw blikveld ligt.
Hmm, ik zie geen vertraging meer na de conversie met de bestanden die je eerder had geüpload.
Kun je het conversielogboek en het originele bestand dat vertragingen vertoont, uploaden?
Stappen om te reproduceren
Aanvullende opmerkingen
