racketboy.com

the langrisser games for the saturn have messy formats that segacuemaker doesnt automatically do for me, and the googling i've done has been inconclusive towards finding an answer. My current cue (which leads to misplaced voices, garbled music (i.e. static)) is

FILE "Track01.iso" BINARY
TRACK 01 MODE1/2048
INDEX 01 00:00:00
POSTGAP 00:02:00
FILE "Track02.tao" BINARY
TRACK 02 MODE2/2352
PREGAP 00:03:00
INDEX 01 00:00:00
FILE "Track03.wav" WAVE
TRACK 03 AUDIO
PREGAP 00:02:00
INDEX 01 00:00:00
FILE "Track04.wav" WAVE
TRACK 04 AUDIO
INDEX 01 00:00:00
FILE "Track05.wav" WAVE
TRACK 05 AUDIO
INDEX 01 00:00:00
FILE "Track06.wav" WAVE
TRACK 06 AUDIO
INDEX 01 00:00:00
FILE "Track07.wav" WAVE
TRACK 07 AUDIO
INDEX 01 00:00:00


I'm pretty sure the only thing that is wrong is the pregap on the track02. That's what the 'example CUE' i got had. But i dont know what to change the pregap to. this link: http://dcforums.co.uk/forum/index.php?showtopic=25377 says i got everything right except: "You must also make sure that track 02 starts at exactly LBA 19785, otherwise the data will shift and be rendered useless." I have no idea what LBA 19785 is though. Is that some kind of data i can convert to seconds?

I don't think any saturn games should have two .ISO files. I believe that's only TurboGraphx CD and Super CDROM^2 games.

there are quite a few but theyre mostly japanese games. it's supposed to be some form of copy-protection from that time. I've got a few (3) games in this format.

sqpat17 wrote:there are quite a few but theyre mostly japanese games. it's supposed to be some form of copy-protection from that time. I've got a few (3) games in this format.

And all they work?

Last Bronx, Nights, and Christmas Nights, and Sega Worldwide Soccer 97 all have 2 data tracks. The rest of the US titles just have 1 data track

2 data track games are a freakin' bitch.

The LBA 19785 you are referring to is "logical block addressing". Instead of stating what 'time' on the CD it starts at you state which block it starts and the size in blocks that it is. The ISO-9660 standard states a block on a CD to be 2048 bytes large. The forum you refer to is stating the SIZE of the "nights into dreams" block size of the first track on it's dual track CD.

As the thread you linked stated. Because the disk follows a non-standard format it utilizes the first track to point at the second track through the TOC (table of contents). So this way it LOOKS like a standard ISO-9660 disk to the cd-rom, but the data actually ISN'T!

Now... I don't know what size these tracks are... and 19785 won't work, that is the block size of track 1 for the USA copy of Nights into Dreams.

Your best bet is to remove the gap between the two tracks all together and burn that way so that the data is laid one right after the other. OR get yourself a cd-burning program that will do RAW/DAO mixed mode discs and construct the disk using that making sure the tracks lay one right after the other (as the cue sheet method won't work very well unless I constructed you a nice one using the sector data...)

Where'd you get this image? Can you upload it to my FTP (info in the Download section) so I can take a look at it and I can construct you a working cue sheet. Compress the audio tracks to mp3 if you need as it will decrease the upload time.

-----

EDIT: I want to add, you can't just divide the byte size of the different images to find the block size for a couple reasons. A) the image has padding which doesn't make it's size congruent to it's size on a CD and B) a half filled block on a CD is still viewed as a FULL block and will just leave blank area to the end of the block before moving onto the next track.

i actually have been doing some work on this and found out some things. Yeah, i figured out the 19k or so was specific to the Nights into Dreams example. Langrisser 4 beings track 2 at 43487 according to isobuster (changing gaps dont seem to change this, but it's at 0 seconds in gaps as i took this number) . I tried removing all the gaps between the two tracks, as you said, but the voices are still out of sync, that is, it loads completely different ones than shouild be playing, sometimes loading two clips for one message, and theyre the wrong people talking, so its way off. However, the music isnt staticky anymore, its actual music, so that seems to be right. Or maybe its loading halfway down a track and i dont even notice. It seems to be a lot better than before at last, this time at least seems to get data in the correct area of the game. Technically i wasnt even getting voices before... But still not perect.

Some other things i've noticed:

- .tao and .bin for track02 seems to work the same, even though they're different sizes. I bet this is obvious to you but i have no idea what i'm doing

- I tried RAW/DAO, and that changes things, i could notice differences in static, but it's still not perfect. Maybe i had gaps in there when i last burnt it in raw/dao mode, though, so i should try that. (using alcohol 120).

- Recently i've gotten an emu working to waste less CDRs by playing mounted images, but i dont think you can use a virtual drive to burn an image onto, so i cant try the raw/dao there, ill just burn another disk i guess.

Anyways, I think I'll take your offer (especially if the RAW/DAO burn without any gaps doesnt work when i try it again) since ive spent all day and have gotten closer and closer but cant quite figure it out. I'll try to learn from it since i have another game or two with that format. Thanks. (The image i got was from snesorama, but you might not want to bother with that place as its annoying to go to rapidshare links and such...)


sorry if the post was illegible.. i went back and forth changing things a lot.


EDIT: Looks like i'm uploading. Didnt work, but there was a difference compared to the other methods i did.

I just started working with the file right now.

I've gotten burns that give me voices. Though the voices don't match who is talking. I took a look at the sectors and found out the problem. The first track is only 41087 blocks long, but when burning it looks like 41237. So it places track 2 at the start point of 41237. All you've got to do is change that so it starts at point 41087.



Oh yeah, and 75 blocks is equal to 1 second. This sucks though because that means that one block is equal to 4/3 milliseconds (1.33333333333... milliseconds. The downside to this is that you can not write time stamps in the form of decimal milliseconds. This means you can only write a time stamp for block numbers divisible by 3 giving you nice round numbers of 4 milliseconds per 3 block portion.

That reminds me, it'd be nice if they'd make a base 60 calculator. you know, like the babylonians and shit.