I’ve been playing around with Sega Dreamcast discs lately. Not playing the games on the DC discs, of course, just studying their structure. To review, the Sega Dreamcast game console used special optical discs named GD-ROMs, where the GD stands for “gigadisc”. They are capable of holding about 1 gigabyte of data.
You know what’s weird about these discs? Each one manages to actually store a gigabyte of data. Each disc has a CD portion and a GD portion. The CD portion occupies the first 45000 sectors and can be read in any standard CD drive. This area is divided between a brief data track and a brief (usually) audio track.
The GD region starts at sector 45000. Sometimes, it’s just one humongous data track that consumes the entire GD region. More often, however, the data track is split between the first track and the last track in the region and there are 1 or more audio tracks in between. But the weird thing is, the GD region is always full. I made a study of it (click for a larger, interactive graph):
Some discs put special data or audio bonuses in the CD region for players to discover. But every disc manages to fill out the GD region. I checked up on a lot of those audio tracks that divide the GD data and they’re legitimate music tracks. So what’s the motivation? Why would the data track be split in 2 pieces like that?
I eventually realized that I probably answered this question in this blog post from 4 years ago. The read speed from the outside of an optical disc is higher than the inside of the same disc. When I inspect the outer data tracks of some of these discs, sure enough, there seem to be timing-sensitive multimedia FMV files living on the outer stretches.
One day, I’ll write a utility to take apart the split ISO-9660 filesystem offset from a weird sector.
I always thought putting higher datarate files near the edge was limited to the pirate DC releases… you’re confirming the retail releases did this too?
That sounds like a pretty advanced thing for pirates to do (have to assume that the game programs are traversing the filesystem normally rather than, e.g., hardcoding absolute sectors). Sure enough, this is how the actual discs are laid out. You might try reconciling some pirate releases with the above chart.
I might investigate this myself. I see that the Internet Archive has a bunch of DC bootlegs.
Hm, I think your theory has a few holes.
While it would explain why there is a data track at the end, it doesn’t explain the data track in front.
Even if it was because programs can only be run from the first, it shouldn’t be as large as it is for some of those.
However more critically, was the Dreamcast drive already using CAV (constant rotation speed)? Early CD drives (I think up to around 4x speed?) all used CLV.
With CLV the transfer rate is exactly the same across the whole disk.
However this opens up for another explanation: As the disk is then spinning faster when near the center, that means faster seek times there.
The best fitting explanation would be if it was a mixed CLV/CAV drive.
I.e. one that uses a fast but constant rotation speed in the center but varying speeds and constant but higher data rate on the outside.
That would mean vastly faster seeking inside (as both the rotation speed is higher and there is no need to adjust the speed while seeking) and somewhat higher data-rates near the outside but costly seeks (so you would only want data that you access linearly and not in parallel with other data there).
There are a few other explanations though. A to me particularly likely one is that it’s just what the development tools suggested you do and a few developers did that without really understanding the point of it. Which would explain some of the outliers…
@Reimar: See this experiment I ran a few years ago using the DC’s optical drive:
http://multimedia.cx/eggs/cd-r-read-speed-experiments/
I empirically determined that the read speed was faster on the outside of the disc vs. anything closer to the middle.
Based on all the discs I have studied so far, it seems reasonable that it was standard practice to put timing-sensitive and streamable files on the faster read portions of the disc. What seems odd to me is that there is never any wasted space on these discs. Though I haven’t dug into the filesystems too much (there could be big, blank files to fill out the space).