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.
# Bug sur Debian SID
Posté par ʭ ☯ . Évalué à 4.
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 Victor STINNER (site web personnel) . Évalué à 6.
[^] # Re: Bug sur Debian SID
Posté par madko (site web personnel) . Évalué à 5.
[^] # Re: Bug sur Debian SID
Posté par smorico . Évalué à 2.
[^] # Re: Bug sur Debian SID
Posté par Nicolas Legrand (site web personnel) . Évalué à 4.
[^] # Re: Bug sur Debian SID
Posté par Anonyme . Évalué à 0.
[^] # Re: Bug sur Debian SID
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
Genre "synaptic install foo" ?
[^] # Re: Bug sur Debian SID
Posté par Anonyme . Évalué à 0.
[^] # Re: Bug sur Debian SID
Posté par Nicolas Legrand (site web personnel) . Évalué à 6.
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 gvallee . Évalué à 2.
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.
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 Matthieu Moy (site web personnel) . Évalué à 2.
$ 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 Victor STINNER (site web personnel) . Évalué à 6.
# Ca avance
Posté par lerouxrv . Évalué à 7.
Ca fait plaisir de voir cette petite appli qui avance. Courage, et félicitations à l'équipe !
# Documents bureautique
Posté par Alex. . Évalué à 2.
Alex.
[^] # Re: Documents bureautique
Posté par Victor STINNER (site web personnel) . Évalué à 4.
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 genma (site web personnel) . Évalué à 2.
[^] # Re: Documents bureautique
Posté par yoho (site web personnel) . Évalué à 3.
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 Victor STINNER (site web personnel) . Évalué à 4.
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 Alex. . Évalué à 2.
[^] # Re: Documents bureautique
Posté par Laurent A. . Évalué à 2.
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 Victor STINNER (site web personnel) . Évalué à 3.
* 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 feth . Évalué à 3.
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 yoho (site web personnel) . Évalué à 2.
(sinon, ça ferait performancité, c'est pas beau...)
# .
Posté par 태 (site web personnel) . Évalué à 2.
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 Victor STINNER (site web personnel) . Évalué à 2.
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
[^] # Re: (soucis setuptools)
Posté par Alex G. . Évalué à 1.
Mais aussi demander sur la mailing list si par hasard il n'y a pas déjà une manière de faire prévue.
Franchement setuptools est tout de même un super truc.
[^] # Re: (soucis setuptools)
Posté par Victor STINNER (site web personnel) . Évalué à 2.
=> http://mail.python.org/pipermail/distutils-sig/2006-November(...)
=> http://mail.python.org/pipermail/distutils-sig/2006-November(...)
Le mieux serait, effectivement, de faire en sorte que setuptools arrive à retrouver la version des modules Python installés par Debian, Ubuntu, Mandriva, Gentoo, etc.
[^] # Re: (soucis setuptools)
Posté par syntaxerror . Évalué à 1.
Tsss... si c'est bien empaqueté, ya pas de raison que ça ne fonctionne pas.
As tu eu l'occasion d'essayer les paquets hachoir pour Debian (etch/sid) de ce repositoire ?
http://plumbear.free.fr/debian etch main
L'egg-info y est empaqueté et setuptools devrait retrouver ses poussins.
# une solution pour des archives corrompues ?
Posté par Tony Flow . Évalué à 1.
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 Victor STINNER (site web personnel) . Évalué à 2.
- 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 Victor STINNER (site web personnel) . Évalué à 2.
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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.