3 broken dumps in TOSEC dats? Tom Clancy's Rainbow Six PAL

This forum is for discussing Dumpcast or the TOSEC project itself. Post suggestions or ask questions about the project or the website here.

Moderator: Moderators

Post Reply
iNub
Posts: 5
Joined: Sun Aug 26, 2012 7:08 pm

3 broken dumps in TOSEC dats? Tom Clancy's Rainbow Six PAL

Post by iNub » Mon Aug 27, 2012 11:46 am

Hi, first of all I'm not quite sure where I should post this so please bear with me and move the thread as needed.

This post concerns "Sega Dreamcast - Games - PAL (TOSEC-v2012-07-25_CM).dat" and the following 3 games:
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)[!]
"Tom Clancy's Rainbow Six - Rogue Spear + Mission Pack - Urban Operations v1.001 (2001)(Red Storm - Swing!)(PAL)[!]" is NOT affected.

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.

Long version:

Code: Select all

rom ( name track02.raw size 14347200 crc e1393c68 md5 c6b9e57df79b228b5bb0b1100acfb625 sha1 e67cf74644806201773741c4386c66a015382a64 )
I'm the coder of "DC2CD" or "Dreamcatcher" as it is now called; that's a tool which allows the user to easily convert .gdi dumps into .bin and .cue files which can be burnt with ImgBurn to get a selfbooting copy. It's not quite ready for public release yet but that's off topic.

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:
2 450 0 2352 track02.raw 0
So track02.raw starts at sector 450.

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.
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 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).

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.
Last edited by iNub on Mon Aug 27, 2012 12:56 pm, edited 3 times in total.
User avatar
atreyu187
Posts: 462
Joined: Mon Jul 25, 2011 8:13 pm

Post by atreyu187 » Mon Aug 27, 2012 1:08 pm

Was about to say there isn't any problems with those as I checked but seems you already noticed that, anyhow HTTP'd ack isn't the only way we can dump our disc for this project and still get the exact same results. I don't even use a BBA at all for my dumps and I have verified over 50 games easily using the SD adapter which gave the same results as a BBA dumped game via HTTP'd ack. Also we have to dump and get the same hashes form two separate dumpers of two separate disc to be added to the DAT's. Also the PAl set is done except for contry variants and ring codes but there is at least one verified dump for every PAL game. We are only 6 (soon to be less once verifed in DAT's) left in the USA set one really needed is PW 3.0, as far as I can tell it is the only disc that doesn't have a single dump submitted. Anyhow looking forward to the next public release of your tool as it makes my life easier when making my backups.
iNub
Posts: 5
Joined: Sun Aug 26, 2012 7:08 pm

Post by iNub » Mon Aug 27, 2012 1:23 pm

So did you use another method of dumping on one of those 3 mentioned games? Then that'd clear that up and it'd seem like an error during manufacturing - or possibly shared code between those dumping methods but that seems unlikely to me.

Or of course my track length calculation could be wrong but since it works with 100s of other dumps, just not those 3 games (or actually I only tested the first one but assume the other two are the same, don't have those dumps here right now but the track02.raws are shared between all 3) I don't think that's the case.

But even if it is just a disc preparation error, should a technically still broken track be in the TOSEC dats?

IMHO proof #1 and #2 still stand.

As for the remaining dumps, Dreamkey 3.1 (ES) is still missing from the dats as far as I can see, it was posted on ASSEMbler recently (not by me).
MD5SUMS:
6ce8d1c1357f9fe425693a7c85d077da *disc.gdi
46abbcc66e28a2bdfcc0e68e99f8ad08 *track01.bin
d1838bcbca4a24b39deddeae2a9d371a *track02.raw
d0c83f2c4ec9c203184c7a8a0b365ea5 *track03.bin
e081e4437e3193c4f9f712f5d607ce52 *track04.raw
ede34c5a85bc9e97733b58ebf04a7eca *track05.bin
I'll have to check my own dumps again but I'm still far from finished, there are a few hundred more I have to look through and that'll take a while.
Maybe the other dumps I have have been added since the February dats, if not I'll post them soon.

Dreamcatcher is coming along nicely but I still have to re-do the ISO creation stuff, (almost) everything else is pretty much done.

EDIT: Another thing. Is there a post somewhere that explains the point of keeping .bin track images instead of .isos? It seems to me the extra 304 bytes per data sector could be left out to save roughly 13% of space.
They can be recalculated precisely if needed (just like the .gdi files) so they seem unnecessary.
I understand that keeping those 304 bytes means it's a raw dump but that extra data just seems useless.
If anyone could link me to such a post or explain the motivation behind that I'd be very grateful.
ackmed
Posts: 28
Joined: Wed May 02, 2007 3:29 pm

Post by ackmed » Mon Aug 27, 2012 7:21 pm

Hi

httpd-ack gets the TOC for the first session from the cdrom itself. When calculating the end sector of the 2nd track it will do leadout_sector - gap.

-ack
iNub
Posts: 5
Joined: Sun Aug 26, 2012 7:08 pm

Post by iNub » Tue Aug 28, 2012 7:39 am

But what confuses me is that httpd-ack shows a start sector of 600 for track02.raw in the html UI but a start sector of 450 in the GDI.

See for yourselves:
http://pastehtml.com/view/c9qd8w4ku.html (httpd-ack html page)
http://pastehtml.com/view/c9qdbtd5q.txt (httpd-ack .gdi)

Something's wrong there - of course not necessarily with your tool ackmed (a great tool that saved me tons of time, thanks!), I'm leaning towards a manufacturing/preparation error now - but either way, this thing still seems broken to me.

When you say "from the cdrom itself", do you mean you send some sort of query to the GD drive and it responds "session 1 is x long" or do you do the same thing I do and look in the Primary Volume Descriptor in track01.bin?

Anyway, when the session length is supposed to be 6400 sectors (as explained in the OP, 15052800 bytes) but track01.bin is just 300 sectors (705600 bytes) and there's a pre-gap of 150 sectors (352800 bytes) before track01.bin, there's still just 5950 sectors (13994400 bytes) left for track02.raw, not 6100 (14347200 bytes).

Plus I find it weird that the (imho) overdumped track02.raw is exactly byte for byte identical to other track02.raw files used in many other games (see OP), except for 150 extra sectors full of 0x00 bytes stuck to the end.

I just don't see how that could be a coincidence.

For me the problem is obviously that I'd prefer Dreamcatcher to not label verified dumps as broken but since my track size checking method works with every other game I've thrown at it (which should be roughly 300 by now), just not those 3 games with the same (again imho, overdumped) track02.raw that just doesn't seem right to me.

I guess what it comes down to is that I don't know how situations like these are handled in TOSEC.
Would "we" rather have a raw dump with errors or an altered - yet probably closer to what was originially intended - dump (deleting 352800 zeroes) with no errors?

But that seems to all depend on the dumping methods; I'm still not sure how exactly the length of track01.bin and track02.raw get determined.

As I said the session length is written in the ISO9660 PVOD but the track lengths aren't, so either the session length is wrong or the track lengths are wrong. There's just no way both are ok since they don't match.

Sorry for those long posts.
ackmed
Posts: 28
Joined: Wed May 02, 2007 3:29 pm

Post by ackmed » Tue Aug 28, 2012 2:54 pm

iNub wrote:But what confuses me is that httpd-ack shows a start sector of 600 for track02.raw in the html UI but a start sector of 450 in the GDI.

See for yourselves:
http://pastehtml.com/view/c9qd8w4ku.html (httpd-ack html page)
http://pastehtml.com/view/c9qdbtd5q.txt (httpd-ack .gdi)

Something's wrong there - of course not necessarily with your tool ackmed (a great tool that saved me tons of time, thanks!), I'm leaning towards a manufacturing/preparation error now - but either way, this thing still seems broken to me.
The first 150 sectors of the cdrom are the lead-in area. When interacting with the cdrom everything is offset by those 150 sectors. The output of the html index is the raw sector offsets that will be used when dumping the track.

The gdi format expects that sector 0 is the first sector after the lead-in area. So this mean 150 must be subtracted from each raw sector offset to generate the sector numbers in the .gdi file.
iNub wrote: When you say "from the cdrom itself", do you mean you send some sort of query to the GD drive and it responds "session 1 is x long" or do you do the same thing I do and look in the Primary Volume Descriptor in track01.bin?
The TOC is contained in the lead-in area of the session. You can query the cdrom device and it will provide you with this TOC data. This is what httpd-ack uses.

Can you tell me what field you are saying the 6400 value comes from in the PVD? I am pretty sure the PVD doesnt have any field that will identify how large the session is, just how large the ISO9660 filesystem is.

-ack
User avatar
Maddog
is awesome
is awesome
Posts: 1427
Joined: Sat May 12, 2007 4:12 pm

Post by Maddog » Tue Aug 28, 2012 4:31 pm

I will try to address some of your questions, excluding those about httpd-ack (since ack is around, he's far more qualified to reply to those)
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.

Quote:
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 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).

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.
.gdi is not our "invention". The format was introduced with the first release of NullDC and became a defacto standard for Dreamcast emulators. It works pretty much like a .cue file, telling the emulator information about the layout of the GD-ROM used. Of course the same info could be achieved by calculating (assuming all tracks are present and noone deleted anything by accident...), but I guess it's easier skipping all these calculations.
Granted, .gdi is not a perfect format and even contained an error at first (the famous -8 issue, which was corrected in the 2nd version of NullDC), but it gets the job done and I don't feel we should get rid of it. Especially the less technically minded people (around 95% of users, probably) would never be able to recreate it even if it's easy.
EDIT: Another thing. Is there a post somewhere that explains the point of keeping .bin track images instead of .isos? It seems to me the extra 304 bytes per data sector could be left out to save roughly 13% of space.
They can be recalculated precisely if needed (just like the .gdi files) so they seem unnecessary.
I understand that keeping those 304 bytes means it's a raw dump but that extra data just seems useless.
First release of the TOSEC dats back in 2007 was in 2048 .iso format. Soon afterwards, several out-of-project people mentioned that it was possible that some discs might have "protection" and that assuming that the extra 304 bytes would only have the expected values might lead to errors in the future. So, we had a discussion and voted to change the dumping method to 2352 .bin. The disk space overhead isn't really important and the accuracy of dumping is better. And it keeps those that dislike 2048 quiet (seems there are more of those around) :P
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.
I am going to make the database (basically, some Excel files) public in the future-they still need some polishing before that.
A slightly older version of the USA dat is available here (this is really close to completion by now). PAL one is complete regarding individual games, but many country variants are still missing.
If you want in the meantime, let me know in a pm what unrecognized dumps you have and I will tell you which are needed. Keep in mind that we don't accept files that you just found on the Net, you need to provide info like the ringcode at minimum. In any case, for a dump to be included in the dats it has to be dumped twice by two different people using different discs (this is a massive help in making sure the dumps are good), so there are lots of single dumps still waiting for verification (some files took years to be verified...)

Regarding the Rainbow Six games:
Our "rivals" at Redump have a couple of Rainbow Six games entered at their database and post the length of track02 as 14700000 bytes. This is our size+352800 bytes of gap that they append to the audio track as their dumping method dictates. Since their dumping method is totally different, using a PC drive and different tools, it seems to me that they "agree" that the size we are using -and httpd-ack is reporting- is correct.
I own these discs too, but currently have no CD drive connected on the PC. I will connect one soon and post here the file info as read by a PC drive using Isobuster or whatever other tool you prefer me to use (the first two tracks are readable in any PC drive). But I am pretty sure it's not an erroneous dump. Could be a mastering error, we have seen plenty of those discs on other systems in the past.
I guess what it comes down to is that I don't know how situations like these are handled in TOSEC.
Would "we" rather have a raw dump with errors or an altered - yet probably closer to what was originially intended - dump (deleting 352800 zeroes) with no errors?
"We" are trying to make dumps that are as close to the original disc as possible. If that one has errors, the errors should be reproduced, not corrected.
iNub
Posts: 5
Joined: Sun Aug 26, 2012 7:08 pm

Post by iNub » Tue Aug 28, 2012 4:47 pm

Thanks a lot for your detailed answers!

Apparently I had a few things figured wrong and I'm always happy to improve my perception of things.

I'm a little busy right now but I'll try to answer asap.
Last edited by iNub on Tue Aug 28, 2012 4:52 pm, edited 1 time in total.
iNub
Posts: 5
Joined: Sun Aug 26, 2012 7:08 pm

Post by iNub » Tue Aug 28, 2012 4:51 pm

Sorry, hit the "quote" button instead of the "edit" button once again in a hurry.

ackmed:

I was never sure what those 150 sector gaps were used for and where you got the TOCs from but now I know, thanks!

You are of course right about the 150 sector html/gdi difference, I haven't dumped any games for quite a while and seem to have forgotten that. After checking some of my unverified dumps that I saved with the corresponding .html files it's clear that you are absolutely correct.

As for the PVD, I'm looking at the 4 bytes at offset 0x9360 in track01.bin; I've been using http://alumnus.caltech.edu/~pje/iso9660.html as a guide and it says that at this position one can find the "total number of sectors", I always assumed that meant the total number of sectors in the session - I'm not sure, would the lead-in and track02.raw also count to the ISO9660 filesystem? If so then I probably just called it by a wrong name.

For "Tom Clancy's Rainbow Six incl. Eagle Watch Missions v1.002 (2000)(Red Storm - Swing!)(PAL)[!]" that value is 0x00 0x19 0x00 0x00 or 6,400.
Subtract the length of track01.bin (705,600 bytes or 300 sectors) and the gap length (352,800 bytes or 150 sectors) and you have 5,950 sectors left.
And usually (= on every single game I tried so far which is somewhere between 250-350, except of course those 3) that's precisely the verfied track length of track02.raw according to the TOSEC dats.

But in these aforementioned 3 cases the length of track02.raw is not the one that was calculated (=5,950 sectors or 13,994,400 bytes) but instead 6100 sectors or 14,347,200 bytes.

Plus if one deletes the last 352,800 0x00 bytes from that track02.raw (= what I think is technically an overdump, regardless of TOC but opinions on that seem to differ) the resulting track02.raw is identical (md5: d1838bcbca4a24b39deddeae2a9d371a) to a track02.raw used in tons of other games, as well as "Tom Clancy's Rainbow Six - Rogue Spear + Mission Pack - Urban Operations v1.001 (2001)(Red Storm - Swing!)(PAL)[!]" which gets detected as a good dump using the above mentioned track02.raw length calculation I'm using.

All in all (if I'm right) it seems to me that some versions of that game were created incorrectly with a wrong session (?) length in the PVD.

Maddog:

gdi stuff: Thanks for the explanation, they still seem a little useless to me but why argue about a few bytes of data, who cares.
As for creating gdi files, the next public release of Dreamcatcher will offer a function to do that automatically for anyone who doesn't have the right .gdi for the dump since it'll be required in the GD(-R) to selfboot CD conversion file checking process.

2048/2352: I'm wondering if any proof for that actually exists, I've heard it mentioned a few times but never really believed in it... because technically those 304 bytes can be calculated easily, unless of course the EDC/ECC (or other) values in there were faked/broken on purpose... But you're right, better safe than sorry.

Unverified dumps: Great, I'm looking forward to the database release! I have a few country variants that don't seem to be in the dats yet, along with mostly JP games that haven't made it in so far. I'm still checking and re-checking dumps so it'll be a while before I PM you.
Unfortunately though I only saved the ringcodes of some of them so I'll probably only be able to verify dumps others have made with these, I remember a post by you in another thread (http://dumpcast.thekickback.com/forum/v ... c.php?t=14) about how ringcodes don't really matter for dump verification because they can differ even though the data is the same.
"There's no need to dump every ringcode twice to confirm it. Two identical dumps even with different ringcodes are confirmation enough. "
So I can still verify other people's dumps even without knowing the ring codes as long as I made them myself, right?

Rainbow Six: A mastering error (ah, there's the expression I was looking for, thx) seems likely to me indeed. I understand ackmed uses the "real" TOCs in the session lead-ins so the dump itself is probably correct; but as I explained above I think the session (?) length definition in the PVD of track01.bin would indicate a different track02.raw length, one that if it was applied to the verified track02.raw would result in the exact same track02.raw we all know from many, many games which is 13,994,400 bytes long.

I understand why it makes sense to preserve the original disc as originally as possible... but imho "original" is a matter of definition since there are two conflicting values for the track02.raw track length, one that comes from the lead-in TOC and one that comes from the track01.bin PVD. The question is which one to choose.

Pro keeping it the way it is: I'd think that a real DC console would probably use the lead-in TOC. But to me, both variants of getting the track02.raw length seem logical and are both possible with data from the original disc, but only the PVD one is possible with a .gdi dump since the lead-in data is not saved with the dumps.

Contra keeping it the way it is: as explained above the track02.raw in those dumps is just (byte for byte) a copy of a well known track02.raw used in many other games and even another variant of the Rainbow Six games ("Tom Clancy's Rainbow Six - Rogue Spear + Mission Pack - Urban Operations v1.001 (2001)(Red Storm - Swing!)(PAL)[!]") plus an additional 352,800 zeroes which to me seem to stem from a false TOC. The session (?) length in the PVD is correct because
a) if using that value, the file suddenfly matches another often used 13,994,400 byte track02.raw
b) one version of the game actually has the correct track02.raw in the TOC which is exactly the track02.raw referred to in a)

Of course for me personally there's another contra to keeping it the way it is.

Dreamcatcher selfboot processing of a supplied .gdi goes like this:

Code: Select all

1) read gdi
2) calculate expected track lengths (using the track01.bin PVD to get the track02.raw length)
3) compare expected to actual file lengths
4) if all tracks match
   true: goto 5) (this happens for all of the couple of hundred "good dump" games I've tried so far except the aforementioned 3 Rainbow Six PAL game versions)
   false: abort processing and disallow selfbooting (this happens for the PAL Rainbow Six games right now, except for the last one with the right track02.raw)
5) check files against tosec database (name, size, crc32, md5, sha1), show verified game name if found
6) extract data from track01.bin and track03.bin
7) wait for user to modify settings
8) start selfbooting process
So if it's kept the way it is I'd have to allow selfbooting even when a dump is broken, which will probably lead to a lot of headaches from hearing users complain about how the program doesn't work with their (really) broken dumps.

Or I assume I could also modify the existing processing method to allow tosec checking and selfbooting for dumps where only track02.raw appears broken since that won't make any real difference anyway...


I'd still like to ask for consideration to be given to the points I raised above about the multiple methods to determine the track lengths and the resulting dumps since I personally just don't feel right having a broken dump in a "good" set (after comparing it to the other track02.raw it clearly is broken to me, it's no coincidence it's just a well known track02.raw with 150 0x00 sectors stuck to the end, it's an error; and the length reflects the correct session (?) length in the PVD).


Thanks for the patience to read it all and for the new (to me) info to all of you!
User avatar
atreyu187
Posts: 462
Joined: Mon Jul 25, 2011 8:13 pm

Post by atreyu187 » Wed Aug 29, 2012 11:36 pm

If I can I will post the PC CD-ROM trap disc for audio and data files as I have used this method before on my laptop. Just say ok and I will have them here.
Nologic
Posts: 207
Joined: Sat Apr 14, 2007 12:14 pm

Post by Nologic » Thu Aug 30, 2012 3:29 pm

Hmm if PW 3.0 means "PlanetWeb Internet Browser v3.0 (U) [T31901N]" then yeah there should be a submission for that...as I did it.

Anyways here again:

Name: PLANETWEB INTERNET BROWSER V3.0
Region: USA
Publisher: SEGA
Box ID: T-31901N
Ringcode: *4S* T-31901N BIFPIL433
Barcode: 831126000014
Notes:

Header Info:

Code: Select all

Title:             PLANETWEB INTERNET BROWSER V3.0
Media ID:          1775
Media Config:      GD-ROM1/1
Regions:           U
Peripheral String: A79FB10
Product Number:    T31901N
Version:           V3.040
Release Date:      20011027
Manufacturer ID:   SEGA LC-T-319
GDI Index:

Code: Select all

3
1 0 4 2352 track01.bin 0
2 756 0 2352 track02.raw 0
3 45000 4 2352 track03.bin 0
File Sizes:

Code: Select all

track01.bin 1425312
track02.raw 1237152
track03.bin 1185760800
CRC-32:

Code: Select all

track01.bin 0287adaf
track02.raw 405041ac
track03.bin dad88a7f
MD5:

Code: Select all

track01.bin 419a362b61ea7fb0e6b54ab6c30c8b24
track02.raw 701760d02c61f0b6e09d700443930c37
track03.bin ccf74f22a6b4ad003491a72e83efc5ad
SHA-1:

Code: Select all

track01.bin 5cc1d6a565c3d191bc1209df61c3e57e0a4a7c44
track02.raw 77825f4cbd073001377bc76d1fe874120647db57
track03.bin 05a8a60dd244765d4084e6c24bc49ec689fee256
User avatar
atreyu187
Posts: 462
Joined: Mon Jul 25, 2011 8:13 pm

Post by atreyu187 » Fri Aug 31, 2012 10:45 am

Missed that nologic but that is good as i am trying to acquire that disc now to dump. Lets just hope it is a matching ring code. Then once i get my PW 2.603 back we can add that to the database as well as 2.62 that just got verified by me and fatman01923
Post Reply