Bueno, te explico un poco comparando la manera matemática de como funcionan generalmente y luego como yo he llegado a entenderlo. Mi fuerte no son los algoritmos pero con los años y tras leer un poco, de lo poco que me ha llegado a interesar, he entendido la base creo. Y si estoy equivocado y alguien me corrige, será un conocimiento nuevo muy agradecido
.
Todo algoritmo de compresión puede tener pérdidas... En algunos las pérdidas es la clave de la compresión, cuanto menos material, al ser posible el mas irrelevante, menos espacio ocupan... Es lo que sucede con el MP3, JPEG en imagen y demás... Que se basan en eliminar calidad ganando mas memoria. Esto da lugar a archivos apenas corruptos, puesto que en el proceso de compresión ves lo que se pierde y si te beneficia esa pérdida o no.
En cambio con los algoritmos de compresión sin pérdida es diferente. La condición de si se producirá una pérdida depende principalmente del contenido que vayas a comprimir (mas complejo como volúmenes virtuales, binarios... ) a simples textos... Y del ratio que quieras comprimirlo.
Explicándome mejor... Imaginemos que queremos comprimir un volumen cifrado de Truecrypt, y luego aparte un archivo de texto.
Hagamos el ejemplo de que lo abrimos con un editor en hexadecimal y el contenido es algo así:
"7y-#+€-72+%&38*+......"
El algoritmo de cifrado, al intentar comprimir esto, tendrá una tolerancia limitada a operaciones simples, por ejemplo si tenemos en una cadena siete sietes, o caracteres repetidos, se limitará ha hacer una operación que al descomprimirlo, el algoritmo pueda generar la misma cadena sin problemas.
En este punto, si aumentamos el ratio de compresión, se aplicarán operaciones mas complejas, operaciones que el algoritmo quizás no tolere dada la complejidad de lo que vas a comprimir y lo estipulado en el algoritmo... Arriesgando a que al comprimirlo, genere alguna cadena defectuosa corrompiendolo.
Un ejemplo es probando a comprimir al máximo con 7zip algo complejo... Lo que consigues en un archivo de 4GB es sacar solamente 200M de memoria menos, y si aumentas el diccionario del algoritmo, puede que logres 400M, pero al ser un archivo de composición compleja, lo mas probable es que quede corrupto al descomprimirlo.
En cambio, por contra, si comprimimos un archivo de texto (algo morfológicamente mas simple), y en el cual se produzcan muchas repeticiones de palabras, y demás... Aunque comprimamos con un ratio muy alto, tenemos menor probabilidad de que quede corrupto, puesto que el contenido a comprimir es mas simple y dispone de muchas repeticiones, funcionando el algoritmo mucho mejor.
Si comprimes un archivo de 4GB de texto, el resultado sera un archivo de aproximadamente 1GB o menos incluso, y con pocas probabilidades de corrupción.
El ejemplo que has dicho tu con una variable "double" es lo mas acertado a mi explicación.
Un pequeño fallo en una operación por exponer un valor no estipulado en el algoritmo, o que suceda un desbordamiento de alguna variable omitiendo algún dato, es suficiente para corromperlo.
Y ahí entra en juego mayormente la complejidad del archivo a comprimir, y el forzar un ratio mayor al que mas o menos por lógica, la morfología del archivo y el algoritmo toleren...
Por eso siempre viene la opción en los compresores, la mas básica como predeterminada... Las demás las dejan a elección porque dependiendo del archivo no te pueden asegurar mayormente lo que sucederá.
Mi deducción es si vas a usar un ratio alto, y es algo medianamente importante, cuando se comprima, descomprimelo y comprueba que tal funciona el resultado...
No se si me he explicado bien, si me he equivocado y alguien me corrige perfecto, pero con lo que he leído con el tiempo y demás es la deducción lógica que he encontrado, y por pruebas propias.
Espero te sirva. Cualquier cosa comenta.
Un saludo
Autor
En línea
