Luc's Compressor

En revenant du taff, y'a eu des bouchons. Oui je vous jure !
Et donc, j'ai profité de ce moment de solitude pour réfléchir sur un moyen à moi de compresser des
gros fichiers. Ne me demandez pas comment j'ai fais pour penser à ça, j'en sais trop rien moi même...

Bref ! Quoi qu'il en soit, en arrivant je me met au travail avec mes petites idées qui ont germées.
Voila mon idée complétement démente et qui ne sert probablement pas à grand chose !

Un fichier est une suite de 0 et de 1. Jusque là tout va bien.
L'idée de mon compresseur est extrêmement simple, pour chaque suite de 1 trouvée on incrémente une variable.
donc cette suite :
111111 = 6 tout simplement.
Ensuite, forcément on tombe sur des 0 :
000000=D6F
Ou encore :
0000=D4F
Voila !

Je me met au travail, et je code vite fais un petit binaire qui me fait ça pour moi.
Je me suis servis comme exemple d'un mp3 :

998Ko , ma méthode sort un fichier .luc (eh oui, faut bien être narcissique de temps en temps)
Ce fichier fait : 80.5Ko
Je suis assez content, jusqu'à ce que l'envie me prenne de faire la méthode inverse...
Finalement, petit échec de la journée. Le fichier reconstitué ne fait plus que 147Ko...
Dommage :/ je creuserais un peu plus demain.

----------------------------------------------------------
EDIT : Merci Mikaël pour l'aide,

"J'avais déjà réfléchi à une méthode comme celle ci (mais plus du genre "Conway") y'a très peu de temps (comme quoi ^^). Le souci, c'est que c'est rentable qu'à partir d'un certain seuil d'invariance. Faudrait' s'amuser à le déterminer. Ce p...rincipe se base sur une constatation simple : si tu utilises un octet (soit 8 bits) pour stocker le nombre de 1 consécutifs à un offset (par exemple), il faudra au minimum trouver 8 1 consécutifs à cet offset pour que la compression soit rentable.

Après, on pourrait optimiser certaines choses. Par exemple, on coderait le nombre de 0 ou de 1 sur un octet, seulement ça supposerait qu'on ne trouve jamais plus de 255 1 ou 0 d'affilée, et donc c'est foireux. Enfin, il faudrait réfléchir à une méthode qui gérerait toutes ces contraintes tout en conservant un seuil de compression supérieur ou égal à zéro en toutes circonstances. Se retrouver avec un fichier compressé plus gros que l'original, ce serait bien pourri ^^.

Sinon, j'ai chaud la flemme de débugguer du code C# (C'est vraiment top mais je suis crevé). Et pour la petite histoire, je pense que de nombreuses personnes ont dû penser à ça avant nous. Le truc intéressant, ce serait au final de savoir pourquoi ce type de compression ne peut pas être rentable ^^."

Il me précise aussi que ce type de compression s'appelle le "Run-length encoding"

M'enfin ça ne va pas m'empêcher de continuer ;)