Forum Programmation.c identifier à coup sur un fichier.

Posté par  (site web personnel, Mastodon) .
Étiquettes : aucune
0
26
août
2004
Bonjour,

Je désire implémenter une méthode en C qui prend en argument un fichier de type MP3 ou OGG et qui :

- renvoie les informations contenues dans une DB si le fichier est déjà présent

- ajoute le fichier dans la DB avec des valeurs par défaut si il n'est pas déjà présent (et renvoie donc ces valeurs par défaut)

Mon problème est donc d'identifier à coup sur un fichier, mais en le reconnaissant même si il a changé de nom, de tag.

Les solutions que je vois :

- Le nombre de bits du fichier. Mais la probabilité d'avoir deux fichiers du même nombre de bits me semble un peu élevée.

- MD5SUM. Mais n'est pas un peu lourd ? (j'aimerais que l'opération puisse être réalisée de manière très transparente et légère).
Quelle est la probabilité d'une collision ? comment utiliser cette fonction en C ?

- SHA1SUM. idem que MD5SUM.

-autre chose ?

Merci pour les infos et les conseils.

  • # A propos de md5/sha1

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

    Les résultats seront différents si un tag change. Donc si tu veux utiliser ca, fais le sur la partie données en ayant enlevé les tags...

    • [^] # Re: A propos de md5/sha1

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

      Bien vu ! Merci..

      Je vais voir si Gstreamer permet facilement d'extraire la zone de données.

      Je penche pour la solution suivante :

      - identification du fichier suivant son nom complet (full path)

      si pas trouvé, c'est que soit :
      - c'est un nouveau fichier
      - le fichier a été renommé
      - le fichier a été déplacé

      Là, je calcule un md5/sha1, ça réduit considérablement la charge (on déplace ou renomme rarement un fichier)

      Sinon, je précise que je prend le full path car I_love_you_baby.mp3 a de très fortes chances de collisions (vous voyez le genre)

      Mes livres CC By-SA : https://ploum.net/livres.html

      • [^] # Re: A propos de md5/sha1

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

        C'est clair que calculer le hash de plusieurs centaines (ou milliers) de mp3/ogg ça risque de prendre du temps mais tu peux faire ça avec des threads pour pas tout bloquer. Genre un thread qui a une liste de fichiers dont ont dont calculer le hash, quand tu veux accéder à un fichier, tu modifies la liste pour que le prochain fichier à être traité soit celui là.

        SHA1 est plus lent que MD5 mais les risques de collisions sont aussi moindres. Il y a aussi peut-être d'autres fonctions de hashage plus rapides (mais avec des risques de collision plus élevés) qui peuvent convenir (MD4 par exemple).

        http://planeta.terra.com.br/informatica/paulobarreto/hflounge.html(...) (une liste de fonctions de hashage cryptographiques trouvée sur Wikipedia)
        http://madchat.org/crypto/md5-vs-sha.txt(...)

        Il y avait aussi un article dans un Linux Mag France qui décrivait un programme de recherche de fichiers en double qui pourrait t'intéresser (le programme est disponible sur internet je pense, j'essairai de le retrouver demain si personne a trouvé d'ici là). Je crois qu'il utilisait notamment la taille des fichiers et un arbre de recherche binaire.

        pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

        • [^] # Re: A propos de md5/sha1

          Posté par  . Évalué à 1.

          Pour accélerer le traitement, peut-être qu'on peut se contenter de faire le hash sur seulement une petite partie du fichier (les 2 premiers Ko de la partie de donnée). Meme deux morceaux qui commencent par du silence auront toujours un peu de bruit de fond pour les distinguer. Et si dans ta base tu detecte quand-même une collision, tu rajoutes 1Ko à hasher jusqu'à ce que ça ne collisionne plus.

        • [^] # Re: A propos de md5/sha1

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

          Le programme dont je parlais s'appelle GDUPS et non seulement le code mais aussi l'article complet qui est passé dans le GNU Linux Magazine France 61 de mai 2004 sont disponibles online: http://f-cpu.seul.org/whygee/lm-gdups/(...)

          pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

        • [^] # Re: A propos de md5/sha1

          Posté par  . Évalué à 2.

          Il y a d'autre systeme plus légé que MD5/SHA1 pour calculer des sommes de controles: sur 16 bits et 32 bits (CRC)

          à titre indicatif sur un fichier de 20 Mo avec les outils GNU : sha1sum(160 bits), md5sum(128bits), cksum(CRC32bits) et sum(16bits)

          sha1sum: 0m1.250s
          md5sum: 0m1.152s
          cksum: 0m0.315s
          sum: 0m0.361s

          Par contre niveau risque de collision ...

          Je pense aussi à 2 autres trucs:
          - il y a un plugin gstreamer: md5sink. je sais mais peut être que tu peux récupérer avec que le md5 des données audio brut (problème de tags évoqué plus haut)
          - dans les specs « Thumbnail Managing Standard » de freedesktop, les vignettes portent le nom du hash MD5 de l'URI de l'image original. Même si le hash md5 d'un chemin doit se calculer trés rapidement, je sais pas trop si ça te sera utile ...

  • # md5

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

    le source de md5:

    http://cvs.gnome.org/viewcvs/drivel/src/(...) (regarde md5.*)

  • # Les entêtes ogg

    Posté par  . Évalué à 3.

    Il me semble que chaque fichier ogg/vorbis contient un identifiant unique (n° de série) dans l'entête, qu'on peut obtenir avec la commande ogginfo, ça peut être utile.

    Exemple :
    Nouveau flux logique (n°1, n° de série : 02a4b55e) : type vorbis
    Entêtes Vorbis du flux 1 analysés, les informations suivent...
    Version : 0
    Vendeur : Xiph.Org libVorbis I 20030909 (1.0.1)
    Canaux : 2
    Taux : 44100

Suivre le flux des commentaires

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