Deunan WIP News

Deunan posted this on his site:

Decision has been made, there will be a short production run of GDEMU soon - as in, a few weeks. After that, when I can tell just how many people are actually going to pay for it, I will decide if I will continue or not. More details will follow once I get everything sorted out.

In other news, my testers notified me of some recently done Dreamcast dumps that appear to be broken on GDEMU, so I investigated.
Seems like there is a group, or groups, that started doing GD-ROM dumps using PC drives with a so-called "swap method". I did that too once, other than having slightly different "audio offsets" there is nothing preventing such dumps from working - if done correctly. And that's the key word here. Well, the group(s) in question decided they know better and introduced changes into tracks' positions and lengths - to "fix" things I guess. The worst part is they've just shoved all their changes into .gdi files and typical user has no way of knowing if it's a proper dump or not.

GD-ROM images made using GD drive in Dreamcast are not perfect either, but frankly no CD image format is, or will ever be, unless we store raw EFM stream (assuming we can even read it glitch-free, which is debatable). But small flaws can be corrected if the method is good in principle and the changes are always consistent. For GDIs it means you need to adjust for missing pregaps (not really needed) on data tracks and starting address on audio tracks. My guess is the new dumps were supposed to overcome that, but instead are plain broken.

As an example let's take a look at Chu-Chu Rocket, the PAL version. The new .gdi file says this for tracks 3 and 4:

3 45000 4 2352 "ChuChu Rocket! (Europe) (En,Ja,Fr,De,Es) (Track 03).bin" 0
4 355602 0 2352 "ChuChu Rocket! (Europe) (En,Ja,Fr,De,Es) (Track 04).bin" 0

Track 3 file is 730535904 bytes long, that is 310602 raw sectors. Since it's missing the pregap I mentioned, the actual length of the track is 150+310602=310752.
Let's add this length to it's starting address, to see where it ends: 45000+310752=355752. See the problem? Track 4 starts at 355602, which is less than 355752. This creates an impossible situation where tracks overlap.

But wait, what if we treated this new image just like the old dumps and actually did apply the fix for audio tracks as usual? Then it'd be 355602 plus 150 fix which equals 355752 and it checks out. Yay! Maybe this is the correct way after all, let's investigate further:

18 505295 0 2352 "ChuChu Rocket! (Europe) (En,Ja,Fr,De,Es) (Track 18).bin" 0
19 505819 4 2352 "ChuChu Rocket! (Europe) (En,Ja,Fr,De,Es) (Track 19).bin" 0

Track 18 is audio, 1232448 bytes long, which makes it 524 "sectors". If we add the fix, then it starts at 505295+150=505445, and ends at 505445+524=505969. Oops. Track 19 started already, at 505819... Now track 18 end overlaps with track 19 pregap.

The funny thing is, the situation with track 18 overlapping track 19 will kinda work still, since no code ever tries to acces the pregap, so the collision will never be discovered. But this tells you a lot about quality of this dump. Can it be fixed? Maybe. Question is, why break and fix it, rather than just use a known good dump.

I rest my case.

http://dknute.livejournal.com/42778.html