Недоархиватор SHAFF

[Shaos]

depack_getbyte() vs depack_getbits()
и далее сам цикл распаковки

да я смотрю:

Code: Select all

        while( (!stop) && success )
        {
                bits = depack_getbits(1,DEPACK_GETBITS_NEXT);

                if( 1&bits ) // %1<byte>
                {
                        byte = depack_getbyte(DEPACK_GETBYTE_NEXT);

как это работает, если внутри depack_getbyte написано вот это:

Code: Select all

// rewind - to the beginning of input stream, byte - next byte
// returns 0xFFFFFFFF if error (exhausted stream), otherwise byte (0..255)
ULONG depack_getbyte(ULONG operation)
{
        static ULONG position;
 ........................
        else if( operation==DEPACK_GETBYTE_NEXT )
        {
                if( position < wrk.inlen )
                {
                        return (ULONG)wrk.indata[position++];
                }
        }

каким таким волшебным образом байт (читаемый следом за битом) всегда выравнен на границу ULONG?...

[angry_troll]

А, простите, тип wrk.indata какой?

[angry_troll]

как это работает

Уже даже и не знаю, как объяснять...
Внутри гетбитса есть буфер битов... Они оттуда вынимаются, пока не кончатся. Как кончатся -- новый байтик (или ворд) подчитываются из *единственного* байтового потока.
Из него же (байтового потока) подчитываются и байты для ссылок, ежели таковые требуются.

[Shaos]

А, простите, тип wrk.indata какой?

байт? ну выровненость на границу байта всё равно непонятна

Code: Select all

mhmt-globals.h:	UBYTE * indata;     // to use in normal depacking process -- begins from input file data

как это работает

Уже даже и не знаю, как объяснять...
Внутри гетбитса есть буфер битов... Они оттуда вынимаются, пока не кончатся. Как кончатся -- новый байтик (или ворд) подчитываются из *единственного* байтового потока.
Из него же (байтового потока) подчитываются и байты для ссылок, ежели таковые требуются.

как? байты для ссылок могут начинаться где угодно - они не выровнены на границу байта, разве нет?
или там реально неиспользуемые дырки? на чтении невыровненного 1 бита и затем выровненного 1 байта можно до 7 бит потерять, что между ними пропускаются...

[angry_troll]

Я прям даже и не знаю, как ещё объяснить.
биты берутся ИЗ БУФЕРА длиной в 1 байт!
А не сразу из запакованного файла.
этот буфер ПОПОЛНЯЕТСЯ целым байтом когда опустошается
Поэтому байты берутся байтами выровненными, а биты -- битами, но из буфера.
Простейшая концепция, но основа всех (почти) депакеров на спектурме.

[Shaos]

Я прям даже и не знаю, как ещё объяснить.
биты берутся ИЗ БУФЕРА длиной в 1 байт!
А не сразу из запакованного файла.
этот буфер ПОПОЛНЯЕТСЯ целым байтом когда опустошается
Поэтому байты берутся байтами выровненными, а биты -- битами, но из буфера.
Простейшая концепция, но основа всех (почти) депакеров на спектурме.

хм, т.е. описание формата, на которые ты выше сослался, не соответствует действительности?
биты идут сами по себе, а байты - сами по себе и всё намешано? да - судя по всему так и есть - мрак...

[angry_troll]

Code: Select all

 Если нужен бит,а его уже нет (все 8 ко─
нчились) - то новый байт выбирается из по─
тока. Оттуда же выбираются и байты,обозна─
ченные  <byte> - но  только  после выборки
всех битов ссылки.

Ы?

[Shaos]

Как-то очень расплывчато написано...

Я подозреваю что отладить все вариации битовых команд и байтов в таком случае практически невозможно

[angry_troll]

А я как имевший дело с мегалзом, понимающий более-менее его распаковщик и т.д. -- это очень удачный формат хранения ссылок. Когда нужны биты -- вот они, а когда байты -- вон они, по указателю в регистре лежат.
Отлаживать там практически нечего, покрмере в этом месте.

[Shaos]

Ну да - может оно и быстрее декодит, но геморнее

Code: Select all

Original:
00000000  3f 7f 10 06 00 4b 00 44  00 a8 10 b9 5c 17 17 3a  |?....K.D....\..:|

MegaLZ:
00000000  3f f8 7f 10 06 00 4b d1  44 20 a8 71 b9 5c 17 e2  |?.....K.D .q.\..|

3F -> byte 3F
F8 ( 1111 1000 ):
1xxx xxxx -> byte 7F
x1xx xxxx -> byte 10
xx1x xxxx -> byte 06
xxx1 xxxx -> byte 00
xxxx 1xxx -> byte 4B
xxxx x000
D1 ( 1101 0001 ):
110x xxxx -> copy old byte FFF8+110=FFFE (-2) -> 00
xxx1 xxxx -> byte 44
xxxx 0001
20 ( 0010 0000 ):
00xx xxxx -> copy old byte FFF8+100=FFFC (-4) -> 00
xx1x xxxx -> byte A8
xxx0 0000
71 ( 0111 0001 ):
0xxx xxxx -> copy old byte FFF8+000=FFF8 (-8) -> 10
x1xx xxxx -> byte B9
xx1x xxxx -> byte 5C
xxx1 xxxx -> byte 17
xxxx 0001
E2 ( 1110 0010 ):
11xx xxxx -> copy old byte FF8+111=FFFF (-1) -> 17

[angry_troll]

Хм, чего геморного-то, правильно перемешать битстрим с байтстримом? Внутри (в пакере) всё равно все ссылки существуют далеко не в виде битовых последовательностей. А вывод их в нужном формате -- тривиальная (хоть и немного утомительная) писанина. Проверить можно просто -- распаковкой нативным Z80-депакером.

[Shaos]

Вот так пока выходит (отсортировал по степени сжатия):

Code: Select all

 49179 zx48k1.sna
  1023 zx48k1.sna.mlz
   930 zx48k1.sna.hrm
   718 zx48k1.zip
   604 zx48k1.rar
   594 zx48k1.sna.gz
   590 zx48k1.SNAFF <<<<< SHAFF0
   576 zx48k1.sna.xz
   535 zx48k1.sna.bz2
   502 zx48k1.sna.hst
   290 zx48k1.sna.ex2

 49179 jswilly16k.sna
  7784 jswilly16k.SNAFF <<<<< SHAFF0
  6901 jswilly16k.sna.bz2
  6826 jswilly16k.sna.mlz
  6767 jswilly16k.sna.hrm
  6708 jswilly16k.zip
  6570 jswilly16k.sna.gz
  6355 jswilly16k.rar
  6230 jswilly16k.sna.hst
  5978 jswilly16k.sna.ex2
  5956 jswilly16k.sna.xz

 49179 chess16k.sna
  7921 chess16k.sna.bz2
  7752 chess16k.sna.mlz
  7702 chess16k.sna.hrm
  7662 chess16k.SNAFF <<<<< SHAFF0
  7481 chess16k.zip
  7378 chess16k.sna.gz
  7226 chess16k.rar
  7066 chess16k.sna.hst
  6860 chess16k.sna.xz
  6707 chess16k.sna.ex2

[Shaos]

Все - допилил декодер формата SHAFF0 - все работает
Причем получившийся файл меньше 1000 строк:

github.com/shaos/shaff/blob/master/shaff.c

Все что насжимал вчера сегодня успешно разжалось (сверял MD5)

Code: Select all

SHAFF v1.0alpha (C) 2013,2017 A.A.Shabarshin <me@shaos.net>


Usage:
	shaff [options] filename

Encoding options:
	-0 to use SHAFF0 file format (by default)
	-1 to use SHAFF1 file format
	-b to save blocks as separate files
	-lN to limit length of matches (by default 2 for SHAFF1 and 4 for SHAFF0)

Decoding options:
	-d to decode SHAFF0 or SHAFF1 compressed file to file
	-c to decode SHAFF0 or SHAFF1 compressed file to screen

Следом буду прикручивать битопоточный SHAFF1 (или сначала ускорением сжатия заняться?)

[Shaos]

Планы на будущее:

SHAFF2 - формат с общей таблицей Хаффмана для литералов всего файла (формат ссылок остаётся таким же как в SHAFF1)

SHAFF3 - формат где у каждого 16КБ блока имеется своя таблица Хаффмана, включающая 1,2 и 3-символьные литералы, а также ссылки (этот формат должен побить всех самодельщиков : )

Кроме этого последний формат может стать полноценным архиватором, когда в один архив могут быть добавлены несколько файлов...

[angry_troll]

(этот формат должен побить всех самодельщиков : )

Главное ещё чтоб exomizer побил.

Кстати, если надо сжать несколько /разных/ блоков, например графика, музло, код, то если их сжимать exomizerом по отдельности -- будет выигрыш по сравнению с тем, если их сжимать одним конкатенированным куском.

кстати, почему exomizerа нет в твоих сравнивалках?

upd: а заодно какихнить crinklerов/шринклеров?