...does it really matter if that subcode data isn't changed to reflect a strict recommended *guideline* ??
It wouldn't if it were just a recomendation. It's not. See iso/iec10149, section 20.
As for example 1:
If I were to burn that and analyze it, I'd find that those 3 seconds of pregap will entirely belong to the data track (the subcode data would indicate track 2 and index 00). All the LBAs of every track thereafter will still match the original and the game will work just fine.
Yes, the pre-gap will belong to the data track. That's what you asked for, that -should- be what you get.
However, you -should- end up with a 2 sec gap after track 1, then your 3 sec pre-gap. Yes, the game would play just fine - the PCE doesn't check tracks that closely (even to the point of ignoring data track checksums, iirc). I'm not so sure the LBA's would match, though - and I'm pretty sure the time stamps encoded in the track headers would be wrong.
In such cases, and when dealing with pure audio discs (index 00 was for a pre announcement/intro before the song actually starts) you'd wanna preserve it when reading the track and that would result in something like this to burn it back:
....
Such a data track would simply have 3 seconds of extra sectors in the beginning and it would get burned back in the duplicate exactly as it was in the original resulting in a more 1:1 copy. Pregap = index 00, same thing, just that when you use the pregap command in the CUE file, the burner will determine what data is actually burned there (and not read from the file), probably just all zeros, etc.
Yes, the data track would have 3 seconds of extra sectors at the begining; I'm not so sure it would be a 'more' 1:1 copy, Because pregap != index00. Again, the iso/iec docs state that gaps are encoded as a 'pause' type sector (pq=00), whereas indexes are encoded as information sectors. They are not the same thing, though many program treat them as such.
And for the record, the burner only writes what it is given - the software determines what is in the pregaps. Sometimes it is all 0's, but not always.
It doesn't matter, at least it shouldn't. The software shouldn't try to bother to accomplish exactly what the strict guideline is calling for. All the CD-Rs that were ever burned with a CUE file like my first example work fine on real NEC hardware.
Whether such things -should- matter is open for debate; the fact is, to produce an iso standard disc as required by the pressers, it -does- matter. And yes, we've already covered that the PCE will run CDs that are not iso compliant; they work fine. That should not be taken to mean that they are 'correct' as required by the presser, however.
I've had this discussion with many, many people. They all seem to make the same mistake: Just because a particular program burns a particular disc that works does not mean the program burned it correctly. Furthermore, just because a particular cue sheet appears to give you a correctly formatted cd does not mean it is iso compliant.
Programmers are lazy: in my general experience, different progams implement the mixed-mode cd slightly differently.
Different programs create different discs from the exact same cue sheet and file. We live with it, and work around the problems when needed.
