Meilleure façon de gérer un dossier avec plusieurs formats audio

Support Général / Questions
1

Ok, donc j’ai un dossier plein de mkv que je voudrais traiter. J’essaie de comprendre comment gérer correctement l’audio.

Mes fichiers contiennent un mélange de stéréo et de surround, il y a même du mono. Mon objectif est de configurer une tâche qui applique un ensemble de paramètres audio pour tout ce qui est à 2 canaux ou moins, et un autre ensemble pour tout ce qui dépasse 2 canaux. Cette fonctionnalité est déjà intégrée à MCEBuddy pour l’AC3, mais uniquement pour l’AC3, ce qui fait qu’elle ignore le DTS, etc.

Je pensais simplement faire un « pass-through » de certains formats comme l’AAC, car c’est très probablement la source 2 canaux, mais j’ai aussi des fichiers 2 canaux en E-AC3, AC3, FLAC, etc. Donc deviner si l’audio est 2 canaux en se basant uniquement sur le codec ne fonctionnera pas. Faire un « pass-through » de l’audio 6 canaux me conviendra très bien si la source est AC3 ou E-AC3, mais je ne veux pas faire de « pass-through » du DTS. Le but est de réduire la taille du fichier, et le DTS est un peu trop lourd.

Je me souviens avoir vu un fil où quelqu’un avait une commande CLI qui faisait du « pass-through » audio en fonction du débit audio. Le principe était que si le débit est inférieur à ~200 kbps, il y a de fortes chances que ce soit 2 canaux ou moins. Au-dessus, il y a de fortes chances que ce soit 6 canaux, etc. Malheureusement, je n’ai pas mis ce fil en favori et je n’arrive pas à le retrouver.

Donc, je cherche de l’aide et des suggestions. Comment géreriez-vous un dossier comme celui-là ?

2

Voici une idée alternative utilisant les profils. Les profils MCEBuddy possèdent une fonctionnalité appelée combinaisons non prises en charge. En gros, pour un encodeur de profil, vous pouvez spécifier des combinaisons non prises en charge de paramètres vidéo, audio et conteneur. S’il rencontre cette combinaison, cet encodeur est ignoré et il passe au suivant. Plus de détails ici :

Grâce à ce paramètre, vous pouvez aborder le problème de deux façons différentes :

  1. Utiliser le premier encodeur pour ne pas gérer certaines combinaisons (par exemple, HandBrake ne gère pas les flux DTS et copie les pistes audio), puis un autre pour gérer le reste (ffmpeg encode toutes les pistes audio en AC3). Un exemple ressemblerait à ceci (seule la partie pertinente du profil, vous devez compléter le reste) :

    order=handbrake,ffmpeg
    handbrake-unsupported=dts
    handbrake-audio=-E copy
    handbrake-audioac3=-E copy
    ffmpeg-audio=-acodec ac3 -ab 384k
    ffmpeg-audioac3=-acodec ac3 -ab 384k

  2. La deuxième approche consiste à utiliser des profils avec des tâches de conversion : vous créez 2 profils, vous ne spécifiez qu’un seul encodeur dans chaque profil et, pour l’un des profils, vous indiquez dts comme non pris en charge et, pour l’autre, vous indiquez aac,ac3 comme non pris en charge. Créez deux tâches de conversion, chacune utilisant l’un des deux profils créés ci-dessus. À présent, seule la tâche avec le profil qui ne prend pas en charge le codec audio échouera et l’autre s’exécutera.

3

L’approche « fall through » était la première chose que j’ai examinée juste après avoir posté. C’est intéressant et plutôt astucieux car cela permet d’isoler vos réglages par format. Malheureusement, ce n’est pas vraiment ce dont j’ai besoin.

Mon problème, c’est que le même codec/format existe en plusieurs saveurs de canaux. Avec Atmos ou DTS, on peut partir du principe que le son ne sera pas 2.0, mais avec EAC3, AC3 ou même AAC ou Flac, cela peut être du 2.0 ou du 5.1. Je peux donc faire « fall through » l’ordre des profils jusqu’à en trouver un pour, disons, l’AAC, mais ensuite je n’ai aucun moyen de savoir si c’est de l’AAC 2.0 ou 5.1, etc. En gros, isoler un codec n’est pas ce qu’il me faut ; j’ai besoin de déterminer si le flux est 2.0 ou surround, et que MCEBuddy ajuste automatiquement les paramètres en conséquence.

MCEBuddy possède bien un mécanisme interne pour distinguer 2.0 vs 5.1, mais il ne fonctionne qu’avec l’AC3. Par exemple, j’ai repris le même profil que vous avez posté et changé le ffmpeg-audio à 192, car c’est plus adapté que 384 pour du stéréo.

order=handbrake,ffmpeg
handbrake-unsupported=dts
handbrake-audio=-E copy
handbrake-audioac3=-E copy
ffmpeg-audio=-acodec ac3 -ab 192k
ffmpeg-audioac3=-acodec ac3 -ab 384k

Si j’utilise ces réglages avec un fichier EAC3 5.1, il produira un fichier audio à 192 k. Si le format de sortie est réglé sur AAC, il produira 256 k, etc.

Même chose pour AAC 2.0 vs 5.1, etc. L’AC3 fonctionnera comme prévu, car la logique est déjà intégrée (et uniquement pour lui) et produira 192 k en 2.0 ou 384 k en 5.1. En résumé, avec tout sauf l’AC3, la ligne ffmpeg-audioac3 est totalement ignorée et n’a aucun effet sur la conversion ; seule la ligne ffmpeg-audio est utilisée par MCEBuddy. Si vous cochez la case « surround » dans l’interface, MCEBuddy passera le flag -6ch à la ligne ffmpeg-audio et considérera ces réglages comme vos paramètres surround.

Dans mon exemple, j’ai utilisé 192 k pour la sortie 2.0 et 384 k pour la 5.1. Puisque l’AAC n’est pas de l’AC3, MCEBuddy ignorera ffmpeg-audioac3=-acodec ac3 -ab 384k et utilisera ffmpeg-audio=-acodec ac3 -ab 192k. Si j’ai coché « surround » dans l’interface, il passera le flag -6ch et j’obtiendrai quelque chose comme ffmpeg-audio=-acodec ac3 -ab 192k -6ch. Si ma sortie est aussi en AAC, une sorte de sécurité interne se déclenche au démarrage de la conversion : elle n’autorise pas un mix 5.1 à 192 k. Elle augmentera automatiquement le bitrate à 256 k (le minimum pour de l’AAC 5.1). Je finirai donc avec un fichier 5.1 à 256 k. Je ne sais pas s’il fait de même pour les autres formats.

Idéalement, il serait génial que ffmpeg-audioac3 serve de réglage « catch-all » pour tout le surround, pas seulement l’AC3, tandis que ffmpeg-audio gérerait tous les mix 2.0. Mais cette fonctionnalité n’existe pas. Trouver une solution de contournement s’est révélé difficile jusqu’à présent.

4

vous pouvez toujours ouvrir une demande de fonctionnalité pour gérer les balises telles que <encoder>-audiodts ou similaires pour l’audio non AC3.

5

Si -audiodts fonctionnait selon le même principe que -audioac3, alors cela devrait marcher, mais il me faudrait en créer un pour chaque format – -audioflac, -audioaac, etc., etc., etc.

Je pense qu’une solution plus simple serait quelque chose comme
ffmpeg-audio <=2ch – réglages 192 kb
ffmpeg-audio >2ch – réglages 448 kb

Autrement dit, la vérification devrait se faire selon le nombre de canaux audio, pas le codec. Ainsi, le codec d’entrée deviendrait totalement indifférent : un FLAC ou AAC à 2 canaux sortira en 192 k, le même fichier FLAC ou AAC à plus de 2 canaux sortira en 448 k, etc.

Pour l’instant, mon codec de sortie par défaut est l’EAC3 à 448 k. Il fonctionne très bien en 6 canaux, mais comme MCEBuddy ne tient pas compte du fait que l’audio d’entrée soit stéréo ou 5.1, j’obtiens des fichiers stéréo à 448 k quand la piste n’a que 2.0. 448 k pour du stéréo, c’est du gaspillage, et c’est ce que je cherche à éviter.

Je réalise aussi que cette fonctionnalité dépasse le cadre du programme. Il est censé retirer les pubs et réduire les fichiers issus d’un DVR. A ma connaissance, aucun DVR n’enregistre en EAC3, FLAC, AAC, etc., donc je demanderais au développeur de coder/ajouter quelque chose qui n’a rien à voir avec la fonction principale de l’application. Je me sens un peu mal de faire ça, et j’aimerais trouver ma propre solution.

6

Pas besoin de vous sentir mal, créez une demande de fonctionnalité, expliquez le besoin et les suggestions, et ouvrez la discussion afin que nous puissions mettre en œuvre la meilleure solution.

7

Terminé.

Voyons ce qu’il se passe :slight_smile: