extract files inside TOSEC dumps?
Moderator: Moderators
extract files inside TOSEC dumps?
Boy this isn't surprising. Just how in the hell can I gain access to TOSEC dump games' internal files? I need to do a selfboot of Fatal Fury. It is 5 tracks. Extract.exe doesn't work with BINs, only ISOs, so that tried and true method is screwed.
Combining tracks 3 and 5, and isofixing them and then feeding the image to isoboot didn't fully work. It broke the last few files, including the 1st_read. So what now? I need all the files inside tracks 3 and 5, and I need to know the proper LBA orders of them.
Another reason I hate this new standard :-\
Combining tracks 3 and 5, and isofixing them and then feeding the image to isoboot didn't fully work. It broke the last few files, including the 1st_read. So what now? I need all the files inside tracks 3 and 5, and I need to know the proper LBA orders of them.
Another reason I hate this new standard :-\
if you need the LBA's i think this would be the best method:
convert both *.bin to *.iso using bin2iso, create a dummy of exact the same size as the audio-tracks between the two data tracks are, then do "copy /b <track1>+<dummy>+<track2> <newfile>".
afterwards run the new file trough isofix ("isofix <newfile> 45000").
now you can open the fixed *.iso using isubuster and create a FileList.txt which you can then convert to a sorttxt.txt for mkisofs (which you already knew? ^^)
convert both *.bin to *.iso using bin2iso, create a dummy of exact the same size as the audio-tracks between the two data tracks are, then do "copy /b <track1>+<dummy>+<track2> <newfile>".
afterwards run the new file trough isofix ("isofix <newfile> 45000").
now you can open the fixed *.iso using isubuster and create a FileList.txt which you can then convert to a sorttxt.txt for mkisofs (which you already knew? ^^)
Um, can I just use track04.raw instead of a dummy? Or does it need to be the filesize of the track if it were 2048 instead? If so, I have no idea how to accurately do that.Majinseed wrote:if you need the LBA's i think this would be the best method:
convert both *.bin to *.iso using bin2iso, create a dummy of exact the same size as the audio-tracks between the two data tracks are, then do "copy /b <track1>+<dummy>+<track2> <newfile>".
afterwards run the new file trough isofix ("isofix <newfile> 45000").
now you can open the fixed *.iso using isubuster and create a FileList.txt which you can then convert to a sorttxt.txt for mkisofs (which you already knew? ^^)
No, track04.raw is always CD/DA track and therefore not 2048.
See the linked topic from az_bont about creating a .cue which includes the CD/DA tracks. Don't forget to add the gaps as described!
For a 5 track game like FF-MOTW you want to do, the .cue would look like this:
FILE "track03.bin" BINARY
TRACK 03 MODE1/2352
PREGAP 10:00:00
INDEX 01 00:00:00
POSTGAP 00:02:00
FILE "track04.raw" BINARY
TRACK 04 AUDIO
INDEX 01 00:00:00
POSTGAP 00:02:00
FILE "track05.bin" BINARY
TRACK 05 MODE1/2352
INDEX 01 00:00:00
So, hate it or not, it's a standard way of ripping now, as voted for by public, dumpers and emu authors. Since files can be converted in all cases, I don't see a problem...
For the record, I personally voted for 2048 though.
See the linked topic from az_bont about creating a .cue which includes the CD/DA tracks. Don't forget to add the gaps as described!
For a 5 track game like FF-MOTW you want to do, the .cue would look like this:
FILE "track03.bin" BINARY
TRACK 03 MODE1/2352
PREGAP 10:00:00
INDEX 01 00:00:00
POSTGAP 00:02:00
FILE "track04.raw" BINARY
TRACK 04 AUDIO
INDEX 01 00:00:00
POSTGAP 00:02:00
FILE "track05.bin" BINARY
TRACK 05 MODE1/2352
INDEX 01 00:00:00
Many users were complaining about "incomplete" dumps when we did them in .iso 2048 at first *and* NullDC authors we talked with asked for RAW rips. Then a vote among dumpers agreed with that.Another reason I hate this new standard :-\
So, hate it or not, it's a standard way of ripping now, as voted for by public, dumpers and emu authors. Since files can be converted in all cases, I don't see a problem...
For the record, I personally voted for 2048 though.
Well no one asked me, or told me about any "vote", so I'm not happy. The same goes for NoLogic. We were completely left in the dark.Maddog wrote:Many users were complaining about "incomplete" dumps when we did them in .iso 2048 at first *and* NullDC authors we talked with asked for RAW rips. Then a vote among dumpers agreed with that.
So, hate it or not, it's a standard way of ripping now, as voted for by public, dumpers and emu authors. Since files can be converted in all cases, I don't see a problem...
For the record, I personally voted for 2048 though.
ok, i dunno what exactly was said already and don't want to read everything again - i'll just write down what i do to get the files and the fileorder...
1. run both *.bin files through bin2iso.
if you don't care about fileorder go on with step 4
2. take a look into your *.gdi, get the lba of track4 and the lba of the last track (track5 for now), now its time to calculate a bit: first do lba of track5 minus lba of track4, then multiply that by 2352. that should be the size for your dummy file in bytes. create a dummy file of that size.
3. execute "/copy /b <data track1>+<dummy>+<data track2> <newfile>"
run isofix 45000 over it. open the fixed iso with isobuster and save the file order...
4. exract the data using "extract <data track1> <data track2> <lba of data track2 from *.gdi>" on the iso created with bin2iso (the one from step 1)
now you have the fileorder (which of course you will need to edit with "makesort.exe") and all the actual data files. that should be everything
1. run both *.bin files through bin2iso.
if you don't care about fileorder go on with step 4
2. take a look into your *.gdi, get the lba of track4 and the lba of the last track (track5 for now), now its time to calculate a bit: first do lba of track5 minus lba of track4, then multiply that by 2352. that should be the size for your dummy file in bytes. create a dummy file of that size.
3. execute "/copy /b <data track1>+<dummy>+<data track2> <newfile>"
run isofix 45000 over it. open the fixed iso with isobuster and save the file order...
4. exract the data using "extract <data track1> <data track2> <lba of data track2 from *.gdi>" on the iso created with bin2iso (the one from step 1)
now you have the fileorder (which of course you will need to edit with "makesort.exe") and all the actual data files. that should be everything
Again, read the thread. bin2iso blows. It corrupts portions of the tracks. Or at least the 2 versions of bin2iso which I have. For example, IsoBuster shows corrupted files in track5, including the 1stread.bin. So this isn't a valid method for a 5 track game such as this.NU-NRG wrote:extract.exe track03.iso lasttrack.iso LBA OF LAST TRACK GOES HERE!!!!
This does work as all the info you need is here.