Inscription : 20 Août 2013, 18:03 Message(s) : 258
Ça ressemble à un problème d'identification par le soft de création d'ipf. Je pense que l'original a de forte variation de vitesse de rotation et sur les pistes non standard, le soft prend ça comme faisant partie de la protection. Avec Aufit, c'est assez clair: - la Piste 0 (standard) est parfaitement stable - les autres pistes ont des variations de vitesse très marquée, au point qu'aufit y détecte des erreur de CRC, sa PLL semble avoir du mal a suivre.
Inscription : 29 Août 2007, 12:04 Message(s) : 2009 Localisation : seine et marne 77
Gerald a écrit :
Ça ressemble à un problème d'identification par le soft de création d'ipf. Je pense que l'original a de forte variation de vitesse de rotation et sur les pistes non standard, le soft prend ça comme faisant partie de la protection. Avec Aufit, c'est assez clair: - la Piste 0 (standard) est parfaitement stable - les autres pistes ont des variations de vitesse très marquée, au point qu'aufit y détecte des erreur de CRC, sa PLL semble avoir du mal a suivre.
En fait, compte tenu de ce que montre le graph, avec la piste 0 positionnée d'une certaine façon, et les autres avec comme une sorte de décalage régulier, c'est normal pour moi.
Dans les images de CTraw générées par Giants, on peut voir que certains disques ont des pistes bien calées les unes par rapport aux autres.
J'en déduis donc que le pattern vient de la machine qui a tracé le disque.
_________________ SPS Community Expert (SPS CE) / SPS France
Inscription : 20 Août 2013, 18:03 Message(s) : 258
dlfrsilver a écrit :
En fait, compte tenu de ce que montre le graph, avec la piste 0 positionnée d'une certaine façon, et les autres avec comme une sorte de décalage régulier, c'est normal pour moi.
Dans les images de CTraw générées par Giants, on peut voir que certains disques ont des pistes bien calées les unes par rapport aux autres.
J'en déduis donc que le pattern vient de la machine qui a tracé le disque.
Si c'est la machine qui a tracé le disque, j'ai donc une version différente, les secteurs sont bien alignés. J'ai plutôt l'impression que c'est le lecteur qui a lut les disques qui cause ces différences. Il est possible de savoir qui a dumpé quoi ? Si le lecteur a un probleme, ca se verra sur les dump fait avec.
Inscription : 21 Août 2008, 16:03 Message(s) : 342
>Ça ressemble à un problème d'identification par le soft de création d'ipf. hEUUU? on parle pas d'IPF la, on parle de format CTR. Les fichier Ct-raw sont directement crées par le logiciel en ligne de commande à savoir DTC.exe, y'a pas d’interprétation de quoi que ce soit. A moins que denis génère des fichiers CT-RAW par rapport à des dumps flux ?!
En faite, c'est TRÈS simple a savoir si cela vient du lecteur comme tu le dit. il suffit de regarder sur ma page tout les dumps qui ont ce genre de 'signature' et regarder d'où vient le dump (on peu faire aussi l’inverse).
Si tout les dumps avec décalage viennent de la même personne alors effectivement, on peu penser à un problème sur le lecteur. Perso, je pense aussi plus à un 'probleme' de dump qu'une volonté propre de protection/décalage. mais... pas sur.
Denis, si tu as noté la provenance de chaque dump, peux tu regarder dans ce sens les jeux cité juste au dessus.
Jerso je me suis amusé a dumper une disquette normalement et généré une diskview du dump puis re-fait la même manip en posant légèrement le doigt sur le disque plastique en dessous qui effectue la rotation du disque BREF, j'ai fait varié la vitesse de rotation à l’arrache. Effectivement ca donne des 'pistes' décalé. Le décalage peu venir d'une variation de vitesse de rotation du disque que ce soit a cause d'une courroie ou d'un moteur vieillissant.
Inscription : 20 Août 2013, 18:03 Message(s) : 258
Giants a écrit :
>Ça ressemble à un problème d'identification par le soft de création d'ipf. hEUUU? on parle pas d'IPF la, on parle de format CTR. Les fichier Ct-raw sont directement crées par le logiciel en ligne de commande à savoir DTC.exe, y'a pas d’interprétation de quoi que ce soit. A moins que Denis génère des fichiers CT-RAW par rapport à des dumps flux ?!
Je part de cette hypothèse. Les CTR/IPF en retour de stream sont bien plus propre que les stream eux-mêmes. Les variations de vitesse on été 'normalisée'. C'est tres visible avec Aufit au niveau de l'histogramme et de la PLL. Et c'est ce qu'on attend de l'outil de la SPS, nettoyer le flux des variations due au lecteur (vitesse de rotation, disperssion des transition due a la faiblesse du signal ...).
Giants a écrit :
En faite, c'est TRÈS simple a savoir si cela vient du lecteur comme tu le dit. il suffit de regarder sur ma page tout les dumps qui ont ce genre de 'signature' et regarder d'où vient le dump (on peu faire aussi l’inverse).
C'est l'idée. Si les dumps exotique proviennent en grande majorité du mème lecteur, il faut essayer de comprendre pourquoi. Dans le lot je n'avais que Gremlins 2 pour comparer.
Giants a écrit :
Le décalage peu venir d'une variation de vitesse de rotation du disque que ce soit a cause d'une courroie ou d'un moteur vieillissant.
La crasse sur le disque fait aussi son effet sur la vitesse de rotation.
Inscription : 21 Août 2008, 16:03 Message(s) : 342
Pour moi, les CT-RAW dispo ici sur CPC-Rulez sont des fichiers crée directement depuis la disquette Ils ne sont traité par aucun soft. Peu importe que ce soit Denis ou quelqu'un d'autre qui les as dumpé, la procédure à été : DISK REEL->CT-RAW
Effectivement, si ce n'est pas le cas...Ca met toujours un doute. Les fichiers CT-RAW que tu files ici denis sont crée comment ? Et si c'est traité par un soft (quelconque, peu importe on sans fiche), est t'il possible dans ce cas d'avoir le 'source' du Dump Réel effectuée (donc flux) Histoire de passer le fichier Flux et CT-Raw à la moulinette du soft de jeff et voir si les diskviews sont identique. Elles devraient (a peu de chose pret bien sur).
Gerald, concernant la version que tu as du jeu en question non décallé. Elle vient d'où cette version ? Si c'est toi qui l'a dumpé, comment l'as tu dumpé (soft et format de sortie), bref, l'a tu traité ou pas logiciellement. et bien sur, la version que tu as, peux tu la passer sur le soft de jeff et voir si le CRC32 est le même. Comme on ne sais pas exactement comment jeff crée ce CRC, c'est juste pour voir 'au cas ou', même si peu probable, c'est le même crc que l'image ICI. Théoriquement.... c'est un cumule de crc de chaque track si je me rappel bien ce que m'a dit jeff
Inscription : 29 Août 2007, 12:04 Message(s) : 2009 Localisation : seine et marne 77
Gerald a écrit :
dlfrsilver a écrit :
En fait, compte tenu de ce que montre le graph, avec la piste 0 positionnée d'une certaine façon, et les autres avec comme une sorte de décalage régulier, c'est normal pour moi.
Dans les images de CTraw générées par Giants, on peut voir que certains disques ont des pistes bien calées les unes par rapport aux autres.
J'en déduis donc que le pattern vient de la machine qui a tracé le disque.
Si c'est la machine qui a tracé le disque, j'ai donc une version différente, les secteurs sont bien alignés. J'ai plutôt l'impression que c'est le lecteur qui a lut les disques qui cause ces différences. Il est possible de savoir qui a dumpé quoi ? Si le lecteur a un probleme, ca se verra sur les dump fait avec.
Tout les dumps sont générés depuis le même lecteur 3 pouces. Mon lecteur 3 pouces a été nettoyé, relubrifié, et la courroie a été changée (achetée à Dataserve en angleterre).
Comme je le disais, la gueule des dumps dépend de la machine qui les a tracé, c'est comme pour la forme du signal analogique présent sur les cassettes. Cette forme n'est pas exactement reproductible, car c'est la machine qui grave sur bande qui donne cette forme bien spécifique et qui différe sur la plupart des cassettes.
Les fichiers CT-raw sont issus des dumps en flux des jeux. une fois dumpée, les disquettes sont rangées et je ne me sers plus que des images en flux de ces dernières.
Comme le dit gérard, les CTR/IPFs sont propres et pour cause, il y a tout un tas de cochonnerie, de parasites, d'erreurs même qu'il convient de discarder pour ne garder que le meilleur afin d'obtenir un master propre et indemne d'erreur.
Les dumps en flux sont simplement une base de travail qui a besoin d'être traitée (comprendre affinée et débarrassée de ses scories), pour n'en garder que la quintessence.
Comme l'indique aussi Giants, certains jeux seulement ont ces décalages, mais pas tous, alors que le lecteur est le même.
Pour rebondir sur ce que disait Gerard, si le lecteur était en cause, le décalage serait visible sur tout les dumps sans exception. Hors ce n'est pas le cas
Gerard, si tu me lis, envoie-moi ton dump de gremlins 2
_________________ SPS Community Expert (SPS CE) / SPS France
Inscription : 21 Août 2008, 16:03 Message(s) : 342
Après discu avec Denis.
Il genere une image Flux puis une image CT-Raw avec le meme soft (a savoir DTC) y'a pas de conv, de traitement de quoi que ce soit, juste le format de sortie qui change.
Et au vue de ce qu'il a dit, ca ne vient pas de son lecteur (sinon ca le ferais sur tout les dumps) Ca ne vient pas d'une conv car il n'y a pas de conv, c'est du DISK->Fichier Ct-Raw Que la disquette soit sale, a connaitre denis, je dirais IMPOSSIBLE (on l'appel Mr propre)
Donc ca doit venir des jeux.
A mon avis gégé (si tu me permet), tu doit avoir une autre version du jeu.
LAST TIME : Mise à jour de mon script de detection de protection sur CPC : http://sasfepu78.fr/cgi-bin/RechercheProtection.cgi Les informations de DATE et de COPYRIGHT ont été ajouté. exemple de recherche : Billy_La_Banlieue
Code :
================================================================================================================================================================================================== 1986 SectorErased loriciels Billy La Banlieue (F) (1986) [Original] (GAPS) 1987 SectorErased loriciels Billy La Banlieue 2 (F) (1987) [Original] (GAPS) 1987 SectorSize3 loriciels Billy La Banlieue 2 (F) (1987) [Original] (GAPS) ==================================================================================================================================================================================================
Dernière édition par Giants le 16 Mars 2016, 17:26, édité 2 fois.
Inscription : 21 Août 2008, 16:03 Message(s) : 342
Je prends pour référence un autre jeux présentant le 'décalage' que l'on peu voir sur les diskview en l’occurrence : Carlos Sainz Campeonato Del Mondo_Zigurat[CPC]_not duplicated
L'image disk en question possède donc aussi ce décalage
Pièce jointe :
zikzag.jpg
L'image en question fonctionne sur l'emulateur ShugarBox pour info Après analyse du flux kryo (que denis m'a filé) par jeff (auteur de la hxc)) il semblerait que cela viennent du Dump et non du master En effet, le RPM varie de 294RPM à 298RPM selon la piste.
Si comme denis l'a signalé, le jeu a été dumpé sur le même lecteur 3" que les autres jeux qu'il a dumpé, cela ne peu venir du moteur du lecteur 3" Par contre, peu être qu'a ce moment du dump, la courroie n'avait pas été encore changé.
Ou encore, tout simplement, que le probleme viennent plutôt de la disquette elle même. Soit disquette pas complétement nettoyé ou tout simplement, disk de mauvaise qualité (tourne mal). (moi je penche pour ca)
vue que le Bitrate varie énormément lors du DUMP, cela ne peu pas venir du master mais bien un probleme physique. En effet, peu importe les données écrites sur le disk, cela n'influence pas le RPM (du moins, pas dans ses proportions)
D'un autre coté... ce décalage semble ne pas poser de problème réel lors de la lecture du disk par nos emulateurs. De plus, une lecture et export avec hxcFloppyEmulator enleve le décallage, peu etre une solution pour eviter de re-dumper ?!
Vous n’êtes pas autorisé(e) à consulter les fichiers insérés à ce message.
Inscription : 29 Août 2007, 12:04 Message(s) : 2009 Localisation : seine et marne 77
Citer :
L'image en question fonctionne sur l'emulateur ShugarBox pour info
Oui heureusement
Citer :
Après analyse du flux kryo (que denis m'a filé) par jeff (auteur de la hxc)) il semblerait que cela viennent du Dump et non du master En effet, le RPM varie de 294RPM à 298RPM selon la piste.
Que dire.....
Citer :
Si comme denis l'a signalé, le jeu a été dumpé sur le même lecteur 3" que les autres jeux qu'il a dumpé, cela ne peu venir du moteur du lecteur 3" Par contre, peu être qu'a ce moment du dump, la courroie n'avait pas été encore changé.
comme dit, ça ne peut pas venir du lecteur, puisque j'utilise toujours le même pour dumper. Hors, les patterns varient suivant la disquette lue.
Ma courroie est changée depuis un sacré bon moment.
Citer :
Ou encore, tout simplement, que le probleme viennent plutôt de la disquette elle même. Soit disquette pas complétement nettoyé ou tout simplement, disk de mauvaise qualité (tourne mal). (moi je penche pour ca)
peut-être que ça vient de la disquette, je sais qu'elle n'était pas très fraîche.
Citer :
vue que le Bitrate varie énormément lors du DUMP, cela ne peu pas venir du master mais bien un probleme physique. En effet, peu importe les données écrites sur le disk, cela n'influence pas le RPM (du moins, pas dans ses proportions)
C'est possible.
Citer :
D'un autre coté... ce décalage semble ne pas poser de problème réel lors de la lecture du disk par nos emulateurs. De plus, une lecture et export avec hxcFloppyEmulator enleve le décallage, peu etre une solution pour eviter de re-dumper ?!
Oui mais en l'occurence, comme la lecture et export rend le dump ultra "propre et lisse", y compris au niveau du signal, mes collègues n'en voudront pas. Je veux pas m'entendre dire que c'est un dump falsifié/grugé, ça porterait un coup à mon crédit.
_________________ SPS Community Expert (SPS CE) / SPS France
Utilisateur(s) parcourant ce forum : Aucun utilisateur inscrit et 15 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
