CPC Rulez :: Consulter le sujet

Merci pour ses infos.

Je me demandais plutôt quel type de filtre, au sens "traitement du signal", mais cela dit, c'est bien complet.

J'ai testé la conversion "CDT" de trivia.
Ca marche évidemment du feu de dieu... Mais j'ai triché, j'ai utilisé un unique bloc 0x18....
En version non compressé, ça prend tout de même 18 mo...

Question : Malgré tout, on semble beaucoup s'embêter à vouloir générer du cdt.

Ma question : Mais pourquoi ?

Imaginons que tous les ému lisent le csw2.0 + zrle... Pourquoi ne pas juste utiliser ce format ?
Les travaux pénible de dumps seraient finis... Enregistrement, CSW.exe et la messe est dite...

Concernant le bloc 0x18 : C'est un bloc définit dans la version 1.20 du format TZX.

Ce format n'a pas pour but d'être spécifique spectrum, ce bloc n'est donc pas un bloc spectrum...
La preuve, le jeu marche très bien en l'utilisant sur cpc.

A mon humble avis, le format CSW est complémentaire mais indispensable au format CDT.

Je m'explique :

Si on parle de taille, la plupart du temps, la v2+zrle donne un fichier du même ordre de grandeur. La plupart du temps, on ne dépasse pas un facteur 2 par rapport à un cdt, ce qui ne justifie pas l'argument de la taille (mais justifie l'existence du 2 et de la compression)

Si on parle de préservation, le csw est bien plus proche du format original (wav), qu'un cdt, sans discussion possible.

C'est, je pense, l'équivalent du format ct-raw, sans le côté "format verrouillé" de celui-ci.

Si on parle de protection, le CSW correctement "nettoyé", comme tu dis, marcheras toujours.

Quelque soit la protection.

On est ici à un niveau d'abstraction différent (même raisonnement que sur un CT-RAW. Un ct-raw correct va toujours marcher (à l’exception de cas limite du format, comme la taille à l'octet par exemple, et non au bit - voir la série des "réussirs")).

Si on parle de récupération sur k7 pour un vrai cpc... La conversion csw -> wav est immédiate et simple.

Son immense avantage, en outre, c'est de produire des dumps fonctionnels immédiatement.

Pour ce qui est de les tester... On les teste de la même manière qu'un CDT, je crois, en les lançant et en y jouant.

Bref, il ne semble rester au pauvre cdt que son aspect décodage facile (ce qui permet des outils aisés à coder pour consulter un fichier). Je ne vois guère que ça... Pour un site web, c'est super pour offrir des outils "on line", mais pour les autres, c'est maigre.

Après, je comprends qu'on aime faire des cdt à la main... Mais très peu pour moi, j'ai déjà des projets qui me prennent bien plus de temps que je n'en ai de disponible...

Je suis programmeur, donc ma grande qualité, c'est mon grand défaut, c'est d'être suffisamment fainéant pour vouloir tout automatiser et me tourner les pouces

Désolé, je poste pas souvent, mais là je me sens obligé.

Je suis totalement d'accord avec Lone.
Le format CDT est à la K7 ce que le DSK est à la D7 : une plaie.

Le format de stockage des données ne doit en aucune manière les interprêter. D'une part ça le complexifie énormément, et d'autre pas ça prend le risque de ne pas être exhaustif dans la gestion du contenu (il suffit de voir les patchs et variantes des CDT/DSK pour s'en convaincre).

Ces formats sont donc simplement de mauvais formats. Il faut y privilégier des formats génériques qui ne contiennent que des données purement physiques. Ce sont ensuite aux outils et émulateurs de faire le sale boulot d'en interprêter le contenu.

En cela, le CSW est à mon avis à privilégier au CDT. Voilà, je retourne dans ma caverne. :wink:

Le format CDT de base n'interprète pas les données. C'est un format qui est même mieux que le format DSK si on compare à égalité.

Il n'y a rien de complexe dans le CDT. Tout est simplifié !

Deuxio, il n'y a pas de patchs sur les CDTs contrairement aux fichiers DSK. Le format CDT n'a pratiquement pas bougé, et ne requiert pas de patch pour passer les jeux. Pour les formats non supportés, on utilise un bytelogger, qui logge exactement les blocs tels qu'ils sont sur la cassette originale.

C'est aux auteurs d'émulateurs de programmer comme il faut le fonctionnement des composants du CPC, et ensuite on verra s'il y a lieu de faire des modifs dans les formats de stockage.

Comparativement, si j'ai une roue voilée sur ma caisse, j'en rachète pas une, je remplace la roue ! :mdr:

Depuis que j'ai accès à l'outil de création d'IPF, on voit clairement que j'avais raison. les jeux en IPF ou en DSK ne peuvent pas fonctionner si le FDC n'est pas parfaitement émulé.

Si le FDC déconne en émulation, ça n'ira pas, et la grande tentation de certaines personnes est de faire plier les formats pour que ça tourne en ému. C'est illogique et c'est pas de cette façon là que ça doit se faire.

Quoi qu'il en soit, le format DSK est pas mal pour ce qu'il est. C'est pas le plus idéal, ça vaut pas les IPFs, mais ça se débrouille plutôt bien. Le format CDT est totalement modulaire, et fait à la base pour supporter tout les systèmes de protection. Le problème vient de l'outil de génération de CDT qui ne reconnait pas certains d'entre eux.

Surement pas, c'est un format intermédiaire, et non on ne va pas faire la même merde que chez les Commodoriens avec leur système TAP à deux balles qui rend le dumping chiant comme la mort, les utilisateurs lambdas ne pourront plus dumper leurs jeux eux-mêmes !

Je connais les deux systèmes, et celui qu'on a sur CPC est de loin le meilleur. Couplé à Tapir, on regénère des masters de cassettes depuis les fichiers CDTs en WAV, qui fonctionnent à 100 % et qui visuellement ressemblent très exactement au dumps en WAV originaux.

Juste mes 2 cts

Pas toujours, certains jeux nécessitent de passer à la moulinette, en brut ça ne passe pas.

je trouve franchement marrant les affirmations de denis face a des gars comme thomas et offset :mdr:

breiztiger a écrit :

je trouve franchement marrant les affirmations de denis face a des gars comme thomas et offset :mdr:

DLFRSILVER est le plus gros DUMPeur de cassettes et disquettes sur CPC, il sais de quoi il parles lui aussi. Le format .CDT support 26 type de blocks de données différent, et inclut les block dit "Pure tone", c''est un peu ce que vous décrivez avec le CSW , alors pourquoi réinventé la roue?

@lone :

Lone a écrit :

Hermol, c'est le cdt qui réinvente la roue...
En outre, personne ne met en doute la compétence de Denis concernant la génération de wav propre, bien au contraire !

Ah bah on dirait pas ! Et de toute façon, ce n'est pas le sujet.

Tu ne comprends pas qu'on ne peut rien faire avec un fichier CSW. On ne peut pas le nettoyer, on ne peut pas aller dedans, on ne peut pas voir les blocs ni leur structure.

Citer :

Le csw a un type simple.
Le CDT en a 26 (dont un qui permet d'inclure.... Des données csw ).

Bon, je ne vais pas tout reprendre, mais que ça soit clair : je ne remets pas en cause ton dévouement et ton apport à la communauté. Je ne remets pas en cause non plus l'immense travail que tu as fait.

Je me permets juste, humblement, de poser la question suivante : si le support du cdt est indispensable pour les évidentes raisons historiques que tu as mentionné, ne peut on y ajouter aussi le csw, bien plus simple, efficace, etc..., quand l'occasion est là, a partir d'aujourd'hui ?

Je peux me tromper, mais je pense que tous les auteurs d'emulateurs préfère gérer un csw qu'un cdt ( vu que c'est le format en entrée du ppi).

@Toto : Ce n'est pas parce que les choses ont été défrichées avec des formats bricolés tant bien que mal, mais de façon louable, cette dernière décénie, qu'il faut se résigner à les considérer comme faisant parti du patrimoine CPC... Ce serait marcher sur la tête.

La préservation concerne les originaux et non les formats qui ont permis d'en arriver ou nous en sommes aujourd'hui grace à l'aide de tout un chacun.

En aucun cas il est question de réinventer la roue, mais de trouver des solutions aux problèmes qui se présentent.

Les formats peuvent cohabiter que je sache (sans parler des dumps en IPF) ... Tant qu'on regarde de l'avant, les solutions s'imposeront d'elles mêmes.

Auteur :	Lone [ 03 Nov 2014, 13:59 ]
Sujet du message :	Re: Dumps originaux
Merci pour ses infos. Je me demandais plutôt quel type de filtre, au sens "traitement du signal", mais cela dit, c'est bien complet. J'ai testé la conversion "CDT" de trivia. Ca marche évidemment du feu de dieu... Mais j'ai triché, j'ai utilisé un unique bloc 0x18.... En version non compressé, ça prend tout de même 18 mo... Question : Malgré tout, on semble beaucoup s'embêter à vouloir générer du cdt. Ma question : Mais pourquoi ? Imaginons que tous les ému lisent le csw2.0 + zrle... Pourquoi ne pas juste utiliser ce format ? Les travaux pénible de dumps seraient finis... Enregistrement, CSW.exe et la messe est dite...

Auteur :	dlfrsilver [ 03 Nov 2014, 17:32 ]
Sujet du message :	Re: Dumps originaux
Lone a écrit : Merci pour ses infos. Je me demandais plutôt quel type de filtre, au sens "traitement du signal", mais cela dit, c'est bien complet. J'ai testé la conversion "CDT" de trivia. Ca marche évidemment du feu de dieu... Mais j'ai triché, j'ai utilisé un unique bloc 0x18.... En version non compressé, ça prend tout de même 18 mo... Justement le but c'était de ne pas tricher (le CPC n'utilise pas de bloc ID 18, c'est un bloc TZX spectrum). Le jeu utilise une protection anti-copie. En utilisant un bloc d'enregistrement CSW, non seulement tu passes à côté, mais en plus ça génère un fichier énorme pour rien...... Saches-le, ce jeu est entièrement en blocs standards. Ma version fait 51ko pour le premier CDT. Citer : Question : Malgré tout, on semble beaucoup s'embêter à vouloir générer du cdt. Ma question : Mais pourquoi ? Réponse extremement simple : déjà, le format CDT est ultra compact et très bien conçu. Quand je vois les mecs de la communauté C64 s'emmerder avec leurs fichier TAP qui ne sont qu'en fait des fichiers CSW, c'est techniquement du grand n'importe quoi. Et le pire, c'est qu'ils accèdent aux fichiers au travers de ces énormes fichiers de plusieurs méga-octets, alors que s'ils avaient un équivalent en CDT, les fichiers seraient tellement plus facile à gérer. On a aujourd'hui des mégas et des mégas de stockage, mais pour autant, c'est un gachis absolu de consacrer 8mo pour une seule face d'un seul jeu quand on peut avoir un fichier qui pèse seulement 190ko. Et je dis ça sachant que je dumpe aussi sur C64, et chez eux c'est pire côté outils encore que côté CPC (des vieux outils pas mis à jours pour la majeure partie d'entre eux, sauf samdisk, tout les autres, rien n'a évolué, on est toujours à utiliser des byteloggers parce qu'on a apparemment aucun programmeur foutu de coder et programmer les systèmes d'encodage dans samp2cdt, ou alors je sais pas, ils ont pas envie les mecs. Sur ST ou Amiga, y a des mecs qui se donnent la peine de coder et de faire bouger les choses, mais pas sur CPC. Je sais pas, je pige pas ) Pour revenir au C64, leur outils pour nettoyer sont pourris, pour une raison totalement stupide : Sur cette machine ils sont partis du principe qu'un bon dump ne se fait qu'au travers d'une interface hardware qui filtre le signal et qui mache le boulot. Résultat, les outils ont une aptitude à nettoyer les fichiers extremement faible. Je te donne un exemple : tu prends le jeu X-out sur amstrad CPC cassette. Il utilise la protection Alkatraz avec le compteur. Si tu utilises un magnétophone nettoyé régulièrement, avec une tête de lecture propre, les niveaux sonores qui vont bien, tu peux générer un fichier WAV du jeu fonctionnel, de base. Tu prends le même jeu sur C64, en utilisant la même méthode, un bon magnétophone, avec les bons réglages de bases, et bien ça ne marchera jamais ! Car les outils que tu utiliseras après seront incapables de nettoyer le signal correctement, y aura toujours de la crasse dessus, et pour couronner ce merdier, les systèmes de protection du C64 sont une plaisanterie comparés à ceux utilisés sur amstrad CPC, bien plus simples. Le format CDT est excellent, le hic c'est les outils qui ne sont pas à la hauteur (buggés, ou bien pas finis). Citer : Imaginons que tous les ému lisent le csw2.0 + zrle... Pourquoi ne pas juste utiliser ce format ? Les travaux pénible de dumps seraient finis... Enregistrement, CSW.exe et la messe est dite... Il est impossible en l'état de vérifier si un dump est bon avec un fichier CSW. La compression ZRLE c'est rien de plus qu'un CSW v1.1 avec une compression ZIP (Deflate) en fait. César le dit lui-même : il ne sait pas pourquoi ils ont crée le format CSW2, ça a tué la simplicité et l'utilité du format original. Et les travaux pénibles de dumps ne seraient pas finis non, car on se retrouverait avec du déchet en pagaille (plus qu'on en a aujourd'hui), car les gens se diraient, "hop j'ai généré mon fichier CSW, c'est bon". Regarde simplement le nombre de dumps que j'ai réalisé avec samp2cdt, ou encore samdisk (voir CPDread au tout début), y avait un bon nombre de dumps qui ont du être refait, car dans la majorité des cas les outils soit n'imageaient pas correctement les originaux, soit les systèmes de protection n'étaient pas supportés. La préservation en tant que telle nécessite un apport à la fois technique (intervention manuelle), parce que les outils ne permettront jamais totalement l'automatisation du processus de générer d'images valides. Le format CDT n'a jamais été conçu à la base pour la génération automatisée de fichiers cassette, mais nécessitait une intervention humaine. C'est comme les IPFs, il n'y a pas de génération automatique, il faut mettre la main à la pâte pour les générer. Bon donc pour trivia, le jeu est entièrement en bloc standard, la protection est juste intéressante à découvrir Tu essayes ?

Auteur :	Lone [ 03 Nov 2014, 18:24 ]
Sujet du message :	Re: Dumps originaux
Concernant le bloc 0x18 : C'est un bloc définit dans la version 1.20 du format TZX. Ce format n'a pas pour but d'être spécifique spectrum, ce bloc n'est donc pas un bloc spectrum... La preuve, le jeu marche très bien en l'utilisant sur cpc. A mon humble avis, le format CSW est complémentaire mais indispensable au format CDT. Je m'explique : Si on parle de taille, la plupart du temps, la v2+zrle donne un fichier du même ordre de grandeur. La plupart du temps, on ne dépasse pas un facteur 2 par rapport à un cdt, ce qui ne justifie pas l'argument de la taille (mais justifie l'existence du 2 et de la compression) Si on parle de préservation, le csw est bien plus proche du format original (wav), qu'un cdt, sans discussion possible. C'est, je pense, l'équivalent du format ct-raw, sans le côté "format verrouillé" de celui-ci. Si on parle de protection, le CSW correctement "nettoyé", comme tu dis, marcheras toujours. Quelque soit la protection. On est ici à un niveau d'abstraction différent (même raisonnement que sur un CT-RAW. Un ct-raw correct va toujours marcher (à l’exception de cas limite du format, comme la taille à l'octet par exemple, et non au bit - voir la série des "réussirs")) Si on parle de récupération sur k7 pour un vrai cpc... La conversion csw -> wav est immédiate et simple. Son immense avantage, en outre, c'est de produire des dumps fonctionnels immédiatement. Pour ce qui est de les tester... On les teste de la même manière qu'un CDT, je crois, en les lançant et en y jouant. Bref, il ne semble rester au pauvre cdt que son aspect décodage facile (ce qui permet des outils aisés à coder pour consulter un fichier). Je ne vois guère que ça... Pour un site web, c'est super pour offrir des outils "on line", mais pour les autres, c'est maigre. Après, je comprends qu'on aime faire des cdt à la main... Mais très peu pour moi, j'ai déjà des projets qui me prennent bien plus de temps que je n'en ai de disponible... Je suis programmeur, donc ma grande qualité, c'est mon grand défaut, c'est d'être suffisamment fainéant pour vouloir tout automatiser et me tourner les pouces

Auteur :	dlfrsilver [ 03 Nov 2014, 19:08 ]
Sujet du message :	Re: Dumps originaux
Lone a écrit : Concernant le bloc 0x18 : C'est un bloc définit dans la version 1.20 du format TZX. Ce format n'a pas pour but d'être spécifique spectrum, ce bloc n'est donc pas un bloc spectrum... La preuve, le jeu marche très bien en l'utilisant sur cpc. A mon humble avis, le format CSW est complémentaire mais indispensable au format CDT. Je me sers du format CSW v1.1 pour générer des fichiers CDT. C'est un format temporaire et intermédiaire, et depuis que j'ai dépoussiéré l'usage des outils pour créer des CDTs (oui en 2004, je ne connaissais personne à même de créer des cdts depuis un bon nombre de protection. Exemple : Le système zydroload. J'ai découvert que seul taper savait décoder ce type de blocs, et y a aussi les jeux speedlockés, aucun site, aucune personne n'avait décrit ni expliqué comment passer un WAV en CDT suivant sa protection. C'est pour ça que j'avais commencé à décrire la chose dans le document présent sur le site annexe de cpc-p0wer, CPC-archives). Citer : Je m'explique : Si on parle de taille, la plupart du temps, la v2+zrle donne un fichier du même ordre de grandeur. La plupart du temps, on ne dépasse pas un facteur 2 par rapport à un cdt, ce qui ne justifie pas l'argument de la taille (mais justifie l'existence du 2 et de la compression) Je crée un fichier CSW v1.1, et je le zippe. Tadaaa, j'obtiens un fichier CSW v2.0 Citer : Si on parle de préservation, le csw est bien plus proche du format original (wav), qu'un cdt, sans discussion possible. Je suis d'accord. Mais je préfèrerais toujours un fichier WAV à un fichier CSW (qui est un fichier compressé quoiqu'il en soit), et un fichier CDT à un fichier CSW. Citer : C'est, je pense, l'équivalent du format ct-raw, sans le côté "format verrouillé" de celui-ci. D'accord. Mais le CT-Raw n'est aussi pour moi qu'un format compact intermédiaire. Je lui préfère l'IPF ou encore les KF-RAW. Citer : Si on parle de protection, le CSW correctement "nettoyé", comme tu dis, marcheras toujours. Sauf qu'on ne voit pas son contenu, et encore moins la tronche des blocs qui composent l'enregistrement. J'aime avoir un visuel sur ce que dumpe, et le CSW n'offre pas cette possibilité. Un fichier WAV me donne un visuel sur sa qualité, pareil pour un fichier CDT. Je vois les blocs, les infos pilot tone, sync, et bit 0 et 1, la taille des pauses (important ça), dans certains cas le checksum des blocs, et leur taille. Citer : Quelque soit la protection. Je suis d'accord, puisque c'est ni plus ni moins qu'un fichier WAV compressé en grosso-modo (CSW : compressed Square Waves). Citer : On est ici à un niveau d'abstraction différent (même raisonnement que sur un CT-RAW. Un ct-raw correct va toujours marcher (à l’exception de cas limite du format, comme la taille à l'octet par exemple, et non au bit - voir la série des "réussirs")). Pas toujours, certains jeux nécessitent de passer à la moulinette, en brut ça ne passe pas. Citer : Si on parle de récupération sur k7 pour un vrai cpc... La conversion csw -> wav est immédiate et simple. Le format CSW permet la transportabilité du dump, et à partir de lui on peut générer un fichier VOC (ex: CSW1 qui lorsque je filtre génère un fichier CSW v2.0, et que je convertis en fichier VOC. Samp2cdt ne gère pas les fichier en CSW v2.0 de toute façon, puisqu'on a les fichiers en CSW v1.1 qui passent très bien). La finalité de tout les outils c'est le format CDT de toute manière. Citer : Son immense avantage, en outre, c'est de produire des dumps fonctionnels immédiatement. Ce n'est pas faux, c'est juste incorrect de dire ça. J'ai produit depuis que je dumpe (soit en gros 10 bonnes années), une quantité infernale de fichier CSW. Et non, un bon nombre d'entre eux ne sont pas immédiatement fonctionnels. Un nettoyage, un filtrage sont souvent nécessaires. Pourquoi ? Tout simplement parce que les gens qui dumpent les cassettes utilisent soit du matériel ancien (vieux lecteur, etc...), soit parce qu'ils n'ont pas les bons réglages (immuables) qui permettent d'avoir un niveau sonore adéquat pour obtenir les dumps les plus propres possibles. Les dumps ainsi générés sont sales ou encrassés, ou encore ont un tel niveau de parasite que les CSW générés ne sont pas à 100% fonctionnels, ou au pire contiennent des erreurs. Citer : Pour ce qui est de les tester... On les teste de la même manière qu'un CDT, je crois, en les lançant et en y jouant. La encore, la grande différence est que le format CDT me permet de découper par portion chargée, exemple : les versions splittées que j'ai mis au point pour justement gagner du temps, et ne charger que les données requises. Les cdts en un seul morceau c'est bien sur émulateur ou pour remasteriser une cassette, mais on est plus de 20 ans après, et les chargements linéaires des cassettes, bof quoi. Le temps c'est des sous-sous On ne peut pas faire reprendre non plus un bloc en cas d'erreur de chargement, le fichier CSW doit être lu comme une cassette, si on coupe son chargement, faut tout reprendre depuis le début. Citer : Bref, il ne semble rester au pauvre cdt que son aspect décodage facile (ce qui permet des outils aisés à coder pour consulter un fichier). Je ne vois guère que ça... Pour un site web, c'est super pour offrir des outils "on line", mais pour les autres, c'est maigre. Le format CDT est une gloire qui nous vient du monde spectrum, les mecs qui l'ont mis au point étaient vraiment des cadors en ingénierie, on peut leur dire merci Citer : Après, je comprends qu'on aime faire des cdt à la main... Mais très peu pour moi, j'ai déjà des projets qui me prennent bien plus de temps que je n'en ai de disponible... Je suis d'accord. Il y aurait une possibilité : coder un outil qui sache décoder et lire un fichier WAV, qui puisse trouver de fait les infos (pilot tone, sync, bit 0 et 1) tout seul, qui sache insérer les temps de pause rigoureusement identiques à celle du dump. Rien que ça, ça ferait gagner du temps. Juste pour info, l'outil appelé TAPIR permet de réparer des CDTs/TZXs, mais aussi de convertir à la perfection les CDTs en fichier WAV, qui ressemblent traits pour traits au wav original. Est-ce que tu l'as déjà essayé ? Citer : Je suis programmeur, donc ma grande qualité, c'est mon grand défaut, c'est d'être suffisamment fainéant pour vouloir tout automatiser et me tourner les pouces Tu sais comme moi que programmeur ou pas, la solution de facilité est toujours la plus mauvaise, car c'est toujours un raccourci. La meilleure solution demande toujours de l'investissement, quelque soit le domaine dans lequel on est

Auteur :	OffseT [ 03 Nov 2014, 23:13 ]
Sujet du message :	Re: Dumps originaux
Désolé, je poste pas souvent, mais là je me sens obligé. Je suis totalement d'accord avec Lone. Le format CDT est à la K7 ce que le DSK est à la D7 : une plaie. Le format de stockage des données ne doit en aucune manière les interprêter. D'une part ça le complexifie énormément, et d'autre pas ça prend le risque de ne pas être exhaustif dans la gestion du contenu (il suffit de voir les patchs et variantes des CDT/DSK pour s'en convaincre). Ces formats sont donc simplement de mauvais formats. Il faut y privilégier des formats génériques qui ne contiennent que des données purement physiques. Ce sont ensuite aux outils et émulateurs de faire le sale boulot d'en interprêter le contenu. En cela, le CSW est à mon avis à privilégier au CDT. Voilà, je retourne dans ma caverne.

CPC Rulez https://cpcrulez.fr/forum/

Dumps originaux https://cpcrulez.fr/forum/viewtopic.php?f=8&t=135	Page 47 sur 54

Auteur :	dlfrsilver [ 04 Nov 2014, 00:29 ]
Sujet du message :	Re: Dumps originaux
OffseT a écrit : Désolé, je poste pas souvent, mais là je me sens obligé. Je suis totalement d'accord avec Lone. Le format CDT est à la K7 ce que le DSK est à la D7 : une plaie. Le format de stockage des données ne doit en aucune manière les interprêter. D'une part ça le complexifie énormément, et d'autre pas ça prend le risque de ne pas être exhaustif dans la gestion du contenu (il suffit de voir les patchs et variantes des CDT/DSK pour s'en convaincre). Le format CDT de base n'interprète pas les données. C'est un format qui est même mieux que le format DSK si on compare à égalité. Il n'y a rien de complexe dans le CDT. Tout est simplifié ! Et bizarrement, j'ai retrouvé dans mes archives ce soir les CDTs d'un mec qui s'est cru malin de créer des CDTs contenant des bloc d'enregistrement direct, ça donne des CDTs de 4 méga ou plus, dont le contenu est invisualisable, impossible à nettoyer ! La belle affaire ! Deuxio, il n'y a pas de patchs sur les CDTs contrairement aux fichiers DSK. Le format CDT n'a pratiquement pas bougé, et ne requiert pas de patch pour passer les jeux. Pour les formats non supportés, on utilise un bytelogger, qui logge exactement les blocs tels qu'ils sont sur la cassette originale. Donc ton histoire d'interprétation, c'est de la couille en barre ! Citer : Ces formats sont donc simplement de mauvais formats. Il faut y privilégier des formats génériques qui ne contiennent que des données purement physiques. Ce sont ensuite aux outils et émulateurs de faire le sale boulot d'en interprêter le contenu. J'étais déjà pas d'accord avec toi concernant l'émulation FDC, et je le suis toujours pas concernant les formats. C'est aux auteurs d'émulateurs de programmer comme il faut le fonctionnement des composants du CPC, et ensuite on verra s'il y a lieu de faire des modifs dans les formats de stockage. Comparativement, si j'ai une roue voilée sur ma caisse, j'en rachète pas une, je remplace la roue ! Depuis que j'ai accès à l'outil de création d'IPF, on voit clairement que j'avais raison. les jeux en IPF ou en DSK ne peuvent pas fonctionner si le FDC n'est pas parfaitement émulé. Si le FDC déconne en émulation, ça n'ira pas, et la grande tentation de certaines personnes est de faire plier les formats pour que ça tourne en ému. C'est illogique et c'est pas de cette façon là que ça doit se faire. Quoi qu'il en soit, le format DSK est pas mal pour ce qu'il est. C'est pas le plus idéal, ça vaut pas les IPFs, mais ça se débrouille plutôt bien. Le format CDT est totalement modulaire, et fait à la base pour supporter tout les systèmes de protection. Le problème vient de l'outil de génération de CDT qui ne reconnait pas certains d'entre eux. Citer : En cela, le CSW est à mon avis à privilégier au CDT. Voilà, je retourne dans ma caverne. Surement pas, c'est un format intermédiaire, et non on ne va pas faire la même merde que chez les Commodoriens avec leur système TAP à deux balles qui rend le dumping chiant comme la mort, les utilisateurs lambdas ne pourront plus dumper leurs jeux eux-mêmes ! Je connais les deux systèmes, et celui qu'on a sur CPC est de loin le meilleur. Couplé à Tapir, on regénère des masters de cassettes depuis les fichiers CDTs en WAV, qui fonctionnent à 100 % et qui visuellement ressemblent très exactement au dumps en WAV originaux. Juste mes 2 cts

Auteur :	breiztiger [ 04 Nov 2014, 08:03 ]
Sujet du message :	Re: Dumps originaux
je trouve franchement marrant les affirmations de denis face a des gars comme thomas et offset tout le monde sait qu'ils n'y connaissent rien

Auteur :	Hicks [ 04 Nov 2014, 10:33 ]
Sujet du message :	Re: Dumps originaux
Saviez-vous que dans les meetings on surnommait Offset "la tanche du FDC" ??

Auteur :	Lone [ 04 Nov 2014, 12:10 ]
Sujet du message :	Re: Dumps originaux
dlfrsilver a écrit : Le format CDT de base n'interprète pas les données. C'est un format qui est même mieux que le format DSK si on compare à égalité. Il n'y a rien de complexe dans le CDT. Tout est simplifié ! Je ne vois pas ce qui est simplifié entre le CSW (qui contient un unique type de données, une durée de transition ) et le CDT (qui contient au bas mot une 20aine de bloc - donc de type de données différents) dlfrsilver a écrit : Deuxio, il n'y a pas de patchs sur les CDTs contrairement aux fichiers DSK. Le format CDT n'a pratiquement pas bougé, et ne requiert pas de patch pour passer les jeux. Pour les formats non supportés, on utilise un bytelogger, qui logge exactement les blocs tels qu'ils sont sur la cassette originale. On est à la version 1.20, donc il y a eu quelques révisions. D'ailleurs, tout est dit lorsque tu dis "format non supportés". C'est un concept qui n'existe pas en CSW, (pour un enregistrement de qualité, ce qui est totalement indépendant du format des données) dlfrsilver a écrit : C'est aux auteurs d'émulateurs de programmer comme il faut le fonctionnement des composants du CPC, et ensuite on verra s'il y a lieu de faire des modifs dans les formats de stockage. Comparativement, si j'ai une roue voilée sur ma caisse, j'en rachète pas une, je remplace la roue ! Excellente remarque. Le format de stockage n'a rien a voir avec l'émulation. Plus il est loin du format "réel", plus on doit faire des algo d'adaptation. J'ai mis au point le FDC. Ensuite, j'ai passé 900 lignes à mettre au point des algo pour faire correspondre le format dsk à un format proche de la réalité (j'ai considéré un flux de bit MFM). Les mêmes fonctions en HFE ? 120 lignes, essentiellement pour lire le fichier. L'émulation fonctionne dans 100% des cas sur scp ( hors problème de qualité de l'enregistrement, je te vois venir avec tes arguments spécieux !), ou csw (idem, pour une qualité optimale). Tu as raisons. Les roues "dsk" et "cdt" sont voilées, changeons les plutôt que de tenter de les réparer avec des tas de petit coups de marteaux pour les faire rentrer dans un modèle proche de la réalité. dlfrsilver a écrit : Depuis que j'ai accès à l'outil de création d'IPF, on voit clairement que j'avais raison. les jeux en IPF ou en DSK ne peuvent pas fonctionner si le FDC n'est pas parfaitement émulé. Si le FDC déconne en émulation, ça n'ira pas, et la grande tentation de certaines personnes est de faire plier les formats pour que ça tourne en ému. C'est illogique et c'est pas de cette façon là que ça doit se faire. Quoi qu'il en soit, le format DSK est pas mal pour ce qu'il est. C'est pas le plus idéal, ça vaut pas les IPFs, mais ça se débrouille plutôt bien. Le format CDT est totalement modulaire, et fait à la base pour supporter tout les systèmes de protection. Le problème vient de l'outil de génération de CDT qui ne reconnait pas certains d'entre eux. Passons nous donc d'outils de génération, pour ne plus avoir de problèmes... Je passe sur l'IPF, c'est un format fermé. Si les données qu'il fournit sont intéressantes (flux de bit mfm), le contenu ne peut donner lieu à débat, vu qu'on ne sait pas ce qu'il contient. Ah si, tu nous parles régulièrement de "protections non supportées".... Ce qu'on n'a pas avec ct-raw ou scp. dlfrsilver a écrit : Surement pas, c'est un format intermédiaire, et non on ne va pas faire la même merde que chez les Commodoriens avec leur système TAP à deux balles qui rend le dumping chiant comme la mort, les utilisateurs lambdas ne pourront plus dumper leurs jeux eux-mêmes ! Je connais les deux systèmes, et celui qu'on a sur CPC est de loin le meilleur. Couplé à Tapir, on regénère des masters de cassettes depuis les fichiers CDTs en WAV, qui fonctionnent à 100 % et qui visuellement ressemblent très exactement au dumps en WAV originaux. Juste mes 2 cts Pour simplifier, actuellement, vous faites CPC -> WAV -> CSW -> VOC -> CDT. On se propose juste de faire CPC -> WAV -> CSW Ce qui simplifie la vie de tout le monde. Les bons dumpers (ceux qui savent faire des wav "propres" ) resterons les plus appréciés. Leurs dumps fonctionneront juste dans 100% des cas. Dernière quote, en parlant du CT-raw : dlfrsilver a écrit : Pas toujours, certains jeux nécessitent de passer à la moulinette, en brut ça ne passe pas. Je veux bien un exemple ou le ct-raw ne passe pas, et ou le dsk passe m'intéresse. Si tu parles de moulinette pour traiter le signal, on est là encore en amont, donc hors sujet. (là, le consensus existe : il faut traiter le signal pour avoir des données brutes propres)

Auteur :	hERMOL [ 04 Nov 2014, 13:31 ]
Sujet du message :	Re: Dumps originaux
breiztiger a écrit : je trouve franchement marrant les affirmations de denis face a des gars comme thomas et offset DLFRSILVER est le plus gros DUMPeur de cassettes et disquettes sur CPC, il sais de quoi il parles lui aussi. Le format .CDT support 26 type de blocks de données différent, et inclut les block dit "Pure tone", c''est un peu ce que vous décrivez avec le CSW , alors pourquoi réinventé la roue?

Auteur :	Lone [ 04 Nov 2014, 13:35 ]
Sujet du message :	Re: Dumps originaux
Hermol, c'est le cdt qui réinvente la roue... En outre, personne ne met en doute la compétence de Denis concernant la génération de wav propre, bien au contraire ! Le csw a un type simple. Le CDT en a 26 (dont un qui permet d'inclure.... Des données csw ). Le "pure tone" permet de mettre un nombre défini de pulses avec une durée déterminée (mais fixe). C'est tout a fait différent

Auteur :	dlfrsilver [ 04 Nov 2014, 16:23 ]
Sujet du message :	Re: Dumps originaux
hERMOL a écrit : breiztiger a écrit : je trouve franchement marrant les affirmations de denis face a des gars comme thomas et offset DLFRSILVER est le plus gros DUMPeur de cassettes et disquettes sur CPC, il sais de quoi il parles lui aussi. Le format .CDT support 26 type de blocks de données différent, et inclut les block dit "Pure tone", c''est un peu ce que vous décrivez avec le CSW , alors pourquoi réinventé la roue? Merci de l'avoir rappellé aux esprits sans mémoire. Quand je suis arrivé en 2003 sur CPC, y avait rien, cette communauté était proprement mort-vivante, avec peu d'activité (cérébrale devrais-je dire ). J'ai proposé à Kukulcan de faire alliance pour sortir la communauté de son état de zombi. J'ai dressé un état des lieux : 80% de cracks (et je suis gentil!), des dumps d'originaux avec des erreurs de partout (sans commune mesure avec celles qu'on a aujourd'hui), rien de rangé ou d'ordonné, et quelques dumps cassettes de jeux avec des protections diverses (speedlock, ricochet, spectrum, etc). Des jeux toujours pas imagés et totalement absent des uploads existants. Il fournissait le site, je mettais à disposition ma collection, soit plus de 600 logiciels amstrad K7 et D7 pour préservation. J'ajoute également qu'en dehors de certaines personnes de la communauté espagnole, PERSONNE ne savait comment générer des CDTs ! J'ai du entièrement défricher ce problème, et ensuite il a fallu déminer les problèmes rencontrés (nombreux, que ce soit sur cassette : problèmes de protection, problème de protection logique nécessitant des paramètres spéciaux, blocs collés, clé de protection pure tone ou sous forme de signaux, etc... sur disquette, ou CPDread aussi bien que samdisk avaient des soucis pour imager correctement ces dernières). Et je parle pas du problème de rigueur sur CPC : émulation FDC toujours incomplète ou buggée jusqu'en 2013 (CPC++ ayant été le pionnier, suivi de Sugarbox). N'étant pas programmeur, mais comprenant parfaitement bien les concepts et étant doté d'un bon sens pragmatique et d'une logique implacable, j'ai très bien saisi la raison de tout les problèmes que j'ai pu rencontrer jusqu'ici en 11 années passées à dumper. Finalement, tout ceux qui me contrent sont arrivés après la guerre, une fois que moi (qui est technicien) et césar (qui est programmeur) on a traité et éradiqué bon nombre des problèmes en amont. Ce que vous faites aussi bien Breitztiger, Offset et Cie c'est nous cracher à la figurer alors qu'on est pionnier sur le sujet, vous étiez ou vous quand on a démarré en 2003 ? Je devrais au moins être respecté pour le millier de dumps que j'ai fait en l'espace de 11 années pour cette communauté, et au lieu de ça je me retrouve avec des gens qui réinventer la roue, qui veulent tout avoir au prix moindre effort. C'est donc ça ma "descendance", les gens qui disent prendre ma suite ? Je me suis pas cassé le cul à passer des milliers d'heures au détriment de ma vie privée et de ma compagne pour lire vos arguments qui consistent à me saloper gratuitement ! Et que ceux qui partent du principe que j'ai fais des dumps pourris ou foireux se rappellent bien que les outils étaient pas au point, voir pour certains mal foutus, et que des dumps pourris, ils en ont aussi mis en ligne (hein Philippe, toi qui aimes te payer ma tête en me faisant comprendre que certains de mes dumps disquettes sont mauvais, alors que toi même tu n'es pas capable de convertir un jeu comme Stormlord en cassette correctement alors que je t'ai indiqué au début quand tu es arrivé en 2010 ou 2011 dans la communauté comment il fallait faire à la demande de Kukulcan!). Bref continuez de foutre votre merde, je serais là ! Citer : @lone : Lone a écrit : Hermol, c'est le cdt qui réinvente la roue... En outre, personne ne met en doute la compétence de Denis concernant la génération de wav propre, bien au contraire ! Ah bah on dirait pas ! Et de toute façon, ce n'est pas le sujet. Tu ne comprends pas qu'on ne peut rien faire avec un fichier CSW. On ne peut pas le nettoyer, on ne peut pas aller dedans, on ne peut pas voir les blocs ni leur structure. Citer : Le csw a un type simple. Le CDT en a 26 (dont un qui permet d'inclure.... Des données csw ). Le CSW n'a pas de type. Il obéit à un seul et même algorythme, et c'est un format de fichier container. Déjà avec le format CDT c'est pas toujours évident de voir si un dump a des erreurs, mais en plus, le format CSW rend la vérification impossible ! Ce que tu ne comprends pas Thomas, c'est que l'utilisation du CDT répond à un accord commun entre auteurs d'émulateurs, et que le format TZX et CDT est la résultante de cet accord. Tu peux supporter sur ton émulateur le format CSW si tu le souhaites, mais si jamais tu cherches à faire "sortir le format CDT" des émulateurs, tout les communautés CPC te tomberont sur le dos ainsi que les autres auteurs d'émulateurs. Tout les jeux ou presque ont été imagés. On ne va pas tout redumper sous prétexte que tu veux du CSW au lieu du CDT, alors même que Tapir regénère sans problème des masters au format WAV, que tu peux ensuite si ça te change reconvertir au format CSW. en bref, le format CSW doit être simplement une possibilité, et non une obligation. Et histoire d'illustrer mon propos, je mets en ligne un CDT crée en 2004 par un mec qui ne savait comment créer correctement des CDTs, et qui a pour les mêmes raisons que Thomas enregistré tout le programme dans un bloc DRB (enregistrement direct). Petite leçon de travaux pratiques pour ceux qui veulent en apprendre plus sur le format CSW et CDT: Le CDT est sale et non fonctionne pas, car généré comme si c'était un fichier CSW directement 1) Trouvez un moyen de le nettoyer 2) Générez une version CDT Postez si vous rencontrez le moindre problème

Auteur :	Lone [ 04 Nov 2014, 17:03 ]
Sujet du message :	Re: Dumps originaux
Bon, je ne vais pas tout reprendre, mais que ça soit clair : je ne remets pas en cause ton dévouement et ton apport à la communauté. Je ne remets pas en cause non plus l'immense travail que tu as fait. Je me permets juste, humblement, de poser la question suivante : si le support du cdt est indispensable pour les évidentes raisons historiques que tu as mentionné, ne peut on y ajouter aussi le csw, bien plus simple, efficace, etc..., quand l'occasion est là, a partir d'aujourd'hui ? Je peux me tromper, mais je pense que tous les auteurs d'emulateurs préfère gérer un csw qu'un cdt ( vu que c'est le format en entrée du ppi).

Auteur :	TotO [ 04 Nov 2014, 17:14 ]
Sujet du message :	Re: Dumps originaux
Ce n'est pas parce que les choses ont été défrichées avec des formats bricolés tant bien que mal dans le temps, mais de façon louable, qu'il faut se résigner à les considérer comme faisant parti du patrimoine CPC... Ce serait marcher sur la tête. La préservation concerne les orriginaux et non les formats qui ont permis d'en arriver ou nous en sommes aujourd'hui grace à l'aide de tout un chacun. En aucun cas il est question de réinventer la roue, mais de trouver des solutions aux problèmes qui se présentent. Les formats peuvent cohabiter que je sache (sans parler des dumps IPF) ... Tant qu'on regarde de l'avant, les solutions s'imposeront d'elles mêmes.

Page 47 sur 54	Le fuseau horaire est UTC+1 heure
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/

Auteur :	dlfrsilver [ 04 Nov 2014, 17:32 ]
Sujet du message :	Re: Dumps originaux
Lone a écrit : Bon, je ne vais pas tout reprendre, mais que ça soit clair : je ne remets pas en cause ton dévouement et ton apport à la communauté. Je ne remets pas en cause non plus l'immense travail que tu as fait. Je me permets juste, humblement, de poser la question suivante : si le support du cdt est indispensable pour les évidentes raisons historiques que tu as mentionné, ne peut on y ajouter aussi le csw, bien plus simple, efficace, etc..., quand l'occasion est là, a partir d'aujourd'hui ? Je peux me tromper, mais je pense que tous les auteurs d'emulateurs préfère gérer un csw qu'un cdt ( vu que c'est le format en entrée du ppi). CPCE supporte le format CSW. Si je veux créer un fichier CSW, je peux. Mais tout dump doit être vérifié et nettoyé AVANT d'être mis dans son format définitif, et le format CSW ne le permet pas. C'est comme si moi je m'amusais à mettre en IPF des jeux qui déjà en CT-RAW n'étaient pas bons ou avec des erreurs ! Je sais bien que ce format CSW est le format du PPI. Seulement voilà c'est oublier que les cassettes ont de l'âge, qu'elles sont assez souvent sales (70% de cassettes qui passent directement sans traitement du signal, les 30% restantes doivent être nettoyées). Et tu omets une chose : le CPC dispose d'un circuit électronique qui dégage automatiquement les erreurs dans les dumps ou cassettes sales à la lecture. Les émulateurs n'émulent pas cette caractéristique, car elle n'est pas documentée, et puis c'est quand même mieux d'avoir des "masters" propres. Autre chose, à l"époque il n'y avait pas de gros disque dur sur les machines (PC) qui permettaient de créer en usine de duplication les cassettes originales. Comme on peut le voir, les fichiers WAV, VOC, font entre 15 et 50 méga-octets, dans les années 80, aucune machine n'avait une telle capacité de stockage, pas même les industriels. Le duplicateur utilisait un outil qui transcodait l'équivalent du format CDT que l'on connait, en données binaires gravées directement sur bande. C'est entre autre ce que fait TAPIR, on lui met dedans le fichier CDT, on va dans le menu, on clique sur Play to WAV, et il génère un master parfait dépourvu d'erreur. Les auteurs d'émulateurs préfèrent le format CDT conçu pour la préservation au format temporaire CSW. Citer : @Toto : Ce n'est pas parce que les choses ont été défrichées avec des formats bricolés tant bien que mal, mais de façon louable, cette dernière décénie, qu'il faut se résigner à les considérer comme faisant parti du patrimoine CPC... Ce serait marcher sur la tête. Le format CDT a été crée pour faire du mastering de cassette, exactement comme l'outil de SPS pour générer des IPFs. Et oui ce format fait partie du patrimoine, puisqu'on peut générer des masters sans aucun défaut depuis ce dernier. Le format n'est pas bricolé, simplement l'outil de génération appelé samp2cdt ne supporte pas certains formats. Le format IPF c'est pareil, si les formats ne sont pas décrits, ils ne peuvent pas être préservés. Et on on ne marche pas sur la tête ! Citer : La préservation concerne les originaux et non les formats qui ont permis d'en arriver ou nous en sommes aujourd'hui grace à l'aide de tout un chacun. Oui elle concerne les originaux. Idéalement, il faudrait simplement mettre samp2cdt à jour. Se baser simplement sur le format CSW, c'est une erreur, pire, ça fermerait totalement le dump à l'utilisateur lambda. Citer : En aucun cas il est question de réinventer la roue, mais de trouver des solutions aux problèmes qui se présentent. Oui et la meilleure solution c'est de coder les nouveaux décodeurs pour les systèmes de protection non supportés dans le source de samp2cdt. Je n'empêche personne de créer des fichiers CSW, si ils le souhaitent. Ce que je dis, c'est que ce format n'a jamais été conçu pour être utilisé comme format de préservation, mais comme format permettant un gain de place sur les fichiers WAV avant que le format CDT ne soit mis au point, pour la "transportabilité". Je le rappelle, il est impossible de traiter et nettoyer des fichiers CSW. On doit obligatoirement le convertir ou le décompresser pour ça. Il suffirait d'améliorer les outils existants, qui ont besoin d'être complétés, plutôt que de tout recommencer Citer : Les formats peuvent cohabiter que je sache (sans parler des dumps en IPF) ... Tant qu'on regarde de l'avant, les solutions s'imposeront d'elles mêmes. Les formats cohabitent DEJA ! En 2003 quand un jeu dumpé depuis une cassette faisait chier, j'utilisais l'outil CSW de césar, l'auteur de CPCE pour générer des CSWs d'abord, et ensuite les passer en CDT si besoin par le bytelogger de CPCE pour obtenir un master parfait et sans erreur. Le format IPF pour les disquettes c'est encore autre chose. La sortie des jeux CPC en IPF est prévue après la sortie de la console KF en révision 2.60 Et justement je regarde de l'avant, et je préconise la mise à jour des outils dont les codes sources ont été rendus public.