What is a post-gap for one track is also the pre-gap for the next.
Hah, yes. I remember finding that out and thinking wtf???
Yeah, they wind up in the same position (a waste of space in my book), but at least a post-gap doesn't cause the complications a genuinely flagged pre-gap does when it comes to track type transitions (audio to data and vice versa). I remember all the damn read errors I used to get when trying to rip a NEC disc in file-per-track mode using CDRWIN, ISOBuster or whatever else. Nothing could do it automatically. Eventually I learned how to use CDRWIN's "Sector Selection" option where you can specify a Start and End LBA to rip a track. So for track 1, Start=0 and End=Track 2's LBA minus 3 seconds (225 sectors), etc. Repeat for track 2, but minus 2 seconds (150 sectors), etc.
I understand now why reading the whole disc in RAW mode worked for every program with no read errors. You don't set the sector type filter flag in the SCSI/MMC Command block in that case. It was years later that I figured this out, but it took developing something like TurboRip to understand it. So what's happening is when you're just asking to read track 1 as an audio track, the program sets a filter flag for only audio sectors and it assumes track 1 ends one sector less where track 2 begins, so it just reads all the way... Well, with NEC discs, you got that damn pre-gap there, and the 1st second of the sectors are flagged as type audio, no problem there, but the last 2 seconds are flagged as type data, so THAT'S where the program will fail out with a read error! When it hits that point... I used to think the sectors in that area were unreadable, but I finally figured it out! That might be true for REALLY old, shitty CD drives from the '90s (should be rare), but yeah, those sectors should be perfectly readable!
Why even have a post-gap cue sheet command. And not all burning software treats it the same. Most burning software puts the post-gap command of the last track as the pre-gap for the next. If you use both, it's probably just a gamble as to how each burning software treats it at that point. Might create a third index (supposedly legal) on the track and pad with 0x00. As far as post-gap goes, nothing in either red book or yellow book docs ever mentioned it. So I just chalk it up to some legacy cue sheet command or some such crap.
I would think it's somewhere in Yellow Book, the official version, but you can find info on page 18, section 20 of the
ECMA-130 PDF which is the freely available version of the Yellow Book format. This stuff:
Track structure of the Information Area
...
For the purpose of linking Information Tracks in the Information Area, these tracks may have:
a) Pause : A part of an Information Track on which only control information but no user data is recorded.
b) Pre-gap : A first part of a Digital Data Track not containing user data and encoded as a Pause. It is divided
into two intervals:
- first interval: at least 75 Sections (at least 1 s) coded as the preceding track, i.e. the Control field
(see 22.3.1) of the q-channel (see 22.3) and, in case of a preceding Digital Data Track, the setting
of the Sector Mode byte are identical with those of the previous Information Track;
- second interval: at least 150 Sections (at least 2 s) in which 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 user
data is recorded. In this interval of the Pre-gap the data is structured in Sectors.
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.
I do remember the red book and yellow book documents stating that you can more then two indexes to a track (whether CD players do anything with it, I dunno. Never tried to test it).
Yeap, you can have 99 tracks and each track can be subdivided from 00 to 99. From the same document:
22.3.3.2 INDEX field
This field contains an Index specifying the subdivisions of an Information Track.
Index 00
This value of the Index indicates that the Section is coded as a Pause. The total length of the Pause corresponds to the number of consecutive Sections with Index set to 00.
Index 01 to Index 99
These values specify the indexes of the subdivisions of that part of an Information Track that contains User Data. The first subdivision shall have Index 01. Consecutive subdivisions shall have consecutive Index values.
The Index field of the Lead-out Track shall be set to 01.
You gotta read and process the Q subchannel data per sector (audio/data) to know what's going on for this stuff. Processing this in a program like TurboRip translates to the 16 byte "C" structure below. I use a MMC1 command to read the Q data of the sector to load it up. Quick example: say you're reading the warning audio track 1 of a mixed-mode NEC game disc. Towards the last 3 seconds, you'll find that the TrackNumber field will have changed from 1 to 2 and the IndexNumber will go from 1 to 0, hence, you will have detected a pre-gap that belongs to track 2, the next track, etc. So that's how you'd know you're at the true final LBA for track 1. Normally, you look at the next track's LBA from the TOC and subtract 1, but this pre-gap crap added complications to where you must read sectors and the subchannel data to properly detect the true stop/end LBA of a track. That's why I hate the concept and don't see much use for it... Add to the fun that most drives convert the BCD to HEX for you, some don't, so after > 09 you gotta be checking for that when it comes to this Q data.
struct SUBCHANNEL_SUBQ_DESCRIPTOR {
BITS ADR : 4;
BITS CONTROL : 4;
BYTE TrackNumber; // Warning: CD Device inconsistency in returning Hex or BCD values
BYTE IndexNumber; // Coding must do BCD/HEX checks before determining data is invalid
BYTE Min;
BYTE Sec;
BYTE Frame;
BYTE ZERO;
BYTE AMIN;
BYTE ASEC;
BYTE AFRAME;
BYTE CRC1;
BYTE CRC2;
BYTE Reserved1;
BYTE Reserved2;
BYTE Reserved3;
BITS Reserved4 : 7;
BITS PSubCode : 1;
};
I will send you an email with a text document explaining things as I see them. PM me your e-mail, please.
Sure, just click my profile, the E-mail is visible. If you had PM'ed me, I would've gotten an E-mail too.
P.S.
If you have the official Yellow Book PDF, or the others after that, by all means, send away.
It could help TurboRip in the future. Been looking for that, but I've managed enough with the EMCA stuff and what the T10 group releases.
You can have more than one index per track. This was used (for example) to allow you to seek to a particular movement in a symphony. The entire symphony would be recorded as one track, with different movements as indexes in the track. The guy who designed the original CD layout was a classical music buff.
(Which, incidentally, is where the size of a cd comes from. It had to have enough space to hold a particularly long symphony, because he didn't want to have to change the disc.)
Yeap, I had just read about that a few days ago (the symphony movements basis for the idea). I knew what the purpose of index 00 was with an audio track, you could put an announcement that normally gets skipped over when you're using the Back/Forward track selection buttons on a CD player. I recall actually seeing this in action; the current track is playing and when it gets towards the end, the announcement or whatever begins for the next track, you also have a negative time countdown to when said track is about to start, etc. However, I was puzzled about 5 indexes I saw on a PC-FX data track some time back (
something David Shadoff reported to me) and I didn't know what further or useful purpose that could provide. Until I get TurboRip to work with such a disc, I can't certify it for use with them.
Anyhow, when it comes to audio tracks and CD players, I would wager the way it works is you use the forward seek buttons (not the track skip) and when it hits a change in the index number flag (it can only increment by one), it probably stops seeking forward even as you're holding it down and playing resumes. I would guess then you have to release and press it down again, let it seek forward some more and if it hits another increment of index number it stops seeking and plays normally, assuming it doesn't get to the end...
That idea reminds me somewhat of AMS (Automatic Music Sensor) or whatever it was called for cassette players (anybody remember those??). If you leave 2-3 seconds of blank space before recording the next song, you would have decent seeking capability. When you press the forward button and it stays down, it'll forward the tape and if it detects those 2-3 seconds of silence, the button will pop up and playing will resume, etc.
Anyway, I never saw a music CD that took advantage of this... Of course,
like this list of hidden songs/tracks in the pre-gap, it's something I could've easily missed even if it was there. Since you can have 99 tracks, you might as well just put the next symphony as its own track making it always fully accessible with the track select/skip buttons and not having to waste time with seeking, etc. You can see why it didn't get used much, if ever, even though it was implemented cause it seemed like a good idea at the time to the designers...
Not really. There is a reason the p-q bits have to be set that way....
Well, we'll have to agree-to-disagree on the value or importance of "decorative" pre/post-gaps when it comes to audio/data track transitions, much less the different flagging of sector type within them. I see all the negative issues/problems that this concept/idea caused and I can't really think much of a benefit...
I did not mean that the pce ignores the error correction
OK, you had me worried there. If I read your original point back, it sounded that way, saying the PCE doesn't check tracks closely, that it ignores the checksums (AKA EDC codes ?), etc. You were trying to point out why you think our burned CD-R discs work anyway, even though they're not totally accurate with regards to this extended 3 second pre-gap issue. But the reason it doesn't care how well that pre-gap is formatted is because, a) it's supposed to be ignored in principle, b) the TOC only ever has the LBA of the first sector that's flagged as index 01. The PCE finds the first data track in the TOC, gets the LBA and wherever that points to is where it boots. As far as it cares, that 3 second pre-gap belongs to track 1 (the warning audio), and not track 2:index 01 where it booted, where the TOC led it to...
Anyhow, this is not out of lack of thoroughness, not checking things too closely. It's natural. Ultimately, my view is this gap crap is "decorative" for track type transitions and hence my feeling that the software at the pressing plant shouldn't care that deeply about how a pre-gap was formatted as far as proper flagging of sector type, etc. It should be good enough that 3 seconds of pre-gap was specified, indexing was all set to 0, and one sector type was chosen for formatting, etc.
There's only one problem with that. You may have either a pre-gap or a post-gap, but not both.
Hmm, I never had a problem burning such a CUE file with both. True, I'd have to examine the disc after it is burned to see exactly how the software implemented it if I wanted to know. CDRWIN and ImgBurn both accept such a CUE file. Sounds like CDRDAO rejects it, your choice software for burning ?
Well, looking at CDRWIN's Help file, it specifies that only one PREGAP command is allowed per track and it must appear *before* any INDEX commands. While POSTGAP commands must appear *after* any INDEX commands, one-time use also. Makes sense. Logically, I see no reason to disallow this and I never saw anything about it in the ECMA or MMC docs I've had - notice, if it was true, it would contradict the rule I posted earlier if you could not use a post-gap when transitioning from audio to data and right back to audio, etc.
Anyway, since the same 2 seconds of space will be created whether one uses a pre-gap command with the next track or a post-gap command at the end of the prior one (in our NEC situation), the LBA offsets are maintained, so it won't change the TOC. What will change is the subchannel data; the track/index fields and what the sectors are flagged as, audio or data (in our situation of a NEC disc), etc.
Also, just for completeness, if you use Index 0, you may not have a pre-gap.
Correct, that'd definitely be a contradiction/confusing if allowed. If you use the INDEX 0 command, you're asking to read the "pre-gap" data from the track file itself (That's almost verbatim from CDRWIN's Help file). While a PREGAP command will burn in a new Index 0 using undefined data generated by the software and the track file will come after. But yeah, that's a genuine mistake.
Please keep this one simple fact in mind: Burning CDs is largely a software matter.
Without access to the source code for *all* the software, things may be happening that you don't see. The data can be modifed by the control program, the cd drivers, and the cd burner firmware. Not all pieces play by the same rules.
Certainly, I agree, no disagreement there. Never was. You answered my feeling though that the 3 seconds of pre-gap having sectors flagged half data/half audio probably wasn't the reason for the problem with the pressing plants. I have an idea for solving it if was, though. Something like: 1) Burn a CD-R like you normally do, following the basic rules, 2) Use CloneCD and rip it back in "RAW 96" mode, 3) Examine the .sub file and calculate where that 3 second pre-gap begins, 4) and basically, for 75 sectors, you'd have to flag them as audio (they'll be set as 'data'). You *could* do this, but it'd be tricky, maybe even write a simple "C" program to do it programmatically each time. You get the idea... So, quite a pain in the ass if you *had* to do it... When done, you'd obviously burn that edited disc image back using "RAW DAO 96" mode and that would be the CD-R to send to the company, etc.
(Totally off topic, I know, but useful info for us tech heads possibly)
I made my son (pushing 11 years old) play Loop v2 the other night, and after one game his reply was "I don't like you."
Heh.
I received about 50 pre-orders.
I must say, I am impressed at your sales figures already for this and a reprint at that. If I thought one day, "
I know, I'll make an asteroids-like game that I can sell", I just wouldn't believe I could find somebody that'd wanna buy it. Download it off of me, sure, but to actually pay me money, that thought never would've entered my mind... Congrats, you did it though!
