1

I have noticed that Sega Saturn MPEG games have the wrong info.  I am currently working on an application that rebuilds Sega Saturn CDs (for purposes of patching)  and I have noticed that of the discs I have checked (Lunar SSSC and Gungriffon 1 JP) have incorrect track lengths and pre gaps.  This info is derived from the actual file table located on Track 1 along with the TOC.  It may have to do with the ripping program having trouble handling the difference in mode 1 and mode 2 tracks.

For Lunar SSSC,  Track 3 should be 26,217,744 bytes and track 4 should be 1,874,544 bytes.

For Gun Griffon, Track 1 should be 81,868,416 bytes and track 2 should be 70,550,592 bytes ... among others being incorrect.

When i did my dump of Lunar tonight, i got the following:

Track 3:
25867296

Track 4:
1872192

Sarami may need to be brought in

I don't get notifications from this forum, and i don't often check PMs here as a result. If you need to reach me, please just email me or contact F1ReB4LL.

Logs, please.

Sarami, i can forward the logs of my dump if that helps, but Knight's issue isn't directly with the dump produced so much as an issue of all MPEG games. He'll be the person who needs to explain his issues.

I don't get notifications from this forum, and i don't often check PMs here as a result. If you need to reach me, please just email me or contact F1ReB4LL.

I got Lunar MPEG version recently.

Here's logs if it helps.
https://cdn.discordapp.com/attachments/ … n_Japan.7z

6 (edited by A Murder of Crows 2021-01-16 10:55:10)

This came from Knight0fDragon:


ok, now that I have some time, I can explain the issue. 

So I have developed an app that is designed to make patching Sega Saturn games as simple as possible. 

What it does is basically extracts all the files from a disc, and then rebuild the files to generate a new ISO.  One of my conditions was that if you just pressed build without applying any patch, it must rebuild the disc perfectly. 

Well, upon first working with MPEG games,  I would come to find out that the CUE SHEETS on REDUMP would lay out the track info incorrectly. 

A good example would be Lunar Silver Star Complete. 

If you take notice,  the last track would be listed with a pregap of 149 sectors (1 minute: 59 seconds, 74 frames).  This came across as weird to me.  Well upon further investigation,  it seems that the issue is with how XA data is handled.  With sega saturn games, Track 1 is always Mode 1 data.  Beyond that, it could be either Mode 2 XA, or audio.  Now the thing with Saturn, some games have files called CDDA files, and the MPEG games have obviously MPEG files.

If you try to open these files, your system should yell at you.  The reason behind it is because in the Mode 1 track's file table, these files are listed as XA files, meaning they have extra information on them, but Mode 1 has no idea how to read them. 

The Saturn, however, does. 

Now another thing:
- Mode 1 data is 2048 bytes. 
- Mode 2 XA and Audio are 2352 bytes. 

So you need to adjust the LBA and the file size to account for the difference from 2048 to 2352:

Basically you
- take the sector size and multiply it by 2352 to get the proper address,
- and you take the size, divide by 2048,
- and multiply by 2352 to get the correct size.) 

Now, when you do all this math,  it ends up giving the correct positions for the pregaps in the CUE sheet.

Since you guys are all about accurate preservation, I figured it may be a good idea to let you know that perhaps these issues are coming up. 

If you head over to Sega Xtreme you can grab a copy of my app
https://segaxtreme.net/resources/sega-s … atcher.73/ 

Test it with lunar star story MPEG and build a CCD.   

On my CCD, you will notice
- Track 3 index 1 points to 244,897, and
- Track 4 index 0 points to 255,744. 

If you go to the REDUMP,
- Track 3 index 1 points to 244,897, and
- Track 4 index 0 points to 255,745. 

In the File table,
- CDDA1 points to 0x03BCA1 (244,897) with a size of 0x0152F800 (22,214,656) 

Now if you divide this size (22,214,656) by 2,048, you get 10,847.
244897 + 10,847 gets you 255,744, which is where Track 4 Index 0 should point.

I don't get notifications from this forum, and i don't often check PMs here as a result. If you need to reach me, please just email me or contact F1ReB4LL.

It's a standard Victor/JVC ringcode pregap disrepancy (x:74 for Q-channel, x:00 for P-channel), we're using the Q-channel gaps, the best solution for you and your converter would be to round them to x:00, I think.