18.06.2013 14:45
[#32]
Re: XPK problem
@cholok, post #31
Wpierw pomarz, aby SongPlayer miał support dla xpk.
SongPlayer od 15 lat ma support dla XPK
V1.2 23-Mar-1998 (...) XPK Support, a to jest grab z wersji 1.53
Po drugie,xpk w aktualnej wersji nie nadaje się do tego.
A na przykład do xpkSMPL się nadaje, to w czym problem?
Ostatnia aktualizacja: 18.06.2013 15:00:21 przez ] SKOLMAN_MWS ˇ agrEssOr [
19.06.2013 00:22
[#34]
Re: XPK problem
@cholok, post #33
Na wersji 1.53 i starszych? Do gotowych plików FLAC to chyba wystarczyłby uniwersalny nagłówek xpkFLAC, a potem go tylko dodać łącząc dwa pliki join: xpkflac-header z audio.flac to audio.flac.xpk ?
Ostatnia aktualizacja: 19.06.2013 00:42:15 przez ] SKOLMAN_MWS ˇ agrEssOr [
Ostatnia aktualizacja: 19.06.2013 00:42:15 przez ] SKOLMAN_MWS ˇ agrEssOr [
19.06.2013 09:15
[#35]
Re: XPK problem
@] SKOLMAN_MWS ˇ agrEssOr [, post #34
Na wersji 1.53 i starszych?
Sprawdzałem na 1.62, a tam support usunięto (checkmark dalej istnieje).
Do gotowych plików FLAC to chyba wystarczyłby uniwersalny nagłówek xpkFLAC
Nie. Pliki zapisane są w sposób:
xpkheader
chunkhdr
data
chunkhdr
data
....
Nawet jeśli chunki xpk przypiszemy odpowiednim blokom flac to napisanie konwertera jest konieczne. Różnica obrazowo jest jak xpkGZIP i gzip. Zaś depaker xfd ograniczony jest do mem to mem co w praktyce wyklucza sens jego istnienia jako playera.
12.07.2013 22:52
[#39]
Re: XPK problem
@cholok, post #38
Dzięki.
Raport wkrótce wyślę mailem.
A tak przy okazji zastanawiałeś się może, co dalej z tymi bibliotekami? Zamierzasz ciągnąć je wszystkie dalej, ciągnąć część (np. bez xpkLZW2 - która przy LZW3 traci powoli sens istnienia).
A może będziesz brał się za inne biblioteki? Jeśli tak, to chciałbym tak nieśmiało zauważyć, że na Aminecie leży sobie xpkELZX ze źródłami, który gdzieś tak od r. 2000 nie bardzo działa (nawet pomimo spatchowania LZXa, do którego xpkELZX się odwołuje)...
Ależ ja bynajmniej niczego nie sugeruję...
Naprawdę... ;)
Ostatnia aktualizacja: 12.07.2013 22:53:26 przez APC74
Raport wkrótce wyślę mailem.
A tak przy okazji zastanawiałeś się może, co dalej z tymi bibliotekami? Zamierzasz ciągnąć je wszystkie dalej, ciągnąć część (np. bez xpkLZW2 - która przy LZW3 traci powoli sens istnienia).
A może będziesz brał się za inne biblioteki? Jeśli tak, to chciałbym tak nieśmiało zauważyć, że na Aminecie leży sobie xpkELZX ze źródłami, który gdzieś tak od r. 2000 nie bardzo działa (nawet pomimo spatchowania LZXa, do którego xpkELZX się odwołuje)...
Ależ ja bynajmniej niczego nie sugeruję...
Naprawdę... ;)
Ostatnia aktualizacja: 12.07.2013 22:53:26 przez APC74
12.07.2013 23:10
[#40]
Re: XPK problem
@APC74, post #39
Co dalej? Te biblioteki są niejako skończone i poprawne, więc nie ma sensu ich rozwijać. Celem było wyeliminowanie błędów krytycznych (zwiechy, utrata danych). Czas na kolejne, a tego jest całkiem sporo (MASH, SHRI, HFMN, SMPL, ZENO...).
Co do ELZX to priorytet jest najniższy z możliwych. Ta biblioteka jest nakładką na LZXa, czego ja nie lubię, bo korzysta z tymczasowych plików. Nie jest to dobra biblioteka.
Co do ELZX to priorytet jest najniższy z możliwych. Ta biblioteka jest nakładką na LZXa, czego ja nie lubię, bo korzysta z tymczasowych plików. Nie jest to dobra biblioteka.
14.07.2013 14:33
[#44]
Re: XPK problem
@cholok, post #43
dziala, dziala ale w archive.org
http://web.archive.org/web/20050515000000*/http://home.swbell.net/dandrea2/xpkELZX.LZX
http://web.archive.org/web/20050515000000*/http://home.swbell.net/dandrea2/xpkELZX.LZX
15.07.2013 20:33
[#49]
Re: XPK problem
@Norbert, post #44
Alleluja! Działa! i się rozpakowało - chociaż, co ciekawe, musiałem poszukać starszej wersji Diavolo. Wiedzieliście, że Diavolo 2K nie jest kompatybilne w dół i nie potrafi rozpakować archiwum wykonanego przez wcześniejszą wersję? Co było nawet śmieszne, bo okazało się, że starszą wersję Diavolo mam wyłącznie w archiwach wykonanych tą starszą wersją...
Gdy tak sobie optymistycznie myślę, że nic mnie już nie zdziwi - wtedy nieoczekiwanie zadziwiam sam siebie... (FACEPALM)
I jak tu nie wieżyć w prawa Murphy'ego.
Gdy tak sobie optymistycznie myślę, że nic mnie już nie zdziwi - wtedy nieoczekiwanie zadziwiam sam siebie... (FACEPALM)
I jak tu nie wieżyć w prawa Murphy'ego.
17.07.2013 11:47
[#51]
Re: XPK problem
@APC74, post #50
Fajnie, ale mam parę uwag odnośnie prędkości. Są one prawie wyssane z palca. Dają one pewien obraz rzeczywistości, ale nie całkiem prawdziwy. Nie wiem jak generuje te wartości Diavolo, ale do testów najlepiej używać xbencha. GZIP i PWPK podobne prędkości? Niemożliwe.
Odnośnie WinUAE. Przy włączonym cycle exact i ustawionej częstotliwości zegara nie uzyskamy tych samych wyników co na realnym sprzęcie. Jednak korelacja pomiędzy różnymi pakerami zostanie zachowana.
Odnośnie WinUAE. Przy włączonym cycle exact i ustawionej częstotliwości zegara nie uzyskamy tych samych wyników co na realnym sprzęcie. Jednak korelacja pomiędzy różnymi pakerami zostanie zachowana.
17.07.2013 14:14
[#53]
Re: XPK problem
@cholok, post #51
Testy nie zostały przeprowadzone za pomocą Diavolo, tylko XPKatany. Co do tej samej prędkości w teście ogólnym GZIPa i PWPK - coż, tak (niechcący) zbalansowałem plik testowy, że wyszło jak wyszło. Gdyby było w nim więcej obrazków a nie było np. modułów protrackera wtedy PWPK byłby szybszy. W odwrotnej sytuacji (dużo modułów, mało obrazków) to GZIP byłby górą.
Odnośnie WinUAE nie zgodzę się z Tobą - przy tym pliku testowym wartości będą po prostu niższe ale nadal GZIP i PWPK idą łeb w łeb (oczywiście tylko w przypadku prędkości pakowania).
Odnośnie WinUAE nie zgodzę się z Tobą - przy tym pliku testowym wartości będą po prostu niższe ale nadal GZIP i PWPK idą łeb w łeb (oczywiście tylko w przypadku prędkości pakowania).
22.07.2013 16:45
[#55]
Re: XPK problem
@cholok, post #38
Kolejny na tapecie to FAST. Generalnie ten paker jest dość dopracowany i zoptymalizowany, ale mode=slow po spakowaniu miał różniące się długości plików. Więc nieco przepisałem kod i teraz jest ok. Mode=speedy też przepisałem, jest teraz sporo wolniejszy, ale też wydajniejszy. Analiza tego pakera pokazała też, że trzeba poprawić nieco poprzednie libsy, więc kolejny update później.
23.07.2013 18:45
[#56]
Re: XPK problem
@cholok, post #55
Znalazłem błąd biblioteki xpkmaster podczas szukania przyczyny zawieszania się depakera xpkCBR0 na procesorze 68000 (nieparzysty adres). Okazało się, że błąd występował, gdy paker zwracał expansion error, wtedy xpkmaster nie pakuje chunka, tylko go kopiuje bez zmian. Problemem był rozmiar domyślnego chunka. Nie może być nieparzysty. Dziwne, bo każdy rozmiar chunka jest zaokrąglany do długiego słowa.
26.07.2013 21:56
[#58]
Re: XPK problem
@APC74, post #57
Trochę to potrwa. Wróciłem do pakerów typu RLE, ponieważ było sporo niedoróbek. Na razie CBR0, RLEN i FRLE zakończone. Aktualnie FBR2 i jego badziewne mody. Usunę też ograniczenie CPU, ponieważ nie ma tu żadnego zysku. Po tym rzucę update.
Niestety trzeba jeszcze gruntownie przebadać pozostałe libsy. Większość dekoderów mam przepisane w pascalu pod win, więc to pomaga dość istotnie. Wiesz, po zbadaniu nowej biblioteki poznaje się nowe techniki i sztuczki, no i wtedy trzeba się cofać i ulepszać. Zastanawiam się nad usunięciem kodu 020 w libsach xpkLZWx oraz dodaniem lepszych modów w ILZR, RDCN, ACCA. To na pewno potrwa.
Co do wcześniejszego buga, okazuje się, że xpkmaster nie lubi tylko rozmiaru $ffff.
Niestety trzeba jeszcze gruntownie przebadać pozostałe libsy. Większość dekoderów mam przepisane w pascalu pod win, więc to pomaga dość istotnie. Wiesz, po zbadaniu nowej biblioteki poznaje się nowe techniki i sztuczki, no i wtedy trzeba się cofać i ulepszać. Zastanawiam się nad usunięciem kodu 020 w libsach xpkLZWx oraz dodaniem lepszych modów w ILZR, RDCN, ACCA. To na pewno potrwa.
Co do wcześniejszego buga, okazuje się, że xpkmaster nie lubi tylko rozmiaru $ffff.
26.07.2013 23:20
[#59]
Re: XPK problem
@cholok, post #58
No i się wyjaśniło :) - zawsze mnie zastanawiało, dlaczego taki np. FAST, czy MASH mają chunka 65536 a nie 65535, jak HEX przykazał. ;)
I jeszcze w temacie nieparzystego rozmiaru - czyli przy np. RAKE (chunk 65535) powinienem zwiększyć chunka, żeby mieć pewność? A pozostałe, z nieparzystymi chunkami jak FBR2, SHRI, SLZ3 (chunk 32767), LZBS, LZWx, TDCS (chunk 327679) itd. można uznać za bezpieczne?
I jeszcze w temacie nieparzystego rozmiaru - czyli przy np. RAKE (chunk 65535) powinienem zwiększyć chunka, żeby mieć pewność? A pozostałe, z nieparzystymi chunkami jak FBR2, SHRI, SLZ3 (chunk 32767), LZBS, LZWx, TDCS (chunk 327679) itd. można uznać za bezpieczne?
26.07.2013 23:45
[#60]
Re: XPK problem
@APC74, post #59
Może być nieparzysty, tylko różny od $ffff. Jeśli ma $ffff może powiesić się na procesorze 68000, ale tylko wtedy, gdy wystąpi expansion. Nie wiem czemu tak się dzieje, bo xpkmaster używa CopyMem. W każdym razie to był problem xpkmaster. Teraz dla CBR0 dałem $7fff, nieparzysty i jest ok.