[whynot]

Originally Posted by chronos

Et là je me heurte a un comportement que j'éxecre au plus haut point, les pseudos-secrets de l'informatique! Ces messieurs ne veulent pas livrer leur "secret" qui ne doit même pas en être un et qui je pense ne doit pas avoir été inventé par eux.

Un "secret" dans un logiciel opensource ???
Haha.
Non, leur réponse a peut-être été de jeter un oeil à la source parce que comme tu le dis toi-même, c'est très compliqué et ça met du temps à expliquer (et donc ne connaissant pas ton niveau de compétences ils n'ont pas eu le courage/temps/envie de le faire). Mais si tu en as ces compétences, libre à toi de parcourir cette source et de décourvir comment marche le LZMA, il n'y a aucun sercet là dedans...

Autre élément d'explication beaucoup plus satisfaisant maintenant que j'y pense : les roms snes (les autres aussi mais là c'est de la snes) sont des images BRUTES des infos stockées dans les différentes pupuces de la cartouche. On ne crerche pas à optimiser le truc, par conséquent, puisque les cartouches étaient dispo selulement dispo en quelques tailles (1Mo, 2Mo, 4Mo, 8Mo, 16Mo pour les dernières c'est bien ça ? Enfin c'est juste pour avoir une idée), si un développeur voulait y mettre un jeu de 12Mo, il fallait une cartouche de 16Mo. Il y a alors 4Mo inutilisés dans la cartouche. Et comme je l'ai dit, avec une image brute, on aura 4Mo de zéros, ce qui est, tu en conviendras, très facile à compresser même avec l'algo de compression le plus niais qui consiste à remplacer 0000000000 par 10*0).

[fonji]

Pas de problème pour un émulateur, parce que tu peux très bien ainsi créer tes propres jeux pour snes, et c'est vrai pour les jeux que nintendo devrait gentillement s'en f... de sa snes (pourtant mythique).
M'enfin, les deux sujets (l'original du mystère de compression et la légalité du reste) m'intéressent, on verra pour la suite...

Excuse-moi donc pour ma réponse pas trop sympathique et bienvenue quand même !

[chronos]

Excuse-moi donc pour ma réponse pas trop sympathique et bienvenue quand même !

C'est pas grave. Merci.

Mais si tu en as ces compétences, libre à toi de parcourir cette source et de décourvir comment marche le LZMA, il n'y a aucun sercet là dedans...

J'ai téléchargé la source et j'y ai jeté un bref coup d'oeil. J'ai fait du c++ pendant toute l'année dernière dans mon petit iut d'informatique mais là je me suis fait un peu peur avec cette source. Pour la comprendre il faudrait que je m'y penche pendant des heures.

les roms snes (les autres aussi mais là c'est de la snes) sont des images BRUTES des infos stockées dans les différentes pupuces de la cartouche. On ne crerche pas à optimiser le truc, par conséquent, puisque les cartouches étaient dispo selulement dispo en quelques tailles (1Mo, 2Mo, 4Mo, 8Mo, 16Mo pour les dernières c'est bien ça ? Enfin c'est juste pour avoir une idée), si un développeur voulait y mettre un jeu de 12Mo, il fallait une cartouche de 16Mo.

Les plus grosses roms que j'ai font 6mo. Les tailles les plus courantes pour les roms de snes sont: 1mo, 2mo, (3mo), 4mo, 6mo.
J'ai aussi ouvert pas mal de roms avec un editeur hexa et il s'avere en effet qu'il y a des données répétitives dans certaines roms, mais jamais plus de 5 ou 10% de la taille totale de la rom. Je pense que le probleme que tu a soulevé a été réglé par les personnes qui on passé le contenu des cartouches de snes en fichiers .smc.

Et toi, aurais-tu déja fouillé dans la source du LZMA SDK ? Aurais tu les-dites qualifications en c++ et algorithmes de compression pour m'expliquer des choses si tu en avait le temps et l'envie ?

[whynot]

Originally Posted by chronos

Les plus grosses roms que j'ai font 6mo. Les tailles les plus courantes pour les roms de snes sont: 1mo, 2mo, (3mo), 4mo, 6mo.

Oui oui, tout à fait possible, comme je le disais, "c'est juste pour avoir une idée" et expliquer mon propos

Originally Posted by chronos

Et toi, aurais-tu déja fouillé dans la source du LZMA SDK ? Aurais tu les-dites qualifications en c++ et algorithmes de compression pour m'expliquer des choses si tu en avait le temps et l'envie ?

Oh que non. La compression est (de ce que je connaisse) avec la crypto le domaine de le prog où tu te tapes le plus vite des maths de fou. Les types qui concoivent des méthodes de compression sont bien plus que de bons programmeurs, ce sont avant tout de grosses brutes en maths...
Si tu souhaite te pencher de plus près à la compression, je te déconseille de commencer par le LZMA, il existe de très bons bouquins qui seront bcp plus progressifs et pédagogiques que ton approche un p'tit peu sauvage quand même .

[fonji]

J'ai étudié la crypto et quelques algos de compression dans mon école d'ingénieur, pas facile d'expliquer ça sur un forum...
Si ça t'intéresse vraiment, je conseille tout comme whynot de voir vers les bouquins.

Toujours est-il que, quand même, 1/8 de la taille, ça m'étonne tout autant que toi...

T'as essayé de recréer l'archive toi-même, pour voir si ça fait la même chose ?!?

[chronos]

Oui, j'ai bien sur rééssayé de recréer cette archive moi même.
J'ai regardé la méthode de compression qui est LZMA:26, c'est a dire avec un dictionnaire de 64mo.
Sans succés, enfin avec un taux de compression juste supérieur au RAR.

Je suis même en train de communiquer avec le support de 7-zip (2 réponses depuis ce matin) et ils font a priori semblant de ne pas savoir de quoi je parle (ou ils lisent les mails tellement vite qu'ils n'ont pas tou compris). Je leur ai envoyé un mail un peu plus explicite pour voir ce qu'ils vont dire.
A mon avis si ce genre de compression est possible, ils sont au courant.

Merci pour le conseil des livres. C'est comme dans beaucoup de choses en informatique: il faut etudier un ou deux bons livres. Mais ça met du temps et je ne suis pas sur que c'est la solution la meilleure pour découvrir comment ces archives ont été faites. Je pense que ce ne sont pas ces gars eux même qui ont inventé ça. Ils ont trouvé quelque part ou c'était expliqué comment faire, je pense. Tout ceci n'est que supposition mais bon...

[Matt]

Quand tu as essayé de recompresser, a tu bien activé l'option "Archive solide" (je suis pas sûr que ça soit activé par défaut dans 7-zip) ?
Si ce n'est pas le cas, la différence peut venir de ça, puisque sur 16 Go de données en fichiers de 4 Mo, il doit y'avoir moyen de gagner pas mal en faisant une archive solide (le gain en mode solide est d'autant plus grand que le nombre de fichiers est grand).