13.06.2021 16:31
[#31]
Re: Amiga jednak Rulez - o dźwięku i modułach
@nogorg, post #30
Cytaciki wyłuskane z mojego tekstu, którego nawet nie próbowałeś zrozumieć, tylko przeczytałeś po to, żeby się przyczepić do wyrwanych z kontekstu wypowiedzi. Brawo! Trzymasz poziom!
Który już raz piszesz, że nie zamierzasz dyskutować i tracić czasu? Mam ja teraz zacząć cytować i szydzić? Merytorycznie - zero argumentów. Ale kop dalej - jeszcze Cię widać.
Który już raz piszesz, że nie zamierzasz dyskutować i tracić czasu? Mam ja teraz zacząć cytować i szydzić? Merytorycznie - zero argumentów. Ale kop dalej - jeszcze Cię widać.
13.06.2021 16:56
[#33]
Re: Amiga jednak Rulez - o dźwięku i modułach
@wali7, post #32
To nie jest kłótnia. To jest brak chęci zrozumienia argumentów. Z jednej strony nacisk, żebym JA się z czymś koniecznie zapoznał, bo rzekomo wymyślam teorie bez pokrycia, potem atak, że w przedstawionym tekście znalazłem bardzo mocny argument za moją teorią (czyli wykorzystałem argumenty drugiej strony dyskusji do poparcia swojego zdania). A potem już, niestety, typowe odwracanie kota ogonem, zmiany tematu (już nie było mowy o tym, że Amiga jest 14-bitowa, tylko że może lepiej gra albo gorzej, może ilość bitów jest mniejsza itd.). A potem już tylko słabe żonglowanie cytacikami, czyli ustawianie się w pozycji wujka "celna riposta". Niestety, to częsty problem w dyskusjach, gdy najpierw ktoś występuje z poziomu rzekomo lepiej poinformowanego, po czym nie jest w stanie na spokojnie ocenić czyichś argumentów, bo wymagałoby to przynajmniej częściowego potwierdzenia tez oponenta. Już samo przystąpienie do dyskusji było mało eleganckie - "ja sugeruję zacząć od lektury (...) zanim zacznie się tworzyć autorskie teorie". Gdyby to był osobny temat pt. "jak dyskutować" albo "co zrobić zanim zacznie się tworzyć autorskie teorie" i kolega by przedstawił swój punkt widzenia na ten temat - wszystko byłoby ok. Ale jak ktoś zaznacza swoją obecność w dyksusji od takiego wyniosłego tonu, to niech nie spodziewa się, że z drugiej strony zawsze zastanie "ucznia", który mu powie "tak jest, panie profesorze". W dyskusji trzeba operować argumentami, a nie "sugerować" komuś coś z pozycji wiedzącego lepiej.
13.06.2021 17:17
[#34]
Re: Amiga jednak Rulez - o dźwięku i modułach
@XTD, post #33
Rozumiem.
Ja tam sobie z boku śledzę, czytam i całkiem ciekawa jest ta dyskusja. W sumie to chyba troszkę wszyscy (prawie) piszecie o tym samym, ale jakoś do meritum nie udaje się dojść.
Mi się wydaje (z naciskiem na słowo wydaje), że te 14 bitów jest i jednocześnie nie jest "prawdziwe". Bo z jednej strony po ściszeniu drugiego kanału 64x mamy w nim dodatkowe młodsze 6 bitów, i jest to naprawdę dodatkowa rozdzielczość próbki, więc w sumie wychodzi 14. Z drugiej jednak strony te młodsze 6 bitów wychodzi z osobnego przetwornika o zupełnie innej liniowości (nie musiały przecież być parowane, skoro oryginalnie były pomyślane jako zupełnie odrębne urządzenia... nie były więc parowane). Jednak istnieje możliwość programowej korekcji tej rozjechanej charakterystyki tak, aby udawało to prawdziwy przetwornik 14 bit.
Co do wspomnianej kwestii szumów w tych pozostałych dwóch bitach - one nie mogą szumieć, bo to nie są najmłodsze bity ściszonego przetwornika, tylko najstarsze, i muszą być zawsze wyzerowane, bo nakładają się na najmłodsze dwa z głośniejszego przetwornika.
Czyli głównym problemem są odmienne charakterystyki, częściowo do wyprostowania programowo.
Drugą sprawą jest możliwość nierównomiernego grania - tu krashan pisał, że one są sprzętowo zsynchronizowane w Pauli. O ile oczywiście dostały dane które odpowiadają danej 14bitowej próbce, bo jeśli się to rozjedzie, to na pewno będzie kaszana. Ale to jest chyba kwestia zadbania (w playerze) aby nie doszło do rozjechania się danych, to Paula je odegra jak trzeba.
Czyli reasumując - mamy pełne 14 bitów, bo próbki są 14 bitowe i tak też są przetwarzane na sygnał analogowy. Jednak odmienności w charakterystyce głośnego i ściszonego przetwornika powodują, że mogą się pojawić nieliniowości w obrębie tych 14 bitów. A więc poziom szumu będzie wyższy niż dla prawdziwego przetwornika 14 bit.
Tak sobie to wyobrażam. Może się mylę :)
Ostatnia aktualizacja: 13.06.2021 17:34:39 przez wali7
Ja tam sobie z boku śledzę, czytam i całkiem ciekawa jest ta dyskusja. W sumie to chyba troszkę wszyscy (prawie) piszecie o tym samym, ale jakoś do meritum nie udaje się dojść.
Mi się wydaje (z naciskiem na słowo wydaje), że te 14 bitów jest i jednocześnie nie jest "prawdziwe". Bo z jednej strony po ściszeniu drugiego kanału 64x mamy w nim dodatkowe młodsze 6 bitów, i jest to naprawdę dodatkowa rozdzielczość próbki, więc w sumie wychodzi 14. Z drugiej jednak strony te młodsze 6 bitów wychodzi z osobnego przetwornika o zupełnie innej liniowości (nie musiały przecież być parowane, skoro oryginalnie były pomyślane jako zupełnie odrębne urządzenia... nie były więc parowane). Jednak istnieje możliwość programowej korekcji tej rozjechanej charakterystyki tak, aby udawało to prawdziwy przetwornik 14 bit.
Co do wspomnianej kwestii szumów w tych pozostałych dwóch bitach - one nie mogą szumieć, bo to nie są najmłodsze bity ściszonego przetwornika, tylko najstarsze, i muszą być zawsze wyzerowane, bo nakładają się na najmłodsze dwa z głośniejszego przetwornika.
Czyli głównym problemem są odmienne charakterystyki, częściowo do wyprostowania programowo.
Drugą sprawą jest możliwość nierównomiernego grania - tu krashan pisał, że one są sprzętowo zsynchronizowane w Pauli. O ile oczywiście dostały dane które odpowiadają danej 14bitowej próbce, bo jeśli się to rozjedzie, to na pewno będzie kaszana. Ale to jest chyba kwestia zadbania (w playerze) aby nie doszło do rozjechania się danych, to Paula je odegra jak trzeba.
Czyli reasumując - mamy pełne 14 bitów, bo próbki są 14 bitowe i tak też są przetwarzane na sygnał analogowy. Jednak odmienności w charakterystyce głośnego i ściszonego przetwornika powodują, że mogą się pojawić nieliniowości w obrębie tych 14 bitów. A więc poziom szumu będzie wyższy niż dla prawdziwego przetwornika 14 bit.
Tak sobie to wyobrażam. Może się mylę :)
Ostatnia aktualizacja: 13.06.2021 17:34:39 przez wali7
13.06.2021 18:36
[#35]
Re: Amiga jednak Rulez - o dźwięku i modułach
@wali7, post #34
No właśnie pisałem o rozjechaniu się. Nie chodzi mi o 2 pozostałe bity, bo wiem jak to jest przeliczane i one by żadnych szumów dodatkowych nie mogły wprowadzić. Chodzi mi o niedokładność (w czasie) w odtwarzaniu kanałów, a co za tym idzie - przypisania młodszych 6-bitów niewłaściwym starszym bitom w danej próbce. Wystarczy naprawdę mikroskopijny ułamek sekundy przesunięcia. Jeżeli dźwięk wychodzi osobno, to tego typu przesunięcia są niemal pewne. Każda karta ma jakąś latencję, tym bardziej stare układy Paula. Niemożliwością jest kontrola wyjścia sygnału w ten sposób, żeby idealnie dopasować młodsze bity do starszych jeżeli młodsze są podawane poprzez inny, niezależny kanał. Tego typu opóźnienia nie mają znaczenia przy odgrywaniu niezależnych kanałów (jak napisałeś), jednak jeżeli łączymy dwa kanały, to sprawa jest trudna, o ile nie niemożliwa. To tak jakbyś próbował zsynchronizować dwie karty dźwiękowe na PC co do mikrosekundy - już pewnie samo opóźnienie sterowników sprawi, że będzie to niemożliwe z taką dokładnością, żeby jedna karta robiła za młodsze bity dla drugiej. A my tu przecież o tym mówimy, żeby dodawać młodsze bity do starszych w czasie rzeczywistym (w domyśle - bez opóźnień, bo inaczej nie jest to żadne dodawanie).
W playerze możesz co najwyżej udawać, ze dopasowujesz kanały, żeby grały równo. Nie zmierzysz w żaden sposób rzeczywistego opóźnienia sygnału. Myślę, że nikt w tamtych czasach nie bawił się w układy o takiej precyzji. Myślę, że nawet oscyloskop niewiele by tu pomógł biorąc pod uwagę, że mówimy o dodatkowych bitach, które trudno byłoby wychwycić wzrokiem (ale uchem się da - stąd bazując na zaszumieniu 14-bitowego trybu przypuszczam, że jest to po prostu nieudany eksperyment i bity są w rzeczywistości przesunięte).
Audio to w ogóle bardzo wrażliwy temat - są przecież ludzie przekonani o tym, że słyszą ultradźwięki, że bez problemu odróżnią utwór 192/24 od 44/16, że drewniane podkładki pod kable głośnikowe znacząco zmieniają charakterystykę dźwięku i że gazeta podłożona pod wzmacniacz zmienia (na plus) jego parametry. W sieci jest setki tematów o tym, co się komu wydaje, że słyszy. Ja jestem sceptykiem - skoro słyszę szumy, nie będę udawał, że "AHI 14 bitów" uwypukliło mi szum morza za oknem. :) Natomiast wierzę, że ludzie słyszą to, co chcą - i zawsze staram się znaleźć (choćby poprzez zwykłe zastanowienie nad tematem) powody. W przypadku AHI - nawet szumy wynikające (jeżeli tak jest) ze źle dodanych bitów mogą komuś podnieść komfot słuchania - podobnie jak dodanie szumu (dithering) do próbki 8-bitowej. Z tym, że tutaj jest lepiej, bo szum leci z osobnego kanału na odpowiednio mniejszej głośności, więc nie powoduje dodatkowych zniekształceń głównego dźwięku (i sam w sobie jest przyjemniejszy, niż 2-bitowe "drapanie"). Nawet podkładki pod kable da się logicznie wytłumaczyć - przy ich instalacji człowiek przez dłuższy czas pracuje pochylony, zmienia się ciśnienie w uszach, a więc po włączeniu tego samego nagrania zaraz po zamontowaniu klocków - zmienia się odbiór muzyki (chwilowo, ale wystarczy, żeby kogoś przekonać do tego, że to działa). Jak to jest z gazetą podłożoną pod wzmacniacz - tego nie byłem w stanie rozgryźć. :)
Ostatnia aktualizacja: 13.06.2021 18:49:45 przez XTD
W playerze możesz co najwyżej udawać, ze dopasowujesz kanały, żeby grały równo. Nie zmierzysz w żaden sposób rzeczywistego opóźnienia sygnału. Myślę, że nikt w tamtych czasach nie bawił się w układy o takiej precyzji. Myślę, że nawet oscyloskop niewiele by tu pomógł biorąc pod uwagę, że mówimy o dodatkowych bitach, które trudno byłoby wychwycić wzrokiem (ale uchem się da - stąd bazując na zaszumieniu 14-bitowego trybu przypuszczam, że jest to po prostu nieudany eksperyment i bity są w rzeczywistości przesunięte).
Audio to w ogóle bardzo wrażliwy temat - są przecież ludzie przekonani o tym, że słyszą ultradźwięki, że bez problemu odróżnią utwór 192/24 od 44/16, że drewniane podkładki pod kable głośnikowe znacząco zmieniają charakterystykę dźwięku i że gazeta podłożona pod wzmacniacz zmienia (na plus) jego parametry. W sieci jest setki tematów o tym, co się komu wydaje, że słyszy. Ja jestem sceptykiem - skoro słyszę szumy, nie będę udawał, że "AHI 14 bitów" uwypukliło mi szum morza za oknem. :) Natomiast wierzę, że ludzie słyszą to, co chcą - i zawsze staram się znaleźć (choćby poprzez zwykłe zastanowienie nad tematem) powody. W przypadku AHI - nawet szumy wynikające (jeżeli tak jest) ze źle dodanych bitów mogą komuś podnieść komfot słuchania - podobnie jak dodanie szumu (dithering) do próbki 8-bitowej. Z tym, że tutaj jest lepiej, bo szum leci z osobnego kanału na odpowiednio mniejszej głośności, więc nie powoduje dodatkowych zniekształceń głównego dźwięku (i sam w sobie jest przyjemniejszy, niż 2-bitowe "drapanie"). Nawet podkładki pod kable da się logicznie wytłumaczyć - przy ich instalacji człowiek przez dłuższy czas pracuje pochylony, zmienia się ciśnienie w uszach, a więc po włączeniu tego samego nagrania zaraz po zamontowaniu klocków - zmienia się odbiór muzyki (chwilowo, ale wystarczy, żeby kogoś przekonać do tego, że to działa). Jak to jest z gazetą podłożoną pod wzmacniacz - tego nie byłem w stanie rozgryźć. :)
Ostatnia aktualizacja: 13.06.2021 18:49:45 przez XTD
13.06.2021 19:48
[#36]
Re: Amiga jednak Rulez - o dźwięku i modułach
@wali7, post #34
Przeczytałem ten ciekawy PDF w całości i pojawia się tam rzecz, o której wcześniej nie wiedziałem, mianowicie jest opisany sposób, w jaki Paula dokonuje regulacji głośności. Niestety ten sposób powoduje, że o 14 bitach nie może być mowy. Otóż jeżeli głośność kanału jest ustawiona na cokolwiek innego niż 64 (czyli max.), to sygnał schodzący z DAC-a jest wewnętrznie resamplowany ze stałą częstotliwością równą 1/64 podstawowego zegara 3,5 MHz (tego, z którego liczy się periody), to jest około 55,4 kHz. Następnie Paula robi PWM: jeżeli n to ustawiona głośność, to przez n taktów zegara na wyjściu jest to co zsamplowano z DAC-a, przez 64-n taktów jest zero. Wartość średnia sygnału jest więc efektywnie iloczynem wyjścia z DAC-a i głośności, czyli teoretycznie właśnie o to chodzi.
W czym więc problem? Ano w tym, że jeżeli weźmiemy ten sam sampel i raz go puścimy z głośnością 64 a raz z głośnością dowolną inną (np. 63), to widma na wyjściu będą miały inny kształt, również w zakresie słyszalnym. Sytuację ratuje nieco fakt, że w trybie 14-bit kanał główny pracuje z stałą głośnością 64, kanał młodszych bitów ze stałą głośnością 1, przez co dodatkowe zniekształcenia wprowadzane przez wewnętrzny resampling są na dość niskim poziomie.
Autor PDF-a przeprowadził pomiary odstępu sygnału od szumu w trybie 14-bit i doszedł do wniosku na ich podstawie, że Paula pracująca w tym trybie, bez kalibracji, odpowiada idealnemu przetwornikowi 10-bitowemu. Po kalibracji i biorąc pod uwagę fakt, że każdy rzeczywisty DAC od ideału jednak odbiega, napisał, że można uznać Paulę w trybie 14-bit calibrated za równoważną 12-bitowemu rzeczywistemu przetwornikowi.
Jeżeli przyjmiemy to do wiadomości, to jednak słowa XTD o tym, że równie dobrze można dodawać do 8 bitów sampla 6 bitów szumu i nie będzie słychać różnicy, są błędne.
Mam również wątpliwości co do części wywodów Henryka Richtera. Z tego co pisze, oraz fotografii systemu pomiarowego wynika, że mierzył napięcia bezpośrednio na wyjściach Pauli. Moim zdaniem Paula, jak wiele DAC-ów ma wyjście prądowe, a pierwszy stopień filtra audio jest w klasycznej konfiguracji konwertera prąd-napięcie. W związku z tym mierzenie tam napięcia i pisanie o jakichś "różnicowych impulsach" nie ma sensu, bo te szpliki to po prostu efekt uboczny przeładowywania kondensatora w pętli sprzężenia. Przebieg mierzyłbym na wyjściu U15, piny 8 i 14 (w Amidze 1200). Można do pomiarów odpiąć kondensator z pętli, żeby mierzyć wyjście w pełnym pasmie częstotliwości.
Odniosę się jeszcze do tematu synchronizacji kanałów Pauli (8-bitowych) między sobą. W rzeczonym PDF jest to wyjaśnione dokładniej, niż tylko w tym cytacie wyrwanym przez XTD z kontekstu. Jest to opisane na stronie 16. Jak twierdzi autor, dwa kanały Pauli umieszczone na jednym kanale stereo, korzystają z tego samego DAC-a naprzemiennie. Trochę w to powątpiewam, w sytuacji gdy każdy kanał może mieć inną częstotliwość próbkowania. Tak czy inaczej to przesunięcie jest stałe, zafiksowane do zegara 3,5 MHz i nie może przekroczyć okresu PWM głośności, czyli jest mniejsze od 20 mikrosekund. Ale wpływ na pogorszenie jakości "udawania 14 bitów" ma.
Zważywszy na zagwozdkę z "impulsami różnicowymi" i mierzeniem napięcia na wyjściach prądowych, nie traktowałbym dokumentu pana Richtera jak źródło wiedzy absolutnej. Choć z pewnością sporo wnosi do tematu.
Swoją drogą, przyszedł mi do głowy pewien pomysł, jak możnaby skalibrować te 14 bitów lepiej, korzystając z współczesnych narzędzi. Całe sedno sprawy polega na stworzeniu optymalnej tablicy konwersji próbek 16-bitowych do wartości ustawianych w kanałach LO i HI pary. Niech więc komputer PC będzie w stanie załadować do Amigi tęże tablicę, oraz sampla do odegrania, a następnie uruchomić odtwarzanie i zsamplować wynik z dużą dokładnością (np. 24-bit, 192 kHz). Dysponując takim sprzężeniem zwrotnym możnaby zagonić do pracy nad idealną tabelą konwersji wybrany algorytm optymalizacyjny (np. genetyczny...), pracujący oczywiście na PC. Rezultaty mogłyby być ciekawe. Oczywiście taka optymalna tabela, podobnie jak używana obecnie "kalibracja słuchawkowa" byłaby dopasowana do konkretnego egzemplarza Amigi.
Ostatnia aktualizacja: 13.06.2021 19:51:03 przez Krashan
W czym więc problem? Ano w tym, że jeżeli weźmiemy ten sam sampel i raz go puścimy z głośnością 64 a raz z głośnością dowolną inną (np. 63), to widma na wyjściu będą miały inny kształt, również w zakresie słyszalnym. Sytuację ratuje nieco fakt, że w trybie 14-bit kanał główny pracuje z stałą głośnością 64, kanał młodszych bitów ze stałą głośnością 1, przez co dodatkowe zniekształcenia wprowadzane przez wewnętrzny resampling są na dość niskim poziomie.
Autor PDF-a przeprowadził pomiary odstępu sygnału od szumu w trybie 14-bit i doszedł do wniosku na ich podstawie, że Paula pracująca w tym trybie, bez kalibracji, odpowiada idealnemu przetwornikowi 10-bitowemu. Po kalibracji i biorąc pod uwagę fakt, że każdy rzeczywisty DAC od ideału jednak odbiega, napisał, że można uznać Paulę w trybie 14-bit calibrated za równoważną 12-bitowemu rzeczywistemu przetwornikowi.
Jeżeli przyjmiemy to do wiadomości, to jednak słowa XTD o tym, że równie dobrze można dodawać do 8 bitów sampla 6 bitów szumu i nie będzie słychać różnicy, są błędne.
Mam również wątpliwości co do części wywodów Henryka Richtera. Z tego co pisze, oraz fotografii systemu pomiarowego wynika, że mierzył napięcia bezpośrednio na wyjściach Pauli. Moim zdaniem Paula, jak wiele DAC-ów ma wyjście prądowe, a pierwszy stopień filtra audio jest w klasycznej konfiguracji konwertera prąd-napięcie. W związku z tym mierzenie tam napięcia i pisanie o jakichś "różnicowych impulsach" nie ma sensu, bo te szpliki to po prostu efekt uboczny przeładowywania kondensatora w pętli sprzężenia. Przebieg mierzyłbym na wyjściu U15, piny 8 i 14 (w Amidze 1200). Można do pomiarów odpiąć kondensator z pętli, żeby mierzyć wyjście w pełnym pasmie częstotliwości.
Odniosę się jeszcze do tematu synchronizacji kanałów Pauli (8-bitowych) między sobą. W rzeczonym PDF jest to wyjaśnione dokładniej, niż tylko w tym cytacie wyrwanym przez XTD z kontekstu. Jest to opisane na stronie 16. Jak twierdzi autor, dwa kanały Pauli umieszczone na jednym kanale stereo, korzystają z tego samego DAC-a naprzemiennie. Trochę w to powątpiewam, w sytuacji gdy każdy kanał może mieć inną częstotliwość próbkowania. Tak czy inaczej to przesunięcie jest stałe, zafiksowane do zegara 3,5 MHz i nie może przekroczyć okresu PWM głośności, czyli jest mniejsze od 20 mikrosekund. Ale wpływ na pogorszenie jakości "udawania 14 bitów" ma.
Zważywszy na zagwozdkę z "impulsami różnicowymi" i mierzeniem napięcia na wyjściach prądowych, nie traktowałbym dokumentu pana Richtera jak źródło wiedzy absolutnej. Choć z pewnością sporo wnosi do tematu.
Swoją drogą, przyszedł mi do głowy pewien pomysł, jak możnaby skalibrować te 14 bitów lepiej, korzystając z współczesnych narzędzi. Całe sedno sprawy polega na stworzeniu optymalnej tablicy konwersji próbek 16-bitowych do wartości ustawianych w kanałach LO i HI pary. Niech więc komputer PC będzie w stanie załadować do Amigi tęże tablicę, oraz sampla do odegrania, a następnie uruchomić odtwarzanie i zsamplować wynik z dużą dokładnością (np. 24-bit, 192 kHz). Dysponując takim sprzężeniem zwrotnym możnaby zagonić do pracy nad idealną tabelą konwersji wybrany algorytm optymalizacyjny (np. genetyczny...), pracujący oczywiście na PC. Rezultaty mogłyby być ciekawe. Oczywiście taka optymalna tabela, podobnie jak używana obecnie "kalibracja słuchawkowa" byłaby dopasowana do konkretnego egzemplarza Amigi.
Ostatnia aktualizacja: 13.06.2021 19:51:03 przez Krashan
13.06.2021 21:44
[#37]
Re: Amiga jednak Rulez - o dźwięku i modułach
@Krashan, post #36
Ciekawie napisane, jednak nie zgodzę się, że cokolwiek wyrywałem z kontekstu. Jest to początek sekcji dotyczącej pomiarów - w żaden sposób nie obcięta, bowiem zacytowany został pełen akapit, bez skrótów ani wyrywania czegokolwiek z kontekstu. Jest to absolutnie uprawniona metoda cytowania i powoływania się na czyjąś pracę. Gdy się szuka jakiejś informacji, najlepszym z punktu widzenia dyskusji jest znalezienie konkretnych odpowiedzi na konkretne pytania. W moim przypadku pytaniem było "czy Amigowe 14 bitów jest prawdziwe" i bardzo dokłądną odpowiedź znalazłem w tym akapicie. Mogę co najwyżej powiedzieć, że jeżeli kogoś interesuje bardziej rozbudowana teoria, może sięgnąć po pełne opracowanie, jednak samemu nie będę (i nawet nie powinienem) cytować więcej, niż jednego, konkretnego paragrafu. Przepisanie całego działu to już jest przedruk a nie cytat, przepisanie dwóch słów byłoby wyrwaniem z kontekstu. Zacytowanie pełnego paragrafu nijak się ma do wyrywania z kontekstu.
Ciekawi mnie jescze jedna sprawa - otóż zwiększając ilość bitów powinniśmy proporcjonalnie uzyskać coraz lepszy stosunek sygnału do szumu. Tymczasem na mojej Amidze obserwowałem odwrotną tendencję lub w najlepszym wypadku brak różnic pomiędzy miksowaniem 8 a 14 bitowym.
I ostatnia sprawa - ten pomysł z samplowaniem na pececie i sprawdzaniem poprawności sygnałów. Nie wiem czy jakikolwiek sampler jest idealnie perfekcyjny. Być może do kalibracji mógłby posłużyć plik w którym naprzemiennie wchodziłby sygnał złożony z samych jedynek a następnie z samych zer. Przy odpowiednio zwiększonej częstotliwości próbkowania można by było zaobserwować przesunięcie sygnałów i je skorygować. Pytanie tylko czy Amiga jest w stanie tak dokładnie przesunąć odtwarzany dźwięk.
Ostatnia aktualizacja: 13.06.2021 21:50:19 przez XTD
Ciekawi mnie jescze jedna sprawa - otóż zwiększając ilość bitów powinniśmy proporcjonalnie uzyskać coraz lepszy stosunek sygnału do szumu. Tymczasem na mojej Amidze obserwowałem odwrotną tendencję lub w najlepszym wypadku brak różnic pomiędzy miksowaniem 8 a 14 bitowym.
I ostatnia sprawa - ten pomysł z samplowaniem na pececie i sprawdzaniem poprawności sygnałów. Nie wiem czy jakikolwiek sampler jest idealnie perfekcyjny. Być może do kalibracji mógłby posłużyć plik w którym naprzemiennie wchodziłby sygnał złożony z samych jedynek a następnie z samych zer. Przy odpowiednio zwiększonej częstotliwości próbkowania można by było zaobserwować przesunięcie sygnałów i je skorygować. Pytanie tylko czy Amiga jest w stanie tak dokładnie przesunąć odtwarzany dźwięk.
Ostatnia aktualizacja: 13.06.2021 21:50:19 przez XTD
13.06.2021 23:12
[#39]
Re: Amiga jednak Rulez - o dźwięku i modułach
@XTD, post #37
Tymczasem na mojej Amidze obserwowałem odwrotną tendencję lub w najlepszym wypadku brak różnic pomiędzy miksowaniem 8 a 14 bitowym.Dla mnie różnica była łatwo zauważalna, na korzyść 14 bit calibrated. Z tym, że testowałem to na materiale zrzuconym cyfrowo z płyt CD, a więc z próbkowaniem 44,1 kHz (zarówno 8 bitów jak i 16). Pomiary z dyskutowanego PDF-a też to potwierdzają, dając od 12 do 16 dB lepszy stosunek sygnału do szumu.
Pytanie tylko czy Amiga jest w stanie tak dokładnie przesunąć odtwarzany dźwięk.Opóźnienie jest poniżej 1 próbki sygnału, więc odpowiedź brzmi nie, przynajmniej nie sprzętowo. Ja opis z PDF-a rozumiem tak, że część mocy części LO (tej 6-bitowej) z danej próbki przechodzi do następnej. W związku z tym należałoby to skompensować przez wyliczanie faktycznie wysyłanej do Pauli części LO jako sumy próbki aktualnej i poprzedniej przemnożonych przez odpowiednie wagi. Wagi zależą tylko od opóźnienia, które jest stałe (bo wynika z PWM głośności, o stałej częstotliwości podstawowej 55,4 kHz).
13.06.2021 23:33
[#40]
Re: Amiga jednak Rulez - o dźwięku i modułach
@Krashan, post #39
Zaraz zaraz, po ludzku. Jak to część 6-bitowej próbki przechodzi do następnej? Przecież to jest dokładnie to, o czym pisałem! Nie da się ot tak przesuwać młodszych bitów do następnej próbki. Młodsze bity zwiększają dokładność TEJ KONKRETNEJ próbki, nie są zaś czymś, co można sobie doklejać do dowolnego bajtu, nawet następnego!
Ok, wyobraźmy sobie, że mamy wartości 31720 w 16-bitowym dźwięku, a następnie wartość 2320 (skala wartości to jak wiadomo -32768 do 32767). Żeby uzyskać dźwięk 8-bitowy dzielimy wartość przez 256. Otrzymujemy, zaokrąglając w dół - 123 i 9. Bez zaokrąglenia są to wartości 123,9063 oraz 9,0625. Jak widać wartość po przecinku jest o wiele większa dla pierwszej próbki, niż dla drugiej. Ta reszta z dzielenia to są właśnie dodatkowe młodsze bity. I teraz co - przenosimy pierwszą wartość 0,9063 jako wartość po przecinku dla wartości 9, bo mamy opóźnienie? W tym przypadku zniekształcamy wynik bardziej, niż gdybyśmy po prostu pozostawili zaokrąglenie w dół.
Liczę oczywiście na zrozumienie powyższego przykładu - nie chcę się rozpisywać i liczę na umiejętność powiązania analogii z dzieleniem do relacji między młodszymi i starszymi bitami. Raz jeszcze powtórzę - NIE DA SIĘ swobodnie przenosić poprzednich młodszych bitów do następnego bajtu. Tzn. da się, ale nie ma to żadnego sensu, chyba że chodzi nam o zwiększenie niedokładności i wprowadzenie elementu losowego.
Proponuję podzielić plik 16-bitowego monofonicznego dźwięku na dwa 8-bitowe sample - jeden zawierający wyłącznie starsze, a drugi młodsze bity. Tak spreparowane sample sugeruję odtworzyć sobie i zobaczyć dlaczego nie ma mowy o żadnym przenoszeniu próbek. Starsze bajty dadzą nam 8-bitowy dźwięk (wyliczony po chamsku poprzez usunięcie młodszych bitów), zaś młodsze bity dadzą na wyjściu szum, ponieważ same w sobie nie tworzą żadnej charakterystyki dźwięku, więc nie da się ich nanieść z jakimkolwiek przesunięciem, żeby uzyskać "mniej więcej lekką poprawę ilości bitów".
Ostatnia aktualizacja: 13.06.2021 23:39:15 przez XTD
Ok, wyobraźmy sobie, że mamy wartości 31720 w 16-bitowym dźwięku, a następnie wartość 2320 (skala wartości to jak wiadomo -32768 do 32767). Żeby uzyskać dźwięk 8-bitowy dzielimy wartość przez 256. Otrzymujemy, zaokrąglając w dół - 123 i 9. Bez zaokrąglenia są to wartości 123,9063 oraz 9,0625. Jak widać wartość po przecinku jest o wiele większa dla pierwszej próbki, niż dla drugiej. Ta reszta z dzielenia to są właśnie dodatkowe młodsze bity. I teraz co - przenosimy pierwszą wartość 0,9063 jako wartość po przecinku dla wartości 9, bo mamy opóźnienie? W tym przypadku zniekształcamy wynik bardziej, niż gdybyśmy po prostu pozostawili zaokrąglenie w dół.
Liczę oczywiście na zrozumienie powyższego przykładu - nie chcę się rozpisywać i liczę na umiejętność powiązania analogii z dzieleniem do relacji między młodszymi i starszymi bitami. Raz jeszcze powtórzę - NIE DA SIĘ swobodnie przenosić poprzednich młodszych bitów do następnego bajtu. Tzn. da się, ale nie ma to żadnego sensu, chyba że chodzi nam o zwiększenie niedokładności i wprowadzenie elementu losowego.
Proponuję podzielić plik 16-bitowego monofonicznego dźwięku na dwa 8-bitowe sample - jeden zawierający wyłącznie starsze, a drugi młodsze bity. Tak spreparowane sample sugeruję odtworzyć sobie i zobaczyć dlaczego nie ma mowy o żadnym przenoszeniu próbek. Starsze bajty dadzą nam 8-bitowy dźwięk (wyliczony po chamsku poprzez usunięcie młodszych bitów), zaś młodsze bity dadzą na wyjściu szum, ponieważ same w sobie nie tworzą żadnej charakterystyki dźwięku, więc nie da się ich nanieść z jakimkolwiek przesunięciem, żeby uzyskać "mniej więcej lekką poprawę ilości bitów".
Ostatnia aktualizacja: 13.06.2021 23:39:15 przez XTD
13.06.2021 23:45
[#41]
Re: Amiga jednak Rulez - o dźwięku i modułach
@Krashan, post #39
Jedynym programem jakim regularnie odtwarzałem coś w 14bit był SongPlayer, (inne nie przypadły mi do gustu), I pamiętam że miał opcje włącz/wyłącz AHI. Z włączonym mogłem przestawiać sposób odtwarzania w AHI mając do wyboru kilka sposobów na 14bit i kilka na 8bit. Pomiędzy niektórymi nie słyszałem różnicy, a pomiędzy innymi słyszałem ale nie umiałbym określić na czym ta różnica polega, i która brzmi lepiej, ale jak dla mnie to i tak najlepiej brzmiało gdy AHI wyłączałem. :)
Która wersja Protrackera miała opcje odtwarzania sampli 14bit?
Bo jeśli dobrze zrozumiałem ktoś tu wcześniej o tym pisał, i przyznam że mnie to dziwi.
PS.: Mam podłożoną piankę pod głośnikiem który stoi na półce, aby nie przenosiła wibracji na inne przedmioty które na tej półce stoją. :)
Ostatnia aktualizacja: 13.06.2021 23:54:03 przez ZbyniuR
Która wersja Protrackera miała opcje odtwarzania sampli 14bit?
Bo jeśli dobrze zrozumiałem ktoś tu wcześniej o tym pisał, i przyznam że mnie to dziwi.
PS.: Mam podłożoną piankę pod głośnikiem który stoi na półce, aby nie przenosiła wibracji na inne przedmioty które na tej półce stoją. :)
Ostatnia aktualizacja: 13.06.2021 23:54:03 przez ZbyniuR
14.06.2021 00:20
[#42]
Re: Amiga jednak Rulez - o dźwięku i modułach
@XTD, post #40
więc nie da się ich nanieść z jakimkolwiek przesunięciemOtóż da się. Wystarczy cyfrowo "przyspieszyć" sygnał LO o tyle ile jest opóźniony przez Paulę. Robiąc to w sofcie nie jesteśmy ograniczeni do przesunięć o całkowitą ilość próbek. Przykładowo, jeżeli Paula opóźnia sygnał LO o 1/4 próbki, to upsamplujemy ten sygnał x4 i wybieramy próbki (1, 5, 9, 13...). Oczywiście dla Amigi to będzie wymagające obliczeniowo, bo prawidłowy upsampling wymaga odpowiedniego filtru cyfrowego. Sam filtr można – dla określonej częstotliwości próbkowania – prekalkulować, ale jego wykonanie to tak czy inaczej kilkanaście mnożeń na próbkę. Motorolka się może troszkę spocić.
14.06.2021 00:24
[#43]
Re: Amiga jednak Rulez - o dźwięku i modułach
@XTD, post #40
Nie jest dokładnie tak jak piszesz, gdyż do kolejnej próbki przechodzi jedynie część mocy poprzedniej. Współczynnika przez który trzeba pomnożyć tą część ułamkową oczywiście nie znamy, trzeba by go wyznaczyć eksperymentalnie, ale bez wątpienia jest mniejszy od jeden (zależy od częstotliwości próbkowania, i jest tym bliższy jedności, im bliższa jest częstotliwość próbkowania wartości 55,4 kHz). Po drugie, raczej nie będziesz słyszał aż tak gwałtownych zmian w sygnale, w Twoim przykładzie kolejne próbki różnią się o blisko 50% amplitudy, co daje okres drgań czterech próbek (a to dla częstości próbkowania przykładowo 50 kHz daje 12,5 KHz, do tego amplituda akurat tej częstotliwości jest niska). Czyli o ile wraz ze wzrostem częstotliwości próbkowania rośnie wpływ danej próbki na kolejną, to jednak stają się one coraz mniej słyszalne (bo zbliżamy się do górnej granicy słyszalności, która wynosi kilkanaście kHz).
A po ostatnie, to błąd który wnosi samplowanie 8 bitowe (bo przecież też musisz wprowadzić zniekształcenia wynikające ze zbyt małej ilości poziomów sygnału) jest większy niż ten wniesiony przez połączenie kanałów i omawiany przez nas przesłuch między kolejnymi próbkami w najmłodszych 6 bitach.
Ostatnia aktualizacja: 14.06.2021 00:36:09 przez wali7
A po ostatnie, to błąd który wnosi samplowanie 8 bitowe (bo przecież też musisz wprowadzić zniekształcenia wynikające ze zbyt małej ilości poziomów sygnału) jest większy niż ten wniesiony przez połączenie kanałów i omawiany przez nas przesłuch między kolejnymi próbkami w najmłodszych 6 bitach.
Ostatnia aktualizacja: 14.06.2021 00:36:09 przez wali7
14.06.2021 08:00
[#44]
Re: Amiga jednak Rulez - o dźwięku i modułach
@wali7, post #43
Sorry wali7, ale nie rozumiem o czym piszesz. Zapewne skupiasz się na dźwięku i wpływie tych ułamkowych wartości na odsłuch, a ja mówię o matematyce!
Młodszy i starszy bajt są ze sobą powiązane - tworzą jedną wartość. Nie miesza się różnych młodszych i starszych bajtów - zapytaj kodera, dowolnego. W sklepie też wydają Ci Twoją resztę, a nie resztę klienta, który był przed Tobą.
Przedstawię to może na bardziej obrazowym przykładzie. Wyobraźmy sobie, że masz sześciany ułożone jeden za drugim. Są one ułożone w linii prostej, ale niedokładnie - jeden jest odrobinkę przesunięty w lewo, drugi w prawo itd.
I chciałbyś je wyrównać. Dla każdego z nich więc dokładnie suwmiarką mierzysz te mikroprzesunięcie, spisujesz i wydajesz polecenie pracownikowi, żeby przesunął każdy z nich o podaną wartość z listy - pierwszy o 0,2 cm, drugi o 0,05 cm, trzeci o -1,2 cm itd. Pracownik przesuwa je, ale błędnie - pierwszy o wartość drugą, drugi o wartość trzecią itd. Zamiast ładnie ułożonych sześcianów w linii masz więc coś zupełnie przypadkowego - może się ułożą lepiej, a może będą stały jeszcze bardziej nierówno.
Te mikroprzesunięcia to właśnie młodsze bity. Analogia może niezbyt pasująca, ale za to może w końcu jasno pokazująca, że się nie da przesunąć bitów.
Młodsze bity nie zawierają w sobie żadnej charakterystyki dźwięku, więc nie mogą służyć jako dodatkowy sygnał wygładzający! Są nierozerwalnie związane ze starszymi bitami i tylko wówczas mają sens.
To, o czym piszesz, być może miałoby sens, gdybyśmy nanosili dwa sygnały dźwiękowe na siebie - jeden głośny, drugi bardzo bardzo cichy, ale jednak nadal będący dźwiękiem, jakimś rodzajem sygnału korygującego. Tutaj tego nie ma - tu jest czysta matematyka!
Oczywiście, że to są wszystko zmiany na granicy słyszalności - ale skoro mamy dodawać wartości, które coś zmienią na plus, to nie mogą to być wartości losowe dodawane na zasadzie "i tak nikt tego nie usłyszy".
@Kraashan: Ty też piszesz o tym, jakby to był jakiś dźwięk, pasmo które można przenieść. Ale młodsze bity nie tworzą same z siebie nic, nie ma co przesuwać i przenosić, nanosić "z lekkim opóźnieniem" itd.
Ostatnia aktualizacja: 14.06.2021 08:08:30 przez XTD
Młodszy i starszy bajt są ze sobą powiązane - tworzą jedną wartość. Nie miesza się różnych młodszych i starszych bajtów - zapytaj kodera, dowolnego. W sklepie też wydają Ci Twoją resztę, a nie resztę klienta, który był przed Tobą.
Przedstawię to może na bardziej obrazowym przykładzie. Wyobraźmy sobie, że masz sześciany ułożone jeden za drugim. Są one ułożone w linii prostej, ale niedokładnie - jeden jest odrobinkę przesunięty w lewo, drugi w prawo itd.
I chciałbyś je wyrównać. Dla każdego z nich więc dokładnie suwmiarką mierzysz te mikroprzesunięcie, spisujesz i wydajesz polecenie pracownikowi, żeby przesunął każdy z nich o podaną wartość z listy - pierwszy o 0,2 cm, drugi o 0,05 cm, trzeci o -1,2 cm itd. Pracownik przesuwa je, ale błędnie - pierwszy o wartość drugą, drugi o wartość trzecią itd. Zamiast ładnie ułożonych sześcianów w linii masz więc coś zupełnie przypadkowego - może się ułożą lepiej, a może będą stały jeszcze bardziej nierówno.
Te mikroprzesunięcia to właśnie młodsze bity. Analogia może niezbyt pasująca, ale za to może w końcu jasno pokazująca, że się nie da przesunąć bitów.
Młodsze bity nie zawierają w sobie żadnej charakterystyki dźwięku, więc nie mogą służyć jako dodatkowy sygnał wygładzający! Są nierozerwalnie związane ze starszymi bitami i tylko wówczas mają sens.
To, o czym piszesz, być może miałoby sens, gdybyśmy nanosili dwa sygnały dźwiękowe na siebie - jeden głośny, drugi bardzo bardzo cichy, ale jednak nadal będący dźwiękiem, jakimś rodzajem sygnału korygującego. Tutaj tego nie ma - tu jest czysta matematyka!
Oczywiście, że to są wszystko zmiany na granicy słyszalności - ale skoro mamy dodawać wartości, które coś zmienią na plus, to nie mogą to być wartości losowe dodawane na zasadzie "i tak nikt tego nie usłyszy".
@Kraashan: Ty też piszesz o tym, jakby to był jakiś dźwięk, pasmo które można przenieść. Ale młodsze bity nie tworzą same z siebie nic, nie ma co przesuwać i przenosić, nanosić "z lekkim opóźnieniem" itd.
Ostatnia aktualizacja: 14.06.2021 08:08:30 przez XTD
14.06.2021 08:46
[#45]
Re: Amiga jednak Rulez - o dźwięku i modułach
@XTD, post #44
Ty też piszesz o tym, jakby to był jakiś dźwięk, pasmo które można przenieść. Ale młodsze bity nie tworzą same z siebie nic, nie ma co przesuwać i przenosić, nanosić "z lekkim opóźnieniem" itd.Dźwięku to może i nie tworzą, ale sygnał – jak najbardziej. Popatrz sobie jak działa np. kodek FLAC. Tam też sygnał jest rozdzielany na część główną, którą ogarnia predyktor, oraz to co zostaje (tzw. residuum). Te dwa sygnały są zapisywane do pliku w zupełnie inny sposób i przetwarzane oddzielnie. A jednak w dekoderze składają się z powrotem w oryginał i to co do bitu, bo jak wiesz FLAC jest formatem bezstratnym. A jak puścisz sobie samo residuum, to też dostaniesz szum. To co, może powiesz, że FLAC oszukuje, bo "dodaje szum do sygnału na wyjściu, a nam się wydaje, że jest bezstratnie"? Tylko dlaczego plik po zakodowaniu i zdekodowaniu FLAC-em zawiera identyczne próbki jak oryginał?...
W naszym temacie mamy sytuację w pełni analogiczną, wzięcie 8 starszych bitów, to prymitywny "predyktor", niższe 6 bitów to residuum. No i tak się składa, że układ odtwarzający opóźnia residuum o jakąś ułamkową część sampla. Więc przesuwasz ten sygnał o tę ułamkową część i kompensujesz to.
Weźmy Twój przykład z sześcianami. Co robi ten tryb 14-bit? Ano bierze 8-bitową piłę i obcina wszystkie kawałki mniejsze od najmłodszego bitu w kanale HI. Te obrzynki potem idą przez kanał LO. Ale pech chce, że tam jest opóźnienie. Czyli część pola obrzynka (co odpowiada energii sygnału) z sześcianu 1 jest odtwarzana wraz z sześcianem 2. I tak dalej. Ale można te obrzynki dodatkowo poprzecinać i poprzekładać kawałki w taki sposób, że do każdego sześcianu - mimo opóźnienia - trafi taka powierzchnia obrzynków, jak oryginalne obrzynki bez opóźnienia. Czysta matematyka. Wystarczy znać wartość opóźnienia. W ten sposób, mimo że ani "sygnał obrzynków" ani "sygnał pociętych i poprzekładanych obrzynków" nie są według Ciebie dźwiękiem, to złoży się to w oryginał, a opóźnienie zostanie skompensowane.
Ostatnia aktualizacja: 14.06.2021 08:53:27 przez Krashan
14.06.2021 08:59
[#46]
Re: Amiga jednak Rulez - o dźwięku i modułach
@Krashan, post #45
Ok, rozumiem ideę kompensowania opóźnienia, żeby bity trafiały w odpowiednie miejsce.
Tylko dwa pytania:
1. Czy obecny system AHI to potrafi? Przecież dumnie nazywa się 14-bit, a nie sądzę, że wykonuje te wszystkie skomplikowane obliczenia, przy których - jak sam stwierdziłeś - Motorolka by się spociła.
2. Czy w ogóle jest to do zrobienia na Amidze, nawet gdy Motorola się spoci?
Jeszcze jedno - FLAC składa sygnał i wypuszcza go przez przetwornik 16/24 bitowy, więc nie musi niczego kompensować, jedynie złożyć do kupy wszystkie bity. To zupełnie inna metoda, niż próba puszczania dwóch dźwięków naraz w idealnej synchronizacji.
Ostatnia aktualizacja: 14.06.2021 09:08:21 przez XTD
Tylko dwa pytania:
1. Czy obecny system AHI to potrafi? Przecież dumnie nazywa się 14-bit, a nie sądzę, że wykonuje te wszystkie skomplikowane obliczenia, przy których - jak sam stwierdziłeś - Motorolka by się spociła.
2. Czy w ogóle jest to do zrobienia na Amidze, nawet gdy Motorola się spoci?
Jeszcze jedno - FLAC składa sygnał i wypuszcza go przez przetwornik 16/24 bitowy, więc nie musi niczego kompensować, jedynie złożyć do kupy wszystkie bity. To zupełnie inna metoda, niż próba puszczania dwóch dźwięków naraz w idealnej synchronizacji.
Ostatnia aktualizacja: 14.06.2021 09:08:21 przez XTD
14.06.2021 09:08
[#47]
Re: Amiga jednak Rulez - o dźwięku i modułach
@XTD, post #44
Młodsze bity nie zawierają w sobie żadnej charakterystyki dźwięku, więc nie mogą służyć jako dodatkowy sygnał wygładzający! Są nierozerwalnie związane ze starszymi bitami i tylko wówczas mają sens.
Na wyjściu z Amigi otrzymujesz na jednym kanale sygnał o poziomie równym sumie 8HI oraz 6LO w jednostce czasu. Jeśli 6LO jest przesunięte, załóżmy że dokładnie o połowę jednostki wcześniej to na wyjściu otrzymasz
8HI-1 +1/2(6LO-1) + 1/2 (6LO-2). Jest to suma połowy właściwej LO6 i połowy wcześniejszej.
Znając opóźnienie w jednostce czasu można wyliczyć wagi dla tych dwóch próbek.
Ostatnia aktualizacja: 14.06.2021 09:14:52 przez Kefir_Union
14.06.2021 09:27
[#48]
Re: Amiga jednak Rulez - o dźwięku i modułach
@Krashan, post #45
Tak czytam, i zastanawiam się nad tym z innej beczki - czy w odstępach czasowych rzędu mikrosekund te przebiegi tak bardzo się różnią, żeby miało znaczenie, który paruje się z którym?
Porównuję to sobie do szybkiej kamery, z którą czasem mam do czynienia. Przy dziesiątkach tysięcy fps potrzeba naprawdę dynamicznych procesów, żeby dwie sąsiednie klatki różniły się istotnie.
Porównuję to sobie do szybkiej kamery, z którą czasem mam do czynienia. Przy dziesiątkach tysięcy fps potrzeba naprawdę dynamicznych procesów, żeby dwie sąsiednie klatki różniły się istotnie.
14.06.2021 09:31
[#49]
Re: Amiga jednak Rulez - o dźwięku i modułach
@XTD, post #46
Czy obecny system AHI to potrafi?Nie i nie robi tego. Wczoraj przebrnąłem przez cały wątek (15 stron...) z EAB przylinkowany przez DonAdana, gdzie gość właśnie z tym walczy. Kłopot jest ten, że nie mamy wewnętrznego schematu Pauli, więc wiemy tylko to co zmierzymy i przypuszczamy, bazując na wiedzy z opisów technicznych Pauli oraz jak się projektuje takie układy. Opóźnienie między kanałami wydaje się też zależeć od trybu graficznego itd. Autor wspomnianego wątku próbował przede wszystkim sprzętowo opóźnić start kanału HI, żeby wyrównać go z LO, ale chyba mu się w końcu nie udało. Albo udało częściowo.
To co AHI robi w tej chwili, to kompensacja niedokładności charakterystyki samego DAC-a. Przy czym opóźnienie międzykanałowe wpływa również na kompensację i trudno powiedzieć, czy błędy kompensowania kasują się z błędami odtwarzania, czy sumują, bo to zależy od konkretnych sygnałów, tego używanego przy kompensacji i tego odtwarzanego potem.
Podsumowując (i tu się zgadzam z Richterem), nazwa "14-bit" jest nazwą techniczną, a w praktyce osiągamy efekt taki, jakbyśmy mieli zamiast Pauli prostego DAC-a 12-bitowego. Przynajmniej z punktu widzenia dynamiki i poziomu szumów.
Czy programowa kompensacja tego nieszczęsnego opóźnienia jest możliwa na Amidze? Na 060/Vampire zapewne tak, ale przy znaczącym obciążeniu procesora. Dla mnie, jako sprzętowca, trochę to się mija z celem, bo mniej obciąży procesor przepchanie tego audio np. przez clockport do 16-bitowego DAC-a, a efekt będzie lepszy. No i nawet 020 zdąży.
Podsumowując – mając do dyspozycji dużą moc obliczeniową można robić z sygnałem cuda, na przykład odtwarzać MP3 z dobrą jakością na 1-bitowym PC-speakerze. Z Pauli też możnaby pocisnąć np. prerenderując na PC plik audio przetworzony pod konkretny egzemplarz Amigi. Tylko jaki to ma sens, oprócz pokazania, że się da?...
14.06.2021 09:37
[#50]
Re: Amiga jednak Rulez - o dźwięku i modułach
@Daclaw, post #48
czy w odstępach czasowych rzędu mikrosekund te przebiegi tak bardzo się różnią, żeby miało znaczenie, który paruje się z którym?Tak. Dzieje się tak dlatego, że - w niewielkim uproszczeniu - słyszymy sygnał widmem, a nie przebiegiem czasowym. To wynika z budowy ucha i sposobu przetwarzania w mózgu tego, co z ucha dociera. A tak się składa, co pokazał pan Fourier, że niewielkie zmiany w przebiegu czasowym mogą dawać duże różnice w widmie. Tu nie ma analogii do wzroku i obrazów.
Nieprzypadkiem stratne formaty kompresji dźwięku usuwają informację po zamianie przebiegu czasowego na widmo. Z widma można wyrzucić więcej i łatwiej przewidzieć jak na to zareaguje zmysł słuchu.
Ostatnia aktualizacja: 14.06.2021 09:40:28 przez Krashan
14.06.2021 09:52
[#51]
Re: Amiga jednak Rulez - o dźwięku i modułach
@Krashan, post #49
Czy programowa kompensacja tego nieszczęsnego opóźnienia jest możliwa na Amidze? Na 060/Vampire zapewne tak, ale przy znaczącym obciążeniu procesora. Dla mnie, jako sprzętowca, trochę to się mija z celem, bo mniej obciąży procesor przepchanie tego audio np. przez clockport do 16-bitowego DAC-a, a efekt będzie lepszy. No i nawet 020 zdąży.
Jeśli opóźnienie jest stałe (wagi zawsze takie same dla kolejnych par) to sumę dwóch dowolnych ważonych próbek 6 bit można stablicować w 4kb i A500 się wyrobi.
14.06.2021 10:01
[#52]
Re: Amiga jednak Rulez - o dźwięku i modułach
@Kefir_Union, post #51
Jeśli opóźnienie jest stałe (wagi zawsze takie same dla kolejnych par) to sumę dwóch dowolnych ważonych próbek 6 bit można stablicować w 4kb i A500 się wyrobi.Tylko że prawidłowe przesunięcie sygnału o ułamek próbki wymaga nieco więcej obliczeń. Ważona suma to tak, jak resampling przez interpolację liniową - działa, ale sam wprowadza dodatkowe zniekształcenia. A ponieważ walczymy na dość niskich poziomach SNR to może się okazać, że upraszczając algorytm zwiększymy szumy zamiast zmniejszyć i cała batalia straci sens.
14.06.2021 10:43
[#55]
Re: Amiga jednak Rulez - o dźwięku i modułach
@Daclaw, post #48
Tak czytam, i zastanawiam się nad tym z innej beczki - czy w odstępach czasowych rzędu mikrosekund te przebiegi tak bardzo się różnią, żeby miało znaczenie, który paruje się z którym?
Już koledzy odpowiedzieli mądrze, ja odpowiem prościej i inaczej - jeżeli nie ma znaczenia który starszy bajt paruje się z którym młodszym, to cała idea dźwieku 14-bitowego nie ma sensu, ponieważ równie dobrze możnaby było odtwarzać dźwięk 8-bitowy dodając na drugim kanale losowe wartości - skoro i tak nie robi to większej róznicy (są to w końcu tylko młodsze bity, na granicy słyszalności). Ale jednak nie na tym polega dźwięk 14- czy 16-bitowy, że odtwarza się poprawnie 8 bitów i dokłada jakieś tam kolejne bity, żeby się ilość bitów zgadzała.
14.06.2021 10:59
[#56]
Re: Amiga jednak Rulez - o dźwięku i modułach
@XTD, post #55
Tak, jeśli się rozjedzie 8 i 6 bitów to wszystko to traci sens bo przestaje być to 14 bitowa próbka. Jeśli jednak mamy stałe, niewielkie opóźnienie, to oczywiście psuje nam to parametry przetwornika (czyli zaczyna szumieć jak 12, czy 10 bitowy, a nie 14 bitowy), ale nadal odstęp sygnału od szumu jest większy niż dla przetwornika 8 bitowego.
Reasumując, najlepiej byłoby porobić pomiary SNR dla różnych metod generowania dźwięku przez Ami. I wtedy byśmy wiedzieli.
Reasumując, najlepiej byłoby porobić pomiary SNR dla różnych metod generowania dźwięku przez Ami. I wtedy byśmy wiedzieli.
14.06.2021 11:14
[#57]
Re: Amiga jednak Rulez - o dźwięku i modułach
@Krashan, post #49
Wedlug mnie najpierw trzeba by byloby porobic testy na jakims dobrej jakosci samplu mono 16bitowym, czyli albo tylko kanaly lewe ( 1 i 4), albo prawe (2 i 3) odgrywac, z bufora 128KB. Sprawdzic rozne sposoby startowania kanalow. Jakie opoznienie jest (zawsze takie samo?) od czego zalezy (procesora, trybu graficznego itp). Wybrac kanal prowadzacy np. 1 czy 4. Ile ma wynosic takie opoznienie, zeby bylo optymalne. Moze odgrywac 1 pusty bajt na poczatku kanalu prowadzacego, zeby byla lepsza synchronizacja? Uzyc timera CIAB do precyzyjnego startu drugiego lub pierwszego kanalu, dac opoznienie programowe startu kanalu (iles NOP-ow, albo innych instrukcji, na Atari ST w demach uzywaja nawet po pareset NOPow, do synchronizacji kodu). Mozliwosci jest wiele, nie wiem czy on wszystkie dokladnie przetestowal. Nie znam angielskiego na tyle, zeby tam za duzo pisac.
14.06.2021 12:03
[#58]
Re: Amiga jednak Rulez - o dźwięku i modułach
@wali7, post #56
Nic nie zaczyna szumieć jak 10-, czy 12-bitowy, tylko po prostu szumi, bo jest źle.
Nadal widzę dyskutujemy tu o tym, że jest źle jak się rozjedzie młodszy i starszy bajt, ale jak się "tylko trochę rozjedzie" to jest ok. Tylko trochę jak się spóźnisz na pociąg to też jesteś szczęśliwy? "Spóźniłem się dosłownie 20 sekund, więc z Krakowa do Gdyni dojadę w 10 godzin; gdybym się nie spóźnił, to byłbym w 8 godzin jadąc tym samym pociągiem, a gdybym się mocniej spóźnił, to bym jechał 12 godzin". To tak nie działa - to działa zero/jedynkowo - albo masz 14 bitów (jedziesz pociągiem), albo ci całe 6 ucieka (nie jedziesz pociągiem). Nadal nie rozumiem jak można tyko trochę się spóźnić na pociąg i uważać, że podróż jest miła i przyjemna, siedząc na peronie.
Nadal widzę dyskutujemy tu o tym, że jest źle jak się rozjedzie młodszy i starszy bajt, ale jak się "tylko trochę rozjedzie" to jest ok. Tylko trochę jak się spóźnisz na pociąg to też jesteś szczęśliwy? "Spóźniłem się dosłownie 20 sekund, więc z Krakowa do Gdyni dojadę w 10 godzin; gdybym się nie spóźnił, to byłbym w 8 godzin jadąc tym samym pociągiem, a gdybym się mocniej spóźnił, to bym jechał 12 godzin". To tak nie działa - to działa zero/jedynkowo - albo masz 14 bitów (jedziesz pociągiem), albo ci całe 6 ucieka (nie jedziesz pociągiem). Nadal nie rozumiem jak można tyko trochę się spóźnić na pociąg i uważać, że podróż jest miła i przyjemna, siedząc na peronie.
14.06.2021 12:25
[#59]
Re: Amiga jednak Rulez - o dźwięku i modułach
@XTD, post #58
Nadal nie rozumiem jak można tyko trochę się spóźnić na pociąg i uważać, że podróż jest miła i przyjemna, siedząc na peronie.Też tego nie rozumiem. A także tego, co to ma wspólnego z odtwarzaniem dźwięku przez Paulę. Zapomniałeś, że każda analogia upraszcza, a im bardziej upraszcza, tym łatwiej jej otrzeć się o absurd.
Wzrost poziomu szumu wywołany przez ułamkowe opóźnienie młodszej połowy bajtu wobec starszej nie jest funkcją zerojedynkową, tylko ciągłą. A stwierdzenie, że mimo tego opóźnienia, zysk na SNR jest, opiera się na pomiarach, nie na wrażeniach.
14.06.2021 12:53
[#60]
Re: Amiga jednak Rulez - o dźwięku i modułach
@Krashan, post #59
W tym temacie jeden z kolegów napisał, że po wyłączeniu AHI i odtwarzaniu po prostu przez 8-bitową Paulę uzyskał najlepszy rezultat. W zasadzie podzielam jego pogląd - ja u siebie też nie potrafiłem usłyszeć poprawy jakości między 8- a 14-bitowym trybem AHI, ani też zmniejszenia poziomu szumów. Może dlatego, że nie było to dobrze skalibrowane.
Nadal jednak, mimo wszystkich teorii, nie wiem dokładnie jak można mówić o przesunięciu bitów "trochę" i dlaczego niby ok jest jak się tu czy tam doda złe wartości. Dla mnie dźwięk cyfrowy to dźwięk pozbawiony losowości, a młodsze bity to część pełnej wartości określanej przez bajt starszy i młodszy. Fajnie by było, gdyby ktoś to wytłumaczył nieco prościej, ale też zgodnie z informatyką i matematyką.
Ostatnia aktualizacja: 14.06.2021 12:57:35 przez XTD
Nadal jednak, mimo wszystkich teorii, nie wiem dokładnie jak można mówić o przesunięciu bitów "trochę" i dlaczego niby ok jest jak się tu czy tam doda złe wartości. Dla mnie dźwięk cyfrowy to dźwięk pozbawiony losowości, a młodsze bity to część pełnej wartości określanej przez bajt starszy i młodszy. Fajnie by było, gdyby ktoś to wytłumaczył nieco prościej, ale też zgodnie z informatyką i matematyką.
Ostatnia aktualizacja: 14.06.2021 12:57:35 przez XTD