Autore Topic: NUOVO DUMP : Byte games numero 01 (lato c64 7 su 7) (lato C16 serie difficoltà)  (Letto 8542 volte)

fab

  • Utente di edicolac64.com
  • *
  • Post: 424
quella dumpata col DC2N fa sì che il VICE faccia il parse e mostri i nomi dei file nella finestra, mentre quella dumpata con MTAP no.
Secondo voi da cosa può dipendere?
Quella cassetta è piena di errori. Ci sono un sacco di impulsi spezzati in due, uno poco più corto del normale e uno brevissimo. In realtà, la domanda è perché funziona sull'emulatore. Una possibile risposta è che gli impulsi brevissimi vengano semplicemente saltati, in un certo senso correggendo l'errore.
E' fattibile pensare a qualcosa che possa correggere il problema in automatico se si presentasse di nuovo o in questi casi l'unica è ridumpare col DC2N (o lasciar perdere)?
Si fa prima a ridumpare col DC2N.

Massi cadenti

  • Non dimenticatevi *MAI* nei vostri dump del Vic20 e soprattutto del C16/+4!!!
  • Administrator
  • Utente di edicolac64.com
  • *****
  • Post: 884
    • http://massicadenti.altervista.org/algasoft.html
Quella cassetta è piena di errori.
Intendi la versione dumpata con MTAP?

Si fa prima a ridumpare col DC2N.
Lo sospettavo...
I'M *DC2N* POWERED (tnx Luigi Di Fraia) - La mia collezione di cassette (non per vendita né scambio)
PER GLI ACQUISTI NEL MERCATINO IO PAGO SOLO CON PAYPAL E LA COMMISSIONE E' A CARICO VOSTRO

fab

  • Utente di edicolac64.com
  • *
  • Post: 424
Intendi la versione dumpata con MTAP?

Massi cadenti

  • Non dimenticatevi *MAI* nei vostri dump del Vic20 e soprattutto del C16/+4!!!
  • Administrator
  • Utente di edicolac64.com
  • *****
  • Post: 884
    • http://massicadenti.altervista.org/algasoft.html
Questa presunta imprecisione, che non sapevo di che tipo fosse, l'avevo sempre sospettata nei dump con mtap da questo pc... ed è stato un motivo in più che mi ha convinto a comprare il DC2N... Non è possibile ipotizzare in tapclean una correzione in automatico del problema, come avviene (meglio: come sembrerebbe avvenga) sull'emulatore?
Un'ultima cosa: ci sono novità per quanto riguarda invece la cassetta di cui stiamo parlando dall'inizio del thread?
« Ultima modifica: 28 Novembre 2011, 23:46:31 da Massi cadenti »
I'M *DC2N* POWERED (tnx Luigi Di Fraia) - La mia collezione di cassette (non per vendita né scambio)
PER GLI ACQUISTI NEL MERCATINO IO PAGO SOLO CON PAYPAL E LA COMMISSIONE E' A CARICO VOSTRO

fab

  • Utente di edicolac64.com
  • *
  • Post: 424
ci sono novità per quanto riguarda invece la cassetta di cui stiamo parlando dall'inizio del thread?
Ritoccando a mano il WAV con Audacity, ho fatto funzionare la presentazione e il primo gioco, Fast Food. Ma il ritocco a mano è lungo e non ho il tempo per continuare.

Massi cadenti

  • Non dimenticatevi *MAI* nei vostri dump del Vic20 e soprattutto del C16/+4!!!
  • Administrator
  • Utente di edicolac64.com
  • *****
  • Post: 884
    • http://massicadenti.altervista.org/algasoft.html
Ritoccando a mano il WAV con Audacity, ho fatto funzionare la presentazione e il primo gioco, Fast Food. Ma il ritocco a mano è lungo e non ho il tempo per continuare.
Servirebbe un qualcosa che lo faccia in automatico :\
I'M *DC2N* POWERED (tnx Luigi Di Fraia) - La mia collezione di cassette (non per vendita né scambio)
PER GLI ACQUISTI NEL MERCATINO IO PAGO SOLO CON PAYPAL E LA COMMISSIONE E' A CARICO VOSTRO

strongboy

  • voglio la giornata di 36 ore
  • Global Moderator
  • Utente di edicolac64.com
  • ****
  • Post: 1189
  • peace & love
Lancio una piccola idea . . . Qualcuno che possiede il cavo MTAP e che quindi usa questo metodo di conversione per generare i tap . . . non potrebbe provare a registrare una cassetta con il wave che ho messo su megaupload e provare a convertire ? ? ?
 :boo:

NEW SPECIAL PLAYGAMES riviste mancanti : 13,15
I MAGNIFICI CINQUE/SETTE riviste mancanti 9,19,21,22,29,30,31,32,33

Massi cadenti

  • Non dimenticatevi *MAI* nei vostri dump del Vic20 e soprattutto del C16/+4!!!
  • Administrator
  • Utente di edicolac64.com
  • *****
  • Post: 884
    • http://massicadenti.altervista.org/algasoft.html
Lancio una piccola idea . . . Qualcuno che possiede il cavo MTAP e che quindi usa questo metodo di conversione per generare i tap . . . non potrebbe provare a registrare una cassetta con il wave che ho messo su megaupload e provare a convertire ? ? ?
 :boo:
E cosa dovrebbe dimostrare? Il problema non è la generazione del tap ma il crearne uno funzionante. Se il WAV non è buono, neanche la cassetta verrà mai letta correttamente, né dalle macchine originali, né da un MTAP o DC2N che sia. Non è che quando metti il wav sulla cassetta si creano i pezzi mancanti o si sistemano i volumi da soli. La cosa migliore in questi casi sarebbe sistemare il wav in qualche modo oppure ridumpare la prima cassetta con un altro sistema.
Temo di non avere ben capito il motivo, perché a me sembra lapalissiano che se parti da un wav corrotto creerai una cassetta non funzionante e quindi anche i dump creati da quella cassetta non funzioneranno. Se invece si parla di sistemare il wav, la cosa migliore sarebbe non rimetterlo su una cassetta ma lavorare sul file in digitale. Come ha provato a fare Fabrizio. Il problema è che farlo a mano prende tempo e fatica, se è una questione di volumi come ho detto serve qualcosa che possa farlo in automatico (si spera una prossima versione di Audiotap che faccia un normalize banale anche di "pezzi" di tap, oppure qualcosa tipo cool edit o audacity che però faccia il normalize portando al massimo volume tutto il wav e non quindi basandosi solo sui picchi).
Ovviamente, il discorso sarebbe diverso se per ridumpare con MTAP o DC2N si partisse non da una cassetta ricreata dal wav corrotto, ma dalla cassetta originale. In questo modo si eliminano quantomeno i problemi relativi alla tua conversione.
« Ultima modifica: 27 Dicembre 2011, 20:57:42 da Massi cadenti »
I'M *DC2N* POWERED (tnx Luigi Di Fraia) - La mia collezione di cassette (non per vendita né scambio)
PER GLI ACQUISTI NEL MERCATINO IO PAGO SOLO CON PAYPAL E LA COMMISSIONE E' A CARICO VOSTRO

fab

  • Utente di edicolac64.com
  • *
  • Post: 424
si spera una prossima versione di Audiotap che faccia un normalize banale anche di "pezzi" di tap
Come dovrebbe funzionare?
Audiotap già adesso si adatta al volume: se il volume è basso, cerca livelli sonori più bassi. I problemi sopraggiungono quando ci sono abbassamenti di volume repentini. Se il volume è alto, la "sensitivity" va tenuta bassa, per filtrare il rumore. Ma se c'è un abbassamento improvviso, si può perdere un'onda. Allora si alza la "sensitivity" per evitare di perderla, e incrociare le dita che non ci sia rumore altrove.

Massi cadenti

  • Non dimenticatevi *MAI* nei vostri dump del Vic20 e soprattutto del C16/+4!!!
  • Administrator
  • Utente di edicolac64.com
  • *****
  • Post: 884
    • http://massicadenti.altervista.org/algasoft.html
Come dovrebbe funzionare?
Mettendo un'opzione per attivare un analizzatore del volume di ogni frammento del wav e non dell'intero wav o dell'intero programma che si sta tentando di convertire. Quindi se il volume si abbassa repentinamente solo per mezzo secondo e poi torna normale, questa opzione farebbe sì che venisse alzato solo quel mezzo secondo lasciando inalterato il resto. Farlo a mano è fattibile (del resto tu stesso c'eri riuscito), ma per farlo in automatico servirebbe quantomeno un algoritmo che analizzi se quell'abbassamento provoca o meno problemi (perché potrebbe trattarsi di un silenzio tra due programmi) e ovviamente regolare il volume solo nel caso in cui sia un tutt'uno.
Non so se riesco a farmi capire bene, purtroppo. Per come la vedo io dal punto di vista teorico è una stupidaggine, è la sua applicazione pratica che è complicata. Forse ci sarà un motivo per cui nessun editor audio preveda una cosa del genere ma si preveda solo un normalize su un pezzo intero prendendo come riferimento il picco massimo. Diciamo che io intendo un normalize per ogni decimo di secondo, vista così forse è più semplice ma resta comunque il problema di capire se è il caso di normalizzare o no, e questo non so se è fattibile in automatico, dipende quanto sia "intelligente" (o "stupido") audiotap. ;)
I'M *DC2N* POWERED (tnx Luigi Di Fraia) - La mia collezione di cassette (non per vendita né scambio)
PER GLI ACQUISTI NEL MERCATINO IO PAGO SOLO CON PAYPAL E LA COMMISSIONE E' A CARICO VOSTRO

fab

  • Utente di edicolac64.com
  • *
  • Post: 424
Audiotap ha un minimo di intelligenza. Come detto, se ci sono abbassamenti di volume, si adatta a riconoscere onde più piccole. Quindi, quello che tu chiedi viene già fatto.

Questo funziona solo se gli abbassamenti non sono troppo rapidi. Aumentare la "sensitivity" significa aumentare la rapidità massima di adattamento: con "sensitivity" più alta, Audiotap si adatta anche quando l'abbassamento di volume è rapido.

Il problema non è l'abbassamento in sé, è il fatto che con "sensitivity" alta non si riesce ad eliminare il rumore.

Per il ritocco a mano, la conoscenza del volume non è sufficiente. I plug-in di WAV-PRG si "aspettano" onde entro certi intervali di durata (Audiotap non è a conoscenza di ciò). Se arriva un'onda anomala, e il WAV editor mostra volume basso in quel punto, si aumenta la sensitivity. Il problema è che, aumentando la sensitivity, si possono creare onde anomale dove il volume è alto ma disturbato, e in quel caso non resta che ritoccare l'onda a mano per eliminare il disturbo. Quindi, il ritocco a mano agisce dove il volume è alto, non dove è basso.

Riassumendo, non credo che dal tuo suggerimento possano nascere miglioramenti pratici per Audiotap.

fab

  • Utente di edicolac64.com
  • *
  • Post: 424
Riassumendo, quando Audiotap trova un'onda "piccola" (con "piccola" si intende "alta meno della metà dell'onda precedente"):
  • se la sensitivity è 0 (minima), l'onda viene considerata rumore e ignorata
  • se la sensitivity è 100 (massima), l'onda viene tenuta in conto, non importa quanto sia basso il volume
  • per valori intermedi, dipende da quanto l'onda è piccola. Ad esempio, se la sensitivity è maggiore di 0 ma bassa, un'onda alta poco meno della metà della precedente verrà considerata, se la sensitivity è quasi 100 ma non 100 tutte le onde tranne le più piccole verranno considerate.
Un modo per realizzare l'idea di Massi cadenti è quella di non considerare la sensitivity ma il volume del segnale: se è alto, ignorare le onde piccole, se è basso, considerarle. Però, come si fa? Tenere una statistica dei valori di picco precedenti? Non ho idee, suggerimenti concreti sono benvenuti.

Massi cadenti

  • Non dimenticatevi *MAI* nei vostri dump del Vic20 e soprattutto del C16/+4!!!
  • Administrator
  • Utente di edicolac64.com
  • *****
  • Post: 884
    • http://massicadenti.altervista.org/algasoft.html
In effetti è molto più complicato di come pensavo. Abituato a manipolare i segnali audio (musicali) trovavo la cosa semplice da spiegare ma quando andiamo a parlare di dati (sia pure in forma di audio) la cosa diventa molto più complessa perché bisogna essere precisi.
Il problema è distinguere, al solito, il rumore dal segnale importante.
Ci si può basare sulla presenza o meno di una nota, ma alcuni turbo verrebbero ignorati.
Ci si può basare sulla forza del segnale ed è in effetti l'approccio che già c'è. Si può però tentare un ragionamento inverso. Posto che all'inizio sia presente un po' di silenzio che in realtà silenzio non è ma è solo rumore di fondo, si potrebbe usare quel livello per considerare l'ampiezza delle onde da considerare rumore e quelle da considerare segnale. In pratica prendere il primo mezzo secondo del file o quello tra un blocco e un altro e analizzare il livello di quelle onde. Per fare un esempio pratico ho preso un pezzo tra un blocco e un altro:

Il punto però secondo me, anche eliminando il rumore tra un blocco e un altro, è eliminare il rumore di fondo "sotto" i dati veri e propri. Parte del rumore viene tollerato comunque, ma se questo rumore è eccessivo (e credo sia il caso della cassetta in questione) no. E' il motivo per cui all'epoca c'erano difficoltà nel copiare i giochi usando un classico radioregistratore (non impianto hi-fi) a "doppia piastra" ed era necessario ricorrere al famoso duplicatore coi due datassette collegati tra loro.
Però, se davvero fosse il rumore il problema, il tap v1 non dovrebbe essere letto, mentre viene letto (ovviamente senza le parti in turbo). Il tap v2 invece non viene letto per niente. E' chiaro che il tap v2 è più preciso però non è chiaro perché nemmeno le parti in kernal loader funzionano.
Quando hai ritoccato a mano arrivando a far funzionare il primo gioco, che cambiamenti avevi apportato con audacity? Avevi alzato il volume dov'è basso e basta?
Puoi farmi un esempio di abbassamento repentino di volume postandomi l'immagine della forma d'onda quando cala di volume? Voglio capire quanto sia esteso il problema, anche per ipotizzarne le cause. Per caso gli abbassamenti sono subito dopo dei picchi? In tal caso si potrebbe cercare di acquisire nuovamente registrando a volume leggermente più basso magari impostando qualche filtro all'origine per ridurre un po' il rumore di fondo (tipo il Dolby B, sempre se per quanto ne sai non distrugge il segnale, e probabilmente lo distrugge quindi non sarebbe una buona idea).
Però rimane l'interrogativo, perché con TAP V1 funziona e con TAP V2 no: e non mi piace doverlo dire ma non scarterei l'ipotesi che ci sia qualcosa che non funziona nella conversione di audiotap per i TAP V2 in particolari circostanze, nel senso che con certi wav funziona bene e con altri no. Una versione che creasse un log di debug di audiotap per capire cosa combina nella conversione pure aiuterebbe. Non prenderle come critiche, non vogliono esserlo.

PS Buon anno a te e a tutti gli utenti del forum
I'M *DC2N* POWERED (tnx Luigi Di Fraia) - La mia collezione di cassette (non per vendita né scambio)
PER GLI ACQUISTI NEL MERCATINO IO PAGO SOLO CON PAYPAL E LA COMMISSIONE E' A CARICO VOSTRO

fab

  • Utente di edicolac64.com
  • *
  • Post: 424
Quando hai ritoccato a mano arrivando a far funzionare il primo gioco, che cambiamenti avevi apportato con audacity? Avevi alzato il volume dov'è basso e basta?
Nel caso specifico di quel WAV, erano singole onde ad avere un volume basso. Per identificarle, ho scritto un plug-in di WAV-PRG apposito per la parte turbo di quel WAV (è molto simile a Freeload) che segnala quando un impulso ha una durata anomala. Poi ho usato Audacity per vedere la froma d'onda in quel punto.
Puoi farmi un esempio di abbassamento repentino di volume postandomi l'immagine della forma d'onda quando cala di volume?
Il plug-in segnala il primo errore:
byte 2807436:Strange pulse 33a
Audacity, alla posizione 2807436, mostra questo

Il segnale ha onde squadrate, un po' frastagliate, ma di buona altezza. Sono chiaramente visibili impulsi lunghi (i primi 3) e impulsi corti (i successivi 6). Non serve "inverted waveform": si vede perché la parte a valore alto e la parte successiva a valore basso hanno più o meno la stessa lunghezza (se la parte a valore alto e la parte precedente a valore basso avessero avuto più o meno la stessa lunghezza, sarebbe servita "inverted waveform"). Ogni impulso dura da un trigger positivo (passaggio da basso ad alto) al successivo trigger positivo. L'impulso che termina a 2807436 (dove c'è la linea verticale) è anomalo: si abbassa leggermente, poi torna alto. Ed è eccezionalmente lungo. Il punto è: quello in realtà è due impulsi, uno corto (il leggero abbasssamento e il successivo rialzo) e uno normalmente lungo (la parte che resta alta e il passaggio a basso). In questo caso alzare la sensitivity è rischioso, perché le onde sono frastagliate, e allora l'unica maniera è modificare il segnale, alzando il volume di una singola onda.
Però rimane l'interrogativo, perché con TAP V1 funziona e con TAP V2 no
I TAP V2 sono più sensibili ad oscillazioni di durata degli impulsi. Un impulso in TAP V1 è di fatto la somma di due impulsi TAP V2. Ad esempio, se c'è una sequenza di semionde di durata (in campioni) 40, 49, 20, 22, 14, 6, 23, 20, la corrispondente sequenza TAP V1 si ottiene sommando coppie adiacenti (un'onda è due semionde): 89, 42, 20, 43. Questa somma ha l'effetto di stabilizzare le sequenze (di fatto, è un filtraggio passa basso). I TAP V2 funzionano dopo ripulitura, che elimina le oscillazioni. Tapclean è uno strumento di ripulitura, che però non funziona con i TAP V2. Lo script Python che avevo scritto e postato su questo forum è uno strumento di ripulitura per la parte in kernal loader dei TAP V2 e funziona discretamente.
PS Buon anno a te e a tutti gli utenti del forum
Buon anno a tutti
« Ultima modifica: 31 Dicembre 2011, 17:51:06 da fab »

Massi cadenti

  • Non dimenticatevi *MAI* nei vostri dump del Vic20 e soprattutto del C16/+4!!!
  • Administrator
  • Utente di edicolac64.com
  • *****
  • Post: 884
    • http://massicadenti.altervista.org/algasoft.html
Ora m'è tutto chiaro.
Il problema non mi sembra di facile soluzione. Quello che mi viene in mente è che Audiotap capisca da solo quando trova un'onda di lungezza anomala prendendo come riferimento la lunghezza delle onde del gruppo subito precedente (diciamo delle due onde precedenti) e le esamini da solo attentamente per vedere se in quest'onda anomala ci sono dei lievi abbassamenti di volume sia pure di poco per capire se si possa trattare di unione di una onda corta più lunga. Nel caso lo ritenga tale, corregga lui stesso la forma d'onda passandola poi in tap (v1 o v2 che sia) in modo corretto. La prima parte della soluzione mi sembra l'hai già attuata (anche se forse con un modo migliore del mio): è quindi da creare la seconda, che immagino sia la più complicata anche perché bisogna capire come spiegargli come vanno corrette questo tipo di onde. Finché comunque un lieve abbassamento dell'onda c'è (e c'è), io penso che si possa sempre correggere. Alzare la sensitivity in generale, agendo quindi su tutto il file, non mi sembra una soluzione né buona né accettabile, perché ovviamente il rumore distruggerebbe il segnale. Serve quindi qualcosa di più mirato, che alzi la sensitivity solo nel caso in cui trova onde anomale e solo su quelle onde anomale, e non sul resto. In pratica, serve un secondo parametro per la sensitivity, il primo resta generico su tutto il file com'è adesso, il secondo viene considerato solo se durante la scansione del file audiotap incontra dei problemi relativi alla lunghezza delle onde, e solo finché il problema non viene risolto. Considererei anche l'opportunità di poter variare il parametro relativo al numero delle onde precedenti da considerare come lunghezza standard, lasciando comunque un numero basso (io ho detto 2 ma si può forse aumentare a 4 o 5) come default.

Per quanto riguarda i problemi relativi a TAP V2 che non si incontrano con TAP V1 (mi riferisco al loader standard del KERNAL), servirebbe allora qualcosa che sia l'unione di AudioTAP e TapClean, prendendo il meglio da tutti e due: in pratica, creare per le parti di kernal loader usare un tap "ripulito" (ciò che fa tapclean, ma per il c16) e convertire questo da tap v1 a tap v2, usando quindi impulsi di lunghezza precisa. Ovviamente i turbo che usano le halfwaves è tutt'un altro discorso, per quelli sarà necessario attendere che tapclean supporti quei loader.

Solo a titolo personale, io credo a questo punto che un'unione di AudioTAP, TapClean e Wav-Prg sia l'ideale, con qualcosa che provveda partendo dal wav (o da un tap già creato ma "sporco") a a creare un tap pulito e testato, e a creare su richiesta un t64 (o una sequenza di prg).
Ovviamente perché succeda devono essere riconosciuti i vari tipi di loader (tanto per TapClean quanto per Wav-Prg), ma come ho già fatto in passato non ho problemi a fornirli qualora li abbia e ce ne fosse bisogno.

PS Solo per curiosità, visto che l'hai fatto funzionare: Fast Food è Burger Time? (se sì, su C16 è uno dei giochi con più nomi in assoluto, solo io nelle mie cassette ce l'avrò 5 o 6 volte con nomi diversi)
« Ultima modifica: 02 Gennaio 2012, 02:43:37 da Massi cadenti »
I'M *DC2N* POWERED (tnx Luigi Di Fraia) - La mia collezione di cassette (non per vendita né scambio)
PER GLI ACQUISTI NEL MERCATINO IO PAGO SOLO CON PAYPAL E LA COMMISSIONE E' A CARICO VOSTRO