13.04 11:30
[#1]
Quite OK Audio
Temat został mi podstępnie podsunięty na Discordzie... ale po kolei. Quite OK Audio to dość nowy (2023) format kompresji dźwięku. Jego założeniem było niewielkie skomplikowanie algorytmu, oraz prosta specyfikacja (mieści się na jednej stronie A4). Jakie podstawowe cechy ma ten format?
Jeżeli chodzi o algorytm to jest to predykcja w dziedzinie czasu, więc można QOA umieścić pomiędzy ADPCM a FLAC, zarówno jeżeli chodzi o jakość, jak i wymagania co do mocy obliczeniowej.
Napisałem dekoder tego formatu i na początek narzędzie "QoaToAiff" konwertujące pliki QOA na nieskompresowane AIFF. Dlaczego użyłem słowa "napisałem"? Ponieważ sam dekoder jest od zera napisany w asemblerze M68k na podstawie specyfikacji, referencyjny dekoder zaś jest w C. Pewnie dałoby się go skompilować na Amidze wprost, ale ze szkodą dla szybkości.
Źródła mojego dekodera (i programu QoaToAiff) są na GitHubie, zaś skompilowany program na Aminecie.
Po dekoderze mam w planach player, na początek jako polecenie shella, a potem może coś z GUI. Nie zapomnę też o enkoderze, co prawda enkodowanie będzie sporo wolniejsze, ale do zrobienia. Rzecz jasna zawsze można enkodować na PC, tam - jak można się domyśleć - enkodowanie idzie jak przecinak i pięciominutowy kawałek kompresuje się sekundę albo i krócej.
Myślałem również o używaniu QOA do przechowywania np. audio w grach, niestety ten format pracuje tylko na 16 bitach. Można oczywiście skompresować dźwięk 8-bitowy dodając mu zera na młodszym bajcie, ale wtedy efektywna kompresja spadnie do 2,5:1. Zaletą QOA w takich zastosowaniach jest bardzo mały nagłówek (8 bajtów, identyfikator 'qoaf' i ilość sampli), którego można się zresztą pozbyć, i małe rozmiary kodu dekodera (660 bajtów jak ostatnio patrzyłem, ale jeszcze jest z czego zjechać). Stały (dla danej ilości kanałów) rozmiar ramki ułatwia też skakanie po strumieniu.
Asemblerowy kod dekodera ramki QOA będzie jeszcze podlegał optymalizacji, specjaliści od asemblera na EAB podsunęli mi szereg pomysłów, które będę benchmarkował i implementował. Dlatego QoaToAiff podaje czas pracy dekodera i szybkość w odniesieniu do czasu utworu. Oczywiście jeżeli tutaj ktoś ma pomysły na przyspieszenie kodu to chętnie poczytam.
Ostatnia aktualizacja: 13.04.2025 11:30:59 przez Krashan
- kompresuje strumienie 16-bitowe o dowolnym próbkowaniu i liczbie kanałów
- jest stratny, podobnie jak np. MP3,
- stopień kompresji jest stały i wynosi 5:1 (dla porównania MP3 @ 128 kbps ma około 10:1),
- jakość po testach odsłuchowych mogę ocenić w okolicach powyższego MP3, może nawet minimalnie lepsza
- dekodowanie jest w miarę szybkie, na razie moja 68020 @ 28 MHz osiąga 0,9 rzeczywistej szybkości, ale dekoder nie jest jeszcze zoptymalizowany i na razie testuję dekoder dla 68000, bez wykorzystania rozkazów 020.
Jeżeli chodzi o algorytm to jest to predykcja w dziedzinie czasu, więc można QOA umieścić pomiędzy ADPCM a FLAC, zarówno jeżeli chodzi o jakość, jak i wymagania co do mocy obliczeniowej.
Napisałem dekoder tego formatu i na początek narzędzie "QoaToAiff" konwertujące pliki QOA na nieskompresowane AIFF. Dlaczego użyłem słowa "napisałem"? Ponieważ sam dekoder jest od zera napisany w asemblerze M68k na podstawie specyfikacji, referencyjny dekoder zaś jest w C. Pewnie dałoby się go skompilować na Amidze wprost, ale ze szkodą dla szybkości.
Źródła mojego dekodera (i programu QoaToAiff) są na GitHubie, zaś skompilowany program na Aminecie.
Po dekoderze mam w planach player, na początek jako polecenie shella, a potem może coś z GUI. Nie zapomnę też o enkoderze, co prawda enkodowanie będzie sporo wolniejsze, ale do zrobienia. Rzecz jasna zawsze można enkodować na PC, tam - jak można się domyśleć - enkodowanie idzie jak przecinak i pięciominutowy kawałek kompresuje się sekundę albo i krócej.
Myślałem również o używaniu QOA do przechowywania np. audio w grach, niestety ten format pracuje tylko na 16 bitach. Można oczywiście skompresować dźwięk 8-bitowy dodając mu zera na młodszym bajcie, ale wtedy efektywna kompresja spadnie do 2,5:1. Zaletą QOA w takich zastosowaniach jest bardzo mały nagłówek (8 bajtów, identyfikator 'qoaf' i ilość sampli), którego można się zresztą pozbyć, i małe rozmiary kodu dekodera (660 bajtów jak ostatnio patrzyłem, ale jeszcze jest z czego zjechać). Stały (dla danej ilości kanałów) rozmiar ramki ułatwia też skakanie po strumieniu.
Asemblerowy kod dekodera ramki QOA będzie jeszcze podlegał optymalizacji, specjaliści od asemblera na EAB podsunęli mi szereg pomysłów, które będę benchmarkował i implementował. Dlatego QoaToAiff podaje czas pracy dekodera i szybkość w odniesieniu do czasu utworu. Oczywiście jeżeli tutaj ktoś ma pomysły na przyspieszenie kodu to chętnie poczytam.
Ostatnia aktualizacja: 13.04.2025 11:30:59 przez Krashan
13.04 16:50
[#3]
Re: Quite OK Audio
@Phibrizzo, post #2
Z ciekawosci zapytam, wiem ze to jest dosc swiezy format ale jak z popularnoscia, przyjal sie?Jako popularny format do słuchania muzyki, nie sądzę. Przeciętny pecet spokojnie odtwarza MP3 czy AAC pojedynczymi procentami mocy procesora, z drugiej strony dla mających wysokie oczekiwania jakościowe jest FLAC, też nie będący wyzwaniem obliczeniowym dla współczesnych komputerów.
BTW. jesli da sie zrobic jako player do Deli-Trackera to bardzo bym prosil.Nigdy nie robiłem, ale przyjrzę się.
Ostatnia aktualizacja: 13.04.2025 16:50:40 przez Krashan
14.04 11:36
[#4]
Re: Quite OK Audio
@Phibrizzo, post #2
Jeśli cokolwiek to znaczy, to Godot Engine ostatnio dodał obsługę QOA do swoich assetów. Format pochodzi z mniej-więcej nowożytnego gamedevu i raczej tak zostanie. Nikt raczej nie będzie na pececie trzymał w tym swojej kolekcji muzyki, ale do gierek jak znalazł.
Ostatnia aktualizacja: 14.04.2025 11:38:13 przez teh_KaiN
Ostatnia aktualizacja: 14.04.2025 11:38:13 przez teh_KaiN
24.04 20:12
[#5]
Re: Quite OK Audio
@Krashan, post #1
Jutro powinna wjechać na Aminet wersja 0.2 narzędzia QoaToAiff. W niej przede wszystkim zbuforowałem operacje dyskowe, zarówno odczyt jak i zapis. Poskutkowało to zauważalnym przyspieszeniem całej konwersji. Na mojej A1200 z kartą ACA1221 i "dyskiem" w postaci karty SD w konwerterze wpiętym w standardowe IDE na płycie, operacje dyskowe zajmują około 20% całego czasu konwersji. Co ciekawe, zauważyłem, że przesadne zwiększenie buforów powoduje... spowolnienie. Nie wiem do końca dlaczego. Poprzestałem na optymalnym buforze miesczącym 8 ramek QOA, co dla plików stereo oznacza około 32 kB bufora odczytu i 160 kB zapisu.
Samo dekodowanie przyspieszyło minimalnie z 0,95 do 1,00 szybkości czasu rzeczywistego. To jeszcze trochę za mało na prawdziwe odtwarzanie, bo przecież trzeba czytać plik i kierować zdekodowane dane do Pauli. Czas na ciśnięcie asemblera, najpierw wersji 68000, a potem zobaczę co instrukcje 68020 mogą poprawić.
Przy okazji uporządkowałem raportowanie błędów konwersji, bo komunikaty błędów mimo, że były już w pliku programu, to nie były używane, za to można było otrzymać bardzo opisowy komunikat w stylu "wystąpił błąd numer 17". Teraz są już używane, a lokalizacja programu jest o krok.
Aha i dalej to całe 6536 bajtów pliku wykonywalnego, mimo, że przecież "w C++ nie da się pisać małych programów".
Co do rozmiaru, to też ciekaw jestem Waszej opinii o następującym dylemacie: cały program jest napisany w C++, ale procedura dekodująca jest w asemblerze. Jeżeli wersja tej procedury dedykowana procesorom 68020+ okaże się jakoś zauważalnie szybsza od kodu 68000 (raczej tak, ale to się okaże), to lepiej:
Samo dekodowanie przyspieszyło minimalnie z 0,95 do 1,00 szybkości czasu rzeczywistego. To jeszcze trochę za mało na prawdziwe odtwarzanie, bo przecież trzeba czytać plik i kierować zdekodowane dane do Pauli. Czas na ciśnięcie asemblera, najpierw wersji 68000, a potem zobaczę co instrukcje 68020 mogą poprawić.
Przy okazji uporządkowałem raportowanie błędów konwersji, bo komunikaty błędów mimo, że były już w pliku programu, to nie były używane, za to można było otrzymać bardzo opisowy komunikat w stylu "wystąpił błąd numer 17". Teraz są już używane, a lokalizacja programu jest o krok.
Aha i dalej to całe 6536 bajtów pliku wykonywalnego, mimo, że przecież "w C++ nie da się pisać małych programów".
Co do rozmiaru, to też ciekaw jestem Waszej opinii o następującym dylemacie: cały program jest napisany w C++, ale procedura dekodująca jest w asemblerze. Jeżeli wersja tej procedury dedykowana procesorom 68020+ okaże się jakoś zauważalnie szybsza od kodu 68000 (raczej tak, ale to się okaże), to lepiej:
- Zrobić dwie wersje programu: 000 i 020+ i wtedy również kod w C++ w tej drugiej wersji skompilować pod 020+. Niech użytkownik sobie skopiuje właściwą wersję. Oczywiście wersja 020+ odpalona na 000 nie będzie się wieszać, tylko wyświetli komunikat, że musisz awansować do amigowej burżuazji.
- Zrobić jedną wersję. Nie kompilować kodu C++ pod 020, bo on przecież i tak nie jest krytyczny szybkościowo (owszem, nie jest). Umieścić w kodzie obie procedury dekodujące, sprawdzać procesor i automatycznie wybierać odpowiednią. Objętościowo, jedna procedura dekodująca to poniżej kilobajta, więc tyle nieużywanego na danej maszynie kodu balastowałoby sobie w pliku wykonywalnym.
24.04 21:47
[#6]
Re: Quite OK Audio
@Krashan, post #5
Samo dekodowanie przyspieszyło minimalnie z 0,95 do 1,00 szybkości czasu rzeczywistego. To jeszcze trochę za mało na prawdziwe odtwarzanie, bo przecież trzeba czytać plik i kierować zdekodowane dane do Pauli.
To 030 50Mhz powinien już sobie z tym poradzić. Z czytaniem pliku, to jak ktoś ma 030 to pewnie i ma wystatczającą ilość Fastu, żeby cały plik zmieścić i zostaje tylko dekodowanie i kopiowanie do Chip. Nie wiem ile taki przeciętny plik może zajmować. Powiedzmy 4 minutowy? Z 10MB? Wiem, że chcesz to robić w czasie rzeczywistym, ale jeśli planujesz pisać jakiś mini player do tego, to taka opcja mogłaby się przydać. Są karty z kotrolerem IDE co wyciągają nawet 10MB/s. Przy kartach z 128MB czy 64MB te kilkanaście MB raczej by nie bolało.
Nawet przy szybkich procesorach 060, może pojawić się problem z odczytem danych z SD gdy w tle będzie się coś jeszcze kopiować. No ale to takie gdybanie bez empirycznego sprawdzenia.
24.04 21:55
[#7]
Re: Quite OK Audio
@Krashan, post #5
Jesli zalezy na szybkosci dzialania to mozesz dekodowac od razu do chipu, anie do fastu jesli ma byc dla Pauli.
Wtedy zapis longwordowy ma sens, bo w zasadzie da sie wtedy pominac zapis do chipu przy dekodowaniu dla 68020.
W przypadku 68000 najszybszy raczej bedzie zapis wordowy, ewentualnie bajtowy, jesli bylyby potrzebne przesuniecia bajtow.
Wedlug mnie 2 (68000 i 68020) wersje sa lepsze niz 1 wersja. No chyba, ze wersja 68000 bedzie tylko niezauwazalnie wolniejsza niz wersja 68020, wtedy to raczej nie bedzie mialo sensu.
Wtedy zapis longwordowy ma sens, bo w zasadzie da sie wtedy pominac zapis do chipu przy dekodowaniu dla 68020.
W przypadku 68000 najszybszy raczej bedzie zapis wordowy, ewentualnie bajtowy, jesli bylyby potrzebne przesuniecia bajtow.
Wedlug mnie 2 (68000 i 68020) wersje sa lepsze niz 1 wersja. No chyba, ze wersja 68000 bedzie tylko niezauwazalnie wolniejsza niz wersja 68020, wtedy to raczej nie bedzie mialo sensu.
24.04 21:59
[#8]
Re: Quite OK Audio
@Krashan, post #5
Co do rozmiaru, to też ciekaw jestem Waszej opinii o następującym dylemacie
Ja bym poszedł w drugie rozwiązanie, zwłaszcza że jak rozumiem mówimy tu różnicy w rozmiarze binarki wyrażonej w pojedynczych kilobajtach. Jedna wersja wydaje mi się prostsza zarówno z punktu widzenia programisty (utrzymanie i rozwój) , jak użytkownika (instalacja i użytkowanie).
24.04 22:14
[#9]
Re: Quite OK Audio
@snifferman, post #6
Tak dla playera można dodać opcję prebuforowania nawet całego pliku w pamięci. QOA 44,1 kHz stereo ma przelicznik z grubsza 2 MB na minutę muzyki, więc przeciętnie będzie to od 6 do 10 MB. Dekoder może zapisywać próbki od razu do chip RAM w przypadku odtwarzania bezpośrednio Paulą (będzie oczywiście opcja AHI i wtedy lepiej bufor w faście).
wczoraj 23:54
[#13]
Re: Quite OK Audio
@Krashan, post #12
Burza mózgów na Discordzie i EAB dała efekt. Aktualnie na 68020@28 dekodowanie przyspieszyło o 15% z x1,00 do x1,18, przy czym to jest kod dla 68000. Okazuje się że nowe rozkazy 68020 w tym przypadku rewolucji nie robią. Napisany przeze mnie oddzielny kod dla 020 okazał się wolniejszy (x1,07), więc poszedł do kosza. Na razie to zostawiam, kiedyś może spróbuję się ponownie z tematem kodu dla 020+ modyfikując nieznacznie ten aktualny dla 68000.
Te wyniki dają jakąś szansę, że A1200 z najsłabszą kartą turbo (chyba, że ktoś nie dopłacił Jensowi do odblokowania zegara...) będzie odtwarzać 44,1 kHz stereo.
Te wyniki dają jakąś szansę, że A1200 z najsłabszą kartą turbo (chyba, że ktoś nie dopłacił Jensowi do odblokowania zegara...) będzie odtwarzać 44,1 kHz stereo.