Raspberry Pi 4

For information, Recalbox IS NOT compatible with Raspberry Pi 4 yet.
Pour information, Recalbox N'EST PAS encore compatible avec le Raspberry Pi 4.

The Recalbox Team.

[SOFT] Universal ROM Cleaner – Nettoyez vos romset d'une main (Clean your Romset with one hand)


  • Staff
    Moderator
    Team

    Je ne dis pas que ton outil ne peut pas faire de tri mais Les roms arcades sont nommées en suivant des "règles". Une rom arcade ne doit jamais être remommée ou dezippée. Cest pourquoi on ne retrouve pas le meme nommage des roms arcades que dans les roms consoles. La liste des roms mame est disponible sur mamedb.com (parent avec leurs clones) On se sert beaucoup du fichier dat pour trier les roms notamment parents seuls ou par constructeur ou "bios" ( neogeo,pgm etc...) (Clrmamepro). Romlister permet de trier les roms à partir de fichiers xml ou dat par categorie. Mame Xml cleaner aussi et plus encore. Peut etre une idee d évolution pour ton outil.



  • On est tout a fait d'accord ;) c'est d’ailleurs ce que je précise, pour Mame (ou les jeux arcades en général) mon soft n'est pas adapté et d'autre le font beaucoup mieux que ce que je pourrais faire ;) Je réagissais juste sur le :

    Seuls les romsets no intro consoles sont triable.

    En fait non, tout romset peut être trié, pas que les No Intro, il leur faut juste une structure au niveau des noms de fichier avec des attributs entre crochets ou parenthèses ;) Mais on est bien d'accord sur le fond, Universal ROM Cleaner n'est pas du tout adapté au tri des roms arcades ;)


  • Staff
    Moderator
    Team

    J'insiste pour no-intro car ce sont les roms de référence et notamment pour la suite le scrap :D et ça donne une base de recherche au recalboxien pour une recherche sur google :P faut que tu nous développes un ti soft pour le tri mame maintenant en se basant sur les dats fournis sur recalbox tiens hihihi... romlister est pas mal mais en anglais, et Mame XML Cleaner faut avoir mame d'installer sur son pc....



  • Dès que j'aurais un peu de temps je checkerais ce que je peux faire ;) surtout si la base de dats existe déjà le gros du boulot est fait ^^



  • Merci a vous pour vos réponses. En ce qui concerne les roms arcades, oui malheureusement je m'en suis rendu compte, et j'ai cru que le soft universal cleaner permettait aussi de nettoyer les roms arcades, car pour le moment, je me suis penché que peu sur le clrmamepro, et je galere un peu. Mais je me suis encore un peu emmêle les pinceaux car c'est au niveau de universal scraper que j'ai quelques soucis, j'irai poser mes quelques questions sur le sujet approprié quand j'aurai déja finit les phases qui se passe sans problèmes. Merci encore acris et merci a toi screech pour ces superbes softs que tu propose aux recalboxiens qui permettent a des noocbs comme moi de gagner un temps fou pour un résultat plus que probant ;)



  • Salut @screech ! Bon, j'abandonne pour le cleaning du set Atari ST :x pour le moment en tous cas. Si un jour tu as un moment, il faudrait qu'on regarde ça ensemble. Trop de truc exotique, sans compter le système multi-disque. Si la zone "attribut ignoré" pouvait fonctionner dans le sens tel qu'on l'a expliqué précédemment, ça devrait déjà résoudre pas mal de soucis. Merci d'avance ! NB : de plus, dans mon cas, la simulation n'a rien à voir avec le résultat final :'(.



  • @jomofcw Je viens de publier une nouvelle version rien que pour toi ;)
    Universal Rom Cleaner V 1.0.0.5

    • Correction des Attributs Ignorés: Maintenant, si une seule rom possède un attribut unique et que celui-ci est ignoré. La rom est conservée.

    Bon, il faudrait quelques tests pour être 100% sur que tout fonctionne bien ;) mais les tests que j'ai fait me semble OK ^^



  • Haha ! Merci  beaucoup @screech ! J'vais tâcher de tester ça dans la semaine, et j'te fais un retour.



  • Salut @screech ! Bon, il y a du mieux, merci ! Mais... ce n'est pas encore tout à fait ça :x. Il reste deux points importants, détaillés ci-dessous. Premièrement, sauf si je n'ai pas compris le fonctionnement, rien ne permet de conserver le "multidisk"; par exemple j'ai les deux roms suivantes (cas réel) :

    • KO|122001|A Day at the Races (1989)(Team)(Disk 1 of 2)(cr MCA).zip
    • OK|122001|A Day at the Races (1989)(Team)(Disk 2 of 2)(cr MCA).zip

    Comme tu peux le voir, seul le "Disk 1 of 2" est conservé. Hors, il me faut bien conserver les deux. J'ai placé tous les attributs type "disk" dans "attributs ignorés". Donc soit je m'y prend mal,  soit le cleaner n'aime pas le multidisk :/. Ensuite, il semble que la priorité avec du multi attribut soit mal géré également. Pour exemple ces deux ROMs (fictive cette fois ci, je n'ai plus l'exemple réel sous le coude) :

    • KO|122001|A Day at the Races (1989)(Germany)(v2.0)(cr MCA).zip
    • OK|122001|A Day at the Races (1989)(Europe)(v1.0)(cr MCA).zip
    • KO|122001|A Day at the Races (1989)(Europe)(v2.0)(cr MCA).zip

    Les attributs "Germany", "Europe", "v1.0" et "v2.0" figure tous dans la liste "classez les attributs dans l'ordre" dans l'ordre suivant :

    1. Europe
    2. Germany
    3. v2.0
    4. v1.0

    Au niveau de la zone géographique c’est bon, puisqu'il conserve l'attribut "Europe" plutôt que "Germany". Mais pour l'attribut de version, là, il semble ne plus respecter l'ordre et conserve la première ROMs rencontré (ou la dernière, je ne sais plus). Donc ici, il conserve la "v1.0" au lieu de la "v2.0" alors même que dans la liste "v2.0" est placé plus "haut" que "v1.0". Bref, le cleaner semble ne tenir compte que du premier atribut classé rencontré. Voilà ! J'espère que ça aidera. Merci encore pour le boulot réalisé. N'hésite pas à me demander si mes explications manques de précisions.



  • @jomofcw Alors pour le second cas... Bein chez moi ça marche ^^
    Attribut dans l'ordre :

    • Europe
    • Germany
    • V2.0
    • V1.0
      Attribut ignorés
    • crc
    • MCA
    • 1989

    Résultat (sur exactement les mêmes fichiers que toi) :

    KO|2001|A Day at the Races (1989)(Germany)(v2.0)(cr MCA).zip
    KO|1034|A Day at the Races (1989)(Europe)(v1.0)(cr MCA).zip
    OK|1001|A Day at the Races (1989)(Europe)(v2.0)(cr MCA).zip
    

    Par contre, du coup, j'ai fait une modif pour le multi disk...
    Il faut mettre les arguments concernant les multidisk dans les ignorer.
    Et du coup quand 2 fichiers on exactement la même valeur, il conserve les 2 ;)
    Tu peux tester et me redire : Pre-release v1.0.0.6



  • Petit ajout pour l'explication du "poids" d'un fichier Lors de la simulation, après le OK ou le KO, il y a un chiffre.
    Plus ce chiffre est faible, plus le fichier est "conservé".

    Ce chiffre est calculé en fonction de l'ordre des attributs.
    L'algo pour le calcul du poids des attributs est plutôt complexe (en fait je m'en rappel plus :p )
    Mais si ça vous intéresse je vous le mettrais ;)

    La modif faite fait que lorsque les chiffres sont identiques, les fichiers sont conservés. ;)



  • @screech, bordel, ça c'est de la réactivité ! Je teste ça immédiatement !



  • @screech, encore du mieux, mais reste deux trois trucs à fixer. Par exemple, les deux ROMs suivantes :

    • OK|41931|Pirates! (Europe) (v832.02).zip
    • OK|41931|Pirates! (Europe) (v832.04).zip

    Les deux sont conservées et ont un poids équivalent. Pourtant les attributs qui les composent sont dans la colonnes des attribut à ordonner, selon l'ordre suivant :

    • Europe
    • v832.04
    • v832.02

    Bien évidemment je ne donne à chaque fois qu'un bref échantillon. Là, pour mon test, il s'agit de ROMs Amiga et j'dois avoir au bas mot une grosse centaine d'attribut ordonner en tout. Peut être que ça joue... Comme suggéré, tu pourrais faire suivre l'algo de calcul du poids s'il te plait ? Je suis sur IRC si tu veux converser directement à ce sujet.



  • Allez, pour me remettre dans le bain, voici une description de l'algo ;)

    Une valeur est donnée à chaque attribut dans l'ordre (Premier attribut de la liste = 0, deuxième = 1, etc...)

    Ensuite chaque fichier est passé au crible pour définir les "doublons" en excluant les attributs et extension (un "mario (europe) [V2.0].zip" devient donc un "mario" tout court)

    On donne ensuite la valeur poids 1 à chaque fichier (pour que même les fichiers sans attributs soit conservés. ça fait partie de mes dernières modifs ^^)
    Pour chaque "doublon" on calcul la valeur de ses attributs selon le calcul balaise suivant :
    Le premier attribut du fichier = (la valeur de l'attribut + 1) *1000000
    Donc un fichier avec 1 seul attribut et dont l'attribut est le premier de la liste aura un poids de 1 + ((0+1)*1000000) soit 1000001
    Ensuite les attributs suivant pondère cette valeur en soustrayant le calcul suivant du poids actuel : (10000 - (((Valeur de l'attribut + 1)*10000)/(le nombre total d'attribut+1)))

    Avec un exemple c'est plus simple ;)
    Voici 3 fichiers :
    Mario (Europe)(V1.0).zip
    Mario (Europe)(V2.0).zip
    Mario (US).zip

    Dans l'ordre les attributs sont trié (avec en face leur valeur du coup) :
    Europe = 0
    US = 1
    V2.0 = 2
    V1.0 = 3

    Maintenant on passe au calcul du poids :
    Mario (Europe)(V1.0).zip
    Europe (premier attribut) = (0+1)*1000000 = 1000000 (POIDS du fichier = 1 + 1000000 = 1000001)
    V1.0 = 10000 - (((3+1)*10000)/3+1) = 0 (comme il s'agit d'un attribut supplémentaire, je soustrais la valeur. POIDS du fichier = 1000001 - (0) = 1000001)
    Mario (Europe)(V1.0).zip = 1000001

    Mario (Europe)(V2.0).zip
    Europe (premier attribut) = (0+1)*1000000 = 1000000 (POIDS du fichier = 1 + 1000000 = 1000001)
    V2.0 = 10000 - (((2+1)*10000)/3+1) = 2500 (comme il s'agit d'un attribut supplémentaire, je soustrais la valeur. POIDS du fichier = 1000001 - (2500) = 997501)
    Mario (Europe)(V2.0).zip = 997501

    Mario (US).zip US
    (premier attribut) = (1+1)*1000000 = 2000000 (POIDS du fichier = 1 + 2000000 = 2000001)
    Mario (US).zip = 2000001

    Il ne me reste plus qu'à trier par poids. Et de ne garder que le poids le plus faible :
    Mario (Europe)(V2.0).zip = 997501 -> OK
    Mario (Europe)(V1.0).zip = 1000001 -> KO
    Mario (US).zip = 2000001 -> KO

    Avant je ne gardais que le premier poids le plus faible.
    Maintenant avec la dernière modif, je garde tous les fichiers ayant un poids le plus faible identique.

    Exemple : Si les attributs (Disk 1-2) et (Disk 2-2) sont ignoré (donc non pris en compte dans le calcul)
    Mario (Europe)(V2.0) (Disk 1-2).zip = 997501 -> OK
    Mario (Europe)(V2.0) (Disk 2-2).zip = 997501 -> OK
    Mario (Europe)(V1.0).zip = 1000001 -> KO
    Mario (US).zip = 2000001 -> KO
    Les 2 premiers fichier ayant le même poids et celui-ci étant le plus faible, ils sont conservé tous les 2 ^^ (Il ne faut pas oublié qu'avant tout ça la liste est purgé des fichiers contenant un attribut de la liste des "non conservés")



  • @screech , merci pour le détail ! Bon donc le soucis se pose bien quand il y a une liste "trop" longue d'attribut. Par exemple, imaginons une liste de 200 attributs ordonnés.

    • Le 150eme aura pour poids : (100 – (((150 + 1)*100)/(200))) = 24,5 (soit une valeur positive, ce qui soustraira au poids au lieu d'ajouter...?!)
    • Le 151eme aura pour poids : (100 – (((151 + 1)*100)/(200))) = 24

    J'imagine qu'il y a un jeux d'arrondit d'entier ce qui expliquerait que mes deux ROMs dans l'exemple précédent aient exactement le même poids, alors même qu'elles comportent deux attributs différents, classés a des rangs voisins mais différents. Là comme ça, je ne vois pas un autre algo à appliquer. En revanche, mathématiquement si tu multiplie tes valeurs fixes par 100 (autre que 1), ça devrait nous donner un peu de marge, et éviter les chiffres à virgule sauf dans le cas d'une liste dépassant les 10000 attributs... mais là, franchement, ce sera de toute manière impossible à trier ^^. Ceci étant, j'ai du mal avec le fait que, théoriquement, pour tout attribut compris entre le premier et l'avant dernier, la valeur sera positive, pour l'avant dernier elle sera 0 et pour le dernier elle sera négative... ça fausse un peu l'ensemble, non ? On devrait toujours avoir une valeur positive, et systématiquement l'ajouter ? Pourquoi ne pas simplement ajouter au poids 1 initial l'index de l'attribut en question, que ce soit le premier, le dernier, ou n'importe quelle autre ? Que penses-tu de tout ça ?



  • Nouvelle version : v1.0.0.15

    De nombreuses corrections, un mode plein écran et un nouvel algo. Le tout testé par @jomofcw ^^

    ça marche drôlement mieux maintenant ^^



  • Now in German : V2.0.0.1

    Thank you @Nachtgarm



  • Bonjour @screech,

    Petite question je n'ai pas trouvé la réponse en parcourant le thread:

    Comment gérer par exemple la plupart des jeux ont des "sous-titres", même nom de jeu, mais souvent en japonais y'a le sous-titre de marqué, ce qui change le nom du jeu au final, résultat il me garde un nombre incalculable de jeux. Pourtant ces jeux viennent de romsets.

    OK|King of the Monsters 2 (USA).zip|SIMUL|
    OK|King of the Monsters 2 - The Next Thing (Japan).zip|SIMUL|

    J'aurais voulu un KO sur le 2ème en japonais :s

    Merci d'avance !



  • Salut @eightkiller

    Malheureusement ce que tu demande est impossible (en tout cas avec Universal Rom Cleaner ;) )

    C'est en projet d'integration dans Universal XML Editor (mon 3eme soft loin d'etre finit) qui permettra de dedoublonné par Id de jeux (les Id récupéré pendant le scrape depuis Universal XML Scraper ^^)

    Mais c'est vraiment pas pour maintenant :(



  • I was really hopping that this tool can remove duplicates by checking Hashes. But it doesnt. Any chance to see that option? or at least compare crc's and remove doubles?

    Steel Empire, The (UE) [!]
    Steel Empire (USA)
    same crc ,sha1



Want to support us ?

370
Online

59096
Users

18462
Topics

138825
Posts

Looks like your connection to Recalbox Forum was lost, please wait while we try to reconnect.