Algoritmo de compresión de código abierto con los puntos de control

Question

Estoy trabajando en C++ con gcc 4.5.0 y msvc8/9.

Me gustaría poder comprimir un archivo (10 Gb), luego abrir este archivo con mi aplicación.

Sin embargo, el contenido del archivo es tal que no necesariamente necesito todo dentro de ellos cada vez que los uso.

Así, por ejemplo, una vez abro uno de estos archivos comprimidos y decido que quiero buscar el 95% del camino sin cargarlo. Con algoritmos de compresión como gzip, esto no es posible: debo descomprimir el primer 95% del archivo, antes de poder descomprimir el último 5%.

So, are they any libraries similar to gzip, that are open source 
and available for commercial use, that have built in check points, 
to re-sync the decompression stream? 

He pensado que tal vez un códec de audio sin pérdida podría hacer el truco. Sé que algunos de estos algoritmos tienen puntos de control para que pueda buscar a través de un archivo de música y no tenga que esperar mientras se descomprime todo el contenido del archivo de música. ¿Hay inconvenientes con el uso de un códec de audio para datos de/compresión?

Gracias!

Answer 1

bzip2 es gratis y de código abierto, y tiene implementaciones de biblioteca disponibles. Está basado en bloques, por lo que puedes descomprimir solo las partes que necesitas. Sin embargo, si necesita buscar una ubicación particular en el archivo descomprimido, puede necesitar construir un índice simple sobre todos los bloques bzip2, para permitirle determinar cuál contiene la dirección que necesita.

gzip, aunque basado en secuencias, se puede restablecer en límites de bloques arbitrarios. La concatenación de cualquier cantidad de flujos gzip es en sí misma una corriente gzip válida, por lo que podría operar fácilmente gzip en un modo de compresión de bloques sin romper la compatibilidad con los descompresores existentes, también.

Answer 2

No estoy seguro de open-source, pero ha habido/hay un buen número de programas que hacen esto. Si la entrada es estática, es bastante trivial: elija un tamaño de bloque fijo y reinicie el compresor después de comprimir esa cantidad de datos de entrada.

Si el contenido es dinámico, las cosas se ponen un poco más feas, porque cuando cambia el contenido de un bloque de entrada, eso generalmente cambiará su tamaño. Hay al menos dos formas de solucionar esto: una es insertar una pequeña cantidad de relleno entre bloques, para que los cambios pequeños puedan acomodarse en el lugar (por ejemplo, lo que comenzó como un bloque de entrada de 64 K se redondea a un número integral de Bloques comprimidos de 512 bytes). El segundo es crear un índice para mapear desde bloques comprimidos hasta bloques descomprimidos. Estoy bastante seguro de que una solución práctica normalmente usará ambas cosas.

Answer 3

Un enfoque simple sería cortar el contenido sin comprimir en "bloques" y comprimir cada uno de forma independiente. No se comprimirán tan bien (ya que no se "compartirá" entre los bloques), pero puede descomprimir bloques de forma independiente.

"Cuadros clave" en video comprimido es una especie de caso especial de este enfoque general.

Answer 4

http://sourceforge.net/projects/gzx