Krótki napisał/a:Powiedz lepiej jak te Twoje hacki z ecasound zintegrować ze źródłami w C (inaczej niż przez zrobienie exec() na programie ecasound)?
Nie ma żadnego libecasound. Programu ecasound używam w zasadzie jako hosta dla wtyczek LADSPA. A ecasound dlatego, że świetnie się daje wykorzystać z commandline-a. Tak naprawdę jedynym elementem oferowanym przez ecasound, którego nie udało mi się znaleźć w postaci plugina LADSPA, jest fitr bandreject (używany do odfiltrowania sygnału mark lub space, żeby lepiej się skupić na tym drugim), a ten filtr można by zastąpić parą highpass-lowpass. Jeżeli chcesz wykorzystać wtyczki LADSPA, to jak najbardziej jest to możliwe (czyli a8cas-convert działał by niejako zamiast ecasound). Na dole strony LADSPA, do której link jest w moim pierwszym poście, jest link do SDK i do pliku nagłowkowego opisującego API. Nie mam pojęcia, czy trudno się w to wgryźć, nie próbowałem i raczej nie będę próbował.
Krótki napisał/a:Czy KK ma niestandardowe rekordy? Jeśli konwersja a8cas do formatu HEX nie wykazuje błędów sumy kontrolnej, to najprawdopodobniej będzie wszystko OK.
Ta gra to jeden z największych oryginałów. Nie dość, że poza loaderem ma tylko jeden długi blok (43kB czy coś koło tego), to jeszcze nie widać, żeby była jakakolwiek suma kontrolna - sam loader chyba nie kontroluje, co się tam wczytuje :(. Można losowo pozmieniać bajty, a i tak nie pojawi się "load error". Problem z konwersją jest taki, że dump jest kiepskiej jakości, w trakcie trwania nagrania zmieniają się częstotliwości sygnałów mark i space (w zakresie do 200Hz), bo pewnie taśma była bardziej lub mniej rozciągnięta. Oznacza to, że zmieniają się szerokości bitów, a nie bardzo jest jak je korygować bez markerów.
Krótki napisał/a:Blok fsk jest pomyślany jako ostateczny ratunek, w którym możliwe jest zapisanie wszystkiego co się da. To co go różni od Twojego rozwiązania (czyli sekwencji następujących po sobie bloków zero, rozdzielanych b. krótkimi IRG) to dokładność - w bloku fsk jednostką jest 1/10 ms.
To nie do końca tak. Nie ma potrzeby rozdzielania bloków 'zero' (które ostatecznie miałem nazwać 'fsk0') bardzo krótkimi IRG. Po prostu takie przypadki się nie zdarzają, a jeżeli się zdarzają, to jest to zbędny szum. Po drugie - jak wiadomo zwykły atarowski magnetofon nie jest w stanie wyciągnąć więcej niż 1400 bodów (jak ktoś ma szczęście). Przy tej prędkości szerokość jednego bitu to okolice 0.7 ms. Oznacza to, że coś, co mogło by posłużyć za zabezpieczenie, praktycznie nie może być krótsze niż 1 ms. Jeżeli jest coś krótszego, to raczej zostanie potraktowane jako szum, który pewnie jakiś kondensator w magnetofonie zniweluje. Przykład - "Polskie Logo" - po pierwszym bloku drugiej części nagrania są w pewnym odstępie cztery bajty 0. Tuż przed nimi jest jeszcze bardzo krótki sygnał (zapewne niezamierzony), którego obecność lub brak nijak nie wpływa na działanie tego zabezpieczenia.
Ale to wszystko tylko gwoli wyjaśnienia piszę, ogólnie nic nie mam przeciw robieniu czegoś na zapas, jeżeli nie wprowadza to niepotrzebnych komplikacji. A to nie wprowadza komplikacji i podoba mi się.
Krótki napisał/a:]
Życzę powodzenia. Czy widziałbyś siebie w roli programisty C współtworzącego projekt A8CAS? ;) Mnie nie starczy czasu na zajmowanie się turbami.
Właściwie w ogóle nie widzę się w roli jakiegokolwiek programisty :P, choć od czasu do czasu zdarza mi się dodać parę bugów tu i ówdzie. Nie odmawiam pomocy, ale też nie mogę niczego obiecać, również ze względu na brak czasu (czytaj - ze względu na priorytety). Sygnał turbo tak naprawdę jest banalny do przetwarzania, jest znacznie czystszy niż ten standardowy i wystarczy wykrywać jego kolejne zbocza. Przeszkodą może być natomiast znacznie większa podatność na uszkodzenia, bo każdy jeden okres fali niesie konkretną informację.
Krótki napisał/a:Blok 'data' został pomyślany jako blok zaczynający się sygnałem IRG i zawierający dowolną liczbę bajtów,
Hmmm... w oryginalnej dokumentacji tak jest opisany, bo inne możliwosci nie były przewidziane. Tymczasem blok 'data' mówi tylko, że oto mamy tyle i tyle bajtów danych poprzedzonych przerwą trwającą tyle i tyle. Nie ma tam nic o częstotliwościach i rodzaju modulacji. Ale upierać się nie będę.
Krótki napisał/a:każdy zakodowany w postaci 10-bitowej (bit startu, 8 bitów danych, bit stopu) - gdzie zera i jedynki mają ściśle określone częstotliwości ~3995 i ~5327 Hz.
A to już w wav-ie, a nie w pliku .cas, a wynika to z interpretacji bloku 'data' przez aplikację, a nie z samej zawartości bloku 'data'.
Ale się nie upieram.
Krótki napisał/a:Dlaczego nie identyfikować typu turba po typie bloku?
Erm... Bo w jednym pliku .cas nie będzie kilku turb naraz ? (choć może być loader w standardzie i reszta w turbo) Albo bardziej - bo jedno turbo przy takim podejściu może mieć 2-3 typy bloków ? Ja miałem na myśli blok 'form' jako "przełącznik", który informuje aplikację, co ma robić z blokami 'data', które napotka za blokiem 'form'...
Ale tu też się nie upieram. Hmmm... czyli bloki 'bliz', 't2k ' itp. + legenda w README ? Albo blok 'tur ' + typ turba w bajtach aux ? Można popróbować, choć mnie z kolei jakoś nie przekonuje mnożenie różnych typów bloków.
Krótki napisał/a:Jest to znacznie prostsze niż bawić się przy odczycie w porównywanie stringów (...)
A sprawdzanie typu bloku to nie porównywanie stringów :P ? I tak to trzeba robić.
Krótki napisał/a:(o 'csum')
Nie bardzo wiem czemu to miałoby służyć. Przecież jeśli masz plik CAS to nie uszkodzi się on samoczynnie, prawda?
No cóż, jest piątek, do tego prawie północ, korci mnie, żeby podwyższyć poziom abstrakcji teoriami o neutrinach przelatujących przez powierzchnię twardego dysku :D.
...
(bierze się w garść)
...
Sam się nie uszkodzi, ale może się uszkodzić np. przy przesyłaniu przez internet, albo może go uszkodzić jakiś złośliwiec i rozprowadzić wśród nieświadomych atarowców-amatorów, tudzież doczepić tam wirusa, który zainfekuje Outlooka (skup się, skup się... - to do siebie).
(i tu próbowałem zanleźć jakieś inne argumenty, ale ponieważ z genów jestem kiepskim mówcą, to nie znalazłem. 'csum' wypada z gry.)
Dobranoc.
@pavros:
Ad. 2: To raczej emulator należało by poprawić, żeby był bardziej zgodny z oryginałem. Z biblioteką Krótkiego każdy emulator powinien sobie radzić (prawie) tak dobrze, jak atari z magnetofonem.
Ad.1: Już zasypiam, więc wybacz jeżeli majaczę. O jakich plikach "binarnych" piszesz i w jakim celu chcesz je oddzielać od całości cas-a, który jest jedną całością ? A BTW - zamierzam swój nowy skrypt perlowy (który ma połączyć te dotychczasowe i nowe w jeden) wyposażyć w różne funkcje do manipulacji plikami cas, w tym np. podział na pojedyncze rekordy do oddzielnych plików i składanie ich do kupy (na razie nie piszę po co, choć to tylko jedno zdanie), tudzież xex<-> cas dla nagrań typu "z wykrzyknikiem", więc jestem otwarty na dziwne propozycje (bez skojarzeń proszę). A w przypdku turbo, które z reguły zawierają coś, co można nazwać xex, to ja tworzę xex mimochodem przy okazji tworzenia cas-a.
Dobranoc.