Making CUE sheets for BIN/RAW dumps (TOSEC/httpd-ack)

This forum is for the discussion of dumping games. Get help with your dumping here.

Moderator: Moderators

Post Reply
az_bont
Site Founder & Admin
Site Founder & Admin
Posts: 40
Joined: Fri Apr 06, 2007 12:02 pm

Making CUE sheets for BIN/RAW dumps (TOSEC/httpd-ack)

Post by az_bont » Fri Jun 08, 2007 7:16 am

SINGLE HIGH-DENSITY TRACK

Games which have only one high-density track will all have an identical CUE sheet. The first two tracks on every GD-ROM are from the low-density region of the disc, so can be ignored completely. If a game ends at track 03, then that means it will need a CUE sheet as follows:
FILE "track03.bin" BINARY
TRACK 03 MODE1/2352
PREGAP 10:00:00
INDEX 01 00:00:00

MULTIPLE HIGH-DENSITY TRACKS

If a game has more than one track in the high-density region of the disc, then you will be required to do a little bit of work to end up wih a working CUE sheet.

I'll just start off by showing an example of the CUE sheet I created for V-Rally 2 - Expert Edition v0.002 (2000)(Infogrames)(PAL)(M3)[!], with the interesting parts bolded:
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

FILE "track05.raw" BINARY
TRACK 05 AUDIO
INDEX 01 00:00:00

FILE "track06.raw" BINARY
TRACK 06 AUDIO
INDEX 01 00:00:00

FILE "track07.raw" BINARY
TRACK 07 AUDIO
INDEX 01 00:00:00

FILE "track08.raw" BINARY
TRACK 08 AUDIO
INDEX 01 00:00:00

FILE "track09.raw" BINARY
TRACK 09 AUDIO
INDEX 01 00:00:00
POSTGAP 00:02:00

FILE "track10.bin" BINARY
TRACK 10 MODE1/2352
INDEX 01 00:00:00
Now I'm going to break it down a little:
Track 03 wrote:FILE "track03.bin" BINARY
TRACK 03 MODE1/2352
PREGAP 10:00:00
INDEX 01 00:00:00
POSTGAP 00:02:00
To start with, the first data track (track03.bin) will always be exactly the same, regardless of the game.

The PREGAP 10:00:00 line will pad out the first track so that its position matches that of the original disc (an LBA of 45000).

The POSTGAP 00:02:00 adds 2 seconds (150 sectors) of padding between this track and the next.

If you are ever in doubt as to whether the POSTGAP command should be used, simply hover over the link in the web page that httdp-ack displays.
track03.bin?session02_p4096_cdxa0_sector_size2352_gap150_dma1_sector_read16_retry5
You'll find that you only need to include the POSTGAP command when the next track of a disc is of a different type to the current one (audio track followed by a data track, or vice versa).

Now let's look at the audio tracks:
Tracks 04 to 08 (all audio tracks minus the last one) wrote:FILE "track04.raw" BINARY
TRACK 04 AUDIO
INDEX 01 00:00:00

FILE "track05.raw" BINARY
TRACK 05 AUDIO
INDEX 01 00:00:00

FILE "track06.raw" BINARY
TRACK 06 AUDIO
INDEX 01 00:00:00

FILE "track07.raw" BINARY
TRACK 07 AUDIO
INDEX 01 00:00:00

FILE "track08.raw" BINARY
TRACK 08 AUDIO
INDEX 01 00:00:00
As you can see, all but the final audio track follow exactly the same pattern. If you check the link for each of those tracks in your browser, you should see that they look like the following:
track04.raw?session02_p4096_cdxa0_sector_size2352_gap0_dma1_sector_read16_retry5
However, the final audio track is slightly different:
Track 09 (last audio track) wrote:FILE "track09.raw" BINARY
TRACK 09 AUDIO
INDEX 01 00:00:00
POSTGAP 00:02:00
As it will be immediatley followed by a data, track, you will have to add the POSTGAP line to pad the data out by 2 seconds (150 sectors). This is reflected in the link httpd-ack will give you:
track09.raw?session02_p4096_cdxa0_sector_size2352_gap150_dma1_sector_read16_retry5
Now, onto to the final data track:
Track 10 (final data track) wrote:FILE "track10.bin" BINARY
TRACK 10 MODE1/2352
INDEX 01 00:00:00
This one is nice and straight forward, so I won't go any further than that.


OPENING CUE SHEETS

The resultant CUE sheets are not entirely standard, so you might find that your favourite image handling application doesn't like them. However, the programs mentioned below both have free versions available, and should be able to do everything you require.

CDMAGE

You can open this CUE sheet directly in CDMage, and it will allow you to see all of the data. You can also use CDMage to check for any corruption in the data tracks, but as audio tracks are raw audio with no ECC, you will only be able to verify they are free from errors by comparing to another dump. Any discs in the TOSEC DAT files will already be verified this way, so this feature is only of use for your personal dumps of games not yet in the DATs.

IsoBuster

If you would like to open the image in IsoBuster, you should mount the CUE sheet in Alcohol 120%, and then select to the virtual drive in IsoBuster. This method takes longer than using CDMage as above, but is useful for creating a "sort file", which allows you to create a CD-R copy of a GD-ROM that maintains the exact same file order (reducing seek time, and putting files that need to be read at higher speeds towards the end of the disc).
TuxTheWise
Posts: 9
Joined: Sun Jan 25, 2009 12:41 pm

Post by TuxTheWise » Wed Jan 28, 2009 8:06 pm

Dude, I had to extract files from a multi data track GD dump and I was really prepared for a long journey through forums and hours wasted looking for the solution. Then I come here and find the solution so easily! Come on, you ruined all my fun LOL

Thanks a lot for the guide, it was very useful :)
User avatar
atreyu187
Posts: 462
Joined: Mon Jul 25, 2011 8:13 pm

Re: Making CUE sheets for BIN/RAW dumps (TOSEC/httpd-ack)

Post by atreyu187 » Wed Nov 21, 2012 2:11 pm

Normally this trick works but for the life of me I cant get Dracounus to mount and extract. Luckily family guys pack extracted and someone else passed the filesort on to me. Now time to see if I can make a single disc version with 900mb cdrs.
Post Reply