Ce n'est pas une opinion. C'est un fait. J'ai converti le CDT que César a crée en byteloggant mon WAV brut original avec CDT2WAV.



Hé bah la preuve que si, puisque je vous ai uploadé un WAV entierement digital crée par CDT2WAV grâce au CDT de César.

César a calculé la clé, qui ne peut être contenue que dans un bloc pure tone. Pour celà, il a totalement désossé le loader, ce que ni toi ni Megachur avez fait pour le moment.

Vrai ou faux ? Tu sais sur le bout de tes doigts comment fonctionne le loader ou pas ?



C'est du digital, car CDT2WAV ne crée pas de WAV contenant du signal analogique, mais du signal digital (carré quoi!).



Je commence sérieusement à me dire que tu te mélanges totalement les pinceaux thomas.

Tu n'arrives pas à comprendre que sur les K7 originales du commerce il y a certains logiciels qui utilisent des clés de protection, celles-ci ne sont pas encodées en analogique, mais en digital, ce qui a pour effet d'empêcher la copie de la cassette, car tout lecteur voir les double-decks de l'époque ne faisaient que de l'analogique.



C'est toi qui te trompe, t'es en plus en train de me traiter de menteur et d'affabulateur, et qui plus tu oses me soutenir que ton CDT à toi est bon ?

Tu te moques de qui là ?

ton CDT est complètement pété, ne reflète pas le dump original, la clé digitale est collé au gros bloc, et ça te parait normal ?

seul le CDT généré par César est bon. C'est ce qui est sur le WAV original de Marmelade, et sur celui que je n'ai plus de Rat Connection.

Ton CDT à toi que j'ai converti montre le bug présent dans ton système, à savoir un problème avec les pauses, et en plus la clé n'apparait plus au bon endroit, les deux pauses qui l'entourent sont shootées.

Je le redis donc, le CDT généré par césar n'est pas une "approximation" ni un "on a fait ce qu'on a pu", il a été généré conformément au WAV original. Que ce soit pour Marmelade ou pour Rat connection.

De deux, César est la seule personne capable de générer des CDTs spéciaux qui soient correct dans la communauté CPC. Et c'est pour ça que je fais équipe avec lui.

Et de trois, ces jeux c'est moi qui les ai dumpés, donc je suis le mieux placé pour en parler, et dire comment sont les blocs, leurs positions, les pauses entre chacun d'eux, et si une clé de protection digitale a été utilisée.

Les clés de protection digitales émettent un son très particulier, ce qui les distinguent des blocs analogiques normalement enregistrés sur une K7.

J'en ai fait plusieurs, la encore je sais de quoi je cause.

Ce que je constate, c'est que tu préfères me renvoyer dans les cordes que de te remettre en question Thomas, et ça c'est le mal.

Je ne bougerais pas d'un iota ma position, le problème est dans sugarbox et aussi dans CPCemu, et comme je l'ai dit, je ne suis pas programmeur, je ne peux donc pas t'aider à débugger le truc.



tu en as déjà un en main généré par CDT2WAV 1.5, je l'ai déjà mis à disposition en téléchargement sur 2 pages différentes sur mon topic. Je ne le remettrais pas une troisième fois.

Le WAV que tu as généré est comme celui que j'ai généré avec CDT2WAV 1.5.

Un coup sugarbox le fait marcher, un coup ça plante, il n'atteint même pas la clé digitale......
Et CPCemu ne reconnait pas le wav.

Suffit la parlote, maintenant action !



tu pars à l'aventure, sans même savoir ce que tu fais et pourquoi tu le fais.

Pas besoin de bloc DRB.

C'est une clé qui se présente sous forme de son, ce n'est pas un bloc de données digitale.

Et c'est plutôt facile de voir pourquoi, le bytelogger de César bytelogge tout ce qui peut être un bloc, et les clés digitales passent à travers, parce que ce n'est pas de la donnée.

C'est comme dans les jeux Bleepload, il y a des blocs pure tone, pourquoi ? Parce que ce n'est pas des blocs de data, mais des clés digitales insérées lors du mastering de la cassette par l'opérateur du duplicateur.



CDT2WAV fait une réversion de la clé digitale dans le WAV, et oui ça vient du CDT réel puisque quand j'ai dumpé depuis la cassette, j'ai eu en visuel la clé digitale, elle se trouve après la pause du dernier bloc du loader, et avant la pause du gros bloc.

C'est l'interprétation qu'en fait sugarbox quand on fait la conversion qui est erronée.

On peut le voir dans les photos screens que j'ai posté dans la page précédente.



Mais tout ça c'est déjà fait , je comprends pas pourquoi vous revenez tout les deux à la charge la dessus !!

Les WAV dumpés depuis les cassettes ne fonctionnent pas (cassettes de mauvaise qualité) ;

Donc obligé de traiter le signal pour décrasser et débarasser le WAV de la merde dans laquelle il est, et aussi remettre les données comme il faut.

à partir de là, on utilise un outil qui converti le WAV originel Brut en CSW 16bits. Ce fichier CSW 16 bits est ensuite passé au format VOC.

De là, César passe le fichier VOC dans son byte logger, et récupère le loader plombé, et juste après l'énorme bloc contenant le jeu.

Ensuite comme il a désossé le loader, il sait exactement ce que le loader veut, et le loader vérifié qu'il n'y a rien pour qu'on puisse le déplomber (test MF2, test FDC, test 128ko de RAM).

Si tout ces conditions sont passées, alors intervient le décryptage. Ce décryptage se met en place durant la période de pause précédent la clé digitale. Dès que le décryptage a eu lieu, la clé digitale est lue, si elle n'est pas présente, le loader considère que c'est une violation de son intégrité, et reset le CPC automatiquement.
Si la clé est présente, elle est lue, et décrypte le loader du gros bloc. La pause qui se trouve après la clé joue le rôle de timer pour le décryptage. Une fois le loader décrypté, le border change de couleur, et positionne les valeurs qui vont bien dans les registres du Z80, et attends qu'on lui enfile le bloc de "données pures (pure data), et le décrypte au passage car lui aussi est encrypté.

La ou je veux en venir, c'est que vous venez m'enquiquiner avec la clé, alors qu'aucun de vos émulateurs de base n'arrive jusque là. On ne dépasse pas le chargement des blocs standard du loader.

Question : pourquoi ?

_________________
SPS Community Expert (SPS CE) / SPS France

Ce que je cherche à comprendre c'est :

pourquoi dans les dumps qui ont été fait :

le wav
Rat Connection (F) (1987) (464 only) (Basic v1.0) [Original] [TAPE].wav
fonctionne !

mais le CDT fonctionne pas
Rat Connection (F) (1987) (464 only) (Basic v1.0) [Original] [TAPE].cdt
et le wav généré à partir de la CDT fonctionne
Rat Connection (F) (1987) (464 only) (Basic v1.0) [Original] [TAPE].wav

donc, j'en déduis, que mon emu ne sais pas retranscrire correctement ca CDT !!! donc on cherche à trouver ce qui nous manque pour ça !!!

la question que j'aurai, c'est pourquoi CDT2WAV 1.4 et 1.5beta ne génère pas le même WAV à partir du CDT ? est-ce un bug de cet outil ? est-ce un hasard si ça marche ou est-ce parce que le codeur a mis en dur (comme dans l'émulation crtc de javacpc) si code particulier ici et exactement celui-ci alors fait cela !???!!??? ou alors il a découvert un truc no documenté dans le format CDT ?!


ce bug m'intéresse, peut me dire de quel wave on parle ?

Parce qu'implémenter la lecteur de fichier wav c'est pas compliqué



Justement, je ne comprends pas moi-même pourquoi vos émus bloquent sur les blocs standards du jeu.

Je me dis de façon logique, que si pour d'autres jeux les blocs standards sont correctement interprétés mais pas avec ces jeux là, c'est que le bug ou le problème est lié à la manière dont les données sont extraites lors
de la lecture.



Celui que Thomas a posté juste avant. Je l'ai testé avec CPCemu en mode 64k, et ton ému ne le reconnait pas.

_________________
SPS Community Expert (SPS CE) / SPS France

Je passe le texte très long pour pas grand chose (y compris les bassesses, mais bref - Par ailleurs, je n'ai PAS de cdt correct, à mon grand regret ! Mon but, dans ce topic, c'est justement d'avoir un bon CDT pour travailler avec)

On va donc procéder autrement.
Puisque tu as une manip pour reconstruire un WAV a partir de ce fameux CDT, et que nous autre n'arrivons pas à le faire (bande d'incompétents !), peux-tu, s'il te plait :
- poster ici même ce fameux cdt2wav en version 1.5.
- Indiquer très précisément la manip pour obtenir ce résultat.

Avec la même source, le même outil et la même manip, nul doute que nous parviendrons à reconstruire comme il se doit ce WAV !


De toute façon, dans le cas contraire, quel intérêt de stocker ce cdt si on ne peut en regénérer le wav...
Autant conserver le wav qui marche.

PS : mon WAV provient du CDT de rat connection, passé à la moulinette CDT2WAV 1.4

Le CDT est correct, c'est juste que Sugarbox ne l'interprète pas correctement ! Rah mais !



Tu te moques de moi j'espère ? Je vous l'ai zippé le 25 octobre 2014 ! il est présent dans une de ces pages, j'ai pas effacé le fichier ZIP de mon disque dur (j'ai donc la date exacte !).

J'ai l'impression de passer mon temps à réuploader ce que vous avez déjà sur vos disques dur (ou alors vous avez effacé les fichiers..... )



Manipulation trop difficile : tu fais comme avec CDT2WAV, tu glisses le CDT original de Marmelade ou de Rat sur la fenêtre de CDT2WAV 1.5 ;

J'ai pas inventé le fil à couper le beurre ou encore un truc super compliqué que personne d'autre peut faire.



Tu prends le CDT de chaque jeu (marmelade ou Rat au choix) sur CPC-rulez ou CPC-p0wer, tu fais glisser ce CDT sur la fenêtre de CDT2WAV 1.5, et voilà, tu as un fichier WAV contenant la clé digitale (visible sous la forme d'un bloc pure tone dans le cdt).

Le wav brut tiré de la cassette a très exactement ce format :

Pause de début / Loader sur 4 blocs / Pause / Clé digitale / Pause / Gros bloc

Et pas comme je l'ai vu sur le WAV généré depuis sugarbox sous la forme :

Pause de début / Loader sur 4 blocs / Pause / Gros Bloc et/ou Clé collée au Gros bloc

Qui n'est absolument pas conforme à ce que j'ai vu sur la cassette originale.

Est-ce que comme ça ça te parle plus, est-ce que visuellement comme ça c'est mieux ?



Le CDT fonctionnerait si vos émus ne plantaient pas sans raison sur le loader.....



Exactement comme les WAV 100% digitaux que j'ai crée à partir des CDTs originaux grâce à CDT2WAV.

Comme je le disais, et c'est malheureux, on a vraiment pas de bol, seul vos deux émulateurs gèrent correctement la non-présence du FDC, mais voilà, ils plantent sur le chargement !
CPCE ayant malheureusement le FDC qui répond présent quand le loader l'interroge, je ne peux pas m'en servir tel quel. Par contre, si je prends le CDT et que je mets à la place du loader protégé le loader avec toutes les protection désactivées, CPCE fait tourner sans aucun problème le jeu, il charge la clé, puis les blocs pure data (qui n'ont en fait aucun pilot tone ou quoi que ce soit).

Je le redis pour la toute dernière fois, la clé digitale est impérative, le loader doit la lire, si elle n'est pas présente, le CPC plante et est réinitialisé !

César vient de me donner l'explication concernant la clé digitale :

La clé est présente dans le CDT sous forme de bloc pure tone parce que le loader de la clé écoute la cassette pendant une durée de temps fixe et s'attends à lire un nombre de pulses.

Par ailleurs, le code qui lit la clé digitale est très long, avec des parties en clair, et de nombreuses parties qui sont obfusquées ou encryptées. Pratiquement impossible à suivre à la main.

César a du "trapper" les accès hardware pour savoir ce que ce code fait. Ce code se met en mode "j'écoute la cassette". On en sait pas plus, c'est comme une sorte de boite noire.

Est-ce que ces informations sont suffisantes comme preuves comme quoi la dite clé existe bel et bien ?

César a généré le CDT par rapport à ce qu'il a entendu sur le WAV original brut (pas celui généré par CDT2WAV) que je lui ai fourni.

_________________
SPS Community Expert (SPS CE) / SPS France

ne vous énervez pas -> à chaque problème sa solution... Si on a pas encore trouvé, c'est pas grave, on le fait pour le fun et notre passion commune : le cpc :kissed: !!!


Si je prends le CDT de Rat et je le convertie en wav avec tapir (un autre outil que CDT2WAV 1.5), j'obtiens un wave qui ne marche pas et qui reset après la clé comme le CDT !

Donc en l'état, je pense qu'il faudrait demander à l'auteur de CDT2WAV 1.5 (DevilMarkus je crois) comment il traite ce bloc CDT précisément dans ce cas !?

Parce que ni Lone, ni moi, en s'appuyant sur la documentation officiel TZX ne trouvons ce point pour pouvoir correctement l'émuler pour votre plaisir !!!

Je précise, que comme dit plus haut, j'ai testé plein d'autres K7 avec ces types de blocs (pour d'autres protection) dont Marmelade du même auteur (code), qui a été dumpé avec la même méthode et qui ne nous posent aucun soucis d'émulation celui-là.

En attendant la réponse de DevilMarkus, j'arrête les investigations pour l'instant à ce sujet.



Est-ce que César la fait sur un cpc ou avec CPCE ?

Car comme tu l'as expliqué nos émulateurs sont différents ce qui pourrait expliquer le problème...

Exemple : le mien comme celui de Lone émule le Z80 à 4Mhz (4 appels par cycle de GA qui lui est à 16 MHz et donc appelé 16 fois pour 1 cycle d'émulation) alors que la plupart des émulateurs émule un Z80 à 4 MHz avec 1 seul appel qui effectue 4 cycles d'un coup sans prendre en compte cette spécificité de l'hardware CPC parce que ça marche dans la plupart des cas sauf pour certains visuels de démo (je poste deux exemples ci-dessous entre WinAPE et CPCEmu) pour illustrer, il faut bien regarder à gauche et à droite des graphismes pour s'apercevoir que les rasters ne sont pas au bon endroits !
le fait d'être proche du vrai hardware du cpc c'est bien pour l'émulation mais en terme de performance c'est quasiment du 4x plus de temps cpu donc bpc plus lent à l'exécution !!!

je crois également que la seule démo qui ne marche pas si on émule pas bien cela c'est

Elle ne tourne donc pas sur ces émulateurs et seul JAVACPC utilise un hack pour passer ce point sinon crash !!!



pour le bug sur les wavs, je suis supris car moi ce matin, j'arrive à le charger sans pb dans l'émulation (c'est juste que le cpc reset après lecture comme dit plus haut) :

par contre, je sais que les browsers sont limités sur la gestion des objets javascript (en fait il ne libère quasiment la mémoire que quand il n'y en a plus de disponible)... Donc, si on charge des waves (15 Mo en moyenne) au bout d'un moment on peut avoir des lenteurs dans un premier temps puis carrément des blocages des navigateurs !
Sur la dernière version de Firefox public (v40.0.3), chez moi, quand il dépasser le 1.2 Go de mémoire alloué par exemple, c'est une catastrophe, il se bloque souvent !!!

dans un onglet, il suffit de taper "about:memory" pour voir le désastre... le problème étant que même en libérant un objet en javascript, on a pas la main sur la libération de la mémoire, seul le garbage collector du browser peut le faire !!! argh ! c'est la joie des développements web javascript ! Car marche partout mais à quel prix !!!

je te mets le copier/coller sous Firefox de la console (dans le menu principal -> développement / console web pour l'afficher) qui te permettra de vérifier le bon chargement ou de m'indiquer l'erreur que tu y vois !

Rat Connection (F) (1987) (464 only) (Basic v1.0) [Original] [TAPE]_CDT2WAV1.4.wav

CDT : This file is not a CDT - id != ZXTape! CDT.js:637:3 l'ému détecte que ce n'est pas un CDT -> normal
WAVE : This file is in PCM Format - channel =1 - sampling frequency =44100 Hz - bytes per second =44100 - bytes by capture =1 - bits per sample =8 CDT.js:83:5l'ému détecte que c'est un wave au format PCM (conforme) en mono / 44100Hz et le converti
CDT : pause=1l'ému mets une pause de 1seconde à la fin de la wave -> normal

j'ai testé quelques waves de JMD télécharger depuis son site pour valider mon code et j'ai pu les charger sans problème malgré leur état donc je me dis que la conversion wave -> format interne CPC doit pas être si mal !!!
ex :
k7 - 3D Starfighter (Codemasters - 1987).wav
k7 - 3d stunt rider (Amsoft - 1985).wav
k7 - army moves - part 1.wav
k7 - army moves - part 2.wav
K7 - Green Beret (Imagine - 1986).wav
k7 - Space Raver.wav
etc...

Je vais demander à Markus

_________________
SPS Community Expert (SPS CE) / SPS France

Bon, test effectué : Le CDT de rat connection passé par CDT2WAV 1.5, donne quelque chose de différent du seul wav fonctionnel à notre disposition.

Taille de fichier différente, longueur différente, et la fameuse zone de la 52e, fort différente.

La zone du haut = fichier wav correct
La zone du bas = fichier reconstruit (les timings de début sont parfaitement identique, jusqu'à cette zone là)



Le wav généré par la 1.5 est, par contre, très très proche de celui généré par la 1.4.

A mon avis, il y a eu mélange de wav à un certain niveau, et celui que tu penses avoir reconstruit n'est pas celui là (sinon, j'aurais obtenu la même chose que ce fameux wav fonctionnel).

Comme dit Megachur, soyons positif : On a au moins un dump correct (le wav), ce qui d'un point de vue préservation, est une très bonne chose.

Edit ; j'avais voulu écrire millisecondes et j'avais écris secondes !

j'ai eu le temps de regarder avec Audacity le wav original de Rat Connection et de Marmelade (ceux 'propres' avant la conversion en CDT) :

il en ressort que :

- pour marmelade, la 'clé' fait 560ms de long visible dans le wav

dans le CDT, le bloc "pure tone" a un pulse length de 1925 et un nombre de pulse de
soit 1018*1925 = 1959650
qu'on divise pour le format TZX par 3.5 = 559900 microseconds
soit environ 560 millisecondes

la pause suivante est de 1629ms ce qui correspond au wav

- pour rat connection, la 'clé' fait 120ms de long visible dans le wav

dans le CDT le bloc "pure tone" a un pulse length de 1120 et un nombre de pulse de 1018
soit 1018*1120 = 1140160
qu'on divise pour le format TZX par 3.5 = 325760 microseconds
soit environ 326 millisecondes

la pause suivante est de 900s ce qui ne correspond pas au wav (717ms)

pour moi au aurait du avoir dans le CDT - 1444 de pulse length ?
et une pause ensuite de 717 millisecondes ?!

Help !!!

As-tu essayé de patcher le cdt ? Peut-être ces seules info suffisent elles a faire fonctionner le bouzin ?

ahem.... Je ne sais pas si tu te relis, mais, ce que tu trouves ne fait pas 560 secondes (ce n'est pas ce qui est dans le CDT), mais 560ms.



la aussi..... le calcul est bizarre.tu dois trouver des microsecondes, et non des secondes.



la encore..... y a pas de pauses en secondes dans le CDT, ce sont des microsecondes.

La raison pour laquelle j'ai mis 900ms au lieu de 717ms c'est tout bête :

si tu ne mets que 717ms, cette durée est insuffisante pour que le loader du bloc pure data se décrypte.

900ms c'est bon à l'inverse. Part aussi du principe qu'on ne sait pas quelle est la vitesse à laquelle le CPC
absorbe les bits au niveau du PPI compte tenu de la vitesse de lecture du lecteur de cassette.

C'est l'autre raison aussi pour laquelle on essaie de cadrer exactement le temps de pause.

_________________
SPS Community Expert (SPS CE) / SPS France

J'ai patché le CDT avec 1444 en longueur de pulses, et mis 717ms.

converti ensuite le CDT avec CDT2WAV, et le WAV obtenu se charge sans problème sur mon 464.

Bizarre, ça n'avait pas marché la première fois. J'ai du me tromper sur ce sujet.

par contre, ça ne change absolument rien dans sugarbox et CPCemu, le programme plante toujours sur le chargeur binaire encrypté du début.

_________________
SPS Community Expert (SPS CE) / SPS France

Tu peux nous zipper cdt &wav s'il te plait ?

Edit ; j'ai corrigé le post plus haut !

j'avais écrit secondes au lieu de milliseconds !

Oui tout en sachant que de toute façon, tu n'arriveras pas à charger le jeu malgré tout, puisque sugarbox
plante sur le chargeur binaire encrypté de la cassette.

C'est bien de t'être penché sur la clé digitale, mais c'est mettre la charrue avant les boeufs, puisque je n'arrive pas jusque là.

Et d'ailleurs c'est bizarre, l'erreur est la même sous sugarbox et CPCemu, ce qui aurait tendance à me faire dire que vous avez la même erreur d'implémentation

Je joins le CDT modifié, ainsi que le WAV généré par conversion via CDT2WAV 1.5

_________________
SPS Community Expert (SPS CE) / SPS France