redump.info Forum

As you know I've been spending a lot of time with ripping SegaCD games lately.

I have run into a problem with SegaCD games dumped with the "redump method", which is relevant to the Sega emulation scene.

I would appreciate if you read my respective post on the Inn on that issue, and help me and Steve (probably just me to understand the problem.

I would like to understand the issue of pregaps, and why the redump ripping method tackles it different even to the EAC method (attaching pregap to the beginning of the next track instead of the default method of attaching it to the previous track).

Guess, Kega's internal CUE parser is wrong, not a dumping method issue.

I never had problems making my dumps working in Kega, but I load the cuesheet in Daemon Tools first and run the dump directly from them as I would with a real CD, through Kega "Boot CD drive" function, I don't use Kega internal parser.

Daemon Tools' cue-sheet parser is correct then

It could be CDRWin working like EAC's "append gaps to previous track" (which is wrong).

3.When I start the game from redump cue sheet using Kega's "load Sega CD image" function, the game boots fine. However, there is too much silence at the beginning of the audio track, except for track 02 (first audio track). For the other audio tracks, I estimate 2 secs additional silence, the length of the pregap.

yeah, it looks something is wrong with how emulator handles cue sheets. if you change gaps in cue it matters only for 2nd track. rest tracks will always play from the start of file, and ther's gaps from previous tracks at the start. they should have been mapped to the end of previous tracks.

gigadeath wrote:It could be CDRWin working like EAC's "append gaps to previous track" (which is wrong).

Why is that wrong?

AFAIK the pregap is there to give the drive the time to start spinning and gain full speed before reading data, if the drive reads a track from a disc not at full speed there's a chance it misses the initial data. The gap is a no-data slice of time in which the drive prepare itself to reading.

So the gap is functional to the track who follows it, not the track that comes before it.

That's the point of gaps. If there was no such problem we won't have gaps between tracks at all today.

Even old magnetic tapes had gaps between sectors who had the same function.

You could alternatively use a CD with a "hidden track" and see how EAC behaves in both modes yourself, and you'll see why its default option is wrong.

By "hidden track", I mean a song or other sound bit that was encoded into the pregap (usually before Track 1), so most CD-players will skip over it by default and you need to hold the rewind button to get to the hidden track. You could also make a test CD which behaves in this manner, if you don't know of any albums like this.

Now we're used to run things direcly from hard disk, and the concept of gap has no sense, but back in the day it was a necessity because CD and tape reader were relatively slow mechanic devices, much slower than the system reading speed. Gaps are an artifact ideated to overcome the limitations of such slow mechanical devices.