Effectivement, j'utilise la pleine puissance du format, avec un objectif différent de la SPS.

Là où elle va tenter de produire un master (d'où la nécessité de connaissance du format), je génère une copie exacte de ma source. Au bit près, ce qui me permet de gérer nativement l'ensemble des protections.

Ce qui pose bien sur une question intéressante : La préservation passe-t-elle par une copie exacte, ou par la génération d'un master qui a donc forcément une part d'interprétation ?

Mon avis sur le sujet, c'est que c'est par la redondance (des sources et des moyens) que l'on pourra correctement préserver notre patrimoine soft.

EDIT : Pour les tag dans les softs : Il me semble qu'on a un CRC global qui empêche de simplement remplacer le tag de l'auteur ou du soft.

Il y a aucun garde fou dans ton logiciel, s'il y a une erreur, elle sera injectée. Pourquoi ? tout simplement parce qu'il n'y a pas de contrôle visuel sur les données en sortie.

On a la réponse depuis longtemps. Les IPFs sont des "copies" exactes de la source d'origine.

Les masters n'ont aucun part d'interprétation, et pour une raison simple : s'il y a interprétation, alors il y a modification. Comme le système interdit ça dans son fonctionnement et son principe, il n'y a rien de ça.

Ce qui est écrit via la carte kryoflux correspond exactement et physiquement à ce qui se trouvait sur la disquette qui a servi pour le dump (au poil de cul près).

En fait, pose toi plutôt la question, totalement logique, que tu ne t'es absolument pas posé, mais qui pourtant est tellement évidente :

Pour quelle raison d'après toi SPS n'a pas utilisé dès le départ la méthode que tu utilises, alors qu'elle semble si simple à priori ?

je vais te répondre :
(...)

En fait, je t'appuie pour au moins 1 point : certains logiciels s'automodifient, on ne les trouvera pas en état neuf. Donc ton soft pourrait s'avérer utile pour ces derniers, car notre politique nous interdit de les traiter, puisqu'ils sont modifiés. Pour les autres, tu nous laisses faire.



Tout à fait, il y a des dispositifs de protection. Pour rappel, c'est le seul programmeur de l'époque qui a vu avec celui de Jurassic Park, sa protection contre la copie inviolée.

Il a protégé Abandoned Places 2, aucun pirate n'a réussi à lui faire la peau. Les copies sont inutilisables, en gros tu fais une partie pendant 10 minutes, tes persos meurent d'un coup. Tu sauvegardes ? Elles se corrompent, ou bien tes personnes meurent instantanément au rechargement de la sauvegarde.

Quand à Jurassic Park, le mec qui l'a plombé a tellement bien fait son job (Mr.E du groupe Crystal pour ne pas le nommer), que le jeu n'a été complètement déprotégée qu'il 'y a 1 ou 2 ans.

Une fois encore, c'est pas mon but. Moi, c'est l'exacte copie que je recherchais. Pas à certifier l'original, non. D'ailleurs, pourquoi le contrôle doit il être visuel ?

"Au poil de cul près". Le diable est dans les détails. Ma conversion n'est pas au poil de cul près, ce qui me permet de tout supporter. Celle de la sps non. Mais tu te trompes de combat, voir ci-dessous.

Bien sûr que je me suis posé la question : j'ai déjà détaillé ce que je crois être la philosophie de la Sps. Pour résumer une nième fois :
La sps avec son format ipf, veut reconstruire des master. L'ipf est inspiré du fameux freeform.

Cela necessite donc de l'analyse, et de l'adaptation, ce qui signifie que leur ipf généré est équivalent, mais non égal au dumps qui a servit de source.

Il est d'ailleurs facile de le voir si l'on compare les pistes d'un kfraw et d'un Ipf( y'a sans doute des bits en rab dans les zones sans importance).

Connaître et supporter la protection consiste à connaître ces zones, de manière à en générer une approximation suffisante et lisible.

Mon avis sur le sujet, c'est que c'est par la redondance (des sources et des moyens) que l'on pourra correctement préserver notre patrimoine soft.

Mélange pas tout Denis : un crc, c'est un checksum, c'est tout... il n'y a ni cryptage, ni protection inviolable sur le format ipf, hein...

1/ Le format IPF ne décrit pas la protection directement. Il décrit la piste. Si tu me dis le contraire, argumente précisément (un exemple serait le bienvenue).

L'outil de la SPS génère un IPF à partir de données reconnues, de protections connues, etc. Le format lui-même ne contient pas trace d'une quelconque infos.

2/ L'histoire de recréer des masters, c'est pas mal. Mais ça parait annexe quant au sujet de la préservation.

Tout comme pour les cassettes, une vrai préservation passe par l'extraction d'un maximum d'information.

Des infos interprétées, c'est bien, mais arrivera un jour ou l'on regrettera de n'avoir que cela.

(Imagine qu'on ait dit un jour "le format DSK est suffisant pour la préservation !"). J'ose espérer que la SPS conserve précieusement les dumps Kryoflux dans ses bases secrètes (à vrai dire, j'en suis persuadé) !

Rappel : IPF = format de bit. C'est à dire que c'est de l'interprétation du niveau inférieur, qui est une description d'inversion de flux (scp, kfraw).

De plus, que va-t-on faire si un jour on découvre un algo qui lave la crasse plus blanc que blanc, si on n'a plus les originaux en inversion de flux ? Quel dommage !

L'IPF n'est donc qu'un format commode de description de piste, pas de préservation réelle.

3/ Pour revenir au format IPF. Il y a certes certaines infos (GAP, etc), mais c'est générique. Si tu as de l'info dans un GAP, ça apparaîtra comme de l'information et non du GAP. Idem, si tu as des secteurs imbriqués (rappel : Sur certaines protections à secteurs imbriqués, les secteurs démarrent en plein milieu d'un autre secteur), un bit peut appartenir à plusieurs secteurs, voir être considéré comme du GAP. On en revient au même truc : IPF = description de piste.

4/ "Crasse", "saleté"... On parle de quoi ? Un bit, c'est un bit (0 ou 1). Ça n'est ni sale, ni crasseux. Éventuellement il est mal lu. Si on parle de bit, c'est qu'on a déjà traité les inversions de flux produisant ces bits.

5/ Si tu considère l'outil d'analyse comme "un nettoyeur de crasse", tu acceptes l'idées que ce qu'il produit est différent de ce qu'il lit. Donc, c'est une copie interprétée. Tu ne peux pas être à la fois une copie exacte et une copie nettoyée.

D'accord avec thomas

L'info de base reste le dump kryoflux, qui contient ces fameuses inversions de flux qui d'ecrivent les bits ... donc à un niveau inférieur à çe que contient l'ipf

Comme le wav pour nos cassettes, qui contient l'analogique transforme ensuite en donnees numerique dans nos Cdt

Il faut absolument conserve les dumps kfraw et nos wavs pour comme dit thomas au cas où on se rend compte que l'on a mal decode quelque chose

En fait, la partie analyse de l'outil n'est que la surface. L'analyseur sait faire bien plus qu'analyser et générer des IPFs. On peut carrément définir une protection en l'appelant par son nom, définir un secteur particulier en taille, avec ses timings, ses propriétés, et ainsi de suite.



Si, mais c'est juste que tu n'as pas les infos correspondantes qui apparaissent en clair. L'outil sait à quoi correspond tel ou tel octet, mais une fois celles-ci injectée dans l'IPF, impossible de savoir qui est quoi.

Comme je l'avais déjà expliqué, tu as décodé toute la partie en clair via le source. Il reste toujours la partie "sombre" (façon de parler hein), qui elle est très complexe, mais aussi impossible à tracer.

Je ne comprends pas ce que tu cherches à dire ou à expliquer.

Denis, pitié arrête le n'importe quoi !

Les IPF ont été entièrement décodés, c'est un fait (et pas que par moi). Il n'y a aucun octet en plus qui contiendrait une quelconque information. Ne soit pas mystique. Ou arrête de troller, c'est un peu gros (même si je tombe dedans régulièrement, je le confesse)

Il faut l'information la plus proche de la source. IPF n'est pas le format le plus proche de la source. Ca peut se résumer à ça. Si ça ressemble au fameux freeform, c'est bien mais pas suffisant. Il faudrait les originaux freeform par exemple.

Je passe sur le reste. J'imagine qu'on dit la même chose...

L'IPF est un format de description de piste. Pour faire bien les choses, la SPS décrit chaque protection, pour avoir des IPF bien propre.

Donc sans les bits de rajouts inutiles que l'on trouve parfois sur les dumps ctraw (j'imagine que c'est ce que tu appelles "la crasses"). On diffère juste sur le fait que tu considères que ça ne fait pas partie du dump source, et moi si.

Je suis d'accord pour dire que le résultat peut être élégant et bien fichu.

J'offre juste un autre moyen : A partir d'un bête fichier dsk, je reconstitue également un master utilisable. J'ai pas le même soucis d'élégance ou d'exhaustivité de description (comme l'outil de génération), mais une fois encore, je n'ai pas le même objectif.

Et si tu regardes objectivement un jour, tu verras que les pistes que génère à partir d'un dsk (si je pars d'une autre source, c'est trop facile) sont très proche de celles que tu aurais à partir d'une source complète (le dsk ayant une manière bien a lui de "nettoyer" les dumps).

@Lone : ce que tu dois expliquer à dlfrsilver c'est le format qu'on a prit pour l'émulation, c'est à dire la piste complète en format MFM/FM qui est générée au final en lecture pour le drive/fdc... Quelque soit la source (IPF, CTRAW ou DSK) , on aboutit, après un lourd traitement dans Sugarbox, à des pistes complètes avec toutes les informations Index, GAP et données !

une fois dans ce 'format' qui est celui de haut niveau lut par le drive/FDC et qui a des données propres (où en tout cas qu'un lecteur de disquette + FDC peut lire, y compris avec les décalage de bits par rapport à la fenêtre de données), c'est là que ton outil peut générer un IPFs, décrit avec zone Index, GAP et données... La particularité, c'est que tu utilises une description bit à bit (le format IPF le permet) plutôt que comme la SPS avec Index (en bytes), GAP (en bit) (et avec complétion de bits entre gap et données) et ensuite les données des secteurs (IDR+crc+données) alignées en bytes !

en tout cas c'est ce que j'ai compris du codage que tu as fait !

ouf !!!

donc au final, c'est un choix d'implémentation différent du SPS... qui aligne toutes les données...c'est propre mais j'attends de voir l'implémentation la gestion des weakbits et des protections comme celle de MOT pour savoir si on peut vraiment appliquer partout l'alignement des données des secteurs (IDR+crc+données) alignées en bytes !

car concernant par exemple le jeu MOT, et j'en sais quelques chose, si on est pas en format bit, on est pas décalé lors de la lecture des données (merci le faux mauvais bit MFM qui j'espère a été mis exprès dans cette protection) ) après index et donc le loader ne détecte pas les bonnes données !