Si c'est un wav, on peut en faire quelque chose !



Oui, exactement, sampler le signal en entrée de ton 464 (ou en sortie de ton pc, ce qui doit donner la même chose).
Ca sera une première étape pour voir comment évolue le signal.

tu sais que c'est ce que j'ai toujours fait.

Le truc c'est qu'après avoir dumpé en brut, je retraite pour avoir un master propre, avec les bonnes longueur de pauses, ainsi que les timings les plus proches possible du signal original (sinon c'est césar qui les calcule, et il le fait mieux que moi )

J'ai toujours dumpé les cassettes depuis 2004 à l'aide de Goldwave tout en faisant le monitoring sur mon CPC 464 à l'aide d'une cassette digitale. ça ne marche pas toujours, pour certains cassettes, la crasse, les variations de volume et de son obligent à nettoyer et corriger le signal avec un outil. Pas le choix.

Le bon point, c'est que mon 464 adore les masters propres, que je génère via CDT2WAV quand j'ai pu faire un CDT (ou césar) à l'identique du WAV originel.

Dans les derniers jeux cassettes dumpés, j'ai des WAV bruts zippés sur mon disque dur.

J'ai un ami qui va me faire parvenir sous peu 3 disques durs de 500go pour que je puisse y mettre les dumps Amiga, St, CPC, PC qui me sont envoyés, ainsi que ceux que je fais.

_________________
SPS Community Expert (SPS CE) / SPS France

Ah ben parfait.

Comme ca on aura les dumps suivants :

- L'original (marche partout)
- Le CDT (ne marche pas sur emu)
- Le WAV généré par tapir ou cdt2wav (ne marche pas sur emu)
- Le même, transformé par le passage en analogique (??)
- Idéalement, celui lu depuis la pin du PPI

La comparaison mettra en lumière les différences.

Si tu parles des jeux MBC, les WAVs originaux tel quel ne fonctionnent pas. les K7 originales sont en mauvais état.

(Tu ne m'as peut-être pas correctement lu. J'ai expliqué plus haut que ce n'est pas du tout la majorité des cas ou le dump brut peut-être utilisé tel quel (parasites, bruit, vieillissement de la bande).

Il y a besoin de traiter le signal dans 80% des cas. Les jeux MBC ont du être traités avec CSW, et les CSW de type 1 générés ont été ensuite converti en VOC, puis byteloggés.

Autrement impossible d'utiliser quoique ce soit.



oui ne marche pas sur ému à cause d'un problème de support et d'implémentation (CQFD la découverte de Mégachur sur son module CDT).



le WAV généré depuis le CDT par CDT2WAV fonctionne sur sugarbox.



Le wav original contient le signal analogique de la cassette. Le wav tiré du CDT crée par CDT2WAV est lui digital.

Mais comme indiqué le signal analogique d'origine étant mauvais, on est obligé de le traiter et de l'expurger de toutes les merdes et autres défects qui sont dedans.



je ne compte pas modifier mon 464 pour faire ça. Il n'existe aucun outil pour gérer correctement ce signal là.



Ce que je comprends pas, c'est qu'aucun passage en revue en terme de débugging du code gérant les CDTs n'a été fait du côté de sugarbox encore, (mégachur l'a fait, et il a trouvé un problème!).

Pour récapituler :

le WAV brut original (analogique) tiré des jeux MBC : ne fonctionne pas tel quel sur mon 464.

le CDT généré depuis le wav brut original traité et nettoyé : fonctionne (sinon CDT2WAV n'en ferait pas un WAV digital parfait fonctionnel), mais Sugarbox n'arrive pas à le traiter correctement (bug sur les pauses, voir sur les blocs, sugarbox ne traite pas correctement les blocs et crashe sans que l'on sache pourquoi).

CPCjava avait le problème jusqu'à il y a peu. Il s'arrêtait carrément après avoir lu les 2 premiers blocs (figeait), et pour Rat connection, lecture du loader, mais ensuite crash et reset.

le WAV digital (propre et sans défect) crée par CDT2WAV : fonctionne sur CPC 464 et sugarbox.

_________________
SPS Community Expert (SPS CE) / SPS France

Je parlais de Rat Connection (dont le cdt plante chez moi - entre autre).

Histoire de reconstituer la vie du dump...

- Peux-tu nous mettre a dispo le wav original (même moche ?)
- Celui amélioré, on l'a, merci à toi
- Le cdt aussi
- Le wav de cdt2wav aussi
- La sortie du PC vers le cpc, si tu peux nous la fournir
- L'entrée de la pin PPI (qui permet, entre autre, d'assurer l'émulation car, comme tu te plais tant à le dire, "le dump est ainsi parfait" - C'est à dire qu'il est samplé après le passage dans l'éléctronique du lecteur de cassette.)
Entre autre, la différence entre l'entrée PPI et ce qui passe par la tête de lecture offre un exemple parlant de ce que fait cette électronique.


En ce qui concerne la revue et le debugging du cdt, je l'ai fait en long, en large et en travers.
Ce qui ne veut pas dire qu'il est complet, mais il arrive tout de même à passer un sacré paquet de dump.

Pour finir : Il semble que le cdt de rat connection passe sur certain emulateurs ? JavaCPC et celui de Megachur, c'est exact ?

J'ai retrouvé le WAV de marmelade non touché, brut. Je n'ai plus celui de Rat Connection (j'ai que le WAV propre en digital, prêt pour un remastering).



C'est celui généré à partir du CDT pour l'un comme pour l'autre.



Déjà donné, vous les avez tout les deux, ils sont dispo ici et sur cpc-p0wer.



C'est celui que tu nommes amélioré.



En pièce jointe pour Marmelade. Je n'ai plus celui de Rat connection.



Il faut modifier le 464, et clairement je ne compte pas le faire.

C'est ce que font les mecs sur C64 et ça m'énerve (ils utilisent en plus le format TAP, c'est du CSW, ça m'énerve aussi) parce qu'on ne peut rien en faire, en cas d'erreur ou de problème, on ne peut rien corriger.

De plus, si tu veux du digital, CDT2WAV le fait très bien depuis un CDT fonctionnel. Le WAV qui en ressort
correspond à ce que tu veux d'un point de vue entrée PPI.



Il y a toujours un problème. Comment expliques-tu que Sugarbox plante en lisant les blocs turbo que ce soit sur Marmelade ou bien Rat connection ?

j'ai fait le test sur l'ému de Mégachur à l'instant, le chargement du loader de marmelade ainsi que Rat Connection plantent après la lecture de 2 blocs sur les 4 que composent le loader.

Ce n'est pas un problème de timing, il y a quelque chose dans le fonctionnement de Sugarbox et CPCemu qui ne colle pas avec la ou les routines que contient le loader.

J'ai essayé sous CPCemu de faire une sauvegarde SNA, celle-ci n'est même pas reconnue par les autres émulateurs (CPCE, Sugarbox, Caprice32).

Donc clairement, il faut ajouter un débuggeur temps réel sur Sugarbox, et monitorer ensuite l'éxecution des instructions, de manière à trouver à quel moment le loader provoque la sortie de route de l'émulateur.

Comme l'émulation z80 est parfaite sur vos 2 émus, et comme le chargement de bloc turbo fonctionne sur d'autres jeux en CDT, la conclusion est claire :

il y a une discordance dans ce que l'émulateur fait des données et ou du décryptage qui se produit après le chargement des blocs.

Et comme vous le savez tout les deux, je ne suis pas programmeur, de ce fait je suis incapable de vous aider sur ce sujet.

Comme césar me le dit souvent, pour déterminer pourquoi le chargement d'un jeu ou d'un soft déconne, il faut utiliser un débuggeur, il n'y a pas le choix.



J'ai essayer la dernière version de CPCemu avec Rat Connection. J'ai exactement le même problème qu'avec Sugarbox. Le chargement se fige avec des pixels corrompus à l'écran, ensuite l'émulateur reset.

Avec JavaCPC ça ne marche pas non plus, parce que Markus a imbriqué l'émulation du FDC, qui est présente même si dans la configuration utilisée il ne peut pas être présent ni exister. Comme la routine de protection est là, et qu'elle appelle matériellement le FDC (youhou ! t'es là enc*lé ? ), même si il n'est pas activé, il répond présent cet idiot. Résultat ça plante sans pitié.

Pour corriger le truc, il faudrait que Markus reprenne de zéro son émulation.

_________________
SPS Community Expert (SPS CE) / SPS France

J'ai testé en mode 464 sans FDC :

Marmelade (F) (1987) (464 only) (Basic v1.0) (DUMP BRUT NON TRAITE).wav :
passe pas après l'affichage de "code chargé" (écran bleu avec border noir puis reset au bout d'un moment)
heureusement que vous savez 'rendre lisible' ces dumps !

et
Marmelade (F) (1987) (464 only) (Basic v1.0) [Original] [TAPE] (CDT2WAV TIRE DU CDT).wav

bon celle-ci se charge sans pb, mais s'est comme le wav propre, le cdt !

Par contre, je pensais que CDT2WAV générait un wav en fichier, là je comprends qu'il faut enregistrer la sortie son du pc (j'ai qu'un version de 2014 en exe pour ce logiciel, peut-être existe-t-il une version plus récente)?!

il me faudrait la même chose sur RAT CONNECTION -> le wave avec CDT2WAV TIRE DU CDT pour valider si pb d'emulation CDT ?

Oui les jeux avec des protections aussi pointues tiennent mal les années hélas.



oui c'est normal, c'est le contenu du CDT converti en fichier WAV, donc parfait. Mon 464 l'adore



Ok, bon là ça part carrément dans tout les sens. Lis attentivement ce que je vais écrire :

- CDT2WAV a été crée pour convertir des fichiers CDTs en WAV. Tout les blocs sont supportés.



j'ai déjà mis en téléchargement quelques pages en arrière le WAV converti depuis le CDT avec CDT2WAV.

Je le mets avec ce post.

_________________
SPS Community Expert (SPS CE) / SPS France

Alors ça, je suis perplexe : Le wav que tu nous donnes est intégralement généré par cdt2wav ?

Parce que quand on le regarde à la loupe, c'est plus qu'étrange...

Notamment entre la 52,8e seconde et la 53e : Si l'on zoome, ça ressemble à tout sauf à du WAV généré à partir d'un CDT...... (le reste est cependant conforme : des seuils max, min, et centrés) - Comme si le petit bloc en question, apparement central pour la protection, avait été copié/coller d'un wav original.



Cela dit, le procédé serait malin, et permettrait d'avoir un wav peu couteux mais fonctionnel

Par ailleurs, quand on génère un wav à partir du CDT, on obtient un fichier très différent (logique : Le CDT ne conserve pas les samples, mais les convertis en pseudos bits - et donc, exit les niveaux différents que l'on retrouve à cet endroit précis, on a que du min/max avec le niveau neutre sur les pauses)
.

Si, malgré tout, tu l'as généré a partir de cdt2wav... Peux-tu nous donner la version de ton cdt2wav miracle, et ses options ? (j'utilise la 1.4 - 44khz, et "use 3 states" coché)
Parce que ça, c'est un changement dans le paradigme du cdt...

Merci !

Bon, bonne nouvelle et cela me rassure : il passe sans problème ce wav !

donc, pour Rat Connection :

Rat Connection (F) (1987) (464 only) (Basic v1.0) [Original] [TAPE].wav : ok
Rat Connection (F) (1987) (Version Basic 1.0) [Original] [TAPE].cdt (de cpc-p0wer) : ko -> reset
Rat Connection (F) (1987) (464 only) (Basic v1.0) [Original] [TAPE].cdt (posté ici) : ko -> reset
Rat Connection (F) (1987) (464 only) (Basic v1.0) [Original] [TAPE].wav (reconversion CDT) : ok

j'en déduis donc que seul CDT ne fonctionne pas. par contre, je ne sais toujours pas ce qui dysfonctionne dans le décodage du CDT (entre le bloc 12 - pause - bloc 14) !!!

tu ne l'avais pas compris quand je l'ai dit 3 pages en arrière ?



Ce n'est pas un bloc normal. C'est un bloc digital et non un bloc analogique. C'est pour ça que César a utiliser un bloc 'pure tone'. Ces blocs sont les seuls à pouvoir contenir les infos de ces blocs spéciaux.

Je reconnais à l'oreille ces blocs là quand je dumpe un jeu cassette. Le son est totalement différent de celui du signal analogique enregistré sur la cassette.





C'est la première raison pour laquelle les outils que l'on possède ne peuvent pas générer un CDT. Aucun ne reconnait cette protection qui avant qu'elle ne tombe entre mes mains n'a jamais été dumpée.



Les seuls samples, sont ceux du bloc digital. Le reste du signal c'est de l'analogique.

Avec CDT2WAV, le WAV obtenu depuis le CDT est entièrement digital.
.


J'utilise la dernière version (la 1.5, qui est dispo sur le net).

Son avantage ? Les WAV générés se compressent incroyablement bien avec 7zip et ça c'est magnifique

Alors qu'un WAV brut original, ça pèse plus de 15mo.....

_________________
SPS Community Expert (SPS CE) / SPS France

Désassemble le loader. C'est pas normal que ça plante après avoir lu 2 blocs. Le lanceur fait un truc qui met ton ému aux fraises.

_________________
SPS Community Expert (SPS CE) / SPS France

-> en fait, pour "reconversion CDT" j'ai juste voulu dire que le WAV venait de CDT2WAV et était un conversion en WAVE de la CDT !

-> par contre pas trouvé de download de la version 1.5 de CDT2WAV (j'ai juste trouvé cela sur le forum cpc-live sur une beta de la 1.5 :http://cpc-live.com/forum/index.php?topic=261.0. Elle est peut-être incluse dans javadesktop ? )

-> en fait, si le loader test la MF2, il n'y a pas de raison que ça marche avec un wav et pas avec un CDT car je pense que cela est complètement indépendant de ce qui est lu sur le lecteur de K7 ??? ou alors, j'ai loupé un truc ?!

-> à ce stade de notre analyse -> je reste persuadé, que c'est plutôt quelque chose qui nous manque dans le code qui effectue la conversion des données de la CDT vers le lecteur de K7 émulé (ce qui lors de la lecture transmets les données au PPI) !
Je prends pour exemple la protection gremlins loader 2 qui fonctionne désormais comme je l'ai dit plus haut et qui fait suite à un changement dans le code qui traduit le contenu de la CDT en données lues par le lecteur de K7...

Par contre, je ne m'explique pas pourquoi le CDT de Marmelade fonctionne alors qu'il semble avoir la même protection !?! Il faudrait voir si le code du loader est le même entre les 2 (Lone ?).

Ou

-> plus on essaye, plus on a de chance de trouver !

Bon, en tout cas, il faut arrêter de penser que le wav fonctionne provient du CDT de Rat connection que tu nous a donné :

Il est tout bonnement impossible d'obtenir un WAV tel que tu nous le mets, à partir du CDT qui est sensé être bon.

Les blocs utilisés sont les suivants :

20 : Bloc de pause
11 : turbo data bloc (c'est a dire des données (octets), en se basant sur les longueurs de transitions des 0 et des 1 - Donc, pas de données de samples comme on le voit sur ce bloc mystérieux)
12 : Pure tone : même chose : une longueur de pulse + le nombre de pulse, rien sur la hauteur de chaque sample
14 : En gros, la même chose que le bloc 11, mais uniquement les datas.

Le fichier CDT ne contient tout simplement pas les données que l'on voit vers la fameuse seconde 52.8....
(De toute façon, même les ID15 (DRB) ne contiennent pas ces données. En fait, le format TZX (CDT étendu) ne contient rien qui puisse permettre de stocker de tel données...)

PAR CONTRE, il serait intéressant de tester un wav généré réellement à partir de ce fameux CDT.
Comme celui-ci par exemple (CDT2wav 1.4)


Sinon, pourquoi ne pas tenter un DRB sur la section (la fameuse "clé" de la seconde 53) qui nous manque ?
On ne pourra pas faire mieux en l'état, à moins de stocker un énorme paquet de blocs 12.....

ma déduction, c'est donc que c'est l'outil CDT2WAV qui interprète le CDT et génère cela dans le wave résultant générant l'illusion que cela vient du CDT réel (voir ton explication sur les données contenus dans le CDT).

Ensuite, ce wave marche sur un 464 grâce à cela -> d'ailleurs, il suffira de tester le wav que tu as fourni avec cet autre outil sur un 464 pour lever le doute !?