Inscription : 29 Août 2007, 12:04 Message(s) : 1992 Localisation : seine et marne 77
Megachur a écrit :
Voici mon analyse rapide sur la question :
Oui, on est carrément en régression par rapport aux cdts précédents... là carrément c'est le block 01 et dans l'autre 00 qui ne sont même pas reconnus sur CPCEPower v2103... J'ai même des doutes sur le fonctionnement du CSW / WAV reversé mais vu que je ne les ai pas eus avec...
D'après ce que tu expliques : je soupçonne un soucis dans CSW2CDT et dans CPCEC fortement...
Selon moi, il faudrait que César puisse valider, comme toi, le CDT (ou le CSW/WAV réversé ) sur le vrai hardware d'un 464, etc. indépendamment d'un émulateur comme CPCEC qui ne semble pas encore parfait en terme de timing.
Après aussi, l'outil TZXDuino de lecture du CDT que tu utilises n'est peut-être pas non plus une référence non buguée vu que cela n'a pas été écrit par un spécialiste du cpc comme César... Il faudrait surement analyser les sources, mais de mémoire il était incapable de générer des timings précis à 1Mhz comme le PPI... En regardant rapidement, je n'ai pas vu dans le code la fréquence d'appel mise pour le loop...
Un analyse du source de la dernière version disponible 1.8 d'il y a 4 ans par César ou autre, me semble indispensable... https://github.com/sadken/TZXDuino
par exemple : 1) il ne semble pas qu'il y ait de gestion du démarrage / arrêt progressif du moteur du player de K7 dans le code 2) tout les timings sont arrondis, disons bizarrement avec un +0,5 !!!
Code :
word TickToUs(word ticks) { return (word) ((((float) ticks)/3.5)+0.5); }
d'ailleurs, je vois qu'il y a un bug ouvert depuis 2017 sur la lecture des bleepload :
Code :
https://github.com/sadken/TZXDuino/issues/1
on est encore loin de la nouvelle précision de CPCEC ou des nos émulateurs...
En même temps, j'arrête pas de dire que les timings sont OBLIGATOIREMENT arrondis !
Si tu m'as lu (j'ai pas l'impression) :
j'ai dit que j'ai fait des tests hier sur CPC 464, et c'est clair, concernant le système Bleepload v1 et les keytones, AUCUN émulateur n'est bon !
que ce soit Caprice Forever, CPCepower, Sugarbox, CPCEC, soit ça passe pas alors que ça devrait, et quand ça passe, ça devrait pas !
Personnellement, je veux pas entendre "oui mais CPCEC et csw2cdt quand même y a un souci hein", alors que mes tests montrent que vos émulateurs font passer des protections ou des fichiers WAV qui ne fonctionnent pas sur mon CPC 464. Et je parle de WAV réversés.
Je suis occupé ce midi, je reviens sur le topic en cours d'après-midi.
_________________ SPS Community Expert (SPS CE) / SPS France
Inscription : 29 Août 2007, 12:04 Message(s) : 1992 Localisation : seine et marne 77
Fredouille a écrit :
Cool, on a l'air de retrouver un peu de sérénité pour avancer sur ce sujet...
Pour moi on est en stand-by complet. La sérénité, ce sera quand les keytones et le système Bleepload v1 seront correctement gérés par vos émulateurs, csw2cdt, et CPCEC.
Pour le moment on y est pas.
Je ne m'explique pas la différence entre mon CPC 464 et les problèmes rencontrés sur émulateurs.
Ce qui est casté dans la pierre, ce sont les jeux dont les protections sont bien comprises, et dont les WAV réversés fonctionnent sur un vrai CPC et par ricochet sur les émulateurs.
ça pour moi, c'est bon, ça veut dire qu'on maitrise le sujet sur ces derniers. Maintenant, pour les keytones et le système bleepload v1, ça va pas. Il y a quelque chose qu'on ne prend pas en compte, que le CPC fait, et que les émulateurs ne gèrent pas.
_________________ SPS Community Expert (SPS CE) / SPS France
Inscription : 26 Nov 2008, 10:04 Message(s) : 174 Localisation : Saint Ouen l'Aumône
Pour moi, il faut partir des WAV originaux pour comprendre ce qu'il se passe, et les essayer sur d'autres machines. Si les WAV sont OK, alors on peut les essayer sur les émulateurs. Si c'est OK, on peut créer un CDT qui sera réversé puis comparer les WAV...
Le but est de tester les wav sur emu et sur vrai cpc
Si au moins une personne fait passer le wav sur un 464 alors on sait que celui ci est bon
Si un wav ne passe pas alors de mon point de vue c’est qu’il n’est pas bon puisqu’en toute logique on devrait pouvoir le faire passer sur le 464 tel quel, a la limite il devrait aussi passer sur emu puisqu’il ne passe à travers aucune conversion (du filtrage au pire qui devrait pouvoir être désactivé)
Inscription : 29 Août 2007, 12:04 Message(s) : 1992 Localisation : seine et marne 77
Fredouille a écrit :
Pour moi, il faut partir des WAV originaux pour comprendre ce qu'il se passe, et les essayer sur d'autres machines. Si les WAV sont OK, alors on peut les essayer sur les émulateurs. Si c'est OK, on peut créer un CDT qui sera réversé puis comparer les WAV...
J'ai plusieurs CPC 464, révisés, que j'utilise à tour de rôle pour tester les WAV.
Et mon expérience montre que les WAV tirés des cassettes ne sont pas lisible directement et sans erreur, tout simplement à cause des bruits, des parasites et de la crasse inclue dedans. Je dirais qu'à la louche, seul 10-15% des WAV fonctionnent directement. Le circuit de filtrage des CPC étant incapable dans bon nombre de cas de filtrer et corriger les erreurs présentes.
C'est la raison pour laquelle on utilise des outils pour filtrer les dumps.
Le problème est le même sur les disquettes en flux, jamais au grand jamais graver un dump en flux lourd directement sur disquette, sans que les impuretés ne soit regravées avec. On doit extraire les données et les séparer des parasites/bruit et compagnie autrement, ça ne marche pas.
csw2cdt a été testé sur un gros millier de dump cassettes que j'ai réalisé. C'est sur la foi de la réussite du chargement des WAV réversé qu'on a validé son bon fonctionnement (c'est le cas pour 90% des softs protégés).
Seul les bleepload v1 et les jeux à keytone posent soucis.
Donc je peux poster ici le WAV original de Bride of Frankenstein, mais ça ne prouvera rien, puisque le problème se pose sur la partie CDT et la réversion en WAV qui doit être testée et fonctionner sur un vrai CPC.
si la réversion fonctionne sur les émulateurs mais pas sur un vrai 464, on est pas bon, pour pas dire offtrack !
Et si ça coince sur émulateur, c'est que le problème est côté émulateur.
Inscription : 26 Nov 2008, 10:04 Message(s) : 174 Localisation : Saint Ouen l'Aumône
Je voudrais juste revenir sur le WAV original de "Bride of frankenstein".
Lorsque je mets ce fichier dans Goldwave, je peux voir que le bruit est largement amplifié à partir de 8min 51s 905ms. Un peu comme si cette partie, qui correspond à la clé, n'est pas d'origine.
Inscription : 20 Août 2013, 18:03 Message(s) : 258
Fredouille a écrit :
Je voudrais juste revenir sur le WAV original de "Bride of frankenstein".
Lorsque je mets ce fichier dans Goldwave, je peux voir que le bruit est largement amplifié à partir de 8min 51s 905ms. Un peu comme si cette partie, qui correspond à la clé, n'est pas d'origine.
Ou volontairement bruitée pour rendre la copie difficile voir impossible ?
Inscription : 29 Août 2007, 12:04 Message(s) : 1992 Localisation : seine et marne 77
Fredouille a écrit :
Je voudrais juste revenir sur le WAV original de "Bride of frankenstein".
Lorsque je mets ce fichier dans Goldwave, je peux voir que le bruit est largement amplifié à partir de 8min 51s 905ms. Un peu comme si cette partie, qui correspond à la clé, n'est pas d'origine.
Pas d'origine ? Tu peux préciser le fond de ta pensée ? Depuis quand les logiciels K7 commerciaux sont pas d'origine ?
Tout les jeux cassettes Amstrad CPC étaient dupliqués en usine. Sans exception.
Par ailleurs, un keytone par essence, c'est un bruit, plus rarement un microbloc contenant des informations spécifique. Ce bruit audio correspond dans le cas de Bride of Frankenstein a une valeur, valeur qui est vérifiée par la routine incorporée par le programmeur.
_________________ SPS Community Expert (SPS CE) / SPS France
Inscription : 29 Août 2007, 12:04 Message(s) : 1992 Localisation : seine et marne 77
Megachur a écrit :
En complément d'analyse, je t'engage à faire le test suivant :
nous allons profiter de que le loader bleepload v1 est réentrant avec contrôle d'erreur au moins sur la première partie :
1) on met le CDT en question Helichopper (UK) (1986) (v6-86) [Original] [TAPE].cdt en chargement sur CPCEPower v2103. 2) Error block 02 not found ! 3) on prends CSW2CDT (dernière version csw2cdt-20191102), on convertie/décode le cdt Helichopper (UK) (1986) (v6-86) [Original] [TAPE].cdt en csw et en wav. 4) on mets le csw ou le wav reconstruit depuis le cdt avec CSW2CDT 5) on press play à nouveau... on attends... et... le loader trouver bien le block 02 et charge tout jusqu'au jeu... conformément au test que tu as fait sur ton 464+ !!! Egalement bien sûr, si on commence le chargement avec le csw ou le wav reconstruit depuis le cdt avec CSW2CDT : no problemo, c'est conforme !
voilà comme cela on est d'accord, le csw/wav reconstruit depuis le cdt avec CSW2CDT fonctionne bien sur le vrai hardware et aussi sur CPCEPower...donc je dois pas être si mauvais en timing alors, non ?
quelle conclusion sur les timings de ce CDT et sur l'encodage / décodage de CSW2CDT avoir maintenant ? --> peut-être un manque de précision, est-ce une limite du code dans CSW2CDT ou de l'encodage du format TZX ??? --> pourquoi on a pas ce soucis sur les autres bleepload v1 ?
Bonsoir à tous, j'ai enfin découvert le mystère, enfin le secret de la protection Bleepload v1 (musical ou non).
J'ai découvert qu'en fait, cette protection locke ou du moins s'attends à un volume sonore de 15% maximum.
J'ai passé mon dimanche à faire des tests sur les WAV tirés des cassettes Bleepload v1, mais aussi à tester les WAV réversé des CDTs générés après filtrage, grâce à mon CPC 464.
Nous avions connaissance de l'instabilité et de la fragilité du signal des cassettes bleepload v1, avec des erreurs jusqu'ici totalement aléatoire, aussi bien en rejouant via goldwave le WAV tiré des cassettes que les WAV digitaux, alors que les émulateurs eux passent les WAV tranquillou (sauf certains pour CPCepower ou Caprice Forever) et les CDTs côté CPCEC.
Le problème est un combiné entre le loader bleepload v1, et une inconnue que nous n'arrivions pas à trouver avec César.
Cette inconnue, c'est tout simplement le niveau sonore de playback, que j'ai découvert et que le CPC fait de façon totalement cachée comme une boite noire.
La ou un speedlock par exemple va demander un volume de playback de 100%, avec un niveau de 15%, le speedlock ne passera pas à la lecture sur un vrai CPC, parce que le loader speedlock attend un certain volume sonore pour charger correctement les données.
Ici, le loader bleepload v1 utilise un niveau sonore de 15% sur tout les jeux sans exception utilisant cette protection. Avec cette valeur, j'ai un taux de réussite de chargement de WAV de 100%. Idem pour les WAV réversés depuis un CDT.
De fait, j'ai plusieurs nouvelles bonnes et mauvaises à vous donner:
ça veut dire que la chaine WAV de K7 - CSW - CDT -WAV digital est correcte et fonctionnelle. C'est donc une bonne nouvelle
Que donc csw2cdt fait correctement le boulot, puisque avec 15% de volume mon 464 lit les jeux bleepload v1 sans erreur.
La mauvaise, c'est que quand Megachur me dit qu'Helichopper en CDT ne fonctionne pas alors que mon 464 charge parfaitement le WAV digital qui en est tiré avec le volume à 15%, c'est une confirmation que CPCepower à un souci côté gestion de CDT. D'un autre côté, CPCEC ne sait pas charger tel quel les fichier WAV tiré des cassettes car il ne fait pas de filtrage.
C'est parfaitement logique, puisqu'on ne peut pas créer de WAV digital fonctionnel depuis un CDT qui ne fonctionne pas.
L'autre issue négative des multiples tests que j'ai effectué, montre que les émulateurs sont trop souples en terme de gestion d'erreur. Cylu par exemple en WAV tiré de la cassette plante systématiquement sur mon 464, parce que le WAV a quelques bits crasseux. Mon 464 ne les filtre pas, alors que vos émulateurs filtrent l'erreur et chargent le jeu. Moi c'est un souci dans le cadre de la préservation, puisque je n'ai pas pu voir cette erreur étant donné que vos émulateurs filtrent à mort les données, plus que ne le fait un 464.
J'ai pu également vérifier que le WAV digital, tiré du CDT de Cylu après filtrage, fonctionne sur mon 464, étant donné que la crasse a été filtrée.
Concernant CPCEC, je vais voir avec césar comment prendre en compte le comportement d'un vrai 464 pour ce qui est du volume du playback effectué par le lecteur de cassette. La manipulation qui consiste à abaisser le volume à 15% manuellement dans goldwave, le 464 le réalise automatiquement, autrement, le loader bleepload v1 ne pourrait pas reconnaitre les données.
Donc à caster dans la pierre : on ne peut rejouer via goldwave les jeux bleepload v1 via cassette digitale uniquement en abaissant le volume à 15%. Au delà de cette valeur, le signal se biaise, et les données se corrompent, entrainant de facto les erreurs de lectures à répétition.
Moralité de l'affaire : 90% des jeux se jouent avec un volume de 100%, et les 10% restant, avec un volume autre.
_________________ SPS Community Expert (SPS CE) / SPS France
Inscription : 26 Nov 2008, 10:04 Message(s) : 174 Localisation : Saint Ouen l'Aumône
Pour moi, 100% de volume ne veut pas dire qrand chose.
Avec Breiztiger, on a fait beaucoup d'essais hier pour faire passer les WAV sur mon 464. La plupart passait avec un volume de 30% et un seul avec un volume de 40%. Au-dessus, aucun de passait.
Les PCM8 ont une amplitude de 50% environ alors que les PCM16ST ont une amplitude de 80-90%. Pourtant, le CPC semble les accepter aussi bien.
Le Wav de "bride of frankenstein" est passé alors qu'il n'est pas lu par Caprice... Par contre, quasiment aucun WAV créé par Caprice issu d'un CDT ne passe, hormis "Killer Ring".
Pour mes essais, j'utilise mon vieux eeePc avec goldwave qui crache sur une vieille soundblaster X-fi go puis directement sur une cassette Belkin dans le 464. Les 30 ou 40% de volume correspondent au volume sonore des signaux envoyés par Windows à la SoundBlaster. Je n'ai pas touché aux réglages de Goldwave.
On s'est rendu compte hier qu'il était nécessaire de qualifier la chaine audio afin de pouvoir parler de la même chose.
Utilisateur(s) parcourant ce forum : Aucun utilisateur inscrit et 7 invité(s)
Vous ne pouvez pas publier de nouveaux sujets dans ce forum Vous ne pouvez pas répondre aux sujets dans ce forum Vous ne pouvez pas éditer vos messages dans ce forum Vous ne pouvez pas supprimer vos messages dans ce forum Vous ne pouvez pas insérer de pièces jointes dans ce forum