Method and apparatus for storing MIDI information in subcode packs

Abstract

The present invention is an apparatus and method for ecoding data in MIDI (Musical Instrument Digital Interface) format on an audio compact disc without affecting the digitized sound stored in the main channel by utilizing what is known as the subcode channel of the compact disc which is reserved for information other than digitized compact disc audio data. The invention is directed to a technique for converting MIDI information generated by a MIDI source (for example, a keyboard or sequencer) into subcode data which may be recorded on a transportable floppy diskettes or other transportable media for subsequent conversion to signals which are input to a compact disc encoder which places the MIDI information into the subcode channel.

Description

SUMMARY OF THE INVENTION

The present invention is an apparatus and method for encoding data in MIDI (Musical Instrument Digital Interface) format on an audio compact disc without affecting the digitized sound stored in the main channel by utilizing what is known as the subcode channel of the compact disc which is reserved for information other than digitized compact disc audio data. Presently, audio compact discs use 95% of their capacity to store digitized sound, leaving 5% for what is called the subcode channel or area. The subcode channel, which corresponds to about 30 megabytes of data capacity, to the extent it is utilized at all, is used for graphics information. In order to play back graphics subcode data, it is necessary for a compact disc player to include a graphics decoder to decode the graphics subcode data. To make MIDI encoded data stored in the subcode area available to a MIDI device, it is necessary to add a connector into which a cable from the MIDI device is plugged into the compact disc player and modify the player to include subcode decoding circuitry. In this connection, if a compact disc player includes a graphics decoder, most of the necessary circuitry would be included in the graphics decoder. If a graphics decoder is not present, the necessary circuitry would need to be added to take advantage of MIDI data encoded on a compact disc according to present invention.

By making the MIDI information placed on a compact disc available to a MIDI device, a user can add MIDI information from other sources and/or change the MIDI information so as to change the sounds of instruments, rearrange the sound of songs, change their tempo and key, and otherwise creatively modify music for new listening experiences and education. For example, by changing the key of a song, one can sing along in his or her own vocal range, or by directing the MIDI information to a set of musical instruments which are different from the original instruments, the user can change the orchestration. All this is accomplished without affecting in any way the original digitized music recorded on the compact disc.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1a shows the format of a subcode data pack for a compact disc.

FIG. 1b shows an encoding scheme for storing MIDI data in a subcode data pack using 10 bytes of MIDI data per pack.

FIG. 1c shows an encoding scheme for storing MIDI data in a subcode data pack using 11 bytes of MIDI data per pack.

FIG. 1d shows an encoding scheme for storing MIDI data in a subcode data pack using 12 bytes of MIDI data per pack.

FIG. 2 is a block diagram showing the components needed to practice the present invention.

FIG. 3 is a schematic of a circuit for implementing encoder interface logic 21.

FIGS. 4a-4h show a hierarchical diagram of a computer program for converting raw MIDI data to subcode data.

FIG. 5 is a hierarchical diagram of a computer program for reading subcode data stored on a floppy or hard disk to RAM for access by encoder interface logic 21.

DETAILED DESCRIPTION OF THE INVENTION

Audio compact discs, by an industry standard, set aside 5% of the possible data storage for non compact disc audio. In other words, 95% of the possible data storage is used to store the digitized audio recording. The reserved 5% portion known as the subcode channel, in effect, stores purely numerical data in a specified format. In particular, data in the subcode channel is stored in packs of 24 words with each word consisting of 6 bits labeled R, S, T, U, V and W respectively as shown in FIG. 1a. Each of the bits in the subcode channel is one of 6 sub channels. Details regarding the format of subcode data on a compact disc are set forth in a document known as the "Red Book" which is a technical specification created by Philips N.V. and Sony Corporation entitled "Compact Disc Digital Audio System Description." The foregoing details are found in the section entitled "Sub Channels R, S, T, U, V and W."

The invention is directed to a technique for converting MIDI information generated by a MIDI source (for example, a keyboard or sequencer) into subcode data which may be recorded on a transportable hard disk or floppy diskettes for subsequent conversion to signals which are input to a compact disc encoder which places the MIDI information into the subcode channel. Alternatively, the subcode data may be directly converted into a form usable by a compact disc encoding device. A block diagram illustrating the various components needed to convert the MIDI information into data which may be encoded into the subcode channel of a compact disc is shown in FIG. 2 as MIDI source 11, MIDI interface 13 which is an interface board for enabling the MIDI data to be input to computer 15, computer 15 which performs the conversion from MIDI data to subcode data, disk 17 which stores the subcode data, computer 19 with encoder interface logic 21 for generating signals to be input to compact disc encoding device 23, and compact disc encoding device 23 which places digitized audio main channel data and subcode data onto compact disc 25. Also shown for completeness are compact disc player with MIDI decoder 27 whose output is used to drive musical instrument 29.

MIDI source 11 may be any source of MIDI data such as a keyboard with a MIDI port or a sequencer. Such components are readily available from a variety of manufacturers. MIDI interface board 13 is a commercially available product such as a Voyetra OP-4000/1 board based on Roland's MPU-401 technology. Details regarding such board may be found in the OP-4000/1 Intelliqent PC/MIDI Interface Technical Reference Manual published by Voyetra. Computers 15 and 19 may be any general purpose digital computer. In the preferred embodiment, an IBM PC/AT or compatible is used. The software necessary to convert the MIDI data from board 13 to subcode data will be described below. The subcode data created by the software in computer 15 is written to disk 17 which is a standard floppy diskette or another transportable medium for data storage. A transportable medium is used because the MIDI data is generally created at a different time and place than that at which the compact disc is encoded with the digitized compact disc audio data and MIDI data.

When the compact discs are to be produced, the MIDI data on floppy diskette 17 is read by computer 19 and converted by interface board 21 into the necessary electrical signals needed to drive compact disc encoder 23. Interface board 21, as shown in FIG. 3, takes bytes of subcode data including MIDI information which have been loaded into RAM 41 from disk 17 and using serial to parallel shift register 45, loads buffer 47 with R, S, T, U and V subcode data. RAM 41 is loaded with the subcode data under program control (see Appendix 2) which reads disk 17, places the data on bus 42 for storage in RAM 41. The details concerning the foregoing components of board 21 are well within the skills of those skilled in the relevant art and, therefore will not be set forth herein. Similarly, encoder 23 is a standard compact disc mastering/pressing apparatus available from Phillips N.V., Sony Corporation, JVC and others which may need to be modified to accept the signals generated by interface board 21. The specific modifications which may be needed are dependent upon the particulars of the encoder and would be readily apparent to persons skilled in the art and therefore will not be described herein.

The details concerning the software used to convert MIDI data into a form which may be converted into signals for use by encoder 23 are as follows. Presently, the standard specification for MIDI is known as MIDI 1.0 and is published and distributed by International MIDI Association, 12439 Magnolia Boulevard, Suite 104 North Hollywood, Calif. 91607. According to the standard, MIDI data is sent and received at speeds up to 3125 bytes per second, with each byte having 8 bits of information. On the other hand, subcode packs which, as noted above, consist of 24 six bit words, are transmitted at 300 per packs per second. Although, each pack has 24 six bit words, as shown in FIG. 1a, only words 4-19 are used for data, for a total of 16 six byte words or 96 bits per pack. Thus, each pack can accommodate up to 12 eight bit MIDI bytes. However, at 300 packs per second, with 12 MIDI bytes per pack, there would be 3600 MIDI bytes per second which exceeds the MIDI specification of a maximum of 3125 bytes per second. Inasmuch as not all 12 bytes may be used, the scheme for placing the MIDI data into the subcode area must provide a mechanism for ensuring that 3125 bytes or less of MIDI data are transmitted per second.

One mechanism which may be employed is to limit the number of MIDI bytes to no more than 10 per pack. In this manner, even if 300 consecutive packs contained only MIDI data, only 3000 bytes of MIDI data could be transmitted per second. While such limitation would be adequate for most applications, there may be times when it is desired to use the maximum MIDI data rate of 3125 bytes per second. If no more than 11 MIDI bytes are allowed per pack, then the 3125 bytes per second standard can be met be limiting the number of packs which are allowed to have 11 MIDI bytes to no more than 5 out of 12 (i.e., for each 12 packs, there are 5*11+7*10=125 bytes and there are 25 groups of 12 packs every second or 125*25=3125 bytes per second). However, as a practical matter, 11 MIDI bytes per pack is not practical since sequences of MIDI commands rarely add up to 11 bytes. For example, the most common MIDI commands are NOTE ON and NOTE OFF which are 3 bytes each, four of which may be placed in a 12 byte pack. Alternatively, three such commands may be placed in a pack with one MIDI clock for a total of 10 bytes. In this manner, up to 12 bytes may be placed in each pack so long as no more than 125 bytes are placed in any 12 consecutive packs.

If 12 bytes are allowed in a pack, the actual number of bytes in a pack must be placed in word one of the pack which is known as the command word. Suitable 10, 11 and 12 bytes per pack schemes are shown in FIGS. 1b-1d respectively. The scheme shown in FIGS. 1c and 1d may also be used for less than 11 bytes by putting smaller numbers in the No. of MIDI bytes field, and using less of the data space. The scheme in FIG. 1b can be made compatible with the schemes shown in FIGS. 1c and 1d provided the command word contains a value greater than 12, thus flagging the scheme shown in 1b.

A suitable program in C source code for executing in computer 15 to convert MIDI data from MIDI source 11 to suitable subcode data is attached hereto as Appendix 1. The embodiment shown in Appendix 1 uses a 10 bytes of MIDI data per subcode pack encoding scheme as shown in FIG. 1b. Modifications to the routine SAVE-SUBCODE for encoding 1 and 12 MIDI bytes per subcode pack as shown in FIGS. 1c and 1d would be well within the abilities of a person having ordinary skill in the art. The purpose of the program is to place the MIDI data from MIDI source 11 into subcode pack by adding the necessary mode, item and command entries, and determining and adding the six parity words. A description of each of its routines is as follows. A hierarchy chart which describes which function calls which sub functions is shown in FIG. 4a-4h. In FIGS. 4a-4h, the references to MPU-401 is MIDI interface board 13 which as previously noted is based on Roland' s MPU-401 technology.

MAIN

Main program which calls the major functions described below. (accepts default tune file name as a command line parameter if present)

PUT.sub.-- MENU

Displays title, current tune and menu items:

"RECORD",

"RECORD WITH CLOCKS",

"PLAY",

"PLAY WITH CLOCKS",

"SAVE",

"LOAD",

"SELECT TUNE",

"SAVE SUBCODE DATA",

"LOAD SUBCODE DATA",

"QUIT",

RECORD (int MIDI-sync)

Starts recording with optional MIDI clock synchronization (MIDI-sync=TRUE). Starts record when command MIDI-start is received from MIDI source 11. Displays time and records until Esc is hit, the command MIDI-stop is received or out of memory.

When finished, there is a table in memory which contains the MIDI events and the time each event was received. The time is recorded as the number of 1/300ths of a second after the time the initial MIDI event is received The recorded time relates directly to which subcode pack the MIDI event will eventually be put in (see SUBCODE.sub.13 SAVE).

PLAY (int send-clocks)

Starts playing with optional sending of MIDI clocks (sendclocks=TRUE). Prompts user to enter tempo if MIDI clocks are to be sent and tune was recorded without MIDI clocks. Starts playing when spacebar is hit, or when MIDI-start is received from MIDI source 11 (if MIDI clocks are being sent) (this allows MIDI source 11 to be played back simultaneously for verification). Displays time and plays until Esc is hit, or MIDI-stop is received (if MIDI clocks sent).

SAVE.sub.-- TUNE

Saves current MIDI data in current tune file (tune-name), in raw format. For each MIDI event (including clocks), eight bytes are saved as follows: four bytes for time (in 1/300s of a second from start of tune), one byte for MIDI status, one byte for first data byte (key number if note event), one byte for second data byte (key velocity if note event), and one byte to handle MIDI events which are longer than 3 bytes. When there are 3 bytes the flag is set to zero. If tune file name contains no extension, ".TUN" is appended.

Prompts user if a file with the same name already exists to prevent accidental overwrite.

LOAD.sub.-- TUNE

Loads current MIDI data from current tune file (tune-name), in raw format. For each MIDI event in file, eight bytes are loaded as follows: four bytes for time (in 1/300s of a second from start of tune), one byte for MIDI status, one byte for first data byte (frequency number if note event), one byte for second data byte (key velocity if note event), and one byte that is set to zero for 3 byte commands. If tune file name contains no extension, ".TUN" is appended. Displays length of tune loaded and time offset of first event.

DISP.sub.-- TIMES

Displays length of current tune and time offset of first event.

SELECT.sub.-- TUNE

Allows user to change current tune file name (tune-name), displays new current tune.

MIDI.sub.-- INTR

Called whenever interrupt is received from interface 13. Reads data from interface 13 and determines if it is a MIDI event to be recorded, a request for the next MIDI event to be played, or an interface 13 message, then calls appropriate routines or sets flags as is required.

PUT.sub.-- PACK (long cur-pack, unsigned length)

Calculates parity symbols for current pack (pack) of given length (length), and stores these and the length in the current pack. Stores pack in subcode file at given pack location (cur-pack), returning FALSE if successful, TRUE otherwise.

REC.sub.-- EVENT (char offset)

Receives MIDI event from interface 13 during record, and saves as MIDI data event, setting event time to current time, after adding timing byte received by MIDI-intr and passed to this routine (offset). If event is "data-end", sets "all-end" flag to indicate end of record. If recording with MIDI clocks (add-clocks=TRUE), inserts MIDI clocks at appropriate times between events received.

SEND.sub.-- EVENT

Sends MIDI events to interface 13 during playback, adding timing byte determined by subtracting current time from event time. If the timing byte would be too large, sends timing overflow message to interface 13 instead. If end of playback data has been reached, sends "data end" message to interface 13. If playing back with MIDI clocks (adjusttempo=TRUE), adjusts event times so that they correspond to the desired playback tempo.

REC.sub.-- MESSAGE

Receives MIDI system message from interface 13, setting "MIDI-stop" flag if message was "MIDI stop". This indicates MIDI source 11 was stopped, and aborts play.

SEND.sub.-- RESET

Resets interface 13, returning FALSE if reset successful, TRUE otherwise.

SEND.sub.-- AND.sub.-- REC (char command)

Sends data request command to interface 13, and returns interface 13 response. Sets "waiting-for-response" flag so that "MIDI-intr" will read response byte when it receives command acknowledge.

SEND.sub.-- COM (char command)

Sends command to interface 13, returning FALSE if transmit successful, TRUE otherwise.

SEND.sub.-- DATA (char data)

Sends data byte to interface 13, returning FALSE if transmit successful, TRUE otherwise.

REC.sub.-- DATA

Receives data byte from interface 13, returning data byte if successful, 0 otherwise.

GETSTR (int length, int caps-only)

Displays current value of data input string (in-text) at current screen position, moves cursor to end of string, and allows user to edit string by using backspace and entering characters. String input is limited to "length", and any alpha input is converted to capitals if "caps-only" is TRUE. Returns TRUE if user exits editing with a return, FALSE if user exits with ESC.

GETYN

Waits for user to enter `Y` (or `y`), `N` (or `n`) or ESC.

Returns TRUE if user entered `Y` (or `y`), FALSE otherwise.

SAVE.sub.-- SUBCODE

Saves current MIDI data into subcode data file. Prompts user with last entered subcode file name (or default at start), and allows it to be changed. Checks that subcode file exists, and that it is a multiple of ten packs (240) in length. Allows user to change/enter number of seconds and frames to start of audio, then checks that there is enough room in the subcode file to save all MIDI data with that lead in. This routine then "lines up" the first non-clock MIDI event with the position in the subcode file which is synchronous with start of audio. It then determines a position in the file synchronous to where the MIDI clock before the first non-clock MIDI event should occur. It writes a subcode pack containing a MIDI clock in this position and bases the positions of all the clocks and nonclock events that follow on this first placement. The routine stores data in the appropriate packs, clearing any packs intended for MIDI that are unused, until all packs of the remaining packs in the subcode file have been "passed". Displays error message if all MIDI data did not fit.

The exact location of any MIDI event in the subcode data file is determined by the time the event occurs. This time is recorded (see RECORD) in 1/300ths of a second. Three hundred sub code packs are transferred from a compact disc each second when the disc is playing. Therefore, the ideal location for a MIDI event is the pack which is the exact number of 1/300ths of a second into the subcode file. If this pack is not intended for MIDI--but, is reserved for graphics for example--the next pack useable for MIDI gets the event.

MIDI events are put in a single pack, they do not span packs. For example, the 3 bytes of a NOTE-ON event--a status byte, a frequency byte and a velocity byte--will always be in the same pack, the status will never be in one pack while the frequency and velocity are in the next available MIDI pack. This guarantees that musical instruments will receive the NOTE-ON event with no significant delay between bytes.

The bytes of MIDI data are formatted into subcode packs of 24 words where there are six bits in each word which is fully compatible with compact disc subcode graphics. The bit-for-bit manner of formatting the MIDI data is described in FIGS. 1b through 1d.

PUT.sub.-- PACK (long cur-pack, unsigned length)

Calculates parity symbols for current pack (pack) of given length (length), and stores these and the length in the current pack. Stores pack in subcode file at given pack location (cur-pack), returning FALSE if successful, TRUE otherwise.

LOAD.sub.-- SUBCOD

Loads current MIDI data from subcode data file. Prompts user with last entered subcode file name (or default at start), and allows it to be changed. Checks that subcode file exists, and that it is a multiple of ten packs (240) in length. It loads MIDI data from subcode file with the bandwidth desired, until all packs in the subcode file have been "passed". Loading is only used to check the distortion (if any) induced by subcode translation.

GET.sub.-- PACK (long cur-pack)

Loads current pack (pack) from given subcode file pack position (cur-pack). Returns FALSE if successful, TRUE otherwise.

CALQPAR

Calculate q parity according to the Red Book.

CALPAR

Calculate non-q ("p") parity according to the Red Book.

A suitable program in C source code and Microsoft Macro Assembler for executing in computer 19 to move subcode data from a file on hard or floppy disk 17 to the computer's random access memory (RAM) is attached hereto as Appendix 2. The data in RAM is then accessed by encoder interface logic 21 by direct memory access (DMA) and presented to compact disc encoder 23 as parallel electronic signals. Encoder 23 uses these signals in conjunction with main channel audio data from another source to cut the master for a digital audio compact disc with subcode data.

A description of each of the routines of the program follows. A hierarchy chart which describes which function calls which sub-functions is shown in FIG. 5.

MAIN()

Requests and receives the file name for the subcode data on hard or floppy disk 17. It passes this name to the "playback" routine which actually handles the data transfer. Upon return, "main" requests another file name and repeats the operation until stopped by a "control C" or "control break".

PLAYBACK (filename)

This routine opens the file of subcode data and returns if there is an error. If there is no error it invokes "dmaseton" which initializes encoder interface logic 21 to begin accessing and transferring data to encoder 23 when the board receives an electronic signal to do so. "Playback" then invokes "readdat" which reads data from the file, adds syncronization bytes according to the "Red Book" and moves the data to one of two data buffers in RAM. In the present embodiment of the program, each data buffer is 8134 bytes and is capable of holding 83 packets of subcode data. Another call to "readdat" is used to fill the second buffer, the "waitint" is called which waits for a signal from the encoder. When that signal is detected, "playback" calls "readdat" again to re-fill the first buffer and "waitint" to wait for a signal that the second buffer has been read and transferred. This process continues with data being read into one buffer while encoder interface logic 21 transfers data from the other buffer until all data from the file has been transferred. "Playback" invokes "dmaoff" to effectively shut down interface logic 21 activity, and closes the disk file containing subcode data and returns to "main".

READDAT (bufnum)

This routine is passed "bufnum" which indicates if the data should be transferred to the first or second buffer. "Readdat" begins by reading 83 packets worth of data from the subcode file on disk 17. Since the disk file does not contain sychronization bytes S0 and S1 (explained in the "red book"), there are only 96 bytes for each packet in the file. Thus, the program attempts to read 83.times.96 bytes=7968 bytes. If there is less than 7968 bytes left in the file, whatever data there is on the file is read in and binary zeros are added to the end of the data to pad it out to 7698 bytes. If the read attempt detects no data (as in the read after a partial read), the program returns to "playback" with a status of end-of-file.

The data read from the file is moved packet by packet--96 bytes at a time--to the buffer area indicated by "bufnum". Before each move to the buffer, an S0 byte and an S1 byte are added before the 96 bytes of data read making a move of 98 bytes to the buffer. In this manner, the buffer contains all the S0 and S1 data needed for the encoder.

DMASETON()

Begins channel 1 DMA from 2C00:0 to 2C00:(83*98)d - wrap around mode. Calls "dma.sub.-- on" to actually initialize initialize the DMA controller of computer 19 and set up the DMA channel.

DMA.sub.-- ON()

Sets up DMA channel 1 for 7.35 khz transfer of subcode bytes to encoder interface logic 21. The details for this may be found in the IBM PC Technical Reference Guide.

DMA.sub.-- OFF()

Stops DMA on channel 1 (subcode) by setting ch 1 mask bit.

WAIT.sub.-- INT()

Waits for a change in the bit 15 of the DMA controller's output count register accessed using routine "get.sub.-- dma.sub.-- count" (indicating a buffer boundary crossing--end of buffer)

GET.sub.-- DMA.sub.-- COUNT()

Reads the contents of the remaining count register of DMA channel 1 and returns the count. ##SPC1##

Claims

1. A system for storing MIDI information in subcode packs for encoding on a compact disc having a main channel and a subcode channel comprising:

(a) a computer having a random access memory, a processor and coupled to a storage device;

(b) MIDI source means for generating MIDI signals;

(c) first interface means coupled to said MIDI source means and said computer for converting the MIDI signals to a form for loading into said memory for access by said processor;

(d) program means for controlling the operation of said processor and said memory so as to convert the MIDI data in said memory to a plurality of subcode packs and writing said subcode packs to a storage medium on said storage device;

(e) second interface means for retrieving said subcode packs on said storage medium and for coupling to a compact disc encoder for converting the MIDI data in the retrieved subcode packs to electric signals useable by the compact disc encoder to encode said MIDI data in the subcode channel on the compact disc.

2. The system defined by claim 1 wherein said program means comprises:

(a) means for creating a subcode data file which is a multiple of at least one subcode pack in length and placing a first MIDI event in a predetermined position within a subcode pack in said subcode data file based upon a predetermined time such that said first MIDI event is placed relative to a start of audio data in said main channel, and placing all subsequent MIDI events in said subcode packs based upon said predetermined position, such that no individual MIDI event spans across more than one subcode pack;

(b) means for calculating parity for each subcode pack which has been created and in which said MIDI events have been stored according to a predetermined parity calculation standard.

3. The system defined by claim 1 wherein said program means comprises:

(a) means for creating a table in said memory which contains MIDI events generated by said MIDI source and a time relative to the time an initial MIDI event was generated by said MIDI source;

(b) means for creating a subcode data file which is a multiple of ten subcode packs in length, accessing said table and placing a first MIDI event in a pr-determined position within a subcode pack in said subcode data file based upon said relative time such that said first MIDI event is synchronous to a MIDI clock, and placing all subsequent events in said subcode packs based upon said predetermined position, such that no individual MIDI event spans across more than one subcode pack;

(c) means for calculating parity for each subcode pack which has been created and in which said MIDI events have been stored according to a predetermined parity calculation standard.

4. The system defined by claim 1 wherein said program means comprises:

(a) means for creating a table in said memory which contains MIDI events generated by said MIDI source and a time relative to the time an initial MIDI event was generated by said MIDI source;

(b) means for creating a subcode data file which is a multiple of at least one subcode pack in length, accessing said table and placing a first MIDI event in a predetermined position within a subcode pack in said subcode data file upon said relative time such that said first event is synchronous to a MIDI clock, and placing all subsequent MIDI events in said subcode packs based upon said predetermined position, such that no individual MIDI event spans across more than one subcode pack;

(c) means for calculating parity for each subcode pack which has been created and in which said MIDI events have been stored according to a predetermined parity calculation standard.

5. The system defined by claim 1 wherein said program means causes up to 10 bytes of MIDI data to be stored in each of said subcode packs.

6. The system defined by claim 1 wherein said program means causes up to 11 bytes of MIDI data to be stored in each of said subcode packs.

7. The system defined by claim 1 wherein said program means causes up to 12 bytes of MIDI data to be stored in each of said subcode packs.

8. The system defined by claim 5 wherein said program means ensures that no more than 125 bytes of MIDI data are stored in any 12 consecutive subcode packs.

9. The system defined by claim 2 wherein said program means causes up to 10 bytes of MIDI data to be stored in each of said subcode packs.

10. The system defined by claim 2 wherein said program means causes up to 11 bytes of MIDI data to be stored in each of said subcode packs.

11. The system defined by claim 2 wherein said program means causes up to 12 bytes of MIDI data to be stored in each of said subcode packs.

12. The system defined by claim 9 wherein said program means ensured that no more than 125 bytes of MIDI data are stored in any 12 consecutive subcode packs.

13. A method for storing MIDI information in subcode packs for encoding on a compact disc having a main channel and a subcode channel using a computer having a random access memory, a processor and coupled to a storage device, said method comprising the steps of:

(a) generating MIDI signals from a MIDI source;

(b) converting the MIDI signals to a form for loading into said memory for access by said processor;

(c) controlling the operation of said processor and said memory so as to convert the MIDI data in said memory to a plurality of subcode packs and writing said subcode packs to a storage medium on said storage device;

(d) retrieving said subcode packs on said storage medium and converting the MIDI data in the retrieved subcode packs to electric signals for encoding said MIDI data in the subcode channel on the compact disc.

14. The method defined by claim 13 wherein said controlling step comprises the steps of:

(a) creating a subcode data file which is a multiple of ten subcode packs in length and placing a first MIDI event in a predetermined position within a subcode pack in said subcode data file based upon a predetermined time such that said first MIDI event is placed relative to a start of audio data in said main channel and placing all subsequent MIDI events in said subcode packs based upon said predetermined position, such that no individual MIDI event spans across more than one subcode pack;

(b) calculating parity for each subcode which has been created and in which said MIDI events have been stored according to a predetermined parity calculation standard.

15. The method defined by claim 13 wherein said controlling step comprises the steps of:

(a) creating a table is said memory which contains MIDI events generated by said MIDI source and a time relative to the time an initial MIDI event was generated by said MIDI source;

(b) creating a subcode data file which is a multiple of ten subcode packs in length, accessing said table and placing a first MIDI event in a predetermined position within a subcode pack in said subcode data file based upon said relative time such that said first MIDI event is synchronous to a MIDI clock and placing all subsequent MIDI events in said subcode packs based upon said predetermined position, such that no individual MIDI event spans across more than one subcode pack;

(c) calculating parity for each subcode pack which has been created and in which said MIDI events have been stored according to a predetermined parity calculation standard.

16. The method defined by claim 14 wherein said creating step causes up to 10 bytes of MIDI data to be stored in each of said subcode packs.

17. The method defined by claim 14 wherein said creating step causes up to 11 bytes of MIDI data to be stored in each of said subcode packs.

18. The method defined by claim 14 wherein said creating step causes up to 12 bytes of MIDI data to be stored in each of said subcode packs.

19. The method defined by claim 16 wherein said creating step ensures that no more than 125 bytes of MIDI data are stored in any 12 consecutive subcode packs.

20. The method defined by claim 15 wherein said creating step causes up to 10 bytes of MIDI data to be stored in each of said subcode packs.

21. The method defined by claim 15 wherein said creating step causes up to 11 bytes of MIDI data to be stored in each of said subcode packs.

22. The method defined by claim 15 wherein said creating step causes up to 12 bytes of MIDI data to be stored in each of said subcode packs.

23. The method defined by claim 20 wherein said creating step ensures that no more than 125 bytes of MIDI data are stored in any 12 consecutive subcode packs.