Citation:
Envoyé par 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 ??
|
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