WO2000035194A1

WO2000035194A1 - Method for encoding multiple audio streams

Info

Publication number: WO2000035194A1
Application number: PCT/US1999/029140
Authority: WO
Inventors: Bo Wu; Bin Lu; Yen Feng
Original assignee: Enreach Technology, Inc.
Priority date: 1998-12-11
Filing date: 1999-12-07
Publication date: 2000-06-15
Also published as: WO2000035194B1; WO2000035194A9; JP2004511113A

Abstract

A method and system is provided to allow the encoding and playing back of encoded one or more still pictures or video streams with multiple sound streams and overlay graphics and/or text information, thereby allowing a medium (e.g. compact disc) to be encoding with a large number of audio information (e.g. songs). In particular, a still picture and multiple sound streams are encoded in such a manner that upon playback of the sound streams the still picture is displayed for all audio information (e.g. songs). The OGT information can be optionally encoded or encoded and optionally displayed to provide subtitle or guidance in sing-along situations. By minimizing the amount of video data to be stored on a medium such as a compact disc, a huge amount of audio information (and therefore songs) can be stored on a single compact disc. Alternatively, at least one video stream can be encoded with multiple audio streams and optional OGT information. In this manner, upon replay, the single video stream is displayed with a variety of audio streams and the corresponding OGT information. This method minimizes the amount of video information that needs to be stored on the storage medium and thereby allowing a tremendous amount of audio information to be stored on a medium such as a compact disc.

Description

Specification METHOD FOR ENCODING MULTIPLE AUDIO STREAMS

CROSS REFERENCES

This application incorporate by reference "Super VCD System Specification" dated September 22, 1998 and "VCD 3.0 Specification" as provided by Enreach Technology Inc., a California corporation.

Field of the Invention

The present invention relates generally to methods for encoding and playing back of audio and video information, and, more particularly, to the encoding and playing back of multimedia information combining audio streams, text streams, and video streams.

BACKGROUND OF THE INVENTION

In the conventional methods and formats for encoding audio streams and video streams onto a physical medium (such as a compact disc), an unique video stream is generally combined with one or more audio streams. This is generally the case for all video and audio combinations. For example, for a music video encoded on a Video Compact Disc ("VCD")^" or Digital Versatile Disc ("DVD"), one particular music video stream is encoded with a particular audio stream. Upon playback, the video stream is synchronized with the audio stream and played. In specialized applications, for example sing-along (or karaoke) applications, the conventional method in encoding the video and audio information for one song is to couple the video stream with one or two audio streams and a stream of overlay graphics and/or text ("OGT") to overlay the video stream - all on one track. Therefore, there is generally one song per track. If there are two audio streams, typically, one audio stream contains both the singer's voice as well as the underlying music and the second audio stream would just have the underlying music. The stream of OGT information typically would contain words in the languages of choice. However, it must be synchronized with the video stream and the audio stream.

While the conventional method is fine for most applications, the number of songs (each with an unique video stream and one or more unique audio streams) that can be placed on a compact disc is extremely limited. This format results in a situation where on an industry standard VCD, the number of songs is limited to 12-18 songs depending on the particular format used. Note that VCDs typically uses the MPEG-1 standard in encoding the video and audio streams. On industry standard DVDs, the number of songs is limited to 25-30 songs when encoded with the MPEG-2 standard. It is generally not possible to place more songs onto these discs. Thus, for a large song collection, a large number of discs are required and they have to be stored and handled, creating additional costs in equipment and storage space. This becomes a severe problem in commercial applications (e.g. singing lounges).

It is therefore desirable to have a method for storing a large number of songs with video information on a compact disc. The method ought to allow maximum compatibility with existing technologies to the extent possible.

SUMMARY OF THE INVENTION

It is therefore an object of the present invention to provide a method for encoding and playing back of one or more still pictures with multiple audio streams.

It is another object of the present invention to provide a method for encoding and playing back of one or more still pictures with multiple audio streams and OGT information synchronized with the respective audio streams.

It is yet another object of the present invention to provide a method for encoding and playing back of one video stream with multiple audio streams and OGT information synchronized with the respective audio streams.

It is still another object of the present invention to provide a method for encoding and playing back of still picture or video and multiple audio streams for sing-along purposes. Briefly, in a presently preferred embodiment of the present invention, a method is provided to allow the encoding and playing back of encoded one or more still pictures or video streams with multiple sound streams and overlay graphics and/or text information, thereby allowing a medium (e.g. compact disc) to be encoding with a large number of audio information (e.g. songs). In particular, a still picture and multiple sound streams are encoded in such a manner that upon playback of the sound streams the still picture is displayed for all audio information (e.g. songs). The OGT information can be optionally encoded or encoded and optionally displayed to provide subtitle or guidance in sing-along situations. By minimizing the amount of video data to be stored on a medium such as a compact disc, a huge amount of audio information (and therefore songs) can be stored on a single compact disc. Alternatively, at least one video stream can be encoded with multiple audio streams and optional OGT information. In this manner, upon replay, the single video stream is displayed with a variety of audio streams and the corresponding OGT information. This method minimizes the amount of video information that needs to be stored on the storage medium and thereby allowing a tremendous amount of audio information to be stored on a medium such as a compact disc. Note that the present invention is not limited by the particular storage media; it can be a VCD formatted physical disc, a DVD formatted physical disc, or any other physical media. Using the methods of the present invention, over fifty songs can be encoded on a VCD formatted disc. An advantage of the present invention is that it provides a method for encoding and playing back of one or more still pictures with multiple audio streams.

Another advantage of the present invention is that it provides a method for encoding and playing back of one or more still pictures with multiple audio streams and graphics and text synchronized with the respective audio streams. Yet another advantage of the present invention is that it provides a method for encoding and playing back of one video stream with multiple audio streams and graphics and text synchronized with the respective audio streams.

Still another advantage of the present invention is that it provides a method for encoding and playing back of still picture or video and multiple audio streams for sing-along purposes. These and other features and advantages of the present invention will become well understood upon examining the figures and reading the following detailed description of the invention.

DRAWINGS

Fig. 1 illustrates the time delay in encoding the audio streams in the preferred embodiment of the present invention.

Figs. 2a - 2c illustrate the encoding for the various format of the preferred embodiments.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

In the presently preferred methods of the present invention, the methods for encoding of still pictures with multiple audio channels, still pictures with multiple audio channels and multiple OGT information, and video stream with multiple audio channels and multiple OGT sub-streams are disclosed. The encoding of video streams and still pictures are performed in accordance with ISO 18318 (MPEG-2), and the encoding of audio streams are performed in accordance with layer II of MPEG- 1 or MPEG-2. In the encoding of one or more still pictures with multiple audio channels, the system stream contains one or more normal or high resolution still pictures encoded as MPEG video streams and one or more audio channel sub-streams. The particular method in packing the still pictures is as described below. The audio bit rate is 224k/second. Using 2xCD loader, twelve audio streams can be encoded into one track where in the audio packet header field, the stream_id field can have a value in the range from $C0 to $CB thereby identifying twelve audio streams. The total bit rate is calculated as audio bit rate (224k-bit/second) multiply by 12 audio streams to give 2,688,000 bits per second which is within the bit rate for a two-speed CD player. All the sound sub-streams are interlaced to maintain constant CD rotation speed in order to improve playability of the disc and player. In the encoding of one or more still pictures with multiple audio channels and multiple

OGT streams, the system stream contains one or more normal or high resolution still picture encoded as MPEG video stream, one or more audio channels, and one or more OGT sub- streams. The particular method in packing the still pictures is as described below. As in the above format, the audio bit rate is 224k-bit/second. Twelve audio streams can be encoded on a track and in the audio packet header field, the stream_id field can be from $C0 to $CB. The total bit rate is calculated as audio bit rate (224k/second) multiply by 12 audio streams to give 2,688,000 bits per second, which is within the performance range for a two-speed CD player. All the sound sub-streams are interlaced to maintain constant CD rotation speed in order to improve playability of the disc and player. For OGT information, it is encoded as a single stream with multiple sub-streams, which correspond to the audio streams. The sub_stream_id can be from 0 to $FC (or greater), providing a range of 24 (or greater) sub-streams. Every OGT packet has its sub_stream_id on the first byte of the data (offset $21) and every OGT page must have a SYNC word at the end of all data and this SYNC word is specified as $04080C10. The available total bit rate for OGT is calculated as follows: total CD bit rate minus total audio sub- stream bit rate which is 2,296 bits/second multiply by 75 by 2 by 8 (2,755,200 bits/second) less 2,688,000 bits/second, resulting in 67,200 bits/second.

In the encoding of one or more video streams with multiple audio and OGT streams, the video stream encoding bit rate is made in accordance with the audio channel numbers. The more audio streams (or channels), the lower bit rate for the video stream is needed. The normal video bit rate of a system of the present invention can be at 1,200,000 bits/second, which allows six (6) audio steams on a single track (224,000x6 bit/second) with a single video stream. For this case, total bit rates are 1,200,000 plus 224,000 multiplied by 6, equaling 2,544,000 bits/second. The remaining bandwidth can be used for OGT streams or padding. There can also be different settings of the bit rate distribution. When video bit rate is higher, less audio channels can be packed into a single track.

A disc is generally divided into a number of tracks, which is specified by the programmer of the disc. In a given track, there are a number of packs each with its own header and data stream. Within each pack, there may be a number of packets, again each having a header section identifying the data type and arrangement. Note that packs and packets are not the same. A pack may contain one or more packets. Generally speaking, there are several types of packets: system, audio, video, OGT, and padding. In most cases, a pack contains a single packet. For some cases, such as at the end of a stream, a pack may contain an audio packet and a padding packet. The packs are placed on to a track in accordance with the play order where the packs are interleaved regardless of the packet types. Since each packet is identified by an identification number and all the packs are sequentially read by the player, the player can easily re-assemble all of the packs in accordance with the packet identification number and respective sequence (or timing) numbers. The preferred embodiments of the present invention as described above modifies the ranges the stream identification numbers for audio and OGT packets to allow for greater number of channels (or streams) to be identified and therefore played. In the prior art, the audio packet identification number is limited to four values and thus limiting the number of audio channels to four channels. As described above, the identification number for audio packets has been modified to allow up to the speed of the media player divided by the audio bit rate. Each type of media player has its own speed limitations. For CD players, the maximum amount of data that can be read from a compact disc to the player is limited by the speed of the player. For a two- speed (2x) CD player, the bit rate is at 2,724,000 bits per second. Dividing by the audio bit rate of 224,000 bits per second, a 2 speed CD player can theoretically play up to two audio streams in one track. For faster CD players, more audio streams can be placed in a track and played. Theoretically, the above calculation is correct as to the maximum number of audio streams playable for a given speed of a two-speed player, meaning that the user can select any one of the twelve audio streams and have the audio stream played without any problem. Empirically, without the additional techniques provided by an aspect of the present invention, it is not possible to play over six or seven audio streams in a given track for a two-speed CD player without suffering from an underflow problem where the data for certain audio streams can not be read by the player in time for playing. The reason for the underflow problem has to do with the timing between data read and data played.

In order to solve this problem, the preferred embodiment of the preferred embodiment of the present invention further modifies the PTS value of a packet. The PTS value of a given packet indicates the start of the playtime of a particular packet. For example (in concept only), an audio stream containing a one-minute long son may be sequenced into six (6) packets. The first packet would have a PTS time of 0^th second; the second packet would have a PTS time of 10^th second; the third packet would have a PTS time of 20^th second; and so on. The last packet will have a PTS time of 50^th second.

Under prior art methods, in playing a twelve audio stream track, all twelve audio streams will have to be able to be played at time 0. As explained above, in practice, using prior art methods where all of the audio streams start at time 0 will cause an underflow problem.

In the preferred embodiment of the present invention, referring to Fig. 1, a method is devised where the PTS time for the first packet of each audio stream is staggered by a predetermined amount of time. As illustrated, each song is staggered by a certain unit of time. In this situation, if the twelfth song is selected and played, there will a period of silence (equaling to eleven time units) before the playing of the song. This time unit of the preferred embodiment is determined by the time that is required to read a pack. For a two-speed CD player, it can read 150 packs per second, equaling to 1/150 of a second. Note that all packs are the same size and a pack is a minimal logical unit of data to be read from a track.

In the preferred embodiment, in placing data on to a track, Fig. 2a illustrates the placement of packs on a track having a still picture and twelve audio streams. Note that all of the video packs (indicated by the symbol "V") can be pre-loaded followed by audio stream packs for audio streams 1 to 12 (A i to A ₁₂) and repeating thereafter. Also note that when the maximum amount of audio streams are being encoded, the audio streams have to be coded sequentially as illustrated. If not all twelve audio streams are being encoded, greater latitude can be had in the sequence of the audio packets. Fig. 2b illustrate the placement of packs on a track having a still picture, twelve audio streams, and an OGT stream interleaved. Again, since a still picture is used for all of the audio streams, the video information can be pre-loaded prior to the loading of any audio information. Fig. 2c illustrates the placement of packs on a track having a video stream encoding a video clip, six audio streams and an OGT stream interleaved. Since there is a video clip, the amount of audio information than can be encoded on a track is reduced. In this example, six audio streams are illustrated.

In order to provide even more songs on a track, the present invention provides a method for encoding additional songs on a track. The preferred embodiment described above illustrates a twelve channel (or stream) encoding method for a two-speed CD player thereby allowing at least twelve songs to be encoded for playback on a two-speed CD player. To incorporate additional songs on a single track, two or more songs can be ordered in such a manner so that one song follows another song in the same audio stream. In this manner, there can be more than one song in an audio stream and the limited on the number of songs on a medium is only limited by the capacity of the medium rather than the logical structure of the medium (as the case in prior art methods). In order to access other songs in the same audio stream, a command can be provided to direct the read head to the starting location of the targeted song in the track. In the preferred embodiment, a playback command is provided and it has arguments identifying the particular video stream, the particular audio stream, the particular OGT information, and the start and stop time within the particular audio stream. Appendices A and B provides further details with respect thereto.

As part of the present invention, a script language is also provided to enable greater and more dynamic interactive functionality and particularly when use with a file having the file format described above. It allows the performance of simple math calculations, simple character operations, drawing of graphics, display of image files and above-described files, or play sound and video clips. More specifically, the language provides relational operator such as equal to, less than, greater than, less than or equal to, greater than or equal to, and not equal to. It allows multiple statements per line of code, conditional statement (if, then, else), goto statement, gosub and return statement, for loop, and end statements. It also provides a number of graphic functions such as screen clear, drawing of a cursor at a specified position on the screen, drawing of a line, rectangle (a frame or filled), or an image on the screen. Multimedia functions are also provided, including playing a sound clip, a video clip, a specified item, a specified location, or a list. Certain sing-along functions are provided as well, including set a particular selection to the play list, insert a selection into certain position in the play list, delete a selection from the play list, randomly generate a number, or play a clip. There is also a call timer function to get system clock time and a call/store infrared key received. Appendices A and B attached hereto provide further details with respect to the script language of the present invention.

In another aspect of the present invention, methods for displaying overlay graphics and text (OGT) is disclosed. Overlay graphics and text is specially designed for display of program title graphics and language texts. The present preferred method supports full screen, multi-color, and overlay displays, and allows insertion of vocal texts and other still graphical images. The advantage is that graphics and text are not needed before video encoding, instead they are merged at decoding time. This flexibility allows language selection and preserves video quality. Overlay graphics and text data is packed into OGT special data streams. OGT data stream is encoded as a "private stream" as identified in the stream identification field ($BD). Its pack structure is-the same as a video pack (PS) and packet (PES) with an additional OGT header indicating the sub-stream's identification (beyond 4, for example 0..23) at the beginning of the packet's data. One of the sub-streams can be selected accordingly.

MISSING AT THE TIME OF PUBLICATION

APPENDIX A

CHM data format specification

All two and four byte integers are represented in the big endian format.

All text strings are terminated with a null character (\0) and padded to be 4-byte boundary.

This specification uses the term URL(Uniform Resource Locators) as defined in [RFC 1808] "Relative Uniform Resource Locators", R. Fielding, June 1995, available at www.w3.org

This specification uses the term HTML as defined in [REC-html40], available at Error! Bookmark not defined.

This specification uses the term WAV as defined in "Microsoft Windows Multimedia Programmer's Guide", available at http://www.microsoft.com/.

A.1 CHM file format

The CHM file has the following general format. An identifying text string, followed by a header and multiple data packets terminated by a private data packet and a closing text string.

<COMPHTML> CHM header CHM data packet CHM data packet

CHM data packet Unknown data package </COMPHTML>

Table A.1 : CHM F le overview <COMPHTML> The CHM file identifier string

CHM header

The CHM header containing global information CHM data packet

The packets of data that make up the CHM structures Private data

Data area reserved for use by the authoring tool </COMPHTML>

The text string that signals the end of the CHM file A.1.1 CHM Header

The header contains the information about the authoring tool, its creator and the source material. The browser uses the palette information to build a new palette that will be used in the context of the CHM file.

Table A-2: CHM Header authoring tools information

Text string that describes the tool used to create the CHM file version information

The version of the CHM file name of title

The title of the CHM page user name

The creator of the CHM file screen width

The width of the source material in pixels screen height

The Height of the source material in pixels background color

The index into the palette to be used as the background for this CHM page palette size

The size of the palette used in the CHM file private data bytes

Data to be used by the creators/content owners of the page palette data

The <palette size> YUV entries of the palette

A.1.2 CHM Data packets

The data packets contain the data to be used by the browser to navigate the information on the disk. A CHM data packet has the following format: A header followed by the data. The header contains the type and the size of the packet following the header.

Table A-3 : CHM Data Packet structure data type

The type of the CHM data packet. The types are listed in the CHM Data type table, size

The size of the data packet in bytes excluding the header, checksum

The checksum according to an algorithm to be specified, data packet

The^" data of the CHM packet

Table A-4 : CHM Data Packet types A.1.2.1 Data Types used in this document

Position description data structure

Rectangle description data structure

Font description data structure

Operations data structure

A.1.2.2 Data Type Packets Types

A.1.2.2.1 Title of CHM page (Type 0)

This gives the title of the CHM page. It is used by the bookmark function. Currently, only English text accepted.

length

The length of the title in bytes excluding the null character text

The title text string A.1.2.2.2 English Text Object (Type 1)

coordinate

The bottom left coordinate of the text string anchor ID

The ID of the anchor font type

The font style used for the text text color The text color text length

The length of the text character string excluding the null character text

The text string to be drawn at the (x,y) coordinates The characters supported : (from space to ~) space !"#$%&'()* + -. /0123456789:;,< = >?@ABCDEFGHIJKLMN OPQRSTUVWXYZ\]^Λ_^λabcdefghijklmnopqrstuvwxyz{|}~

A.1.2.2.3 Image Object (Type 3)

coordinate

The top left coordinate of the image width and height

The width and height of the image anchor ID

The ID of the anchor map name

The name of the client side image map color

The text color image file name length

The number of characters in the image file name excluding the null character image file name

The image file name

A.1.2.2.4 Rectangle Outline Object (Type 4)

rectangle coordinates

The (top, left) and (bottom, right) coordinates of the rectangle outline color

The outline color

A.1.2.2.5 Filled Rectangle Object (Type 5)

rectangle coordinates

The (top, left) and (bottom, right) coordinates of the rectangle outline color

The outline color

A.1.2.2.6 Line Object (Type 8)

coordinate 1

The start point of the line coordinate 2

The end point of the line style

The drawing style of the line (NOT USED) color The line color

A.1.2.2.7 Anchor Object (Type 9)

anchor ID

The ID of the anchor. overlay

If the overlay value is ' 1 ' the background image will be preserved and the new image will be drawn on top of the current image. event Handler

See the event handler data structure number of operations

Number of CHM operations present in the operations .field operations

The operation executed after the selection of the anchor

URL length

The length of the URL string excluding the null character

URL

The URL string

A.1.2.2.8 Image Map Area Object (Type 11)

image map name The name of the image map. overlay If the overlay value is ' 1 ' the background image will be preserved and the new image will be drawn on top of the background image. event handlers

See the event handler data structure number of operations

Number of CHM operations present in the operations field operations

The operation executed after the selection of the map

URL length

The length of the URL string excluding the null character

URL

The URL string

A.1.2.2.9 Refresh Object (Type 13)

delay

The time in seconds before the operations will be executed number of operations

Number of CHM operations present in the operations field operations

The operation executed after the selection of the map

URL lengthl

The length of the first URL string referring to the original URL name excluding the null character

URL length2

The length of the second URL string referring to the overlay URL name excluding the null character URL

The URL strings terminated with a null character. A.1.2.2.10 Variable Object (Type 14)

coordinate

The (bottom, left) coordinate of the text string that prints the value of the variable variable name

The name of the variable whose value will be displayed

A.1.2.2.11 Background Sound Object (Type 15)

number of loops

The number of loops the clip should be played (-1 indicates continuous) length of sound file name

The length of the sound file name sound file name

The name of the WAV file to be played

A.1.2.2.12 Script Object (Type 16)

language ID The scripting language ID. Valid ID is NCDSCRIPT' length of script

The length of the script in bytes script

The script to be executed or parsed.

A.1.2.2.13 Background Image Object (Type 17)

length of image file name

The length of the image file name image file name

The name of the image file to be loaded. The background image is a file that can be shared when drawing various text screens.

APPENDIX B

APPENDIX A 9

CHM data format specification 9

A.1 CHM file format 9 A.l.l CHM Header 10

A.1.2 CHM Data packets 11

A.l.2.2 Data Type Packets Types 13

A.l.2.2.1 Title of CHM page (Type 0) 13

A.l.2.2.2 English Text Object (Type 1) 14 A.l.2.2.5 Filled Rectangle Object (Type 5) 15

A.l.2.2.6 Line Object (Type 8) 16

A.l.2.2.7 Anchor Object (Type 9) 16

A.l.2.2.8 Image Map Area Object (Type 11) 17

A.l.2.2.9 Refresh Object (Type 13) 18 A.l.2.2.10 Variable Object (Type 14) 19

A.1.2.2.11 Background Sound Object (Type 15) 19

A.l.2.2.12 Script Object (Type 16) 19

A.l.2.2.13 Background Image Object (Type 17) 20

APPENDIX B 21 B.l General Characteristics of the SVCD SCRIPT language 21

B.2 Language Specification 22

B.2.1 Multiple Statement Per Line 22

B.2.2 Documenting a Program 22

B.2.3 Flow Control 22 B.2.4 Graphic Function 24

B.2.5 Multimedia Function 25

B.2.6 Special System Functions 27

B.3 PROGRAMMING USING SVCD SCRIPT 28

SVCD SCRIPT is a simple scripting language, serves as the companion to enable more dynamic and interactive functionality to CHM file. It allows the user to do simple math calculations ( such as +-*/ ), simple character operations, draw graphics, display image files/CHM files, or play WAV files and video clips.

B.1 General Characteristics of the SVCD SCRIPT language DATA TYPE

Currently, SVCD SCRIPT supports only one kind of data type: integer (INT).

DEFINITION OF VARIABLES

SVCD SCRIPT supports a maximum of 26 variables. The names of these variables must be a single character from A to Z. Inside an SVCD SCRIPT, all variables are treated as global.

LINE NUMBER

The maximum number of script lines is 999. Line numbers may not be larger than 65535.

Relational Operators used in Conditions

B.2 Language Specification B.2.1 Multiple Statement Per Line

Example: a. X = 4: Y=10:Z=10:GOSUB150 B.2.2 Documenting a Program b. The REM statement

B.2.3 Flow Control

The IF ... THEN ... ELSE ... statement

d. The GOTO statement

e. THE GOSUB and RETURN statement

** The main difference between the GOTO and GOSUB statements is that:

GOTO is an unconditional jump to another point in the script to continue script execution. GOSUB is used for implementing sub-functions within a script by allowing a jump to another point in the script and return script processing to the statement right after the GOSUB statement once the function has been completed via the RETURN statement.

The FOR ... TO ... NEXT ... Statement

Note The increment value is always 1

The End Statement

B.2.4 Graphic Function g- Clearing the Screen h. The DRAWCLS statement

The DRAWCURSOR statement

The DRAWLINE statement

The DRAWRECT statement

The DRAWIMAGE statement

B.2.5 Multimedia Function The PLAYSOUND statement

The PLAYVIDEO statement

General Form PLAYVIDEO filename,time 1 ,time2,fname2 where filename is the name of the video file to be displayed; timel is the starting time(mm:ss:ff) of the video file specified by filename time2 is the ending time(mm:ss;ff) of the video file specified by filename fname2 is a CHM file name which is to be displayed after the ending time oftime2

The PLAYENTRY statement

The PLAYITEM statement

The PLAYLIST statement

The KARAOKE SET statement

The KARAOKE INS statement

The KARAOKE PLAY statement

The KARAOKE DEL statement

B.2.6 Special System Functions

RANDOM INTEGER NUMBER The CALL RAND(I) statement

SYSTEM TIMER

The CALL TIME(X) statement

The CALL IRKEY(X) Statement

Remote Control Key Definition

B.3 PROGRAMMING USING SVCD SCRIPT

As mentioned previously, SVCD SCRIPT is a simple scripting language that serves as a companion to enable more dynamic and interactive functionality to CHM files.

A SVCD SCRIPT program is composed of a sequence of lines. Each line contains a unique line number that serves as a label for the statement as shown in Figure 1. The line may contain up to 160 characters, although it usually contains considerably fewer.

Fig.B-1 The general form of a SVCD SCRIPT program

A SVCD SCRIPT program can be manipulated in 2 ways:

First, a pure SVCD SCRIPT program file can be called directly from a CHM file. Please note that all pure SVCD SCRIPT program files should have the extension name CLS. For example:

<A href=<math.cls"> Sample SVCD SCRIPT program </A> <A href=<math.cls"> <img src=<mathtest.ybm"> </A> or same as in MAPAREA

Second, a SVCD SCRIPT program can be contained inside of the CHM file. As shown in Fig 2. Below, scripts are placed between the <SCRIPT> and </SCRIPT> tags, and will always before </HEAD> within CHM file. The script is then invoked by an Anchor Event, (i.e. OnClick / OnLeave / OnEnter) with a numerical argument indicating the line number to begin execution of the SVCD SCRIPT program. Unlike a typical script, unrelated blocks of the script code share the same variables and line number space, even though these scripts may have no relationship with each other at all. As a result of this, scripts must be carefully written so as not to result in line number and variable confiicts. As shown in Fig3 below, if program 1 and program2 are independent scripts, it is highly recommended to initialize all of the variables that will be used in both of these scripts at the beginning of the program.

Example:

10 ... // 20 ... // program 1 30 ... // 40 END //

100 .... // program 2

120 END //

</script></head>

<A OnClick= "10"

OnLeave="l 00">TEST</A>

</body></html>

Fig 3

Programming Tips:

The SVCD SCRIPT language supports only 26 single character variables from A to Z, and all of its variables are global variables. As a result, program flow and variable definition should be carefully designed before the programmer before beginning actually script coding.

All script line numbers should be sorted in ascending numerical order. As shown in the following diagram, the following script is coded incorrectly:

10 xxxxxxxxxxxxx

20 xxxxxxxxxxxxxx

100 xxxxxxxxxxxxx

200 xxxxxxxxxxxxxx

30 xxxxxxxxxxxxxx

40 xxxxxxxxxxxxxx

All integers should be decimal numbers, no hexadecimal or octal number are supported on integer variables assignment.

For Example:

10 X=10 (correct)

10 X=0xA (incorrect)

All scripts should be written using upper case letters, with the exception of any text after a REM

Limitations on using multiple statements on a single line

The.':' statements after RETURN , GOTO , GOSUB , NEXT and THEN will not be execute correctly. Do not use ':' after these statements. Use a new line instead. Although the present invention has been described in terms of specific embodiments it is anticipated that alterations and modifications thereof will no doubt become apparent to those skilled in the art. It is therefore intended that the following claims be interpreted as covering all such alterations and modifications as fall within the true spirit and scope of the invention. We claim:

Claims

1. A method for encoding information on a physical medium, comprising the steps of: providing a medium for recording and playback; and encoding said medium with one or more tracks, at least one track having packs encoding a video stream and at least five or more audio streams.

2. A method as recited in claim 1 wherein each of said audio streams is sequenced into one or more packs and said packs of the said audio streams are encoded sequentially.

3. A method as recited in claim 2 wherein each of said audio streams are delayed by a predetermined time unit.

4. A method as recited in claim 3 wherein said time unit is the amount of time required for a player for said physical medium to read a pack.

5. A method as recited in claim 3 wherein for said audio streams, an audio stream placed later in the sequence is delayed by more time than an audio stream placed earlier in the sequence.

6. A method as recited in claim 1 wherein said medium is a compact disc.

7. A method as recited in claim 6 wherein said compact disc is encoded using the VCD standard.

8. A method as recited in claim 1 wherein said video stream represents a still picture.

9. A method as recited in claim 1 wherein said video stream represents a video clip.

10. A method as recited in claim 1 wherein each audio streams encodes one or more songs.

11. A compact disc encoded using the method recited in claim 1.

12. A method for decoding information encoded on a physical medium, comprising the steps of: reading from a selected track of a physical medium; reading packs of said track; identifying the content of each pack, each pack having one or more packets; identifying video packets for a video stream from said packs and audio packets for four or more audio streams from said packs; and sequencing said respective packets for playback.

13. A method as recited in claim 12 wherein each of said audio streams is sequenced into one or more packs and said packs of the said audio streams are encoded sequentially.

14. A method as recited in claim 13 wherein each of said audio streams are delayed by a predetermined time unit.

15. A method as recited in claim 14 wherein said time unit is the amount of time required for a player for said physical medium to read a pack.

16. A method as recited in claim 14 wherein for said audio streams, an audio stream placed later in the sequence is delayed by more time than an audio stream placed earlier in the sequence.

17. A method as recited in claim 12 wherein said medium is a compact disc.

18. A method as recited in claim 17 wherein said compact disc is encoded using the VCD standard.

19. A method as recited in claim 1 wherein each audio streams encodes one or more songs.