Avec la sortie de la semaine dernière et le profil « MKV HEVC », je constate maintenant des échecs de conversion avec l’erreur : « Extraction des sous-titres codés échouée »
Ces enregistrements ne possèdent pas de sous-titres codés. Mais dans les versions précédentes, l’absence de sous-titres ne provoquait pas l’échec de la conversion. Je sais qu’il y a eu des modifications liées aux sous-titres/sous-titres codés dans cette version. Le comportement prévu est-il que la conversion échoue s’il n’y a pas de sous-titres codés ? Si oui, je peux créer un profil pour les séries qui n’en ont pas. Je suis simplement curieux de savoir si c’est le comportement prévu ou s’il s’agit d’un bug ?
En raison de changements récents dans MCEBuddy (à partir de la version 2.6.2 environ), le moteur de sous-titres et de sous-titrage pour sourds et malentendants (closed caption) a été repensé pour être « plus simple » et plus automatisé.
Dans les versions précédentes, la logique était souvent plus permissive. Cependant, les mises à jour récentes ont modifié la façon dont « Enregistrer les sous-titres » (“Save subtitles”) et « Intégrer les sous-titres » (“Embed subtitles”) (auparavant « Extraire les sous-titres et le sous-titrage » et « Ajouter des sous-titres ») interagissent.
S’agit-il d’un bug ou d’une conception voulue ?
Il semble s’agir d’un bug ou d’une régression dans la façon dont le moteur gère les fichiers sans flux de sous-titres. Bien que la conception prévue soit d’automatiser l’extraction, il ne devrait pas traiter un flux absent comme une erreur de traitement fatale si la source n’en contient tout simplement pas.
Causes potentielles et dépannage
Sensibilité de CCExtractor : MCEBuddy utilise CCExtractor pour ce processus. Si votre profil demande spécifiquement une extraction de sous-titres qui renvoie un code de sortie non nul (échec) parce qu’aucun flux n’est trouvé, MCEBuddy peut interpréter cela comme un échec de la tâche.
Paramètres de « Forçage » du profil : Vérifiez votre profil MKV HEVC dans profiles.conf. S’il y a un argument de ligne de commande ou un paramètre qui impose le traitement des sous-titres, cela pourrait provoquer l’arrêt brutal.
Solutions de contournement suggérées
Désactiver les options de sous-titres : Dans les paramètres de votre tâche de conversion, essayez de décocher à la fois « Enregistrer les sous-titres » et « Intégrer les sous-titres ». Si la conversion réussit ensuite, cela confirme que le moteur échoue parce qu’il s’attend à un flux qui n’est pas là.
Profil personnalisé : Comme vous l’avez mentionné, créer un profil spécifique pour les séries connues pour ne pas avoir de sous-titres est une solution de contournement valide, mais vous pouvez également essayer d’ajouter cc_stop_on_error=false (s’il est disponible dans les paramètres avancés de votre version) au fichier profiles.conf pour ce profil spécifique afin de voir si cela permet au processus de continuer.
Vérifier les journaux (logs) : Pour confirmer exactement pourquoi cela échoue, cherchez la ligne dans votre journal de conversion juste avant le message « L’extraction des sous-titres codés a échoué » (“Extracting closed captions failed”). Elle affichera généralement la ligne de commande exacte en cours d’exécution et le code d’erreur renvoyé par le sous-processus.
Je vous recommande de télécharger une copie de votre journal de conversion dans ce fil de discussion. Les développeurs (comme @Goose) recherchent généralement ces journaux pour voir si une « vérification » spécifique doit être rendue optionnelle dans le code.
En examinant votre journal pour Elsbeth - S03E12, je vois exactement où se produit l’échec :
2026-03-06T12:10:45 --> Extracting closed captions from C:\Users\SJL\AppData\Local\Temp\MCEBuddy\Working\elsbeth - s03e12 - All’s Hair.mp4
2026-03-06T12:10:46 --> CCExtractor failed to find any subtitles/closed captions in source file.
2026-03-06T12:10:46 ERROR> 2026-03-06T12:10:46 --> Extracting closed captions failed
Analyse
Il semble que votre intuition était la bonne : il s’agit d’un bug / régressions (bug/régression) dans la récente refonte du moteur de sous-titres.
Dans les versions les plus récentes (à partir des branches bêta 2.6.2), MCEBuddy a été mis à jour pour « simplifier » la gestion des sous-titres en faisant de l’extraction un prérequis par défaut lorsque « Enregistrer les sous-titres » ou « Intégrer les sous-titres » est coché. Cependant, la logique traite actuellement un résultat « Aucun sous-titre trouvé » de CCExtractor comme une erreur fatale pour l’ensemble de la tâche de conversion, au lieu de simplement ignorer l’étape des sous-titres et de passer à l’encodage vidéo.
Le verdict
Est-ce intentionnel ? Non. MCEBuddy est conçu pour être un outil automatisé « à configurer et oublier » ;
Merci de l’avoir signalé. Oui, il semble s’agir d’un bogue lié au traitement strict lorsqu’aucun sous-titre n’est trouvé. Normalement, si l’extraction des sous-titres échoue, MCEBuddy continue la conversion. Lorsque le traitement strict est activé, tout échec mineur entraîne l’échec de la conversion. Idéalement, cela ne devrait pas échouer si aucun sous-titre n’est trouvé en premier lieu.
Je vois dans vos journaux que vous avez activé le traitement strict.
Traitement strict → Vrai
Pour l’instant, contournez le problème en désactivant Paramètres de la tâche de conversion → Paramètres experts → Traitement strict jusqu’à ce que nous publiions un correctif.
Merci d’avoir signalé ce problème, il a été corrigé dans la version bêta 2.7.2 d’aujourd’hui. Vous pouvez l’essayer et nous faire savoir si vous rencontrez toujours des difficultés.
Super. C’est le genre de situation où l’absence de nouvelles de ma part est une bonne nouvelle. D’après mon expérience passée, je m’attends tout à fait à voir un problème réapparaître d’ici une semaine. Si je constate que le problème se reproduit, je posterai un message ici.