Voilà mon problème,
aprés un tar -cjvf (archive + compression bzip2) d'un
répertoire de 593M je me retrouve bizarrement avec
une archive "compressée" de 595M .
J'ai donc à tout hasard relancer la commande et le résultat
est identique.
Je suis un peu perdu là , une idée ?
ps : le contenu du répertoire est principalement du flac
stocké sur une partoche en fat32 (???).
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Annie D.
françois wrote:
aprés un tar -cjvf (archive + compression bzip2) d'un répertoire de 593M je me retrouve bizarrement avec une archive "compressée" de 595M . ps : le contenu du répertoire est principalement du flac
Si le "flac" c'est ça :
"FLAC stands for Free Lossless Audio Codec. Grossly oversimplified, FLAC is similar to MP3, but lossless, meaning that audio is compressed in FLAC without any loss in quality. This is similar to how Zip works" (source: http://flac.sourceforge.net/)
Alors c'est normal, puisque c'est déjà compressé comme quasiment tous les formats multimédia maintenant.
françois wrote:
aprés un tar -cjvf (archive + compression bzip2) d'un
répertoire de 593M je me retrouve bizarrement avec
une archive "compressée" de 595M .
ps : le contenu du répertoire est principalement du flac
Si le "flac" c'est ça :
"FLAC stands for Free Lossless Audio Codec. Grossly oversimplified, FLAC
is similar to MP3, but lossless, meaning that audio is compressed in
FLAC without any loss in quality. This is similar to how Zip works"
(source: http://flac.sourceforge.net/)
Alors c'est normal, puisque c'est déjà compressé comme quasiment tous
les formats multimédia maintenant.
aprés un tar -cjvf (archive + compression bzip2) d'un répertoire de 593M je me retrouve bizarrement avec une archive "compressée" de 595M . ps : le contenu du répertoire est principalement du flac
Si le "flac" c'est ça :
"FLAC stands for Free Lossless Audio Codec. Grossly oversimplified, FLAC is similar to MP3, but lossless, meaning that audio is compressed in FLAC without any loss in quality. This is similar to how Zip works" (source: http://flac.sourceforge.net/)
Alors c'est normal, puisque c'est déjà compressé comme quasiment tous les formats multimédia maintenant.
françois
Annie D. wrote:
Si le "flac" c'est ça :
"FLAC stands for Free Lossless Audio Codec. Grossly oversimplified, FLAC is similar to MP3, but lossless, meaning that audio is compressed in FLAC without any loss in quality. This is similar to how Zip works" (source: http://flac.sourceforge.net/)
Oui c'est ça
Alors c'est normal, puisque c'est déjà compressé comme quasiment tous les formats multimédia maintenant.
c'est vrai que cela parait LOGIQUE de ne pouvoir obtenir plus de comression d'un fichier qui l'est déjà .
Merci encore.
Annie D. wrote:
Si le "flac" c'est ça :
"FLAC stands for Free Lossless Audio Codec. Grossly oversimplified, FLAC
is similar to MP3, but lossless, meaning that audio is compressed in
FLAC without any loss in quality. This is similar to how Zip works"
(source: http://flac.sourceforge.net/)
Oui c'est ça
Alors c'est normal, puisque c'est déjà compressé comme quasiment tous
les formats multimédia maintenant.
c'est vrai que cela parait LOGIQUE de ne pouvoir
obtenir plus de comression d'un fichier qui l'est déjà .
"FLAC stands for Free Lossless Audio Codec. Grossly oversimplified, FLAC is similar to MP3, but lossless, meaning that audio is compressed in FLAC without any loss in quality. This is similar to how Zip works" (source: http://flac.sourceforge.net/)
Oui c'est ça
Alors c'est normal, puisque c'est déjà compressé comme quasiment tous les formats multimédia maintenant.
c'est vrai que cela parait LOGIQUE de ne pouvoir obtenir plus de comression d'un fichier qui l'est déjà .
Merci encore.
Michel Tatoute
Le Sat, 18 Sep 2004 11:52:12 +0000, françois a écrit :
Annie D. wrote:
Si le "flac" c'est ça :
"FLAC stands for Free Lossless Audio Codec. Grossly oversimplified, FLAC is similar to MP3, but lossless, meaning that audio is compressed in FLAC without any loss in quality. This is similar to how Zip works" (source: http://flac.sourceforge.net/)
Oui c'est ça
Alors c'est normal, puisque c'est déjà compressé comme quasiment tous les formats multimédia maintenant.
c'est vrai que cela parait LOGIQUE de ne pouvoir obtenir plus de comression d'un fichier qui l'est déjà .
Oui, c'erst meme normal qu'il grossisse.
Merci encore.
Le Sat, 18 Sep 2004 11:52:12 +0000, françois a écrit :
Annie D. wrote:
Si le "flac" c'est ça :
"FLAC stands for Free Lossless Audio Codec. Grossly oversimplified, FLAC
is similar to MP3, but lossless, meaning that audio is compressed in
FLAC without any loss in quality. This is similar to how Zip works"
(source: http://flac.sourceforge.net/)
Oui c'est ça
Alors c'est normal, puisque c'est déjà compressé comme quasiment tous
les formats multimédia maintenant.
c'est vrai que cela parait LOGIQUE de ne pouvoir
obtenir plus de comression d'un fichier qui l'est déjà .
Le Sat, 18 Sep 2004 11:52:12 +0000, françois a écrit :
Annie D. wrote:
Si le "flac" c'est ça :
"FLAC stands for Free Lossless Audio Codec. Grossly oversimplified, FLAC is similar to MP3, but lossless, meaning that audio is compressed in FLAC without any loss in quality. This is similar to how Zip works" (source: http://flac.sourceforge.net/)
Oui c'est ça
Alors c'est normal, puisque c'est déjà compressé comme quasiment tous les formats multimédia maintenant.
c'est vrai que cela parait LOGIQUE de ne pouvoir obtenir plus de comression d'un fichier qui l'est déjà .
Oui, c'erst meme normal qu'il grossisse.
Merci encore.
Michel SIMIAN
Michel Tatoute wrote:
Annie D. wrote:
Si le "flac" c'est ça :
"FLAC stands for Free Lossless Audio Codec. Grossly oversimplified, FLAC is similar to MP3, but lossless, meaning that audio is compressed in FLAC without any loss in quality. This is similar to how Zip works" (source: http://flac.sourceforge.net/)
Oui c'est ça
Alors c'est normal, puisque c'est déjà compressé comme quasiment tous les formats multimédia maintenant.
c'est vrai que cela parait LOGIQUE de ne pouvoir obtenir plus de comression d'un fichier qui l'est déjà .
Oui, c'erst meme normal qu'il grossisse.
sauf si on force l'algo de compression à un autre compromis entre la vitesse de travail et le taux.
par défaut; gzip fournit un compromis qui peut-être amélioré et qui, meme sur des compressé, peut "gratter" quelques octets
-- L'Amer Michel
Michel Tatoute wrote:
Annie D. wrote:
Si le "flac" c'est ça :
"FLAC stands for Free Lossless Audio Codec. Grossly oversimplified, FLAC
is similar to MP3, but lossless, meaning that audio is compressed in
FLAC without any loss in quality. This is similar to how Zip works"
(source: http://flac.sourceforge.net/)
Oui c'est ça
Alors c'est normal, puisque c'est déjà compressé comme quasiment tous
les formats multimédia maintenant.
c'est vrai que cela parait LOGIQUE de ne pouvoir
obtenir plus de comression d'un fichier qui l'est déjà .
Oui, c'erst meme normal qu'il grossisse.
sauf si on force l'algo de compression à un autre
compromis entre la vitesse de travail et le taux.
par défaut; gzip fournit un compromis qui peut-être amélioré
et qui, meme sur des compressé, peut "gratter" quelques octets
"FLAC stands for Free Lossless Audio Codec. Grossly oversimplified, FLAC is similar to MP3, but lossless, meaning that audio is compressed in FLAC without any loss in quality. This is similar to how Zip works" (source: http://flac.sourceforge.net/)
Oui c'est ça
Alors c'est normal, puisque c'est déjà compressé comme quasiment tous les formats multimédia maintenant.
c'est vrai que cela parait LOGIQUE de ne pouvoir obtenir plus de comression d'un fichier qui l'est déjà .
Oui, c'erst meme normal qu'il grossisse.
sauf si on force l'algo de compression à un autre compromis entre la vitesse de travail et le taux.
par défaut; gzip fournit un compromis qui peut-être amélioré et qui, meme sur des compressé, peut "gratter" quelques octets
-- L'Amer Michel
Michel Tatoute
Le Sat, 18 Sep 2004 20:28:34 +0200, Michel SIMIAN a écrit :
Michel Tatoute wrote:$
[ file de message sur la compression de fichiers compressés ] Oui, c'erst meme normal qu'il grossisse.
sauf si on force l'algo de compression à un autre compromis entre la vitesse de travail et le taux.
par défaut; gzip fournit un compromis qui peut-être amélioré et qui, meme sur des compressé, peut "gratter" quelques octets
[ troll en émergence ]
<provoc> comme ça j'ai qu'a utiliser gzip répétitivement sur un fichier et il se réduira à 0 octets, mais avec toute l'info dedans. Génial ce compromis! tu peux nous en faire partager le source? </provoc>
Le Sat, 18 Sep 2004 20:28:34 +0200, Michel SIMIAN a écrit :
Michel Tatoute wrote:$
[ file de message sur la compression de fichiers compressés ]
Oui, c'erst meme normal qu'il grossisse.
sauf si on force l'algo de compression à un autre
compromis entre la vitesse de travail et le taux.
par défaut; gzip fournit un compromis qui peut-être amélioré
et qui, meme sur des compressé, peut "gratter" quelques octets
[ troll en émergence ]
<provoc>
comme ça j'ai qu'a utiliser gzip répétitivement sur un fichier et il se
réduira à 0 octets, mais avec toute l'info dedans. Génial ce compromis!
tu peux nous en faire partager le source?
</provoc>
Le Sat, 18 Sep 2004 20:28:34 +0200, Michel SIMIAN a écrit :
Michel Tatoute wrote:$
[ file de message sur la compression de fichiers compressés ] Oui, c'erst meme normal qu'il grossisse.
sauf si on force l'algo de compression à un autre compromis entre la vitesse de travail et le taux.
par défaut; gzip fournit un compromis qui peut-être amélioré et qui, meme sur des compressé, peut "gratter" quelques octets
[ troll en émergence ]
<provoc> comme ça j'ai qu'a utiliser gzip répétitivement sur un fichier et il se réduira à 0 octets, mais avec toute l'info dedans. Génial ce compromis! tu peux nous en faire partager le source? </provoc>
TiChou
Dans le message <news:, *Michel Tatoute* tapota sur f.c.o.l.configuration :
[ file de message sur la compression de fichiers compressés ] Oui, c'erst meme normal qu'il grossisse.
sauf si on force l'algo de compression à un autre compromis entre la vitesse de travail et le taux.
par défaut; gzip fournit un compromis qui peut-être amélioré et qui, meme sur des compressé, peut "gratter" quelques octets
[ troll en émergence ]
<provoc> comme ça j'ai qu'a utiliser gzip répétitivement sur un fichier et il se réduira à 0 octets, mais avec toute l'info dedans. Génial ce compromis! tu peux nous en faire partager le source? </provoc>
Dans le message <news:pan.2004.09.18.20.19.31.960545@alussinan.org>,
*Michel Tatoute* tapota sur f.c.o.l.configuration :
[ file de message sur la compression de fichiers compressés ]
Oui, c'erst meme normal qu'il grossisse.
sauf si on force l'algo de compression à un autre
compromis entre la vitesse de travail et le taux.
par défaut; gzip fournit un compromis qui peut-être amélioré
et qui, meme sur des compressé, peut "gratter" quelques octets
[ troll en émergence ]
<provoc>
comme ça j'ai qu'a utiliser gzip répétitivement sur un fichier et il se
réduira à 0 octets, mais avec toute l'info dedans. Génial ce compromis!
tu peux nous en faire partager le source?
</provoc>
Dans le message <news:, *Michel Tatoute* tapota sur f.c.o.l.configuration :
[ file de message sur la compression de fichiers compressés ] Oui, c'erst meme normal qu'il grossisse.
sauf si on force l'algo de compression à un autre compromis entre la vitesse de travail et le taux.
par défaut; gzip fournit un compromis qui peut-être amélioré et qui, meme sur des compressé, peut "gratter" quelques octets
[ troll en émergence ]
<provoc> comme ça j'ai qu'a utiliser gzip répétitivement sur un fichier et il se réduira à 0 octets, mais avec toute l'info dedans. Génial ce compromis! tu peux nous en faire partager le source? </provoc>
On Sat, 18 Sep 2004 14:31:51 +0200 Michel Tatoute wrote:
Oui, c'erst meme normal qu'il grossisse.
Par curiosité, le grossissement, il ne serait pas dû à tar (qui ajoute ses séparateurs et les métadonnées)?
Est-ce que gzip n'a pas un mécanisme pour éviter de perdre de la place? (quand il constate qu'il ne fait rien de bien, il se contente de recopier les données sans essayer de les compresser) Je confonds peut-être avec bzip2.
-- Jérémy JUST
On Sat, 18 Sep 2004 14:31:51 +0200
Michel Tatoute <tatoute@alussinan.org> wrote:
Oui, c'erst meme normal qu'il grossisse.
Par curiosité, le grossissement, il ne serait pas dû à tar (qui ajoute
ses séparateurs et les métadonnées)?
Est-ce que gzip n'a pas un mécanisme pour éviter de perdre de la
place? (quand il constate qu'il ne fait rien de bien, il se contente de
recopier les données sans essayer de les compresser)
Je confonds peut-être avec bzip2.
On Sat, 18 Sep 2004 14:31:51 +0200 Michel Tatoute wrote:
Oui, c'erst meme normal qu'il grossisse.
Par curiosité, le grossissement, il ne serait pas dû à tar (qui ajoute ses séparateurs et les métadonnées)?
Est-ce que gzip n'a pas un mécanisme pour éviter de perdre de la place? (quand il constate qu'il ne fait rien de bien, il se contente de recopier les données sans essayer de les compresser) Je confonds peut-être avec bzip2.
-- Jérémy JUST
no_spam
On Sun, 19 Sep 2004 02:08:13 +0200, Jérémy JUST wrote:
On Sat, 18 Sep 2004 14:31:51 +0200 Michel Tatoute wrote:
Oui, c'erst meme normal qu'il grossisse.
Par curiosité, le grossissement, il ne serait pas dû à tar (qui ajoute ses séparateurs et les métadonnées)?
Est-ce que gzip n'a pas un mécanisme pour éviter de perdre de la place? (quand il constate qu'il ne fait rien de bien, il se contente de recopier les données sans essayer de les compresser) Je confonds peut-être avec bzip2.
gzip et bzip2 compressent par blocs de taille fixe, je crois. Même s'ils se contentaient de recopier les données sans compresser, ils sont obligés de rajouter un header à chaque bloc pour indiquer que celui-ci n'est pas compressé. Le fichier résultant est donc plus gros que le fichier de départ.
On Sun, 19 Sep 2004 02:08:13 +0200, Jérémy JUST wrote:
On Sat, 18 Sep 2004 14:31:51 +0200
Michel Tatoute <tatoute@alussinan.org> wrote:
Oui, c'erst meme normal qu'il grossisse.
Par curiosité, le grossissement, il ne serait pas dû à tar (qui ajoute
ses séparateurs et les métadonnées)?
Est-ce que gzip n'a pas un mécanisme pour éviter de perdre de la
place? (quand il constate qu'il ne fait rien de bien, il se contente de
recopier les données sans essayer de les compresser)
Je confonds peut-être avec bzip2.
gzip et bzip2 compressent par blocs de taille fixe, je crois.
Même s'ils se contentaient de recopier les données sans compresser, ils
sont obligés de rajouter un header à chaque bloc pour indiquer que
celui-ci n'est pas compressé.
Le fichier résultant est donc plus gros que le fichier de départ.
On Sun, 19 Sep 2004 02:08:13 +0200, Jérémy JUST wrote:
On Sat, 18 Sep 2004 14:31:51 +0200 Michel Tatoute wrote:
Oui, c'erst meme normal qu'il grossisse.
Par curiosité, le grossissement, il ne serait pas dû à tar (qui ajoute ses séparateurs et les métadonnées)?
Est-ce que gzip n'a pas un mécanisme pour éviter de perdre de la place? (quand il constate qu'il ne fait rien de bien, il se contente de recopier les données sans essayer de les compresser) Je confonds peut-être avec bzip2.
gzip et bzip2 compressent par blocs de taille fixe, je crois. Même s'ils se contentaient de recopier les données sans compresser, ils sont obligés de rajouter un header à chaque bloc pour indiquer que celui-ci n'est pas compressé. Le fichier résultant est donc plus gros que le fichier de départ.
Jérémy JUST
On Sun, 19 Sep 2004 10:41:03 +0200 no_spam wrote:
gzip et bzip2 compressent par blocs de taille fixe, je crois.
bzip2 fait parfois autrement, pour éviter le « pire cas », d'après sa doc.
Expériences amusante: - prendre un fichier de quelques dizaines de Mo du même caractère (moi, j'ai fait avec 60 Mo d'espaces). - le compresser avec bzip2 -> fichier de quelques dizaines octets. - le compresser avec gzip -> fichier de quelques dizaines de kilo-octets - regarder le contenu du .gz; il est extrêmement répétitif, justement parce que gzip a travaillé par blocs indépendants, qui se compressent en la même chaîne. - compresser le .gz en .gz.gz -> fichier de quelques dizaines d'octets.
-- Jérémy JUST
On Sun, 19 Sep 2004 10:41:03 +0200
no_spam <l_indien_no_more_spams@magic.fr> wrote:
gzip et bzip2 compressent par blocs de taille fixe, je crois.
bzip2 fait parfois autrement, pour éviter le « pire cas », d'après sa
doc.
Expériences amusante:
- prendre un fichier de quelques dizaines de Mo du même caractère (moi,
j'ai fait avec 60 Mo d'espaces).
- le compresser avec bzip2 -> fichier de quelques dizaines octets.
- le compresser avec gzip -> fichier de quelques dizaines de
kilo-octets
- regarder le contenu du .gz; il est extrêmement répétitif, justement
parce que gzip a travaillé par blocs indépendants, qui se compressent en
la même chaîne.
- compresser le .gz en .gz.gz -> fichier de quelques dizaines d'octets.
gzip et bzip2 compressent par blocs de taille fixe, je crois.
bzip2 fait parfois autrement, pour éviter le « pire cas », d'après sa doc.
Expériences amusante: - prendre un fichier de quelques dizaines de Mo du même caractère (moi, j'ai fait avec 60 Mo d'espaces). - le compresser avec bzip2 -> fichier de quelques dizaines octets. - le compresser avec gzip -> fichier de quelques dizaines de kilo-octets - regarder le contenu du .gz; il est extrêmement répétitif, justement parce que gzip a travaillé par blocs indépendants, qui se compressent en la même chaîne. - compresser le .gz en .gz.gz -> fichier de quelques dizaines d'octets.
-- Jérémy JUST
Michel SIMIAN
Michel Tatoute wrote:
Michel Tatoute wrote:$
[ file de message sur la compression de fichiers compressés ]
Oui, c'erst meme normal qu'il grossisse.
sauf si on force l'algo de compression à un autre compromis entre la vitesse de travail et le taux.
par défaut; gzip fournit un compromis qui peut-être amélioré et qui, meme sur des compressé, peut "gratter" quelques octets
[ troll en émergence ]
<provoc> comme ça j'ai qu'a utiliser gzip répétitivement sur un fichier et il se réduira à 0 octets, mais avec toute l'info dedans. Génial ce compromis! tu peux nous en faire partager le source? </provoc>
<je réponds sans comprendre> fais donc des essais sur plusieurs fichiers en gzipant plusieurs fois et tu comprendras ce que j'ai voulu dire. Puis, après, man gzip. Et je n'ai jamais voulu dire que le gzip d'un gzip (ou le compressé d'un compressé) sera plus petit que l'original :
tout dépend des blocs par défaut et des paramètres de l'algo. </je réponds sans comprendre>
-- L'Amer Michel
Michel Tatoute wrote:
Michel Tatoute wrote:$
[ file de message sur la compression de fichiers compressés ]
Oui, c'erst meme normal qu'il grossisse.
sauf si on force l'algo de compression à un autre
compromis entre la vitesse de travail et le taux.
par défaut; gzip fournit un compromis qui peut-être amélioré
et qui, meme sur des compressé, peut "gratter" quelques octets
[ troll en émergence ]
<provoc>
comme ça j'ai qu'a utiliser gzip répétitivement sur un fichier et il se
réduira à 0 octets, mais avec toute l'info dedans. Génial ce compromis!
tu peux nous en faire partager le source?
</provoc>
<je réponds sans comprendre>
fais donc des essais sur plusieurs fichiers
en gzipant plusieurs fois et tu comprendras
ce que j'ai voulu dire.
Puis, après, man gzip.
Et je n'ai jamais voulu dire que le gzip
d'un gzip (ou le compressé d'un compressé)
sera plus petit que l'original :
tout dépend des blocs par défaut
et des paramètres de l'algo.
</je réponds sans comprendre>
[ file de message sur la compression de fichiers compressés ]
Oui, c'erst meme normal qu'il grossisse.
sauf si on force l'algo de compression à un autre compromis entre la vitesse de travail et le taux.
par défaut; gzip fournit un compromis qui peut-être amélioré et qui, meme sur des compressé, peut "gratter" quelques octets
[ troll en émergence ]
<provoc> comme ça j'ai qu'a utiliser gzip répétitivement sur un fichier et il se réduira à 0 octets, mais avec toute l'info dedans. Génial ce compromis! tu peux nous en faire partager le source? </provoc>
<je réponds sans comprendre> fais donc des essais sur plusieurs fichiers en gzipant plusieurs fois et tu comprendras ce que j'ai voulu dire. Puis, après, man gzip. Et je n'ai jamais voulu dire que le gzip d'un gzip (ou le compressé d'un compressé) sera plus petit que l'original :
tout dépend des blocs par défaut et des paramètres de l'algo. </je réponds sans comprendre>
