jest sporo miejsca na CPU gdy próbkowanie jest na poziomie 4KHz, na gry logiczne powinno wystarczyć. Przy graniu z VQ Trackera przy 4KHz jest wolnego około 50% CPU, przy streamowaniu RAW z extended ramu (ten drugi testowy projekt) jest znacnie więcej, tak z 70% wolnego CPU.
@tebe - no właśnie się zastanawiam, czy zamiast poprawiać obsługę pamięci bankowanej w VQ Tracker raczej ją kompletnie nie wywalę z projektu, i zostawię jak było oryginalnie stock 64KB. Dla pamięci rozszerzonej ten projekt nie ma sensu - streamowanie skonwertowanego mp3 jest pod każdym względem lepsze (jakość, użycie CPU) i nie ma narzutu trackera.
Pomysł jest bardzo prosty. Masz długi strumień próbek audio (dla uproszczenia po bajcie, 8-bitowe wartości AUDC dla POKEYa). Odtwarzanie ich jedna po drugiej kosztuje 1 bajt na próbkę - dużo pamięci.
Kompresja VQ: Krok 1 - Budowa książki kodowej. Bierzesz strumień próbek i krojisz go na krótkie kawałki (wektory) o określonej długości, np. 4 bajty każdy. Na tych kawałkach odpalasz algorytm k-means. 256 wynikowych centroidów (czyli "najlepszych reprezentantów") to Twoja książka kodowa - 256 reprezentatywnych 4-próbkowych wzorców, które najlepiej przybliżają dłuższy kawałek audio. To 256 × 4 = 1024 bajty. Krok 2 - Kodowanie. Każdy oryginalny 4-próbkowy kawałek zastępujesz indeksem (0–255) najbliższego wpisu z książki kodowej. Strumień audio to teraz ciąg jednobajtowych indeksów zamiast 4-bajtowych kawałków. Kompresja: 4:1. Krok 3 - Dekoder. Czytasz jeden bajt indeksu, pobierasz 4 próbki z książki kodowej, które wpychasz na wyjście po kolei. W tym konwerterze strumienia na bankach - jest książka kodowa niezależna dla banku. Można to dowolnie uspprawniać np. wektory zmiennej długości, albo codebook na huffmanie, ale każde usprawnienie stopnia kompresji to więcej processingu przy dekompresji. Można też usprawniać budowanie książki kodowej, czyli przy danych wejściowcyh: AAAA|AACC|AACC zamiast wybrać najlepszego reprezentanta do książki kodowej jako AACC, można szukać najlepszego reprezentana dynamicznie i znaleźć jeszcze lepszego reprezentanta na poziomie wartości, czyli tu by mógłby być AABB (co jest już zaimplementowane tzw. Lloyd's algorithm). Kompresja VQ działa dla audio dlatego, że to nie są losowe dane (losowy szum), ale dane audio to "fala" i jest ograniczona liczba możliwości, które "brzmią dobrze".
piekne. jest też taka brutalna implementacja fali w gsm chyba - rośnie, spada, stoi.
ale ja oczem innem - to wygląda na idealny tracker do logików itp. z 50% CPU to nawet zręczność wejdzie - wiadomo, nie cała, ale w dużej części tak. ale teraz wchodzi pamięć - mało jej. jakby teraz zamarzyć sobie ładną grafę i ładną muzę to chyba fajnie by było mieć możliwość ataku choćby 130XE... W każdem razie projekt tip top jak zwykle, chylę czoła, czapki z głów, padam do nóżek.
Przypomina to logosowanie obrazka, przy czym tutaj jak rozumiem jesteśmy zafiksowani na jeden "font" / książkę kodową, dostosowaną do zestawu sampli i liczymy się ze stratami. Jest 256 centroidów po 4 próbki 4-bitowe?
Dokładnie tak, jak logosowanie obrazka do ograniczonego zestawu znaków w foncie. Ale tu mamy książkę kodową per-bank pamięci rozszerzonej, czyli jak zmienianie zestawu znaków co kilka linii obrazka. Każdy bank ma (dla wektora długości 4): [książka kodowa 256 * 4 bajty] [skompresowany strumień indeksów z książki kodowej]
Wrzuciłem nową wersję konwertera do grania muzyki z banków, z poprawioną identyfikacją i przedzieleniem pamięci rozszerzonej: ->link<-
Jeszcze zrobię drobniejsze poprawki do tego playera.
Poprawiłem konwerter i ma teraz znacznie zredukowane szumy (dla porównania z poprzedniego posta ten sam kawałek w załączniku, w 8KHz zamiast 12KHz). Załączam też "wizualnie" ile CPU zjada player 8KHz (czarny kolor).
Zrobiłem też "release" na Github: ->link<- Konwerter jest dostępny jako .exe bez wymagania instalowania Pythona. Usprawniłem również generację .asm (dla czytelności generowanego kodu playera i ewentualnych poprawek) oraz wrzuciłem prosty replacement MADSa do kompilacji, aby zmniejszyć dependency.
Czyli rzeczywiście - nie trzeba dodatkowego samplowego Trackera na Atari jeżeli jest wystarczająca ilość pamięci rozszerzonej. Ale dla pamięci podstawowej można robić ciekawe utwory mające 10x mniej miejsca (Cannon Fodder jako przykład)
Nowa Beta 5 dostępna: ->link<- Zmian i poprawek dużo. Kolejny etap do zrobienia to player z wykorzystaniem emulacji Pokeya, aby to co w trackerze brzmiało jak z Atari. EDIT: Można pobrać z release binarkę, ale z jakiegoś powodu Git wrzucił tam tydzień stare źródła :/
