	    USE OF CDDB SERVICE IN YOUR SOFTWARE
	    ------------------------------------
		  by Ti Kan and Steve Scherf

		  @(#)cddb.howto	1.23 98/05/12



	In this document:

	- WHAT IS THE CDDB
	- CDDB USE RESTRICTIONS
	- TWO FORMS OF ACCESS TO THE CDDB
	- CDDB DISCID
	- REMOTE CDDB ACCESS
	- CDDB SUBMISSION
	- QUESTIONS?
	- APPENDIX A - CDDB DISCID ALGORITHM
	- APPENDIX B - CDDB FILE FORMAT
	- APPENDIX C - CDDB SERVER PROTOCOL
	- APPENDIX D - OFFICIAL CDDB SOFTWARE DISTRIBUTION SITES



WHAT IS THE CDDB
----------------

CDDB (CD database) is an information database containing artist, disc
title, track titles, and other information for digital audio compact
discs.  It was created originally to support Xmcd, a CD-audio player
software package for many computer platforms (primarily UNIX) running
the X11 window system.  It uses the OSF/Motif toolkit for its graphical
user interface.

Early versions of xmcd allowed users to enter the CD information and
save it on the computer's local disk.  The next time a user loads the
same CDs in the drive, the saved information is automatically retrieved
and displayed.  Further more, xmcd a "Send" feature in xmcd allows its
users to submit CD information entries to the central archive via
Internet electronic mail.  Over time, this archive has grown to contain
a substantial collection of CD information and is continuing to grow at
a rapid rate.

The CDDB data archive used to be available in full via FTP on the
Internet, so that users can download this archive onto their computers
and use it with xmcd.  However, the data has grown large enough over
time to make it unfeasible to be distributed or used in this manner.

To address this issue, xmcd began supporting the concept of CDDB servers,
such that users no longer need to download the entire CDDB to make full
use of it.  Rather, a number of CDDB server hosts have been set up on
the Internet around the world, and xmcd running on a system which is
connected to the Internet can connect to one or more CDDB servers and
query the CD database information.

The CDDB data format and the CDDB servers are designed to be open, and
are now used by many other client application software requiring CD
information.  The list of CDDB-capable applications is growing rapidly
and a current list of these applications is available via the CDDB web
site:

	http://www.cddb.com/


CDDB USE RESTRICTIONS
---------------------

The xmcd package and the CDDB server software are both released as free
software under the GNU General Public License, and we would like to
foster the concept of free software.  Moreover, the public CDDB servers
all run on sites that have graciously volunteered their disk space,
computing and network resources, not to mention occasional maintenance
and support chores, all for free.

Given this, we provide full assistance to freeware authors who desire
to incorporate the use of CDDB into their software.  In addition,
shareware programs are also supported, because it is our understanding
that shareware authors, like freeware authors, usually develop their
software because they enjoy doing so, and they rarely make significant
enough money from their shareware programs.  Users of CDDB-capable
freeware and shareware applicationa may use the public CDDB servers for
free.

Commercial uses of CDDB data and/or servers are subject to negotiations
with the CDDB Project.  Write to us at cddb-support@moonsoft.com for
information.

The xmcd and CDDB server software are both released to the public with
full source code.  You may inspect the source to see how it works. but
please be aware that the source code to both of these packages are
released under the terms of the GNU General Public License.  The full
text of the GNU GPL is in the COPYING file in each of these packages.

If you plan to use the CDDB and/or the CDDB servers in your software,
please notify cddb-support@moonsoft.com of your intention.  Also, we
appreciate that you keep us posted as to your development/test progress and
release schedules.

You must explicitly give credit to the authors (Ti Kan, author of xmcd
and creator of the CDDB concept and maintainer of the CDDB sites; and
Steve Scherf, author of the CDDB server software and co-designer of
the remote CDDB interfaces) both in all documentation and when the product
is operating.  The latter need not appear conspicuously, but should be
viewable by the user through some obvious means.



TWO FORMS OF ACCESS TO THE CDDB
-------------------------------

If you are interested in incorporating the use of CDDB in your
software, there are two forms of access that you may consider.

1. Local access

   In this mode your software simply attempts to open local files on
   the computer to access the CDDB.

   You may store the CD information in the CDDB-native format (See
   Appendix B), or another format of your choice (for example, the
   Win95 cdplayer.ini format).

   Note that the full CDDB archive data is no longer available for
   downloads, therefore this mode is only useful to retrieve CD data
   that is entered by the user and saved to disk.

2. Remote access

   In this mode the software must connect to a CDDB server on the
   network to access the CDDB.  There is a CDDB server protocol that
   the software (also known as the "client") must use to converse with
   the server.

   This mode allows the client application full access to the entire
   CD database over the Internet.  The data returned is in the CDDB
   native file format as described in Appendix B.

You may choose to support only remote access mode, or both remote and
local.  We do not recommend a local-only application, since it is not
very useful.


CDDB DISCID
-----------

Both forms of CDDB access requires that the software compute a "disc
ID" which is an identifier that is used to access the CDDB.  The disc
ID is a 8-digit hexadecimal (base-16) number, computed using data from
a CD's Table-of-Contents (TOC) in MSF (Minute Second Frame) form.  The
algorithm is listed below in Appendix A.

It is crucial that your software compute the disc ID correctly.  If it
does not generate the disc ID, it will not be compatible with the
CDDB.  Moreover, if your software submits CDDB entries with bad disc
IDs to the CDDB archives, it could compromise the integrity of the
CDDB.

If you have access to a UNIX platform that xmcd supports, we suggest 
installing xmcd, and then testing the disc ID code in your software by
comparing the disc ID generated by xmcd with that of your software
for as large a number of CDs as possible.


REMOTE CDDB ACCESS
------------------

In order to perform remote access of CDDB servers, your software must be
able to communicate with a remote CD server system via TCP/IP.  There are a
number of public CDDB servers operating on the Internet.  The current list
of public servers is listed on the CDDB Web site at:

	http://www.cddb.com/

The current list of public servers may also be obtained programmatically
via the CDDBP "sites" command.  The permanent server site, cddb.cddb.com
(at IP port 8880) has been established in order to provide a reliable source
of server site information via the "sites" command. This address may be safely
hard-wired into client software for this purpose.

There are two forms of remote access to CDDB servers, CDDBP and HTTP.
All current CDDB servers answer either at IP port 888 or 8880 for CDDBP and
port 80 for HTTP access.  There may be sites that deviate from this convention,
however.

You should make the CDDB server host (or hosts) and port numbers
user-configurable in your software.  Do not hard-wire the list of
CD database servers into your code.  The list of active servers changes
over time.

Note that while all the current public CDDB server sites on the Internet
support the CDDBP protocol, not all of them support HTTP.

Both the CDDBP and HTTP CDDB server protocols are described below in
Appendix C.

The CDDB entry returned from the server via a "cddb read" command is in
the format described in Appendix B below.

You may experiment with the CDDB server by connecting to the IP port for
the server host via the "telnet" program, and then typing the cddb
protocol commands by hand.  For example:

	telnet cddb.cddb.com 8880

connects you to the CDDB server at cddb.cddb.com.

Some additional notes for accessing CDDB over the Internet:

We consider the use of the "cddb query" command mandatory for all CDDB
clients. It is not valid to issue a "cddb read" command without issuing
a prior "cddb query" and receiving a good response, as it may yield incorrect
results. In addition, it is required that clients support close matches
(aka "fuzzy" matches, or response code 211) in response to a query.

The proper way to handle fuzzy matches is to present the entire list of
matches to the user and to let the user choose between them. Fuzzy matches
are listed in the order of best fit for the user's disc, so they should
be presented to the user in the order they are listed by the server.

When handshaking with the server via the "cddb hello" command, make sure
to use the proper arguments. The user and hostname arguments should be
that of the actual user, not some fixed hard-coded value. The application
name and version should be that of your application, not "xmcd" or
another existing application. While handshaking is not required for
certain commands such as "sites" or "motd", it is suggested your application
handshake regardless of the command to be issued.

The suggested algorithm for obtaining the list of server sites is as follows.
The application should be distributed with the last known list of server
sites, and should attempt to update that list from cddb.cddb.com with the
"sites" command the first time the user runs the program. Should the user
be unable to download the list of sites due to temporary network perturbation,
the application should attempt to download the site list from one of the
sites in its current list. All of the official CDDB server sites will contain
a valid list of servers, though cddb.cddb.com is the only site which is
guaranteed to always exist. After the initial download of the site list, the
application should periodically attempt to download the site list, or at
least provide the user with some method of downloading the list on-demand.

We consider it mandatory that applications implement accessing the CDDB
servers through CDDBP. It is optional for applications to additionally support
accessing the servers through HTTP. The reason for this is that CDDBP servers
are much more prevalent than HTTP servers, and are distributed around the
world more uniformly.


CDDB SUBMISSION
---------------

Your software may allow users to enter CDDB data and then submit them
to the CDDB archives.  The method of submission is to send the entry to
following address via electronic mail:

	cddb-submit@submit.cddb.com

You may implement a button or somesuch in your software's user-interface
to facilitate this.  The destination e-mail address should be made
user-configurable.  Submissions are silently accepted, and no confirmation
of receipt is sent to the submitter.  Rejected submissions are automatically
returned to the sender via e-mail with an explanation of the reason for the
rejection.

There should be one e-mail message per CDDB entry.  The mail Subject
line should be in the form "cddb category discid".  For example:

Subject: cddb rock 850f970b

The body of the e-mail message should be in the format of a CDDB file
entry as described in Appendix B.  The messages should contain only
plain ASCII text.  Do not attach encoded information or add special
escape sequences.

The master CDDB accepts only submissions in the ISO-8859 or US-ASCII
character sets.  If the user submits any entries containing 8-bit
characters (for accents such as umlaut, or other extended characters),
the application should use the MIME "quoted-printable" scheme to encode
the message such that the 8th bit will not be stripped off during e-mail
transit.

Note that the disc ID specified in the mail Subject line should
also appear in the list of disc IDs in the DISCID= field of the
CDDB file entry.  If not, it is considered an error and the submission
will be rejected.

You should only allow categories that are officially supported by the
master CDDB archives.  Submissions specifying unsupported categories
will be rejected.  The current list of "official" categories are listed
on the CDDB web site, or can be obtained programmatically cddb.cddb.com
via the "cddb lscat" command.

Please do not allow a user to submit CD database entries that have
completely unfilled contents (i.e., blank information in the disc
artist/title as well as the track titles).  While the current CD database
server checks and rejects submissions that have a blank DTITLE line, it
doesn't (and can't feasibly) check the track titles effectively, nor can
it check any of these fields if they are filled with a default string.
If you must use a default string, please use "track 1", "track 2",
etc, since the server specifically checks for this string.  Otherwise,
it would have to be hacked to know about the default strings of every
possible client.

Thus, please design your client with this in mind.  This is a somewhat
tricky thing to do, as some CDs contain blank tracks with no titles
and you need to allow for that.  An example minimum requirement
that a CD player client should meet is listed below:

1. Don't allow the "send" or "submit" feature to be activated if
   the CD database information form is not edited at all.
2. Check that the disc artist/title contains something (that the user
   typed in).
3. At least one of the tracks has a title filled in by the user.
4. Don't submit a default string if a field is not filled in
   (e.g. If track 3 is not filled in, submit a blank "TTITLE3=" line.)
   If you must use a default string, please use "track N" where N
   is the track number.

This should minimize the amount of useless garbage being submitted
into the CD database.

Before you release your software, please be sure that it produces
submissions that adhere to the CDDB file format, and that the frame
offset, disc length, and disc ID information are correctly computed.
For testing, please make your software send submissions to one of the
following two e-mail addresses (rather than the real submission site at
cddb-submit@submit.cddb.com):

	cddb-test@submit.cddb.com

	or

	cddb-test@cddb.cddb.com

The test addresses perform sanity checking on the CDDB submission and
send back pass/fail confirmation, but do not actually deposit the entry
in the CD database.

When you feel your application is ready to support submissions, please contact
us at cddb-support@moonsoft.com. We will provide you with our qualification
procedure, which involves submitting a number of entries of different types.
Once qualified, your application will be permitted to submit to the database.


QUESTIONS?
----------

Please direct your questions about the xmcd to xmcd@amb.org.  Questions
specific to the CDDB or the CDDB server should be directed to
cddb-support@moonsoft.com.

APPENDIX A - CDDB DISCID ALGORITHM
----------------------------------

The following is C code that illustrates how to generate the
CDDB disc ID:


struct toc {
	int	min;
	int	sec;
	int	frame;
};

struct toc cdtoc[100];

int
read_cdtoc_from_drive(void)
{
	/* Do whatever is appropriate to read the TOC of the CD
	 * into the cdtoc[] structure array.
	 */
	return (tot_trks);
}

int
cddb_sum(int n)
{
	int	ret;

	/* For backward compatibility this algorithm must not change */

	ret = 0;

	while (n > 0) {
		ret = ret + (n % 10);
		n = n / 10;
	}

	return (ret);
}

unsigned long
cddb_discid(int tot_trks)
{
	int	i,
		t = 0,
		n = 0;

	/* For backward compatibility this algorithm must not change */

	i = 0;

	while (i < tot_trks) {
		n = n + cddb_sum((cdtoc[i].min * 60) + cdtoc[i].sec);
		i++;
	}

	t = ((cdtoc[tot_trks].min * 60) + cdtoc[tot_trks].sec) -
	    ((cdtoc[0].min * 60) + cdtoc[0].sec);

	return ((n % 0xff) << 24 | t << 8 | tot_trks);
}

main()
{
	int tot_trks;

	tot_trks = read_cdtoc_from_drive();
	printf("The discid is %08x", cddb_discid(tot_trks));
}


This code assumes that your compiler and architecture support 32-bit
integers.

The cddb_discid function computes the discid based on the CD's TOC data
in MSF form.  The frames are ignored for this purpose.  The function is
passed a parameter of tot_trks (which is the total number of tracks on
the CD), and returns the discid integer number.

It is assumed that cdtoc[] is an array of data structures (records)
containing the fields min, sec and frame, which are the minute, second
and frame offsets (the starting location) of each track.  This
information is read from the TOC of the CD.  There are actually
tot_trks + 1 "active" elements in the array, the last one being the
offset of the lead-out (also known as track 0xAA).

The function loops through each track in the TOC, and for each track
it takes the (M * 60) + S (total offset in seconds) of the track and
feeds it to cddb_sum() function, which simply adds the value of each digit
in the decimal string representation of the number. A running sum of this
result for each track is kept in the variable n.

At the end of the loop:
1. t is calculated by subtracting the (M * 60) + S offset of the lead-out
minus the (M * 60) + S offset of first track (yielding the length of
the disc in seconds).

2. The result of (n modulo FFh) is left-shifted by 24 bits.

3. t is left shifted by 8.

The bitwise-OR operation of result 2., 3. and the tot_trks number is
used as the discid.

The discid is represented in hexadecimal form for the purpose of
xmcd cddb file names and the DISCID= field in the xmcd cddb file itself.
If the hexadecimal string is less than 8 characters long, it is
zero-padded to 8 characters (i.e., 3a8f07 becomes 003a8f07).  All
alpha characters in the string should be in lower case, where
applicable.

Important note for clients using the MS-Windows MCI interface:

The Windows MCI interface does not provide the MSF location of the
lead-out.  Thus, you must compute the lead-out location by taking the
starting position of the last track and add the length of the last
track to it.  However, the MCI interface returns the length of the last
track as ONE FRAME SHORT of the actual length found in the CD's TOC.
In most cases this does not affect the disc ID generated, because we
truncate the frame count when computing the disc ID anyway.  However,
if the lead-out track has an actual a frame count of 0, the computed
quantity (based on the MSF data returned from the MCI interface) would
result in the seconds being one short and the frame count be 74.  For
example, a CD with the last track at an offset of 48m 32s 12f and having
a track length of 2m 50s 63f has a lead-out offset of 51m 23s 0f long. Windows
MCI incorrectly reports the length as 2m 50s 62f, which would yield
a lead-out offset of 51m 22s 74f, which causes the resulting truncated disc
length to be off by one second.  This will cause an incorrect disc ID to be
generated. You should thus add one frame to the length of the last track when
computing the location of the lead-out.

The easiest way for Windows clients to compute the lead-out given information
in MSF format is like this:

(offset_minutes * 60 * 75) + (offset_seconds * 75) + offset_frames +
(length_minutes * 60 * 75) + (length_seconds * 75) + length_frames + 1 = X

Where X is the offset of the lead-out in frames. To find the lead-out in
seconds, simply divide by 75 and discard the remainder.


APPENDIX B - CDDB FILE FORMAT
-----------------------------

			       CDDB File Format
			         Version 1.0

			       By Steve Scherf

	      Based on the xmcd database file design by Ti Kan
	      ------------------------------------------------

Revision: $Id: cddb.howto,v 1.1 1999/05/07 05:35:56 bungi Exp $


Database entries must be in the ISO-8859-1 character set (the 8-bit ASCII
extension also known as "Latin alphabet #1"). Lines must always be
terminated only by a single newline (ctrl-J, or 0Ah). All lines in a
database entry must be less than or equal to 80 bytes in length, including
the newline. Database entries with lines that are longer will be considered
invalid. There must be no blank lines in a database entry.

Lines that begin with # are comments. Comments should appear only at the
top of the file before any keywords. Comments in the body of the file are
subject to removal when submitted for inclusion to the database. Comments
may consist only of characters in the set:

{ tab (09h); space (20h) through tilde (7Eh) inclusive }

Comments should be ignored by applications using the database file, with
several exceptions described below.

The beginning of the first line in a database entry should consist of the
string "# xmcd". This string identifies the file as an xmcd format CD
database file. More text can appear after the "xmcd", but is unnecessary.

The comments should also contain the string "# Track frame offsets:" followed
by the list of track offsets (the # of frames from the beginning of the CD)
obtained from the table of contents on the CD itself, with any amount of white
space between the "#" and the offset. There should be no other comments
interspersed between the list of track offsets. This list must follow the
initial identifier string described above. Following the offset list should
be at least one blank comment.

After the offset list, the following string should appear:

"# Disc length: N seconds"

where the number of seconds in the CD's play length is substituted for "N".
The number of seconds should be computed by dividing the total number of
1/75th second frames in the CD by 75 and truncating any remainder. This number
should not be rounded. 

Note for Windows programmers:

The disc length provided by the Windows MCI interface should not be used here.
Instead, the lead-out (address of the N+1th track) should be used. Since the
MCI interface does not provide the address of the lead-out, it should be
computed by adding the length of the last track to the offset of the last
track and truncating (not rounding) any remaining fraction of a second. Note
that the MCI interface yields an incorrect track offset which must be
corrected by adding one frame to the total frame count when performing the
disc length computation.

After the disc length, the following string should appear:

"# Revision: N"

where the database entry revision (decimal integer) is substituted for "N".

Files missing a revision are assumed to have a revision revision level of 0.
The revision is used for database management when comparing two entries in
order to determine which is the most recent. Client programs which allow the
user to modify a database entry should increment the revision when the user
submits a modified entry for inclusion in the database.

After the revision, the following string should appear:

"# Submitted via: client_name client_version optional_comments"

where the name of the client submitting the entry is substituted for
"client_name", the version of the client is substituted for "client_version",
and "optional_comments" is any sequence of legal characters. Clients which
allow users to modify database entries read from the database should update
this string with their own information before submitting.

The "client_version" field has a very specific format which should be observed:

[leading text]version_number[release type][level]

Where:

	Leading text: is any string which does not include numbers.
	Version number and level: is any (possibly) decimal-separated list of
	    numbers.
	Release type: is a string of the form:
	    alpha, a, beta, b, patchlevel, patch, pl

For example:

	release:2.35.1alpha7
	v4.0PL0
	2.4

The only required portion of the version field is the version number. The
other parts are optional, though it is strongly recommended that the release
type field be filled in if relevant. Strict version checking may be
applied by software which evaluates the submitter revision, so it is wise
to make it clear when a release is beta, etc.

Following the comments is the disc data. Each line of disc data consists
of the format "KEYWORD=data", where "KEYWORD" is a valid keyword as described
below and "data" is any string consisting of characters in the set:

{ space (20h) through tilde (7Eh) inclusive; no-break-space (A0h) through
  y-umlaut (FFh) inclusive }

Newlines (20h), tabs (09h) and backslashes (2Fh) may be represented by the
two-character sequences "\n", "\t" and "\\" respectively. Client programs must
translate these sequences to the appropriate characters when displaying
disc data.

All of the applicable keywords must be present in the file, though they may
have empty data except for the DISCID and DTITLE keywords. They must appear in
the file in the order shown below. Multiple occurrences of the same keyword
indicate that the data contained on those lines should be concatenated.
Keywords with numeric data should not have a comma after the last number on
each line. Valid keywords are as follows:

DISCID: The data following this keyword should be a comma-separated list of
        8-byte disc IDs. The disc ID indicated by the track offsets in the
	comment section must appear somewhere in the list. Other disc IDs
	represent links to this database entry. The algorithm for generating
	the disc ID is beyond the scope of this document.

DTITLE: Technically, this may consist of any data, but by convention contains
	the artist and disc title (in that order) separated by a "/". If the
	"/" is absent, it is implied that the artist and disc title are the
	same.

TTITLEN:There must be one of these for each track in the CD. The track
	number should be substituted for the "N", starting with 0. This field
	should contain the title of the Nth track on the CD.

EXTD:	This field contains the "extended data" for the CD. This is intended
	to be used as a place for interesting information related to the CD,
	such as credits, et cetera. If there is more than one of these lines
	in the file, the data is concatenated. This allows for extended data
	of arbitrary length.

EXTTN:	This field contains the "extended track data" for track "N". There
	must be one of these for each track in the CD. The track number
	should be substituted for the "N", starting with 0. This field is
	intended to be used as a place for interesting information related to
	the Nth track, such as the author and other credits, or lyrics. If
	there is more than one of these lines in the file, the data is
	concatenated. This allows for extended data of arbitrary length.

PLAYORDER:
	This field contains a comma-separated list of track numbers which
	represent a programmed track play order. This field is generally
	stripped of data in non-local database entries. Applications that
	submit entries for addition to the main database should strip this
	keyword of data.


A minimal database entry is as follows. A "[ ... ]" indicates repetition.

# xmcd
#
# Track frame offsets:
#	150
[ ... 21 frame offsets omitted ]
#	210627
#
# Disc length: 2952 seconds
#
# Revision: 1
# Submitted via: xmcd 2.0
#
DISCID=270b8617,5f430c17,[ ... ],4c72be17
[ ... ]
DISCID=88fe2017,ff293017,[ ... ],5920cc17
DTITLE=Con Spirito / Franske stemninger
TTITLE0=Mille regretz de vous abandonner
[ ... 21 TTITLEN keywords omitted ]
TTITLE22=L'arche de no
EXTD=Copyright (c) 1981 MCA Records Inc.\nManufactured
EXTD=for MCA Records Inc.
EXTT0=Des Prez\nYez
[ ... 21 EXTTN keywords omitted ]
EXTT22=Schmitt: A contre-voix \n(excerpt)
PLAYORDER=1,5,6,19,7,[ ... ],19
PLAYORDER=8,20,[ ... ],21


APPENDIX C - CDDB SERVER PROTOCOL
---------------------------------


				CDDB Protocol

			  By Steve Scherf and Ti Kan
		          --------------------------

Revision: $Id: cddb.howto,v 1.1 1999/05/07 05:35:56 bungi Exp $


Notation:
-> : client to server
<- : server to client

terminating marker: `.' character in the beginning of a line


Server response code (three digit code):

First digit:
1xx	Informative message
2xx	Command OK
3xx	Command OK so far, continue
4xx	Command OK, but cannot be performed for some specified reasons
5xx	Command unimplemented, incorrect, or program error
 
Second digit:
x0x	Ready for further commands
x1x	More server-to-client output follows (until terminating marker)
x2x	More client-to-server input follows (until terminating marker)
x3x	Connection will close

Third digit:
xx[0-9]	Command-specific code


CDDB Protocol Level 1:
----------------------

Server sign-on banner:
----------------------
<- code hostname CDDBP server version ready at date

    code:
	200	OK, read/write allowed
	201	OK, read only
	432	No connections allowed: permission denied
	433	No connections allowed: X users allowed, Y currently active
	434	No connections allowed: system load too high
    hostname:
	Server host name.  Example: xyz.fubar.com
    version:
	Version number of server software.  Example: v1.0PL0
    date:
	Current date and time.  Example: Wed Mar 13 00:41:34 1996


Initial client-server handshake:
--------------------------------
Note: This handshake must occur before other cddb commands
      are accepted by the server.

Client command:
-> cddb hello username hostname clientname version

    username:
	Login name of user.  Example: johndoe
    hostname:
	Host name of client.  Example: abc.fubar.com
    clientname:
	The name of the connecting client.  Example: xmcd, cda, EasyCD,
	et cetera. Do not use the name of another client which already
	exists.
    version:
	Version number of client software.  Example: v1.0PL0

Server response:
<- code hello and welcome username@hostname running clientname version

    code:
	200	Handshake successful
	431	Handshake not successful, closing connection
	402	Already shook hands


CDDB lscat:
----------
Client command:
-> cddb lscat

Server response:
<- code Okay category list follows
<- category
<- category
<- (more categories...)
<- .

    code:
	210	Okay category list follows (until terminating marker)
    category:
	CD category.  Example: rock


CDDB query:
-----------
Client command:
-> cddb query discid ntrks off1 off2 ... nsecs

    discid:
	CD disc ID number.  Example: f50a3b13
    ntrks:
	Total number of tracks on CD.
    off1, off2, ...:
	Frame offset of the starting location of each track.
    nsecs:
	Total playing length of CD in seconds.

Server response:
<- code categ discid dtitle
	or
<- code close matches found
<- categ discid dtitle
<- categ discid dtitle
<- (more matches...)
<- .

    code:
	200	Found exact match
	211	Found inexact matches, list follows (until terminating marker)
	202	No match found
	403	Database entry is corrupt
	409	No handshake
    categ:
	CD category.  Example: rock
    discid:
	CD disc ID number of the found entry.  Example: f50a3b13
    dtitle:
	The Disc Artist and Disc Title (The DTITLE line).  For example:
	Pink Floyd / The Dark Side of the Moon


CDDB read:
----------
Client command:
-> cddb read categ discid

    categ:
	CD category.  Example: rock
    discid:
	CD disc ID number.  Example: f50a3b13

Server response:
<- code categ discid
<- # xmcd 2.0 CD database file
<- # ...
<- (CDDB data...)
<- .
	or
<- code categ discid No such CD entry in database

    code:
	210	OK, CDDB database entry follows (until terminating marker)
	401	Specified CDDB entry not found.
	402	Server error.
	403	Database entry is corrupt.
	409	No handshake.
    categ:
	CD category.  Example: rock
    discid:
	CD disc ID number.  Example: f50a3b13


CDDB write:
-----------
Client command:
-> cddb write categ discid

    categ:
	CD category.  Example: rock
    discid:
	CD disc ID number.  Example: f50a3b13

Server response:
<- code categ discid

    code:
	320	OK, input CDDB data (until terminating marker)
	401	Permission denied.
	402	Server file system full/file access failed.
	409	No handshake.
	501	Entry rejected: reason for rejection.
    categ:
	CD category.  Example: rock
    discid:
	CD disc ID number.  Example: f50a3b13

Client data:
-> # xmcd 2.0 CD database file
-> # ...
-> (CDDB data)
-> .

Server response:
<- code message

    code:
	200	CDDB entry accepted
	401	CDDB entry rejected: reason why
    message:
	Message string to indicate write status:
	CDDB entry accepted, or CDDB entry rejected.


Help information:
-----------------
Client command:
-> help
	or
-> help cmd

    cmd:
	CDDB command.  Example: quit

	or

-> help cmd subcmd

    cmd:
	CDDB command.  Example: cddb
    subcmd:
	CDDB command argument.  Example: query

Server response:
<- code Help information follows
<- (help data ...)
<- .
	or
<- code no help information available

    code:
	210	OK, help information follows (until terminating marker)
	401	No help information available


Log statistics:
---------------
Client command:
-> log [[-l lines] [start date [end date]] | [day ["days"]] | ["get"]]

    lines:
	The maximum number of lines to print for each data list in the
	log statistics.
    start date:
	The date after which statistics should be calculated. Date is
	of the format: hh[mm[ss[MM[DD[[CC]YY]]]]]

	E.g.:	201200053196 for 8:12 PM on May 31, 1996.
		20120005312096 for 8:12 PM on May 31, 2096.
		080530 for today at at 8:15 and 30 seconds.

	If the century ("CC") is omitted, a reasonable guess is made. If
	this argument is omitted, all messages are considered.
    end date:
	The date after which statistics should not be calculated. If
	omitted, the end date is assumed to be the current date.
    day:
	The string "day". This solitary argument will cause a log search
	of messages generated within the last day.
    days:
	A positive numerical argument which modifies the number of days'
        messages to searh. If this argument is left out, the default is 1.
    get:
	The string "get". This solitary argument will cause the server
	to send the contents of the log file.

Server response:
<- code Log summary follows
<- (log stats)
<- .
	or
<- code Log follows
<- (log stats)
<- .

    code:
	210	OK, log summary follows (until terminating marker)
	211	OK, log follows (until terminating marker)
	401	Permission denied
	402	No log information available
	501	Invalid start/end date


Message of the day:
------------------
Client command:
-> motd

Server response:
<- code Last modified: date MOTD follows (until terminating marker)
<- (message text)
<- .

    code:
	210	Last modified: 05/31/96 06:31:14 MOTD follows (until terminating marker)
	401	No message of the day available
    date:
	The date the text of the message of the day was modified. The date
	appears in the following format:

		05/31/96 06:31:14

	This value may be used by client software as a message timestamp
	for purposes of determining if it has already been displayed. This
	format was chosen because it is more easily parsed than the standard
	ctime() format.


Server protocol level:
----------------------
Client command:
-> proto [level]

    level:
	The (numerical) protocol level to set the server to.

Server response:
<- code CDDB protocol level: current cur_level, supported supported_level
	or
<- code OK, protocol version now: cur_level

    code:
	200	CDDB protocol level: current cur_level, supported supp_level
	201	OK, protocol version now: cur_level
	501	Illegal protocol level.
	502	Protocol level already cur_level.
    cur_level:
	The current protocol level at which the server is running.
    supported_level:
	The maximum supported protocol level.


Server sites:
--------------
Client command:
-> sites

Server response:
<- code OK, site information follows (until terminating `.')
<- (data)
<- .

    code:
	210	Ok, site information follows
	401	No site information available.

    The data format is as follows:
	site port latitude longitude description

    The fields are as follows:
	site:
	    The Internet address of the remote site.
	port:
	    The port at which the server resides on that site.
	latitude:
	    The latitude of the server site. The format is as follows:
		CDDD.MM
	    Where "C" is the compass direction (N, S), "DDD" is the
	    degrees, and "MM" is the minutes.
	longitude:
	    The longitude of the server site. Format is as above, except
	    the compass direction must be one of (E, W).
	description:
	    A short description of the geographical location of the site.

    Example:
	cddb.moonsoft.com 888 N037.23 W122.01 Fremont, CA USA


Server status:
--------------
Client command:
-> stat

Server response:
<- code OK, status information follows (until terminating `.')
<- (data)
<- .

    code:
	210	Ok, status information follows

    The possible data is as follows:
	current proto: <current_level>
	    An integer representing the server's current operating protocol
	    level.
	max proto:     <max_level>
	    The maximum supported protocol level.
	gets:          <yes | no>
	    Whether or not the client is allowed to get log information,
	    according to the string "yes" or "no".
	updates:       <yes | no>
	    Whether or not the client is allowed to initiate a database
	    update, according to the string "yes" or "no".
	posting:       <yes | no>
	    Whether or not the client is allowed to post new entries,
	    according to the string "yes" or "no".
	quotes:        <yes | no>
	    Whether or not quoted arguments are enabled, according to
	    the string "yes" or "no".
	current users: <num_users>
	    The number of users currently connected to the server.
	max users:     <num_max_users>
	    The number of users that can concurrently connect to the server.
	strip ext:	<yes | no>
	    Whether or not extended data is stripped by the server before
	    presented to the user.
	Database entries: <num_db_entries>
	    The total number of entries in the database.
	Database entries by category:
	    This field is followed by a list of catgories and the number
	    of entries in that category. Each entry is of the following
	    format:

		<white space>catgory: <num_db_entries>

	    The list of entries is terminated by the first line that does
	    not begin with white space.

	Pending file transmissions:
	    This field is followed by a list of sites that are fed new
	    database entries at periodic intervals, and the number of
	    entries that have yet to be transmitted to that site.
	    Each entry is of the following format:

		<white space>site: <num_db_entries>

	    The list of entries is terminated by the first line that does
	    not begin with white space.

	This list may grow as needed, so clients must expect possible
	unrecognizable data. Also, additional fields may be added to
	the currently existing lines, although no existing fields will
	be removed or change position.
	

Server version:
---------------
Client command:
-> ver

Server response:
<- code servername version copyright
	or
<- code Version information follows

    code:
	200	Version information.
	211	OK, version information follows (until terminating marker)
    version:
	Server version.  Example: v1.0PL0
    copyright:
	Copyright string.  Example: Copyright (c) 1996 Steve Scherf


Database update:
----------------
Client command:
-> update

Server response:
<- code Updating the database.
	or
<- code Permission denied.
	or
<- code Unable to update the database.

    code:
	200 Updating the database.
	401 Permission denied.
	402 Unable to update the database.


Server users:
-------------
Client command:
-> whom

Server response:
<- code User list follows

    code:
	210	OK, user list follows (until terminating marker)
	401	No user information available.


Client sign-off:
----------------
Client command:
-> quit

Server response:
<- code hostname closing connection.  Goodbye.

    code:
	230	OK, goodbye.
    hostname:
	Server host name.  Example: xyz.fubar.com


General errors:
---------------

Server response:
<- code error
    code:
	402	Server error.
	408	CGI environment error.
	500	Command syntax error, command unknown, command unimplemented.
	530	Server error, server timeout.


Reserved errors:
----------------

The following error codes are reserved, and will never be returned as a
response to a CDDB protocol command. They are intended to be used internally
by clients that have a need for generating pseudo-responses.

	600-699


CDDB Protocol Level 2:
----------------------

In all respects, protocol level 2 is the same as level 1, with the exceptions
listed below.

Arguments to commands may be surrounded by double quotes. All characters
within the quotes, including white space, are included in the argument. All
white space is replaced by the `_' (2Dh) character by the server. White space
is defined as ` ' (20h) and `^I' (control-I, or 09h).

Arguments containing quotes that should not be interpreted with the special
meaning described above should be escaped with a preceding backslash character,
or '\' (5Ch). If an actual backslash appears in an argument, it should be
escaped with a preceding backslash. In both cases, the preceding backslash
will be removed from the input before being interpreted.


CDDB Protocol Level 3:
----------------------

Protocol level 3 is the same as level 2, with the exception listed below.

The output of the "sites" command has changed to meet the folowing description:

    The data format is as follows:
	site protocol port address latitude longitude description

    The fields are as follows:
	site:
	    The Internet address of the remote site.
	protocol:
	    The transfer protocol used to access the site.
	port:
	    The port at which the server resides on that site.
	address:
	    Any additional addressing information needed to access the
	    server. For example, for HTTP protocol servers, this would be
	    the path to the CDDB server CGI script. This field will be
	    "-" if no additional addressing information is needed.
	latitude:
	    The latitude of the server site. The format is as follows:
		CDDD.MM
	    Where "C" is the compass direction (N, S), "DDD" is the
	    degrees, and "MM" is the minutes.
	longitude:
	    The longitude of the server site. Format is as above, except
	    the compass direction must be one of (E, W).
	description:
	    A short description of the geographical location of the site.

    Example:
	cddb.moonsoft.com cddbp 888 - N037.23 W122.01 Fremont, CA USA
	cddb.moonsoft.com http 80 /~cddb/cddb.cgi N037.23 W122.01 Fremont,CA USA

Note that a site may appear once for each type of protocol it supports for
accessing the server.


CDDB Protocol Level 4:
----------------------

Protocol level 4 is the same as level 3, with the exception listed below.

The output of the "cddb query" command may result in multiple exact matches.
A new response code, 210, has been added to indicate that more than one
exact match has been found.

Server response:
----------------
<- code exact matches found
<- categ discid dtitle
<- categ discid dtitle
<- (more matches...)
<- .

    code:
        211 Found exact matches, list follows (until terminating marker)


Addendum A: Proper use of CDDBP:
--------------------------------

There are a few guidelines that must be followed in order to make proper use
of CDDBP:

- When handshaking with the server via the "cddb hello" command, the client
  must specify its own name and version, not that of some other client (such
  as xmcd). Also, the "username" and "hostname" must be that of the actual
  user running the program, not some hardwired value.

- Before performing a "cddb read", the client program MUST perform a
  "cddb query". Failure to do so may result in the client program receiving
  incorrect CDDB data from the server. Also, without performing a query, the
  client program will not benefit from close matches in the event of the
  lack of an exact match in the database.

- For accounting purposes, it is best if client programs only perform a single
  "cddb query" for a particular disc before performing a "cddb read" for that
  disc.


Addendum B: CDDBP under HTTP:
-----------------------------

Accessing a server as a CGI script is done in much the same way as through
direct interaction. The command set is identical, though the method of
communication is through CDDBP commands encapsulated in the HTTP protocol.
The only limitation is that a single command may be executed per connection,
since HTTP is not truly interactive. For the server to be accessed in this
way, it must reside on the target host at a known URL which is accessible by
the host HTTP server. The client program must connect to the HTTP server on
the target host and issue an HTTP command with the appropriate CDDBP command
encapsulated within.

Commands may be submitted to servers in CGI mode using either the "GET" or
"POST" HTTP commands. Both methods are supported, and there is no real
difference between how both are to be used other than the syntactical
difference between the two methods. The "POST" method may provide the ability
to issue longer commands, though, depending on the architecture of the system
on which the server resides.

The server command must be sent as part of the "Request-URI" in the case
of the "GET" method, and as the "Entity-Body" in the case of the "POST"
method. In both cases, the command must be of the following form:

cmd=server+command&hello=joe+my.host.com+clientname+version&proto=1

Where the text following the "cmd=" represents the CDDBP command to be
executed, the text following the "hello=" represents the arguments to
the "cddb hello" command that is implied by this operation, and the
text following the "proto=" represents the argument to the "proto" command
that is implied by this operation.

The "+" characters in the input represent spaces, and will be translated
by the server before performing the request. Special characters may be
represented by the sequence "%XX" where "XX" is a two-digit hex number
corresponding to the ASCII (ISO-8859-1) sequence of that character. The
"&" characters denote separations between the command, hello and proto
arguments. Newlines and carriage returns must not appear anywhere in the
string except at the end.

All CDDBP commands are supported under HTTP, except for "cddb hello",
"cddb write", "proto" and "quit".

For example, should user "joe" on system "my.host.com" be running xmcd 2.1,
a read request for his currenly playing CD might look like this:

cmd=cddb+read+rock+12345678&hello=joe+my.host.com+xmcd+2.1&proto=1

The server will perform the implied "proto" and "cddb hello" commands,
and then perform the requested "cddb read" command.

Server response to the command is encapsulated in the HTTP server response,
and appears in the "Entity-Body" exactly as it would appear using the CDDBP
protocol. Note that the HTTP response "Entity-Header" is not guaranteed to
contain a "Content-Length" field, so clients should be prepared to accept
variable length input. This is no different from operation under CDDBP. The
header will always contain a Mime "Content-Type" field which describes the
body of data as "text/plain".

For more detailed information on HTTP and Mime, see RFC 1945 and RFC 1521.


Addendum C: CDDBP under SMTP:
-----------------------------

The use of email mode (SMTP) commands is simple. A special subject line
lets the server know that the email contains a command, and somewhere in the
body there should be a HTTP-style server command; actually, the server will
execute up to 5 such commands in a single email.

The subject for email commands should look like this:

Subject: cddb #command arbitrary_string

The "arbitrary_string" should be some randomly-chosen string. The server
will include this string in the subject of the response. The rest of the
subject should appear literally as it does here.

Somewhere in the body of the email should be at least one server command. For
example:

cmd=motd&hello=steve+moonsoft.com+xmcd_via_email+v1.0&proto=3

As you might have noticed, this command is exactly the same as a HTTP-mode
CDDBP command. Command responses will be mailed to the sender, concatenated
together if there is more than one command in the original email. Upon
successful completion of an email command request (even if the command(s)
itself was not successful), the reply will contain a subject which looks
like this:

Subject cddb #response ok arbitrary_string

Should the server be unable to process the email command for some reason, the
subject will look like this:

Subject cddb #response failed arbitrary_string

In both cases, the "arbitrary_string" is the same as the one specified in the
initial command email.


APPENDIX D - OFFICIAL CDDB SOFTWARE DISTRIBUTION SITES
------------------------------------------------------

All CDDB-related software and archive distribution is via the
CDDB server web page (under "Downloads"):

	http://www.cddb.com/
