ZONA DE PRUEBAS

Muchas gracias.

Jojojojo estoy flipando! a esto si que se le puede llamar "anomalía". El rar4 de toda la vida machacando a los mejores compresores del momento.
Lo cachondo del asunto es que tanto en rar4 como en rar5 se emplea el mismo método (m5:22) pero la diferencia de tamaño es increible (756.327 vs 1.286.984)

Yo creo que esto es lo bastante importante como para enviar un mensaje a los responsables del winrar ¿no?

En serio, habría que ver qué parámetros se han usado para comprimir. Puede que el RAR5 tenga unos parámetros por defecto algo menos agresivos que el RAR4.

Los que más van a influir van a ser los archivos sólidos. En ese sentido RAR solo permite activar/desactivar, 7z permite decir el tamaño de los bloques sólidos y bz2 suele ser sólido siempre (porque en realidad suele ser .tar.bz2). Por detras de esto, tamaño de diccionario (que aumenta y mucho los requerimientos de memoria para comprimir y extraer) y tamaño de palabra.

Otro tema (que no toca a los ficheros que estáis comprimiendo) es que al menos WinRAR agrupa los ficheros por extensión cuando hace archivos sólidos (en 7zip 15 y posteriores hay que poner el parámetro qs para que lo haga). La teoría es que al tener los ficheros similares juntos, es más probable encontrar datos repetidos juntos y el diccionario funciona mejor. No sé si el resto de compresores que hacen ficheros sólidos también aplican este proceso (y en este caso no influye al ser todos los ficheros del mismo tipo), pero el criterio de ordenación también puede influir (algo) en el resultado.

Y, por último, está el tema de que algunos compresores parecen preferir ciertos tipos de datos. Hay compresores que en general no son los mejores, pero cuando se enfrentan a ciertos tipos de ficheros barren a la competencia.

Acabo de hacer pruebas y son bastante curiosas, el fotograma de BIG BANG THEORY se comprime peor en jZip (1.124.312 bytes) que en RAR4, pero un fotograma de mi animacion comprime mejor en jZIP (446.466 bytes) que en RAR4 (531.800 bytes) y la animacion completa en RAR4 con archivo solido 347.115.633 bytes.

1124658 con el 7z, linux y esto que es lo que uso habitualmente:

7z a -t7z -m0=lzma2 -mx=9 -mfb=128 -md=128m -ms=on -mmt=1

Se podría mejorar con mas diccionario y alguna otra cosilla supongo. Recordad que cuantos mas núcleos mas rápido pero mas tamaño y comprimiendo pelis también pierdes calidad.

Skuall escribió:Se podría mejorar con mas diccionario y alguna otra cosilla supongo. Recordad que cuantos mas núcleos mas rápido pero mas tamaño y comprimiendo pelis también pierdes calidad.

Comprimir pelis en 7Z pierden calidad???

No sé muy bien la razón del comentario de Skuall, puesto que 7-Zip y cualquier otro compresor sin pérdidas de los que hemos estado hablando en este hilo, no se utilizan comúnmente para comprimir vídeo. Y si llegasen a usarse, meramente con fin de archivar una película, para darle una integridad CRC o partirla en trozos, obviamente el contenido sería íntegro y no se pierde calidad.

Creo que Skuall está mezclando conceptos. Los compresores con pérdidas, ya sean de la familia MPEG como MPEG-1, MPEG-2, MPEG 4 ASP, MPEG-4 AVC o MPEG-H HEVC, ya sean de On2/Google como VP6, VP7, VP8 o VP9, o de Microsoft como WMV, pues como su nombre indica no mantiene la calidad íntegra del original. Igualmente pasa en la compresión de audio, que hay modelos de compresión sin pérdidas como FLAC, ALAC, APE, TTA, DTS-HD ... y luego hay modelos de compresión psicoacústica con pérdidas, como MP2, MP3, Vorbis OGG, AC3, AAC, WMA...

No conviene confundir al personal con estas cosas.

Sorry. Esta mal redactado y no se me entiende. Lo que quería decir es que no useis threads para hacer este tipo de pruebas, ni ninguna prácticamente.

A note on threads:

https://birds-are-nice.me/ipfs/QmU7sznS ... 264_5.html

Skuall escribió:no useis threads para hacer este tipo de pruebas, ni ninguna prácticamente.

A note on threads:

https://birds-are-nice.me/ipfs/QmU7sznS ... 264_5.html

Realmente lo que dice ese articulo es que codificar video con 8 o mas hilos puede perjudicar notablemente la calidad del video por la propia naturaleza del codec x265 en contra de si se codifica con 4 hilos o menos, pero eso no tiene nada que ver con la compresion sin perdida de tipos de datos variopintos. Por tanto usar multiples hilos en la compresion de datos sin perdida no tiene porque influir en la eficiencia de la compresion y si en el tiempo que tarda en realizarse esta.

Pero es que si que influye. Esto es una simple prueba con un bin de PS2 y la orden anterior variando el número de cores-threads (-mmt) en un AMD 8350:

localhost ~ # ls -la /mnt/compartido/LEGORacers2CD.*
-rw-r--r-- 1 root root 488457873 mar 14 22:07 /mnt/compartido/LEGORacers2CD.7z
-rw-r--r-- 1 root root 488459582 mar 14 21:53 /mnt/compartido/LEGORacers2CD.7z2
-rw-r--r-- 1 root root 488590805 mar 14 22:31 /mnt/compartido/LEGORacers2CD.7z4
-rw-r--r-- 1 root root 488590805 mar 14 22:39 /mnt/compartido/LEGORacers2CD.7z6
-rw-r--r-- 1 root root 488590805 mar 14 22:43 /mnt/compartido/LEGORacers2CD.7z8
-rw-r--r-- 1 root root 631434384 sep 28 2001 /mnt/compartido/LEGORacers2CD.bin

El número después de la z es el número de núcleos. Si el archivo hubiera sido mas grande también hubiera habido diferencias en el de 6 y 8 cores.

Mas rápido pero el archivo resultante ocupa mas.

Lo que dice Skuall es cierto, la calidad de compresión y tamaño del video pueden ser peor (dependiendo del codec de video) cuantos más nucleos de cpu se usen.
Y también puede ocurrir algo parecido, pero sólo en tamaño, cuando comprimes en 7z. Es por eso que yo tengo configurado el 7z para que sólo use un nucleo.