@dlfrsilver : Je pense qu'on a surtout un problème de communication sur la technique : Je te propose donc qu'on en reste là (même si tes infos sur l'Amiga était très intéressantes).
Petit WIP du jour : Aujourd'hui, un iPF de Hercule II a été généré par mes soins, fonctionne avec la lib (mais pas avec Caprice - qui crash comme un malheureux lors du chargement (si j'était mauvaise langue, je dirais que ça ressemble au crash que j'avais avec la lib !)). Mieux, l'écriture disk fonctionne, et le résultat marche bien.
Et mieux encore, j'ai fait deux ipf : L'un a partir d'un dump kryoflux (raw), l'autre d'un bête dsk, eh bien les deux donnent très exactement le même résultat fonctionnel, comme prévu (le soft se lance et passe la célèbre protection LATIS).
Inscription : 29 Août 2007, 12:04 Message(s) : 2009 Localisation : seine et marne 77
Lone a écrit :
@dlfrsilver : Je pense qu'on a surtout un problème de communication sur la technique : Je te propose donc qu'on en reste là (même si tes infos sur l'Amiga était très intéressantes).
Petit WIP du jour : Aujourd'hui, un iPF de Hercule II a été généré par mes soins, fonctionne avec la lib (mais pas avec Caprice - qui crash comme un malheureux lors du chargement (si j'était mauvaise langue, je dirais que ça ressemble au crash que j'avais avec la lib !)). Mieux, l'écriture disk fonctionne, et le résultat marche bien.
Et mieux encore, j'ai fait deux ipf : L'un a partir d'un dump kryoflux (raw), l'autre d'un bête dsk, eh bien les deux donnent très exactement le même résultat fonctionnel, comme prévu (le soft se lance et passe la célèbre protection LATIS).
C'est normal, caprice n'a pas un set d'instruction 100% parfait. Et la latis nécessite que ça soit le cas.
_________________ SPS Community Expert (SPS CE) / SPS France
Petite avancée du jour sur Sugarbox qui génère des IPFs.
EXIT en version IPF est fonctionnel avec la librairie (sur Sugarbox), mais pas avec Caprice... (un problème d'émulation ?)
La régénération sur disquette fonctionne également.
Quizz du jour : A votre avis (enfin, ceux qui ont des outils d'analyse !), généré à partir d'un DSK ou d'une source plus fiable ? Réponse argumentée attendue (sinon c'est facile, une chance sur deux !)
Par ailleurs, si vous avez des envies de test sur des protection chelou, n'hésitez pas à me demander (en PM si vous ne voulez pas lancer de polémique !), ça me permettra de voir si mon algo tiens la route ( A l'exception des weaks sectors, j'attaque tout juste le sujet, il faudra patienter un brin)
Vous n’êtes pas autorisé(e) à consulter les fichiers insérés à ce message.
Inscription : 21 Août 2008, 16:03 Message(s) : 342
Pour moi, deux genre de personnes sur ce thread.
Y'a les gens de passages, qui viennent pour pousser une gueulante sans avoir toutes les billes. Une fois leur petit coup de gueule passer, ils retourneront dans leur grotte où ils étaient caché.
Et y'a les autres, qui font avancer les choses que ce soit au niveau du code, du dump, du scan... Qu'on soit d'accord ou pas sur les sujets, on fait avancer la chose.
EDIT : info reportée dans l'autre topic scan.
Dernière édition par Giants le 12 Jan 2016, 09:37, édité 1 fois.
Inscription : 29 Août 2007, 12:04 Message(s) : 2009 Localisation : seine et marne 77
Lone a écrit :
Petite avancée du jour sur Sugarbox qui génère des IPFs.
EXIT en version IPF est fonctionnel avec la librairie (sur Sugarbox), mais pas avec Caprice... (un problème d'émulation ?)
La régénération sur disquette fonctionne également.
Je viens de tester ton IPF. Mon outil m'indique que les pistes de protections ne sont pas décrites dans tes IPF.
Quand je tombe sur un original qui me donne ce résultat, j'ai interdiction de générer un IPF en sortie.
C'est soit toutes les pistes sont reconnues lors de l'analyse, soit elles ne le sont pas, auquel cas c'est pas valide .
Citer :
Quizz du jour : A votre avis (enfin, ceux qui ont des outils d'analyse !), généré à partir d'un DSK ou d'une source plus fiable ? Réponse argumentée attendue (sinon c'est facile, une chance sur deux !)
Tu ne peux pas m'avoir sur une question pareille. Tout simplement parce que l'outil ne gère pas que du bit, du MFM. Je fais également le monitoring du signal (celui que le duplicateur a tracé sur le disque original).
Très clairement, tu as injecté un DSK et tu as procédé à une reconstruction MFM des pistes.
Pourquoi je dis ça ? Tout simplement parce que le signal est trop propre quand je charge ton IPF dans mon outil.
Ton IPF pèse 262968 octets et se compresse en une taille de 68402 octets.
Un IPF que j'ai généré moi, du même jeu en face A pèse 215129 octets, et compressé fait une taille de 46313 octets.
Ah tiens, ton IPF est plus gros que le mien ?
Réponse : Normal, ton système ne prend pas en charge la compression intégrée du format IPF
Note: l'algorithme de compression est spécifique et propriétaire, similaire à un format comme celui de 7zip.
C'est quoi les 60ko en plus ? Tu as planqué une poupée gonflable en cadeau dedans ?
Tu vois, quand je te dis que connaitre le format IPF ou même CT-raw ça ne suffit pas, il y a une mécanique bien plus complexe derrière à l'oeuvre.... Tu me crois toujours pas ?
Bref, quand je traite un fichier CT-RAW dans l'outil d'analyse, le signal original qui vient de la disquette est vu sous forme de graphique. Un signal totalement plane comme celui tiré de ton IPF indiqué que c'est soit trafiqué, soit les données ont été injectées directement propres ou ont été modifiées.
Les données gravées présentent d'origine des imperfections. Quand il n'y en a aucune, c'est que c'est cheaté
_________________ SPS Community Expert (SPS CE) / SPS France
C'est ce qui explique la taille supérieure : Etant donné que c'est un dump "original", on n'a pas (forcément) l'alignement des GAP sur 16 bits (je parle MFM).
Mon algo étant prévu pour stocker l'intégralité de la piste, je suis obligé de passer en taille en nombre de bits plutôt qu'en bytes. Et surtout, vu qu'en plus on n'est pas forcément aligné sur un nombre de bits pairs, je suis obligé dans ce cas de stocker les infos sous forme MFM plutôt qu'en data classique... 20% de donnée en plus, ça s'explique comme ça (un bloc de data sur 5 doit avoir cette fameuse taille impaire).
C'est pire encore quand on fait la manip à partir d'un RAW kryoflux : J'ai l'exemple de Hercule II qui fait 434ko depuis le RAW, et 225 depuis le dsk. A cause de ces fameux blocs impairs.
Ceci dit, tout ceci est intéressant à un autre titre : On comprend bien que la SPS et moi ne sommes finalement pas en concurrence. Comme le disait justement Remax, la SPS cherche à préserver et à faire des masters maîtrisés. J'entends par là qu'elle cherche à comprendre les protections, de manière à faire des IPFs qui ne soient pas comme les miens, de vulgaire copie 100% parfaite d'UN disque unique. Ils souhaitent avoir un master plus générique (et sans doute plus propre, avec des jolis blocs de données et des gaps le mieux définis possible).
Mes IPFS sont juste des copies de piste. Fort pratique pour recopier des images à l'identique, mais certainement trop spécifique et précis pour une préservation (qui se doit d'être un peu plus générique). En gros, c'est comme si je fournissais des RAW ou des SCP, juste un peu plus petits.
Concernant la compression des IPFs. Denis, je decode correctement tes IPFs. Sans les décompresser. Il n'y a pas de compression (au sens zip ou autre) dans ces fichiers. S'il y avait une compression mystère, je ne parviendrais pas à les lire, voyons...
Inscription : 29 Août 2007, 12:04 Message(s) : 2009 Localisation : seine et marne 77
Lone a écrit :
Presque bon, denis
En fait, c'est généré à partir d'un CT-Raw.
C'est ce qui explique la taille supérieure : Etant donné que c'est un dump "original", on n'a pas (forcément) l'alignement des GAP sur 16 bits (je parle MFM).
C'est très bizarre, j'ai un dump en CT-raw venant d'un original de Loic, le signal n'a pas cette tête, et pareil sur le même dump de Breiztiger.
Citer :
Mon algo étant prévu pour stocker l'intégralité de la piste, je suis obligé de passer en taille en nombre de bits plutôt qu'en bytes. Et surtout, vu qu'en plus on n'est pas forcément aligné sur un nombre de bits pairs, je suis obligé dans ce cas de stocker les infos sous forme MFM plutôt qu'en data classique... 20% de donnée en plus, ça s'explique comme ça (un bloc de data sur 5 doit avoir cette fameuse taille impaire).
C'est pire encore quand on fait la manip à partir d'un RAW kryoflux : J'ai l'exemple de Hercule II qui fait 434ko depuis le RAW, et 225 depuis le dsk. A cause de ces fameux blocs impairs.
Ouais ça ressemble aux ADFs étendus que je générais sur Amiga ton truc. Ca donne effectivement de grosses images.
Citer :
Ceci dit, tout ceci est intéressant à un autre titre : On comprend bien que la SPS et moi ne sommes finalement pas en concurrence. Comme le disait justement Remax, la SPS cherche à préserver et à faire des masters maîtrisés. J'entends par là qu'elle cherche à comprendre les protections, de manière à faire des IPFs qui ne soient pas comme les miens, de vulgaire copie 100% parfaite d'UN disque unique. Ils souhaitent avoir un master plus générique (et sans doute plus propre, avec des jolis blocs de données et des gaps le mieux définis possible).
Franchement, pour éviter qu'on ne s'emmêle les pinceaux, donne un autre nom d'extension à tes fichiers.
ça va être une grosse galère de faire la différence, les gens ne comprendront pas, et ça va m'obliger à répondre à des questions auxquelles je n'aurais normalement pas à faire face....
Citer :
Mes IPFS sont juste des copies de piste. Fort pratique pour recopier des images à l'identique, mais certainement trop spécifique et précis pour une préservation (qui se doit d'être un peu plus générique). En gros, c'est comme si je fournissais des RAW ou des SCP, juste un peu plus petits.
J'avais bien comprendu
Citer :
Concernant la compression des IPFs. Denis, je decode correctement tes IPFs. Sans les décompresser. Il n'y a pas de compression (au sens zip ou autre) dans ces fichiers. S'il y avait une compression mystère, je ne parviendrais pas à les lire, voyons...
Vo-yons !
_________________ SPS Community Expert (SPS CE) / SPS France
Inscription : 13 Jan 2010, 14:25 Message(s) : 2282
dlfrsilver a écrit :
Vo-yons !
N'importe qui peux ouvrir un fichier IPF avec un éditeur hexa et s'appuyer sur la description du format pour s’apercevoir qu'il n'y a pas de compression.
Inscription : 21 Août 2008, 16:03 Message(s) : 342
>Franchement, pour éviter qu'on ne s'emmêle les pinceaux, donne un autre nom d'extension à tes fichiers.
ça va être une grosse galère de faire la différence, les gens ne comprendront pas, et ça va m'obliger à répondre à des questions auxquelles je n'aurais normalement pas à faire face....
J'avais déjà aussi proposer cette solution simple qui réglerais bien des problèmes...
Pour la question de Lone moi je n'ai pas eu la même réflexion concernant ce demande Me suis dit, ca ne peu etre une source DSK car il nous a déja fait le coup Peu pas être un IPF sps car ca n'a aurait aucun intérêt, d'une part car denis le verrais de suite et surtout, ca ne ferai pas avancer le code de Lone Restait plus qu'a mon sens du flux (alors ct raw ou flux flux... bref...) J'ETAIS PAS LOIN :)
L'image en question n'ai pas reconnue avec AUFIT et j'ai IPF file reader me pète aussi une erreur, pour lui, la structure de l'image n'est pas correct.
Inscription : 21 Août 2008, 16:03 Message(s) : 342
Lone !
Je me suis fait un petit outils pour checker et je voudrais comparer ce que j'ai déja avec une image que tu génère. Peux Tu crée via ton ch'tit code une image IPF du jeux EXIT avec comme source une image DSK
Quelques avancées. Après m'être un peu battu, j'ai changé ma manière de gérer les pistes : Plutôt que stocker plusieurs révolutions, je n'en conserve qu'une, avec une info sur le fait que le bit est indéterminé ou non. Ca me permet en outre de générer des IPFS corrects de ce point de vue là. Et de tester ma gestion des weak bits via IPF.
Voici un petit exemple : After Burner (toujours lui), généré avec les weaks bits au bon endroit (et seulement là, sans avoir la grosse ficèle précédente).
A priori, je ne sais pas ce qu'on pourra en faire : La lib de la SPS ne le gère pas correctement (mais c'est pas une nouveauté), vous pourrez le relire via la prochaine version de Sugarbox...
Je n'ai pas encore de retour de test de réécriture via l'outil qui prend les IPF, mais un test marrant a été fait : Regénérer un SCP à partir de cet IPF (via Sugarbox)... Et le jeu marche !
Je pense avoir l'explication (alors que je ne gère pas explicitement les weaks bits en scp), mais c'est quand même une sacré surprise !
Vous n’êtes pas autorisé(e) à consulter les fichiers insérés à ce message.
Utilisateur(s) parcourant ce forum : Aucun utilisateur inscrit et 99 invité(s)
Vous ne pouvez pas publier de nouveaux sujets dans ce forum Vous ne pouvez pas répondre aux sujets dans ce forum Vous ne pouvez pas éditer vos messages dans ce forum Vous ne pouvez pas supprimer vos messages dans ce forum Vous ne pouvez pas insérer de pièces jointes dans ce forum
Connexion
Inscription
FAQ
