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.
