SpritesMind.Net

As I was reading official docs (see attached pictures), I had some trouble figuring exactly how it was related to the TOC informations returned to the BIOS by CDD (CD drive processor).

From what I gathered:

1) there is a fixed 2 sec PREGAP (index 00) at the start of DATA track (track 01)

2) there should be a minimal 2 sec POSTGAP (index 02) at the end of DATA track (track 01)

3) there should be a minimal 2 sec PREGAP (index 00) at the start of each AUDIO track

4) there should be a minimal 2 sec POSTGAP (index 02) at the end of last AUDIO track

5) the first logical sector (LBA=0) starts at DATA track index 01 (00:02:00) and the last logical sector ends just before last AUDIO track POSTGAP (max. 60:01:74)

Is that correct ?


Now, I was wondering what effect it really had on the MSF informations returned by CDD on TOC reads (which I assume are directly retrieved from channel Q subcode data by the CDD processor) and especially:

1) does start of track returns the absolute time with or without PREGAP ? For the data track, it seems that emulators automatically add the 2s PREGAP and return 00:02:00 as track start MSF, but what about audio tracks ? Should be the same right ?

2) does track length includes POST-GAP for data track and last audio track ?

3) is total length the sum of all track length (without PREGAP) or does it includes PREGAP as well ?


I also tried to analyze various CUE image files coming from different places and it seems there are big discrepancies between TOC informations for a single CD image:

- none of the CUE files include DATA track PREGAP (i.e first track always starts at 00:00:00 which is inaccurate but it probably works because CD burn programs & emulators automatically add it anyway), DATA track or last AUDIO track POSTGAP (maybe directly included in the CD image file(s) through a bunch of zeros ?).

- some use PREGAP command, while some others use INDEX00: i believe the former indicates that the pause is not included in the image file but that it exists anyway, while the latter indicates that there are two indexes stored in the image file (with the first one always being filled by zeros ?). In fact, it seems that PREGAP is sometime only present for first audio track (track 02) which makes me think there is a confusion with Data track POSTGAP.

- some CUE files (mostly coming from redump.org) have PREGAP/ INDEX00 fields that are less than 2 seconds (generally 00:01:74): this does not respect the Red Book standard and I cannot believe there was so much different CD burners at this time to got inconsistencies like that. It seems to me it's a mistake from the CD drive when dumping the CD or a result of wrong method applied when dumping CD images (seems like the method posted on their forums involves playing with specific drive read offsets, though I am not sure to understand the theory behind this and if this is correct or not).

Can these discrepancies be explained by faulty or mis-configured CD dumping softwares ? Can all CD drives/software detect PREGAP/POSTGAP correctly using the track index (00,01,02,...) or other infos in the sub-code channels ?

Eke wrote:- none of the CUE files include DATA track PREGAP (i.e first track always starts at 00:00:00 which is inaccurate but it probably works because CD burn programs & emulators automatically add it anyway), DATA track or last AUDIO track POSTGAP (maybe directly included in the CD image file(s) through a bunch of zeros ?).

This is the lead-in area. It is never ripped because 99.99(...)99% of the time it's all zeros anyway. Some formats include them (NRG, CDI, I think), but I'm not sure if the data included here is read from the disc and not pregenerated empty padding - the mentality here is that if it's all zeros all the time, why even bother ripping them?

CUE sheets can't store 1st data track pregap for this reason - it's pointless, and always 2 seconds in the standard anyway.

Some audio cds DO have hidden tracks in the 1st track pregap, which is why you have EAC and it's nonstandard cue sheets that can read and store these, and it only works on some drives.

- some use PREGAP command, while some others use INDEX00: i believe the former indicates that the pause is not included in the image file but that it exists anyway, while the latter indicates that there are two indexes stored in the image file (with the first one always being filled by zeros ?). In fact, it seems that PREGAP is sometime only present for first audio track (track 02) which makes me think there is a confusion with Data track POSTGAP.

Pregap in a cue sheet means that the data between INDEX 00 and INDEX 01 is not included in the image, and should be "padded out" logically in that area with zeros. So if you read that area from a mounted image, or from your bin/cue that you burned back to a disc, you get zeros.

I think, PREGAP is strictly a cue sheet command, because the information specified this way is still considered INDEX 00 from the red book standards point of view, which does not mention pregap by word anywhere (it calls index 00s as "pause before the track").

INDEX statements are sorts of secondary track indexes. If you have an real cd player and some older discs, you'll see that between track switching, the player will start counting back from -2:00. This is the Index 00 at work. Index 01 is the actual start of the track, same address as the TOC entry of that track. Index 02, 03, 04 are possible but nowadays very rare, they are like "tracknumbers within tracknumbers". Some classical discs use them to specify individual movements in one composition and such. I've heard of a very early classical CD that had only a single gargantuan track, and navigation was only through indexes - there's a thread about it at Hydrogenaudio if you search.

- some CUE files (mostly coming from redump.org) have PREGAP/ INDEX00 fields that are less than 2 seconds (generally 00:01:74): this does not respect the Red Book standard and I cannot believe there was so much different CD burners at this time to got inconsistencies like that. It seems to me it's a mistake from the CD drive when dumping the CD or a result of wrong method applied when dumping CD images (seems like the method posted on their forums involves playing with specific drive read offsets, though I am not sure to understand the theory behind this and if this is correct or not).

They are mastering errors. There are also 2:01 ones and such. Tolerable margins of error to the standard 2:00 value. You don't see them often because not all drives can read subcodes, and fewer application can READ subcodes properly (even applications that rip subcodes, like CloneCD, generate Q subs from P subs, or the other way around, I forgot).

The 2:00 gaps are required to get around the fact that you can't address a sample directly on the red book standard. You can address a sector through MSF values in the subcode, but the laser will only pick up what the drive THINKS is the first sample of that sector. And this sample may be as much as 2000 samples later or earlier than it should be. See the gigantic clusterfuck called "audio offset correction".

I believe that the yellow and red books required these 2 sec pauses to get around this problem. Most importantly, so you don't end up reading part of a descrambled data track when addressing the following/preceding audio.

So the mastering standards Sega set it more of a safety precaution, rather than limitations of the Mega CD BIOS commands and such. The pictures you linked to even mention this however!

Can these discrepancies be explained by faulty or mis-configured CD dumping softwares ?

For the pregap vs index00 in the cuesheets, yes, the difference is because nearly all ripping apps save this data differently. Pregap entries in the cuesheet are logical "all zeros", while INDEX 00s mention that the data from here to there is the pregap (so they include the data in the rip).

Can all CD drives/software detect PREGAP/POSTGAP correctly using the track index (00,01,02,...) or other infos in the sub-code channels?

Not all drives can read subcodes equally. Some can't at all, some can only read certain subcode channels (so you can read track indexes from the P/Q channels but not any CD+G data) and so on. And then you have the software side of things which is even more chaotic.

1) does start of track returns the absolute time with or without PREGAP ? For the data track, it seems that emulators automatically add the 2s PREGAP and return 00:02:00 as track start MSF, but what about audio tracks ? Should be the same right ?

2) does track length includes POST-GAP for data track and last audio track ?

3) is total length the sum of all track length (without PREGAP) or does it includes PREGAP as well ?

I am unfamiliar with how the Mega CD drive seeks to data, but logically the track lengths should all be computed from the TOC values, otherwise the drive would have to analyze the entire disc when loading.
The TOC values match the INDEX01 entry of a track, irregardless of gaps or additional indexes. I believe this is specified in the red book. I don't know what would happen if the two mismatch, I imagine that different CD drives would behave differently (or create a quantum singularity and cause the solar system to implode).

I'd like to see those Mega CD docs you mentioned. I only have Saturn era hardware docs.

Thanks for the clarifications.

Huge wrote:
This is the lead-in area.

Well, according to the image I posted, the 2s pause before first logical sector is part of the program area, not read-in. But I agree it is most likely ignored in CUE files because it's there by default (same goes for last audio track POSTGAP probably), although DATA track is starting at 02:00, not 00:00 as it is indicated in cue sheets. .

Still, that does not explain why the DATA track "POSTGAP" is ignored or confused with first audio track "PREGAP". According to this spec, there should be a 4s pause between the end of the last sector of data and the first piece of audio. I don't think it's really important for emulators or real hardware as the BIOS only seek a few blocks before reading/playing the desired track so 2s pause is enough, but I think the way it is dumped in cue sheets (which is used to determine what is returned when BIOS is reading TOC) is not accurate.

Pregap in a cue sheet means that the data between INDEX 00 and INDEX 01 is not included in the image, and should be "padded out" logically in that area with zeros. So if you read that area from a mounted image, or from your bin/cue that you burned back to a disc, you get zeros.

I think, PREGAP is strictly a cue sheet command, because the information specified this way is still considered INDEX 00 from the red book standards point of view, which does not mention pregap by word anywhere (it calls index 00s as "pause before the track")....

Yes, I know what INDEX are and that PREGAP is a term originally defined by CDRWiN and only used by cue sheets , I just wanted confirmation that it was the same as INDEX 00 except that the "pause" data was not included in image file.

They are mastering errors. There are also 2:01 ones and such. Tolerable margins of error to the standard 2:00 value. You don't see them often because not all drives can read subcodes, and fewer application can READ subcodes properly (even applications that rip subcodes, like CloneCD, generate Q subs from P subs, or the other way around, I forgot).

For the pregap vs index00 in the cuesheets, yes, the difference is because nearly all ripping apps save this data differently. Pregap entries in the cuesheet are logical "all zeros", while INDEX 00s mention that the data from here to there is the pregap (so they include the data in the rip).

Not all drives can read subcodes equally. Some can't at all, some can only read certain subcode channels (so you can read track indexes from the P/Q channels but not any CD+G data) and so on. And then you have the software side of things which is even more chaotic.

Hum, so basically, none one these dumps that claim to be binary accurate are really accurate. I think that it would be sufficient to only dump binary (mode 1) and audio (cd-da) data, wihout the pause since detecting them vary upon drives, then build the cue sheet using Mega CD disc specification (respecting PREGAP and POSTGAP minimal pause). It would be as much accurate and probably more close to original mastering.

I am unfamiliar with how the Mega CD drive seeks to data, but logically the track lengths should all be computed from the TOC values, otherwise the drive would have to analyze the entire disc when loading.

well, forget about that, the CDD only return the number of tracks, the total length and the start address for each track and it indeed get this from the TOC in the Lead-In area. There is no track length information returned and it must be computed by software.

other infos returned are absolute time, relative time within a track and current track number, which are most likely returned from reading Q-channel subcode

The TOC values match the INDEX01 entry of a track, irregardless of gaps or additional indexes. I believe this is specified in the red book. I don't know what would happen if the two mismatch, I imagine that different CD drives would behave differently (or create a quantum singularity and cause the solar system to implode).

Yes, that is what I thought too, so basically if I have a binary track which start at 00:02:00 and which length is 01:00:00, first audio track should start at 01:06:00.

I'm still not sure about total length returned by TOC, it probably refers to the last frame of program area (including 2s pause at the end) instead of the last sector. I guess it'd be easy to check by inserting a Mega CD disc into a CD player or go into the BIOS menu.

I'd like to see those Mega CD docs you mentioned. I only have Saturn era hardware docs.

They are available online. Check this thread: viewtopic.php?t=375

or directly here: http://koti.kapsi.fi/~antime/sega/md.html

Well, according to the image I posted, the 2s pause before first logical sector is part of the program area, not read-in. But I agree it is most likely ignored in CUE files because it's there by default (same goes for last audio track POSTGAP probably), although DATA track is starting at 02:00, not 00:00 as it is indicated in cue sheets. .

You are right, I was wrong (was checking red book only, not yellow book).

Lead-in = TOC. Not directly rippable, but possible to generate as drive firmware returns it.

Pregap is MSF 0 to 2:00, or LBA -150 to 0. It is not included in (some) cd images because most drives can't read them, and it's all zeros anyway - either in data sector format or audio sector format, but the user data is zeros either way.

Audio tracks with stuff hidden in the 1st pregap may have a pregap longer than 2 seconds. I really wish I had a disc to test this with. I even passed up on buying one, since I didn't knew it had such a hidden track in it.

Still, that does not explain why the DATA track "POSTGAP" is ignored or confused with first audio track "PREGAP". According to this spec, there should be a 4s pause between the end of the last sector of data and the first piece of audio. I don't think it's really important for emulators or real hardware as the BIOS only seek a few blocks before reading/playing the desired track so 2s pause is enough, but I think the way it is dumped in cue sheets (which is used to determine what is returned when BIOS is reading TOC) is not accurate.

I just re-checked the yellow book: data track pregaps and postgaps are defined there as requirements. Post-gap is defined as:

c) Post-gap :
A last part of a Digital Data Track, not containing user data, and structured in Sectors. It has the length of at least 150 Sections (at least 2 s). The setting of the Control field of the q-channel and the setting of the Sector Mode byte are identical with those of the part of the track where the user data is recorded.

So postgap is at least 150 data sectors with no data in them (all zeros), following the last data sector that actually has data in them. This is certainly ripped in any bin/cues I have right here. More importantly, data track pregap/postgap is defined in the yellow book, Sega is just following that standard here.
2 second pregap/pause for the first audio track is also mentioned in the red book. So again, Sega is following the standards.
As for 2 sec pregaps for preceding audio tracks, these are not red book requirements as far as I can tell, but something Sega enforced. Either because of the offsetting problem, or so there's a clear end to each audio track (a cosmetic procedure).

Hum, so basically, none one these dumps that claim to be binary accurate are really accurate. I think that it would be sufficient to only dump binary (mode 1) and audio (cd-da) data, wihout the pause since detecting them vary upon drives, then build the cue sheet using Mega CD disc specification (respecting PREGAP and POSTGAP minimal pause). It would be as much accurate and probably more close to original mastering.

TOC and user data can be preserved mostly fine with any drive. Pregaps are more difficult due to limited subcode reading, but not impossible with proper software and hardware. BIN/CUE does this already to a degree, it's just that most ripping applications don't do subcodes in a good way or any way. The fact that cd drives see subcodes differently is another issue here - some see pregaps through P subs, some through Q subs, and so you may end with a drive seeing 1.74 while another is seeing 2.03.

Just because Sega says there should be x seconds of gap, that does not mean that all games had that much. The Saturn also had the same exact requirements regarding gaps, and:
- Exhumed (PAL) has 2 sec data postgap, and 2 sec pregap for all audio
- VF Kids (PAL) has 8 sec data postgap, and a 2 sec pregap for all audio
- X-Men Children of the Atom (PAL) has 5 sec 67 frame postgap, 2 sec pregap for the first audio track, and no pregap for the other audio tracks

So if you want to be close to the original mastering, you have to remember those masters can be flawed as well.

This is not taking crap like audio offset correction into account by the way, which no public bin/cue ripper does. That's why Redump uses 2631873 different tools.

I'm still not sure about total length returned by TOC, it probably refers to the last frame of program area (including 2s pause at the end) instead of the last sector. I guess it'd be easy to check by inserting a Mega CD disc into a CD player or go into the BIOS menu.

Llead-out MSF minus first track MSF? Both are there in the TOC. Seems the fastest way to me.

Thanks for the docs.