This post concerns "Sega Dreamcast - Games - PAL (TOSEC-v2012-07-25_CM).dat" and the following 3 games:
"Tom Clancy's Rainbow Six - Rogue Spear + Mission Pack - Urban Operations v1.001 (2001)(Red Storm - Swing!)(PAL)[!]" is NOT affected.Tom Clancy's Rainbow Six incl. Eagle Watch Missions v1.002 (2000)(Red Storm - Swing!)(PAL)[!] (this is the game that I found to be wrong first, the other two I found later)
Tom Clancy's Rainbow Six incl. Eagle Watch Missions v1.002 (2000)(Red Storm - Swing!)(PAL)(FR)[!]
Tom Clancy's Rainbow Six - Rogue Spear + Mission Pack - Urban Operations v1.000 (2001)(Red Storm - Swing!)(PAL)(DE)[!]
Short version: track02.raw seems to be broken; according to the .dat it is 14,347,200 Bytes long but according to my calculations it should be just 13,994,400 Bytes long. I think it's a bug in HTTPD-Ack.
Code: Select all
rom ( name track02.raw size 14347200 crc e1393c68 md5 c6b9e57df79b228b5bb0b1100acfb625 sha1 e67cf74644806201773741c4386c66a015382a64 )
I mention this simply because my tool has a file length checking function to make sure a user can not try to convert a broken dump, since that could lead to all kinds of trouble during further processing.
I think it's common knowledge that all tracks in the second session ("HD session", from track03.bin to trackXX.bin) are together precisely 1,185,760,800 Bytes long (minus 705,600 bytes if there are other tracks after track03.bin). That's not really important anyway because track03.bin - track35.bin of said game (Tom Clancy's Rainbow Six incl. Eagle Watch Missions v1.002 (2000)(Red Storm - Swing!)(PAL)[!]) have the correct length in the .dat.
However the length of the first session is not correct.
The length of track01.bin can be read from the .gdi:
So track02.raw starts at sector 450.2 450 0 2352 track02.raw 0
Substract the gap length (always 150 sectors) you know that track01.bin should be 300 sectors long.
track01.bin is 705,600 Bytes long, divided by 2352 Bytes per sector = 300 sectors so it's ok (at least in length).
As for track02.raw: the dword (4 bytes) at 0x9360 in track01.bin (that's in the ISO9660 Primary Volume Descriptor, see http://alumnus.caltech.edu/~pje/iso9660.html) equals the length (in sectors) of the entire first session, in this case it's 0x00 0x19 0x00 0x00 or 6400, meaning the entire first session (track01.bin and track02.raw + 150 sectors gap) should be 6400 sectors at 2352 bytes each long.
Since we know track01.bin is 300 sectors long and there is a 150 sector gap that means track02.raw starts at sector 450 as mentioned in the .gdi and that track02.raw is supposed to be 5950 sectors long.
Proof #1: 5950 * 2352 bytes/sector = 13,994,400 Bytes.
And that's the problem since the track02.raw in the .dat is 14,347,200 Bytes long which is 352,800 Bytes, precisely 150 sectors or 2 seonds too long according to my calculations.
You might recognize the 13,994,400 Bytes long track02.raw since many games share the same track02.raw (or at least of the same length).
So when I ran the dump with the apparently broken track02.raw dump through my tool it stopped processing before even trying to verify the dump against the TOSEC dats since it found track02.raw to be broken.
Curiously enough when dumping my original "Tom Clancy's Rainbow Six - Rogue Spear + Mission Pack - Urban Operations v1.000 (2001)(Red Storm - Swing!)(PAL)(DE)[!]" using HTTPD-Ack 20071123 it claims track02.raw starts at sector 600, yet in the .gdi it claims it starts at sector 450 (which is correct according to my calculations). The 150 sectors difference are the cause of the problem, imho track02.raw dumping started at the right point but ended 150 sectors too late which is easily possible since track03.bin only starts at 45000 (+150) and there are most likely only zeroes in between.
Proof #2: take the track02.raw (or better yet, a copy of the file) from "Tom Clancy's Rainbow Six - Rogue Spear + Mission Pack - Urban Operations v1.001 (2001)(Red Storm - Swing!)(PAL)[!]" (or any other game with the same track02.raw, there are tons of them, just look in the PAL .dat, MD5 d1838bcbca4a24b39deddeae2a9d371a) and add 352,800 0x00 Bytes to the end. You'll end up with the exact same file as in the TOSEC dats for the aforementioned 3 games (MD5 c6b9e57df79b228b5bb0b1100acfb625).
So the solution is to either delete the 352,800 0x00 bytes from the end of the current track02.raw of those 3 broken dumps or just copy over the correct track02.raw (13,994,000 Bytes, MD5 d1838bcbca4a24b39deddeae2a9d371a).
It seems to me that HTTPD-Ack 20071123 has a bug in it that only affects those aforementioned 3 games, the US versions don't seem to be affected and according to the dats there are no JP versions.
That is in no way meant to be understood as "bashing" Ackmed, I love his tool and am very grateful for it. And I could also imagine something went wrong during the creation of the original GDs and Ackmed is not to blame at all.
Maybe someone who uses another dumping method than HTTPD-Ack could confirm if it's a bug in there or from disc manufacturing, or I'm just crazy.
Btw, I've checked 140 dumps yesterday and today using my aforementioned tool and all of them were detected as good.
The corresponding TOSEC dat entries for those discs were found without a problem, just those 3 games result in an error about a broken track02.raw.
Another thing: could someone explain the purpose of .gdi files to me? Is it just to verify that all tracks are there and to verify the length of track01.bin in case track02.raw size is unknown (as in: could be broken)? It just seems kind of redundant and not really needed to me.
Let's use the .gdi from the aforementioned game (Tom Clancy's Rainbow Six incl. Eagle Watch Missions v1.002 (2000)(Red Storm - Swing!)(PAL)[!]) as an example.
Line 1 is the total number of tracks. One who has to process these files programmatically could just look for all track*.bin files in the dir and get the number of tracks from the last one (track35.bin).35
1 0 4 2352 track01.bin 0
2 450 0 2352 track02.raw 0
3 45000 4 2352 track03.bin 0
4 186855 0 2352 track04.raw 0
5 194209 0 2352 track05.raw 0
34 297950 0 2352 track34.raw 0
35 299991 4 2352 track35.bin 0
Line 2 (track01.bin) is always the same.
Line 3 (track02.raw) starts with <track01.bin length in sectors> + 150 and the rest is always the same.
Line 4 (track03.bin) is always the same.
The lines after that are just the audio tracks, each start right after the other, the first track starts right after track03.bin.
The last line (track35.bin) (or actually second to last since there is another \r\n at the end) line is the last .bin track which starts at <end of last audio track> + 150.
Of course those calculations are unnecessary with a .gdi but I can't help but feel it's pretty useless nonetheless.
And since it's possible to create a .gdi file at any time for any valid dump which doesn't have one... I don't see why we need to save them in the first place.
And last but not least: is there any way to see which dumps are still needed?
I still have quite a few on my HDDs that don't match anything in the TOSEC dats; I'm currently re-organizing my collection and re-verifying against the July dats so I'm not yet quite able to say which ones those are but there seem to be more than a handful.
All right lads, sorry for the long wall of text but I thought those matters might be worthy of discussion.
Thanks for the attention and if I made any mistakes I'd be very glad if anyone could correct me.