Aller au contenu
  • Contributeurs populaires

    Personne n’a encore reçu de point de réputation cette semaine.

  • Statistiques des membres

    23 028
    Total des membres
    1 033
    Maximum en ligne
    Subaru
    Membre le plus récent
    Subaru
    Inscription
  • En ligne récemment   0 membre est en ligne

    Aucun utilisateur enregistré regarde cette page.

-FamilyGuy-

Membres Enregistrés
  • Compteur de contenus

    321
  • Inscription

Tout ce qui a été posté par -FamilyGuy-

  1. Kogami tu pourrais pas garder 14khz mais changer le BAP seulement pour sauver 10mo ? moi J'ai aps le temps de tester. Et puis c'est quoi les Parties 1, 2 et 3 ?? FG
  2. Tente ce que tu veux, moi je teste! @Kogami: Met le "word size" à 255 et le "compression type" à ultra ou (mpass à 4) pour compresser mieux les GZ. PS: Je vais bientôt plancher sur une version 99min le plus parfait possible bientôt, pour mon usage personnel (je viens de m'acheter des CDr 99min). Je vous dirai si je trouve une astuce en travaillant sur ce disque! FG
  3. Note: je sais pas comment ut as ré-encoder les .gz, mais certains ne contiennt pas un fichier qui porte le même nom que le gz ... Je m'explique, VM_A33.GZ contient un fichier nommé A33 ; alors soit sur qu'il est recompresser en tant que VM_A33.GZ et non A33.GZ. Dans le dernier cas, tu perd de la place plutôt qu'en gagner. Avec le fqripper à Sizious, il pourrait être posible de sauver quelque kB de plus dans FREE0X.AFS ; Dans le Humans.afs de Shenmue1 j'avais sauvé 1.1MB en utilisant sa version BETA. Sinon downsamplé 10MB sur 300+, ça devrait pas trop parraitre! FG
  4. J'ai fait le ménage dans mes pms tu peux maintenant m'envoyer des messages! TU peux aussi écraser les fichiers du dossier SPRITE avec ceux du dossier FRENCH (les 50 seront écrasés) ce qui remplacera les menus anglais par les français et sauvera encore 3MB environ. De plus tu peux ré-encoder chaque GZ avec 7-zip pour sauver quelques centaines de Ko. Si tu veux mon pack selfboot aussi il sauve beaucuop de temps quand tu fais des test sur des isos, tu modifie, lance le batch file, mount dans deamon, et test dns nullDC duplicates once et sort inclus Les afs que tu peux ''massacrer'' un peu plus sont les 0120.afs et les 0140XXX.afs (ou XXX=variable), ce sont des minigames etc.. FG
  5. Kogami, remplace les fichiers German et Spanish (les 50 fichiers du dossier) par ceux de French, avec -duplicates-once il serton écrit sur le même secteur (pas d'espace de plus) et les consoles avec le bios en espagnol et allemand pourront jouer au jeu avec les menus en francais. C'est ce que j'ai fait sur ma release. FG
  6. Plutôt 22Mo pour el multisession (45000-33750 = 11250 ; 11250*2 = 22500ko) Attendez, p-e que le truc a Siz va sauver quelques MB dans les afs (subtiltes inutilisés) Et vous pouvez ré-encoder les fichier GZ de plus de 2ko avec 7-zip pour sauver environ 1MB au total pour toutes les langues et le dossier SPRITE (losslessly). @Kogami ; Non, le son est bien plus clair sur une Vrai DC. Par contre c'est sur que la qulaité sonore du CD2 est la moins bonne, mais le but était de rentrer le jeux dans 80min (Vérifie tes PM) FG [EDIT] ya aussi tv-check.spr que j'ai réduit du quart de la taille (640ko plutot que 2560) en réduisant la taille des images de moitié (superficies du quart), je peux envoyer ce SPR à MagicSeb ou Kogami-san si vous voulez, je en crois même pas qu'il soit utilisé dans le jeux. Et pour sauver 18mo ; y'a quà prendre les afs des mini-jeux, des voyantes etc. et en réencoder les afs avec un sample rate d'environ 10khz et un fg.bap aps trop bon. Apres y,aura presque plus rien a diminuer. FG
  7. Lol, gars de la famille ... Ouais, mon pack ahx était à 10050 parce que je faisait du 80min. Pense a jouer avec le FG.BAP aussi, des veleurs comme 5 au début et quelques 0 à la fin (graduation entre els deux) donne une bonne qualité de compression, amis prend un peu plus de place. FG
  8. Pour ceux qui veulent savoir, la version 80min est finie, une release en englais est déjà faite sur Underground-Gamer (ShenmueII FullSpeech Edition). Étant donné la nature "80min" de cette version, il est certain que "ça crachote" comme le dis si bien MagicSeb. Cependant les voix rauques ne sont pas trop dérangeantes et je trouve qu'on s'y habitue bien vite, c'est quand même mieux que des conversations entre muets . Bref, on ne peut pas vraiment faire mieux en gardant tout les speech en 80min. MagicSeb, avec les outils que je lui ai remis, devrait être en mesure de faire une release de toute première qualité sur 99min. @MagicSeb: Je ne crois pas que la DC ait des problèmes avec les cd de 98+min, car les gd-rom sont 120min (110 pour la session2) et que j'ai lis quelquepart que les cd en gigarec de 110 minutes fonctionnait à merveille. Cheers, FG
  9. -FamilyGuy-

    adapatateur SD !!!

    L'ingénieur derriere tout ça est japonais ; C'est JJ1ODM. Ils sont encore plus fort les Japonais! PS: J'ai testé le SD-loader de JJ1oDM pour alncer des bin/elf et ça marche très bien! FG
  10. Mon ami tu ne te simplifie pas la vie du tout! :reflexiomo6: D'après ce que tu m'as dit: binhack + (p-e) dahack et tout fonctionne nickel. Merci d'avoir testé mon nouveau bat. FG
  11. Peu importe le LBA de la deuxième session (a part 45000) tu DOIS lancer binhack sur les executables avec la bonne valeur de LBA, celle que cdrecord -dev=X,X,X -msinfo te sort (celui des deux chiffre qui n'est pas un zéro). Après vérification, il semble que BINHACK et dahack sur le 0.bin soient nécessaires. Ça n'a aucune importance si tu arrive avant ou après 45000LBA en CDDA/DATA. De plus pour sauver de l'espace, tes trois premières tracks peuvent être 3secondes de silence (soit 705 600 octects). FG
  12. Hey puisuqe tu travaille sur des dumps assez différents, pourrait tu tester ce nouveau batch file pour moi: @echo OFF title=FamilyGuy's SelfBootDATA Pack! - Image2Data v1.1 ECHO. ECHO This bat files will extract the data from a multi-track ECHO game to the data folder. It works for both ISO and BIN ECHO files! In the latter case, the tracks will be converted ECHO into iso. You'll have the choice to keep them or not. ECHO. ECHO It will also place the ip.bin in the root folder of the pack. ECHO You could then run SELFBOOT.bat to make a selfboot backup ! ECHO. ECHO For 3track-only games, input the name of the 3rd track both ECHO times it ask for a track, and put 45000 as the starting LBA. ECHO. ECHO. ECHO. set /p T3="Enter the name of the 1st track with the extension (ex: XYZ.bin):" for %%1 in (%T3%) do ( set T3X=%%~x1 set T3N=%%~n1 ) If %T3X%==.bin Echo %T3% will be converted to iso ... ECHO. set /p TX="Enter the name of the last track with the extension (ex: ZYX.iso):" for %%1 in (%TX%) do ( set TXX=%%~x1 set TXN=%%~n1 ) If %TX%==%T3% Echo Both tracks are the same! if not %TX%==%T3% ( If %TXX%==.bin Echo %TX% will be converted to iso ... ) ECHO. ECHO. set /p LBA1="Enter the Starting LBA of the last track of the GD-ROM:" set /A LBA = "LBA1"+150 ECHO. ECHO. IF not exist %T3% GOTO ERR1 IF not exist %TX% GOTO ERR2 if %T3X%==.bin ( ECHO Converting %T3% into %T3N%.iso copy "Utilities\bin2iso.exe" bin2iso.exe >nul bin2iso %T3% %T3N%.iso del bin2iso.exe >nul ) if %TXX%==.bin ( if %TX%==%T3% goto EXTRACT ECHO Converting %TX% into %TXN%.iso copy "Utilities\bin2iso.exe" bin2iso.exe >nul bin2iso %TX% %TXN%.iso del bin2iso.exe >nul ) GOTO EXTRACT :ERR1 IF not exist %TX% GOTO ERR3 ECHO. ECHO ERROR ! ECHO %T3% doesn't exist! ECHO Make sure %T3% is in the the root folder of the pack! ECHO. ECHO FamilyGuy 2008 pause >nul exit :ERR2 ECHO. ECHO ERROR !! ECHO %Tx% doesn't exist! ECHO Make sure %Tx% is in the the root folder of the pack! ECHO. ECHO FamilyGuy 2008 pause >nul exit :ERR3 ECHO. ECHO ERROR !!! ECHO %T3% and %TX% don't exist! ECHO Make sure they are in the the root folder of the pack! ECHO. ECHO FamilyGuy 2008 pause >nul exit :EXTRACT ECHO. ECHO. ECHO Extracting %TXN%.iso to the data folder with the TOC from %T3N%.iso ... ECHO. move %T3N%.iso data\%T3N%.iso >nul if not %TX%==%T3% move %TXN%.iso data\%TXN%.iso >nul copy utilities\extract.exe data\extract.exe >nul cd data >nul extract %T3N%.iso %TXN%.iso %LBA% ECHO Moving ip.bin ... move ip.bin ..\ip.bin ECHO Deleting temp files ... del extract.exe >nul move %T3N%.iso ..\%T3N%.iso if not %TX%==%T3% move %TXN%.iso ..\%TXN%.iso cd .. >nul ECHO. ECHO The tracks have been extracted to the data folder ! ECHO. If %T3X%==.bin CHOICE /C:YN Delete the converted %T3N%.iso ?%1 IF ERRORLEVEL ==2 GOTO HERE IF ERRORLEVEL ==1 del %T3N%.iso >nul :HERE if not %T3%==%TX% ( If %TXX%==.bin CHOICE /C:YN Delete the converted %TXN%.iso ?%1 IF ERRORLEVEL ==2 GOTO THERE IF ERRORLEVEL ==1 del %TXN%.iso >nul ) :THERE ECHO. CHOICE /C:YN Run SELFBOOT.bat? (Good idea if the game fits a cd and isn't protected)%1 IF ERRORLEVEL ==2 GOTO END IF ERRORLEVEL ==1 CALL SELFBOOT.BAT :END Echo. ECHO DONE! ECHO. ECHO Familyguy 2008 pause >nul exit C'est un nouveau image2data.bat beaucoup plus élégant que le dernier, tu n'as qu'à spécifier le nom complet (y compris l'extension) des tracks et puis le LBA de la derniere track. Pour l'utiliser, ouvre l'ancien bat avec notepad, efface tout et colle-le nouveau dedans. Merci, si tout se passe bien avec tes jeux il sera de la prochaine update. FG
  13. -FamilyGuy-

    adapatateur SD !!!

    Ma carte sdhc de 16 gb ne foncitonne pas. Selon jj1odm toute les cartes de 4gig et moins devraient fonctionner. Mais je ne peux confirmer. Ma carte de 2gig marche parfaitement par contre! FG
  14. -FamilyGuy-

    adapatateur SD !!!

    Je confirme, ayant fait plusieurs backups avec ce cable dans les derniers mois, la vitesse varie de 530 à 550 kB/s ce qui donne 35min pour un dump complet! Les espagnol vont sortir une librairie supportant ce câble et ensuite devraient sortir un multitude de soft, dont un backup launcher surement, bien que 550kB/s ne soit ps très vite pour loader une partie ... FG
  15. -FamilyGuy-

    adapatateur SD !!!

    Le schéma original date d,encore plus longtemps... Moi j'ai le mien depuis assez longtemps et je ne peux que me réjouir d'avoir des gens qui vont coder des application compatibles ! PS: C'est en grande partie grace a moi si jj1odm a recommencer à travaille sur cet adapteur et que ces espagnols se sont intéresser a ce calbe en premier Bon, trêve de fanfaronnade, je retourne bosser sur ShenmueII FG
  16. Je suis bien heureux de t'avoir éclairé! Donne-nous des nouvelles si tu réussis à faire tes images selfboot ou si tu as d'autres problèmes ou interrogations. FG
  17. Le DC se fout éperdument de la session dans laquelle les track cdda sont. Seulement, il les nomment d'après leur ordre sur le disque. SUr un gd-rom, la track04 est la 1ere track cdda (gdda en fait). En utilisant cdda.exe (sur le bin principal en général) on peut spécifier la 1ere track cdda comme étant la 1ere track. Et voilà, pas besoin de 3 tracks dummy! Aucun hack supplémentaire n'est nécessaire sur le ip.bin ! FG
  18. 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] 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
  19. 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
  20. 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
  21. Ç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
  22. 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
  23. En fait il faut quand-même spécifier un lba de départ et un 1st_read.bin et le bon) mais dans ce cas on met 45000 (donc rien de changé) et le 1st_read.bin du jeux (on n'utilise pas le 1st_read.bin hacké). auto.binhack.exe et ip.binhack.exe font cette manipulation automatiquement en autant qu'un ip.bin soit dans le root du pack et le 1st_read.bin spécifié dans le ip.bin dans le dossier data. Le ip.bin hacké est nommé ip.hak et est effacé après le création du NRG selfboot dans mon pack. FG [EDIT] Bon jeux CDDA (il vous faut cdrecord.exe et mkisofs.exe en plus de CDDA.EXE et Binhack.exe): D'abord, trouver l'adresse de son graveur: cdrecord -scanbus L'adresse est formaté ainsi: x,x,x ; Pour l'exemple on prendra 0,0,0 comme adresse, prenez le votre, pas le mien! Graver les cdda en première session en met l'adresse du graveur apres -dev= cdrecord -dev=0,0,0 -multi -audio track04.wav track05.wav track0X.wav Puis, il faut regarder à quel LBA la session suivante commencera: cdrecord -dev=0,0,0 -msinfo Le logiciel sort deux chiffres séparés apr une virgule, c'est le 2ieme qui nous intéresse: 0,Y Ça serait Y ici donc. Maintenant se souvenir de ce nombre, et hacké le boot.bin et les autres bins qui ont besoin de l'être (dur a trouver parfois) avec binhack et dahack selon ce nombre et hacké avec cdda (sans le nombre). Vous pouvez aussi visiter le dreamcast ripping database pour voir si d'autres protections existent dans votre jeux! Maintenant on fait l'iso des data: mkisofs -C 0,Y -V FAMLYGY -l -o data.iso data Les donnés doivent être dans un dossier nommé data, et Y est le nombre sorti par cdrecord à l'étape du msinfo. Vous pouvez remplacer FAMLYGY par le nom du jeux, c'est le nom de la session en fait (8 caractères max). Et là on grave: cdrecord -dev=0,0,0 -xa1 data.iso Et on test le CD obtenu dans le DC en croisant les doigt! Je ne connais malheureusement pas vraiment de façon sûre de faire un backup CDDA qui fonctionne dans les emulateurs, cependant cela devrait marcher sur une console. Cette technique "old school" nécessite malheureusement de graver un cd. OUF! C'était long! FG
  24. En fait, quand le DC load un cd il barre le lecteur gd-rom pour ne plus rien lire du média, le hack du ip.bin débarre le gd-rom après c'est tout. FG
  25. C'est à peu près ça mais mon apck ne fait pas de dummy automatiquement car avec la commande -duplicates-once on ne peut pas vraiment savoir quel taille aura l'iso d'après les fichiers (si il y en a plusieurs identique ils seront tous ecrit au même endroit.). tu peux mettre toi-même un fichier 0.0 de la grosseur que tu veux qui servira de DUMMY, il ne sera pas inscrit dans la TOC mais il prendra l'espace au début du CD. Le data1 est inutile si ton jeux rentre dans la session2, dans ce cas la premiere session sera rempli de "vide" (0x00) et tout fonctionnera pareil, même que les loading seront accélérés si ton jeux est peitit. Pour les cdda c'est assez compliqué comme l'a dit kogami, j'ai par contre quelques bat déjà faits pour faciliter ça, lis le pdf que je t'ai envoyé il explique très bien les cdda. FG
×
×
  • Créer...