06.04.2006 19:48
[#1]
XPK problem
Testował ktoś subliby. Niektóre sprawiają kłopoty. Kiedyś używając A1200 nic nie zauważyłem, ale teraz mam tylko UAE i zacząłem pisać depaker do xpk (bez szyfrowania). Przy testach używałem xpkKnighta i subliby z aminetu używając różnych ustawień i pojawiły się przekłamania przy dużych plikach (ok. 2 MB). Subliby sprawiające problemy to: DMCB (kaszana), MASH, ILZR, SHRI (przy zmianie chunka na większy). Powiesić się lubią: HUFF, HFMN, LZWx, FRLE, FBR2. Mógłby to ktoś przetestować na prawdziwej Amidze, emulator może być do kitu (zwłaszcza FPU). No i czy ktoś ma subliby: PPMQ, LZCB i inne rzadkie.
08.04.2006 08:16
[#5]
Re: XPK problem
@Phibrizzo, post #4
Jestem oczywiście zainteresowany. Ja mam 38 sublibów nie licząc tych dwóch i nie licząc szyfrujących, no i bez dwóch opartych na LZX (te są na aminecie). W spisie znalazłem jeszcze takie, których nie mam: TDCS, DMCI, DMCD, DMCU, ZENO, FRHT. Jeśli ktoś coś o nich wie, niech da znać.
13.01.2011 23:45
[#8]
Re: XPK problem
@cholok, post #7
Poszukuję bibliotek
xpkTLTA.library by Stephan Fuhrmann
xpkDMCI.library by André Osterhues
xpkDMCU.library by André Osterhues
xpkDMCD.library by André Osterhues
xpkFRHT.library by Sebastiam Mulenke
xpkCYB1.library by Alexis Nasr
xpkCYB2.library by Alexis Nasr
xpkFBR2.library by Miguel Fides
xpkLZBS.library by Miguel Fides
xpkLZW2.library by Miguel Fides
xpkLZW3.library by Miguel Fides
xpkLZW4.library by Miguel Fides
xpkLZW5.library by Miguel Fides
xpkSLZ3.library by Miguel Fides
xpkTDCS.library by Niels Fröhling
xpkLIN1.library by Gerhard Tuenkler
xpkLIN2.library by Gerhard Tuenkler
xpkLIN3.library by Gerhard Tuenkler
xpkLIN4.library by Gerhard Tuenkler
Jeśli ktoś takowe posiada proszę o przesłanie na maila lub info gdzie mogę je znaleźć.
xpkTLTA.library by Stephan Fuhrmann
xpkDMCI.library by André Osterhues
xpkDMCU.library by André Osterhues
xpkDMCD.library by André Osterhues
xpkFRHT.library by Sebastiam Mulenke
xpkCYB1.library by Alexis Nasr
xpkCYB2.library by Alexis Nasr
xpkFBR2.library by Miguel Fides
xpkLZBS.library by Miguel Fides
xpkLZW2.library by Miguel Fides
xpkLZW3.library by Miguel Fides
xpkLZW4.library by Miguel Fides
xpkLZW5.library by Miguel Fides
xpkSLZ3.library by Miguel Fides
xpkTDCS.library by Niels Fröhling
xpkLIN1.library by Gerhard Tuenkler
xpkLIN2.library by Gerhard Tuenkler
xpkLIN3.library by Gerhard Tuenkler
xpkLIN4.library by Gerhard Tuenkler
Jeśli ktoś takowe posiada proszę o przesłanie na maila lub info gdzie mogę je znaleźć.
14.01.2011 08:04
[#10]
Re: XPK problem
@cholok, post #9
Zostały jeszcze:
xpkTLTA.library by Stephan Fuhrmann
xpkDMCI.library by André Osterhues
xpkDMCU.library by André Osterhues
xpkDMCD.library by André Osterhues
xpkFRHT.library by Sebastiam Mulenke
xpkTDCS.library by Niels Fröhling
xpkLIN1.library by Gerhard Tuenkler
xpkLIN2.library by Gerhard Tuenkler
xpkLIN3.library by Gerhard Tuenkler
xpkLIN4.library by Gerhard Tuenkler
Dzięki cholok
xpkTLTA.library by Stephan Fuhrmann
xpkDMCI.library by André Osterhues
xpkDMCU.library by André Osterhues
xpkDMCD.library by André Osterhues
xpkFRHT.library by Sebastiam Mulenke
xpkTDCS.library by Niels Fröhling
xpkLIN1.library by Gerhard Tuenkler
xpkLIN2.library by Gerhard Tuenkler
xpkLIN3.library by Gerhard Tuenkler
xpkLIN4.library by Gerhard Tuenkler
Dzięki cholok
14.01.2011 11:12
[#13]
Re: XPK problem
@HOŁDYS, post #12
rozne algorytmy do roznych rodzajow plikow , dane,text,bin,obraz,muzyka,8svx,txt,doc itp
To, aż takie kolosalne są różnice w kompresji różnych plików, że jest to takie ważne?
Chyba, że chodzi o sztukę dla sztuki - jakieś demo, etc. Musi się zmieścić w określonej wielkości pliku. I chyba sobie sam odpowiedziałem na to pytanie
14.01.2011 11:57
[#15]
Re: XPK problem
@Tomski, post #13
Chyba, że chodzi o sztukę dla sztuki - jakieś demo, etc. Musi się zmieścić w określonej wielkości pliku. I chyba sobie sam odpowiedziałem na to pytanie
Bo to jest sztuka dla sztuki.
Implodera i samorozpakowujące się archiwa PP używałem na A500 i pluskwie.
XPK używałem na A1200 ale to były czasy dysków 100-200MB.
Pierwszy dysk twardy w A1200 miałem o pojemności 170MB i był zapchany po instalacji programów które chciałem obejrzeć.
Kolejny dysk w tym kompie to było 500MB i na tym dysku wycofałem się z kompresji, ważniejszy stał się czas uruchamiania programów od zajętości HD.
Dzisiaj kiedy rekordzista ma w klasyku 750GB a dysk 4GB jest czymś normalnym jest to już tylko zabawa.
Pozdrawiam
14.01.2011 12:20
[#16]
Re: XPK problem
@RadoslawF, post #15
przy 4 GB na A600 staram sie wszystko miec w formie rozpakowanej...
z drugiej storny Amiga z dyskiem twardym i pamiecia fast ram rozwija skrzydla i spokojnie mozna ja uzytkowac :D .. na A500 modulow staram sie juz nie sluchac. najmniej uzywam A1200 desktop z 1260/80 64 MB
z drugiej strony niezle umieli upchac danych na glupiej zadkiej dyskietce DD :)
Ostatnia modyfikacja: 14.01.2011 12:21:06
z drugiej storny Amiga z dyskiem twardym i pamiecia fast ram rozwija skrzydla i spokojnie mozna ja uzytkowac :D .. na A500 modulow staram sie juz nie sluchac. najmniej uzywam A1200 desktop z 1260/80 64 MB
z drugiej strony niezle umieli upchac danych na glupiej zadkiej dyskietce DD :)
Ostatnia modyfikacja: 14.01.2011 12:21:06
14.01.2011 16:23
[#18]
Re: XPK problem
@Tomski, post #13
To, aż takie kolosalne są różnice w kompresji różnych plików, że jest to takie ważne?
Różnice są znaczne - przykład dla modka. Dziś to nie ma żadnego znaczenia - ale kiedyś, gdy miało się dysk ~100MB oznaczało to różnicę kilkuset modułów na partycji, w zależności czy się pakowało (i czym), czy trzymało się modki niespakowane.
P.S. Tak sobie przypomniałem: w przypadku modułów o rozmiarze do ~110 kB lepiej było używać xpkSQSH. Przy modach o większym rozmiarze (tak jak na obrazku) lepsza była xpkCRMS. Miałem nawet napisany specjalny skrypt, który pakował wskazane moduły jedną z tych bibliotek, w zależności od rozmiaru modułu.
Ostatnia modyfikacja: 14.01.2011 16:28:52
Różnice są znaczne - przykład dla modka. Dziś to nie ma żadnego znaczenia - ale kiedyś, gdy miało się dysk ~100MB oznaczało to różnicę kilkuset modułów na partycji, w zależności czy się pakowało (i czym), czy trzymało się modki niespakowane.
P.S. Tak sobie przypomniałem: w przypadku modułów o rozmiarze do ~110 kB lepiej było używać xpkSQSH. Przy modach o większym rozmiarze (tak jak na obrazku) lepsza była xpkCRMS. Miałem nawet napisany specjalny skrypt, który pakował wskazane moduły jedną z tych bibliotek, w zależności od rozmiaru modułu.
Ostatnia modyfikacja: 14.01.2011 16:28:52
14.01.2011 21:57
[#19]
Re: XPK problem
@tom256, post #10
Przejrzałem na piechotę AmigaFuture81, Magazyn Amiga CD-ROM, oraz covery Magazynu Amiga od 12 do 7 włącznie wraz z specjalnym wydaniem CD-ROM z bibliotekami i nie udało mi się znaleźć powyższych bibliotek
. Była cała masa innych ale tych co wypisałeś nie było. W najbliższym czasie postaram się jeszcze przeszukać pozostałe 6 płytek z coverów MA(od 6 do 1).
. Była cała masa innych ale tych co wypisałeś nie było. W najbliższym czasie postaram się jeszcze przeszukać pozostałe 6 płytek z coverów MA(od 6 do 1).14.01.2011 23:06
[#20]
Re: XPK problem
@Tomski, post #19
Marne są szanse, że coś znajdziesz, bo biblioteki z serii DMxx są shareware i dostępne były od autora za opłatą, podobnie z LINx, te są także shareware dołączane do pakera Lino. Pozostałe są może i za darmo, ale pewnie dołączane do programów. Te, co wysłałem były dołączone do dema Wildfire 5, które kiedyś było na aminecie, a już nie ma. Przeszukiwanie katalogu libs jest więc mało efektywne.
12.05.2013 13:19
[#21]
Re: XPK problem
@cholok, post #20
Poprawiłem kilka bibliotek:
LZW2 - ten pakował poprawnie, ale usunąłem wymagania co do KS3.0.
LZW3 - przekłamywał dane, dekoder jest identyczny jak w LZW2, ale pakuje lepiej ze względu na lepszy hashing.
LZW4 - przekłamywał dane i dziurawił pamięć (złe alokacje), przerobiłem pakera z TDCS, więc pakuje nieco lepiej.
LZW5 - jak wyżej, jest to bardzo podobny paker tylko z ograniczonym hashingiem.
TDCS - pakował poprawnie, ale usprawniłem nieco użycie rejestrów i dałem lepszy depacker.
LZBS - przekłamywał dane w specyficznym przypadku. Jest bardzo wolny, ponieważ nie używa hashingu.
FBR2 - przekłamywał dane w specyficznym przypadku. Poprawiłem i napisałem nowszą wersję pakera z bardziej optymalną kompresją.
Wszystkie powyżej miały nieprawidłowo wypełnione struktury xpkinfo, nie sprawdzały konfiguracji CPU i KS, a większość wymaga 020 i czasem KS3.0 (memory pools).
Cosmos niektóre z powyższych optymalizował, ale nie naprawiał, więc złe biblioteki są zoptymalizowane, ale dalej złe.
LZW2 - ten pakował poprawnie, ale usunąłem wymagania co do KS3.0.
LZW3 - przekłamywał dane, dekoder jest identyczny jak w LZW2, ale pakuje lepiej ze względu na lepszy hashing.
LZW4 - przekłamywał dane i dziurawił pamięć (złe alokacje), przerobiłem pakera z TDCS, więc pakuje nieco lepiej.
LZW5 - jak wyżej, jest to bardzo podobny paker tylko z ograniczonym hashingiem.
TDCS - pakował poprawnie, ale usprawniłem nieco użycie rejestrów i dałem lepszy depacker.
LZBS - przekłamywał dane w specyficznym przypadku. Jest bardzo wolny, ponieważ nie używa hashingu.
FBR2 - przekłamywał dane w specyficznym przypadku. Poprawiłem i napisałem nowszą wersję pakera z bardziej optymalną kompresją.
Wszystkie powyżej miały nieprawidłowo wypełnione struktury xpkinfo, nie sprawdzały konfiguracji CPU i KS, a większość wymaga 020 i czasem KS3.0 (memory pools).
Cosmos niektóre z powyższych optymalizował, ale nie naprawiał, więc złe biblioteki są zoptymalizowane, ale dalej złe.
12.05.2013 14:24
[#22]
Re: XPK problem
@cholok, post #21
Może na temat xpk wypowiem się z okazji innej obserwacji. Robiąc kompilację własnego systemu mając modki do słuchania pochodzace ze Scenexplorer (spakowane xpk) potrzebowałem programu który odtwarzałby te moduły w rachubę wchodził Hippoplayer który rozpakowuje te pliki do pamięci i odtwarza lub xpkatana program ten działa na podobnej zasadzie co hippoplayer rozpakowuje modki do pamięci i ustawiłem aby rozpakowane gry przechowywało w pamięci przez 5 s po czym kasowało ogólnie bardzo podobało mi się to rozwiązanie jednak musiałem z niego zrezygnować gdyż powodowało to problemy z uruchamianiem gier wywałao jakieś błędy a szkoda...
25.05.2013 12:44
[#24]
Re: XPK problem
@BULI, post #23
Kolejne poprawki:
RLEN, CBR0 - proste pakery, były poprawne, ale nie optymalne, teraz nieco lepiej kompresują.
DLTA - widać, że to niedokończona biblioteka, usunąłem kilka niepotrzebnych rzeczy, ciekawostką jest, że może kodować na hasło, ale faktycznie nie koduje, więc wpisanie byle jakiego hasła przy dekodowaniu odcyfruje "zakodowany" plik.
ILZR - tu był dość specyficzny i trudny do znalezienia błąd, który powodował w specyficznym przypadku utratę danych. Paker także był nieoptymalny. Aha, usunąłem instrukcje dla 020, ponieważ paker używał ich w liczbie 3.
Ostatnia aktualizacja: 25.05.2013 12:45:03 przez cholok
RLEN, CBR0 - proste pakery, były poprawne, ale nie optymalne, teraz nieco lepiej kompresują.
DLTA - widać, że to niedokończona biblioteka, usunąłem kilka niepotrzebnych rzeczy, ciekawostką jest, że może kodować na hasło, ale faktycznie nie koduje, więc wpisanie byle jakiego hasła przy dekodowaniu odcyfruje "zakodowany" plik.
ILZR - tu był dość specyficzny i trudny do znalezienia błąd, który powodował w specyficznym przypadku utratę danych. Paker także był nieoptymalny. Aha, usunąłem instrukcje dla 020, ponieważ paker używał ich w liczbie 3.
Ostatnia aktualizacja: 25.05.2013 12:45:03 przez cholok
30.05.2013 23:04
[#26]
Re: XPK problem
@APC74, post #25
Zgłosić zapotrzebowanie u mnie. Aminet jest wykluczony gdyż wersje cosmosa zostały usunięte.
Kolejna poprawka to SLZ3. Akurat ta wersja kodowała poprawnie pliki, ale należy używać wersji od cosmosa, gdyż ta normalna jest nieentrantna (czy coś). W każdym razie użyłem hashingu z ILZR, który jest szybszy i usunąłem użycie 020. Trzeba wspomnieć, że cosmos optymalizuje te subliby pod kątem 060 oraz rozmiaru. Cześć depakerów jest napisana pod kątem szybkości 000 bez patrzenia na rozmiar. Po optymalizacji cosmosa mogą być wolniejsze na 000, ale mniejsze i szybsze na 060 (2 instrukcje na raz).
Kolejna poprawka to SLZ3. Akurat ta wersja kodowała poprawnie pliki, ale należy używać wersji od cosmosa, gdyż ta normalna jest nieentrantna (czy coś). W każdym razie użyłem hashingu z ILZR, który jest szybszy i usunąłem użycie 020. Trzeba wspomnieć, że cosmos optymalizuje te subliby pod kątem 060 oraz rozmiaru. Cześć depakerów jest napisana pod kątem szybkości 000 bez patrzenia na rozmiar. Po optymalizacji cosmosa mogą być wolniejsze na 000, ale mniejsze i szybsze na 060 (2 instrukcje na raz).
09.06.2013 13:16
[#28]
Re: XPK problem
@cholok, post #27
Kolejne poprawki:
RDCN - usunąłem nadmiarowość kompilatora C i błąd resetowania tablic
ACCA - jest oparty na RDCN i posiadał ten sam błąd
Uogólniając, xpkmaster pakuje pliki dzieląc je na chunki. Każdy z nich pakowany jest oddzielnie, ale można przekazywać dane z poprzedniego chunku w postaci tablic czy zmiennych np. słownik czy statystyki. W przypadku kompresji opartych na LZ77 (jak oba powyżej) przekazywanie danych w postaci tablicy hashującej zawierającej odnośniki do bufora poprzednich chunków jest nieprawidłowe, ponieważ nie ma żadnej gwarancji do istnienia wszystkich chunków w pamięci na raz, zwłaszcza, że istnieje funkcja xpkSeek.
Prościej. Wgrywamy plik do pamięci i pakujemy. Xpkmaster podzieli go na części, zaś RDCN będzie miało odnośniki do wszystkich, poprzednich chunków. Jeśli wgramy spakowany plik do pamięci to rozpakowanie nastąpi prawidłowo. Jednak można alokować pamięć tylko dla jednego chunka i depakować je kolejno, Wtedy odnośniki do prowadzą do nieistniejących danych. RDCN czyścił tablice tylko raz, zmieniłem, by czyścił każdorazowo. Pomijam już fakt, że przed zwróceniem błędu typu expansion też nie było resetu.
RDCN - usunąłem nadmiarowość kompilatora C i błąd resetowania tablic
ACCA - jest oparty na RDCN i posiadał ten sam błąd
Uogólniając, xpkmaster pakuje pliki dzieląc je na chunki. Każdy z nich pakowany jest oddzielnie, ale można przekazywać dane z poprzedniego chunku w postaci tablic czy zmiennych np. słownik czy statystyki. W przypadku kompresji opartych na LZ77 (jak oba powyżej) przekazywanie danych w postaci tablicy hashującej zawierającej odnośniki do bufora poprzednich chunków jest nieprawidłowe, ponieważ nie ma żadnej gwarancji do istnienia wszystkich chunków w pamięci na raz, zwłaszcza, że istnieje funkcja xpkSeek.
Prościej. Wgrywamy plik do pamięci i pakujemy. Xpkmaster podzieli go na części, zaś RDCN będzie miało odnośniki do wszystkich, poprzednich chunków. Jeśli wgramy spakowany plik do pamięci to rozpakowanie nastąpi prawidłowo. Jednak można alokować pamięć tylko dla jednego chunka i depakować je kolejno, Wtedy odnośniki do prowadzą do nieistniejących danych. RDCN czyścił tablice tylko raz, zmieniłem, by czyścił każdorazowo. Pomijam już fakt, że przed zwróceniem błędu typu expansion też nie było resetu.
18.06.2013 11:02
[#29]
Re: XPK problem
@cholok, post #28
Jako, że LZW4 i 5 posiadają bliżej niezidentyfikowane błędy, postanowiłem przearanżować całą rodzinkę na innego rodzaju hashing, gdyż ten zastosowany wcześniej jest pamięciożerny (min 1 MB) i mało efektywny (packer nie hashował wszystkich możliwych ciągów). Zacząłem od LZW2 i 3. Teraz LZW2 zużywa 272 KB, a LZW3 512 KB. Kompresja się poprawiła ze względu na kompletny hashing (ale też zwolniła). Oba pakery pakują tak samo, ale LZW2 nieco wolniej (mniej pamięci kosztuje).
