Cześć, miłośnicy (i przeciwnicy) kaset.

Przy ostatniej fali tęsknoty za starymi dobrymi czasami mnie też wzięło właśnie na kasety i od jakichś dwóch miesięcy zamiast słuchać muzyki słucham kojącego ;) rzężenia magnetofonu.
Pomysł z obsługą plików .cas przez coś w rodzaju cas2sd niesamowicie mi się podoba i niewątpliwie zasponsoruję kogoś, kto by mi zmontował takie urządzonko jeżeli już wyjdzie z fazy projektów. Swoją drogą wydaje mi się, że dodanie przynajmniej podstawowej obsługi plików .cas na sio2sd chyba nie powinno być zbyt trudne, kupując sio2sd miałem nadzieję, że może kiedyś pojawi się stosowny update...

Kiedy jakiś czas temu przewinął mi się przed oczami tekst o emulatorze Altirra, w którym była deklarowana obsługa tasiemek w formie plików dźwiękowych, nad moją głową zapaliła się żaróweczka. Lubię się bawić dźwiękiem pod Linuxem, więc słowo "bandpass" wywołało natychmiastowe skojarzenie. Celem było przerobienie oryginalnego sygnału z taśmy na falę prostokątną, która by wiernie zachowywała wszystkie zależności czasowe, zabezpieczenia itp., czego klasyczny .cas nie umożliwia. Dodatkowy warunek to zero programowania ;). Po kilku tygodniach prób i błędów (testowanie wyników na żywo niestety wymaga czasu) osiągnąłem co chciałem. Potrzebne jest tylko kilka wtyczek LADSPA i - w moim rozwiązaniu - program ecasound. Konwersja w jedną bądź w drugą stronę w zasadzie wymaga jednej (choć długiej) linijki commandline-a. Efekt wygląda np. tak:

Pliki z wynikową falą prostokątną to zwykłe .wav-y (próbki 8-bitowe), więc zajmują dużo miejsca, ale niesamowicie dobrze się kompresują. Najlepiej ściska je bzip2, który pozwala zmniejszyć rozmiar ponad 300x, a w przypadku idealnych plików, z równiutkimi szerokościami bitów (czyli remasterowanych z plików .cas), nawet 700x. W efekcie taki plik często jest mniejszy niż odpowiadający mu nieskompresowany .cas.

Bez odrobiny programowania jednak się nie obyło. Potrzebowałem poza testami na prawdziwym sprzęcie czegoś, co by pozwoliło szybciej sprawdzać, czy osiągany efekt jest prawidłowy. Powstały zatem dwa skrypty w perlu, które pozwalają konwertować "kwadratowego" wav-a do formatu .cas i z powrotem. Okazuje się, że stary, dobry .cas z niewielkimi przeróbkami świetnie spełnia swoje zadanie dla wszystkich kaset, z którymi się zetknąłem. Jak to było wcześniej wspomniane, oprócz normalnych rekordów z danymi (krótszych bądź dłuższych) i przerw między nimi można się spotkać z "długimi zerami". Zapisuję to w odrobinę inny sposób, niż proponowany wcześniej, mianowicie:

7a 65 72 6f ; nagłówek 'zero'
02 00 ; długoś bloku 2 bajty
xx xx ; długość IRG przed 'zerem' w ms, jak w bloku 'data'
xx xx ; długość sygnału 'zero' w ms

Druga różnica w moich .cas-ach to częstsze zapisywanie bloków 'baud'. Wstawiam taki blok zawsze, gdy jest wykryta zmiana szerokości bitu (w samplach) w kolejnym bloku. Przy ładowaniu programów z prawdziwej kasety rożnice w prędkości są dość dobrze słyszalne (wyższe-niższe buczenie) i te różnice dla podniesienia wierności zapisu chyba warto zachować. Ta konkretna zmiana nawet nie przeszkadza obecnym emulatorom (testowane na atari800).

W kwestii synchronizacji kanału prawego i lewego - jeżeli poprzestać na konwersji do fali prostokątnej, to zależności czasowe zostają raczej wiernie zachowane. Czasem nawet zbyt wiernie i zbyt często pozwalają podziwiać napis "boot error" (dotyczy prędkości większych niż standardowa). Dla plików .cas, przy użyciu odpowiednich współczynników używanych przy konwersjach, najlepsze co się udaje osiągnąć to rozjazd około 0.6 s na 28 min nagrania. Taka różnica niespecjalnie przeszkadza, testowałem na "An Introduction to programming" i "Sammy the Sea Serpent". Nie da rady osiągnąć ideału z powodu zaokrągleń prędkości transmisji do pełnych bodów.

Nie ma specjalnych problemów z konwersją programów nagranych ze zwiększoną prędkością, czyli w przypadku "turbo" dla magnetofonów bez przeróbek. Testowałem do prędkości około 1200 baud.
Zaletą używanych filtrów bandpass, w przeciwieństwie do metody używanej przez wav2cas, jest to, że sygnał nie musi w ogóle przechodzić przez zero, żeby był poprawnie rozpoznany. Możliwe jest więc odczytanie sfatygowanych kaset z miejscowymi sporymi zniekształceniami sygnału (a czasem z miejscowymi prawie-zanikami sygnału, po wzmocnieniu w edytorze audio). Dość chyba powiedzieć, że np. wszystkie pliki dźwiękowe z tpp udaje się przekonwertować na pliki .cas, które po odwróceniu procesu dają się poprawnie załadować na prawdziwym sprzęcie (emu atari800 niestety nie zawsze daje sobie radę, na innych emulatorach nie próbowałem).

Jeżeli to kogoś interesuje - oto obecne wersje skryptów w archiwum zip: wav-square-cas.zip (link wygaśnie za jakiś miesiąc).

W środku znajdziecie:
wav2square.sh - konwersja oryginalnego wav-a na falę prostokątną
square2cas.pl - konwersja otrzymanego wyżej wav-a na plik .cas (+ log w formie czytelnej dla człowieka)
cas2square.pl - odwrotnie niż poprzedni
square2wav.sh - odwrotnie niż pierwszy

Skrypty shella opatrzone są komentarzami, perlowe mają własny help.

Zacząłem się przyglądać formatowi blizzard turbo pod kontem konwersji na .cas. Na razie wydaje mi się, że powinno być jeszcze prościej (wystarczy po prostu liczyć sample...?), ale drugiej strony, to co widzę w edytorze audio nie do końca mi się zgadza z opisem na Atariki. Dam znać, jak coś mi się uda z tym zrobić (a może nie warto tracić czasu ?).

A ze sprzętowych życzeń dotyczących cas2sd - żeby linia "motor control" była wykorzystywana do sterowania wirtualnym silnikiem (pauza/wznowienie odtwarzania .cas-a). Tego mi brakuje w sio2pc.