Multi-menu VCD

last updated: 20-Dec-2002 | introduction | authoring | authoring tips | xml | conclusions | back to index

Donate! If you like using this guide, then please help with its development by donation!  You can do so by clicking on the button to the left.  The donation is handled securely via PayPal.  Thank you.


Once simple menus have been mastered, the natural progression is for the use of more complex menus, and several of them, on a VCD.  Although even one menu can be a vast improvement in interactivity compared to no menus at all, putting everything into just the one menu tends to look cluttered and amateurish.  Look and examine the menu structure of any DVD; the use of a "main menu" with sub-menus (e.g., "special features", "audio selection") is the norm.

In this guide, a hypothetical VCD is created.  As menus are created using <selection>, knowledge and comprehension of the workings of <selection> is crucial for the understand of this guide.   There is a detailed guide here, and a diagrammatic guide here.

There will be no CUE/BIN sample of the multi-menu VCD to download.  The PAL/NTSC Demo VCD is an example of a multi-menu VCD.  This can be downloaded here:


Multi-menu VCD -- figure 1
Multi-menu VCD -- figure 2Structure of the VCD

The main menu is an animated menu that loops indefinitely.  It links to a number of things that the user can select: 1-3 selects 3 "episodes" of a show on the VCD, 4 goes to a "trailer menu" and 5 goes to an information screen.

The three episodes are linked in such a way that they form a simple multitrack (method three).

The trailer menu and info screen both use high resolution stills.  The VCD stays on both menus for 60s and then timeouts back to the main menu if the user doesn't provide any input.

Two trailers are linked to the trailer menu.


Authoring the Disc

This VCD uses the following source files:


Some authoring tips before we start

Animated (video clip) vs. High Resolution Still as <play-item> or background of a selection

A <selection> in a VCD can utilise both a VCD compliant video clip or a high resolution still image (704x480/576).  It is important to realise that the resultant <selection> is authored slightly differently in these two cases.  The most pertinent changes involve the <loop> number and the <wait> number.  For more information on the <selection> element, click here.

The <loop> tag really only has significance if you are using a video clip as the background.  This makes sense.  A video clip has an intrinsic play-length and this tag allows you to loop it a specific number of times (or indefinitely).  For example, say the video clip for a menu was 10 seconds long.  It may be desired for the menu to loop 6 times before timing out.   That is, the menu is displayed for 60 seconds (10s x 6) before it timeouts.

The <loop> tag has NO SIGNIFICANCE with a menu based on a still image.  This is simply as a still image has no intrinsic play-length.  What is wanted is for the still image to play once (i.e., load up) and then stay displayed for a set amount of time.  This time is set by the <wait> tag.  If the <loop> number is set to anything other than 1 for a still image based menu, there is a chance that the menu will not work correctly or may even hang the player (think about it, the player is displaying the same image again and again as fast as it can...)

The <wait> tag is thus of prime importance for a still image menu.  Basically it dictates how long the menu will stay up before it timeouts.   The <wait> tag tends to be of less functional importance for a video clip based menu.  This is simply as it doesn't come into effect until after the clip has finished looping completely.  The <wait> tag in a video clip menu works by displaying the last frame of the video clip for the specified amount of time before it timeouts.  This is usually not a useful thing.

In summary:

  Video clip based <selection> Still image based <selection>
<loop> any number you want (0 = infinite) 1 ONLY
<wait> of little significance
shows last frame for this amount of time AFTER looping
of prime significance
time set here determines the time the men will stayed displayed
(-1 = infinite)


Order of the Video Sequences

This is probably a point not often thought of, or really even that important.  However, understanding of this point, it will yield VCDs authored with just that little bit extra polish.

In this VCD project example, there are 5, possibly 6 video clips that could be authored as <sequence-items>.  That is, the three episodes, the two trailers and possibly the "main menu" clip for the main menu background.  I usually (and have) put the menu video clips as <segment-items> (unless I have a good reason -- more on this in "advanced authoring") but it can be authored as a <sequence-item> with little consequence.

Now, the only functional difference in arranging the clips in a different order physically on the VCD is the time it takes to load particular tracks.  Obviously, the three episode video clips should follow each other consecutively.  That is, after one finishes playing, the next loads as quickly as possible.  However, should the trailer clips before or after the episode clips?  That is:

  1. trailer1 - trailer 2 - episode 1 - episode 2 - episode 3 or
  2. episode 1 - episode 2 - episode 3 - trailer1 - trailer2

Most people would be tempted to follow option 2 as it seems to be the most logical representation of the diagram as shown in figure 1.   However, option 1 is a better choice!


When a trailer is chosen from the trailer menu during playback, the reading laser mechanism has to move from near the centre of the disc (all <segment-items> occupy the FIRST physical track so are near the centre of the disc) to somewhere further out.  In option 2, the trailers would be at the furthest edges of the disc as the bulk of the VCD data (episodes 1-3) is before it.  In option 1, the laser would barely have to move at all to get to the beginning of the trailers.  Thus they will load just that little bit faster.

On the other hand, when we choose to play the episodes, there is little difference between option 1 and 2 as the trailers are quite short and occupy little of the VCD.

Although this isn't much of an issue in modern DVD players (very quick drive mechanisms), it makes a noticeable difference on older stand-alone VCD players.  These use a single-spin CD drive and often the movement of the laser head from the centre of the disc to the out edge (and vice versa) will take almost a second.  That is, optimising where the video sequences are authored can be the difference between a crisp loading trailer compared to a brief (but irritating) pause.


Orderly and consistent naming in the XML file

It is a very good idea to get into a habit of naming things in a consistent manner in the XML files.  Obviously, writing an XML from scratch each time for each new VCD can be a very tedious process.  However, with the gaining of experience comes the realisation that most structures are very stereotypical.  Consistent naming between XML files will mean the opportunity to cannibalise past XML files and to copy large chunks en masse.  Only small degrees of editing is necessary.  Even complex XML structures (of say DVD rips) take little time to author.

From my experience, if naming is not performed in an obvious way, it can be very confusing, very quickly.  Thus, in the XML authored in the article (and all subsequent ones with complex PBC structures), items are named in the following way:

This scheme works quite well for me.  I would suggest that anybody with an interest in authoring XML for VCDs should consider a similar system.  For example, if a <sequence-item> is named "mainmenu" (i.e., the video clip of the menu), it can be confusing latter whether "mainmenu" referred to the actual <sequence-item> or the <selection> used to play it.  However, the names "seq-mainmenu" (<sequence-item> of the mainmenu) and "select-mainmenu" (<selection< of the mainmenu) are unambiguous.


A good text editor

Notepad which comes with Windows is only barely sufficient.  WordPad (or Write) is better, but it has an annoying habit of formatting text...  It works better if a text file (blank or otherwise) is loaded first.

At any good shareware repository, freeware text editors that are much better than the Microsoft fare can be downloaded.  I don't recommend any in particular, but the ones which display the line number are better.  This feature is a a godsend when hunting down mistakes (VCDXBUILD will state the line number of the error).



There will not be an explaination for every line of this XML.  The answer to any questions are in the various guides in this site, and of course, the VCDImager manual.  For a guide on XML for VCDImager, click here.  Furthermore, the VCDImager forums should be the next point of call (i.e., don't e-mail me unless all other avenues and resources have been exhausted first).

As a reminder, this is what we want to author (figure 1):
Multi-menu -- figure 1

<?xml version="1.0"?>
<!DOCTYPE videocd PUBLIC "-//GNU//DTD VideoCD//EN" "">

<videocd xmlns="" class="vcd" version="2.0">


    <system-id>CD-RTOS CD-BRIDGE</system-id>
    <publisher-id>MICHAEL TAM - VITUALIS PRODUCTIONS</publisher-id>

      <file src="cdi_imag.rtf" format="mixed">
      <file src="cdi_text.fnt">
      <file src="">

    <segment-item src="mainmenu.mpg" id="seg-mainmenu"/>
    <segment-item src="trailermenu.mpg" id="seg-trailermenu"/>
    <segment-item src="info.mpg" id="seg-info"/>

    <sequence-item src="trailer1.mpg" id="seq-trailer1"/>
    <sequence-item src="trailer2.mpg" id="seq-trailer2"/>
    <sequence-item src="episode1.mpg" id="seq-episode1"/>
    <sequence-item src="episode2.mpg" id="seq-episode2"/>
    <sequence-item src="episode3.mpg" id="seq-episode3"/>


    <selection id="select-mainmenu">
      <loop jump-timing="immediate">0</loop>
      <play-item ref="seg-mainmenu"/>
      <select ref="play-episode1"/>
      <select ref="play-episode2"/>
      <select ref="play-episode3"/>
      <select ref="select-trailermenu"/>
      <select ref="select-info"/>

    <playlist id="play-episode1">
      <prev ref="select-mainmenu"/>
      <next ref="play-episode2"/>
      <return ref="select-mainmenu"/>
      <play-item ref="seq-episode1"/>

    <playlist id="play-episode2">
      <prev ref="play-episode1"/>
      <next ref="play-episode3"/>
      <return ref="select-mainmenu"/>
      <play-item ref="seq-episode2"/>

    <playlist id="play-episode3">
      <prev ref="play-episode2"/>
      <next ref="select-mainmenu"/>
      <return ref="select-mainmenu"/>
      <play-item ref="seq-episode3"/>

    <selection id="select-trailermenu">
      <return ref="select-mainmenu"/>
      <timeout ref="select-mainmenu"/>
      <loop jump-timing="immediate">1</loop>
      <play-item ref="seg-trailermenu"/>
      <select ref="play-trailer1"/>
      <select ref="play-trailer2"/>

    <playlist id="play-trailer1">
      <next ref="select-trailermenu"/>
      <return ref="select-trailermenu"/>
      <play-item ref="seq-trailer1"/>

    <playlist id="play-trailer2">
      <next ref="select-trailermenu"/>
      <return ref="select-trailermenu"/>
      <play-item ref="seq-trailer2"/>

    <selection id="select-info">
      <return ref="select-mainmenu"/>
      <timeout ref="select-mainmenu"/>
      <loop jump-timing="immediate">1</loop>
      <play-item ref="seg-info"/>



Additional authoring

Those with sharp eyes should be able to see that a few things (well one thing, several times) have been added that aren't in the diagram (figure 1).  Can you see it?

My opinion is that it is a good idea to use the button <return> in a standardised way.  That it, it brings the VCD one "level" up.  For example (as drawn in figure 1), the "trailer menu" and "info" screens are sub-menus of the "main menu".  Thus, pressing <return> in those menus goes back to the main menu.

In the XML, I've further authored that pressing <return> from any of the "episode" <playlist> will return to the "main menu".  Similarly, pressing <return> in the "trailer" <playlist> will go back to the "trailer menu".

These weren't drawn on "figure 1" for the sake of visual clarity.



Once you've mastered using multiple menus in VCDs, you'll be well on the way to mastering VCD authoring.  Most of the more complex VCD authoring involves using <selection> in creative ways.  Also, by this stage you'll realise that most of the work in authoring VCDs is NOT in the XML.  Rather, it is in understanding how VCDs work.  The XML is simply a conceptual representation... and quite a good one.

Look at the complexity in the visual schematic of this VCD (figure 1)... and I haven't even used all the features possible (e.g., multi-default menus).  In my humble opinion, this is where GUIs break down.  Although they can simplify the task enormously for very simple structures, this comes at the cost, a large cost, of flexibility.  For example, case and point are the commercial programs Nero and Easy CD Creator.  Both can create VCD menus, but the implementation is simple to a fault.

For a GUI to be able to attain the same degree of complexity as the VCDImager XML system, it itself becomes too complex for the beginner and is thus no better (e.g., VideoPack 4, Video-CD 2.0 Toolkit).

Furthermore, as VCDImager is open source and uses XML, third party GUIs can, and have been easily created to cater for beginners.  Thus, you can have the best of both works in one system...  A GUI for the casual user who isn't interested in learning the XML system or exactly how VCDs work, and manual XML authoring for the enthusiast.

Addendum (4-Sep-2002): Indeed, my prediction about this has borne out to be mostly correct.  There are now a number of GUIs for VCDImager that aid in the authoring of the XML.  Good examples include both TSCV and VCDEasy.  Both can automate the creation of menus to certain degrees of complexity as well as other features like "chapters".  These are a great way for a beginner to learn how the XML authoring system works.  However, for true customability, one still needs to take out the text editor and edit / tweak the XML file manually.

Michael Tam <vitualis (at)>
anti-spam device - replace (at) with @ to send me e-mail

(c) 20 December, 2002