Victor STINNER a écrit 1639 commentaires

Ce qui est assez fort avec cvs2svn, c'est qu'il arrive à recréer des commit atomiques svn. À ce que j'ai entendu, il utilise les dates de commit "tiens celui là est assez proche de l'autre là, on va dire que c'est le même commit" :-)

Non, en fait le charset est Shift JIS, on appelle donc ça Shift JIS Art :-)

Mais pas celui que tu cherches :

http://fr.wikipedia.org/wiki/ASCII_Art
http://mahonet.info/~kozou/english.html (ASCII Art japonais, avec leur charset, je trouve ça très joli)

Ah oui voilà :
http://en.wikipedia.org/wiki/Shift_JIS_art

Haypo

http://linuxfr.org/2004/02/24/15522.html

(ah bon, c'est hors sujet ?)

Taille du fichier en kbit / Durée en seconde.

Hum, et si tu as un flux vidéo et un flux audio (voir 2, 3, 4 flux audios) ? Hum, ta formule est trop simpliste. Et si ne tiens pas compte des entêtes de chaque page Ogg. De plus, Hachoir ne sait pas lire la durée d'un .ogg :-) (j'ai ouvert un ticket pour ça)

J'ai rencontré un warn (fichier .avi, Xvid, MP3) :

[warn] Unable to convert string /info/comment/text to Unicode: 'ascii' codec can 't decode byte 0x89 in position 0: ordinal not in range(128)
Common:
(...)
- Comment: ‰f‘½FDivX640 Q3 PV3cap D-CX

Ouais, il semble pas très catholique ton commentaire. Tu peux m'envoyer la vidéo si elle est pas trop grosse (5 Mo max) ? Si elle est trop grosse, tronque là (dd if=fichier.avi of=fichier_tronque.avi bs=1024 count=1024) et regarde si tu as encore le bug. Si oui, envoie moi ce fichier tronqué. Si non, euh... Contacte moi :)

Et il doit y avoir un problème avec le parseur du .mp4 qui me renvoie :

Metadata:
- Duration: 23 min 6 sec
(...)
C'est tout ce qu'il sait lire pour l'instant. Si t'es chaud pour améliorer le parseur MPEG-4, n'hésite pas :-) Si ta question concernait "MIME type: video/quicktime", sache que le format Quicktime est le format MPEG-4 (ou l'inverse, je sais pas).

Victor

J'ai modifié l'extracteur pour qu'il prenne en compte les sous-titres. Exemple :

Subtitle:
- Title: Piste de présentation
- Compression: S_TEXT/UTF8
Subtitle:
- Language: French
- Compression: S_VOBSUB
Subtitle:
- Language: English
- Compression: S_VOBSUB

J'ai ajouté la norme ISO 639-2 à Hachoir pour donne le nom complet de la langue (fre => French).

Je sais pas s'il te faut d'autres info. Si oui, dit moi où les trouver :-)
--
Pour EXIF, il faudrait recoder le parseur pour qu'il bug moins, et réorganiser l'extracteur de méta-données pour qu'il sépare les infos sur la photo et sur l'appareil photo (faut pas tout mélanger).

Pour le format "Canon", ben envoie moi les spec' ou code le parseur. J'y peux rien moi si chaque constructeur invente son format maison :-(

J'ai corrigé l'extracteur Matroska pour accepter plusieurs canaux audios, mais aussi plusieux canaux vidéos (c'est tellement le bordel Matroska, on sait jamais).

Pour le bitrate, j'ai aucune idée de comment l'obtenir.

J'ai corrigé cette division mais également toutes les autres que j'ai trouvé :-)

Haypo

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).

Haypo

Oups, j'avais zappé ça, trop subtile pour moi. Voici un commit qui en corrige "deux/trois" :
http://hachoir.org/changeset/1349

Mais quand on l'écrit tout seul, "unknow", faut-il également deux N ?

http://lesrobinsdesbois3.free.fr/sketches/sophie/sophie_self(...)
euh... c'est quoi ce copier/coller foireux du vendredi ? ah non :
http://wiki.apache.org/spamassassin/FuzzyOcrPlugin
voilà

Haypo

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.

Victor

Oups : http://www.haypocalc.com/tmp/hachoir-svn1345.tar.bz2

Merci, c'est corrigé :-) Et si si, ça m'intéresse aussi.

Haypo

http://www.haypocalc.com/tmp/hachoir-svn1345.zip

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.

Haypo

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 ?

Mon email & co : http://www.haypocalc.com/wiki/Victor_Stinner

Haypo

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

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

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.

Haypo

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.

Haypo

Le parseur EXIF est foireux, je dois le réécrire. Mais bon, comme tu l'as écrit, il fonctionne quand même. C'est juste qu'il aime bien râler :-)

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.

Haypo

À lire sur le blog Formats Ouverts :
http://formats-ouverts.org/blog/2006/11/15/1006-le-baladeur-(...)
(la même info est donnée dans le Sun-Times)

Haypo