Comparaison de compresseurs de données - LZO, Gzip, Bzip2, XZ

fabien26 · Le 07/06/2012, à 19:18

Bonjour les Linuxiens,

J'ai eu besoin pour un projet obscur de comparer la vitesse et le taux de compression de différents format de compression et compresseurs attitrés libres.

Je vais les classés du plus rapide au plus lent, ceci aidant à s'y repérer et en tirer des conclusions pertinentes.

Je me suis donné deux impératifs:
- Pouvoir compresser à une vitesse convenable sur un processeur très limité (K6-2 underclocké à 250 mhz moins performant que les premiers pentium 2 et Celeron à fréquence égale)
- Pouvoir fonctionner parfaitement avec très très peu de ram, 28 Mo en l'occurrence. (oui c'est un PC vraiment ancien)

J'ai commencé par faire un .tar de tout mon système Debian installé sur une vielle machine ( cf: http://forum.ubuntu-fr.org/viewtopic.ph … #p4030319). Ce fichier contient donc une Debian fraîchement installée, pleine de fichiers textes, d'images et d'exécutables.

Rappel: le .tar n'est pas un fichier compressé, il s'agit plus d'une archive non compressée contenant tous les fichiers et leurs propriétés et en fait donc un seul très facile à compresser ensuite. Des formats comme le 7zip ou le .zip ont un système qui fait le travail de tar. Mais à l'origine un format de compression n'est capable de compresser qu'un seul fichier. tar faisant le travail de tout regrouper avant la compression. (ce processus peut être automatisé bien entendu et est normalement totalement transparent).

Début des résultats:

# time lzop -vc /Debackup.tar > /Debackup-def.tar.lzo
   4m42.48s real    2m19.24s user     0m30.61s system
# du -m /Debackup-def.tar.lzo  # <- Cette commande renvoie la taille en Mo d'un fichier
376    /Debackup-def.tar.lzo  # Taille en Mo puis nom du fichier, voici ce que renvoi cette commande.

Ouah ça commence vite pour un si vieux joujou !
Et comme vous le voyez au fait que "user" et "real" sont très différent, le processeur n'était qu'à 50% lors de la compression, ce qui voudrait dire que l'on pourrait aller encore plus vite si je changeais de disque dur. ("time" ajouté devant n'importe quelle commande permet de voir le temps qu'elle a mise à s'exécuter. Real correspond au temps Réel, User le temps que le programme à travaillé et System le temps que le noyau Linux a travaillé pour gérer le programme)

# time lzop -"1à6"vc /Debackup.tar > /Debackup-"1à6".tar.lzo
   sensiblement les mêmes temps et exactement la même taille de fichier.

Là je ne comprendre pas. De -1 à -6 aucune différence, ce paramètre ne sert à rien du tout...

# time gzip -1vc /Debackup.tar > /Debackup-1.tar.gz                            
/Debackup.tar:   59.8%
    8m19.20s real     7m13.40s user     0m27.04s system
315     /Debackup-1.tar.gz

Gzip lancé avec l'option -1 (-1 à -9 permettent de choisir la "force" de la compression, par défaut c'est -6) rapporte un temps très correct étant donné qu'on ne dispose pas de beaucoup de ressources. gzip -1 est donc une très bonne alternative à lzop dans ce cas. 2 fois plus de temps (4 fois plus si le HDD avait été plus rapide) et une compression bien plus forte.

# time gzip -c /Debackup.tar > /Debackup-def.tar.gz                           
/Debackup.tar:   63.0%
   19m59.64s real    18m57.31s user     0m28.28s system
290     /Debackup-def.tar.gz

Malgré qu'ils soient bien plus lents, les paramètres par défaut de gzip restent un bon compromis entre temps passé et compression. Transformer 781 Mo en 290 Mo en 20 minutes est un score surprenant.

# time xz -z0vc /Debackup.tar > /Debackup-0.tar.xz                             
/Debackup.tar (1/1)
  100 %       247,7 MiB / 781,3 MiB = 0,317   457 KiB/s      29:09             
   29m10.73s real    27m51.02s user     0m23.04s system
248     /Debackup-0.tar.xz

Pour dix minutes de plus on gagne encore 40 Mo ! Bien plus rentable que gzip ! Xz est un format de compression récent basé sur LZMA, et il m'impressionne par sa vitesse ! Bien entendu il faut pour cela activer la compression minimale. Qui reste malgré tout extrêmement compressante !

# time xz -z1vc /Debackup.tar > /Debackup-1.tar.xz                             
/Debackup.tar (1/1)
  100 %       234,6 MiB / 781,3 MiB = 0,300   350 KiB/s      38:03             
   38m5.03s real    36m33.73s user     0m23.96s system
235     /Debackup-1.tar.xz

Et encore 10 minutes de notre temps précieux de perdu pour gagner ce coup ci 13 Mo de plus ! C'est peu et c'est le maximum que l'on peut avoir dans les limites du raisonnable sur ce PC. Au delà de -1 xz utilisera en effet trop de Ram. Et les 28 mo de Ram de ce PC limitent Xz à -1. -2 créera un enfer de lag à cause de l'obligation de passer massivement par le Swap. Une très mauvaise idée si on ne veut pas compresser un fichier pendant 4 jours. Il en reste quand même que même sur un ordinausaure comme celui ci on peut parfaitement utiliser XZ. Ce qui veut dire qu'il a de beaux jours devant lui ! On pourrait en effet imaginer utiliser XZ comme format de compression par défaut des .deb et ainsi réduire énormément le temps de téléchargement des mises à jours ! (les index des dépôts sont déjà en LZMA (peut être pas XZ)).

# time lzop -7c /Debackup.tar > /Debackup-7.tar.lzo
   45m2.98s real    42m10.41s user     0m29.62s system
316    /Debackup-7.tar.lzo

Alors là nous commençons à entrer dans l'antre de la perte de temps ... Alors déjà je tiens à réaffirmer ma confusion face à lzop ... -1 jusqu'à -6 aucun changement, mais -7 commence à donner un résultat, et quel résultat ! Un résultat sans équivoques, nous avons perdu notre temps ! Et bien en plus ! Pour 7 minutes de plus que xz nous avons un fichier 80 Mo plus gros ! Le seul argument de LZO étant la vitesse c'est un peu perdre tout l'intérêt du truc. Mais bon ...

# time bzip2 -z1vc /Debackup.tar > /Debackup-1.tar.bz2                          
  /Debackup.tar:  2.829:1,  2.828 bits/byte, 64.65% saved, 819261440 in, 289574292 out.
   45m3.23s real    43m13.42s user     0m27.75s system
277     /Debackup-1.tar.bz2

Ah passons à notre gros looseur du jour, bzip2 ! Il n'est nul par sur les podiums. Peut être sur le podium de l'inutilité sur lequel il est roi désormais. Il ne faut pas non plus être trop méchant avec ce format, il fut autrefois très utile, il compresse comme vous le voyez bien plus que gzip quelque soit le réglage (même le plus rapide comme vous le voyez ici) mais depuis l'arrivée de xz il ne fait décidément plus le poids, et il ne serait pas étonnant de voir disparaître totalement les .tar.bz2 des téléchargements au profit des .tar.gz (déjà standard) et .tar.xz.
Nous sommes au réglage le plus rapide et comme vous le voyez bzip2 n'est pas bien rapide, 45 minutes pour faire moins bien que ce que peut faire xz en 30 minutes c'est plutôt pathétique.

# time bzip2 -zvc /Debackup.tar > /Debackup-def.tar.bz2                                                                          
  /Debackup.tar:  2.975:1,  2.689 bits/byte, 66.39% saved, 819261440 in, 275381190 out.
   55m38.24s real    53m8.15s user     0m25.56s system
263     /Debackup-def.tar.bz2

Pour 10 minutes avec bzip2 de plus (en utilisant les paramètres par défaut) nous gagnons 13 Mo. C'est maigre, c'est peu compétitif, ça n'apporte aucun avantage face à la concurrence, c'est bzip2 ...

# time bzip2 -z9vc /Debackup.tar > /Debackup-9.tar.bz2                                                                           
  /Debackup.tar:  2.975:1,  2.689 bits/byte, 66.39% saved, 819261440 in, 275381190 out.
   55m45.82s real    53m6.99s user     0m26.23s system
263     /Debackup-9.tar.bz2

C'est moi ou -9 est le choix par défaut chez bzip2 ? J'aime la triche !

# time gzip -9vc /Debackup.tar > /Debackup-9.tar.gz                              
/Debackup.tar:   63.2%
   59m26.76s real    57m34.01s user     0m26.62s system
# du -m /Debackup-9.tar.gz                         
289     /Debackup-9.tar.gz

L'une des plus grosses aberrations que je découvre avec ce comparatif, l'option -9 de compression maximale de gzip qui, regardez à nouveau un peu plus haut, fait gagner 1 Mo (oui 1 malheureux Mo !) au dépend de 40 minutes de travail supplémentaire ! C'est à se demander pourquoi il existe des paramètres au dessus de -6 dans gzip ... Complètement incompréhensible ...

# time xz -z0evc /Debackup.tar > /Debackup-0e.tar.xz                           
/Debackup.tar (1/1)
  100 %       224,1 MiB / 781,3 MiB = 0,287    83 KiB/s    2:41:18             
  161m19.04s real   156m29.89s user     0m25.58s system
225     /Debackup-0e.tar.xz

xz propose une option -e cette option permet d'augmenter la compression au dépend d'une utilisation plus importante du processeur. J'étais curieux de voir ce que cela pouvait donner. La réponse est là, une attente interminable ! Mais en dehors de cela on y gagne pas mal !

# time lzop -9vc /Debackup.tar > /Debackup-9.tar.lzo

Ridiculement long ! Au bout d'une heure j'étais encore à 130 Mo ... Le mode compression maximale de lzo est à oublier. Le seul intérêt de ce compresseur est sa vitesse, ce mode à de quoi dérouter car on a ni la vitesse ni la bonne compression (de toute évidence). Je ne sais pas ce qu'ils ont dans la tête quand ils ont entre les mains un compresseur qui n'a que sa vitesse pour argument et qu'ils te mettent ce genre de modes totalement inutiles. Bon je suis désolé d'être aussi énervé contre un programme de quelques Ko mais l'attente m'a mis KO ...

Changeons de PC pour analyser un peu plus en profondeur notre champion XZ.
Les tests ont été fait sur un Core 2 Quad 3,6 Ghz pour des raisons de Ram et de vitesse. Les paramètres par défauts de XZ restent parfaitement utilisables sur un PC modeste (par exemple un pentium 4 avec 512 Mo de Ram), les paramètres minimaux sont parfaitement utilisables même avec des ressources très restreintes, que peut on dire des paramètres maximums. Es-ce qu'ils ont un effet contrairement aux autres compresseurs ? Nous allons voir ça !

# time xz -zvc ./Debackup.tar > ./Debackup-def.tar.xz
./Debackup.tar (1/1)
  100 %       198,8 MiB / 781,3 MiB = 0,254   1,8 MiB/s       7:09             

real    7m9.211s
user    7m7.375s
sys    0m1.276s
utilise environ 90 Mo de ram
199    ./Debackup-def.tar.xz

Avec les paramètres par défaut xz compresse vraiment beaucoup beaucoup. Et c'est magnifique ! Gardez à l'esprit que ce fichier ne pourra pas être décompressé avec mon vieux Medion (28 Mo de ram rappel) car la RAM utilisée pour la compression est la même que pour la décompression. Le mode par défaut demande donc 90 Mo, il faudra un PC avec un minimum de 192 Mo de ram pour décompresser ce fichier à l'aise. (ou 128 Mo sans interface graphique)

# time xz -z9vc ./Debackup.tar > ./Debackup-9.tar.xz
./Debackup.tar (1/1)
  100 %       179,0 MiB / 781,3 MiB = 0,229   1,6 MiB/s       8:16             

real    8m16.503s
user    8m13.087s
sys    0m1.708s
utilise environ 670 Mo de ram
180    ./Debackup-9.tar.xz

Poussons xz à fond ! Là nous utilisons vraiment beaucoup trop de RAM et je comprend pourquoi ce mode n'est pas actif par défaut, mais le temps passé à compresser reste très raisonnable. et le gain (près de 20 Mo) est significatif. On peut donc facilement comprendre l'utilisation de ce mode si votre ordinateur à un minimum d'un GO de mémoire vive, 2 GO pour être à l'aise (attention juste à ne pas envoyer ce fichier à un windowsien avec 2 GO de ram car il va swapper à mort)

# time xz -zevc ./Debackup.tar > ./Debackup-e.tar.xz
./Debackup.tar (1/1)
  100 %       198,5 MiB / 781,3 MiB = 0,254   1,4 MiB/s       9:26             

real    9m26.819s
user    9m25.479s
sys    0m1.164s
199    ./Debackup-e.tar.xz

L'option -e utilise plus de processeur, mais pas plus de RAM, par contre, même si elle peut être ajoutée à n'importe quel autre paramètre de force de compression elle ne change plus grand chose à partir de -2

# time xz -z9evc ./Debackup.tar > ./Debackup-9e.tar.xz
./Debackup.tar (1/1)
  100 %       178,6 MiB / 781,3 MiB = 0,229   1,2 MiB/s      10:58             

real    10m58.810s
user    10m56.521s
sys    0m1.708s
-e ne change pas l'utilisation de la RAM
179    ./Debackup-9e.tar.xz

Idem ... Peut être que si le fichier à compresser faisait plus de 20 Go on pourrait voir une différence mais je doute qu'elle soit significative.

Conclusions pour XZ:
* L'option -e requiert un très bon processeur et est utilisable avec tous les réglages pour augmenter encore plus la compression au dépend de l'utilisation processeur.
* -0 jusqu'à -9 augmentent progressivement l'utilisation de la RAM et modérément l'utilisation du processeur. Gardez à l'esprit que la Ram demandée lors de la compression sera aussi demandé lors de la décompression (pour -9 vous ne pourrez pas le décompresser sur un PC avec 512 Mo de ram, en tout cas pas en moins d'une semaine)
* -e ne sert à rien si on vise une haute utilisation de ram (entre -4 et -9) et que l'on ne compresse pas des dizaines de GO. Mais est très avantageux pour augmenter la compression tout en utilisant un minimum de ram (rappel la ram utilisée pour la compression est la même que pour la décompression). Cette option peut donc être très utile si vous comptez envoyer le paquet le plus petit possible et qu'il peut concerner des ordinateurs peu puissant (reste à savoir si -e allonge ou pas le temps de décompression, je pense que non mais des tests sont à faire.)

Voilà donc ce qui conclu cette comparaison des compresseurs les plus populaire dans le monde du libre. On peut en conclure que:
- LZO est vraiment très rapide, il peut même permettre d'aller plus vite que son disque dur, et ce même sur un vieux coucou
- XZ est le champion toute catégorie de la compression pure et ce à toutes les vitesses sauf "rapides comme le vent"(Gzip) et "rapides comme l'éclair"(LZO).
- Utiliser Gzip en compression minimale offre un bon compromis entre LZO et XZ, c'est à dire vitesse et compression pure
- Les options de compressions poussés à bout ne servent qu'à perdre votre temps (-9e pour XZ et -9 pour lzo, gzip et bzip2)
- Bzip2 ne sert plus à rien et doit passer de technologie fastueuse à relique du passé ! Il n'a aucun bon point, pas un seul ! Même pas un petit ... Si en creusant on peut en trouver un ... Si votre PC n'a pas xz, il permet d'avoir un fichier plus petit à télécharger pour télécharger XZ ^^ Mais une fois que l'on a xz, il n'a absolument aucun intérêt. D'ailleurs j'ai eu la surprise de voir qu'après une installation minimale de Debian Xz était installé mais bzip2 devait être installé manuellement, ils ont tout compris.

Petit mot pour les absents:
- zip: le zip est théoriquement identique à gzip, il utilise le même algorithme et donc doit avoir des résultats similaires.
- lzma: lzma est en gros l'ancienne version de xz (lzma2). lzma est lent et lourd, et est connu pour compresser de manière sensiblement identique (xz fait même mieux). Pas besoin de perdre du temps à le tester donc.
- 7zip: Très populaire sous windows, et par conséquent sous linux, ce format est lui aussi dérivé de lzma. Des tests personnels m'ont permit de voir qu'il compresse avec des taux identiques à xz. Peut être est il plus ou moins rapide, je n'ai pas pris le temps de le mesurer. Mais il ne convenait pas à mon usage. Les .tar.7z ça fait un peu bâtard comme format et il n'est pas possible à ma connaissance de faire un .tar pendant la compression comme avec les formats testés ce qui fait perdre un temps considérable. J'ouvre une parenthèse pour dire que le Tar est important sous linux, il permet de garder le fichier et aussi ces propriétés comme les permissions. Les formats zip, et 7zip ne peuvent pas les conserver ce qui peut gêner ce qui est compressé surtout quand ce que vous compressez est un programme.
- Qpaq, Zpaq, etc formats peu diffusés. Pas assez diffusés et souvent à raison. Ou ils sont en développement, ou ils sont inutiles (recherches infructueuses), ou ils sont totalement inutilisable si on a pas un PC de malade mental (même mon core 2 qui compresse un fichier de 800 Mo en XZ en 10 minutes avec les paramètres maxi prendrait un temps phénoménal - comparables à ceux du vieux Medion) Ma curiosité aidant ça sera peut être l'occasion d'un autre test.

Dernière modification par fabien26 (Le 08/06/2012, à 09:23)

kamui57 · Le 07/06/2012, à 20:16

LZO a été utilisé dans Stuxnet (et Duqu), les agences des US et d'Israël savent choisir leurs libs

Tu pourrais juste mettre ce qui se passe dans le terminal entre balises codes, pour améliorer la lecture ? Je trouve que ça fait gros pavé là.

Dernière modification par kamui57 (Le 07/06/2012, à 20:24)

fabien26 · Le 07/06/2012, à 21:51

Tu as totalement raison je vais mettre des balises code !

Grünt · Le 07/06/2012, à 22:24

Si t'aimes faire des benchmarks, ça te dirait d'en faire un pour copier des données via le réseau, avec plusieurs config hardware (processeur, RAM, disque) et réseau (vitesse, support physique..) ?

fabien26 · Le 08/06/2012, à 08:18

J'ai déjà eu à faire ce genre de Benchmark. malheureusement je n'ai pas noté les résultats, mais ils étaient surprenants.

C'est à dire qu'en gros avec le même processeur, la même ram, la même carte réseau, on peut avoir un énorme gain de performance en changeant la carte mère contre une bonne carte mère (Chipset Via et SiS VS chipset Intel) J'avais testé avec un Pentium 3 533 Mhz.

Avec le Pentium 3 en NFS si on active le mode asynchrone et que l'on utilise le protocole UDP on peut atteindre 17 Mo/s dans les deux sens. Ce qui n'est pas mal du tout pour une si vielle machine.

J'ai un autre benchmark dans les bacs que j'ai fait pour faire un rapport de Bug pour gvfsd. Il concerne d'ailleurs lui aussi les NAS.

Heliox · Le 08/06/2012, à 13:04

Merci pour ces comparaisons !
Quand je crée des archives je ne sais jamais quel type d'archive choisir, si je comprends bien, XZ est le format à favoriser (pour nos machines modernes).

J'ai une question d'ordre pratique : comment profite-t-on concrètement de ce(s) format(s) ? Avec la ligne de commande j'imagine, mais avec une GUI ?

Avec Windows j'utilise le logiciel libre 7zip, mais quand je veux créer une archive, je n'ai le choix qu'entre 3 formats qui proposent différents types de compression :
- .7z permet de compresser avec LZMA, PPMd, BZip2.
- .tar ne propose... rien (il faut recompresser encore après je pense).
- .zip permet de compresser avec Deflate, Defalte64, BZip2 et LZMA

Avec GNU/Linux (j'utilise FileRoller de Gnome 3.4), je n'ai le choix qu'entre :
- .7z
- .cbz
- .exe (<- lol ?)
- .jar (<- idem)
- .tar
- .tar.7z
- .tar.Z
- .tar.bz2
- .tar.gz
- .tar.lzma
- .tar.xz
- .zip

Donc en rapport à ce que tu as mesuré, quel est le plus intéressant parmi les choix proposés par ces deux logiciels ?
Pour FileRoller, j'imagine que c'est .tar.xz, et pour 7zip c'est .7z avec LZMA, non ?

Edit : Une dernière chose, j'ai toujours entendu dire que compresser des photos ne servait à rien, qu'il n'y a quasiment aucun gain d'espace quelle que soit la méthode de compression utilisée, est-ce vrai ou est-ce une légende urbaine ?

Dernière modification par Heliox (Le 08/06/2012, à 13:09)

fabien26 · Le 08/06/2012, à 13:19

Oui par défaut le .7z et .tar.7z utilisent le format interne LZMA sous Linux comme sous Windows. C'est le format par défaut de ce type d'archives et c'est celui qui a le meilleur rapport Temps/Compression.

Le XZ offre des compressions quasi identiques à 7zip mais est bien plus rapide que 7zip quand on cherche à faire un .tar.*

Les .tar.xz sont décompressible sous Windows avec 7zip il me semble, donc ce format ne pose pas de problèmes pour les windowsiens.

Edit: Oui file-roller comme n'importe quel GUI de compression sous Linux utilise les paramètres par défaut des différents formats de compression (les tests avec -def dans le nom du fichier compressé reflètent le comportement des GUI)

Pour ce qui est de la compression des images et des vidéos. Tout comme pour la musique en .mp3/ogg/aac. Il n'y a aucun gain à les compresser car ces formats utilisent déjà en interne des compressions diverses et variés qui sont pour la plupart adaptés spécifiquement au format qu'ils traitent et qui sont donc bien plus performants. En gros c'est comme compresser un fichier compressé, ça n'offre aucun gain. Ça peut même faire perdre de la place ! (Il n'est pas rare que lorsque l'on compresse un fichier compressé) les descriptifs de contenu s’accumulent et donc le fichier gonfle.)

Dans la pratique j'ai pu quand même voir des résultats étonnants à compresser des fichiers .jpg et des .mp3. On peut parfois gagner quelques dizaines de Mo sur une très grosse bibliothèque. Mais on aurait plus vite fait de convertir directement ces fichiers dans un format plus performant (comme passer les .mp3 en .ogg).

Dernière modification par fabien26 (Le 08/06/2012, à 13:27)

The Uploader · Le 08/06/2012, à 13:49

fabien26 a écrit :

Mais on aurait plus vite fait de convertir directement ces fichiers dans un format plus performant (comme passer les .mp3 en .ogg).

Oui, mais tu perds en qualité audio dès que tu encode avec un format de compression avec perte, tel que Ogg Vorbis.

fabien26 · Le 08/06/2012, à 13:52

The Uploader a écrit :

fabien26 a écrit :
Mais on aurait plus vite fait de convertir directement ces fichiers dans un format plus performant (comme passer les .mp3 en .ogg).
Oui, mais tu perds en qualité audio dès que tu encode avec un format de compression avec perte, tel que Ogg Vorbis.

Je parles de MP3, les passer de MP3 à Ogg n'est pas une perte vu que l'original est déjà un format à perte. Après pour les formats sans perte, hors le Wav ils sont déjà compressé lossless. Le flac par exemple compresse très bien la musique. Bien mieux que si l'on faisait un .tar.xz contenant des wav et bien plus pratique à utiliser que décompresser puis lire.

The Uploader · Le 08/06/2012, à 13:56

fabien26 a écrit :

Je parles de MP3, les passer de MP3 à Ogg n'est pas une perte vu que l'original est déjà un format à perte.

Oui, mais ça c'est autre chose. N'importe quel format avec perte va augmenter la perte de données par rapport à l'original, ça fait partie de leur fonctionnement.

fabien26 · Le 08/06/2012, à 14:10

The Uploader a écrit :

fabien26 a écrit :
Je parles de MP3, les passer de MP3 à Ogg n'est pas une perte vu que l'original est déjà un format à perte.
Oui, mais ça c'est autre chose. N'importe quel format avec perte va augmenter la perte de données par rapport à l'original, ça fait partie de leur fonctionnement.

C'est là où tu te trompe, c'est bien plus complexe que cela. Un format avec perte n'est pas un format qui ajoute volontairement de la perte à chaque recompression. Bien entendu à chaque recompression des bizarreries vont s'ajouter c'est le syndrome du photocopieur, quand on photocopie une photocopie et que l'on photocopie cette photocopie, etc au fur et à mesure le tout deviendra bien moins beau. Mais on a de la marge avant que la destruction prenne le pas sur le gain de place dans le cas d'un passage par exemple d'un format d'ancienne génération à un nouveau format. Le passage de MP3 à Ogg permet de garder la même qualité perçue en gagnant environ 12 kb/s (pour un 128 kb/s)

The Uploader · Le 08/06/2012, à 14:15

Bien sûr qu'il y a de la marge avant que la perte ne devienne audible, dans la plupart des cas... Mais je préfère ne rien risquer (donc ne pas convertir).

fabien26 · Le 08/06/2012, à 14:19

The Uploader a écrit :

Bien sûr qu'il y a de la marge avant que la perte ne devienne audible, dans la plupart des cas... Mais je préfère ne rien risquer (donc ne pas convertir).

Je ne converti que quand j'ai besoin de place et que la différence de taille se fait ressentir. (et que la qualité reste la même). Mais je fais surtout ça avec les vidéos, la différence entre un Ogg et un Mp3 à qualité égale étant négligeable sur les disque dur d'aujourd'hui ... Sur un téléphone portable par contre !

Dernière modification par fabien26 (Le 08/06/2012, à 14:20)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 07/06/2012, à 19:18

Comparaison de compresseurs de données - LZO, Gzip, Bzip2, XZ

#2 Le 07/06/2012, à 20:16

Re : Comparaison de compresseurs de données - LZO, Gzip, Bzip2, XZ

#3 Le 07/06/2012, à 21:51

Re : Comparaison de compresseurs de données - LZO, Gzip, Bzip2, XZ

#4 Le 07/06/2012, à 22:24

Re : Comparaison de compresseurs de données - LZO, Gzip, Bzip2, XZ

#5 Le 08/06/2012, à 08:18

Re : Comparaison de compresseurs de données - LZO, Gzip, Bzip2, XZ

#6 Le 08/06/2012, à 13:04

Re : Comparaison de compresseurs de données - LZO, Gzip, Bzip2, XZ

#7 Le 08/06/2012, à 13:19

Re : Comparaison de compresseurs de données - LZO, Gzip, Bzip2, XZ

#8 Le 08/06/2012, à 13:49

Re : Comparaison de compresseurs de données - LZO, Gzip, Bzip2, XZ

#9 Le 08/06/2012, à 13:52

Re : Comparaison de compresseurs de données - LZO, Gzip, Bzip2, XZ

#10 Le 08/06/2012, à 13:56

Re : Comparaison de compresseurs de données - LZO, Gzip, Bzip2, XZ

#11 Le 08/06/2012, à 14:10

Re : Comparaison de compresseurs de données - LZO, Gzip, Bzip2, XZ

#12 Le 08/06/2012, à 14:15

Re : Comparaison de compresseurs de données - LZO, Gzip, Bzip2, XZ

#13 Le 08/06/2012, à 14:19

Re : Comparaison de compresseurs de données - LZO, Gzip, Bzip2, XZ

Pied de page des forums