AtariX, jeżeli nie jesteś zainteresowany wypróbowaniem a8cas-util pod linuksem (wbrew temu co napisał voy dekodowanie nagrań turbo to chyba główna funkcja a8cas-util), to się nie będę tu wtrącał ;), w przeciwnym razie też służę pomocą. Dekodowanie Blizzarda jest dobrze przetestowane.
Odpowiadając na wcześniejsze pytania:
1. istniejące narzędzia są rozwijane od lat, więc raczej szkoda poświęcać czas na tworzenie nowych od zera, co nie znaczy że z odpowiednimi umiejętnościami nie można stworzyć czegoś lepszego
2. opis formatu Blizzard (budowy nagrania) na atariki powstawał m.in. na podstawie analizy kodu handlera (liczyłem cykle zegara dla pętli odmierzających szerokości impulsów). Niemniej, jak tam jest wspomniane, w pewnym zakresie możliwe są odchylenia parametrów czasowych, handler dostosowuje się do rzeczywistej prędkości transmisji używając pierwszego (tego długiego) sygnału pilotującego
3. format z $FFFF na początku chyba nie nazywa się nijak oficjalnie, na atariki nazywa się Binarny plik DOS-u
4. do taśm w normalu narzędzia a8cas Krótkiego, a8cas-util (a jakże), albo legendarny wav2cas do prostych przypadków. Z tego co słyszałem Turgen też w jakimś stopniu obsługuje normal (nie próbowałem).
5. ... czasem mimo wszystko trzeba się pomęczyć.
Szumy w sygnale w przypadku nagrań turbo odgrywają marginalną rolę (w normalu zresztą też), w zasadzie moim zdaniem w ogóle nie trzeba się tym przejmować. Przerobiłem mnóstwo nagrań w normalu i różnych formatach turbo, i praktycznie nie korzystałem z opcji do obcinania szumów, którą dorobiłem na początku zmagań z a8cas-util.
Powody błędów dekodowania mogą być różne:
- uszkodzenia taśmy, miejscowe osłabienie sygnału lub całkowite zaniki sygnału na odcinku pojedynczych bitów
- chwilowe przesterowania sygnału (też na odcinku pojedynczych bitów)
- zbyt duża różnica w prędkości odtwarzania w stosunku do prędkości nagrywania; Turgen jest tu dość elastyczny, bo pozwala łatwo definiować własne zestawy opisujące szerokości impulsów - wystarczy w edytorze audio policzyć sample dla każdego typu ipulsu (pilot, zero, jeden) i utworzyć plik konfiguracyjny
- zniekształcenia sygnału, spowodowane np. różnicą w ustawieniu głowicy przy nagrywaniu i odtwarzaniu (bity "0" odpowiadające wyższej częstotliwości mogą być znacznie osłabione) lub wadami elektroniki; np. zdarza się że szerokie impulsy (pilot, jedynka) zyskują dodatkowe "brzuchy", które mogą być dekodowane jako bity '"zero" (zwykle duże wzmocnienie to kompensuje, ale z drugiej strony duże wzmocnienie może zepsuć coś innego)
- zniekształcenia wytwarzane przez filtry używane przez program dekodujący (np. za duże wzmocnienie, podbicie/wygaszenie niewłaściwych częstotliwości)
- suma kontrolna liczona według algorytmu innego niż standardowy (np. xor zamiast modulo256)
Blizzard jest jednym z najszybszych systemów turbo, przy częstotliwości próbkowania 48kHz różnia w szerokości impulsów "0" i "1" wynosi tylko kilka sampli, jest to więc dość czułe na nierównomierności prędkości przesuwu taśmy. Samplowanie na 96kHz może dać lepsze rezultaty, ale nie musi, natomiast sam proces dekodowania przy 96kHz działa lepiej niż przy 48kHz (przynajmniej w a8cas-util, jest programowo resamplowane).
Jeśli chodzi o samo zgrywanie kaset do wav to też nie ma uniwersalnej recepty. Czasem lepiej wychodzi, jak się sygnał przesteruje, żeby wyszła fala prostokątna, czasem o wiele lepiej jest zgrać tak, żeby nie tknąć wierzchołków fal, czasem jest lepiej ustawić dość cicho. Każdy przypadek może wymagać użycia różnych filtrów przy dekodowaniu i innych algorytmów przy resamplingu do wyższych częstotliwości (z interpolacją lub bez).
