Note: Descriptions are shown in the official language in which they were submitted.
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.
12
- 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
16
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
19
- 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.
