samedi 15 novembre
Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Derniers journaux de haypo :

Journal : hachoir-metadata cherche des testeurs

Posté par Victor STINNER (page perso, ) le 29 novembre 2006
0
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

> Lire le journal (41 commentaires, moyenne: 2,6).  

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

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

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

Posté par Oscar Blumberg () le 29/11/2006 à 22:21. (lien). É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 wistiti68 () le 30/11/2006 à 01:33. (lien). É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 Farvardin (page perso, ) le 30/11/2006 à 07:26. (lien). É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..

    --
    Et si vous essayiez un *BSD pour quelques temps ?

    • [^]Re: bug?

      Posté par ptifeth (page perso, ) le 30/11/2006 à 07:38. (lien). Évalué à 2.

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

      • [^]Re: bug?

        Posté par Victor STINNER (page perso, ) le 30/11/2006 à 09:18. (lien). É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 sn00py () le 30/11/2006 à 10:48. (lien). É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 Victor STINNER (page perso, ) le 30/11/2006 à 11:59. (lien). É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 Victor STINNER (page perso, ) le 01/12/2006 à 14:08. (lien). É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 ptifeth (page perso, ) le 30/11/2006 à 07:28. (lien). É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 ptifeth (page perso, ) le 30/11/2006 à 07:39. (lien). Évalué à 4.

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

    • [^]Re: bug?

      Posté par Victor STINNER (page perso, ) le 30/11/2006 à 09:15. (lien). É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 Victor STINNER (page perso, ) le 30/11/2006 à 09:09. (lien). É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 JoeBar () le 30/11/2006 à 16:36. (lien). É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 Victor STINNER (page perso, ) le 30/11/2006 à 16:51. (lien). Évalué à 2.

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

      Haypo

      • [^]Re: bug?

        Posté par wistiti68 () le 30/11/2006 à 21:08. (lien). É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 David Tschumperlé (page perso, ) le 30/11/2006 à 08:19. (lien). É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 Victor STINNER (page perso, ) le 30/11/2006 à 09:31. (lien). É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 David Tschumperlé (page perso, ) le 30/11/2006 à 09:47. (lien). É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 Victor STINNER (page perso, ) le 30/11/2006 à 13:18. (lien). É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 cho7 (page perso, ) le 30/11/2006 à 09:12. (lien). É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" ?

--
le python, c'est bon

  • [^]Re: c'est grave ca ?

    Posté par Victor STINNER (page perso, ) le 30/11/2006 à 09:25. (lien). Évalué à 2.

    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

Nouveau snapshot

Posté par Victor STINNER (page perso, ) le 30/11/2006 à 16:50. (lien). É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

  • [^]Re: Nouveau snapshot

    Posté par cho7 (page perso, ) le 01/12/2006 à 12:15. (lien). Évalué à 2.

    * corrige une faute de grammaire (content don't => content doesn't) :-)

    Oui j'en avais discrètement signalé une également dans mon 1er post mais tu ne l'as pas relevé : mettre unknown ZIP header au lieu de unknow ZIP header

    Voilou

    --
    le python, c'est bon

    • [^]Re: Nouveau snapshot

      Posté par Victor STINNER (page perso, ) le 01/12/2006 à 13:21. (lien). Évalué à 2.

      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 ?

      • [^]Re: Nouveau snapshot

        Posté par Thomas Douillard () le 01/12/2006 à 13:28. (lien). Évalué à 2.

        http://dictionary.reference.com/browse/unknow

        Si c'est un verbe (oublier / ne pas connaitre) , ou un nom (un inconnu) il faut pas le n à la fin. Si c'est un adjectif ( inconnu toujours ), si.

        • [^]Re: Nouveau snapshot

          Posté par Thomas Douillard () le 01/12/2006 à 13:34. (lien). Évalué à 2.

          http://dictionary.reference.com/browse/unknown

          Rectification: si c'est un adjectif, unknow marche on dirait, pas si c'est un nom. Unknown marche si adejectif ou nom. Unknow à l'air d'être plus "brittish".

Bug?

Posté par Khâpin (Jabber id, page perso, ) le 30/11/2006 à 19:26. (lien). É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 Victor STINNER (page perso, ) le 01/12/2006 à 08:53. (lien). É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 Loic Jaquemet (page perso, ) le 01/12/2006 à 21:17. (lien). É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

  • [^]Re: Un problème sur le Wav ...

    Posté par Victor STINNER (page perso, ) le 03/12/2006 à 15:48. (lien). Évalué à 2.

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

    Haypo

mkv multi audio

Posté par hokata () le 02/12/2006 à 23:06. (lien). É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 Victor STINNER (page perso, ) le 04/12/2006 à 10:18. (lien). É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 hokata () le 04/12/2006 à 11:41. (lien). É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 Victor STINNER (page perso, ) le 04/12/2006 à 14:16. (lien). É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 briaeros007 () le 03/12/2006 à 13:18. (lien). É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 ;)

--
Subete ga wakatta toki…watashi ga anta wo korosu.

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

    Posté par briaeros007 () le 04/12/2006 à 10:27. (lien). É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é ?)

    --
    Subete ga wakatta toki…watashi ga anta wo korosu.

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

    Posté par Victor STINNER (page perso, ) le 04/12/2006 à 10:31. (lien). É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 :-(

Revenir en haut de page

Run by Team LinuxFr.org

Cette page a été générée par Templeet en 0.1342s (dont 0.0114 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !