1 Topic by Eidolon (edited by Eidolon 2008-01-21 21:47:00)

  • Registered: 2008-01-15
  • Posts: 50

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

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

  • Registered: 2006-12-24
  • Posts: 3,847

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

  • Registered: 2007-09-11
  • Posts: 402

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.

  • Registered: 2007-11-06
  • Posts: 34

Daemon Tools' cue-sheet parser is correct then tongue

  • Registered: 2007-09-11
  • Posts: 402

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

  • From: Macondo
  • Registered: 2007-08-21
  • Posts: 966

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.

ECMa130 @20091225 :: friidump 0.5.3 :: PSXstuff :: SaturnPrograms :: MyStupidPrograms2 :: MyStupidPrograms

themabus's Website

  • Registered: 2008-01-15
  • Posts: 50

gigadeath wrote:

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

Why is that wrong?

8 Reply by gigadeath (edited by gigadeath 2008-01-22 00:35:19)

  • Registered: 2007-09-11
  • Posts: 402

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.

  • Registered: 2007-11-06
  • Posts: 34

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.

  • Registered: 2007-09-11
  • Posts: 402

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.

  • Registered: 2007-09-11
  • Posts: 402

Snake wrote:

I don't know that I'd call it 'wrong'. Pretty much everything does it that way. Is everyone wrong?

If wrong is a word too hard, call it "less suitable" then.

It's true that old programs behave like CDRWin. In fact EAC guys has always made clear that the ability to select where gaps go is a strong point of their program.

From a theoretical point of view, gaps should be attached at the beginning of a track, because they act as support to the full reading of the following track; the previous track could care less that there's a gap coming after itself.

  • Registered: 2007-11-06
  • Posts: 34

Snake wrote:

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

This does not explain why Kega is unable to see the data track in one instance. The cue sheet for the data track is identical. Daemon tools is definitely doing something odd in that instance.

Do all the files actually exist on the filesystem? Look at the cue-sheet, and the Cue sheet syntax, there don't seem to be any errors in them on the article in question. I would have to bet that Kega is wrong (emulators tend to get it wrong more often--DOSBox, for example, doesn't skip the pregap if you've mounted a virtual CD using its native method, though a real CD or CD-emulators will not have these problems), there doesn't seem to be any compelling reason to believe otherwise.

  • Registered: 2008-01-15
  • Posts: 50

Nevermind. Number 2 is a non-issue, I tested it again today and it works fine.

That Kega doesn't work with REDUMP cue sheets seems to be because of the way you guys handle the addition of pregaps to the beginning of the single audio track file.

  • Registered: 2007-09-11
  • Posts: 402

Eidolon wrote:

That Kega doesn't work with REDUMP cue sheets seems to be because of the way you guys handle the addition of pregaps to the beginning of the single audio track file.

Again, they work perfectly when loaded with a proper CD emulation tool like Daemon Tools. I think it's very clear where the fault resides.

  • Registered: 2008-01-15
  • Posts: 50

Yes, somehow there seems to be confusion about the INDEX value for the audio track file.

It seems Kega uses the INDEX00 position rather than the INDEX01 position when loading the "REDUMP" CUE sheet.

INDEX00 points to the pregap silence
INDEX01 points to the audio track without pregap silence

16 Reply by F1ReB4LL (edited by F1ReB4LL 2008-01-23 00:11:26)

  • Registered: 2006-12-24
  • Posts: 3,847

Kega supports iso-mp3 and iso-wav rips without using cuesheet at all, maybe it just ignores cue in this case? Too lazy to test, though smile Or (more likely) it reads a cue file, but when it sees audiotracks as separate wav files, it plays them directly, ignoring index settings for each file.