Salut à tous,
J'ai écrit un petit programme nommé Playtag qui permet de mettre des paramètres de lecture d'un fichier audio ou vidéo (ex : le volume) dans un tag de ce fichier, puis de le lire en appliquant ces paramètres.
Le tag Playtag est une ligne de texte qui contiendra par exemple :
v1; t = 0:26; vol = +3dB
qui signifie que la lecture commencera à 26 secondes du début du fichier et que le volume sera augmenté de 3 décibels.
Motivation
Lors de la lecture d'un fichier audio ou vidéo, un lecteur tel que MPlayer ou VLC expose à l'utilisateur un certain nombre de paramètres : le volume, le fait de ne lire qu'une partie du fichier, etc.
Ces paramètres, s'ils ne concernent qu'un fichier en particulier, doivent être réglés lors de la lecture, à chaque lecture du fichier. S'il veut rendre le paramétrage persistant, l'utilisateur doit éditer le fichier dans une application séparée et le réencoder en un nouveau fichier.
L'édition de fichier audio et vidéo a des inconvénients : elle peut prendre un temps de calcul important et/ou induire une perte de qualité et/ou la perte d'une propriété technique de l'encodage d'origine dont l'utilisateur n'avait pas conscience, et bien sûr elle empêche de revenir à l'original si la modification consiste à tronquer le fichier par exemple.
À l'inverse, le fait de stocker de tels paramètres comme métadonnées, dans les tags d'un fichier, ne nécessite aucun calcul, n'entraine aucune perte de données, et est tout aussi efficace dans certains cas.
Et donc ?
Le programme (en Python, sous licence MIT) est un wrapper pour MPlayer et VLC qui permet de lire les fichiers avec (ou sans) tag Playtag en passant au lecteur choisi les paramètres nécessaires. Il intègre aussi des fonctions d'édition du tag en ligne de commande.
Le format du tag ne contient pour l'instant que quelques paramètres qui correspondent à mes propres besoins. Le format se veut naturellement ouvert, pour permettre en théorie à quelqu'un qui le souhaite de réaliser une implémentation indépendante compatible, intégrée à un lecteur par exemple.
Commentaires bienvenus :-)
# Une autre manière de faire
Posté par wiflye81 . Évalué à 0.
Bonjour,
Le projet est intéressant mais le wrapper c'est moyen.
J'ai eu une idée similaire pour une intégration "universelle" avec Trakt sauf que l'idée serait de passer par les protocoles de commandes et d'interrogation à distance comme MPRIS, Dbus ou bien les protocoles spécifiques à mpv et vlc.
[^] # Re: Une autre manière de faire
Posté par nahoj (site web personnel) . Évalué à 1.
L'idéal serait clairement une implémentation au sein de chaque lecteur ; un wrapper c'était la solution de facilité.
Je ne connaissais pas MPRIS ; c'est intéressant quoique dans une orientation différente de Playtag : des actions de lecture (play, pause, etc.) plus que des paramètres…
[^] # Re: Une autre manière de faire
Posté par Sébastien Wilmet . Évalué à 1.
GVfs permet d'écrire et lire des métadonnées. Soit en ligne de commande avec gvfs-set-attribute et gvfs-info, soit en utilisant l'API de GIO.
C'est ce qu'utilise par exemple gedit pour enregistrer des métadonnées, comme par exemple la position du curseur, la langue pour la correction orthographique, le langage utilisé pour la coloration syntaxique, le type d'encodage des caractères (UTF-8, …), etc.
# Not Invented Here
Posté par Zenitram (site web personnel) . Évalué à 3. Dernière modification le 18 juin 2016 à 10:28.
https://en.wikipedia.org/wiki/ReplayGain#Metadata
Et une "format" de plus, un!
(et en plus, ici c'est un unique tag pour faire plein de choses différentes, super… Car justement les tags sont la pour qu'un tag corresponde à une chose, ça fait du coup des tags dans les tags, la prochaine étape sera de faire une tag spécial dans le texte PlayTag qui sera formaté en Base64 pour pouvoir faire passer du binaire dans ce bloc de texte qui est dans un bloc binaire, et ainsi de suite)
[^] # Re: Not Invented Here
Posté par nahoj (site web personnel) . Évalué à 1.
Merci pour le lien ; je ne connaissais pas. En effet, il semble que ReplayGain rende superflu le paramètre de volume de Playtag. Malheureusement, si j'en crois cette page, ReplayGain n'est que partiellement supporté par MPlayer ; reste à voir s'il y a une raison particulière…
Ensuite, il ne t'a pas échappé que le volume n'est qu'un des paramètres supportés par Playtag ; je n'en suis donc pas à réinventer complètement la roue par fierté ou pour le fun. (Le volume est d'ailleurs le plus récent ajout à Playtag ; ça me semblait évident qu'il le fallait mais en pratique j'utilise surtout
t=...-....)Pour les autres paramètres, donc, vu l'état d'ébauche du format, il m'a semblé pertinent depuis que j'ai commencé à coder de les regrouper dans un seul tag pour ne pas pourrir mes fichiers de tags qui ne correspondent plus à rien si je changeais d'avis sur leur nom par exemple. Mais en faisant les choses plus sérieusement, les paramètres pourraient très bien en effet avoir chacun un tag séparé.
[^] # Re: Not Invented Here
Posté par Zenitram (site web personnel) . Évalué à 1.
Un format n'est pas supporté par un logiciel, utilisons ça comme argument contre celui qui le fait remarquer et continuons de créer un autre format pas plus supporté par ce logiciel plutôt que d'ajouter le support en lecture/écriture du format déjà supporté par d'autres lecteurs, youpi.
C'est quand même problématique d'inventer un nouveau format sans avoir jeté un oeil sur ce qui existe déjà, ce n'est pas comme si ce type de champs était rare… D'où le titre du commentaire.
Bon, jouons :
aspect-ratio: alors la, on est dans l'horreur à modifier l'aspect ratio déjà indiqué dans un fichier, plutôt que de corriger la metadata exactement prévu à cet effet dans le fichier. Et puis toucher à ça… Sans commentaire.
mirror: ne vaudrait-il pas mieux corriger tes enceintes, ou si c'est le fichier mettre les meta qui conviennent? certes c'est par format, mais voila, "corriger" un fichier ayant des meta par un meta en plus, c'est juste chiant à gérer pour les autres.
Au pire pourquoi ne pas utiliser un container MP4 avec un atom "chan" (Audio Channel Layout Atom)? Pas supporté partout, mais déjà dans plusieurs logiciels il me semble.
time: pas le premier non plus, mais j'avoue n'avoir jamais vu quelqu'un le mettre dans les meta du fichier lui-même, c'est plutôt dans la playlist que ça se met.
https://datatracker.ietf.org/doc/draft-pantos-http-live-streaming/?include_text=1
"EXT-X-START". Certes pas pour la fin, mais on pourrait imaginer un équivalent.
sinon, on peut empaqueter ça dans un MP4 (quasi tous les formats audio sont empaquetables dans un MP4) et ajouter un "Edit list".
Tu les pourris déjà pas mal même avec un tag, qui va embêter les autres ("qu'est-ce que c'est encore que ce nouveau tag? Zut, encore un truc en plus qu'on va me réclamer de supporter dans mon lecteur")
Je constate juste le syndrome (et d'ailleurs, il y a toujours un "je n'en suis donc pas à réinventer complètement la roue par fierté ou pour le fun" comme réponse pour s'en défendre, tout en ayant "oublié" de regarder ce qui existe, et puis les autres c'est pourri/pas adapté/etc de toutes façons, mon format est plus simple/plusmieuxbien), ce ne sera pas la première fois ni la dernière fois (tiens une question "intéressante" à ce sujet, enfin surtout la réponse), il y a tous les jours un nouveau format de container, un nouveau format de tag, un nouveau tag "important tu comprends"… Ca ne sera qu'un autre de plus si jamais le format "prend" (sachant que 99% des nouveaux formats restent avec moins de 10 utilisateurs car finalement l'importance du besoin est assez… restreinte à des besoins assez uniques)
[^] # Re: Not Invented Here
Posté par nahoj (site web personnel) . Évalué à 7.
D'où la phrase finale du journal, « Rendez-vous sans conditions »…
Je n'y connais pas grand chose en audio/vidéo et j'ai codé un truc pour faire ce que je voulais sans devoir devenir expert. J'ai bien sûr cherché si quelque chose de semblable existait, mais sans savoir quoi chercher…
Je trouve les alternatives que tu mentionnes intéressantes et j'en prends note. Pas besoin de tant d'amertume…
[^] # BeOS le faisait il y a 15 ans!
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 2.
Sous BeOS et Haiku, ce genre d'infos sont stockées dans des xattrs au niveau du système de fichiers. ça évite de "pourrir" le fichier lui-même avec des tags bizarres.
# mplayer/mpv te proposent cela de base
Posté par Vroum . Évalué à 3.
Pour information avec les lecteurs de la famille mplayer, tu as la possibilité d'avoir un fichier de configuration dédié.
Exemple: un fichier
video.avi.confdans le répertoire par défaut-use-filedir-confte permet de définir des options spécifiques.https://mpv.io/manual/master/#file-specific-configuration-files
[^] # Re: mplayer/mpv te proposent cela de base
Posté par nahoj (site web personnel) . Évalué à 2.
Effectivement c'est vraiment le même principe. Dommage que la syntaxe soit liée à celle de la ligne de commande, et que donc elle ne soit pas la même d'un lecteur à l'autre ("fullscreen=yes", donnée en exemple pour mpv, n'est pas reconnue par mplayer qui ne comprend que "fs=yes").
J'ai aussi une préférence, pour ce qui est du stockage de l'information, pour les tags du fichier lui-même plutôt qu'un fichier séparé ou un mécanisme fourni par le système (bureau sémantique ou autre), pour avoir l'idée qu'on modifie le fichier et que si on le transfère ensuite sur un autre support, on le transfère avec la modification.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.