4 ms·

> What it’s not at all prepared for is requests like “play from position 12:00:42 on the disc”. > You can probably guess what Classical Cats does! Instead of w

> What it’s not at all prepared for is requests like “play from position 12:00:42 on the disc”. > You can probably guess what Classical Cats does! Instead of working with tracks, it starts and stops playback based on absolute positions on a disc. This may sound strange, but it’s how the disc itself is set up No, absolutely not strange. This is also the way to implement some type of interactive music for games (somewhat similar to iMuse) though seek times for 1-2x CD-ROMs aren't good for that

raverbashing 3y ago
What is strange is the part where CC reads the TOC (with usual tracks) then seeks based on time Yes it would be normal if the sound was just one long track, but that's not what's happening here
- pavlov 3y ago
  Since CD audio tracks are basically just bookmarks to specific times, it doesn't really make a difference? Having those separate tracks would be quite useful to someone who wants to listen to "Classical Cats" in an audio CD player. I'm guessing this was pretty common, and perhaps even the majority use case. Fans of the musician might try the novelty CD-ROM interface once, then go back to the familiar hi-fi player in the living room.
- sumtechguy 3y ago
  The thing is it kind of is one long track on the actual layout. This kind of messed with people at first one they were ripping these discs. The tracks are basically designated by a gap. That gap can be a few different lengths of basically silence. This is sort of left over from where CD's came from the vinyl era where the disc was one long groove and the start of the songs were just basically a spot where nothing played that you could see it was secondary. So CD players though had a different issue. They could not touch the disc. So they would designate a gap zone an the player could seek to a particular timeframe which should put you in that gap. Also remember what would be 12:00 for one player could be 12:00:01 on another. So the gap had have some wiggle room. I am surprised that the scumm group did not just grab an existing disc container format like CHD (which I think is BSD3). They have solved most of these issues already.
  - jandrese 3y ago
    The gap is optional too. You can burn CDs with no gap between audio tracks. I've done this for disks that are just one continuous track. I break it up into 90 small tracks with 0 gap between them. This way if you need to pull the disc out and continue playback on a different device you can seek to the track instead of having to hold down the fast forward button for ages.
- jandrese 3y ago
  It had to read the TOC first because the compiled program wouldn't know how long the first track of the CD is until it was burned. Once they are storing the TOC in memory it's just as easy to do absolute positioning, basically doing the calculation for the drive. It's a bit more work for the developer and slightly more fragile, but it works well enough.

raverbashing 3y ago

What is strange is the part where CC reads the TOC (with usual tracks) then seeks based on time Yes it would be normal if the sound was just one long track, but that's not what's happening here

pavlov 3y ago
Since CD audio tracks are basically just bookmarks to specific times, it doesn't really make a difference? Having those separate tracks would be quite useful to someone who wants to listen to "Classical Cats" in an audio CD player. I'm guessing this was pretty common, and perhaps even the majority use case. Fans of the musician might try the novelty CD-ROM interface once, then go back to the familiar hi-fi player in the living room.
sumtechguy 3y ago
The thing is it kind of is one long track on the actual layout. This kind of messed with people at first one they were ripping these discs. The tracks are basically designated by a gap. That gap can be a few different lengths of basically silence. This is sort of left over from where CD's came from the vinyl era where the disc was one long groove and the start of the songs were just basically a spot where nothing played that you could see it was secondary. So CD players though had a different issue. They could not touch the disc. So they would designate a gap zone an the player could seek to a particular timeframe which should put you in that gap. Also remember what would be 12:00 for one player could be 12:00:01 on another. So the gap had have some wiggle room. I am surprised that the scumm group did not just grab an existing disc container format like CHD (which I think is BSD3). They have solved most of these issues already.
- jandrese 3y ago
  The gap is optional too. You can burn CDs with no gap between audio tracks. I've done this for disks that are just one continuous track. I break it up into 90 small tracks with 0 gap between them. This way if you need to pull the disc out and continue playback on a different device you can seek to the track instead of having to hold down the fast forward button for ages.
jandrese 3y ago
It had to read the TOC first because the compiled program wouldn't know how long the first track of the CD is until it was burned. Once they are storing the TOC in memory it's just as easy to do absolute positioning, basically doing the calculation for the drive. It's a bit more work for the developer and slightly more fragile, but it works well enough.