Salut à tous,
Je rencontre un problème récurrent avec MCEBuddy 2.6.7 en utilisant la tâche « MKV Unprocessed ». Après traitement, mes fichiers MKV affichent un délai audio négatif d’environ -1,997 s (confirmé via MediaInfo). Cela provoque :
• VLC lit l’audio immédiatement tandis que la vidéo reste en retard avec un écran noir pendant ~2 secondes.
• Apple TV (via Infuse ou Plex) échoue à la lecture sauf si le fichier est remuxé via MKVToolNix.
• Plex peine avec Direct Play et/ou Direct Stream — un ami avec Apple TV confirme que ces fichiers ne lisent pas proprement tant qu’ils ne sont pas remuxés.
Ce délai n’est pas présent :
• Dans le MKV original
• Dans le fichier après HandBrake (NVENC x265)
Seule la sortie MCEBuddy introduit le délai.
Étapes de reproduction
Partir d’un MKV propre
→ Se lit bien dans VLC, Apple TV et Plex.
Passer par HandBrake (NVENC x265)
→ Se lit toujours bien, pas de délai.
Traiter avec MCEBuddy 2.6.7 via « MKV Unprocessed »
→ Activer le téléchargement de métadonnées et le renommage (paramètres par défaut ainsi qu’avec Cut Start xx utilisé).
Skip Copying et Skip remux ne sont pas cochés.
Ouvrir le MKV final dans MediaInfo
→ Observer Delay relative to video: -1 s 997 ms sur le flux audio.
Lire dans VLC
→ L’audio démarre instantanément, la vidéo traîne avec écran noir.
Essayer Apple TV ou Plex
→ Lecture échoue ou met en mémoire tampon indéfiniment sauf remux via MKVToolNix.
Remarques complémentaires
• Remplacer mkvmerge.exe dans le dossier MCEBuddy par la dernière version ne corrige pas le problème.
• Il est possible que MCEBuddy invoque ffmpeg ou utilise des flags obsolètes modifiant la synchronisation des flux.
• Remuxer le MKV final avec MKVToolNix (sans correction de délai audio) résout le problème sur toutes les plateformes.
Je peux fournir les logs MediaInfo ou des fichiers d’exemple si cela aide. J’aimerais savoir si d’autres ont vu cela et s’il existe un moyen d’empêcher MCEBuddy d’introduire le délai.
Merci !
—John
Désolé, j’ai oublié de joindre Audio Delay and Black Screen in VLC.7z (121,8 Ko)
Je rencontre un problème similaire avec les versions 2.6.7 et 2.6.6, mais en utilisant MP4 Haute Qualité. À mi-parcours du film, l’audio se désynchronise avec la vidéo. Cela ne se produisait pas dans les versions précédentes.
Je ne constate pas ce problème avec nos vidéos de test. Pouvez-vous tous les deux télécharger vos vidéos originales sur le serveur avec les journaux de conversion (afin que nous puissions reproduire chaque paramètre) pour que nous puissions analyser et voir ce qui se passe.
Les fichiers et les nouveaux journaux sont désormais situés dans ‘\\upload.mcebuddy2x.com\JohnFreiman\’
Cela se produit avec 99 ou 100 % des fichiers.
Chopped S63E09.mkv -- Original
Chopped - s63e09 - In Cod We Trust.mkv -- Sortie MCEBuddy
srt subs.7z -- sous-titres externes
Les sous-titres srt externes sont nécessaires pour que Plex reconnaisse les sous-titres forcés, non-SDH et SDH.
Je ne sais pas si c’est lié, mais j’ai des sous-titres externes (avec chaque vidéo) qui sont ajoutés à la sortie.
logs.7z -- "mcebuddy.log" & "Chopped S63E09.mkv-TV to Television-2025-08-21T00-55-38.log"
** mise à jour **
Je viens d’ajouter une archive zip avec les fichiers .conf au cas où j’aurais fait une erreur au fil des années…
"conf files.7z"
mise à jour 2
Bien que l’épisode de Chopped que j’ai téléversé présente un décalage audio, il n’est pas aussi grave que celui des journaux Countdown que j’ai téléversés dans mon OP plus tôt aujourd’hui — c’est simplement le dernier fichier que j’ai transcodé dont je possède encore l’original, mais il montre bien l’apparition du décalage audio.
Il n’est pas rare de rencontrer des décalages audio lors de la conversion de fichiers. Ils peuvent survenir pour diverses raisons.
MCEBuddy peut détecter ces décalages audio et les compenser si nécessaire (par défaut, il ne le fait pas). La plupart du temps, les informations de décalage sont stockées dans la vidéo convertie, de sorte que le logiciel de lecture devrait être capable de corriger les décalages à l’exécution. Si cela ne se produit pas avec votre lecteur, vous pouvez demander à MCEBuddy de corriger automatiquement ces décalages en modifiant votre profil.
John, d’après vos journaux, je vois dans votre profil :
ffmpeg-audiodelay=skip
changez ceci en
ffmpeg-audiodelay=auto
et cela devrait corriger automatiquement les décalages audio lors de la conversion. Notez que cela ne fonctionne que pour les profils basés sur les encodeurs ffmpeg, handbrake et mencoder, cela ne fonctionne pas sur les profils utilisant l’encodeur copy.
Alternativement, si vous constatez une quantité fixe de déviation dans toutes les vidéos, vous pouvez également la corriger à partir de la Tâche de conversion → Paramètres experts → Décalage audio
Eh bien, j’ai inclus le fichier d’entrée ainsi que le fichier que MCEBuddy crée dans mon téléchargement. La vidéo d’entrée/originale n’a aucun décalage et se lit correctement sur tous les appareils et applications que j’ai essayés sans aucun problème audio.
MediaInfo ne montre aucun décalage audio dans le fichier original.
Le fichier de sortie de MCEBuddy signale qu’il y a un décalage, et provoque soit l’incompatibilité de la lecture (Apple TV) soit un début de vidéo décalé sur les lecteurs vidéo comme VLC.
Si je prends la vidéo MCEBuddy, que je la remuxe en utilisant mkvtoolnix, la vidéo ne présente aucun décalage audio et se lit parfaitement - sans décalages, échecs, etc.
Il n’y a pas de décalage audio constant sur la vidéo de sortie. Ils sont différents à chaque fois.
Le profil MKV Unprocessed ne devrait pas utiliser Handbrake. Ce profil ne devrait rien faire d’autre que potentiellement couper la vidéo sans aucune conversion de la vidéo ou de l’audio.
J’utilise simplement des profils pour prendre mes épisodes de série existants, intégrer les sous-titres, couper le début si nécessaire, les renommer et les déplacer.
Donc, je crois que seuls ffmpeg et probablement mkvmerge sont utilisés. – Si je me trompe et que mkvmerge n’est pas utilisé, puis-je demander à MCEBuddy d’utiliser mkvmerge pour écrire les fichiers avec les sous-titres avant de les déplacer ?
Non, j’ai vu des écarts aussi petits qu’une fraction de seconde jusqu’à près de 2 secondes - ce sont certainement des vidéos qui ne peuvent pas être lues par Apple TV.
Chaque vidéo que j’utilise MCEBuddy pour traiter entre sans aucun décalage audio signalé. Chaque vidéo qui est sortie avec MCEBuddy a un décalage introduit/détecté - qui ne semblait pas être là auparavant.
Je trouve très peu probable que toutes les vidéos que je possède aient eu une sorte de problème de décalage audio non détecté/indétectable. Je parle de dizaines de milliers de vidéos au cours des 5 derniers mois. (Je ré-extrais toute ma bibliothèque TV à partir des médias sources)
Toutes les vidéos fusionnées par MCEBuddy prennent une ou deux secondes avant que la vidéo n’apparaisse dans VLC Media Player sur Windows - quelle que soit la petitesse ou l’ampleur de la déviation audio.
Correction, je voulais juste obtenir un échantillon actuel des vidéos que j’ai traitées avec MCEBuddy au cours des dernières 24 heures et la première que j’ai vérifiée est bien au-delà de 2 secondes
Je viens de prendre le dossier avec une saison que j’ai utilisée avec MCEBuddy pour ajouter des sous-titres et organiser hier – la série avec le décalage de -7 s 600 ms, et j’ai déplacé les fichiers de mon dossier Plex TV, et je l’ai remis en file d’attente dans MCEBuddy avec audiodelay=auto et maintenant les vidéos de sortie de MCEBuddy sont totalement désynchronisées.
Même l’épisode ci-dessus avec les -7,6 ms est maintenant à -10,88 ms – donc il n’a même pas utilisé le nombre 7,6 et a décalé l’audio d’environ 3 secondes supplémentaires.
Heureusement, j’ai fait une sauvegarde au lieu de remplacer.
Je viens de prendre quelques nouveaux épisodes qui provenaient directement de Blu-ray et je les ai passés dans MCEBuddy avec la modification ffmpeg-audiodelay=auto, et cette vidéo (ainsi que quelques autres qui n’affichaient aucun délai audio) passée dans MCEBuddy et elles ont toutes abouti avec des délais « introduits ».
Je soupçonne que les retards sont introduits par ffmpeg pendant l’étape intermédiaire de remuxage, qui est principalement nécessaire pour améliorer la compatibilité avec d’autres programmes. Compte tenu de votre configuration, vous n’avez peut-être pas besoin de cette étape intermédiaire.
Essayez de cocher l’option Ignorer le remuxage dans la tâche de conversion → page des paramètres experts et voyez si cela résout votre problème.
J’ai littéralement plus de 124 000 épisodes dont la majorité de ces épisodes/vidéos présentent ces (sont-ils artificiels ?) décalages audio - certains les rendant injouables sur les appareils Apple TV, et les autres présentent des décalages lors de la lecture de la vidéo sur des lecteurs tels que VLC sur d’autres appareils.
Actuellement, j’utilise MKV Non traité avec la recherche de métadonnées définie pour prioriser le titre de la saison/l’épisode et l’écrasement du nom de fichier des métadonnées en utilisant TVDB pour la cohérence et également pour empêcher que les émissions qui réutilisent les titres d’épisodes ne soient incorrectement associées à la mauvaise saison (je pense que MCEBuddy utilise toujours les premiers épisodes S/E de la série…
Alors, quelle serait la meilleure/plus simple méthode pour remuxer ces épisodes sans potentiellement gâcher l’ordre des épisodes ?
De plus, je n’y ai pas prêté beaucoup d’attention dernièrement, mais je pense que le paramètre par défaut Non traité coupe un peu du début de chaque vidéo pour s’assurer qu’il n’y a pas d’erreurs ou d’images sautées au début de la vidéo.
Si je réexécute MKV Non traité sur ces fichiers, cela coupera un « peu plus » du début de chacun et cela pourrait « effacer » des informations potentiellement importantes de chaque vidéo.
Étant donné que tous les fichiers sont déjà nommés et que les métadonnées appropriées sont attachées à chaque fichier, existe-t-il un meilleur moyen de réparer/corriger toutes ces vidéos – plutôt que d’utiliser le profil MKV Non traité ?
Si aucun rognage n’est effectué au début des vidéos, mes sous-titres externes (avec .forced .sdh, etc.) pourraient rester inchangés et seuls les fichiers mkv devraient être remuxés.
Cela ne devrait pas se produire, ce problème a été corrigé il y a des années. Il ne devrait y avoir AUCUNE suppression avec les fichiers profiles.conf et mcebuddy.conf standards, sauf si vous avez spécifiquement configuré la tâche de conversion pour supprimer dans les paramètres experts ou si vous utilisez un profil ancien ou personnalisé.
Je recommanderais de créer un nouveau sujet concernant les métadonnées, je ne vois pas clairement ce que vous essayez de faire.
Nous avons trouvé le problème et il semble qu’il s’agisse d’un bogue avec ffmpeg, même si nous disons à ffmpeg de NE PAS couper/sauter quoi que ce soit (-ss 0), s’il en rencontre un, il essaie de synchroniser les pistes et perd la synchronisation dans le processus.
Ainsi, si à n’importe quel endroit du processus de conversion (remuxage, profils, etc.) il y a un -ss 0, cela créera ce problème de synchronisation.
Nous allons le corriger (actuellement, la plupart de nos profils incluent également -ss 0, donc même si vous sautez le remuxage mais utilisez un profil standard, cela créera toujours le problème).
Essayez la version BETA 2.6.7 d’aujourd’hui (gardez le remuxage activé pour tester) et cela devrait résoudre les problèmes de synchronisation audio. Aucune modification ne devrait être nécessaire de votre côté concernant vos profils ou paramètres existants.
Oh, merci du ciel ! J’étais justement en train de me connecter pour vous informer que je rencontre à nouveau le problème - les deux autres fichiers que j’ai testés ne devaient pas être représentatifs du problème.
Je ne suis pas sûr si cela vient de la version bêta, ou si j’ai foiré quelque chose en faisant un rechercher/remplacer dans les paramètres de remuxage, mais les sous-titres srt ne sont plus fusionnés dans le mkv – cependant, les sous-titres externes sont copiés dans le dossier de destination.
J’ai juste déposé un nouveau fichier zip dans le dossier de téléchargement pour que vous puissiez jeter un œil.
Contient : journaux et fichiers de configuration
Les épisodes de Longmire sont ceux que j’ai créés en octobre 2022 et qui présentent également ce problème.
Les épisodes de Forgive Me sont ceux que je viens de transcoder dans Handbrake - vérifié, pas de décalage audio.
Merci.
J’ai réinstallé et le dossier ainsi que l’exécutable sont présents.
Ok, j’ai renvoyé les épisodes d’hier (~60) et ces fichiers semblent bons.
Si je prends certains épisodes (Longmire) qui ont été traités via MCEBuddy en 2022 et que je les exécute à nouveau via MCEBuddy avec la nouvelle version, en laissant Remux par défaut et Skip, les fichiers précédents conservent toujours le « délai par rapport à la vidéo ».
Si je prends ce même fichier de 2022 et que je le passe dans MKVToolNix sans aucun délai pour la piste audio, le fichier de sortie n’affiche aucun délai dans MediaInfo et se lance immédiatement dans VLC sans aucun décalage de démarrage de la vidéo.
Pensez-vous qu’il existe un moyen de « corriger » et/ou de supprimer le délai en utilisant MCEBuddy ?
Je viens de vérifier et, honnêtement, en regardant un échantillon aléatoire de tous les épisodes de mes séries remontant au moins à 2022, ils présentent des délais – heureusement, les épisodes de 2014 et 2015 que j’ai vérifiés ne semblent pas avoir de délais (mais ceux-là a) n’ont pas de sous-titres externes et b) ont été convertis via MCEBuddy avec Handbrake).
L’un ou l’autre
Mon inquiétude et ma crainte sont d’avoir commencé à remplacer d’innombrables séries (30 000, 60 000 ? épisodes) l’automne dernier par de nouvelles sources numériques pour remplacer mes enregistrements WMC et autres.
Faites-moi savoir quelles options s’offrent à moi… Si cela relève de votre champ de compétence.
Hmm, je ne vois plus de retard après la conversion avec les fichiers que vous aviez téléchargés précédemment. Pouvez-vous télécharger le journal de conversion et le fichier original qui présente des retards ?
Étapes de reproduction
Remarques complémentaires
