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).
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 Krunch (courriel, site web personnel) . En réponse au message identifier à coup sur un fichier.. Évalué à 4.
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.