Journal hachoir-metadata cherche des testeurs

Posté par  (site web personnel) .
Étiquettes :
0
29
nov.
2006
Le programme hachoir-metadata se prépare à passer en version 1.0. Pour cela, il a besoin d'être testé sur beaucoup de fichiers pour détecter un maximum de bugs. Utilisez cette archive clé-en-main (rien à installer mise à part Python 2.4) :
http://www.haypocalc.com/tmp/hachoir-metadata-svn1335.tar.bz(...)

Décompressez l'archive, entrez dans le répertoire créer, et utilisez le script hachoir-metadata que vous y trouverez. Vous pouvez les traiter plusieurs fichiers en même temps.

Spécifications :

* Formats supportés : archive (bz2, gz, tar, zip), audio (au, cda, mp1, mp2, mp3, ogg, wav, wma), image (bmp, gif, ico, jpg, pcx, png, tiff, xcf), vidéo (asf, avi, flv, mkv, mov, .mp4, wmf)
* Supporte les fichiers corrompus / tronqués
* Gère très bien Unicode (charset ISO-8859-XX, UTF-8, UTF-16), convertit les chaînes dans le charset de votre terminal
* Supprime les doublons (et si une chaîne est une partie d'une autre, conserve la chaîne la plus longue)
* Assigne une priorité aux informations qu'on peut alors filtrer avec l'option --level
* Dépend uniquement de hachoir-parser (et non pas de libmatroska, libmpeg2, libvorbis, etc.) et tourne sur tous les OS et toutes les architectures

Comparez les résultats avec d'autres outils :
(du plus généraliste au plus particulier)

* http://freevo.sourceforge.net/cgi-bin/freevo-2.0/Kaa (Kaa-metadata, qui contient le programme mminfo)
* https://gnunet.org/libextractor/ (paquet 'extract' sous Debian, le programme porte le même nom)
* http://mediainfo.sourceforge.net/fr (récement porté sous Linux)
* http://badcomputer.org/unix/code/wmainfo/
* ogginfo (programme et paquet Debian du même nom)
* mkvinfo (programme et paquet Debian du même nom)
* (liste non exhaustive, je ne les connais pas tous !)

Erreurs qui n'en sont pas :

L'erreur « Unable to parse file: (...) » indique qu'Hachoir n'a pas de parseur pour le format du fichier. L'erreur « Hachoir can't extract metadata, but is able to parse (...) » indique que je n'ai pas jugé intéressant d'écrire un extracteur de méta-donnée pour ce type de fichier :-) (mais que c'est possible si quelqu'un est motivé pour le faire car le format est reconnu). Certains parseurs peuvent également générer des avertissements (EXIF, ID3, Ogg/Vorbis) qui sont plus ou moins utiles, --quiet permet de les ignorer.

Plus d'informations :

http://hachoir.org/wiki/hachoir-metadata

  • # Faut bien quelqun pour la faire ... non ? bon ok ...

    Posté par  . Évalué à 6.

    * Gère très bien Unicode (charset ISO-8859-XX, UTF-8, UTF-16), convertit les chaînes dans le charset de votre terminal

    Veillez a ne pas laisser traîner votre hachoir sur irc, plus particulièrement sur #linuxfr, l'auteur n'est en rien responsable des conséquences de ceci.

    => []

  • # bug?

    Posté par  . Évalué à 3.

    Sur un jpeg j'ai ce message qui est répété 8 fois (en variant légèrement):
    [warn] Warning: padding /exif/content/ifd[0]/entry[0]/padding content don't look normal (invalid pattern at byte 0)!

    mais à la fin c'est bon j'ai les info sur mon fichier.

    • [^] # Re: bug?

      Posté par  . Évalué à 4.

      chez moi cela fonctionne bien pour les fichiers jpg, par contre les fichiers .blend sont interprétés ainsi :

      [warn] MPEG audio: Unable to find synchronization bits
      [warn] [Autofix] Fix parser error in /frames: stop parser, add padding
      Metadata:
      - Duration: 13.64 sec
      - Channel: Stereo
      - Sample rate: 22.1 KHz
      - Bits/sample: 16 bits
      - Bit rate: 40.0 Kbit/sec
      - Format version: MPEG version 2 layer II
      - MIME type: audio/mpeg
      - Endian: Big endian

      en comparaison la commande "file" me donne :
      Blender3D, saved as 32-bits big endian with version 2.35

      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

      cela contient du texte, des données (pour une machine virtuelle), des images, du son..

      Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

      • [^] # Re: bug?

        Posté par  . Évalué à 2.

        Argh, le retour de la vengeance du parseur mpeg gourmand.

        • [^] # Re: bug?

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

          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

          • [^] # Re: bug?

            Posté par  . Évalué à 1.

            pourqoi ne pas demander d'abord à libmagic et ensuite choisir le parseur approprié ?

            Si j'ai bien compris le but de hachoir, tu ne souhaites pas supporter plus de formats que le fait "file", mais avoir beaucoup plus de détails sur certains formats.

            autant utiliser ce qui existe pour la première étape : détection du type de fichier.

            • [^] # Re: libmagic

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

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

        • [^] # Re: bug?

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

          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

      • [^] # Re: bug?

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

        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

        • [^] # Re: bug?

          Posté par  . Évalué à 2.

          le format semble très bien documenté ( http://www.eblong.com/zarf/glulx/glulx-spec.html ), si je peux je pourrais essayer de l'implémenter alors, je vais regarder comment sont faits les autres parseurs.

          Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

    • [^] # Re: bug?

      Posté par  . Évalué à 2.

      Je crains que ceci ne soit pas un bug, mais une feature.
      D'ailleurs on peut ne pas voir cette information en sélectionnant un niveau d'information adéquat avec --level.
      Peut-être le level par défaut devrait-il être de 1 ?

      Pour ma part j'ai deux remarques :
      *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 ?
      *Ceci est-il un bug ?

      $~/hachoir-metadata/hachoir-metadata 1.jpg --level 1
      [warn] Warning: padding /psd/content/res_info/reserved content don't look normal (invalid pattern at byte 0)!
      [warn] [Autofix] Delete /psd/content/res_info (too large)
      (
      n
      o

      m
      e
      t
      a
      d
      a
      t
      a
      ,

      p
      r
      i
      o
      r
      i
      t
      y

      m
      a
      y

      b
      e

      t
      o
      o

      s
      m
      a
      l
      l
      )

      • [^] # Re: bug?

        Posté par  . Évalué à 4.

        Rectification : on peut ne pas voir cette information en étant mal réveillé.

      • [^] # Re: bug?

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

        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

    • [^] # Re: bug?

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

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

    • [^] # Re: bug?

      Posté par  . Évalué à 4.

      Moi j'ai un bug : "padding content don't look normal" devrait s'écrire "padding content doesn't look normal".

      Quoi, c'est pas ça qui t'intéresse ? :)

      • [^] # Re: bug?

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

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

        Haypo

        • [^] # Re: bug?

          Posté par  . Évalué à 1.

          Je n'ai pas bien compris les conclusions de mon psuedo bug.
          Je précise que l'extention de mon jpeg est bien ".jpg"

          Sinon j'ai essayé la proposition de modifier le level. Mais le niveau 1 ne me met que ces 8 messages d'erreur. À partir du niveau 3 je commence à avoir quelques info, et ce n'est qu'avec le niveau 9 que j'ai la totalité des informations.

          Ça ne m'arrive qu'avec ce fichier en particulier. Si tu veux je peux te le mettre à disposition.

  • # Qualité de compression d'un JPEG

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

    Ca serait pas mal d'avoir l'information du taux de compression en % d'un JPEG, en plus du nombre de bits/pixel et des dimensions.
    Je ne sais pas si c'est facilement accessible, mais les traiteurs d'images te remercieraient grandement pour cette feature très utile.

    • [^] # Re: Qualité de compression d'un JPEG

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

      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

      • [^] # Re: Qualité de compression d'un JPEG

        Posté par  (site web personnel) . Évalué à 1.

        En fait, quand je parlais du taux de compression, je parlais plutôt du paramètre
        de "qualité" qui indique grosso-modo le nombre de coefficients DCT qui sont gardés lors du codage des blocs de l'image. Ce paramètre doit apparaitre quelque part dans l'en-tête du fichier JPEG, à mon avis au même titre que les dimensions ou le nombre de bits par pixels. Mais c'est peut-être plus compliqué que ça à récupérer...

        • [^] # Re: Qualité de compression d'un JPEG

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

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

  • # c'est grave ca ?

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

    [warn] Error, unknow ZIP header (0xCFCCCE2A).
    [warn] [Autofix] Fix parser error in /: stop parser, add padding
    Common:
    - MIME type: application/zip
    - Endian: Little endian
    File "META-INF/MANIFEST.MF":
    - File name: META-INF/MANIFEST.MF
    - File size: 0 bytes
    - Creation date: 2006-11-29 16:24:22
    - Compression: Deflate

    C'est un fichier ear, donc un zip en fait. D'où vient le "unknow (sic) ZIP header" ?

  • # Nouveau snapshot

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

    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

  • # Bug?

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

    Bonjour haypo

    j'ai testé hachoir sur divers fichiers qui me passaient sous la main, et j'ai repéré quelques "bugs" (si tu veux les fichiers en question, tu n'as qu'à demander):

    Sur un jpeg, le "manufacturer" donné par hachoir est différent de celui d'exif, et quelques info manquent:

    $ ./hachoir-metadata --level=9 --verbose ~/doc/photos/Tom_Rhodamine6G/02045649.jpg
    [warn] Warning: padding /exif/content/ifd[1]/entry[11]/padding content don't look normal (invalid pattern at byte 0)!
    [warn] [Autofix] Delete /exif/content/ifd[1]/entry[15]/tag (too large)
    [warn] [Autofix] Delete /exif/content/ifd[1]/entry[15] (too large)
    Metadata:
    - Image width: 800
    - Image height: 600
    - Bits/pixel: 24
    - Pixel format: YCbCr
    - Creation date: 00:01:02 04:54:49
    - Camera model: -L1-2M H
    - Camera manufacturer: konDS
    - Compression: JPEG
    - Producer: 0.0701.3720.05090520
    - MIME type: image/jpeg
    - Endian: Big endian

    $ exif ~/doc/photos/Tom_Rhodamine6G/02045649.jpg
    (...)
    Constructeur |Nikon
    Logiciel |310.0701.3720.050905
    Temps d'exposition |1/2 sec.
    ExposureProgram |Programme normal
    Version d'exif |Unknown Exif Version
    FlashPixVersion |Unknown FlashPix Version
    Espace des couleurs |sRGB
    PixelXDimension |800
    PixelYDimension |600
    (...)


    Un truc bizarre (mais très facile à corriger je suppose): sur une autre image, l'extension était .JPG, et hachoir a essayé plusieurs parseurs avant de choisir EXIF, alors qu'avec la même image avec l'extension .jpg, il prend le bon parseur tout de suite.

    Sur les images TIFF, tiffinfo me donne plus d'info que hachoir:

    $ ./hachoir-metadata --level=9 --verbose ~/PhD/data/image_intensifier/20oct2006/1st\ test/k00001.tif
    Metadata:
    - Image width: 496
    - Image width: 480
    - MIME type: image/tiff
    - Endian: Little endian

    $ tiffinfo ~/PhD/data/image_intensifier/20oct2006/1st\ test/k00001.tif
    TIFF Directory at offset 0x8 (8)
    Subfile Type: reduced-resolution image (1 = 0x1)
    Image Width: 496 Image Length: 480
    Resolution: 0.330667, 0.32 pixels/inch
    Bits/Sample: 8
    Compression Scheme: None
    Photometric Interpretation: min-is-black
    Samples/Pixel: 1
    Rows/Strip: 480
    Planar Configuration: single image plane


    une autre:

    $ ./hachoir-metadata --level=9 --verbose ~/doc/PhD/EBCCD\ Datas/7.tif
    Metadata:
    - Image width: 512
    - MIME type: image/tiff
    - Endian: Little endian

    $ tiffinfo ~/doc/PhD/EBCCD\ Datas/7.tif
    TIFF Directory at offset 0x8 (8)
    Subfile Type: (0 = 0x0)
    Image Width: 512 Image Length: 512
    Resolution: 1, 1 (unitless)
    Bits/Sample: 16
    Compression Scheme: None
    Photometric Interpretation: min-is-black
    FillOrder: msb-to-lsb
    Orientation: row 0 top, col 0 lhs
    Samples/Pixel: 1
    Rows/Strip: 10
    Planar Configuration: single image plane
    ImageDescription: [Application],Date="04-07-2003",Time="14:04:05",Software="HiPic",Application=1,ApplicationTitle="High Performance Image Control System",SoftwareVersion="6.4.0 pf2",SoftwareDate="31.01.2003"
    [Camera],SSP=S,SAG=S,SMD=N,SHA=F,SVO=0,SVW=1018,SVB=2,SHB=2,SPX=2,SOP=I,AET=20ms,ASH=A,AMD=I,ATP=N,ATN=1,ACN=1,CSW=O,PSW=O,SHC=F,TST=-25,CEG=0,CEO=0,CEC=F,IGC=O,IIG=12,Temperature=-25.1,CVG=235,CVO=187,CameraName="C7190-10",Type=1,SubType=18
    [Acquisition],NrExposure=1,NrTrigger=0,ExposureTime=20ms,AcqMode=2,DataType=3,DataTypeOfSingleImage=3,ShadingCorr=0,CurveCorr=0,areSource="0,0,512,512",areGRBScan="0,0,512,512",pntOrigCh="0,0",pntOrigFB="0,0",pntBinning="1,1",BytesPerPixel=2,BacksubCorr=0
    [Grabber],ConfigFile="C:\Program Files\Hipic\HiPic640\PCDig.txt",Type=3,SubType=1,ComPort=1
    [DisplayLUT],EntrySize=3,LowerValue=1442,UpperValue=4096,BitRange="12 bit",Color=3,LUTType=0,Gamma=1,First812OvlCol=1,Lut16xShift=0,Lut16xOvlVal=32767
    [Scaling],ScalingXType=1,ScalingXScale=1,ScalingXUnit="No unit",ScalingXScalingFile="No scaling",ScalingYType=1,ScalingYScale=1,ScalingYUnit="No unit",ScalingYScalingFile="No scaling"[Comment],UserComment=""
    Software: HiPic 6.4.0 pf2
    DateTime: 2003:04:07 14:04:58
    Artist: Copyright Hamamatsu GmbH, 2002


    Voilivoilou, j'espère que ça peut t'aider! Encore bravo et merci pour Hachoir.

    • [^] # Re: Bug?

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

      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

  • # Un problème sur le Wav ...

    Posté par  . Évalué à 2.

    A vu de nez une division par zéro sur un fichier "non standard"

    cf ta boite à courriel

    Traceback (most recent call last):
    File "./hachoir-metadata", line 163, in ?
    main()
    File "./hachoir-metadata", line 156, in main
    ok = processFiles(values, filenames)
    File "./hachoir-metadata", line 114, in processFiles
    ok &= processFile(values, filename, display_filename, priority, human, display)
    File "./hachoir-metadata", line 76, in processFile
    metadata = extractMetadata(parser)
    File "./hachoir_metadata/metadata.py", line 319, in extractMetadata
    metadata.extract(parser)
    File "./hachoir_metadata/riff.py", line 54, in extract
    wav.extract(riff)
    File "./hachoir_metadata/riff.py", line 26, in extract
    self.bit_rate = (wav["audio_data"].size * 1000) / self.duration[0]
    ZeroDivisionError: long division or modulo by zero

  • # mkv multi audio

    Posté par  . Évalué à 1.

    J'ai fait quelques tests sur des fichiers matroska.
    J'ai observé un problème pour les fichiers contenant plus d'une piste audio.
    Voilà ce que le programme me renvoie.

    [err!] Key 'audio' already exists
    [err!] Hachoir can't extract metadata, but is able to parse.

    Et pour les vidéos, il serait intéressant d'obtenir le bitrate.

    • [^] # Re: mkv multi audio

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

      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.

      • [^] # Re: mkv multi audio

        Posté par  . Évalué à 1.

        Pour le bitrate, cela ne doit pas être compliqué en théorie.

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

        Hachoir fournie déjà la durée, la taille doit pouvoir être extraite du ls (avec les multiplications ou divisions qui vont bien).


        Sinon j'ai continué de tester des fichiers vidéos.

        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:
        - Duration: 23 min 49 sec
        - Copyright: monazoroQYOrk004ti
        - Comment: Has audio/video index (1.0 MB)
        - Comment: ‰f‘œFDivX640 Q3 PV3cap D-CX
        - MIME type: video/x-msvideo
        - Endian: Little endian


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

        Metadata:
        - Duration: 23 min 6 sec
        - Creation date: 2006-10-02 05:30:43
        - Last modification: 2006-10-02 05:30:43
        - Comment: Play speed: 100.0%
        - Comment: User volume: 100.0%
        - MIME type: video/quicktime
        - Endian: Big endian

        • [^] # Re: mkv multi audio

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

          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

  • # sous titres dans un mkv?

    Posté par  . Évalué à 2.

    Bonjour , j'ai testé hachoir avec plusieurs mv qui ont des sous titres (un ou plusieurs) et hachoir en détecte aucun (mplayer les lis sans problèmes)
    pv moi si tu veux les fichiers que j'ai utilisé ou plus d'info ;)

    Sinon pour les exifs, on a pas toutes les données que l'on peut avoir avec exiftool , (et largement moins qu'avec exiftool dans les fichiers CR2 (raw de canon)) (comme la focale utilisée, l'ouverture, la vitesse, si le flash est mis ou pas etc...)

    Sinon pas vraiment de bugs trouvé.
    beau boulot ;)

    • [^] # Re: sous titres dans un mkv?

      Posté par  . Évalué à 2.

      Rahhh
      A la place de mv faut lire mkv !!!
      Je savais qu'il fallait pas surfer quand son dd nous lache on fait des conneries (comment ca il est toujours pas changé ?)

    • [^] # Re: sous titres dans un mkv?

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

      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 :-(

Suivre le flux des commentaires

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