It wouldn't if it were just a recomendation. It's not. See iso/iec10149, section 20.
If this really is the problem, it's such a minor thing and unfortunate. No burning software that I know of thought the concept important enough to allow you to burn it exactly as called for. Obviously, most standards ARE important (TOC, sector format, etc.) and need to be strictly/precisely followed because you won't have a working CD by the end of it, duh, but in this case, where you can at the very least encode a 3 second pregap with most burning software (and meet that standard), it shouldn't matter so much that the 1st second of those sectors in this pregap area (
75 sectors we're talking about) won't be flagged as type audio, just like it doesn't matter if the actual data in this area is all 0's or 1's...
If the pressing software rejects our mixed-mode CDs simply because a 3 second pregap on a data track doesn't have the 1st second of that pregap flagged as audio sectors (
when it comes to audio to data transitions), it just strikes me as way, way too damn picky is what I'm trying to say, I guess... I had just heard that the current, popular software used by pressing plants just has problems with mixed-mode CDs period and I kinda wanna know exactly what the problem is here!
the PCE doesn't check tracks that closely (even to the point of ignoring data track checksums, iirc).
Hm, that doesn't sound right, the ignoring of an EDC/CRC code. Years ago I asked David Michel (Magic Engine emulator author) about the last data track typically found in NEC discs that is mostly a duplicate of the 2nd working data track. He confirmed that it is indeed a "backup" track, that there is code in the BIOS/system that'll resort to using that track if the 2nd track suffers from enough read failures/can't be read, etc. As to the details, how many read failures/retries does it take before resorting to using the last backup track, I didn't ask, but I just wanted to know what purpose, if any, that duplicated track had. Point is, read errors of data sectors must be detected somehow for obvious reasons and for this switch to the backup track to occur, etc.
Anyway, ignoring pregaps in data tracks is one thing, it happens naturally since the TOC only stores the LBA of index 01 (
where valid user data actually begins in a track), they're supposed to be ignored content-wise (
I have heard of copy protection schemes making use of them because of this, though), but ignoring EDC codes is quite another.
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.
The LBA/Time data of the TOC will match the original if all files in the ISO/WAV/CUE image file set were read and stored properly, etc. That's not hard! If you couldn't even accomplish that, well, then a significant % of burned CD-R games (e.g. Dracula X) would suffer from numerous problems: crashes, lip-syncing issues when a cinema plays, or background music starting at the wrong time, etc. I dunno about the time stamps in the track headers that you mention, which I guess refers to the time data burned into the subchannel sectors, but yeah, the LBA/Time data found in the TOC *will* match if the original image was read properly.
Quick aside: There used to be an infamous problem with all those ISO/MP3/CUE image file sets floating around precisely because when a MP3 file is decoded back into a WAV file, the original file size is lost and you get a file that's either smaller or bigger than the original. Thus, burning that image set to a CD-R would result in a TOC much different than the original and would cause the problems I mentioned because of how a % of games are coded: Games like "Dracula X" have the LBA address hardcoded for the audio track to play, while games like "Ys IV: Dawn of Ys" dynamically obtain the LBA from the TOC, so for such games, you could replace all audio tracks with either smaller or bigger ones and it wouldn't break the game, etc. SignOfZeta once offered his own replacement soundtrack for "Lords of Thunder" because it happened to be one of the games that operates this way. Anyway, that whole ISO/MP3 craze was what led to me
creating TOC Fixer which will resize all files in your image set to what they should be so that the TOC will match the original when burned. This was another good use of the
NEC TOC Database which is what allows emulators like Magic Engine and
good ole TurboRip to detect and title a disc when it's inserted.
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,
What I was talking about was in situations where you'd want to preserve the actual data burned in a pregap as opposed to discarding it (like I currently do in TurboRip for NEC discs). The other method I showed preserves it, so if there was copy protection information hidden there, the new disc would still work, so yeah, a "more" 1:1 copy in *that* sense... Obviously, if you want a perfect 100% 1:1 copy, you need to go all the way in terms of methods with something like CloneCD and read the original disc in "RAW 96 mode" (2352 data sector bytes and 96 bytes of subchannel data), and then set the burner to "RAW DAO 96" (if supported) mode to burn everything back byte for byte. That is for copy protection schemes that intentionally burn wrong/bad subchannel data where letting the burner/software recalculate/rebuild that data will result in a non-working disc.
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.
Just how different are they beyond labeling ?? The SCSI-3 MMC docs basically state index 00 is a special index, and it defines the pre-gap or pause before the audio starts. Information sectors start at index 01. Here it is verbatim:
The CD media standards require transition areas between tracks encoded with different types of information. In addition, transition areas may be used at the beginning or end of any track. For audio tracks the transition areas are called pause areas. For data tracks, transition areas are called pre-gap and post-gap areas.
...
An index is a partition of a track. Pre-gap areas are encoded with an index value of zero. Pause areas at the beginning of audio tracks are also encoded with an index value of zero. The first information sector of a track has an index value of one. Consecutive values up to 99 are permitted. Index information is not contained in the TOC. Not all sectors are encoded with the index value in the Q sub-channel data (the requirement is 9 out of 10). A sector without an index value is presumed to have the same index as the preceding sector.
or
Every sector contains an index which is a number between 0 and 99. Index 0 and 1 have special meanings: 0 indicates a pause sector and 1 the beginning of the data in a track.
Beyond flagging the index byte as 00, what else is a program supposed to do to create further distinction ??
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.
Well, the burner's firmware is responsible for some aspects of the burning process depending on the mode. If you burn a wave file in a basic mode, the firmware is responsible for generating the subchannel data, etc. But yeah, if the mode is set to something like "RAW DAO 96," then the burning software and/or image is entirely responsible for what is written and must provide it - must come either from the image or be recalculated/rebuilt by the software. I wasn't intentionally specifying that the burner itself was handling pregap content though, I could've said "burner/software," etc. I hadn't thought about the distinction at the time.
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.
*
Here's what I wanted to ask you: Did an engineer from a pressing company specifically tell you that the 3 second pregap must have the first second of sectors flagged as audio and that this was the reason their software was rejecting the disc
I wanted to know if you were specifically told this was the problem by someone from a pressing company versus if this is your own conclusion as to why "Mixed Mode Layout fails Eclipse," etc.
This specifically:
The problem <apparently> is that the p-q codes which indicate the track type have to change at those intervals...which seems to screw with the pressing software.
(ie, the 2 sec gap has to be encoded as an audio track, while the 1 sec extended gap has to be encoded as a data track.)
I also have a suggestion for someone to try in the future. I'd be curious if it gets a different result because, now, I don't think NEC discs are actually proper. I'm gonna repaste the rule I added before:
**** 6.2.11.7. Post-gap ****
If a Data track is followed by another kind of track (such as an audio
track), this Data track ends with a post-gap. A post-gap is placed at the
end of a Data track, and is part of the Data Track. A post-gap does not
contain actual user data. The minimum length of post-gap is 2 seconds. The
drive does not perform any action for a Post-gap.
OK, here's the thing, NEC discs made what apparently should be a 2 second post-gap a pre-gap instead! Moreover, the pre-gap belongs to the next audio track, when according to this rule, it should belong to the same data track! I wonder if this is why their pressing software complains! In other words, a CUE should look like this:
FILE "01 Fighting Street (J).wav" WAVE
TRACK 01 AUDIO
INDEX 01 00:00:00
FILE "02 Fighting Street (J).iso" BINARY
TRACK 02 MODE1/2048
PREGAP 00:03:00
INDEX 01 00:00:00
POSTGAP 00:02:00
FILE "03 Fighting Street (J).wav" WAVE
TRACK 03 AUDIO
INDEX 01 00:00:00
In reality, NEC discs are actually burned like this:
FILE "01 Fighting Street (J).wav" WAVE
TRACK 01 AUDIO
INDEX 01 00:00:00
FILE "02 Fighting Street (J).iso" BINARY
TRACK 02 MODE1/2048
PREGAP 00:03:00
INDEX 01 00:00:00
FILE "03 Fighting Street (J).wav" WAVE
TRACK 03 AUDIO
PREGAP 00:02:00
INDEX 01 00:00:00
So yeah, technically NEC is wrong here... Any thoughts ?? BT ?? I believe you once said that NEC discs were not of proper format, or something to that extent... If the rule I posted is accurate, that would seem to be the case. I could be over-analyzing here and the issue is how exactly a "post-gap" is implemented.
Anyway, I had 2 final things on this:
1) Did somebody ever send an *original* NEC disc for duplication ?? I wonder if they get the same type of problems or not, etc. That'd answer some questions.
2) I wanted to offer a suggestion to Arkhan or the MS team, etc. if they can try burning a new disc with the use of a post-gap command and send that to the pressing company (like the first style that I posted) on say the next homebrew project, etc... I'd be curious if that makes a difference.
(Apologies for the long post/interruption. It's an interesting subject for me. Proper handling of indexes is something I still wanna fix for TurboRip.)
