En gros, c'est un cdi selfbootable à base de data/data (alternative à l'audio/data) mais avec une première piste en mode 2 afin de "gagner" des octets?
Par contre je ne comprend pas pourquoi ça ne marcherait pas avec CDI4DC. En binhackant ip.bin.1st_read.bin avec la valeur post piste audio de CDI4DC (qui doit etre 11702) puis en passant CDI4DC, ça devrait passer, non? (le risque étant que l'iso fasse plus que la taille d'un CDR).
Enfin, je sais pas, je trouve ça super tordu.
__________________
-|- edd -|-
Merci de ne pas m'envoyer de messages privés pour de
l'assistance, le forum est là pour ça...
En gros, c'est un cdi selfbootable à base de data/data (alternative à l'audio/data) mais avec une première piste en mode 2 afin de "gagner" des octets?
Par contre je ne comprend pas pourquoi ça ne marcherait pas avec CDI4DC. En binhackant ip.bin.1st_read.bin avec la valeur post piste audio de CDI4DC (qui doit etre 11702) puis en passant CDI4DC, ça devrait passer, non? (le risque étant que l'iso fasse plus que la taille d'un CDR).
Enfin, je sais pas, je trouve ça super tordu.
Tu as tous comprit _edd_ !
Pour ce qui est de binhacker le jeu … je sais pas c’est une entreprise périlleuse, as-tu des informations des valeurs a modifier ?
Ma procédure est, certes tordu, mais fonctionne et il serait possible d’ecrire un programme pour remplacer directement la deuxième piste de l’image original avec les source de cdi4dc .
J’ai réussi également a modifier les sous titres dans Shenmue 1 , j’ai appliquer une méthode quasi similaire, a la différence que le backup est un CDI selfbootable audio/data mais dont la valeur LBA est de 11700 au lieu de 11702 acceptable par cdi4dc .
_edd_ ! tu semble en connaître plus que moi sur cet valeur LBA . Sait tu comment la calculer ?
_edd_ ! tu semble en connaître plus que moi sur cet valeur LBA . Sait tu comment la calculer ?
J'ai retrouvé ça dans mon dossier search de cdi4dc... mais je ne sais plus à quoi ça correspond exactement (mouarf j'ai pas mis de commentaires... ) :
Code:
int main(int argc, char* argv[]) {
unsigned int datalength;
if (argc < 2) {
printf("syntax : gap [data sector length]\n");
return 1;
}
sscanf(argv[1], "%d", &datalength);
// LBA c'est aussi = (((M*60)+S)*75+F)-150
printf("Outer Lead Out : %d\n", ((11702 + datalength)) - 150);
return 0;
}
Sinon j'ai aussi un autre prog de "recherche" que j'avais fait mais là encore, pas de comms donc je ne sais plus à quoi ça correspond (je sais juste que je m'en servais pour calculer une valeur quelqu'onque à foutre dans l'header du CDI) :
Code:
/* Conversion function: from logical block adresses to minute,second,frame
*/
int lba_2_msf (long lba, int *m, int* s, int* f) {
#ifdef __follow_redbook__
if (lba >= -150 && lba < 405000) { /* lba <= 404849 */
#else
if (lba >= -150) {
#endif
lba += 150;
} else if (lba >= -45150 && lba <= -151) {
lba += 450150;
} else
return 1;
*m = lba / 60 / 75;
lba -= (*m)*60*75;
*s = lba / 75;
lba -= (*s)*75;
*f = lba;
return 0;
}
int msf_2_lba(int m, int s, int f) {
int lba;
lba = (((m * 60) + s) * 75 + f) - 150;
return lba;
}
int main(int argc, char* argv[]) {
unsigned int m, s, f, lba, sizeofdatatrack;
if (argc < 2) {
printf("syntax : lba <msinfo>\n");
return 1;
}
sscanf(argv[1], "%d", &lba);
lba_2_msf(lba, &m, &s, &f);
lba = msf_2_lba(m, s, f);
printf("MSINFO (LBA) : %d\n", lba);
printf("MSF : %02d:%02d:%02d\n", m, s, f);
//301 = nb secteurs track audio
//11702 = notre msinfo/lba pour commencer track02
// le 150 chai pas c'est comme ça
printf("Outer Lead Out : %d\n", ((301 + 11702 + (lba - 1))) - 150);
//outel lead out valeur donnée par pfctoc.dll de padus, ce calcul donne la m value
return 0;
}
Moi ce que je sais (et je ne sais pas grand chose ), c'est que si tu fais l'auto boot "normallement" et donc à base d'audio/data avec l'audio.raw communément utilisé, la fin de ta piste audio sera en 11702.
En conséquence, le couple ip.bin.1st_read.bin n'est plus en accord avec la position de la partie data. En utilisant tels quels les ip.bin/1st_read.bin du cdi d'ECH, ils indiquent un LBA de la partie data qui n'est pas le bon (puisque en refaisant le SB on est en 11702). Bon je m'embrouille, c'est pas bien clair.
La solution est simple (selon moi). En récupérant ça, dedans y'a un exe qui s'appelle binhack.exe.
Il suffit, avant de passer CDI4DC (avec la val 11702) de mettre l'ip.bin et le 1st_read.bin à coté de l'exe, de la lancer et de taper 1st_read.bin puis ip.bin puis 11702. Ensuite remettre le 1st_read.bin à sa place (dans le rep qui sert de base au futur CDI) et de lancer CDI4DC avec ce répertoire, notre ip.bin et la val 11702.
Le CDI fera peut-etre (surement compte tenu de la bidouille d'ECH) plus d'un CD 80min mais sous win ce n'est pas trop le pb pour l'instant.
Si ça marche, ça me parait + simple pour les tests.
Ensuite, évidement faudra procéder tel que tu le décris, L@_cible, afin que ça tienne sur un cd (mais sans passer par CDI4DC et en passant par la vieille méthode à base de cdrecord, on doit pouvoir reproduire ce qu'a fait ECH... enfin après faut voir comment tu préfères procéder).
Ouais je sais, je parle un peu dans le vague, je n'ai pas testé (pas trop le temps) mais à l'occaz je pourrai (il s'agit bien de refaire un CDI qui passe sous Chankast à partir des fichiers contenus dans le CD de la version d'ECH?).
__________________
-|- edd -|-
Merci de ne pas m'envoyer de messages privés pour de
l'assistance, le forum est là pour ça...
Petit update de ma part: J'ai encore des problèmes avec mon éditeur de sous-titres. Mais ça ne devrait pas être trop long à régler, sauf que là j'ai pas trop le temps. Peut-être en fin de semaine. Après cela il devrait être fonctionnel à 100%, avec secteurisation sur 2048 octets et pas de plantage in-game... normalement!
__________________ Recherchez sur le forum avant de poser des questions! Et je parles le français, pas le langage SMS... et vous?
Dernière modification par Manic ; 28/09/2006 à 00h32.
Petit update de ma part: J'ai encore des problèmes avec mon éditeur de sous-titres. Mais ça ne devrait pas être trop long à régler, sauf que là j'ai pas trop le temps. Peut-être en fin de semaine. Après cela il devrait être fonctionnel à 100%, avec secteurisation sur 2048 octets et pas de plantage in-game... normalement!
Ok donc tu as réussi à t'en sortir ? C'est cool
Citation:
Envoyé par _edd_
Ouais je sais, je parle un peu dans le vague, je n'ai pas testé (pas trop le temps) mais à l'occaz je pourrai (il s'agit bien de refaire un CDI qui passe sous Chankast à partir des fichiers contenus dans le CD de la version d'ECH?).
Seulement quelques problèmes avec les blocs de 2048 octets... pour une raison que j'ignore, ils ne sont pas créer correctement. Sinon, tout fonctionne à peu près comme il faut.
__________________ Recherchez sur le forum avant de poser des questions! Et je parles le français, pas le langage SMS... et vous?
Oh, attend! Je penses bien avoir réglé mon problème! Je calculais mal la fin du bloc de 2048 octets par rapport à la position actuelle dans le nouveau fichier srf. Mais je dois tester sur d'autres fichiers.
Edit: j'ai tester sur d'autres fichiers et ça semble être correct. Et j'ai tester sur un fichier qui faisait planter le jeu et maintenant il n'y a plus aucun problème. Edit #2: L@Cible, comme tu te posais la question quelques pages auparavant, oui on peut changer les sous-titres de bloc. le fichier idx fait le travail d'indiquer la bonne position dans le srf.
__________________ Recherchez sur le forum avant de poser des questions! Et je parles le français, pas le langage SMS... et vous?
Dernière modification par Manic ; 29/09/2006 à 01h06.
Bon, j'ai recommencer un peu la traduction... à partir de zéro. Mais qu'est-ce que ça peut être chiant de traduire hors contexte. Mais bon, c'est la vie...
__________________ Recherchez sur le forum avant de poser des questions! Et je parles le français, pas le langage SMS... et vous?
) :
), c'est que si tu fais l'auto boot "normallement" et donc à base d'audio/data avec l'audio.raw communément utilisé, la fin de ta piste audio sera en 11702.
Mode linéaire
