Apres le dump d'un GDrom, que faire ??

[-FamilyGuy-]

c'est pour cela que c'est plus dure les jeux CDDA car on a pas trouver d'autre moyen que de graver les CDDA avant , il ce trouve dans dans la session 1 ce qui veut dire que le inférieur au LBA 45000 donc resultat , il faut modifier tout les fichiers voulant lire la piste audio.

 

arf en faite on arrive pas a graver les pistes audio aprés le debut de la session 2 puis de repartir sur un session de data.

 

il et peut etre possible de graver en multissesion la Track03 , creer une nouvelle session audio, puis creer une nouvelle session data !!

 

quelqu'un aurait-il essayer ??

 

Edit :

 

Aprés renseignement, il est impossible de graver un CD en mode mixte avec de la Data => AUDIO => Data, il faut obligatoirement l'audio d'abord puis ensuite les datas

 

En fait les tracks cdda peuvent finir après 45000, mais on doit quand-même tout hacker d'après le LBA même s,il est plus grand que 45000, c'ets seulement s'il est EXACTEMENT 45000 qu'aucun hack relatif au LBA n'est nécessaire.

 

Plusieur façons fonctionnerais, mais le plus simple, bien que compliqué, est toujours cette façon si selon moi. Il est possible en fait de recréer la structure d'un gd-rom:

SESSION1: track01.bin track02.wav (allongé pour se rendre a 45000)

SESSION2: track03.bin (toc) trackXXX.wav trackYYY.bin (donnés).

 

Mais pour un backup, on perd de l'espaces inutile, car ainsi on ne peut lancer cdda.exe (qui met la 1ere track cdda comme la première du cd et non la 4ieme comme sur un gd-rom) et on doit donc mettre une tracko1.bin et une trak02.wav (dummy) en 1ere session. Sans ouvblier que couper une track en deux comme sur un gd-rom est assez compliqué.

 

FG

[Hiei-]

ah ok en faite le hack du IP.bin vas forcer le lecteur GD a rester en lecture CD ok .

 

je penser qu'il falais mettre le LBA de Start dans le IP.bin aussi.

 

Plus précisemment, si je ne dis pas de bétises, il force simplement le mode GD-ROM (car par défaut, quand un CD-ROM est inséré dans la DreamCast, elle passe en mode CD-Audio).

 

C'est d'ailleurs de là que vient la faille pour lire les copies.

[Invité remyar]

comment on peut facilement inclure la piste .raw facielement dans l'iso générar par ton .bat ???

 

car en faite j'aimerai refaire cette structure

 

la SESSION1 : peut importe 65Mo

SESSION2 45000: track03.iso (toc) track04.wav track05.iso (donnés).

 

pour l'instant peu importe si le fichier final et enorme mais si sa fonctionne comme sa cela voudrais dire que la pluspart des jeux pourrais fonctionner en CDDA en respectant cette structure sans grande modification ( certe sa ne rentre pas sur un CD mais bon )

Modifié le 25 mars 2009 par remyar

[-FamilyGuy-]

comment on peut facilement inclure la piste .raw facielement dans l'iso générar par ton .bat ???

 

car en faite j'aimerai refaire cette structure

 

la SESSION1 : peut importe 65Mo

SESSION2 45000: track03.iso (toc) track04.wav track05.iso (donnés).

 

pour l'instant peu importe si le fichier final et enorme mais si sa fonctionne comme sa cela voudrais dire que la pluspart des jeux pourrais fonctionner en CDDA en respectant cette structure sans grande modification ( certe sa ne rentre pas sur un CD mais bon )

 

Ça serait faisable en 2352 bytes par sector, en mettant un dummy a la track03 au moins aussi grand que les tracks audio, en insérant les tracks audio à la main et en rebâtissant la TOC par rapport à la nouvelle structure. Mon pack ne fonctionnera pas avec cela, car le programme NRGHEADER.EXE (fait par Indiket, gracias mi amigo) ne supporte que les images en 2048bytes/sector selon une structure de deux session data, la 2ieme étant a 45000. Le programme change ensuite le nrgheader pour correspondre avec la fin de la 2ieme session.

 

Bref je ne m'y colle pas, c'est mieux tant qu'à faire d'utiliser la bonne vieille (10ans) technique avec cdrecord et mkisofs.

 

FG

[Invité remyar]

le truc a savoir aussi c'est comment les jeux appelle les tracks audio , par LBA ou bien tout autrement ??

 

la technique du dummy j'y avait penser mais apres reste a savoir coment intéragir directement dans le iso.

 

pour le nrgheader, on est obliger de le mettre car du coup on ce retrouve avec un .nrg si on s'arrete au merge des iso sa ne marche pas ??

 

franchement familyguy je suis vraiment désoler de poser toute ces questions, peut etre que c'est techniques ont déja était essayer mais comme tu peut le voir sa m'interesse fortement de savoir vraiment coment sa marche lol !

[-FamilyGuy-]

le truc a savoir aussi c'est comment les jeux appelle les tracks audio , par LBA ou bien tout autrement ??

 

la technique du dummy j'y avait penser mais apres reste a savoir coment intéragir directement dans le iso.

 

pour le nrgheader, on est obliger de le mettre car du coup on ce retrouve avec un .nrg si on s'arrete au merge des iso sa ne marche pas ??

 

franchement familyguy je suis vraiment désoler de poser toute ces questions, peut etre que c'est techniques ont déja était essayer mais comme tu peut le voir sa m'interesse fortement de savoir vraiment coment sa marche lol !

 

La DC load les tracks cdda par numéro de track, cdda.exe met la 1ere track à loader comme étant 1 plutôt que 4 en fait.

 

Sinon tu peux interragir avec le iso vie un éditeur hexadécimal.

 

TU peux utiliser mkisofs SANS monpack pour faire des iso/raw/wav des deux sessions que tu pourrais graver.

 

FG

[Invité remyar]

ok c'est pour sa que meme si l'on grave la piste CDDA en premier, la dreamcast sait quand meme la trouver mais elle ce base par rapport a quel TOC ??

 

la sa commence a ete compliquer pour moi, jusqu'a maintenant j'ai compri comment fonctionne la partie GD mais cette fichu CDDA pose vraiment des problémes.

 

jusque la je comprend comprend la SESSION1 qui d'origine fait environ 65Mo c'est la session low density ( posséde le message audio " inserez ce disque dans une dreamcast" )et ce termine legerement avant le LBA 45000 a partir du LBA45000, le IP.BIN hacker permettant de rester en mode lecture CD et contenant le nom du jeux etc .... a partir de la , si j'ai compri, la dreamcast travaille avec le systéme de fichier ce qui veut dire que l'on peut les mettres n'importe où sur le CD sans ce soucier de leur LBA tout cela fonctionne pour un jeux sans CDDA et serait donc compatible avec une grande majorité de jeu c'est bien sa ??

 

maintenant pour plus de faciliter, on applique la meme technique avec un jeu CDDA mais la le probléme c'est que le jeu appelle et charge la Track01 mais comment la DC sait où cette piste audio est ??

 

vu qu'il et facile de graver une piste audio avec CDRecord ( façon old school ) , cela voudrais dire que l'on aurais 65Mo de donnée audio si on veut garder le LBA a 45000

 

dans ce cas la on ce retrouve avec la structure suivante

 

jeux CDDA

=> SESSION1 : Audio ( lba 0 ) => 65Mo ( lba 45000 )

=> SESSION2 : Data ( lba 45000 ) => end

 

jeux DATA

=> SESSION1 : dummy ( lba 0 ) => 65Mo ( lba 45000 )

=> SESSION2 : Data ( lba 45000 ) => end

 

mais on en revient a la meme question comment sait la dreamcast où sont les pistes audio car théoriquement elles doivent etre dans la SESSION2 ??

Modifié le 25 mars 2009 par remyar

[-FamilyGuy-]

ok c'est pour sa que meme si l'on grave la piste CDDA en premier, la dreamcast sait quand meme la trouver mais elle ce base par rapport a quel TOC ??

 

la sa commence a ete compliquer pour moi, jusqu'a maintenant j'ai compri comment fonctionne la partie GD mais cette fichu CDDA pose vraiment des problémes.

 

jusque la je comprend comprend la SESSION1 qui d'origine fait environ 65Mo c'est la session low density ( posséde le message audio " inserez ce disque dans une dreamcast" )et ce termine legerement avant le LBA 45000 a partir du LBA45000, le IP.BIN hacker permettant de rester en mode lecture CD et contenant le nom du jeux etc .... a partir de la , si j'ai compri, la dreamcast travaille avec le systéme de fichier ce qui veut dire que l'on peut les mettres n'importe où sur le CD sans ce soucier de leur LBA tout cela fonctionne pour un jeux sans CDDA et serait donc compatible avec une grande majorité de jeu c'est bien sa ??

 

maintenant pour plus de faciliter, on applique la meme technique avec un jeu CDDA mais la le probléme c'est que le jeu appelle et charge la Track01 mais comment la DC sait où cette piste audio est ??

 

vu qu'il et facile de graver une piste audio avec CDRecord ( façon old school ) , cela voudrais dire que l'on aurais 65Mo de donnée audio si on veut garder le LBA a 45000

 

dans ce cas la on ce retrouve avec la structure suivante

 

jeux CDDA

=> SESSION1 : Audio ( lba 0 ) => 65Mo ( lba 45000 )

=> SESSION2 : Data ( lba 45000 ) => end

 

jeux DATA

=> SESSION1 : dummy ( lba 0 ) => 65Mo ( lba 45000 )

=> SESSION2 : Data ( lba 45000 ) => end

 

mais on en revient a la meme question comment sait la dreamcast où sont les pistes audio car théoriquement elles doivent etre dans la SESSION2 ??

 

Normalement le DC ne se fi qu'au numéro de la piste dans la TOC [pour un gd-rom => track01 = data ; track02=audio ; track03=data ; Si il y a des tracks audio: track04=audio ; track(n-1)=audio ; track(n)=data]

D'où les numéros de tracks qui se suivent d'une session à l'autre quand tu fais un rip. Ex: track03.bin ou track03.iso => 1ere track 2ieme session.

 

De plus les fichiers de la première track du gd-rom (low density) sont totalement inutiles pour les backups.

 

Donc, le DC load la track04 en tant que 1ere piste cdda. la vieille technique de selfboot mettait 3 pistes de 3sec dummy au début du CD pour faire fonctionner les tracks cdda, tandis que celle, à peine plus récente, que je t'ai décrite utilise le programme cdda.exe qui réfère la première track CDDA comme étant la track01 simplement: plus besoin des 3 tracks dummy.

 

TU semble un peu confus par rapport au LBA 45000, si je met tout mes jeux en 45000 c'est simplement car c'est moins compliqué (pour ShenmueII entre autre) et la plupart du temps aucun hack n'est nécessaire sur les bins du jeux. Seulement il est possible de faire un backup à n'importe quel LBA voulu, en hackant les exécutables (bins) d'après ce LBA. Ainsi si tu as des tracks de data qui font que ta 2ieme session est à 55000LBA, tu peux simplement te faire une session data a 55000 en hackant les bins selon ce LBA. Cela va de même pour des valeurs plus petite que 45000. (en fait n'importe quel valeur).

 

Mettre un gros dummy audio pour que les donnés du jeux soient à 45000LBA est la première technique de selfboot 45000LBA (soit cdda/data); la technique utilisé dans mon pack (soit data/data + fusion des TOC) quant à elle permet d'utiliser les 65MB perdu avec la première méthode.

 

Il est à noter qu'on ne peut pas mettre les donnés n'importe où, il est vrai qu'il n'est pas nécessaire qu'ils soient dans la track à 45000LBA, mais ils doivent y être inscrit dans la TOC. Ainsi mes backups de ShenmueII contiennent des fichiers accessible à partir de la TOC de la Session2, mais qui sont physiquement dans la Session1. ouvre cette image avec IsoBuster et tu verra, dans la session à 45000LBA des fichiers à des lba de 10000.

 

J'espère avoir été plus clair

 

FG

Modifié le 26 mars 2009 par -=FamilyGuy=-

[Invité remyar]

oui j'avais bien compri cela mais si je desire rester a 45000 dans n'importe quel cas c'est a cause des dreamcast non-Mil et de certain jeux non proteger ce qui évite de ce casser la tete. et sa fonctionnerai avec pas mal de jeu.

 

j'avais remarquer avec ton .bat que certain de mes fichier était en dessous de 45000 du fait que je les avais mis dans le dossier data1 pour faire les 65Mo du coup cela voudrais dire que j'ai utiliser les 65Mo pour mettre certaine donnée qui ne sont plus physiquement sur la session 2 ?

 

encore une question, la toc générale du GD ce trouve en début du GD dans la partie lowdensity ??

 

donc en faite il n'y a pas grand chose a faire pour l'audio tu grave une premiére session en audio ( sa rempli la TOC du CD ) puis tu grave les datas et sui vienne s'incrire a leur tours dans la toc . ( escuse mou mais je dit sa mais je ne connait rien a la toc d'un CD je vais aller chercher quelque infos )

Modifié le 26 mars 2009 par remyar

[-FamilyGuy-]

En fait c'est possilble un data/data cdda mais c'ets vraiment compliqué pour rien.

 

La section low density ne contient que la TOC low density et est faite comme si il n'y avait pas de 2ieme session (protection de base), la TOC de la section high density elle, contient sa propre TOC (commençant à la track03). Le ip.bin contient aussi la TOC high density et peut même "overwriter" celle de la section high density avec la sienne (protection supplémentaire, asez rare

 

FG

 

[EDIT]

 

j'avais remarquer avec ton .bat que certain de mes fichier était en dessous de 45000 du fait que je les avais mis dans le dossier data1 pour faire les 65Mo du coup cela voudrais dire que j'ai utiliser les 65Mo pour mettre certaine donnée qui ne sont plus physiquement sur la session 2 ?

 

Oui, en fait le dossier data1 permet simplement d'utiliser l'espace perdu, pour pousser la 2ieme session à un LBA de 45000, pour y mettre des fichiers qui seront ensuite inscrit dans la 2ieme session. Ainsi, le DC va lire dans la 1ere track de la 2ieme session (la seule track d'ou on peut loader des fichiers [via la toc]) Que il y a un fichier nommé XYZ à un LBA de 10000 apr exemple.

Ce fichier est donc "LOGIQUEMENT" dans la 1ere track de la 2ieme session ; mais "PHYSIQUEMENT" dans la 1ere track de la 1ere session.

 

SI ton jeux rentre au complet dans la 2ieme session il n'ets pas nécessaire de mettre des fichiers ans le dossier data1, l'image data1.iso se pad automatiquement à 69120000 bytes grace au programme fill.exe (Par Neoblast et indiket, gracias los amigos!), soit la grandeur nécessaire à une seconde sesison à 45000LBA. Ainsi la première session sera completement vide et servira de genre de dummy, ce qui est bon pour accelérer les loadings.

 

FG

Modifié le 26 mars 2009 par -=FamilyGuy=-