Hello,

sous ce nom barbare se cache un modeste et petit mécanisme pour nettoyer les noms des fichiers. Il faut savoir qu’avec des conteneurs audio et vidéo de bonne qualité, le titre du média est généralement stocké dans une méta-donnée “title”. En général ce titre est propre et peut être utilisé tel quel pour une recherche d’information sur internet. Dans notre contexte, il est utilisé en général par les “grabbers” pour rechercher les données, paroles des chansons, descriptions, liste des acteurs, etc, … Malheureusement, on traine encore des boulets au niveau conteneur multimédia.

Un petit bond en arrière

Je me rappel encore très bien, à l’époque de Windows 3.1 / 3.11 d’avoir installé le composant optionnel “Video for Windows”. Celui-ci rendait possible la lecture de petites vidéos dans des conteneurs AVI (entre autres). J’avais les yeux qui brillaient quand je voyais ces mini-films défiler. Pourtant aujourd’hui on se plaint quand une vidéo n’est même pas en 720p. D’un autre côté quand on voit le lecteur Flash qui bouffe toute la puissance CPU avec des vidéos de mauvaise qualité, y a de quoi se poser des questions par rapport à ce qui se faisait déjà il y a 15 ans en arrière. Voyez par exemple la vidéo suivante :

Cliquez dessus pour la lire! (si vous le pouvez :-P)

C’est un petit film qui date des alentours de 1997 (peut être même 1996), et qui est enregistré au format FLI. C’est un format d’animation d’image dans la même idée que le GIF. Ce petit film est cadencé à 14 images/sec avec une définition d’image de 320×200 px. Il peut y avoir également de la compression avec ce format, mais ce n’est pas aussi sophistiqué que du MPEG. Là où je veux en venir, c’est que cette vidéo est lisible de manière fluide sur un Smaky 130, qui correspond à un processeur Motorola 68030 (fixé à 25 MHz pour cet ordinateur). C’est d’un Smaky que j’ai récupéré ce film à l’aide d’un outil que je m’étais amusé à faire http://home.gna.org/fosfat/ (cf. http://fosfat.schroetersa.ch). La grande partie des logiciels Smaky sont écrits en CALM (en calme aussi), qui est une sorte de langage d’abstraction sur les assembleurs (une notation assembleur indépendante du fabricant). Il y a donc de forte chance que le Smaky utilise un logiciel écrit non pas en C/Pascal, mais en CALM pour arriver à lire cette animation. Ainsi le Flash me donne vraiment mal au ventre quand je le vois suer avec un Athlon X2 64.

Decrapifier

Bref, pour en revenir au “decrapifier”, j’ai abordé les fichiers AVI. Ce conteneur développé à l’origine par Microsoft a aujourd’hui des défauts, et malheureusement on le retrouve encore bien trop souvent (on ne peut pas en vouloir à l’AVI, il est vieux). Quoiqu’il en soit, il n’y a pas de méta-donnée “title” la dedans.

Le “decrapifier” va alors se charger d’éliminer tous les caractères peu propice à aider à effectuer des recherches via les “grabbers”. A noter également que lorsqu’un titre est nettoyé, c’est aussi une bonne chose pour l’utilisateur. Le principe est très simple et efficace dans la plupart des cas. Pour l’illustrer, prenons un nom de fichier inutilisable pour une recherche (et bien trop courant).

"{XvID-LOL}.Elephant.-.Dreams.s02e10_(DVDRip)_Etach.avi"

Etape 1

Le nom est nettoyé de tous ses caractères dont le code ASCII est inclus dans les 7 premiers bits (128 premiers caractères). L’ASCII 7 bits à l’avantage d’être présent dans (presque) tous les codages de caractères dont l’unicode. L’idée est de simplement remplacer chacun de ces caractères par un espace, en prenant soins de supprimer l’extension du fichier (sauf exception pour l’apostrophe, les espaces et les caractères alpha-numériques qui sont conservés).

"XvID LOL Elephant Dreams s02e10 DVDRip Etach"

Etape 2

Une liste noir de mots clefs va permettre d’éliminer tout ce qui ne nous intéresse pas pour la recherche. Les valeurs par défaut avec Enna (fichier ~/.enna/enna.cfg) sont :

0tv, 1080p, 2hd, 720p, ac3, booya, caph, crimson, ctu, dimension, divx, dot,
dsr, dvdrip, dvdscr, e7, etach, fov, fqm, hdq, hdtv, lol, mainevent, notv, pdtv,
proper, pushercrew, repack, reseed, screencam, screener, sys, vtv, x264, xor,
xvid, SExEP, sSEeEP

Cette liste est donc éditable à souhait. Il y a deux mots clefs particulier (en fin de liste) que je vais expliquer dans un deuxième temps. Tous les autres mots clefs sont écrits en minuscules car le système n’est pas sensible aux majuscules en temps normal. On peut donc voir le résultat sous la forme suivante :

" Elephant Dreams s02e10 "

Etape 3

Mais le résultat précédent, bien que beaucoup plus intéressant, ne correspond pas à la réalité. Le mot clef "sSEeEP" présent dans la liste va permettre de gérer le s02e10. L’idée est de récupérer également des informations utiles comme la saison et le numéro d’épisode. Le vrai résultat est donc :

" Elephant Dreams "

Add new metadata “season”, value: “2”
Add new metadata “episode”, value: “10”

Etape 4

La dernière étape est de supprimer tous les espaces blancs superflus. Pour finalement avoir une chaîne de caractère sous cette forme :

"Elephant Dreams"

Les motifs

Deux motifs ont été présentés brièvement. En réalité il y en a trois.

• NUM (indique un nombre non signé et entier)
• SE (indique un nombre non signé et entier qui représente une saison)
• EP (indique un nombre non signé et entier qui représente un épisode)

Il y a quelques règles à prendre en compte lorsqu’on les utilise. Tout d’abord, ce type de mot clef est sensible aux majuscules. Par exemple, SSEEEP n’est pas égale à sSEeEP. Ensuite NUM, ne retournant aucune valeur, il peut être utilisé plusieurs fois dans un même mot clef.

Prenons l’exemple d’Elephant Dreams. Si le mot clef était sNUMeNUM, le résultat final serait exactement le même qu’au point 4. Néanmoins, aucune nouvelle méta-donnée seraient insérées. Cela peut donc être utile dans certains cas de figure où on trouverait des numéros inutiles. Il ne faut pas non plus abuser de ce genre de mots clefs. En voulant supprimer tous les numéros, on risquerait de ne plus avoir de titre (je pense au film “2012” par exemple).

Concernant SE et EP, ils ne doivent être utilisés qu’une seule fois par mot clef. Mais il y a qu’en même quelques libertés comme par exemple les mots clefs suivants sont parfaitement possibles: SeasonSE, EpisodeEP. Il n’est donc pas obligatoire d’avoir toujours SE et EP dans le même mot clef. Une autre considération concerne le nombre de saisons et d’épisodes pour un seul et même fichier. Imaginons un autre exemple complètement absurde :

"Mes Vacances (02x100) -s55e10-"

Si les mots clefs SExEP et sSEeEP sont présents dans la liste noir, le résultat final est donc bien:

"Mes Vacances"

Mais en plus il y a 4 nouvelles méta-données :

Add new metadata “season”, value: “2”
Add new metadata “episode”, value: “100”
Add new metadata “season”, value: “55”
Add new metadata “episode”, value: “10”

Pour terminer

Je ne tiens pas à donner des explications techniques sur le fonctionnement. Le gros du travail se fait via la magie de sscanf(). Le choix de NUM, SE et EP n’est pas non plus arbitraire. C’est uniquement par souci de commodité. En interne, le NUM est remplacé par %*u, les SE et EP sont remplacés par %u. Cela évite de devoir jouer l’accordéon avec les chaînes de caractères. Pour des détails, lisez le MAN de sscanf.

A bientôt,
Mathieu SCHROETER