Faites parler vos fichiers avec hachoir-metadata

Posté par  (site Web personnel) . Modéré par Thomas Petazzoni.
Étiquettes :
0
19
déc.
2006
Audiovisuel
Tous les jours, nous manipulons des dizaines de fichiers binaires sans vraiment se soucier de leur format ou de connaître toutes les informations qu'ils contiennent. Pourtant, ils sont souvent accompagnés de métadonnées qui renseignent sur leur origine et leur contenu : auteur, nom du logiciel, date de création, durée, taille, codec, genre, etc. Ces informations permettent une classification fine et des recherches multicritères très fines.

Hachoir-metadata, programme basé sur la bibliothèque Hachoir, permet de lire ces informations et les présente de manière synthétique. Tous les formats courants sont reconnus : image (JPEG, PNG, GIF, ICO...), vidéo (AVI, WMV, FLV, MKV...), audio (MP3, wav, Ogg, WMA...), archive (zip, gzip, bzip2, tar...).

Les informations sont triées par pertinence (ex les dimensions d'une image sont plus importantes que la méthode de compression). Pour les formats contenant plusieurs « documents », chaque document possède sa propre section (ex : les flux audio, vidéo et les informations générales sont séparés). Contrairement à certains outils où la présentation est calquée sur le format de fichier, hachoir-metadata classe des informations de manière générique (ex : le champ 'duration' est partagée pour une vidéo ou un son).

Hachoir-metadata n'est sûrement pas une révolution, il existe déjà une multitude de bibliothèques pour extraire les métadonnées. Mais, pour les formats supportés, il donne d'aussi bons résultats que ses concurrents voire parfois meilleurs. Au passage, essayez également le programme hachoir-urwid pour explorer vos fichiers en profondeur et découvrir d'autres informations passées sous silence. Formats supportés
  • Archive : bzip2, gzip, TAR, zip
  • Audio : CDDA, MPEG audio, Ogg Vorbis, Sun/NeXT audio, wav, WMA
  • Image : bmp, cur, GIF, ico, JPEG, pcx, PNG, TIFF, WCF (The Gimp)
  • Métadonnées : AMF (utilisé dans les vidéos FLV), EXIF (image JPEG), ID3 (MPEG audio), IPTC (image JPEG)
  • Vidéo : AVI, ASF, FLV, Ogg Theora, Matroska, MPEG video, MOV (Quicktime), WMV

Installation

Pour l'installation, le plus simple est d'utiliser la commande sudo easy_install hachoir-metadata (idem pour hachoir-urwid) qui télécharge tout ce qui faut.

Si vous n'avez pas cette commande (easy_install) : installez le paquet python-setuptools avec votre outil de gestion de paquets. En dernier recours, utilisez la commande sudo python ez_setup.py hachoir-metadata avec le fichier http://peak.telecommunity.com/dist/ez_setup.py.

Bien sûr, de vrais paquets Debian, Gentoo, etc. seraient appréciés.

Rapport de bogue

Si vous trouvez un bogue, envoyez-moi le message d'erreur complet et le fichier posant problème par courriel (victor.stinner chez haypocalc.com). Si le fichier pèse plus d'1 Mo, n'envoyez que le début (dd if=fichier of=fichier1Mo bs=1024 count=1024).

Idées

Il serait intéressant d'écrire des greffons pour les logiciels Konqueror, Nautilus, etc. permettant de lire les métadonnées par un simple survol sur un fichier.

hachoir-strip

La bibliothèque Hachoir supportant l'édition depuis peu, un programme à l'opposé d'hachoir-metadata a été développé : hachoir-strip. Il supprime les métadonnées pour ne conserver que les données les plus importantes. Il ne travaille pas directement sur le fichier spécifié en entrée, il sauvegarde le résultat dans un nouveau fichier.

Aller plus loin

  • # Bug sur Debian SID

    Posté par  (site Web personnel) . Évalué à 4.

    Traceback (most recent call last):
    File "/usr/bin/hachoir-metadata", line 11, in ?
    import hachoir
    ImportError: No module named hachoir

    ... et puis un jour, les systèmes GNU/linux seront simples à utiliser ;-)

    ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

    • [^] # Re: Bug sur Debian SID

      Posté par  (site Web personnel) . Évalué à 6.

      Ceci ressemble à une ancienne installation d'Hachoir (car le module "hachoir" a été renommé "hachoir-core"). Essaye "sudo easy_install -U hachoir-metadata" (U comme Upgrade). Au pire, suppression sauvage de l'ancienne version (rm -rf /usr/bin/hachoir* /usr/lib/python2.4/site-package/hachoir*) puis réinstallation.
    • [^] # Re: Bug sur Debian SID

      Posté par  (site Web personnel) . Évalué à 5.

      et puis un jour les utilisateurs liront la notice
    • [^] # Re: Bug sur Debian SID

      Posté par  . Évalué à 2.

      apt-get install python-hachoir
      • [^] # Re: Bug sur Debian SID

        Posté par  (site Web personnel) . Évalué à 4.

        Je suis toujours étonné de voir le nombre de gens qui utilisent encore apt-get alors que aptitude est merveilleux :-).
        • [^] # Re: Bug sur Debian SID

          Posté par  . Évalué à 0.

          Je suis toujours étonné de voir le nombre de gens qui utilisent encore aptitude alors que synaptic est merveilleux.
          • [^] # Re: Bug sur Debian SID

            Posté par  (site Web personnel) . Évalué à 2.

            Synaptic, ça marche en ligne de commande ?

            Genre "synaptic install foo" ?
            • [^] # Re: Bug sur Debian SID

              Posté par  . Évalué à 0.

              pas du tout non
            • [^] # Re: Bug sur Debian SID

              Posté par  (site Web personnel) . Évalué à 6.

              Oui en gros c'est ça... Je vais pas m'amuser à installer X sur mes serveurs pour lancer Synaptic.

              Après si synaptic fait quelques choses de mieux (à part l'interface graphique) qu'aptitude pourquoi pas l'utiliser ? Le truc c'est que aptitude faisait des choses en plus par rapport à apt-get ou dselect (pour la version ncurse de aptitude) pour ce qui est de la gestion des paquets cassés ou inutilisés, donc c'était intéressant pour moi d'apprendre à utiliser un autre outil. J'ai pas eu l'impression que Synaptic fasse un truc en plus et je cherche à utiliser de préférence un outil qui fonctionnera en mode texte.

              Donc voilà, je préfère faire tape tape que clique clique. Il faut de tout pour faire un monde. C'est ce qui est d'ailleurs mis en avant dans les publicités de United Colors of Bubuntu.
          • [^] # Re: Bug sur Debian SID

            Posté par  . Évalué à 2.

            Synaptic, c'est pas mal pour une machine de bureau avec notamment le classement des paquets pas theme. Ca rend la gestion des paquets simple a travers une interface graphique (pour ceux qui aiment).

            Pour les machines distantes/serveurs, en particulier a travers ssh, c'est pas trop ca et puis "apt-get install synaptic" -> "Après dépaquetage, 11.6Mo d'espace disque supplémentaires seront utilisés."

            aptitude quant a lui passe tres bien a travers ssh (mode texte), l'ergonomie est au final assez proche de synaptic mais en mode texte.

            Alors oui je suis d'accord que Synaptic est bien fait mais c'est loin de pouvoir "remplacer" apt ou aptitude a mon avis, a part peut-etre pour les gens qui ne gere que leur machine sans avoir a se soucier d'administration a distance.

            Mon commentaire peu inutile du matin. :-)
            • [^] # Re: Bug sur Debian SID

              Posté par  (site Web personnel) . Évalué à 3.

              % sudo apt-get install aptitude
              After unpacking 8819kB of additional disk space will be used.

              l'espace disque est un faux problème...
              Quant à moi, je n'ai jamais réussi à utiliser aptitude, apt-get me va très bien en général. Si je veux faire des trucs plus sioux sans trop passer par apt-cache et dpkg, j'utilise dselect quand je suis à distance ou synaptic quand j'ai la machine devant moi.

              Oui, je sais qu'aptitude sait désinstaller un truc et toutes les dépendances qu'il libère...
              • [^] # Re: Bug sur Debian SID

                Posté par  (site Web personnel) . Évalué à 2.

                Bah, pour passer d'apt-get à aptitude, il faut principalement changer le nom de la commande :

                $ aptitude install foo
                $ aptitude search bar
                $ aptitude remove foobar
                ...

                Mais tu peux aussi avoir une interface ncurses en faisant juste

                $ aptitude
      • [^] # Re: Bug sur Debian SID

        Posté par  (site Web personnel) . Évalué à 6.

        "et puis un jour les commentateurs liront le texte de la dépêche", il n'y a pas de paquet d'hachoir-* version 0.7. Mais libre à toi, smorico, d'en préparer ;-)
  • # Ca avance

    Posté par  . Évalué à 7.

    Bjr,

    Ca fait plaisir de voir cette petite appli qui avance. Courage, et félicitations à l'équipe !
  • # Documents bureautique

    Posté par  . Évalué à 2.

    Est ce qu'on peut imaginer hachoir-metadata récupérer les méta-données d'un document OpenOffice, PDF, MS Word ... ?

    Alex.
    • [^] # Re: Documents bureautique

      Posté par  (site Web personnel) . Évalué à 4.

      Pour les documents Office, c'est essentiellement le format OLE2, et ce format est le plus complexe de tous les formats qui existent sur Terre. Un parseur a été entamé mais c'est pas encore ça. Aujourd'hui la meilleure bibliothèque pour lire ces informations est libgsf. Plus d'info par ici :
      http://hachoir.org/wiki/MicrosoftOffice

      Pour OpenOffice, rien n'a été fait pour l'instant, bien qu'un parseur ZIP existe et que Python a tout le nécessaire pour manipuler du XML.

      Pour PDF, un parseur existait il y a bien longtemps, mais depuis il n'a pas été récupéré.
      • [^] # Re: Documents bureautique

        Posté par  (site Web personnel) . Évalué à 2.

        Je m'étais posé la question de la récupération du texte depuis les documents openoffice (.sxw et .odt), j'avais trouvé des scripts que j'ai mis (en citant les sources) sur mon blog. Le lien : http://genma.free.fr/article.php3?id_article=302 En espérant que ça aide...
        • [^] # Re: Documents bureautique

          Posté par  (site Web personnel) . Évalué à 3.

          Mais en allant plus loin, est-ce que hachoir ne pourrait pas être la base des moteurs d'indexation ? Je ne sais pas comment sont architecturés beagle, strigi, ex-kat, etc... mais il me semble qu'ils pourraient utiliser hachoir, rendant ainsi l'écriture de plugins pour de nouveaux formats plus aisée. Actuellement, si on veut supporter un nouveau format de fichier pour ces moteurs, je suppose qu'il faut se coltiner la création d'une librairie ou alors en reprendre une existante, mais se coltiner l'interface entre la librairie et le moteur.

          Avec hachoir, ce serait plus facile, je trouve. Même si les types de fichier les plus importants sont supportés actuellement, il en reste encore des milliers qui pourraient être indexés...
          • [^] # Re: Documents bureautique

            Posté par  (site Web personnel) . Évalué à 4.

            Mais en allant plus loin, est-ce que hachoir ne pourrait pas être la base des moteurs d'indexation ?
            Ca peut se faire. hachoir-grep est un outil bourrin pour lister toutes les chaînes de caractère d'un fichier binaire. Il sort des chaînes en Unicode propre (si le charset est bien spécifié dans le parseur).

            Sinon, hachoir-metadata vise les moteurs d'indexation / de recherche, mais en fait je n'ai jamais zieuté du côté de Beagle & co.

            Je ne sais pas si Hachoir est assez rapide pour ces outils. Après il faut choisir vitesse ou qualité des infos :-p
            • [^] # Re: Documents bureautique

              Posté par  . Évalué à 2.

              Moi je vois en hachoir-metadata une brique très intéressante pour une GED en python :-)
          • [^] # Re: Documents bureautique

            Posté par  . Évalué à 2.

            Tracker utilise un démon nommé trackerd qui appelle tracker-extract pour sortir des metadata de documents. Les deux programmes sont écrits en C.
            Le problème avec hachoir est le python... Le programme tracker-extract est lancé sur chaque fichier à traiter, puis il termine (s'il tourne encore au bout d'un certain laps de temps, il est tué). Sur des vidéos ou des fichiers sonores par exemple, GStreamer met déjà un certain temps à se lancer. Il me semble qu'un programme en Python serait encore plus coûteux à ce moment là parce qu'il apporterait un surcoût. D'autre part, j'ai aussi peur de la conso mémoire et de la rapidité de l'ensemble. Le but de Tracker est aussi d'utiliser le moins de RAM possible et de rester discret (le programme est très poli (nice 19) et demande à passer en dernier sur les opérations d'IO lorsque l'ordonanceur CFQ est utilisé). Tracker a aussi était proposé à l'inclusion dans GNOME 2.18, si cela était accepté, il serait considéré comme une pièce de bas niveau, à la hauteur de gnomevfs.

            Autre chose : Hachoir évite l'utilisation de bibliothèques externes, si j'ai bien compris. Dans ce cas, cela déplace le moment où tracker en utilisera une. En effet, il faut de temps à autre extraire les données contenus dans des documents : Poppler pour les PDF, libGSF pour les fichiers OLE2, etc.

            Enfin, si je ne me trompe en disant que Hachoir évite l'utilisation de bibliothèques extérieures, cela signifie que les développeurs de ce programme sont amenés à manipuler un très grand nombre de formats hétéroclites. En pratique, non seulement ces fichiers sont très différents, mais peuvent en plus être buggés vis à vis des spécifications (lorsqu'elles sont connues...) normalement attendues. J'ai donc très peu confiance en la capacité d'une petite équipe à arriver à autant d'expertise que plusieurs groupes qui se focalisent sur différents formats de fichiers...
            • [^] # Re: Documents bureautique

              Posté par  (site Web personnel) . Évalué à 3.

              Python est à la fois une désavantage et un avantage :
              * il est plus lent qu'un programme en C et utilise plus de mémoire (des statistiques sur l'extraction de méta-données m'intéresseraient)
              * mais il n'a pas les erreurs du langage C (buffer overflow, pointeur explosif & co) et est plus robuste avec sa gestion des exceptions

              Hachoir résiste bien aux fichiers corrompus et tronqués. Je voulais sortir un exemple concret pour le prouver, mais là je me suis souvenu qu'hachoir-metadata est encore très sensible : il n'aime pas les fichiers tronqués :) Il plante lamentablement lorsqu'un champ est absent. Il faudrait que je trouve une solution élégante et générique pour corriger ça.
            • [^] # Re: Documents bureautique

              Posté par  (site Web personnel) . Évalué à 3.

              J'ai donc très peu confiance en la capacité d'une petite équipe à arriver à autant d'expertise que plusieurs groupes qui se focalisent sur différents formats de fichiers...


              Et Victor créa l'infrastructure pour que l'humanité s'en saisisse et que les gourous insufflent leur connaissance des formats exotiques dans un parseur.

              Tout comme le langage Python permet la manipulation directe d'abstractions plus évoluées que le C, la suite hachoir vise à nous permettre de considérer les conteneurs et les contenus de façon plus générique que ce qui a jamais été imaginé auparavant, et j'ai assez confiance qu'elle y parviendra.
              • [^] # Re: Documents bureautique

                Posté par  (site Web personnel) . Évalué à 2.

                Oui, mais il est vrai que pour résumer ce qui a été dit avant : généricité ne rime pas avec performance, malheureusement.

                (sinon, ça ferait performancité, c'est pas beau...)
  • # .

    Posté par  (site Web personnel) . Évalué à 2.

    Je devrais peut-être créer un ticket sur le trac de hachoir ou sur celui de python-setuptools à moins que ce ne soit un bug de python. Voilà mon problème :
    je trouve le mécanisme d'installation de easy_install vraiment désagréable : je n'ai aucune envie de le laisser écrire n'importe où surtout en tant que root. Donc je me fais une installation dans un répertoire personnel. Il se trouve que j'avais déjà py-setuptools installé (une dépendance d'un autre truc), mais aussi py-urwid.
    easy_install hachoir-urwid marche presque bien, mais je ne comprends pas pourquoi il installe une autre version de urwid. Bon, je laisse faire, hachoir-urwid marche.
    Comme je suis con, j'enlève le fichier urwid-machin.egg qu'il m'a mis (a-t-il installé autre chose ?). Et évidemment, ça ne marche plus. hachoir ne veut pas trouver la version d'urwid que j'ai, même en faisant un PYTHONPATH qui me semblait bon.

    Donc. Est-il possible d'installer hachoir ailleurs que dans /usr/lib/.../site-packages/ sans installer les dépendances en doublon ?
    • [^] # Re: (soucis setuptools)

      Posté par  (site Web personnel) . Évalué à 2.

      Petit à petit, je déteste setuptools que je trouvais magnifique. À ce que j'ai compris du problème : (aucune distribution linux) n'inclut les informations "egg info". Setuptools n'arrive pas à déterminer les versions des modules Python installés. Alors plutôt que de deviner, il fait son bourrin et installe une deuxième version du module Python.

      J'hésite entre :
      * Supporter setuptools et ses nombreuses qualités : pouvoir installer tout un module dans un seul oeuf (fichier ".egg"), pouvoir installer plusieurs versions d'un module au même endroits et choisir la version au chargement, pouvoir installer un programme dans son dossier perso sans toucher au PYTHONPATH, ...
      * Ne plus utiliser setuptools qui réinstalle tout et de travers en plus
  • # une solution pour des archives corrompues ?

    Posté par  . Évalué à 1.

    Récemment j'ai recherché un outils me permettant de récupérer les données d'un fichier zip corrompu. Je n'espère pas retrouver la totalité de l'archive, mais je me dis que sur un zip qui fait plus d'1Go, ya au moins moyen de récupérer quelques fichiers...

    Et à mon grand désarroi, je n'ai rien trouvé ! J'ai en lointain souvenir une commande du genre pkzipfix par exemple... En fait tout ce que google m'a apporté était des solutions proprio commerciales, parfois en shareware, sous windows. D'où ma frustration !

    Je n'avais pas pensé au Hachoir (que je n'ai pas encore eu l'occasion d'essayer), mais un rapprochement vient de ce faire dans ma petite tête : Est-ce une utilisation possible de ce couteau suisse ?

    Merci de m'éclairer sur ce point qui me semble interessant, surtout si aucun autre outils n'existe sous linux pour faire cela. Sinon si vous en connaissez, profitez-en pour les signaler ;)
    • [^] # Re: une solution pour des archives corrompues ?

      Posté par  (site Web personnel) . Évalué à 2.

      Hachoir est une bibliothèque bas niveau pour manipuler des fichiers, ce n'est pas un programme dédié à la récupération des données tel que TestDisk. Je pense par contre qu'il peut être un très bon point de départ pour :
      - reconnaître le format d'un fichier de format inconnu
      - trouver le début d'un fichier dans une image disque
      - recupérer une partie d'un fichier tronqué / partiellement corrumpu

      Mais je n'ai pas du tout fait d'essai dans ce sens. N'ayant jamais été victime de disque dur fou ou de clé USB malade, je n'ai pas eu l'occasion de mettre en action l'Hachoir sur ce sujet.

      Pour le format ZIP, il manque un petit patch pour pouvoir décompresser un fichier dans une archive ZIP. Avec cette fonctionnalité, il serait possible d'extraire un fichier donné d'une archive ZIP. Il faut juste trouver la bonne bilbliothèque Python pour le faire étant donné qu'Hachoir supporte depuis peu la décompression à la demande (on peut entrer dans une archive .gz puis dans une archive .tar puis dans une image .jpeg puis dans les données EXIF, et là trouver le code d'accès à l'immeuble ^^).
  • # Paquets Debian

    Posté par  (site Web personnel) . Évalué à 2.

    On peut trouver tout le bazar en vrac dans:
    http://plumbear.free.fr/hachoir/

    et le repository bien rangé dans l'arborescence sous:
    http://plumbear.free.fr/debian/

    Merci à Michel Casabona (aka plumbear).

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n’en sommes pas responsables.