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

[kogami-san]

Tien le voilà dans un pack

MEGAUPLOAD - The leading online storage and file delivery service

ok merci bien !!

bon voici des news les amis.

alors j'ai reussi a faire mon cd selfboot avec cdda au lba45000.

pour cela la methode et similaire a la tienne -=familyGuy=- mais en faite j'intervien a la création de la deuxiéme session, c'est a dire que je saute la premiére session de 65Mo que je ne creer pas, je réalise la session deux j'obtien donc un data2.iso qui est une copie du dossier data. je ne fait aucun merge de l'iso1 , l'iso2 et le nrgheader je garde donc la data2.iso en brute sans la retoucher ( 0,45000 )

de la je prend lbacalc et je ragarde la valeur du lba qu'il em dit et je réalise un dummy de maniére a tomber pil poil au lba45000 de la je passe dans la moulinette de mfs4dc ou je sort mon selboot.mds de data2.iso + track04.raw + track04.raw+track04.raw+track04.raw + trackdummy

et voila je ressort donc avec les piste audio jusqu'au lba45000 puis passe en data a partir de 45000 donc toujours selfboot avec les track audio. pour l'instant j'ai mis 3 fois la track04.raw au debut c'est juste pour garder les 3 pistes dummy qui sont dans mon cas juste les track04.raw

malheureusement vu que la piste audio n'est pas jouer des le debut du jeu, je n'ai pu controler qu'elle soit bien lu mais wmp me la lie correctement .

vous en pensez quoi ???

de plus j'ai creer plein de bath pour réaliser cette opération presque automatique je remercie donc -=FamilyGuy=- pour le selfboot, Sizious pour son mds4dc ainsi que kogami et tous ceux qui ont essayer de m'aider.

de pplus le downsample audio des AFS est totalement automatique , il decompresse en adx, convertie en wav, downsample du wav , recompression du adx puis reforme le AFS !!!

jolie detterage de topic!!

donc si tu passes par la -=familyGuy=- j'aurais besoin d'un peu d'aide.

j'ai repri le rip de mon fameux ecco the dolphin car il y a un truc qui cloche , je ne suis pas bien sur d'avoir tout compri lol .

voici ce que j'ai fait pour le moment.

j'extrait mon track03.iso et track05.iso a 95792

j'ai tout sa dans le dossier data.

le track04.raw dans un dossier CDDA. je creer 3 track dummy de taille 1500000 octet chacune

j'ai donc track01.raw track02.raw track03.raw ( 3 * dummy ) track04.raw et un track0x.raw ( dummy ) pour arriver a mon LBA45000 a partir de la j'ai une zone contenant l'image de la track03.iso + track05.iso.

normalement la track04.raw devrait etre lue normalement meme si elle est inférieur au lba45000. c'est ce que tu m'avais expliqué.

maintenant dans le cas ou j'ai plein de track.raw est ce que je peut former mon cd de la meme maniére mais en ajoutant des pistes CDDA apres l'image de track03 et track10.iso par exemple c'est a dire que j'aurais sa !!

=> piste CDDA => 45000
=> piste data => xxxxx
=> piste CDDA => end

je redemande sa car je suis en train de faire un GUI pour extraire et formatter le mdf final car je me dit que dans la session un je ne pourrais jamais faire entré des jeux avec 10 pistes CDDA ( V Rally 2 )

merci a toi

[-=FamilyGuy=-]

En fait, il faut que les tracks audio soient dans la première session, ta track 1 pourrait être une track data fusionné avec une trac de deuxième session par contre. N'oublie pas d'utiliser CDDA.exe et DAHACK.exe si nécessaire pour les jeux CDDA.

Cheers!

FG

[edit]

Apres réflexion, si tu met la première track de la 2ieme session contenant la TOC des donnés ed la dernière track de la 2ieme session, et si tu insert des tracks audio ENTRE la TOC et les DONNÉ (comme sur un gd-rom avec du CDDA) ça pourrait fonctionner:

Donc: pour UNE track audio, schéma de concept:

Session1 (LBA=0)
Track01 (DUMMY)
Track02 (DUMMY)

Session2 (LBA=45000)
Track03 (DATA_2352) [TOC de track04]
Track04 (Audio)
Track05 (DATA_2352) [Donnés liés à la TOC dans la track02]

La track03 pourrait être fusionée à la track01 et/ou à la track02 pour mettre plus de donnés.

Pour créer les tracks 03 et 05 il faudrait calculer combien de place en 2352bytes/sectors tes tracks audio on besoin au minumum, puis créé une track (nommons la trackX) data en 2352bytes/sectors ave un fichier DUMMY au moins aussi gros que cette valeur (on peut penser à pousser les donnés au bout du disque aussi). Puis tu coupe la track X en trois partie, la TOC de la track(nommons la TrackXTOC), un gap dummy exactement aussi gros que les tracks audio (une fois gravées, en considérant le gap entre elles et les tracks data) et les donnés de la trackX(nommons la TrackXDATA). Ensuite tu grave ta premiere session. Puis tu grave ta deuxième session Come suit: TrackXTOC+TRACKS_AUDIO+TrackXDATA


Si tu veux faire les tracks de donnés en 2048bytes/sectors il te faudra calculer le nombres de SECTEURS nécessaires pour tes tracks audio, et convertir sa de 2352 à 2048 pour obtenir la taille de ton dumy.

Notons que le style de gravure, DAO ou SAO, modifie la gradeur de gap entre les tracks, si tu fait un MDF/MDS alors tu peu le choisir toi même je crois.

Bref c'est lourd comme manipulation mais ça devrait foncitonner, puisque c'est la structure même des réels gd-roms.

Le DC va lire les noms de fichiers dans la track03, aller les lire dans la track05 comme si c'était la track03 et lira les tracks audio selon leur ordre normal.

Bonne chance!

Cheers!

FG

Note: je crois que je mérite le prix pour l'édit le plus long comparativement au message d'origine...

voila on en arrive a refaire exactement la structure du GDRom ce qui m'interesse au final.

donc la question principale actuellement c'est comment séparer la toc des datas.

c'est sur qu'une fois cela fait, alors si l'on creer un dummy aussi gros que les track audio cela devrait marcher, comme ceci la track04.raw ce trouve toujours a sa place ainsi que toutes les tracks en faite.

Une fois extrait, on ce retrouve avec le ip.bin a hacker ( obligatoire , obliger de le hacker on ne peut pas ce passer de cette manip ) il suffirai de reccreur deux track .iso c'est a dire la toc d'un coter et les data de l'autre .

sa pourrait ce tenter tu pense pas ?? car en plus on pourrais gagner un peu de place en donwsamplant les track audio.

[-=FamilyGuy=-]

Envoyé par remyar

voila on en arrive a refaire exactement la structure du GDRom ce qui m'interesse au final.

donc la question principale actuellement c'est comment séparer la toc des datas.

c'est sur qu'une fois cela fait, alors si l'on creer un dummy aussi gros que les track audio cela devrait marcher, comme ceci la track04.raw ce trouve toujours a sa place ainsi que toutes les tracks en faite.

Une fois extrait, on ce retrouve avec le ip.bin a hacker ( obligatoire , obliger de le hacker on ne peut pas ce passer de cette manip ) il suffirai de reccreur deux track .iso c'est a dire la toc d'un coter et les data de l'autre .

sa pourrait ce tenter tu pense pas ?? car en plus on pourrais gagner un peu de place en donwsamplant les track audio.

Bien sur ça se ferait, je l'ai expliqué dans mon post précédent!

Tu met un dummy comme premier fichier dans la track de data, donc ta track data sera comme suis: TOC + DUMMY + DONNÉS

Ensuite tu "coupe" le dummy et tu te retrouve avec une track TOC et une track DONNÉS, tu peux graver les tracks audio entre les deux! (Qui doivent impérativement prendre EXACTEMENT la même place (taille en fait) que le DUMMY pour que les fichiers de la track donnés soient au même LBA que si tu n'avait jamais coupé la track originale.

Perso j'ai aps vrm de temps d'essayer sa puisque je vais à l'école amis sa devrait se faire sans trop de complications si tu grave dans un mode donné (DAO par exemple) car les GAPS entres tracks son déterminés (faudrait je fouille dans mes vieux outils pour trouver les valeurs exactes des gaps entre les différents types de tracks possibles, soit : data-data , data-audio , audio-audio et audio-data.

Note que les tracks 1 et 2 peuvent être de nimportequel type, et peuvent même contenir des donnés dans la TOC de la track03. (Cette track devient la TOC fusionné des tracks 1 et 5 par exemple. Il est bien sur plus évident de n'utiliser qu'une track de data en session1 fusionné à la tack03 et de mettre l'autre track en audio de 3secondes. On perd tout de même 3sec sur le disque de plus qu'avec la technique CDDA+data à nimportequel LBA, à moins de se faire un cdda.exe modifié qui load la 2e track comme la 3e en audio plutot que la 1ere comme le fait cdda.exe!

Cheers!

FG

je pense que je vais essayer avec mkisofs . on peut spécifier l'ordre des fichiers apparement et donc le mieux sa seraitde prendre lors de la réalisation des l'iso , les track.raw a la place de faire un gros fichier dummy . comme sa la place exacte des track.raw est déja reserver pourles inclure par la suite.

je regarde ce soir pour essayer d'integrer directement la .raw dans l'iso !!!

[-=FamilyGuy=-]

Envoyé par remyar

je pense que je vais essayer avec mkisofs . on peut spécifier l'ordre des fichiers apparement et donc le mieux sa seraitde prendre lors de la réalisation des l'iso , les track.raw a la place de faire un gros fichier dummy . comme sa la place exacte des track.raw est déja reserver pourles inclure par la suite.

je regarde ce soir pour essayer d'integrer directement la .raw dans l'iso !!!

Le problème c'ets que les tracs en raw sont en 2352 bytes/secteurs et les donnés, normalement en 2048 bytes par secteurs. De plus il y a un certain Espace de GAP (ou 0x00 si tu préfère) de 0 à 75 secteurs entre les tracks qui change selon le type de gravure (Disc At Once ou Session At Once) et les tracks de part et d'autres de celui-ci. Tu dois donc calculer le nombre de secteurs que tes tracks prendront et convertir sela en taille de donnés (Nb_secteurs*2352).

FG

me revoila aprés avoir fait plein d'essai et de malheur dans ma gravure d'iso lol

bon j'ai reussi une chose :

=> Session 1 LBA@0
Track01 => Audio
Track02 => Audio
=> Session 2 LBA@45000
Track03 => Data
Track04 => Piste CDDA du jeu

bon certe je n'ai pas séparer la toc des data mais certain dirons que ce n'est pas respecter la structure d'un GD rom mais le coup de séparer la toc des datas devient trop compliquer a réaliser les data ne sont pas a la fin du CD mais est ce vraiment utile ?? je ne pense pas mis a part certain dirons les temps de chargements. Moi ej vais dire autre chose, chaque fois que la dremacast veut lire un fichier, si la toc était séparer des datas , le bloc obtique fera tout plein d'aller retour entre la toc et les data pour lire les fichiers alors que la les datas sont inclu dans la toc ( ou inversement ) et donc le bloc fera moin de vas et vien !!

si je me trompe corriger moi !!!