If a PCE CD game uses CDPLAY with the track argument, instead of start and end LBA sectors, you need an end track for it to work. This is why some games wouldn't play the audio last track, since the end track didn't exist for that request (cue needs to be fixed). I did this for the Megaman CD audio routines (used the first data track as the last track as well). It doesn't matter if the last track is audio or not - just that it exists.
Ah, I see. So CDPLAY, the dynamic track play method (since it'll fetch the start LBA from the TOC), needs an ending marker, which yeah, you get by using the start of the next track and subtract off pregap sector markings if need be.
Interesting thing, I did solve the problem with the last audio track by adding a POSTGAP 03:00 to the CUE file when I used to share Ys IV images without the backup tracks to compress them better. That also served as a solution somehow instead of putting data track #32 back with its 03:00 PREGAP command.
Nowadays though, I wouldn't do that, there was a smarter way. Just copy a translated/patched data track #2 to data track #32, and then resize it to what the original size is, case closed. I still get a more compressed archive of one data track and all its audio tracks. And when the batch file unpacks all the APE zipped waves, it will copy the data track to track #32 and resize it proper.
If you think about it, it ought to work properly without an extra track, it should be smart enough to use the Leadout LBA for the final track. Think about audio CDs. It plays them correctly on the other hand. I guess CD player code does advanced analysis on the TOC but that doesn't happen with general game code or something.
the data track repeated as the last data track. There is a function/setup in the bios that holds the LBA offset of a redundant track - in case the primary track is have issues with data reads. The game can theoretically use the alt LBA offset to read from the redundant track instead. Whether any game actually does this or not, I don't know. But the software is there and setup for it (for those games that use that layout). Good to know of you're hacking games.
Yeah, I learned that long ago from David Michel who assured me it's a backup track and the design is there to read sectors from it if the first data track #2 starts to encounter read errors.
It's a fine idea I guess, but not really needed if discs are properly maintained. I suppose if you have the space, it doesn't hurt.
Incidentally, they ran out of space for Ys IV and fully maxed out the CD! Every last byte that you can burn back then was used up! Most of the ADPCM voice-acting is clipped out when it comes to track #32, so it really wouldn't do any good if track #2 went bad and the system switched to using track #32 throughout the rest of the game. I would presume it'd eventually crash when it came time to play the voice-acting, or you just won't hear anything when it tries.
EDIT: HomeBrew Block added. If a user tries to rip "Pyramid Plunder" or "Insanity" by Arkhan's/OldMan's Aetherbyte Studios, the attempt is aborted and a browser is opened to their website (
http://www.aetherbyte.com/). This is just a minor courtesy until their pressed CDs sell out. Somebody asked me for help to try to pirate this and I declined; let the CDs sell out first out of courtesy before wanting to make your friends happy by uploading it to them or to ROM sites...
