CA2225190A1 - Distributed digital data delivery system - Google Patents

Description

CA 0222~190 1997-12-18 DISTRl~u ~ DIGITAL DATA DELIVERY SYSTEM

R~CK~,RoU~n OF THE INVENTION

Field of the Invention The present invention relates to CD-ROMs, more specifically to methods and apparatus for ordering individual music titles and recording them on a recordable audio CD.

Description of the prior Art In the music industry, the basic method for selling a new album is to record a number of songs on a music support and then to distribute the song collection through sale terminals, such as music stores. This has been know for many years and, as technology advanced, music recording media have changed, from the old vinyl records, through magnetic cassettes to audio CDs.
However, this common method of marketing music has various drawbacks. One of the most important is that people are obliged to buy a collection of songs even if they are only interested in a limited number of songs from that album. This fact may even lead people to illegally copy music from pre-recorded audio cassettes or CDs for making their own personalized collection of songs, available on the same recording medium. This results in great losses of sales for the music industry.
A new method of commercializing music is suggested in US patent 3,990,710 to Hughes. A public kiosk is used for recording individual music titles as chosen by the client.
Various songs from various singers may be recorded onto the CA 0222~190 1997-12-18 same music magnetic cassette thus providing to the client a personalized music album. However, recording on magnetic tape cassettes is not quite efficient since they deteriorate with time and with the number of plays.
A similar type of public kiosk is disclosed in US
patents 5,633,839 to Alexander et al. and 5,418,713 to Allen. In these patents, there is disclosed computer-based public kiosks that records digital music and data chosen by the client onto recordable CDs. However, the features provided by these inventions are not reliable enough, especially for the CD-ROM data writing. When a CD-ROM
burner performs digital data writing onto an empty CD, data must arrive in continuous and constant data flow to the CD-ROM device in order not to leave blank spaces onto the CD-ROM, since those blank spaces, even having a relatively small size, may result in sound glitches when the CD-ROM is later listen by the client. The CD-ROM burner systems disclosed in these prior art patents do not provide accurate techniques for writing onto a CD-ROM.
Summary of the Invention It is therefore an object of the present invention to provide a reliable method and apparatus that allow clients to make their own musical selection and to record these songs on a CD-ROM support.
It is also an object of the present invention to provide a public kiosk comprising electronic interface means for allowing a client to perform his/her musical selection, communication means for receiving from a remote server musical digital data, digital storing means for storing locally a large number of songs, optical engraving means, such as a CD-ROM burner for saving the selected music onto a CA 0222~190 1997-12-18 CD-ROM and payment means for billing the client for the musical selection.
In another preferred embodiment of the present invention, the digital data arrives in a constant and permanent flow to the CD-ROM burner in order not to leave blank spaces onto the CD when recording, thus greatly improving the accuracy of the recorded music.
In another preferred embodiment of the present invention, a large number of songs are stored locally, on a local hard disk drive inside the public kiosk for example, while other songs may be obtained via a high speed network such as a satellite link or via optical fiber, from one or more remote servers that contain larger selection of music.
It is also an object of the present invention to lS provide the public kiosk with an user-friendly interface that allows the client to easily choose songs from a list of songs, wherein songs may be classified in many different ways, such as by musical style, year of issue, name of the singer, album title or other. The electronic interface is easy-to-use even for a computer non-initiate person and may comprise a tactile screen, or a keyboard in association with a screen.
Another object of the present invention is to provide electronic modules that performs advising for the client concerning the music to be recorded onto the CD-ROM support.
This advises may be based on previous selections of this client, by association with another singer or songs, or may be based on personal information of the client (age, sex, etc).

CA 0222~190 1997-12-18 Brief Description of the Drawings The scope of the present invention will be better understood with reference to the following drawings:
s Figure 1 shows a high level block diagram of the overall system used with the present invention;

Figure 2 shows a general hardware block diagram of a preferred embodiment of the present invention;

Figure 3 shows a detailed block diagram representing the data passage from a hard-disk drive to the CD-ROM
burner;
Figure 4 shows a preferred embodiment of the present invention, namely the fuel gauge;

CA 0222~190 1997-12-18 De~ e~ Description of the Preferred Embodiments While the ideas contained herein are applicable to any type of digital data (e.g. text, computer software, audio, video etc.), the present invention will be described with reference to the delivery of digital audio data from a remote repository, through a high-speed link, to an end-point.

Further, while the consumer can select either entire audio recordings of an album (e.g. an entire CD-ROM
available on the market) or a la carte tracks (user selections), this document will limit its discussion scope to the audio tracks (e.g. songs from a Compact Disc).
Entire recordings are nothing more than a preset selection of tracks.

At the highest level, the present invention comprises a local public kiosk also called the end-point in the present application, a high speed communication link and a number of repositories which are remote servers containing large selection of music.

The repository is simply the place where the digital data (i.e. audio tracks) is stored on local storage means, such as a hard drives. It should be noted that even if other storage means may be used as well, both for the local kiosks and for the repositories, the present application will refer to a hard drive as being the storage means. The repository may be situated in one or more locations. These multiple repository locations are themselves connected via a communications infrastructure so they appear to the end-points to be a single entity.

Joining the repository to the end-points is a communications infrastructure. It is suitable that this CA 0222~190 1997-12-18 communications infrastructure will consist of a high-speed connection because of the potentially large volumes of data that may have to be moved from the repository to the end-point.
Figure l illustrates the general block diagram of the present invention.

The end-points will be packaged differently depending on their location. One set of end-points may be deployed in a public access setting, while others may be used in the home (in the form of consumer electronic devices).
Moreover, on one hand, there is a need for a more robust industrial grade enclosure, on the other, esthetics and cost may be more important.

Regardless of physical packaging, the end-points all comprise an user manager that performs the user interface program, a file manager for managing the song selections and of a communication manager for downloading the song selections that are not available locally and for validating credit card payments.

Each of these managers is a software application that executes using specialized hardware, in accordance with its predominant task. Further, each of these managers may be tightly coupled (i.e. on a single computer with each manager being a task within a real-time, multitasking operating system) or loosely coupled (i.e. on multiple computers connected through communication channels).

While each manager has been named in accordance with its predominant function, each of the managers may contain within it, other functions. For example, each manager may have a message delivery and queuing function, a timer function, a communications function, an I/O function etc.

CA 0222~190 1997-12-18 Periodically there will be a requirement to process additions/deletions and changes. The List Synchronizer will communicate with the File Manager to obtain the latest list of content. Since the File Manager manages the tracks, only the list of available tracks ~not the tracks themselves) has to be given to the Repertoire List Synchronizer.

Each public kiosk may be composed of one or more computer systems. It appears that it is preferable to have a plurality of computers, since it is better for each one to run a single application than to have a more powerful multi-tasking computer running a few applications. Therefore, this distributed architecture was created to provide maximum flexibility. It can, for example, take advantage of the fact that three commodity computers each executing a manager could potentially be more cost effective than having a single more powerful machine executing all three managers under a multi-tasking operating system. Such an architecture is shown in Figure 1, wherein the user manager runs onto a Windows 97 system while the CD burner runs of a DOS machine.

Another advantage of this architecture is that it allows one or more User Manager(s) to operate with zero or more File Managers, to operate with one or more Communication Manager(s). The significance of this can be better illustrated through an example. Let's assume for a moment that each manager is running on a separate computer.
If it is determined that the user interacting with the User Manager is the rate-limiting step in the process (i.e. the User Manager's execution time is some multiple of the time required by the File Manager), cost reductions can be realized by having multiple User Managers operating in conjunction with a single File Manager.

' CA 0222~190 1997-12-18 , The minimum functioning architecture for the public kiosk consists of a single User Manager and a single Communication manager. This would be analogous to a personal jukebox located in the home where selections are purchased from the available repertoire, downloaded and stored internally on a storage means.

At the other extreme, end-points deployed in a public access setting (such as a retail outlet) may be grouped in clusters. Each cluster may consist of one or more User Managers, zero or more File Managers, and one or more Communications Managers.

In a preferred embodiment of the present invention, a cost effective architecture is used and implies to have the User Manager on one computer and the File and Communications Managers on a second - with a communications link between the two computers.

The User Manager's primary responsibility is to solicit, and guide a user through the process of making audio track selections. Once the choices are made, they are confirmed, the payment method chosen and the credit verified. The process then proceeds to the manufacturing phase, which is in the domain of the File Manager.

When the end-point is not involved in interacting with a potential customer, (i.e. the end-point is idle,) control is turned over to the Advertising Manager. Once potential customers identify themselves to the end-point, the Advertising manager turns control back over to the Coach.
The coach is an extremely user friendly piece of software that helps customers through the selection process.

Besides being able to browse selected lists of tracks (e.g. local specials, top l00, latest releases etc), the - CA 0222~190 1997-12-18 potential customer is also offered the ability to search for audio tracks. The search may be performed by looking for an artist, a particular sound track, a label, an year of issue, a genre (e.g. Blues, Jazz etc) or an subtext within lyrics.
The search facility is easy to use, and the selection of tracks is retained across searches on a session by session basis. In the event that the customer cancels the selection process, he/she is offered the choice to save the tracks selected so far in anticipation that the selection process will continue later.

In another preferred embodiment of the present invention, the digital data arrives in a constant and permanent flow to the CD-ROM burner in order not to leave blank spaces onto the CD-ROM when recording, thus greatly improving the accuracy of the recorded music. This architecture is shown in Fig. 2 wherein data is first stored onto a hard disk drive in an compressed and encrypted format. When a song track is requested by the user, the digital song is decompressed and decrypted by the Decompression and Decryption Module, the stereo bit frame is created by the Framing Module and data get into the CD-ROM buffer in a continuous and steady flow. This buffer must never be empty in order to be able to feed the CD-ROM burner constantly with data so it may constantly burn the CD-ROM disk. The reason for this is that when a CD-ROM burner does not have any more data in its buffer to engrave on the disk, it does not stop immediately engraving but rather put a number of zeros (0) on the disk after finishing engraving the valuable data. These zeros are then left on the disk because at the next CD-ROM head passage, data will be engraved on the disk at the end of the zeros stream. This string of zeros is then audible at the playback time, thus reducing the recording accuracy of the disk. This is the reason because the sound tracks are stored on a hard disk drive instead that on a CD-' CA 0222~190 1997-12-18 .

ROM drive: the hard-disk allow a steady stream of data to be read from it so it provides continuous flow of data toward the CD-ROM burner, while a CD-ROM reader would sequentially read data, output data and replace its head reader, thus not providing continuous data flow. This embodiment of the present invention is showed in Figure 2.

An Internet Web (WWW) Site may also be made available to potential customers to allow off-line choosing. This web site will allow potential customers to browse and search the repertoire, listen to sound bites from tracks and save their selections. When the customers then visit the end-point and identify themselves, their pre-chosen track list(s) will be recalled and the end-point can immediately proceed to the recording process (after customer confirmation).

The Web Site may also e-mail notices and special promotions on an ongoing basis (provided that the customer has requested to be added to the mailing list).

If at the end of the search process the customer has been unable to find the particular track that they were looking for, the system will prompt and request a few lines of text to help identify what they were looking for (e.g.
artist/title guess/recording date etc). This information will then be sent to Customer Service and will be used to track the lost opportunity. This lost opportunity might also be communicated to the respective audio track owner(s) so that it can be added to the repository and made available to the customer. Over time these statistics will be very useful to record labels, as it will help them decide which titles from their catalogues should be made available.

30 As mentioned above, regardless of the track selection process (searching, browsing etc), the tracks chosen are - CA 0222~190 1997-12-18 retained and calculations are performed to indicate both the cost, and the accumulated time as shown in Figure 4.
The repository may also have the flexibility to associate sophisticated business rules on a track by track basis. These business rules are applied in real-time as each track is selected to provide the customer with track costing. The track owner(s) may provide the business rules.

There also may be a need to apply business rules based on certain collections of songs. For example, record labels may require that new releases be only delivered in their entirety (since the same collection of songs might be available through traditional retail channels). This will most likely be done to preserve the investment made in the production of the new release by the record label.

These business rules (associated with collections and with each track) will take into consideration such things locale, currency exchange, taxation, tariffs, royalties and time-limited promotions. This kind of flexibility may be provided to protect the existing business models of the record labels.

Once all the tracks have been chosen, the user may be asked to allow the File Manager to reorder the tracks. This will be done when it is discovered that the tracks that are local are interleaved with tracks that have to be downloaded. If the missing tracks can be retrieved while the other locally cached tracks are being produced, the amount of time that the consumer has to wait is reduced.

The client terminal may also provide a music advisor service for customers wanting to be helped in their musical selection. Assume for a moment that a customer has chosen three or four tracks. Further, suppose that he/she is not CA 0222~190 1997-12-18 interested in continuing the selection process but wishes to be offered advice on other tracks that could be added to the list. The Music Advisor feature of the User Manager will offer suggestions of other tracks that the customer may be interested. These additional tracks will be suggested using essentially two mechanisms:

l)Based on categorizing songs and/or artists together (e.g. if you like Ella Fitzgerald, you might also like Billie Holiday). This categorization is already being done by critics, fan clubs etc. The system will offer multiple categorization facilities so that the Music Advisor can offer additional selections based on reviews, genre, top 10 statistics and other sorts of groupings.

2)The second method for suggestions will be based on tracking the history of previous selections. From day one, the Music Advisor will track the song lists that other customers have chosen and infer that certain songs seem to have an affinity for one another. A grouping of songs based on an affinity is referred to as clustering. To offer additional suggestions for tracks, the Music Advisor simply examines the customer's current choices, locates those songs' cluster(s), and offers the other members of the cluster as suggestions.

The songs suggested by the Music Advisor will improve over time as historical selections accumulate and alternative suggestion "advice" is made available from critics, clubs and other sources.

- CA 0222~190 1997-12-18 The Music Advisor may also be made available through the Off-line Choosing facility previously mentioned. This will allow people to spend as much time as they like (in the comfort of their homes), to create the right combination of musical selections. Upon completing their list, they save it and that list is later retrieved when they arrive at the end-point.

The Advertising Manager will ensure that any self-promotion or advertising done on behalf of a third party is up to date and tracked. This will ensure that the promotion gets the frequency of exposure agreed to. It might also be desirable to air certain advertisements during particular days or even at particular times during the day. The Advertising Manager will create an audit trail showing exactly when the promotional information aired. The Advertising Manager also ensures that the advertising content is up-to-date by synchronizing with the repository.

To foster repeat sales, a loyalty system will be established that will remember tracks selected via an Internet Web site and a frequent buyer program implemented.
The intention is to have an electronic cash token with a unique ID that identifies the customer to the system so that it can recognize and cater to the individual's needs and tastes. The Loyalty Manager (client side) will communicate with the Loyalty Manager (Server Side) to retrieve and update the customer info.
The Unified Payment Manager presents a common dialog and interface to the application regardless of the method of payment. The most suitable payment method is using credit cards but other payment methods may be used as well, such as cash or debit card.

CA 0222~190 1997-12-18 Since our potential customers may not be of the age of majority, the system will accommodate the use of an electronic-cash ~e-cash) token. The e-cash token can be given as a gift preloaded with a selection of songs, song credits or simply with soft currency (i.e. e-cash proper).
It might also be desirable to have the record labels' and maybe the artists' offer their own loyalty tokens. The packaging of the loyalty tokens may be in the form of debit cards or other in other shapes and sizes such as pendants or wristwatches.

Periodically there will be a requirement to process additions/deletions and changes. The List Synchronizer will communicate with the File Manager to obtain the latest list of content. Since the File Manager manages the tracks, only the list of available tracks (not the tracks themselves) has to be given to the Repertoire List Synchronizer.

As each track is chosen (using any of previously described methods) the User Manager sends the track title to the File Manager so that it can:
l)Retrieve the cost of the track title based on the recorded business rules (i.e. royalty, exchange rate, and markup). This will be done via the Unified Payment Manager (Client Side).

2)Verify that the chosen track title is being cached locally - and if not - then

3)The Communications Manager will consider downloading the track title from the repository It is imperative - particularly during the production process - that determinism be foremost in the implementation of the File Manager and the Communications Manager. An embedded application or a real-time operating system will be - CA 0222~190 1997-12-18 used to ensure that performance objectives are met and that production of the recording and communications occur on tight deadlines.

In addition to being given notice of a user's desire to purchase a particular track, a Predictive Downloader will also consult other end-points (most likely on a regional basis) to anticipate the list of tracks that need to be cached locally. This will most likely occur in the off-hours.

As tracks are added at the repository, a repertoire synchronize command is sent to each end-point (in a staggered fashion, to avoid a broadcast storm). The repertoire synchronizer then requests the adds/changes/deletions from the repository and updates its database of tracks to reflect the changes.

The adds/changes/deletions are then sent to the User Manager (Repertoire List Synchronizer) so that the latest and most complete list of tracks is always available to the consumer.

As part of the recording process, the peaks and valleys (minimum and maximum) will be determined and stored with the track information. When it comes time to produce a recording of a number of tracks, the minimum and maximum will be considered against other minimum and maximum for the other tracks and a compensation value will be calculated for each track. This is necessary because each track has the potential of being recorded at different volume levels producing a very noticeable increase/decrease in volume from track to track. This Recording Level Normalization is done to prevent the consumer from having to continually adjust the volume at playback time. If however an entire recording is chosen, no Recording Level Normalization will occur.

' CA 0222~190 1997-12-18 , This will ensure that a copy of this recording from a retail store will sound identical as compared to the copy produced by the end-point.

The Communications Manager will be implemented s independently of the physical network. The only assumption will be that the network protocol will be IP. This will allow for the adoption of the best and most cost effective communications mechanism. Currently IP is supported over more communications networks than any other protocol.
Examples of physical networks that may be used with the present invention are: Satellite, ISDN, ASDL, ATM, Ethernet, Token Ring and voice grade modems over POTS (plain old telephone system).

All communication traffic that is of a sensitive nature that cannot be conducted across a secure channel (where both ends of the communication pipe are controlled) will be encrypted. Encrypted traffic will occur particularly if a public network has to be traversed such as the Internet.
Security will be of the utmost importance for credit card transactions and anywhere privacy is paramount.

The Music Advisor Module is located at the server side (the repository) and will accumulate user choices in an effort to identify patterns where songs have been chosen and manufactured together. This is referred to as clustering.
Collections of songs will be sent from the end-points and stored at the repository under the control of the Music Advisor (Server Side) where clusters will be identified and will then be provided to the end-points to help users in selecting tracks.

30 The Music Advisor (Server Side) will also be the keeper of the pre-selected collections from Critics, Artists and CA 0222~190 1997-12-18 Fan Clubs. An unlimited number of collections of this sort can be made available.
Self-promotion and paid-for advertising will be created at the repository, put under the control of the Advertising Manager (Server side) and subsequently pushed to specific end-points (where it will be managed by the Advertising Manager (Client Side)).

The frequency and exposure of the advertisement will be tracked by the individual end-points and those statistics will be passed back to the Advertising Manager (Server Side) to provide an audit trail to advertiser that their content has indeed aired.

The Loyalty Manager (Server Side) will track on a system wide basis individuals who are planning to use or who are already using the delivery system. Purchase history as well as specific interests and choices will be tracked in an effort to make the system friendly and accommodating.

Track lists chosen through the Web site or at the end-points may be stored here and delivered to the end-points on an as needed basis. These lists must be tracked at the repository to make them available. Statistics may also be made available (under privacy rules) to those who need to know the activities of individuals.

The repertoire for a given region may be different than another. For example, the music that is cached locally in Spanish regions may most likely be different than the music that is available in English speaking regions. Further, particular genres may be more predominant in certain areas (e.g. Country versus Rock).

- CA 0222~190 1997-12-18 .

The Repertoire Evolver may gather statistics of tracks cached by the end-points and accumulate regional statistics.
These lists may then be made available to other end-points in the region in an effort to anticipate the customer's choices.
A Unified Payment Manager located at the server side will act as an intermediary between end-point credit verification and the respective credit granters. The Unified Payment Manager (Server Side) may cache a list of bad credit cards to prevent unnecessary communication with the credit granter's system. By having all credit transactional information flowing through the Unified Payment Manager (Server Side), adding additional creditors and ensuring timely and up-to-date information regarding the purchaser will be greatly simplified.

The Unified Payment Manager (Server Side) will also factor in business rules and will be sensitive to exchange rates, taxes and other costs of doing business.

Hardware requirements The User Manager provided with a public access terminal may use COTS (common off the shelf) parts. A touch sensitive screen with appropriate user interface may be also provided to simplify and make more rugged the end-point.

The only specific hardware requirement is the need for a communications mechanism to the File Manager (and the Communications Manager). Currently this has been achieved using an RS-232C connection. However, if the number of User Managers (on the front-end) out-number the back-end units, a multi-drop or network approach will have to be deployed.

- CA 0222~190 1997-12-18 Since the entire user interaction occurs with the User Manager, it is important to make it operate as independently as possible from both the File and Communications Managers.
This will be particularly important if the user decided to engage in some compute intensive activity such as playing a full motion video. The File and Communications Managers must have a deterministic response if success is to be achieved in the production of the recording.

The File Manager requires access to potentially a large amount of disk space. As such, hardware with a SCSI bus may be employed to ensure a large storage space and achieve the performance requirements.

The hardware requirements have to satisfy the needs of potentially multiple writing devices. Calculations and testing have proven that this activity, while not compute intensive, is I/O intensive.

The repository will be a large-scale disk farm. Since the repository is vital for the success of the operation, the repository will be constructed to be highly scaleable, and have high availability. Further, it will be distributed (not centralized).

From the end-point perspective, the repository will appear to be a single entity but for the purposes of not having a single point of failure, the repository will be divided between two or more geographical locations. This will decrease the possibility of a catastrophic event (e.g.
earthquake, flood etc) shutting down the operation.

The repository will also operate on 7x24 (seven days a week, 24 hours a day). Each of the repositories will have a near complete copy of all the digital data that is available - CA 0222~190 1997-12-18 for delivery. Synchronization mechanisms will be employed to ensure that all repositories are up-to-date.

A Customer Service facility will also be established at one or more locations (perhaps housed in the same physical location as one or more of the repositories). Customer Service will respond to customer inquiries and provide a mechanism to ensure customer satisfaction.

The inter-manager communications will be based on message passing. This message passing mechanism will be implemented independent of the underlying transport protocol or physical layer.

The inter-manager communication may be an efficient module. It may not tax the processor when tasks are local to the same memory space, but it will be robust enough to support the guaranteed delivery of messages. It may also include a time-out facility to prevent deadlocks (because of a message getting lost).

The repository to end-point communication will be via a high-speed satellite connection using a broadcast model.
With exceptionally high speed pipes and the ability to update multiple end-points simultaneously, this is an ideal communication mechanism for digital data delivery.

Since very small quantities of data flow from the end-point to the repository (e.g. credit card authorization requests, purchase information, advertising frequency and time of day, etc.), a much slower communication channel can be used. As such, it is anticipated that the end-point to repository communication will be via a 56K modem over POTS.

Since the end-points in retail location will essentially be idle at certain times in the day, it will be - CA 0222~190 1997-12-18 possible to have them perform their maintenance chores (e.g.
updating local cache of songs, performing system checks and diagnostics, etc) in off hours. This will allow for lower cost operation since most telephone companies offer discounts from 18:00 till 06:00 the next day.

Hardware Equipment To better understand some of the details surrounding the movement of data in the writing of digital audio data, consider the following tables which provide examples of the hardware equipment needed in order to implement a system as the one disclosed by the present invention. It has to be noted that these hardware equipment are only provided as an example and are not restrictive under any circumstances.
Other combinations of materials may be used as well.

Mo~C~ PCBusArc!~ ~Ch~ ;t;.s ISA EISA Mac~Ch~el V~Bus PCI
Data Path Width 8/16 32.00 16132164 32l64 32l64 Data Bus Speed (M~) 5.33/8.33 8.33 10.00 33/50 33.00 Data Transfer Rates (MB/sec) 5.33/8.33 33.00 20/40/80/160 132/264 132/264 Data Rates T . l ~ (MB/sec) 5.33/8.33 33.00 40 (PS/2)/80 (RS/6000) 132.00 132.00 Numberof Slots 0-8 0-8 0-8 0-2 W
BusMasters Supported No Yes Yes Yes Yes Data/Address Parity No No Yes No Yes Sy~c, Channel Checks No No Yes No Yes Card ID/Auto Confi~lr~ n No Yes Yes Yes Yes Works with MC/ISA/EISA N/A N/A N/A Yes Yes CA 0222~190 1997-12-18 Tl-- ~' 'Thr~ ~, ' of Typic~DeviceBuses SCSI2 Fast Wide SCSI

Data Tran~fer Rate (MB/sec) 10 20 Pc.~f~ - ~ P ~, ~ . for Various Speeds of CR-R Writers 1~ Writer 2~ Writer 4~ Writer 8x Writer 16~ Writer 45 n~in CD 45:00 22:30 11:15 5:37 2:48 (mm:ss) Or (MB/sec) 0.15 0.29 0.59 1.17 2.34 Most device buses (e.g. SCSI) are relatively low speed as compared to the internal buses currently being used in PC
architecture (e.g. PCI). Therefore it can be seen that the data transfer rate across the device bus will in no way tax the internal bus. And the throughput required in writing to the CD-R device(s), would not tax the SCSI bus unless multiple high-speed writers are simultaneously employed.

Given that the current architecture uses SCSI as the device bus and PCI as the internal bus, it can be seen that a single SCSI bus could easily support 32 writers (even 15 though the SCSI bus specification only supports 8 addresses (one for the controller and 7 devices)). Separate buses also allow better caching at the operating system level improving application performance.

It should also be noted that the data being read from a 20 CD-ROM and ultimately being written to CD-R must traverse two buses, three times: upon reading, the data travels across the device bus then across the internal bus. Upon - CA 0222~190 1997-12-18 writing, the data travels across the internal bus then across the device bus. The writing step is repeated.

Since the device bus is the limiting factor in moving the data, attention has to be paid to make sure that these device buses are optimized. So for example, in an effort to provide consistency between the reading and the writing operations (particularly if there is more than one writing device), two SCSI buses may have to be used. The first bus will support the drives storing the track data, the second bus would support the CD-R writer(s).

In a preferred embodiment of the present invention, SCSI CD-R drives from Kodak ( PCD600 ) and Yamaha ( CD400 ) are used as CD-ROM writers since they are capable of consistently produce error free recordings. In the case where multiple disks are daisy-chained together, a fast, wide SCSI bus may be employed to ensure that data is delivered to the CD-R Writer before its buffer is starved.

Claims