Petite question : Pourquoi les DRB sont-ils considérés comme si mauvais ?

Ca me parait la solution idéale : Pas de place à l'interprétation (du style : Après une pause, c'est pulse "high" ou "low" ??)

En regardant le wav de Mask (qui passe sans frémir; sur une version de Sbx un peu débuggée ) : Il fait ce que je pense qu'il doit faire : Les deux "Big pulses" sont dans l'ordre (high puis low), alors que quand je décode le CDT, j'en déduis l'inverse, ce qui me posait soucis : On mesure le pulse "low" (le second), alors que s'ils sont inversé, le décodage de ce pulse arrive trop tard (on a une sorte d'overflow, vu qu'on time la pulse en ratant le début).

Du coup, je me demande ce qu'on doit penser d'une "pause" : Comment repartir après sans se tromper ?
D'ailleurs, je me demande bien comment ce cas est géré par d'autres émulateurs : J'ai généré un CDT "patché" avec un pilots comprenant un nombre paire de pulse (comme sur le wav), et j'ai le résultat suivant :
- Winape fait tout marcher (je pense que ça n'est pas forcément bon signe)
- Sugarbox passe la version patchée, mais pas la version officielle
- CPCE passe la version générale, et pas la patchée

En fait, CPCE et Sugarbox ont un comportement correct. La différence réside dans l'interprétation du CDT (après cette fameuse pause... ou Sbx part avec une pulse "high" et CPCE sans doute "low" )

Bref, difficile de trancher avec les infos que j'ai...


PS: Pour les néophytes, DRB = Direct Recording Bloc : c'est une sorte de sampling de bloc (chaque bit de chaque octet de ce DRB est un sample, en fait (0 ou 1)).

Hello,
J'arrive certainement après la bataille.
Effectivement, Mask n'est pas sur mon site car je en suis pas arrivé, à l’époque, à le dumper de manière a ce qu'il fonctionne sur émulateur.
Du coup, je l'ai redumpé ce matin et tu peux trouver le dump brut des deux faces là (16bits 44.1 stéréo, 105Mo)

Pour le dumper, j'ai utilisé ma méthode habituelle qui est d'intercepter le signal directement à la sortie du lecteur k7 d'un CPC 464 puis de échantillonner avec Wavosaur (très bon outil gratuit !) au travers de ma carte son (suivant les cas la realtek intégré au PC ou ma vieille MAudio delta que j'utilise pour la musique).
Le montage coté CPC m'avait été indiqué par Irios et ressemble à ça :


J'ai de très bon résultats généralement et cette méthode permet de s'assurer que le jeu passe bien sur le CPC (il s’exécute en même temps).

Pour les WAV de mon site, j’effectue des retraitements audio pour rendre les wav plus compressibles et simplifier le signal. J'avais donné le détail là.
Enfin, pour la partie conversion CDT, j'utilise samp2cdt couplé à une petite interface que je me suis codé

Malgré tout ça, il arrive que ça ne suffise pas et suivant ma motivation, je peux mixer les résultats obtenus a partir de plusieurs sources (les 2 faces ou plusieurs versions équivalentes du jeu), généralement en utilisant CPCTapeXP.
Enfin, on arrive a "rattraper" certains wav en les passant par la formule (pas toujours) magique csw.com crée par César Nicolás González et fournit avec CPCE. Je ne sais pas trop comment ça marche en pratique mais il arrive que ce soit très efficace.

JMD

En tout cas, ces deux dumps sont nickels (et permettent de comprendre ce qui se passe, surtout !)

Merci à vous deux !

A-t-on moyen de contacter Cesar ? J'aimerais lui poser la question concernant Mask, histoire d'avoir une conclusion définitive sur le sujet.

voici un début de réponse de sa part au sujet des pauses :

"Toutes les pauses sont identiques d'après le standard TZX; Elles forcent l'état interne à l'état 'low'."
Elles le forcent après le premier millième de seconde de pause si il n'est pas encore à l'état 'low'. C'est de cette manière que le standard s'assure que la polarité de chaque pulse dans la cassette est toujours prévisible, en évitant l'ambiguité des dernières pulses qui sont en état 'high' ou 'low' après les pauses.

Rhaaa, c'est bien là ou je trouve que ça coince : J'ai implémenté cette vision des choses (La pause force l'état "low", et donc l'état immédiatement suivant est "high"). Et cette vision ne fonctionne pas avec le CDT généré de Mask, ou il est nécessaire d'avoir un état "Low" immédiatement après la pause pour que ça marche...

Ce qui est également étrange, c'est que CDT2WAV utilisé sur ce Cdt de mask va faire la chose inverse :
Considérons 1 comme high, -1 comme low, et 0 comme "pause" : Après la pause (positionéne sur le 0), on a un état low (-1)... Ce qui semble contradictoire, mais fait en fait fonctionner correctement le WAV généré en le rendant a peu près conforme au WAV original

J'ai exactement cette implémentation (d'ailleurs, les wav de mask - les tiens et ceux de JMD - passent parfaitement).

De toute façon, on ne peut pas faire d'émulation un peu sérieuse des cassettes sans passer par là.

Concernant CDT2WAV, si tu le passes sur le CDT généré, et regarde le résultat, tu verras, a 3:15,690.... Une pause, suivi d'un level low... Et le wav résultant passe sur sugarbox.


Bref, j'en perds mon latin.

Je vais tacher de générer un wav a partir de mon implémentation du cdt , pour voir si ça passe sur CPCE.

Voila, c'est codé.

J'ai donc pris la version "originale" de mask en cdt (celle de cpc-p0wer), regénéré par mes soins en wav. Verdict : Ko sur sugarbox (pas étonnant) et cpce.
Ensuite, ma version patchée, regénérée en wav.
Verdict : Ok sur sugarbox (encore heureux) et ok sur CPCE.

Conclusion : Je suis en phase sur le fond avec CPCE.

Corollaire : CPCE fait quelque chose différemment de moi sur le décodage du CDT.

J'avoue que j'adorerais avoir l'avis de César sur le sujet...

Mes wav générés : Http:\\sugarbox.free.fr/release/Mask.zip

PS : Je viens de lancer CPCE en version "Tape compatibility" et "Tape speedup".
Et là... Le CDT officiel de cpc p0wer plante, exactement comme Sugarbox. Et ma version patchée fonctionne. Comme Sugarbox.

On avance, les amis

My bad, c'est bien polarity que j'ai coché ...
Et qui fait que ça ne marche plus.

Sugarbox.free.fr/Mask.zip devrait mieux marcher.
Ces WAV sont générés par un build spécial debug de sugarbox.