Ok, j'ai fini par corriger le bug. Le parseur veut au moins 5 frames valides, n'autorise plus le padding entre chaque frame, et reconnait quand même les fichiers MPEG audio contenant moins de 5 frames (ex: un chunk dans une vidéo AVI/FLV).
Hum, intéressant :-) Pour le premier fichier (02045649.jpg), c'est vraiment un bug du parseur. Les messages "[Autofix] Delete (...) (too large)" indique que le parseur ne comprend plus rien et s'arrête avant de planter complètement.
Pour le format TIFF, je n'ai que peu de fichiers de test donc il est possible qu'il y ait encore des points à améliorer. Et tiens, je ne connaissait pas tiffinfo :-)
Merci de m'envoyer tes fichiers pour que je puisse corriger les bugs.
Derniers changements :
* calcule la "qualité" des images JPEG
* supporteID3v1.1b (avant il ne supportait qu'ID3 v1.1)
* supprime les avertissements sur le padding dans le parseur EXIF
* corrige une faute de grammaire (content don't => content doesn't) :-)
* utilise stat() pour lire la taille des fichiers et attrape les erreurs sur la lecture de la taille du fichier
Après quelques recherches, j'ai remarqué qu'ImageMagick arrive à donner la qualité du JPEG :
identify -verbose image.jpg|grep Quality
J'ai corrigé mon parseur de table de quantification ("dqt") qui ne semble plus bogué maintenant. J'ai repris l'algorithme en C et les tables utilisées pour le calcul et voilà que j'arrive au même résultat.
Je suis un peu bluffé que ça marche (qu'on arrive à retrouver le taux de compression au pourcent près) :-) Par contre, l'algorithme pour déterminer la qualité en pourcent est loin d'être trivial ! Fonction computeQuality() : http://hachoir.org/browser/hachoir-metadata/trunk/hachoir_me(...)
La première version d'Hachoir utilisait libmagic mais malheureusement son binding Python n'est packagé que pour Debian, beaucoup de formats lui sont inconnus (système de fichier, données du jeu Worms2, et bien d'autres), et le mode --mime pour récupérer le type MIME n'est pas trop fiable.
Petit à petit j'ai recodé libmagic pour les types non reconnus. Sur sur une suggestion de Julien, les parseurs ont gagné une méthode validate() qui permet de vérifier la validité d'un format, et un dictionnaire "tags" qui contient des informations pour aider le choix du parseur (extension du nom du fichier, taille minimale, types MIME). Dans la grande majorité des cas, le fichier porte la bonne extension, et donc le choix du bon parseur est immédiat. Une petite optimisation serait d'ajouter la signature du fichier (les N premiers octets : "BMP", "PK", "BZ2", "PNG", etc.).
Hum, je ne sais pas si le parseur JPEG d'Hachoir est assez costaux pour ça. Le taux de compression peut se calculer en prenant la taille du champ "data" et en multipliant la largeur par la hauteur. Enfin, j'sais pas si on parle de la même chose :-)
Dans le champ "sof" (start of frame 0), je vois precision=8, height=695, height=901, nb_components=3. On a donc le nombre de "dimensions" et la précision des couleurs. C'est bien ça dont tu parles ?
Utilise hachoir-urwid pour entrer plus en profondeur dans un fichier JPEG. Je peux te faire un tarball si tu veux.
Le parseur ZIP est incomplet et certains entêtes ne sont pas reconnus. Or avec le format ZIP, si on est incapable de lire un entête, on ne peut pas lire la suite. Est-ce que tu peux m'envoyer ce fichier ?
Sinon je sais que c'est très spécifique, mais est-ce que cela ne serait pas intéressant que hachoir puisse extraire les données de ce format : http://en.wikipedia.org/wiki/Glulx
Quand à ce format, bien sûr que Hachoir pourrait le lire, mais il faut le lui apprendre. J'ai reçu quand même pas mal de parseurs, ce qui me laisse penser qu'il est relativement simple d'en écrire un. Base toi sur un parseur existant ou mieux sur le parseur "template.py" (modèle) dans hachoir_parser/. L'API du noyau est ici : http://hachoir.org/wiki/hachoir-core/API
Quelques explications : Hachoir utilise l'extension du fichier pour choisir le parseur adéquoi. Si ça ne donne rien (le parseur dit qu'il ne veut pas d'un fichier), il va essayer tous les autres parseurs l'un après l'autre. Mais malheureusement comme le préciser ptifeth, le parseur MPEG audio a tendance à s'accaper tous les fichiers car selon lui tout est audio... Il faut que je le rende un peu plus strict.
pourquoi le niveau est-il étalé de 1 à 9 ? Un niveau 0 n'affichant que des warnings ou les erreurs éventuelles ne serait-il pas pertinent ?
Il existe déjà l'option --quiet pour cacher les avertissements.
Ceci est-il un bug ?
Bien que je trouve ça joli d'écrire une chaîne à la verticale, j'ai quand même décidé d'écrire la chaîne à l'horizontale pour le bien être de notre cou. J'ai corrigé le bug avant la version 1335. C'est peut-être que tu as une autre version d'hachoir-metadata d'installée qq. part.
Tiens, ça me fait bien rire ça, « À la communauté de prendre le relais ».
Dès qu'un logiciel est jugé trop vieux, inintéressant du point de vue économique, ou encore qu'une boîte coule, le logiciel passe sous licence libre. Ca me laisse perplexe. Pourquoi ne pas l'avoir fait quand le logiciel était compétitif, jeune et désinvolte ? Et non, il faut attendre qu'il soit vieux, usé et fatigué.
Bon, soyons positif, de telles initiatives ont déjà donné naissance aux programmes Mozilla (Firefox et Thunderbird), Blender (enfin, pour celui-là, il a quand même fallu payer 100.000$...) et d'autres.
L'équipe Hachoir est constituée de 2 personnes :-) Je suis seul à bosser sur les parseurs et les méta-données. Pour me contacter : http://www.haypocalc.com/wiki/Victor_Stinner
(je t'ai même envoyé un email)
Faut pas se voir en concurrents, y'a moyen qu'on bosse ensemble. MediaInfo a des formats que Hachoir ne sait pas encore parser (ou mal) : Real Audio/Video, MPEG-4, trucs Apple, etc.
L'idéal serait que tu puisses utilise Hachoir comme extracteur :-)
D'ailleurs, j'aimerai bien définir un format générique pour écrire des parseurs de fichier, mais ceci me semble très complexe car il faudrait permettre un export en C, Python, Hachoir, et autres. Bon, c'est juste une idée.
http://freshmeat.net/projects/libgsf/ « libgsf aims to provide an efficient extensible i/o abstraction for dealing with different structured file formats » (en particulier, le format Microsoft Office)
http://wvware.sourceforge.net/libwmf.html : « libwmf is a library for reading vector images in Microsøft's native Windøws Metafile Format (WMF) and for either (a) displaying (...) or (b) converting them (...) »
libgsf est utilisé (au moins) par AbiWord, Gnumeric, et KWord. libwmf est utilisé par gimp et AbiWord (selon apt-cache rdepends).
Ce genre d'initiave est excellente car elle évite le travail redondant.
L'idéal étant de stocker les emails sur ton PC allumé 24h/24 et connecté à Internet en POP3/POPS, puis d'y accéder en IMAP. Ceci éviter d'avoir des messages lus marqués comme non lus sur l'autre machine (entre autres). J'ai fait ça sur mon serveur car ça faisait 5 ans que j'utilisais juste du POP et que j'en avais marre.
J'ai commencé un article sur mon blog qui explique la mise en place de getmail et de courier-imap-ssl, mais je ne l'ai pas encore fini.
Dès qu'il y a des clés privées à récupérer, les gens se mettent à inventer des techniques toujours plus tordues. Pour la Xbox, un mec a sniffé les communications sur port PCI...
(Oups, j'avais pas fini) De plus je trouve ça nul que LinuxFR reprenne le texte du journal Le Monde en utilisant les même phrases chocs "un véritable bouleversement dans le milieu de la cryptographie", "Intel ait choisi la politique de l'autruche", " Dans une note confidentielle (...)". Beaucoup de mystères autour de cette annonce. Moins on en dit, plus ça semble affreux :-)
[^] # Re: Un problème sur le Wav ...
Posté par Victor STINNER (site web personnel) . En réponse au journal hachoir-metadata cherche des testeurs. Évalué à 2.
Haypo
[^] # Re: bug?
Posté par Victor STINNER (site web personnel) . En réponse au journal hachoir-metadata cherche des testeurs. Évalué à 4.
Haypo
[^] # Re: Nouveau snapshot
Posté par Victor STINNER (site web personnel) . En réponse au journal hachoir-metadata cherche des testeurs. Évalué à 2.
http://hachoir.org/changeset/1349
Mais quand on l'écrit tout seul, "unknow", faut-il également deux N ?
# Pom pom podem
Posté par Victor STINNER (site web personnel) . En réponse au journal Idée de lutte contre les spams. Évalué à 2.
euh... c'est quoi ce copier/coller foireux du vendredi ? ah non :
http://wiki.apache.org/spamassassin/FuzzyOcrPlugin
voilà
Haypo
[^] # Re: Bug?
Posté par Victor STINNER (site web personnel) . En réponse au journal hachoir-metadata cherche des testeurs. Évalué à 3.
Pour le format TIFF, je n'ai que peu de fichiers de test donc il est possible qu'il y ait encore des points à améliorer. Et tiens, je ne connaissait pas tiffinfo :-)
Merci de m'envoyer tes fichiers pour que je puisse corriger les bugs.
Victor
[^] # Re: Nouveau snapshot
Posté par Victor STINNER (site web personnel) . En réponse au journal hachoir-metadata cherche des testeurs. Évalué à 3.
[^] # Re: bug?
Posté par Victor STINNER (site web personnel) . En réponse au journal hachoir-metadata cherche des testeurs. Évalué à 2.
Haypo
# Nouveau snapshot
Posté par Victor STINNER (site web personnel) . En réponse au journal hachoir-metadata cherche des testeurs. Évalué à 2.
Derniers changements :
* calcule la "qualité" des images JPEG
* supporteID3v1.1b (avant il ne supportait qu'ID3 v1.1)
* supprime les avertissements sur le padding dans le parseur EXIF
* corrige une faute de grammaire (content don't => content doesn't) :-)
* utilise stat() pour lire la taille des fichiers et attrape les erreurs sur la lecture de la taille du fichier
[^] # Re: Qualité de compression d'un JPEG
Posté par Victor STINNER (site web personnel) . En réponse au journal hachoir-metadata cherche des testeurs. Évalué à 4.
J'ai corrigé mon parseur de table de quantification ("dqt") qui ne semble plus bogué maintenant. J'ai repris l'algorithme en C et les tables utilisées pour le calcul et voilà que j'arrive au même résultat.
Je suis un peu bluffé que ça marche (qu'on arrive à retrouver le taux de compression au pourcent près) :-) Par contre, l'algorithme pour déterminer la qualité en pourcent est loin d'être trivial ! Fonction computeQuality() :
http://hachoir.org/browser/hachoir-metadata/trunk/hachoir_me(...)
[^] # Re: libmagic
Posté par Victor STINNER (site web personnel) . En réponse au journal hachoir-metadata cherche des testeurs. Évalué à 3.
Petit à petit j'ai recodé libmagic pour les types non reconnus. Sur sur une suggestion de Julien, les parseurs ont gagné une méthode validate() qui permet de vérifier la validité d'un format, et un dictionnaire "tags" qui contient des informations pour aider le choix du parseur (extension du nom du fichier, taille minimale, types MIME). Dans la grande majorité des cas, le fichier porte la bonne extension, et donc le choix du bon parseur est immédiat. Une petite optimisation serait d'ajouter la signature du fichier (les N premiers octets : "BMP", "PK", "BZ2", "PNG", etc.).
[^] # Re: Qualité de compression d'un JPEG
Posté par Victor STINNER (site web personnel) . En réponse au journal hachoir-metadata cherche des testeurs. Évalué à 2.
Dans le champ "sof" (start of frame 0), je vois precision=8, height=695, height=901, nb_components=3. On a donc le nombre de "dimensions" et la précision des couleurs. C'est bien ça dont tu parles ?
Utilise hachoir-urwid pour entrer plus en profondeur dans un fichier JPEG. Je peux te faire un tarball si tu veux.
Haypo
[^] # Re: c'est grave ca ?
Posté par Victor STINNER (site web personnel) . En réponse au journal hachoir-metadata cherche des testeurs. Évalué à 2.
Mon email & co : http://www.haypocalc.com/wiki/Victor_Stinner
Haypo
[^] # Re: bug?
Posté par Victor STINNER (site web personnel) . En réponse au journal hachoir-metadata cherche des testeurs. Évalué à 5.
Quand à ce format, bien sûr que Hachoir pourrait le lire, mais il faut le lui apprendre. J'ai reçu quand même pas mal de parseurs, ce qui me laisse penser qu'il est relativement simple d'en écrire un. Base toi sur un parseur existant ou mieux sur le parseur "template.py" (modèle) dans hachoir_parser/. L'API du noyau est ici :
http://hachoir.org/wiki/hachoir-core/API
Et la même mais plus complète et plus à jour :
http://hachoir.org/browser/hachoir-core/trunk/doc/hachoir-ap(...)
Il faut que je documente l'écriture d'un parseur. Si tu as les spécifications, c'est "facile" d'écrire un parseur.
Haypo
[^] # Re: bug?
Posté par Victor STINNER (site web personnel) . En réponse au journal hachoir-metadata cherche des testeurs. Évalué à 4.
Haypo
[^] # Re: bug?
Posté par Victor STINNER (site web personnel) . En réponse au journal hachoir-metadata cherche des testeurs. Évalué à 4.
Il existe déjà l'option --quiet pour cacher les avertissements.
Ceci est-il un bug ?
Bien que je trouve ça joli d'écrire une chaîne à la verticale, j'ai quand même décidé d'écrire la chaîne à l'horizontale pour le bien être de notre cou. J'ai corrigé le bug avant la version 1335. C'est peut-être que tu as une autre version d'hachoir-metadata d'installée qq. part.
Haypo
[^] # Re: bug?
Posté par Victor STINNER (site web personnel) . En réponse au journal hachoir-metadata cherche des testeurs. Évalué à 3.
# À la communauté de prendre le relais
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Hula devient un projet communautaire. Évalué à 10.
Dès qu'un logiciel est jugé trop vieux, inintéressant du point de vue économique, ou encore qu'une boîte coule, le logiciel passe sous licence libre. Ca me laisse perplexe. Pourquoi ne pas l'avoir fait quand le logiciel était compétitif, jeune et désinvolte ? Et non, il faut attendre qu'il soit vieux, usé et fatigué.
Bon, soyons positif, de telles initiatives ont déjà donné naissance aux programmes Mozilla (Firefox et Thunderbird), Blender (enfin, pour celui-là, il a quand même fallu payer 100.000$...) et d'autres.
Haypo
# Le baladeur Zune de Microsoft accepte le format de Microsoft mais pas ce
Posté par Victor STINNER (site web personnel) . En réponse au journal Loony Zune. Évalué à 1.
http://formats-ouverts.org/blog/2006/11/15/1006-le-baladeur-(...)
(la même info est donnée dans le Sun-Times)
Haypo
[^] # Re: hachoir
Posté par Victor STINNER (site web personnel) . En réponse au journal MediaInfo 0.7.4.0 sous Linux. Évalué à 4.
http://www.haypocalc.com/wiki/Victor_Stinner
(je t'ai même envoyé un email)
Faut pas se voir en concurrents, y'a moyen qu'on bosse ensemble. MediaInfo a des formats que Hachoir ne sait pas encore parser (ou mal) : Real Audio/Video, MPEG-4, trucs Apple, etc.
L'idéal serait que tu puisses utilise Hachoir comme extracteur :-)
D'ailleurs, j'aimerai bien définir un format générique pour écrire des parseurs de fichier, mais ceci me semble très complexe car il faudrait permettre un export en C, Python, Hachoir, et autres. Bon, c'est juste une idée.
Haypo
# Compilation sous Linux
Posté par Victor STINNER (site web personnel) . En réponse au journal MediaInfo 0.7.4.0 sous Linux. Évalué à 6.
http://downloads.sourceforge.net/mediainfo/MediaInfo_0.7.4.0(...)
http://downloads.sourceforge.net/mediainfo/MediaInfoLib_0.7.(...)
/!\ ATTENTION : L'archive ne crée pas de sous-dossier /!\
Le genre de saloperie qui me pourri mon $HOME >:-( À corriger rapidement donc.
Le binaire Linux ne fonctionne pas chez moi : il a besoin de la glibc 2.4 et j'ai la 2.3.6 (Ubuntu Dapper).
Je vous tiens au courant pour la compilation...
Haypo
# Quelques bibliothèques
Posté par Victor STINNER (site web personnel) . En réponse au journal Adoption de l'ODF. Évalué à 4.
http://wvware.sourceforge.net/libwmf.html : « libwmf is a library for reading vector images in Microsøft's native Windøws Metafile Format (WMF) and for either (a) displaying (...) or (b) converting them (...) »
libgsf est utilisé (au moins) par AbiWord, Gnumeric, et KWord. libwmf est utilisé par gimp et AbiWord (selon apt-cache rdepends).
Ce genre d'initiave est excellente car elle évite le travail redondant.
Haypo
# IMAP \o/
Posté par Victor STINNER (site web personnel) . En réponse au message Synchroniser mes mails entre deux machines. Évalué à 7.
J'ai commencé un article sur mon blog qui explique la mise en place de getmail et de courier-imap-ssl, mais je ne l'ai pas encore fini.
Victor
# Troll attitude : à quand prog.saimal.fr ?
Posté par Victor STINNER (site web personnel) . En réponse au journal [PUB] les filles, saimal ! dites le en Web 2.0. Évalué à 1.
(Visual)Basic c'est 15x mal
.NET c'est (trop beaucoup) mal
Perl c'est 7429x mal
etc.
Haypo
[^] # Re: Pas si révoluionnaire
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Une faille majeure de la cryptographie courante. Évalué à 8.
http://www.wisdom.weizmann.ac.il/~tromer/acoustic/ par Adi Shamir et Eran Tromer (Adi est le A de RSA ;-))
http://citeseer.ist.psu.edu/kocher99differential.html de Paul Kocher, Joshua Jaffe, Benjamin Jun
Dès qu'il y a des clés privées à récupérer, les gens se mettent à inventer des techniques toujours plus tordues. Pour la Xbox, un mec a sniffé les communications sur port PCI...
Haypo
[^] # Re: Pas si révoluionnaire
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Une faille majeure de la cryptographie courante. Évalué à 10.
Haypo