Sa SAPy "TYPE R", ktore skladaja sie z wartosci rejestrow POKEYa dla kazdej ramki.
Player w Numenie stosuje buforowanie (muzyka zajmuje >300 KB). Nie moglem odpuscic 2% mocy obliczeniowej - dlatego player MPT wykonuje sie w "wolnym czasie" (ktorego prawde mowiac wiele nie ma), a co ramke idzie prosty odtwarzacz (z tego, co pamietam, ok. 100 cykli).
Jesli chodzi o przewijanie muzyki, to nie bardzo widze sens (3 min. muzyki, to nie 3-godzinny film, ktory sie oglada na raty). A pomysl rozpisania wartosci rejestrow POKEYa na Atari jest durny. Jesli chodzi o PC, to moze WinAMP nie umozliwia przewijania SAPow (nie wiem, bo nie uzywam), ale na pewno widzialem taka mozliwosc ("Pulse Player"?), zrealizowana bardzo prosto - przy przewijaniu do przodu zapuszczamy emulacje 6502 na wiele ramek, przy przewijaniu do tylu tak samo, zaczynajac emulacje od poczatku.
Kompresja LZ77 (jak w FP) wymaga rozpakowania calej wczesniejszej zawartosci strumienia (wielkosc okna nie ma znaczenia). Dlatego w formatach umozliwiajacych przewijanie (np. MP3) sa niezaleznie kompresowane ramki. Najlepsza metoda kompresji jest zawsze taka, ktora jest dostosowana do kompresowanych danych. MPT/TMC mozna wlasnie traktowac jako skompresowanie strumienia danych, z podzialem na ramki (pozycje w songu).
Racje ma Pecus. Wplyw poprzednich patternow na nastepne jest niewielki. Na poczatku mozemy szybko przetworzyc wszystkie patterny zapisujac kilku/kilkunastobajtowy wektor stanu playera. Nastepnie szybko pomijamy pozycje w paternie i potem wywolujemy juz player. Nie potrzeba hektarow pamieci, jest to szybkie, ale oczywiscie trzeba napisac "pod player".