I've done quite a few CDs and have A LOT of advice on this subject. Of course all of it is dependant on exactly what type of project you are trying to put on CD. For example, if the program has sections of material that are likely to be accessed in a linear fashion by the user, then make certain that all of that material is in the same library. Often people divide their libraries by sounds, graphics, text, etc. The problem with this is that the CD needs to jump back and forth to read from these different libraries if, for example, it needs to show a graphic and play a sound at the same time. What happens is that your program runs r_e_a_l_l_y s_l_o_w. So, if it most likely that a user will see certain material together, make sure it is in the same library.

As far as a small apw file vs large, I always opt for the smaller file. The whole purpose of the CD is so that you can have a lot of material available without loading it on the user's hard drive. So, a small apw that pulls from libraries on the CD is your best bet.

O.K., I guess I opened my big mouth and now I have to deliver. Since a LARGE number of people seem interested in how to go about optimizing CD-ROM/APW projects, I decided to post this information to the list. As I have time (always in short supply), I'll try and answer specific questions and give additional general advice.

First, let me warn you, each project is different. What your program does affects how you set up the final project on CD. A program that uses lots of video is quite a bit different that one that uses still images. The method I use to get a handle on CD performance is to try and state how the program will be accessed. For example:

1) The user sees the title screen
2) Next the user is at the main menu and can select from five topics
3) It is most likely that the user will pick the topic button at the left/top of the screen
4) Once in a topic, the user will most likely access the material in 3 linear segments
5) In topic 5 the user will access a series of 300x300 pixel graphics with a continuous audio track
6) In topic 2 the user will view 3 video segments, each about 2 minutes long

From the statements in this example we can determine a few things about our project. You need to decide what stuff requires quick access (copied to hard drive during installation) and what stuff can be read off the CD. Items that are displayed many times throughout the program need to be on the hard drive. So, almost always, we want to put the shell of the program (that section that contains the graphics for the navigation/interface items) on the hard drive. In our example this would probably apply to the main menu and any common interface items for the topics themselves. This will help them appear on the screen faster (often this is all it take to make the user think the program is nice and fast). Along the same lines, the first screen of major transitions (like jumping to a new topic) should be on the hard drive if space permits. Again this makes things seem faster when the user runs the program. If you choose carefully, you can keep the size of the files copied to the hard drive relatively small. Often I set up my projects with all the items that should be on the hard drive in one library that can, at installation time, be copied/not copied to the users hard drive depending on space/speed desires of the user. If you put 99% of your content into libraries, your AP code will be fairly small and can always be copied to the user's hard drive. I recommend always doing this (of course there are specific exceptions which I'll have to cover in another posting.)

You should set up your other libraries logically. For our example, you probably would put all of your content (sound, graphics, text, etc.) for a topic in its own library. This helps keep files that are accessed in a linear fashion next to each other (important in CD access). And there is always linear stuff in even the most interactive titles. I know you're saying "not in my title", but even if that is not the case, often users will most likely pick a certain path (see #3 above). If you can determine what that most likely path is, you can do a better job of optimizing your CD.

When you need to do something like #5 above (accessing graphics while audio plays) you need to work carefully. While many CD drives have a buffer, don't count on them for this type of access. If you have an audio track running from the CD and try to display a graphic from the CD at the same time the audio will stutter or stop completely until the graphic is displayed. A better method is to decide which files can go to the hard drive and which should stay on the CD. More often than not, you will put the smaller of the two on the hard drive. BUT, you will probably see better performance from leaving the audio on the CD if each individual graphic is small, or the reverse if each individual graphic is very large.

As far as video is concerned, it is best to leave it on the CD and compressed for the data rate that matches your target platform (i.e., double speed). Remember to only use 60% or less of the CD-ROM data rate. And, just like audio, don't try to display additional graphics from the CD while playing a video.

Now a couple of VERY general comments on CD file layout. When laying out the file placement for your CD-ROM, the rule of thumb is to put your smallest randomly accessed files closest to the center of the disk. Of course all the rest of the files that are most likely to be accessed in a linear fashion should be put right next to each other anywhere else on the CD.

O.K., I've used much too much time on this. I'll try to put together some more thoughts on this subject as I get time. Several people expressed interest in the installation routines (what files where and why), and a few other topics. I'll be glad to comment on your specific projects, BUT first please go through the exercise of stating how your program is likely to be accessed by the user. Once you've done that, include it with your questions. I know this took a bunch of bandwidth, but I received a large number of responses on this subject. HTH.

Jamil Zainasheff