Parçe que tu interprètes l'analogique pour en faire du numérique, forcément.
Interprétation : sujet à erreur ( voir les anciens Dumps avec la polarité, réputé parfait 100% eux aussi...)

Par ailleurs, un wav est toujours du numérique : une fois dumpé il ne va plus bouger....
C'est pour ça qu'il faut les dumper soigneusement et surtout, conserver ces originaux.

Parler de wav numérique ou analogique n'a pas de sens : c'est un format numérique, point.
Éventuellement, tu peux parler d'un wav issue d'une source analogique.

Justement non. Interpréter veut dire ici 'modifier' et qui dit modifier dit 'altérer le contenu et donc l'abimer.

Ce n'est pas ce que nous faisons. L'analogique doit être passé en digital, je vais pas te donner un cours ni même te parler de la théorie de Shannon.

Ce qui me dérange sérieusement, c'est que ton raisonnement sous-entends salement que si les fichiers ne fonctionnent pas sur ton émulateur, c'est qu'ils contiennent des erreurs, erreurs qui font planter vos émulateurs respectifs.

Pas de bol, les vrais CPC eux me disent que tu te trompes



Aucun outil avant celui de césar ne gardait les timings, samp2cdt les calculait au pif, je vais même pas dire au doigt mouillé....

La polarité existe, c'est un fait absolu, c'est pas parce que CPCE ne les gérait pas à la base correctement et que les timings n'étaient pas 100 % conformes dans les CDTs que la gestion de polarité par les loaders des softs n'existent pas.

Tu fais un syllogisme, c'est pas parce qu'il y a des chiens roux et qu'il y a des chiens gentils que tout les chiens roux sont gentils !

Mais voilà, on peut discuter des heures et des heures, tant que vous n'aurez pas regardé ce qui se passe, ça n'avancera pas



Je vais dans ce cas t'apprendre (pour une fois lol) quelque chose : mon matériel est supérieur d'un point de vue technologique et précision à ce qu'un amstrad CPC 464 lit et transforme.

Notre ami JMD1200 t'a donné un lien avec des dumps à lui en WAV, qui ont été enregistré au niveau des pins de sortie du lecteur K7. Mon propre magnétophone Sony TCM-939 sort un signal encore plus propre que ça de base, alors que les WAVs à JM ont été filtré en hard par son CPC 464 !

Sans remettre en question la qualité des dumps de JM, qui sont tout à fait bien (ça je peux le confirmer ), quel est l'intêret en soi de vouloir garder à tout prix les WAV contenant le signal analogique alors que ceux-ci sont dans 80% des cas inexploitables ? On ne peut rien en tirer tant qu'ils ont leur gangue de crasse, et en plus les émulateurs ne peuvent pas les exploiter !

A la différence des dumps kryoflux, que le FDC peut lire sans problème, pour les cassettes on a plusieurs problèmes : leur âge, les bandes qui vieillissent, la fragilité du signal analogique avec tout ses défauts.

Le but est de sauvegarder le contenu, qu'il soit sans erreur et 100% conforme au master digital d'origine, et non de faire comme c'était en 2003, garder des WAVs pourris dumpés ou non avec du matériel de qualité.



Oui d'accord Mais y a une différence entre un WAV qui contient des erreurs et de la merde liées au support sur lequel a été enregistré le signal et un WAV identique propre sans aucune cochonnerie !

A t'écouter, on jurerait que les masters originaux était aussi crasseux que les dumps qu'on fait depuis les cassettes commerciales, et qu'on doit garder des WAVs sales par conséquent, je dis non non surement pas !



Si tu veux

_________________
SPS Community Expert (SPS CE) / SPS France

je complète mon post précédent avec ceci :

"Une fois sous cette forme le signal peut être copié et transmis sans pertes car au lieu de transporter un signal dont l’amplitude doit varier fidèlement à l’original on transporte un signal formé de seulement deux amplitudes (par exemple 0=0volt et 1=5volts) .

Ainsi lorsqu’un parasite perturbe un signal analogique , en numérique ce parasite aura aucun effet : par exemple un parasite qui ajoute 0.2v de perturbation va détériorer un signal analogique alors que ce même parasite sur un signal numérique n’aura pas d’effet car 0v+/-0.2v sera toujours considéré comme = " 0 ".

Le signal numérique est donc un signal analogique constitué de deux niveaux possibles (par exemple " 0 "=0v et " 1 "=5v) et lorsque le signal analogique s’éloigne de ces deux tensions cela n’est pas grave car tous signal proche de 0v sera considéré comme = " 0 " et tout signal proche de 5v sera = " 1 " avec un seuil de tension entre les deux d’ou une immunité exceptionnelle contre les parasites et une facilité exemplaire à faire des copies parfaites (clones) de ce type de signal."

Est-ce que c'est plus clair pour toi ?

_________________
SPS Community Expert (SPS CE) / SPS France

Notre amis César est très calé sur le sujet, mais cela ne veut pas dire qu'il est infaillible.
C'est quelqu'un de modeste et je ne pense pas qu'il aurait le même discours que toi.

Quoi qu'il en soit, c'est vraiment génial qu'il ait fournis de nouveaux outils pour aller de l'avant, mais il faut toujours envisager toutes les éventualités et non pointer systématiquement l'émulateur lorsqu'il y a un problème de compatibilité CPC <-> DUMP <-> Emulateur.

_________________
Cent Pour Cent

Tu confonds binaire (deux valeur possible) et numérique (2^n valeurs possible).

Parce-que justement non, tu n'a pas la même chose avec ton format binaire qu'avec un format wav 'analogique'.
Tu semble faire abstraction que la chaine de traitement sur un CPC est entièrement analogique, et que ta méthode de vérification de tes CDT 'parfait' repasse par une conversion vers l'analogique avant d’être digérè par ton CPC réel.
Du CDT tu passe en wav binaire
Ton wav binaire est ensuite converti par ta carte son (avec sans doute des tas filtrage numérique et aussi analogique)
Tu injecte ça dans to CPC avec une cassette avec encore une altération du signal (couplage des têtes, caractéristiques des têtes)
Ensuite il y a toute la section analogique du lecteur du CPC avant d'arriver au PPI en analogique.

Un émulateur, pour être parfait doit émuler la section analogique du CPC, et y injecter un signal binaire (0/5V) n'est pas forcement approprié, et quand tu cherche a résoudre un problème, plus tu as de sources et de moyen de comparaison, plus tu a de chance de trouver.

César n'est pas infaillible, comme je l'expliquais, il doit en être au moins à la 30ème révision de son programme depuis qu'on a démarré.

Il découvre, corrige, et moi je lui fourni des dumps par centaine. Il n'est pas question de modestie ou d'égo ici.

J'ai attendu qu'on ait une version suffisamment pointue du logiciel pour venir poster sur mon topic.
Je voulais être sur de poster des fichiers qui soient impeccables.

J'ai même demandé confirmation avant de le faire à César.



Justement, c'est à lui, qui est programmeur de son état de vérifier que tout est correct au niveau de son logiciel, et c'est ce qu'il fait. Je l'assiste de mon côté, et je lui soumets des idées, il les implémente ou pas, et il en ajoute aussi de lui-même.

J'étais tout content quand il m'a dit "j'ai déssossé intégralement les systèmes de chargement de gremlin, on va devoir les renommer, car il n'y a pas 2 systèmes d'encodage, mais 3. Mask est le troisième type d'encodage, c'est le plus complexe, il m'aura fallu une journée entière pour comprendre son fonctionnement.". Il n'était pas chaud au début pour l'implémenter, et finalement il l'a fait

Concernant le problème de compatibilité CPC - DUMP - Emulateur, comme je le disais plus haut, certaines parties du CPC ont encore à ce jour des parts d'ombre.

Avec César on est parti de zéro, et on a pris le parti de se dire, y a eu trop de problème de dump sales, mal décodés, avec des timings foireux, résultat, quand ça marchait sur un émulateur ça marchait pas sur d'autres, on peut plus continuer comme ça, à perdre du temps à nettoyer des dumps dégueulasse qu'il faudra redumper au final, alors que l'émulation ne doit viser qu'un fonctionnement identique à la machine visée.

Donc, lui comme moi on en a marre de retoucher les CDTs à la main, c'est les softs qui devraient faire ça d'après les infos de la cassette d'origine. De ce fait, tout les CDTs et WAV nouvellement sortis fonctionnent tous sur les 464 et 464+ (suivant compatibilité du programme pour le plus hein).

Comme on est sur du 100% bon, c'est clair, maintenant, plus de tricherie ou tour de passe passe, si ça marche pas en émulation, c'est qu'il y a une couille d'implémentation.

Moi je préfère savoir comme je l'ai dit à césar qu'un jeu original ne tourne pas sur CPCE, mais qu'au moins le jeu soit 100% bon de tout point de vue, et pareil pour les autres émulateurs, si ça déconne ou que ça marche pas, c'est que quelque chose est incorrect en ému.

Si le jeu marche sur mon 464(ou +), ça doit marcher sur tout le reste

_________________
SPS Community Expert (SPS CE) / SPS France

+1 a ce que vient de dire Gerald

Perso, je pense qu'on peu justement ce passer de cette couche 'wav' pour le debug en passant par la phase : DUMP direct sur le PPI
et ensuite comparer avec ce que l'on envoie dans l’émulateur sur le PPI via la routine en question.

LA, on verra la diff (même si, au niveau donnée, ça va susurrement être colossale.)

Sinon... honnêtement... bonne chance pour trouver...

J'avoue d'ailleurs ne pas trop comprendre pourquoi vous plus'oyer pas dans ce sans ? O_o'


Quelqu'un d'ailleurs aurait un petit programme sur CPC pour voir ce qui passe en direct sur le PPI en entrée ?

Pourtant : viewtopic.php?f=2&t=5279&start=960#p50001

_________________
Cent Pour Cent

Bon ok Gerald Tu me parlerais de musique gravée en analogique sur une cassette, je te dirais ok, tu as surement raison.

Ici on parle de données informatiques, des 0 et des 1. Donc de deux choses l'une, soit ce qu'on récupère est conforme, et ça s'entend à l'oreille (je suis pas programmeur, mais j'ai l'oreille musicale )

Quand on a un WAV qui est altéré ou différent d'un dump tiré d'une cassette, le son émis est clairement différent, et visuellement il y a une différence, je m'explique :

Quand on générait un CDT avec samp2cdt, et que le jeu utilisait un speedlock, on pouvait voir que les stries dans le border étaient peu mobile, au lieu de bouger à l'écran dans tout les sens comme sur la cassette originale.

Pourquoi ? Tout simplement parce que le mouvement des stries est la conséquences de la lecture des timings, qui ne doivent pas être fixes, mais variables. Je l'ai expliqué il y a quelques postes de ça.
Samp2cdt rigidifiait les timings, alors que le nouvel outil prends les timings présent dans le fichier CSW tiré du WAV brut, les relève et les injecte directement dans le CDT qui va être crée.

Quel est le résultat ? Les stries du speedlock bougent comme sur la cassette originale, et le son émis est pareil J'ai trouvé ça hallucinant quand j'ai testé pour la fois le nouvel outil.

Franchement, le résultat était tellement bien et loin de ce qu'on avait avant que j'ai applaudi devant mon écran, quel bonheur d'avoir enfin la même chose que sur la cassette !

Dans le même ordre d'idée, Mask par exemple est tellement fidèle au WAV original, que le WAV digital tiré du CSW tiré lui-même du CDT 100% conforme quand il est lu par le CPC émet exactement le même son étouffé et qui fait des plops que la cassette originale.

Je trouve ça juste magique

Il s'est en partie inspiré de ce qui se fait sur Commodore 64, ou les mecs sont très à cheval sur les timings des jeux en cassette, tout doit être parfait. Mais maintenant c'est sur Amstrad CPC que ça se passe



Je connais parfaitement la chaine en question :

C'est cassette gravée par une machine en analogique depuis un master DAT digital, cassette avec signal analogique lue par le CPC, qui converti le signal en numérique avant passage dans le PPI (un ordinateur ne gère que des 0 et des 1 donc du numérique).



oui du CDT je passe en CSW, qui est un format WAV compressé, puis de CSW à WAV numérique.

L'outil de césar fait une conversion exacte au bit. Jusqu'ici aucun outil ne permettait ça.

Mon WAV binaire n'est en aucune façon converti par ma carte son. Sache le, l'amstrad CPC sait gérer le signal analogique des cassettes, mais aussi le signal digital, sinon, il me serait impossible de jouer depuis goldwave des WAV numériques de jeux.

Ma carte son ne filtre rien du tout justement, c'est une carte son haut de gamme, sur laquelle ma cassette digitale est connectée à la sortie speaker.



couplage des têtes ?? tu peux m'expliquer, c'est du chinois pour moi ?



Le PPI gère du digital, soit du 0 et 1. la phase analogique c'est avant. Tout ordinateur ne peut de toute façon ne gérer de base que du numérique et rien que du numérique. Pour gérer de l'analogique il faut un circuit spécifique (qui est intégré au lecteur de K7 du CPC).

Le CPC est donc obligé de convertir l'analogique en numérique avant de feeder le PPI du CPC.



je suis d'accord au sujet de la section de filtrage analogique de la machine. Le problème qu'on a ici est que les données ne sont pas feedées correctement à la machine émulée, ce qui provoque le plantage des protections utilisées.

Problème pour moi : je ne suis pas programmeur, je ne peux de fait pas aider de ce point de vue.

Par contre, comme je suis un spécialiste du hardware, c'est assez simple de comprendre que si un CPC 464 fait tourner le logiciel avec le fichier qu'on lui met dans le bec, et que cette même opération ne marche pas sur un émulateur, ce dernier a forcément une couille.

Par définition les protections utilisent tout un tas de tour de passe passe voir des fonctions non documentées, qui font que si la personne qui implémente dans un émulateur ne comprends pas, ou ne voit pas ce qui se passe, l'issue est courue d'avance, c'est un plantage assuré.

_________________
SPS Community Expert (SPS CE) / SPS France

A un moment, mieux faut que chacun se cantonne à ses compétences pour aller ensemble de l'avant.
Ici, Gerald à raison. Du coup, ça ne sert à rien de vouloir lui prouver que rouge c'est bleu.

_________________
Cent Pour Cent

Sauf que le PPI ne prend que du binaire, des 0 et des 1, donc du numérique et pas de l'analogique

_________________
SPS Community Expert (SPS CE) / SPS France

Sauf qu'avant le PPI il y a toute une chaine de filtrage analogique que tu refuse de prendre en compte !
Pour un test 100% binaire, il faut que tu teste tes CDT sur CPC réel avec une injection directe au niveau du PPI, pas par une chaine PC/Carte Son/fausse cassette/Lecteur CPC. Pour cela il te faut du matériel dédie (mais c'est un autre sujet. PM si tu veux en discuter)
Si le CDT parfait passe dans ce cas et pas sur un émulateur, on a un vrai point de comparaison.

Gerald, si je te file un 'dump' via analyseur logique de ce qui arrive sur le PPI avec tel ou tel jeux, ca t'aide ?

Je sais parfaitement bien qu'il y a une chaine de filtrage analogique, c'est normal

Ce que je dis de mon côté, c'est que le problème rencontré n'est pas lié à l'analogique ou au numérique.



C'est faisable Mais comme je le disais, ce qu'on trouve dans les CDTs que j'ai fourni, c'est ce qui se trouve dans le WAV brut sans la crasse.

Ce qui compte, c'est de savoir si un 464 lit correctement le fichier. Comme c'est le cas, j'en déduis qu'il y a un problème côté émulateur.



En fait, César a conçu son outil pour que le contenu du WAV, du CSW et du CDT soit rigoureusement pareil.

Par exemple, un des effets bonus de son outil, est qu'un CDT généré par samp2cdt qui semblerait correct, mais qui ne l'est pas ne pourra pas être réversé eu format CSW puis au format WAV.

J'ai fais le test avec un certain nombre de CDT présents sur cpc-p0wer et CPC-rulez, et c'est l'hécatombe.

Quand je vois le nombre de jeux speedlock dont les timings étaient mal calculés, laisse tomber
Impossible d'en faire quoi que ce soit, la réversion ne fonctionne pas, le WAV digital qui en découle ne fonctionne pas sur un vrai CPC.

ça rassure sur l'outil, ça montre que quand on lui injecte de la merde en entrée, il en sort la même merde en sortie.

quand un CDT est bon (malgré les timings farfelues et imprécis), la réversion fonctionne.

Mais bon, si comme tu l'as proposé quelqu'un fait le test côté PPI, je suis partant, au contraire

Mais compte tenu de ce que je sais déjà, il y a 1% de chance que ça aboutisse au résultat que certains pensent.

Je pars avec un gros avantage dans mon raisonnement, c'est que les vrais CPC jouent impeccablement bien les WAV numériques 100% perfect En émulation, on ne peut pas en dire autant.

@giants : vas-y fournir lui un dump

_________________
SPS Community Expert (SPS CE) / SPS France

Denis, tu devrais t’entraîner à la concision, tes posts sont tellement long qu'on finit par ne plus y répondre.

Si tes CDT et wav bruts contiennent la même chose, c'est très bien. Simplement, l'affirmer parce qu'ils marchent tous les deux sur un cpc est un peu rapide en besogne : Pour le prouver, il faudrait sampler la pin du PPI, et comparer le wav résultat au cdt (la conversion cdt-> wav est une opération sans ambiguïté, elle).



Sinon, dans ce post ci : viewtopic.php?f=2&t=5279&start=960#p49999

Tu as du te tromper : Il ya trois dumps qui sont des log plutôt que des csw/wav.