Soite mais... ça fait tache parmi tous tes autres DUMP nickel.
Perso, j'aurais re-dumper.

Le problème c'est que chaque éditeur a fait appel à une entreprise de duplication, utilisant des machines différentes.

Par exemple, les jeux espagnols ont été répliqués avec du matos bas de gamme, là ou une bonne partie des éditeurs passaient par une machine de duplication digne de ce nom (genre TRACE Mountain).

Donc non ça fait pas tâche puisqu'au final, quand ces jeux seront passé en IPF, tout sera normalisé. Comme indiqué, les dumps en flux n'ont rien de définitif en soi, c'est de la donnée de travail. Donc si c'est cracra ou encore avec un aspect chelou, ça dérange pas.

_________________
SPS Community Expert (SPS CE) / SPS France

Heuu quel rapport avec la qualitee de machine de duplication ?
La c'est clair et net que ca vient de la disquette, pas du tracer.

Un rpm qui varie a la lecture, y'a pas photo.
Que ce soit plus ou moins crade en sortie du tracer, ok
La c'est clairement pas le probleme, c'est decalé a cause d'un rpm qui varie.
Un rpm qui varie lors du dump c'est clairement a cause du support ou du lecteur.
PAS des donnees ecrites sur le media (proprement ou pas).

Le rpm ne varirais pas autant, ok, ca viendrais de la qualitee du traceur.
La... niet, c'est pas du tout le cas.

Ceci dit, c'est peu etre pas le cas sur les autres dump décalé.

Mais tu as raison dans l'ensemble, cela ,ne devrait pas gêne pour la création d'IPF
Il faut bien comprendre que ce que l'on voit sur la 'diskview' n'est PAS l'image du master
MAIS l'image du Flux PENDANT la création du dump. La nuance est très importante
De plus, la diskview est une image a 'plat' des variables dans le dump flux et non l’interprétation que fait le FDC en réel sur le CPC lors de la lecture.
Donc Oui, effectivement, il faut prendre les dump flux comme un support de base pour la création de 'master' et non comme 'master' lui même.


Mais comme dit plus haut, perso j'aurais 'a l'okaz' re-dumper ses jeux 'décalé' juste parce que l'image de la diskview ne me plaît pas.
Juste pour ça

Une disquette tracée avec une machine trace mountain ne donne pas ce résultat visuel.



D'autres jeux que j'ai pu dumper présentent le même pattern, et les disquettes en question étaient en bon état.



Oui mais dans ce cas, les RPM c'est lié au moteur, hors sur d'autres jeux y a pas soucis.



Quand une disquette est merdique, foireuse, le dump ne se passe pas bien, tu obtiens des erreurs de lecture, surtout avec la variation en RPM dont tu parles. Et dans ce cas, si le problème venait du lecteur, le problème se poserait sur toutes les disquettes sans exception. Hors ce n'est pas le cas



je m'explique : ce qu'on voit sur ces disquettes, ce sont des tailles de gap / taille entre chaque piste qui ne sont pas fixes. On voit que les pistes sont OK, mais par contre ces dernières ne sont pas alignées proprement.

On a ce cas de figure sur les disquettes dupliquées en Espagne sur machines unix Philips.



Beh oui justement, c'est pas le cas sur les autre dumps. C'est pour cette raison que j'adhère plus que moyenne que ce soit
à un problème de type moteur ou encore un problème de disquette.

Le kryoflux lit tout bêtement ce qui a été écrit par la machine de duplication. Et une disquette indépendamment de son état,
n'a pas d'influence sur le nombre de RPM du moteur. En cas d'erreur, le kryoflux réitère sa tentative de lecture.



Certain effectivement étant donné que les données sont bonnes.



On est bien d'acccord



Tout à fait, et c'est ce que j'expliquais plus haut



Tout à fait. C'est tout l'avantage de lire les disques avec un controleur propriétaire et pas le FDC765 de nec qui interprète (sous entendu ne voit pas les données telles qu'elles sont nécessairement écrites physiquement).



Clairement.



LOL. En l'occurence, le but est que les données soient bonnes. Si on a ça, c'est déjà une bonne base

_________________
SPS Community Expert (SPS CE) / SPS France

@dlfrsilver : As-tu, par le plus grand des hasard, un IPF du raw "1001 BC A Mediterranean Odyssey " ?

J'ai fait des tests de génération d'IPF le concernant assez surprenant : L'IPF marche sur Sugarbox, ne marche pas quand on le dump sur une disquette, mais si l'on dump ladite disquette, le résultat (kryoflux) fonctionne là encore...

Par ailleurs, mon "fameux" algo de détection des bits faibles à partir de révolutions multiples fonctionne désormais assez correctement : Je décode efficacement tous les RAW que j'au pu trouver (soit un sacré paquet, grâce à Denis et à tous nos super collectionneurs !)

Ce qui me fait dire que le dump est une science difficile : J'ai eu des cas tordu, des très tordus, et plus encore.
Le pire étant les pistes avec erreurs de lectures sur piste de taille 6 sans crc : Je suis obligé de considérer ces bits problématiques comme "faibles" car impossible de déterminer la révolution correcte.
Au final, ça fonctionne grâce aux algo de relectures (on comprend leur intérêt ici !) qui fini par avoir un "1" ou un "0" comme voulu

Sur les 5 qui me posaient problème :

- [CPC] Cobra Pinball (A) (F) (1985) [Cobra Soft].raw et [CPC] Galivan - Cosmo Police (UK) (1986) [Imagine].raw :
Problème de PPI plutôt que de disque (c'est réglé)

- [CPC] Gemini Wing (UK) (1990) [DroSoft Spain].raw : Il marche mais je ne sais plus pourquoi !

- [CPC] Little Puff In Dragonland (UK) (1990) [EDOS - Codemasters].raw : Lui, c'est le fameux "secteur 6, crc ko et piste en erreur"... Mais il a fini par se lancer. Par contre, je comprend que la SPS interdise d'en faire un IPF : Difficile de savoir quelle révolution est correcte !

- [CPC] Spy Vs Spy III - Arctics Antics (UK) (1987) [First Star Software].raw : Le seul qui me pose des soucis, mais sans doute pas lié au dump/FDC (plutôt un problème d'émulation d'un autre périph, je pense)

Pourtant à la vue du diskview de [CPC] Spy Vs Spy III - Arctics Antics (UK) (1987) [First Star Software].raw
rien de bien spécial... Zarb

Bien sur que non Et tu sais pourquoi..... ce jeu utilise la KBI-10 Weak Sector CA. Je ne peux pas en l'état faire d'IPF de ce jeu.



C'est tout à fait normal. Comme le format n'est pas supporté, le DTC ne sait pas comment l'écrire. Résultat, si dumpe la disquette sur laquelle tu as écris, ben c'est merdeux.

Ce type de protection doit être décrite pour pouvoir être écrite sans qu'il y ait de couille.







Tu en doutais ?



Y a encore mieux : avoir en main un original propre, ce qui permet d'avoir des pistes qui tiennent la route



OK



Je te la fais simple, cette version espagnole n'est rien de plus dans le principe qu'une copie pirate, avec les niveaux en sectoriel.
Il n'y a aucune particularité, ni même la moindre protection.



La piste 0 est vue comme "mauvaise", je dirais plutôt que c'est un faux positif.....



Y a aucune protection sur celui-là, mais rien de chez rien.....

_________________
SPS Community Expert (SPS CE) / SPS France

@dlfrsilver : As-tu, par contre, le dump kryoflux ?
Et si oui, peux-tu me le zipper quelque part, que je regarde ce qui s'y passe que je ne retrouve pas ?

Merci d'avance !

De quel jeu tu parles exactement ?

_________________
SPS Community Expert (SPS CE) / SPS France

Milles excuses, je parlais de "1001 BC A Mediterranean Odyssey " qui m'interpelle toujours autant.
J'aimerais voir ce qui m'échappe, et pour ça, seul le dump kryoflux peut me permettre de le voir...

@dlfrsilver : J'en conclus que tu n'as plus les dumps Kryoflux originaux ?

Sinon, j'ai corrigé ma génération d'IPF qui était inexacte sur un octet non utilisé (signalé par AIR).
Le résultat fait toujours planter AIR, ce qui est un peu normal, en débuggant cet outil, on remarque que les tailles en bits qui ne sont pas des multiples de 8 ne sont pas correctement gérés...

@Giants : dans la liste je ne retrouve pas ton autre utilitaire qui retournait des erreurs, pourrais tu me le rappeler ?

Je vous joins la version de 1001BC en IPF, intéressante car fonctionnelle sur émulateur, non fonctionnelle sur CPC, mais dont le dump kryoflux est lui aussi fonctionnel sur ému (d'ou ma perplexité)

Au passage, la version de "IPF Reader" corrigée (comprendre : Qui lit les champs de bits non multiples de 8).

Tu peux preciser car la, je ne voie pas du tout de quoi tu parles.

@Giants : Pardon, je suis dans mon sujet à fond...

Donc, il s'agissait d'un outil qui lisait les IPF, et retournait des erreurs sur les IPF que je générais... Il semble me souvenir (sans retrouver la bonne page) que tu mentionnais un autre outil que celui du Dr Coolzic ?

Pour analyser les ipf il n'y a pas trente six solutions
soit passer par ipfreader de DrCoolzik
soit ipfread en ligne de commande (a compiler)
Si l'ipf est pas 'conforme' alors le soft petera une erreur.

ou avoir 3990E pour prendre la version la plus lite de Cta...