Tu peux nous mettre les wav originaux aussi stp ?

(pas les fameux "wav de doigts", mais les wav avec des jolies courbes sinusoidales)

Question: comme je l'ai expliqué, ces CDT, CSW et WAV sont 100% conformes d'un point de vue contenu au WAV tiré de la cassette, qu'est-ce que tu crois ou espère trouver ?

Il est fini le temps ou on ajustait les timings parce que ça marchait pas. Maintenant on utilise les timings originaux, et ils sont dans les CDTs, CSW et WAV digitaux.

A moins que tu ais découvert un problème, dans ce cas, merci de me le communiquer pour que je puisse le remonter.

_________________
SPS Community Expert (SPS CE) / SPS France

Pour ma part, c'est que si le wave fonctionne et pas le CDT 100% conforme, c'est que j'ai forcément un calcul de timming qui n'est pas bon lié au format CDT. donc si je veux voir la différence, faut bien que j'ai les deux !!!

Après, perso, pour le wave original, c'est autre chose pour moi. Si celui-ci marche sur mon emul et pas , je me dis que je n'ai pas de problème sur l'émulation CPC mais sur l'émulation CDT ou WAV 100% conforme !?

Je n'ai également jamais constaté de pb avec mon ému avec des waves 'originaux' qui marchaient sur un cpc 464 aussi !

Dans tous les cas, perso, je ne modifie pas mon moteur pour m'adapter à un CDT ou un WAV qui ne marche pas !
Je cherche surtout un problème, une faute sur le codage et la compréhension des formats d'émulation ou un problème de configuration, etc.
Comme pour le FDC, tous les formats K7, sont convertis dans le même format en interne dans mon émulation, donc il suffit de comparer entre le wav et le CDT pour voir si cela vient d'une interprétation de format ou non !? si cela vient d'un outil qui a mal converti le wav en CDT, je le signale à son auteur si je le connais !

Pas mieux que Megachur : Si le wav marche et pas le cdt, c'est bien d'avoir les deux pour comparer.

Comme indiqué plus haut, ce CDT de mask est rigoureusement identique au contenu de la cassette.
Le précédent généré avec le bytelogger de César était fonctionnel, mais pas 100% identique.

Tu as sous les yeux un CDT 100% conforme au système tel qu'on l'a dans le WAV.

Last Mission (F) loriciel.7z [25.57 Kio] -> chargement bizarre de l'image de présentation - décalage ?! ne fait rien une fois chargé !?

décalage idem de l'image de présentation sur un autre ancien CDT testé -> bizarre !

Oui ton émulateur, tout comme celui de thomas ne supporte pas encore ce système d'encodage. Il y a quelque chose qui foire (je précise, mon 464 et mon 464+ chargent le jeu sans aucun problème).

Je te laisse tracer le code afin que tu puisses découvrir à quel endroit ça pêche.

Je précise : le WAV tiré de la K7 ne fonctionne pas tel quel, il faut le filtrer pour le faire fonctionner via un outil qui passe en même temps le WAV au format CSW. J'ai testé Last Mission en version française, et ça n'a pas marché, mais aucun des autres jeux utilisant ce format ne marche sous sugarbox, que ce soit le WAV original, le CSW ou encore le CDT. Par contre un vrai CPC 464 lui se régale



J'ai expliqué plus haut que ces CDTs sont de nouvelle génération. Ils sont à présent 100% conforme au contenu des WAV d'origine (timing+pauses+système d'encodage des protections).

Je n'utilise plus ni samp2cdt, ni cdt2wav ni aucun autre outil. Maintenant on va jouer avec les vraies règles du jeu. Et tu vois chose bizarre, ton émulateur supporte sans aucun problème le jeu trivial pursuit, la où sugarbox lui, crashe sans aucune autre forme de procès. Pourtant y a rien de compliqué sur celui là, qui fait simplement appel à un bloc type 14 (pure data). Y a un truc qui cloche côté sugarbox, mais dire quoi je sais pas, ni le WAV original, ni le CSW, ni le CDT, ni le WAV digital ne tournent dessus, alors que ça fonctionne chez toi, sur CPCE, sur mes CPC sans aucune distinction.

Et je précise autre chose. J'habite à 2300km de distance de césar, et le nouvel outil n'a pas été crée par rapport à mon matériel. César a codé de zéro l'outil, et il a utilisé ses connaissances approfondies de l'amstrad CPC avec l'usage bien évidemment d'algorithmes mathématiques, qui sont des merveilles comparés à ceux de samp2cdt. La ou avant je devais copier coller 3 cdts pour un seul jeu, maintenant grâce à ses algos, je génère un jeu en une seule passe, je sais à quel vitesse est chargé le jeu, l'homogénéité des pauses, et ainsi de suite.

Et même mieux, si je me trompe de switch, exemple, je choisis speedlock 2 alors que c'est un speedlock 1,
l'outil m'indique dans le fichier de log que c'est un speedlock 1. C'est juste du grand art !

J'ai passé en revue plusieurs centaines de jeux speedlock, et on a testé tout les jeux dont les protections sont référencées plus haut (je sais même pas combien d'heures on a pu y passer, et c'est pas fini, d'autres protections vont être ajoutées).

Bref, par exemple, si ça peut aider, et outre les milliers de micro-blocs qui le composent, le jeu Mask se charge à une vitesse d'environ 2300 bauds, impossamole 1950 bauds, et mickey mouse par exemple 1800 bauds.

Voilà ou on en est. Ces informations sont extraites avec les timings lorsque le CDT est généré.

Je vois joins les logs de quelques jeux en PJ. Je ne mettrais pas de WAV tirés des K7 de jeux qui posent problèmes car dans 100% des cas ceux-ci ne fonctionnent avec les émulateurs (à cause de la crasse dans laquelle sont noyés les jeux, principalement), ces derniers se cassent les dents car aucun n'arrive à filtrer comme le fait un vrai CPC (et d'ailleurs un vrai CPC sait faire la différence entre la donnée et le bruit d'une cassette NDLR).

Donc au mieux, je peux fournir les CSW des jeux en question. A vous de voir si vous voulez les réverser en WAV ou non (ils sont en PJ).



Vous me lisez pas les gars, j'ai indiqué plus haut :

les WAVs originaux ne fonctionnent pas sur les émulateurs, car ces derniers sont incapables de les filtrer et donc de les faire tourner ! Les CSW et les CDTs ne marchent pas non plus, ni les WAV digitaux sur vos émulateurs, par contre, tout ce monde là tourne sans problème sur un vrai CPC.

Je le redis, la base pour moi c'est pas les émulateurs, mais la vraie machine. Si ça tourne sur mes CPCs et pas sur les émulateurs, c'est un problème d'émulation !



Le CDT est conforme au WAV. L'outil a été codé pour intégrer toutes les données présentes dans le WAV original (sans la crasse et les cochonneries !).

Quand tu prends un CDT généré par l'outil, et que tu le réverses en CSW puis en WAV, ce dernier même si il est digital est 100% identique d'un point de vue vitesse, son de la cassette jouée et timings. C'est juste que la crasse originelle qui empêche l'utilise du WAV brut n'est plus là. On a le signal tel qu'il est avant gravure par la traceuse industrielle.

Comme c'est un problème de prise en charge de format de protection, ces jeux refusent de marcher, quelque soit le fichier utilisé (WAV brut, CSW, CDT, WAV digital).



Aie, j'ai mal au cerveau pour toi ! Aucun des WAV brut tirés des cassettes ne fonctionnent sur émulateur, je dis bien aucun. Pourquoi ? Parce qu'aucun émulateur n'est en mesure de filtrer ces WAVs (alors que mes 464 eux le font sans problème!). Donc ça ne sert à rien que je perde du temps à mettre en download des fichiers d'une taille énorme alors que ça ne servira à personne (vous deux compris), et que moi ça va juste me faire perdre du temps pour que dalle.

Si on a depuis longtemps des outils de filtrages pour virer la crasse des dumps, c'est pas parce qu'un mec s'est levé un matin en pissant dans ses chaussons tout en se disant "merde alors faudrait que j'ponde un filtreur de dump K7!"

Non, c'est juste que personne, je dis bien personne ne sait encore ce jour comment le CPC le fait.

Et de toute façon, je m'appuie sur un fait bien établi, comme l'un et l'autre vous émulez au ras du métal, et gros vous nourrissez le PPI, donc c'est clair, il ne devrait y avoir aucun problème ! Hors manque de bol, malgré cette émulation qui sent le PPI (c'est lundi, je suis en forme lol), ça merde, donc y a un souci d'implémentation chez vous messieurs, comme vous êtes des champions en z80, vous devriez trouver assez facilement d'ou viennent les problèmes.



Pas de bol, tu penses bien que j'ai testé un maximum de softs avant de venir poster. Et comme je m'appuie sur mes machines, et qu'elles ont toujours raison, c'est bien un souci d'émulation CPC.



ça c'est tout autre chose. J'ai quelque WAV de jeux plus ou moins standard qui tournent directement sans filtrage sur mon 464 ou CPCE ou l'émulateur de Thomas.

Moi ce qui me dérange, c'est que les jeux en question tournent tous sur mes 464, sur CPCE (sauf Impossamole), Caprice32.

D'ailleurs regarde, TP nouvelle génération fonctionne sur ton émulateur et pas celui de Thomas !



Sauf qu'ici présent les jeux concernés ne fonctionnent pas sur vos émulateurs (sauf TP sur le tiens), mais bel et bien sur le hardware d'origine, donc d'ou vient le problème d'après toi ? lol



Je te laisse débugger et trouver pourquoi ça foire chez vous et pas sur le hardware



Tu ne te dis même pas que s'il y a la moindre erreur ou bug dans votre propre interprétation vous êtes marron ?

Rien que concernant la protection operasoft, l'anomalie rencontré ne peut que provenir d'un bug d'émulation. Pour que vous puissiez comprendre d'ou vient le problème, il faut que vous débuggiez le format, pour en comprendre les subtilités.

Rien que dans le cas de Mask, vous allez vous amusez, c'est pas de la magie noire, le gus qui l'a conçu a fait une partouze avec le diable !

_________________
SPS Community Expert (SPS CE) / SPS France

pourquoi ne pas prendre un jeux que denis a poster, regarder au niveau ppi sur vos emulateurs ce qui y arrivent, Prendre un analyseur logique connecté sur le ppi d'un vrai cpc et dumper aussi ce qui arrive en vrai.
Comparer le tout...
La difference sera visibile au premier coup d'oeil.

Je vous ais deja proposer de faire ca et avait d'ailleurs posté de quoi faire cette analyse...
Ca serait peu etre plus rapide que de chercher quelque chose que l'on ne sait pas dans 5000 lignes de code.

non ?

Absolument.
C'est la meilleurs méthode sans conteste.
Si tu peux le faire, ça serait vraiment top !

Ma réflexion logique Giants est la suivante : chacun a choisi d'émuler au ras du métal, et donc au niveau PPI. C'est très clair de ce point de vue, si les données sont envoyées exactement comme le CPC émulé l'attend (comme un vrai quoi), chacun de ces CDTs devrait passer comme une lettre à la poste, pareil pour les CSW et WAV.

Hors ce n'est pas le cas. Déjà, quelle vitesse de K7 les émus à Thomas et Yoann gèrent ? Un vrai CPC gère jusqu'à 6500 bauds (en réel!, pas en théorique!).

Est-ce que c'est bien raccord de ce point de vue ?

Ensuite, est-ce que chacun des deux émulateurs gèrent les jeux qui utilisent un loader "simple bordure" ou "double bordure" ?

Il y a tellement de paramètres à prendre en compte rien que sur le jeu Mask, que si tout n'est pas au "carré", ça merdera, la protection ne tolère aucun pas de côté ! Il suffit d'un décalage sur la lecture d'un micro-bloc pour que le chargement se stoppe direct. le jeu comme je l'ai indiqué plus haut fait usage de polarités opposées, est-ce que c'est pris en compte et émulé ??

Tiens comme autre bizarrerie dont j'ai oublié de parler et qui m'a fait rire quand je l'ai vu lors de mes tests sous sugarbox, je charge au hasard un jeu speedlock (dragon ninja, operation thunderbolt), et la qu'est-ce que je vois, l'écran qui se met à défiler de haut en bas, comme si le CRTC déconnait à plein tube.

Sur Dragon Ninja, ça me l'a fait sur le texte indiquant "vous chargez la version 128k, tout les niveaux vont être chargé en ram, et vous aurez les digits en prime !".

Le jeu se charge pourtant correctement, j'ai aucune idée de ce qui peut provoquer ce truc là

_________________
SPS Community Expert (SPS CE) / SPS France

On émule au raz du métal, donc le pb vient d'arrondis mal géré sans doute. Comme un dump disk mfm, on émule au dessous de la protection, donc on s'en fout.

Pour l'écran qui roule, c'est parçe que je n'affiche pas tout ( pour booster le chargement ), c'est un pb de moniteur dans cette config la, rien d'autre.

bah, ca c'est toi qui l'affirme... -> Envoi moi un wav qui est dans ce cas que je vois s'il fonctionne ou pas !?

C'est comme d'affirmer que tous les outils qui partent du wav original pour le transformer en wav 'filtré' puis cdt fonctionnent toujours 100 % ok et sont sans bug !?
Comme j'en sais rien perso, je n'affirme rien et je ne contrôle toujours que mon travail/code ... plutôt que de remettre en question en permanence le reste...

euh, pour le reste, te prends pas la tête pour moi, cela restera toujours du plaisir me concernant, jamais une prise de tête !!!

@dlfrsilver: je sais que je vais peut-être faire le chiant avec ma requête mais contrairement à Lone (ou d'autres), je ne supporte pas le csw. uniquement les CDTs et WAVs. Le format CDT inclus d'ailleurs la possibilité de faire du csw (ID 18 - CSW recording block).

Afin de ne pas passer pas un outil tiers, est-il possible que tu postes ici les wavs 100% conforme pour mask et last mission ?

Effectivement, pour "last mission", j'ai surement un problème d'émulation mais je ne pense pas que cela vient de l'émulation "CDT" puisque le jeu se charge entièrement jusqu'au bout sans pb.

pour mask, cela me semble plus compliqué... en effet, l'ancien cdt que j'ai qui était en id 12 et 14 pure tone et pure data block, etc. (16280 blocks) fonctionne. et après le premier loader, l'image s'affiche, le jeu se charge et marche sans pb...

sur le nouveau cdt, on est en block 13 et 14... donc si j'élimine par défaut que le block 14 ne fonctionne pas (sinon le précédent CDT n'aurait pas fonctionné), il faut que je regarde le bloc 13... sauf que celui-ci est un des plus simple...

ID 13 - Pulse sequence length: [00]*02+01
Offset Value Type Description
0x00 N BYTE Number of pulses
0x01 - WORD[N] Pulses' lengths

This will produce N pulses, each having its own timing. Up to 255 pulses can be stored in this block; this is useful for non-standard sync tones used by some protection schemes.

donc pas d’interprétation possible ici... c'est ce qu'il y a de plus simple.

donc a part une erreur d'arrondi...sur la longueur des pulses, je vois pas bien encore d'où vient l'erreur !

Qu'est-ce que tu entends par un problème de moniteur ? T'es quand même pas en train de dire que le moniteur physique de mon PC déconne quand même ?

Non, tu n'oses pas quand même ? C'est un problème d'écran qui roule dans l'émulateur !
C'est pas l'écran de mon PC qui roule du haut vers le bas XD !



Fait simple, convertis simplement le CSW sous sugarbox et fait en un fichier WAV

Le bloc type 18 est une erreur. Ce bloc là n'aurait jamais du exister. C'est d'une connerie surpuissante d'injecter un CSW dans un fichier master. En plus il est impossible de contrôler le contenu d'un CSW, donc si il y a la moindre erreur (et y a 98% de chance que ça soit le cas à cause de l'analogique......),



Ok, je te poste les 2 wavs 100% conforme.



Oui mais à partir du moment ou l'écran titre est coupé en deux, c'est la garantie que le jeu ne s'exécutera pas une fois le fichier entièrement lu. Le système de protection a été conçu comme ça.



Oui Cesar avait généré un CDT fonctionnel, mais pas conforme et 100% exact (il n'avait pas le temps à l'époque). Là il a pris une journée entière pour décoder le format dans sa totalité.

Comme les outils qu'on utilisait précédemment étaient buggés, on avait malheureusement pas des fichiers correspondant en l'état à ce qu'on avait précisément sur les cassettes.

A présent c'est réglé, le premier outil encode directement au format CSW (du wav compressé quoi), puis on injecte ce dernier dans l'encodeur, qui va récupérer toutes les infos dont on a besoin, et il les encode directement en CDT.

Et quand on fait la réversion, de CDT vers WAV, le WAV numérique généré correspondant exactement au WAV analogique en terme de contenu, mais sans les erreurs.

C'est une boucle simple : WAV analogique => CSW type 1 => CDT 100% conforme => CSW type 1 => wav numérique ; mais on si on refait un CSW type 1 depuis ce WAV numérique, on peut refaire un CDT 100% conforme qui sera identique à celui qu'on a généré en première instance.

Le fait est que le WAV numérique correspondant à 100% au WAV analogique (si on minore la forme du signal, qui est propre à la machine qui a tracé sur la bande en analogique), et que le fichier CSW type 1 correspondant dans les 2 cas.

Je précise aussi autre chose, dans bon nombre de cas, les éditeurs généraient un master DAT digital numérique, qui était lu puis tracé par la machine de duplication en analogique.



Moi ce que je trouve incroyable, ce que vous avez des programmes qui émulent au raz du métal, avec une émulation z80 parfait, une utilisation précise à priori du CRTC et des autres puces, et on arrive encore à avoir ce type de soucis et des jeux qui fonctionnent pas sur émulateur alors qu'ils se chargent très bien sur la vraie machine avec les mêmes fichiers.

Moi à votre place j'aurais envie de hurler



Justement, ça devrait te mettre la puce à l'oreille. Si ton émulation est 100% bonne, que tu gères correctement les blocs, et qu'en plus les fichiers tournent sur les vrais CPC, il ne peut y avoir qu'une seule issue: une erreur d'interprétation dans l'émulation.



Une erreur d'arrondi sur la longueur des pulses ? c'est à dire ? Les timings présents n'ont pas été inventés, ni injectés à la main, ce sont ceux de la cassette



Comme je l'ai indiqué, j'ai testé avant de poster. maintenant comme tu me l'as demandé plus haut, je vais mettre en PJ last mission et Mask. Et tu constateras par toi même.



exactement. L'outil de filtrage et passage en CSW 1 est terminé. Il ne reste que l'outil d'encodage que César doit affiner, car ce dernier ne tolère pas les dumps crasseux (ce qui n'est pas un mal quand je vois la tonne de CDT crade générés via samp2cdt). Quand ce sera fait, et que les derniers systèmes de protection auront été ajoutés, l'outil sera rendu public.

Je peux dire qu'actuellement, les CDTs générés de last mission et Mask sont finaux. le format de chacun d'eux est entièrement compris et supporté par l'outil qui sait exactement via un algorithme super compliqué de quelle manière le décoder et le sortir de sa gangue de crasse analogique.



Comme perso je le sais, puisque je travaille avec césar depuis plusieurs mois dessus, tout à été contrôlé et je dois dire que c'est triste de dire qu'il ait fallu attendre 2016 pour couper court avec les outils buggés de la communauté amstrad. Enfin les choses sont faites de manière empiriques et propres, ça change !

Dans tout les cas, tu trouveras les WAV 100% conformes en PJ !

_________________
SPS Community Expert (SPS CE) / SPS France

Ouf j'ai eu peur un instant

Sinon, j'avais raté ça (faut dire que tes posts sont.... longs !) :



je ne suis pas programmeur. Maintenant celà dit, tu te trompes quand tu dis que la polarité n'existe pas.
ça c'est une "grave" erreur. Mask possède aujourd'hui les bons timings, pas de bol pour vous, le loader fait usage à mort de la polarité, tu te souviens de ce que je disais ? Je parlais de polarité opposée !

César a disséqué en long en large et travers, les 3 loaders de chez gremlin. La polarité est bien utilisée.



Je pourrais le faire, mais ça ne servirait à rien. Je vous propose mieux que les dumps analogiques, leur versions sans erreur en numérique, qui sont exactement pareil, mais sans la crasse (normal, y en a pas dans les masters).



J'ai expliqué que le nouvel outil générait des WAV numériques rigoureusement identiques à ce qu'on trouve sur les cassettes originales. Ils sont 100% conformes, donc vos émulateurs devraient les faire tourner.

Lone

Je peux et je dirais même, je l'ai déjà fait et spécialement pour vous deux !
Regarde le post : http://cpcrulez.fr/forum/viewtopic.php?f=2&t=5279&start=570

Tu trouveras le fichier de dump 'ppi' du CPC
Tu trouveras le Soft qui va te permettre de mouline ces données et les sortir comme tu veux (et le soft est gratuit)
Ainsi que le wav dont tout ça est issue.
Wav qui, une fois joué sur shugar, te permettra de voir ce qui entre sur le ppi
et là, tu compares.

Je part du principe (tu m’arrêtes si je dit une bêtise) qu'il y a forcement une routine d’interprétation des données qui est pas 100% bonne sur vos deux emulateurs.
Donc, peu importe le jeux envoyé sur l'emulateur, les données reçu par le PPI emulé ne sont pas 100% conforme a ce qui est réellement envoyé sur un CPC.
BREF, peu importe le jeu en question, on retrouve le probleme, c'est pratique car pas besoin d'un jeu spécifique pour debuger o_O'
Alors selon la protec, ca passe ou ca passe pas, ca...

Du coup, Je pense qu'avec ce que j'ai déja posté, tu as de quoi faire sur le problème, qui, au final est le même que précédemment.

Si maintenant tu préfères avoir le dump 'PPI' d'un des derniers jeux posté par Denis.
OOOkkkéé, je peux le faire, pas de soucis.
Mais faut que tu l'utilises hein ?

Voilou, dit moi, je fait.

J'ai aussi par ailleurs lu un article concernant l'analogique et le numérique.

L'analogique est un signal prompt aux erreurs, et imparfait, et qui possède la propriété de se détériorer avec le temps quand on le copie.

Le numérique est un signal parfait, qui peut être reproduit sans erreur aucune.

L'idéal est donc de transformer le signal analogique en numérique. Ainsi tout les parasites et autres cochonneries n'ont plus aucune incidence, étant donné que le numérique c'est du 0 ou 1, et du +0v ou du +5v. Un parasite qui se présenterait sous la forme de +0.2v serait ainsi sans importance.

C'est pour cette raison que dire : je veux les dumps originaux analogique, parce qu'ils sont originaux et pas les numériques c'est une aberration en soi. Les logiciels sur K7 étaient au format numérique avant d'être gravé en analogique sur bande.

Les duplicateurs utilisaient des masters numériques et pas analogiques justement à cause des erreurs liées à l'analogique (pour de la musique c'est pas grave, mais pour des données informatiques, c'est un sacré problème, puisque qui dit erreurs dit en l'état arrêt ou bug du programme, alors que leur version originales numériques sont sans erreurs, tout les blocs ou micro-blocs sont impeccables, les timings industriels et non artisanaux ni fait à la main).

Quelqu'un peut m'expliquer ? Pourquoi cette obstination féroce sur l'analogique alors qu'on a exactement la même chose en numérique, c'est à dire ce que le responsable de la duplication remettait à la maison de duplication de cassette ? (Ablex par exemple en Angleterre, ou CAAV, voir KBI en france)

_________________
SPS Community Expert (SPS CE) / SPS France