Je suis perplexe, comment obtiens-tu un CDT qui passe à partir d'un WAV original qui ne passe pas ?

le principe consiste à filtrer le WAV d'origine et obtenir un wav/csw filtré correct qui sera ensuite converti en CDT.

je ne sais pas si dlfrsilver conserver le wav/csw filtré, car c'est celui-ci que tu pourrais tester également si le CDT ne passe pas...

Seulement, pour moi, un WAV qui ne passe pas, cela veut dire qu'il ne passe sur un CPC.
S'il ne passe pas sur un CPC, inutile d'aller plus loin.

Après, en effet, tu peux toujours ajouter tout un tas de filtres pour le faire passer sur émulateurs, puis obtenir un WAV parfait qui va passer sur CPC, mais ce CDT ne provient plus d'un signal original.

Le nom du fichier "Bride Of Frankenstein (UK) (1987) [AS 54715] [Original] [TAPE].cdt" est trompeur et mensonger.

Fredouille, je dumpe des cassettes depuis 2004. J'ai affiné au fil des années mes connaissances et mes techniques, sans compter les échanges ici avec Lone ou Megachur, et ceux avec César, mon comparse de toujours.

Je vais te surprendre, mais il y a encore certaines particularités Fredouille que tu ne connais pas, et que je vais te donner ici pour combler le gap :

Il est absolument impossible pour nous particuliers ou encore groupe de préservation de garder le signal analogique tel quel et sa forme.

Pourquoi ? Tout simplement parce que la forme du signal est propre à la machine industrielle qui l'a tracé sur la bande. Ce n'est pas simulable. Donc, une fois réversé, le signal une fois remis en analogique a la même tête. Il s'agit d'un compromis qu'on est obligé de faire, d'un aspect qu'on ne peut pas garder.

Ensuite, Quand je dumpe une cassette, je charge en même temps le jeu sur mon 464 tout en l'enregistrant sur goldwave. J'ai mis en place et au point mon propre banc de dump.

Autre point, très difficile a reproduire en émulation, c'est la capacité que le CPC possède pour filtrer le signal qu'on lui envoie depuis la cassette. On a simplifié la chose en créant un petit logiciel, CSW0, qui permet de filtrer les cochonneries.

Mais d'un autre point de vue, comme je te l'avais expliqué quelques posts en arrière, quand tu dumpes une cassette CPC/ZX/C64 , etc.... tu prends les données, et tu prends aussi de la crasse/merde/poussière/saleté.

Que ces éléments soient présent dans le WAV de travail tiré de la cassette, c'est normal, puisque c'est notre point de départ en terme de préservation. Maintenant, c'est comme en archéologie, avec la préservation des amphores marines : elles ne sont jamais présentées dans leur gangue de crasse et de saleté. On les bichonne pour qu'elles aient le meilleur aspect possible, et on les protèges avec les moyens actuels pour les empêcher de s'abimer et surtout être présentables.

La préservation des disquettes et des cassettes, c'est exactement pareil.

Pour les disquettes, tu fais un dump flux de bonne qualité, avec sa crasse et ses bruits parasites, et ensuite tu en extrais les informations de A à Z, et tu les injectes dans un fichier CTraw (MFM), qu'ensuite je traite si c'est possible en IPF. L'IPF = données du dump en flux bas niveau extraite en haut niveau - la crasse/impureté/merde etc....

Pour les cassettes, même procédé :

Tu dumpes en WAV 44khz (actuellement, je monte en 64khz, la compression 7zip étant hyper bonne), tu filtres la merde/crasse/parasites qui sont dans le WAV en un fichier CSW qui contient les timings arrondis au plus près de ceux d'origine (exemple : un speedlock v4 en 2000 bauds, on a en arrondi 199x bauds).
et enfin on encode le contenu du CSW dans un CDT.

J'espère que tu comprendras qu'on ne peut pas avoir des données figées en digital pour les cassettes, puisqu'on part de l'analogique.

Sur un autre sujet, pour répondre à Mégachur, après avoir fait plusieurs tests, je me suis aperçu que l'encodage et réversion du système Bleepload v1 était foireux et buggé. Donc clairement même les CDTs qui passent sur CPCepower en bleepload v1 ne sont pas bon. Je vais les regénérer quand César m'aurait fait parvenir les nouveaux binaires.

Voici ce qui a été découvert :

"J'ai trouvé le bug — lors de la réécriture de l'exportation en CSW dans CSW2CDT j'ai inclu un filtre qui attrapait les bordures trop courtes pour qu'elles puissent tenir dans un sample. Devinez quoi : ça ne marchait pas correctement. Le nouveau code n'avait pas également les bons changements dans le playback des samples (précisément le bloc type utilisé dans les cassettes Bleepload1) et les pauses: les deux réunis ont mené à ce que les premières millisecondes de pause "magiques" soient bouffées."

Donc, encore des bugs qui mordent la poussière

_________________
SPS Community Expert (SPS CE) / SPS France

Apparemment, il y a préservation et préservation...

J'en connais qui veulent garder au plus près de l'original, avec l'original tant que c'est possible.
Ils gardent aujourd'hui une image en ctraw pour les disquettes et en wav pour les cassettes, car on voit bien que les outils évoluent car ils sont défaillants et seront meilleurs.

Avec les moyens de stockage actuels, je me dis qu'on peut quand même garder une meilleure empreinte de l'original qu'un CDT et même un CSW.

Perso, je ne fais pas de préservation. A chacun son hobby.
Cependant, mon objectif est de pouvoir restituer au mieux ce qui a été préservé.
Comme cela pose quelque fois des problèmes, il est tout naturel de devoir se poser des questions sur les méthodes de préservations utilisées.

L'archéologue a normalement une approche scientifique et critique de son travail, c'est bien dommage que cela se s'applique pas ici.

J'en fais partie. Je garde au plus près de l'original avec les contraintes que l'on a. On peut garder 98% des informations, donc 2% de "perte", ça va, c'est pas la mer à boire.

Le format CTraw est équivalent au format CSW pour les cassettes :

WAV => CSW => CDT
KFRAW => CTRAW => IPF

Je garde les dumps lourds disquette et les dumps lourds cassette dumpés.



Tu veux dire utiliser publiquement les fichiers WAV de travail ? trop gros trop lourd. Même problème avec le format SCP pour les disquettes. Fichiers trop gros, pas adaptés à la préservation/utilisation des fichiers de façon régulière. On a besoin d'avoir les données dans des fichiers compacts et propres.



Un peu quand même puisque ton émulateur supporte les fichiers de préservation



Moi pareil, simplement je sais qu'il y a des éléments qu'on ne peut pas garder, parce que ça supposerait de pouvoir reproduire le marquage (forme du signal analogique des cassettes), sauf que je sais que ça n'est pas possible.



Les méthodes de préservation sont abouties à ce jour ; Ce qui pose problème ce sont les bugs introduits en terme de programmation soit dans les outils de préservation, soit dans les émulateurs.



L'archéologue, tout comme l'archiviste que je suis, est uniquement limité par la technologie utilisée dans le cadre de la préservation/sauvegarde.

Je reprends l'exemple des amphores. Des méthodes de nettoyages ont été mises au point parce qu'il est bien évidemment hors de question par exemple de mettre celles-ci immergées dans un liquide opaque sous prétexte de les garder avec leur gangue. Non il y a un travail de nettoyage fait en amont par les archéos, afin de rendre présentable les amphores, les exposer au public, et les empêcher de se dégrader.

Ce que tu dis n'es pas correct en ce qui concerne le travail que j'effectue. C'est exactement le même principe et procédé : je ne fournis pas au public les dumps bruts non nettoyés et non travaillés. Pourquoi ? tout simplement parce que je dois m'assurer que les données sont bonnes. La préservation logicielle ne se fait pas en aveugle. Autrement n'importe qui prend un lecteur, sort son supercard pro, et hop vlà la pizza sortie du four ! Non, les données doivent être examinées, on doit s'assurer que les pistes sont ok, qu'on a pas de secteurs pourris, et j'en passe. D'ou le fait toujours par rapport à l'amphore, l'équivalent du nettoyage pour les softs, c'est que je suis obligé de nettoyer les disquettes CPC qu'on m'envoie sinon, no cigar, ce serait des dumps pourris 90% du temps, et pas présentables.

Mon rôle d'archiviste ne se limite pas à l'Amstrad CPC, je traite 7 autres plateformes.

Ce que nous préservons, ce sont les données telles qu'elles ont été écrites. C'est à dire le contenu des blocs, les timings à l'arrondi parce qu'il est impossible de faire autrement (le digital a des contraintes que n'a pas l'analogique), et les protections avec leurs particularités. C'est déjà beaucoup !

Par ailleurs, je vous l'annonce ici, j'ai été contacté par le responsable de la préservation de la BNF, pour aider un chercheur universitaire, qui avait besoin d'aide pour préserver et restaurer les premières poésies numériques crée sur Amstrad CPC d'un grand auteur Franco-Hongrois primé du goncourt, du nom de Tibor Papp.

Ses disquettes de travail Amstrad CPC m'ont été confiées car je suis reconnu internationalement pour la préservation, et ses techniques, que j'ai développé et suis le seul à maitriser à 100%.

J'ai donc oeuvré, et préservé ses 25 disquettes, et sauvé pour l'éternité son oeuvre entière, avec celle qui était pensée perdue, du nom "les riches heures de l'ordinateur".

Le chercheur de l'université de Lille qui me les a confié était ravi, et m'a offert 80 euros pour mon travail.
Mon nom sera diffusé dans tout les musées d'Europe à titre de remerciements et je serais invité quand ses oeuvres seront diffusées sur Paris.

C'était juste une parenthèse pour remettre les choses dans leur contexte.

_________________
SPS Community Expert (SPS CE) / SPS France

Amen

Bien, après bugfix de CSW0 et CSW2CDT, j'ai généré 2 nouveaux CDTs qui cette fois sont corrects d'un point de vue format.





Voici à présent le tableau concernant les résultats de fonctionnement :

Caprice Forever :
-------------------

WAV = OK ; CSW = OK ; CDT = NOK ; CSW réversé = OK ; WAV réversé = OK

CPCEpower :
---------------

WAV = OK ; CSW = OK ; CDT = NOK ; CSW réversé = OK ; WAV réversé = OK

CPCEC :
---------

WAV = OK ; CSW = OK ; CDT = OK ; CSW réversé = OK ; WAV réversé = OK

Sugarbox :
------------

WAV = OK ; CSW = OK ; CDT = NOK (lockup) ; CSW réversé = OK ; WAV réversé = OK

Bien à présent, après examen sur Caprice Forever, il apparait ceci comme étant la cause de l'erreur de lecture de bloc :

"Même problème entre Helichopper et Rasputin, le chargement a pris fin dans BIT0, mais Caprice a lu BIT1 parce qu'il a fusionné le dernier sample du bloc (un court) avec le début de la pause, rendant ainsi le sample plus long, ce qui est incorrect.".

Tu regardes ta gestion CDT fredouille (idem Megachur) ?

_________________
SPS Community Expert (SPS CE) / SPS France

1 contre 3

L’exception qui confirme la règle

Je trouve normal que cpcec fonctionne de la même façon que l’ecodeur puisque programme par la même personne

Sauf que tu te trompes. Je viens de faire une série de test, et en fait le WAV réversé ne fonctionne pas sur un vrai CPC !

Ce qui veut dire que chaque émulateur est en réalité aux fraises, et pas simplement CPCEC ! Ils chargent le fichier alors qu'un vrai 464 fait des erreurs aléatoires au chargement dessus, donc retour au tableau noir !

Je sais que le système Bleepload v1 est hyper intolérant, ok, mais je prends à titre d'exemple que quand un format est clairement compris, l'encodage et la réversion fonctionnent sur un vrai CPC.

Par exemple, les formats ultra complexes gremlin 2 et 3 s'encodent et se réversent parfaitement. Idem pour les speedlock, hexagon, alkatraz, ricochet, etc (je vais pas tous les nommer).

Pour moi c'est clair, Bleepload v1 et keytone, ces protections ne sont pas correctement comprises, il manque quelque chose, dont les émulateurs ne se soucient pas, mais qu'un vrai CPC prend en compte.

Moi ça me va pas du tout, donc je vais reprendre avec César. Je laisse Lone, Fredouille et Megachur tirer leur conclusions.

_________________
SPS Community Expert (SPS CE) / SPS France

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 !!!


d'ailleurs, je vois qu'il y a un bug ouvert depuis 2017 sur la lecture des bleepload :

on est encore loin de la nouvelle précision de CPCEC ou des nos émulateurs...

Là, je trouve cela un peu facile.
Je ne vois comment on peut avancer avec des CDTs qui sont reconstruis tous les jours...

Comme l'outil de base est mis en cause, le seul moyen d'avancer serait d'avoir accès aux wavs originaux.

megachur m'a coupe l'herbe sous les pieds ...

le TZXDuino n'a surement pas la même "interprétation" du cdt donc normal que l'on obtienne encore un résultat diffèrent

par contre, comme tu peux tester les wavs, est ce que le wav original passe ?

d'ailleurs pourrais tu nous partager ceux ci (bride of Frankenstein et les autres dont tu fais les test sur ce problème) stp ?

merci d'avance

Finalement, on vient de faire le tour, cela me donne encore plus l'impression que CSW2CDT ne fait des CDT que pour CPCEC...

ce n'est pas un arrondi bizarre de faire +0.5 c'est ce qu'on appelle une conversion CORRECTE qui tient compte des effets secondaires de l'encodage des nombres flottants

si tu fais pas ça et que tu bosses dans le financier tu vas rapidement te faire taper sur les doigts

le souci des flottants c'est que t'arrives toujours à un moment ou un autre à des valeurs genre *.999999999999 et tu vas perdre une unité lors de la conversion vers INT