|
<< Click to Display Table of Contents >> freedb.howto.txt |
  
|
|
<< Click to Display Table of Contents >> freedb.howto.txt |
|
[Freedb no longer exists, so the URLs and email addresses in this document cannot be used.]
USE OF FREEDB SERVICE IN YOUR SOFTWARE
------------------------------------
freedb.howto 1.07 2004/01/08
by freedb team
including parts from the cddb.howto's by Ti Kan and Steve Scherf
In this document:
- WHAT IS THE FREEDB
- FREEDB USE RESTRICTIONS
- TWO FORMS OF ACCESS TO THE FREEDB
- CDDB/FREEDB DISCID
- LOCALE FREEDB ACCESS
- REMOTE FREEDB ACCESS
- FREEDB SUBMISSION
- QUESTIONS?
- APPENDIX A - CDDB/FREEDB DISCID ALGORITHM
- APPENDIX B - FREEDB FILE FORMAT
- APPENDIX C - CDDB SERVER PROTOCOL
- APPENDIX D - OFFICIAL FREEDB SOFTWARE DISTRIBUTION SITES
WHAT IS THE FREEDB
------------------
freedb (free cd database) is an information database containing artist,
disc title, track titles, and other information for digital audio
compact discs. It is based on the CDDB server software, which 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, a "Send" feature in xmcd allows its users to submit CD
information entries to the central archive via e-mail. Over time, this archive
had grown to contain a substantial collection of CD information, when the
original CDDB became commercial and decided to stop offering database archives
and the server software for download in late 1997.
To fill the gap left by CDDB, freedb was started, using the last free database
archive and the GPL'ed CDDB server software. freedb has started and is
continuing to grow at a rapid rate.
The freedb database archives are made available via FTP and HTTP on the
Internet, so that users can download this archive and use it with programs
that support directly reading from it or with the server software (which
is also available for download). We periodically update the database
archives, incorporating new user submissions.
When the CDDB archives started to grow rapidly, xmcd began supporting the
concept of CDDB servers, so that users no longer needed to download the entire
database to make full use of it.
Rather, a number of CDDB server hosts were set up on the Internet around the
world, and xmcd running on a system which was connected to the Internet could
connect to one of the CDDB servers and query the CD database information.
Since the CDDB and servers were designed to be open and usable by other CD
player applications or other software requiring CD information, more and more
programs started supporting CDDB servers and today there is a huge list of
programs, which are CDDB/freedb-aware.
A list of applications, which are freedb-aware is available at:
http://www.freedb.org/
FREEDB USE RESTRICTIONS
-----------------------
The public freedb-servers may be used for free.
The freedb server software and the database archives are being released
as free software under the GNU General Public License, and we would like to
foster the concept of free software. Moreover, the public freedb servers all
run on sites that have graciously volunteered their disk space, computing and
network resources, not to mention occasional maintenance, all for free.
As freedb is a free project, which shall stay free forever, all submitted data
is GPL'ed (and made available for ftp-download).
The freedb server software is released to the public as source code.
Please be aware that the source code of this package is released under
the terms of the GNU General Public License. The full text of the GNU GPL is
in the COPYING file in the package.
TWO FORMS OF ACCESS TO THE FREEDB
---------------------------------
If you are interested in incorporating the use of freedb 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 freedb.
You may store the CD information in the freedb-native format (See
Appendix B), or another format of your choice (for example, the Win95
cdplayer.ini format).
2. Remote access
In this mode the software must connect to a freedb server on the network to
access the freedb. There is a CDDB/freedb 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 freedb 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 sensible to
force the users to download the whole database archive.
CDDB/FREEDB DISCID
------------------
Both forms of freedb access require that the software computes a "disc ID"
which is an identifier that is used to access the freedb. The disc ID is an
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 computes the disc ID correctly. If it does not
generate the disc ID correctly, it will not be compatible with the freedb.
Moreover, if your software submits freedb entries with bad disc IDs to the
freedb archives, it could compromise the integrity of the freedb.
We suggest installing one of the disc ID generator programs listed on the
freedb web page in the download/misc section, and then testing the disc
ID code in your software by comparing the disc ID generated by the program
with that of your software for as large a number of CDs as possible.
Alternatively you can e.g. use xmcd and compare the disc ID generated by xmcd
with that of your software. Bugs in disc ID calculation can be subtle, and
history shows that it sometimes takes hundreds of discs to find problems.
Additionally, to help you with testing disc ID calculation, an image for a
test CD is available on the freedb website. The test CD has been carefully
designed to exposes a large number of common bugs in disc ID generation. Just
download the image and burn it to a CD (instructions are included in the
archive).
LOCAL FREEDB ACCESS
-------------------
There are two forms of the freedb archive available, the standard form and the
alternate form. Both forms are available for download from the freedb ftp
server and several mirrors (see Appendix D). Both forms of the freedb archives
are released to the public as a tar-format archive, compressed with bzip2.
Standard Form:
--------------
Each CD entry is a separate file in this form of the archive. These files are
organized in several directories, each directory is a category of music.
Currently the "official" categories are listed as follows:
blues (self explanatory)
classical (self explanatory)
country (self explanatory)
data (ISO9660 and other data CDs)
folk (self explanatory)
jazz (self explanatory)
newage (self explanatory)
reggae (self explanatory)
rock (incl. funk, soul, rap, pop, industrial, metal, etc.)
soundtrack (movies, shows)
misc (others that do not fit the above categories)
The individual database files have a file name that is the 8-digit disc ID.
For example, under the blues directory there may be the following files:
0511c012
060e7314
0c01e902
0f0c3112
...
fa0f6f10
fb0f8814
fd0e6013
To access the freedb entry associated with a CD, your software simply opens
the appropriate file and reads the information.
The content of each of these files is in a format described below in
Appendix B.
Different pressings of a particular CD title may contain differences in
timings that can cause the computed disc ID to be different. The freedb allows
this by having multiple file names be links to the same file. The links are
implemented as actual filesystem links (see the ln command) on UNIX systems.
For example, the following files in the rock directory are all links to the
same file, and refer to the CD "Pink Floyd / The Division Bell".:
850f740b
850f950b
850f970b
860f960b
890f970b
Linked entries with multiple disc IDs should only be used for local databases,
never for submitting entries to freedb!
Xmcd (as well as a lot of other programs) and the CD database server use this
form of the freedb archive. The benefit of the standard form of the freedb
archive is very fast access, and ease of add/delete/edit operations on
entries.
Alternate Form:
---------------
Due to limitations in the FAT file system used by Windows-9x/ME, it is
infeasible to use the standard format freedb archive due to the large number
of files. This is because such a filesystem operates on fixed-size clusters
and even a small file (and most freedb files are 1KB or less) would consume
the space of a full cluster (depending upon disk size, a cluster can range
from 4KB to 32KB in size). Thus, a tremendous amount of disk space would be
wasted on these systems if the freedb archive was used in its standard form.
Additionally there is a limitation on FAT file-systems for how many files can
be kept within one directory, which is exceeded by at least the rock and the
misc directory in the current archive.
An alternate form of the freedb archives (also known as Windows form) was
created for use by software that must operate on a system with the FAT
limitations.
The alternate form still uses the separate category directories like the
standard form, but concatenates many files into a smaller number of files
under each category. The first two digits of the database file names is used
as a key for concatenation, each file is allowed to grow to approximately 64KB
in size before a new file is started (although some of the files in the
rock-directory even have a size of more than 1MB). The file name indicates
what range of digits is included in that file. For example, in the blues
category we may have the following files:
01to36
37to55
56to71
...
b2tod7
d8toff
The 01to36 file contains all freedb entries with disc ID 01xxxxxx,
02xxxxxx, 03xxxxxx and so on, up to 36xxxxxx.
Each entry in the concatenated file begins with the keyword
#FILENAME=xxxxxxxx
where discid is the 8-digit hexadecimal disc ID of that entry. Your
software must search through the appropriate file to locate the desired
entry. The freedb entry is in the format described in Appendix B below.
The alternate form avoids the problem of inefficient disk space utilization on
FAT-based filesystems, but is slower to access than the standard form, and
it is much more cumbersome to perform add/delete/edit operations on entrys.
Additionally the freedb updater application, which is only available for
Windows, is required to make use of the database updates released by freedb.
It is impossible to release database update archives directly in the alternate
format.
REMOTE FREEDB ACCESS
--------------------
In order to perform remote access of freedb servers, your software must be
able to communicate with a remote CD server system via TCP/IP. There are a
number of public freedb servers operating on the Internet. The current list
of public servers is listed on the freedb Web site at:
http://www.freedb.org/
The current list of public servers may also be obtained programmatically
via the CDDBP "sites" command. The permanent server site freedb.freedb.org
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 freedb servers, CDDBP and HTTP.
(Alternatively freedb can be accessed via e-mail-mode, the e-mail-address for
this is freedb-query@freedb.org.)
All current freedb servers answer at IP port 8880 for CDDBP and port 80 for
HTTP access. The standard URL for access via http is
http://freedb_server/~cddb/cddb.cgi
There may be unofficial sites that deviate from these conventions, however.
You should make the freedb 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.
The CDDBP, HTTP and e-mail CDDB server protocols are described below in
Appendix C.
The freedb entry returned from the server via a "cddb read" command is in the
format described in Appendix B below.
You may experiment with the freedb 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 freedb.freedb.org 8880
connects you to the freedb server at freedb.freedb.org.
Some additional notes for accessing freedb over the Internet:
Your application should always specify the highest documented protocol level
when accessing freedb. The highest level currently specified is "6". Lower
protocol levels will work, but are only provided for compatibility with older
applications. If you do not use the highest available protocol level, certain
useful features will not be available to your application.
We consider the use of the "cddb query" command mandatory for all freedb
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) and multiple exact matches (response code 210)
in response to a query.
The proper way to handle fuzzy matches and multiple exact 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 application name and version should be that of your
application, not "xmcd" or the name of another application.
Clients should not have a hard-coded list of remote server sites. These sites
are subject to change, so hard-coded lists of sites can become stale. The
"sites" command was created for clients to acquire a definitive list of valid
server sites worldwide. It is suggested that client applications acquire the
list when the program is first run, and offer an option to do so thereafter.
(It's not necessary or desirable to do this every time the program is run.)
Because sites do come and go without notice sometimes, a permanent server
site, freedb.freedb.org, has been created for clients to download the site
list from. It is intended that clients use freedb.freedb.org to get the site
list, and failing that, to get the list from one of the other last known
public servers as a backup. All of the official freedb server sites will
contain a valid list of servers, though freedb.freedb.org is the only site
which is guaranteed to always exist.
We do strongly suggest that you provide your users with the capability of
choosing freedb server sites as described above. However, for some applications
this may not be feasible. If you do not wish to offer this functionality, you
may safely hard-code "freedb.freedb.org" in your application as the sole freedb
site to access. This will deprive your users of the option to choose a site
near their locale for optimal response, but that is your choice.
FREEDB SUBMISSION
-----------------
Your software may allow users to enter freedb data and then submit it to the
freedb archives.
There are two methods of submission: via e-mail or via http using submit.cgi
It is up to you, if you support one or both of these methods.
1. Submission via e-mail
------------------------
The method of submission is to send the entry to following address via e-mail:
freedb-submit@freedb.org
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 freedb entry. The e-mail subject line
should be in the form "cddb category discid". For example:
Subject: cddb rock 850f970b
You may optionally set an additional "X-Cddbd-Note:" header line, specifying
an arbitrary message to be included at the top of any rejection notice that
may be sent to the submitting user. You could e.g. add a note about your
support-address give the user a chance to contact you, if there are problems
to successfully submit using your program. The length of the arbitrary message
is limited to 70 chars.
The body of the e-mail message should be in the format of a freedb 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 freedb accepts only submissions in the US-ASCII, ISO-8859-1 and
UTF-8 character sets. If your program supports UTF-8 and protocol level 6,
you should always use UTF-8 for submissions and specify UTF-8 as the charset
of the e-mail, even if the submission contains no 8bit-characters and would
therefore also be valid as US-ASCII. Only submissions specifying UTF-8 as the
charset in the e-mail headers are allowed to update existing entries that
contain characters, which can not be represented in US-ASCII or ISO-8859-1.
Note that the disc ID specified in the e-mail subject line should also appear
in the list of disc IDs in the DISCID= field of the freedb file entry. If not,
it is considered an error and the submission will be rejected.
You should only allow categories that are currently supported by the freedb.
Valid categories are: blues, classical, country, data, folk, jazz, misc,
newage, reggae, rock and soundtrack
Submissions specifying unsupported categories will be rejected.
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, or filled with useless default information like "track 1",
"track 2", etc.). 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 it were, 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. Check that the majority of the tracks have a title filled in by the user.
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 freedb 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 the following e-mail address (rather
than the real submission site at freedb-submit@freedb.org):
test-submit@freedb.org
freedb submissions sent to the test e-mail address will be sanity-checked
by the freedb server and pass/fail confirmation will be sent back to the
submitter, but the submission will not actually be deposited in the CD
database. Please do _not_ send submissions in "submit" mode until you have
tested your program with several different CD's.
When you feel your application is ready to support submissions, we would
appreciate, if you would contact us and provide a copy of your program
before releasing it, so we can check if everything is really OK.
2. Submission via http
----------------------
The method of submitting via http is, to transmit the entry to the database
through a CGI program, which is present at the same location as the cddb.cgi.
The standard address for this is:
http://freedb_server/~cddb/submit.cgi
where freedb_server is the address of the selected freedb-server.
You may implement a button or somesuch in your software's user interface to
initiate submissions. Rejected submissions are automatically returned via
e-mail to the sender specified in the "User-Email" header field (see below)
with an explanation of the reason for the rejection.
To submit via the cgi-program, you must use the "POST" method of sending data;
"GET" is not supported. Several HTTP "Entity-Header" fields (described below)
must be included in the data followed by a blank line, followed by the
"Entity-Body" (the freedb entry) in the format described in Appendix B.
The header fields are:
Category: valid_freedb_category
Discid: cd_discid
User-Email: username@domain
Submit-Mode: test_or_submit
Content-Length: freedb_entry_length
Charset: character_set_of_freedb_entry (optional)
X-Cddbd-Note: message_for_user (optional)
Where
- "valid_freedb_category" is a valid freedb category (valid categories are:
blues, classical, country, data, folk, jazz, misc, newage, reggae, rock,
soundtrack). Submissions with an invalid category specified will be rejected.
- "cd_discid" is the 8-digit hex CDDB/freedb disc ID of the entry (see
Appendix A). This has to be exactly the same disc ID that appears in the
"DISCID=" section of the entry being submitted. If not, the entry will be
rejected.
- "username@domain" is the valid e-mail address of the submitting user. This
is required, as the server must be able to notify the submitter, if the
submission was rejected. So you should _never_ fill this with a default
value. Your program should refuse to submit anything, if the user has not
specified an e-mail-address.
- "test_or_submit" is the word "test" or "submit" (without the surrounding
quotes), which specifies if the submission is a test submission or a real
submission to the database (test submissions are described below).
- "freedb_entry_length" is the size in bytes of the freedb entry being
submitted. This number covers only the "Entity-Body" (without the blank line
that separates it from the header).
- "character_set_of_freedb_entry" is US-ASCII, ISO-8859-1 or UTF-8 (can be lower
case). This specifies the character set the submitted entry has been encoded
in. If your application knows the user's character set, then you should
specify it here. If your program supports UTF-8 and protocol level 6,
you should always use UTF-8 for submissions and specify UTF-8 as the charset
of the e-mail, even if the submission contains no 8bit-characters and would
therefore also be valid as US-ASCII. Only submissions specifying UTF-8 as the
charset in the headers are allowed to update existing entries that contain
characters, which can not be represented in US-ASCII or ISO-8859-1.
The default charset value if no charset is specified is ISO-8859-1 for
backwards compatibility.
- "message_for_user" is an arbitrary message to be included at the top of
any rejection notice that may be sent to the submitting user. The length of
the arbitrary message is limited to 70 chars.
To see, how a correct submission should look like, take a look at the following
example:
POST /~cddb/submit.cgi HTTP/1.0
Category: newage
Discid: 4306eb06
User-Email: joe@myhost.home.com
Submit-Mode: submit
Charset: ISO-8859-1
X-Cddbd-Note: Sent by free CD player - Questions: support@freecdplayer.org.
Content-Length: 960
# xmcd
#
# Track frame offsets:
[ data omitted for brevity ]
PLAYORDER=
Note the blank line between the "Content-Length" header field and "# xmcd"
which marks the beginning of the freedb entry. This complies to the standard
http header behaviour where the http header information is separated by a
single newline from the body content. Check http://www.w3.org/Protocols/
for more information on the http in general.
The CGI does a quick check on the submitted data (a more thoroughly check of
the entry is made later by the server, which notifies the user by e-mail if the
submission has been rejected) and responds to a submission
with a 3-digit response code followed by a description.
Currently the following response-codes are used:
200 OK, submission has been sent.
500 Missing required header information.
500 Internal Server Error: [description].
501 Invalid header information [details].
where "details" can be one of the following:
freedb category
disc ID
email address
charset
The body of the freedb submission must be sent exactly as described in
Appendix B. Do _not_ encode the data in any way before transmitting it; data
must be sent as raw text. Windows programmers should not use the Windows URL
encode function prior to calling the submit CGI program. Doing so may lead to
corrupt data being sent, causing rejected submissions.
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, or filled with useless default information like "track 1",
"track 2", etc.). 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 it were, 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. Check that the majority of the tracks have a title filled in by the user.
This should minimize the amount of useless garbage being submitted to the
CD database.
Before you release your software, please be sure that it produces submissions
that adhere to the freedb file format, and that the frame offset, disc
length, and disc ID information are correctly computed.
For testing, please make your software sends submissions with the
"Submit-Mode" HTTP header field set to "test".
freedb submissions sent in test mode will be sanity-checked by the freedb
server and pass/fail confirmation will be sent back to the submitter, but
the submission will not actually be deposited in the CD database. Please do
_not_ send submissions in "submit" mode until you have tested your program
with several different CD's.
When you feel your application is ready to support submissions, we would
appreciate, if you would contact us and provide a copy of your program
before releasing it, so we can check if everything is really OK.
QUESTIONS?
----------
Questions regarding the freedb or the CDDB/freedb server should be directed to
info@freedb.org
APPENDIX A - CDDB/FREEDB DISCID ALGORITHM
-----------------------------------------
The following is a C code example that illustrates how to generate the
CDDB/freedb disc ID. Examples in other programming languages may be found on
the freedb web site at http://www.freedb.org in the developers-section.
A text description of the algorithm follows, which should contain the necessary
information to code the algorithm in any programming language.
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 recognize data tracks, as you find them on
CD Extra CD's. Therefore a wrong disc ID is generated for CD Extra's when
using the MCI interface to read the TOC. Because of this, using the MCI
interface should only be the last resort - if possible you should use other
methods to read the TOC, like ASPI calls. An example disc ID calculator using
ASPI can be found on the freedb website along with the sourcecode.
If for some reason, there is no other way for your program, than to use the MCI
interface, here is the description how to do so:
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 - FREEDB FILE FORMAT
-------------------------------
Database entries must be in the US-ASCII, ISO-8859-1 (the 8-bit ASCII
extension also known as "Latin alphabet #1" or ISO-Latin-1) or UTF-8 (Unicode)
character set. Lines must always be terminated by a newline/linefeed
(ctrl-J, or 0Ah) character or a carriage return character (ctrl-M, or 0Dh)
followed by a newline/linefeed character. All lines in a database entry must
be less than or equal to 256 characters in length, including the terminating
character(s). 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
should 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, even though database entries without such a
blank comment are also considered valid.
After the offset list, the following string should appear:
"# Disc length: N"
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
may not be rounded.
Any string, such as "seconds", may be appended to the line provided there's at
least one white space between the amount of seconds and the string. An
application must be able to parse the line correctly at all times.
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. For more information see the freedb.howto.
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
positive 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 }
or an UTF-8 encoded string.
Newlines (0Ah), 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; this
applies to any of the textual fields.
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. Note that linking entries is
now deprecated and should not be used by submitting programs!
The algorithm for generating the disc ID is described in the freedb.howto.
DTITLE: Technically, this may consist of any data, but by convention contains
the artist and disc title (in that order) separated by a "/" with a
single space on either side to separate it from the text. There may be
other "/" characters in the DTITLE, but not with space on both sides,
as that character sequence is exclusively reserved as delimiter of
artist and disc title! If the "/" is absent, it is implied that the
artist and disc title are the same, although in this case the name
should rather be specified twice, separated by the delimiter.
If the disc is a sampler containing titles of various artists, the disc
artist should be set to "Various" (without the quotes).
DYEAR: This field contains the (4-digit) year, in which the CD was released.
It should be empty (not 0) if the user hasn't entered a year.
DGENRE: This field contains the exact genre of the disc in a textual form
(i.e. write the genre here and do not use e.g. simply the MP3 ID3V1
genre code). Please note that this genre is not limited to the
11 CDDB-genres. The Genre in this field should be capitalized, e.g.
"New Age" instead of "newage" or "new age".
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. If the disc is a
sampler and there are different artists for the track titles, the
track artist and the track title (in that order) should be separated
by a "/" with a single space on either side to separate it from the text.
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 any data
from this keyword (i.e. add an empty "PLAYORDER=" line).
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
DTITLE=Franske Stemninger / Con Spirito
DYEAR=1981
DGENRE=Classical
TTITLE0=Mille regretz de vous abandonner
[ ... 21 TTITLEN keywords omitted ]
TTITLE22=L'arche de no
EXTD=Copyright (c) 1981 MCA Records Inc.\nManufactured f
EXTD=or MCA Records Inc.
EXTT0=Des Prez\nYez
[ ... 21 EXTTN keywords omitted ]
EXTT22=Schmitt: A contre-voix \n(excerpt)
PLAYORDER=
Please note that the EXTD section above is split in 2 pieces and contains a \n.
It should be displayed to the user as:
Copyright (c) 1981 MCA Records Inc.
Manufactured for MCA Records Inc.
APPENDIX C - CDDB SERVER PROTOCOL
---------------------------------
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
Note: "*" means, that the command is only for administrative use and requires
special access permissions, that normal users don't have.
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
List the genre categories:
--------------------------
Client command:
-> cddb lscat
Server response:
<- code Okay category list follows (until terminating marker)
<- category
<- category
<- (more categories...)
<- .
code:
210 Okay category list follows
category:
CD category. Example: rock
Query database for matching entries:
------------------------------------
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
Read entry from database:
-------------------------
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
* Delete entry from database:
-----------------------------
Client command:
-> cddb unlink categ discid
categ:
CD category. Example: rock
discid:
CD disc ID number. Example: f50a3b13
Server response:
<- code and message
code and message:
200 OK, file has been deleted.
401 Permission denied.
402 File access failed.
501 Invalid category: categ.
categ:
CD category. Example: rock
* Write entry to database:
--------------------------
Client command:
-> cddb write categ discid
categ:
CD category. Example: rock
discid:
CD disc ID number. Example: f50a3b13
Server response:
<- code and message
code and message:
320 OK, input CDDB data (until terminating marker)
401 Permission denied.
402 Server file system full/file access failed.
409 No handshake.
Client data:
-> # xmcd 2.0 CD database file
-> # ...
-> (CDDB data)
-> .
Server response:
<- code message
code:
200 CDDB entry accepted
501 Entry rejected: reason for rejection.
message:
Message string to indicate write status:
CDDB entry accepted, or CDDB entry rejected.
Discid calculation:
------------------
Client command:
-> discid ntrks off_1 off_2 ... off_n nsecs
ntrks:
total number of tracks on CD.
off_X:
frame offset of track X.
nsecs:
total playing length of the CD in seconds.
Server response:
<- code Disc ID is discid
code:
200 Calculated disc ID properly
500 Command Syntax error
discid:
CD disc ID number calculated from the given arguments.
* Get a server system file:
---------------------------
Client command:
-> get file
file:
filename of the file to get
Server response:
<- code message
or
<- code OK, (filename) follows (until terminating `.')
<- (file content)
<- .
code and message:
210 OK, %s follows (until terminating `.')
401 Permission denied.
402 File access failed.
402 File not found.
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.
* Put a server system file:
---------------------------
Client command:
-> put file
file:
sites or motd
Server response:
<- code message
code and message:
320 OK, input file data (terminate with `.')
401 Permission denied.
402 File access failed.
402 Not a regular file.
Client data:
-> (file data of the file, that shall be written)
-> .
Server response
<- code message
code and message:
200 Put successful.
402 File access failed.
501 Input too long.
Close connection to server:
---------------------------
Client command:
-> quit
Server response:
<- code hostname message
code and message:
230 Closing connection. Goodbye.
530 error, closing connection.
hostname:
Server host name. Example: xyz.fubar.com
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:
us.freedb.org 8880 N037.21 W121.55 San Jose, 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.
* 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.
* Perform user validation:
--------------------------
Client command:
-> validate
Server response:
<- 503 Validation not required.
or
<- 320 OK, input validation string, salt=saltvalue (terminate with newline)
Client data:
-> validation string
Server response:
-> code message
code and message:
200 Validation successful.
501 Incorrect validation string length.
502 Invalid validation string.
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.5PL0
copyright:
Copyright string. Example: Copyright (c) 1996-2001 Steve Scherf et al.
* Server users:
---------------
Client command:
-> whom
Server response:
<- code message
code and message:
210 OK, user list follows (until terminating marker)
401 No user information available.
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:
us.freedb.org cddbp 8880 - N037.21 W121.55 San Jose, CA USA
us.freedb.org http 80 /~cddb/cddb.cgi N037.21 W121.55 San Jose, 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:
210 Found exact matches, list follows (until terminating marker)
CDDB Protocol Level 5:
----------------------
Protocol level 5 is the same as level 4, with the following exception:
The database entries returned when issuing the "cddb read" command now also
contain DYEAR and DGENRE fields (between the DTITLE and the TTITLE's).
For more info on the new database entry fields take a look at the
database format specification
CDDB Protocol Level 6:
----------------------
Protocol level 6 is the same as level 5 except that the character set
is now UTF-8 instead of ISO-8859-1. Note that UTF-8 is an extension of
US-ASCII, just like ISO-8859-1 is an extension of US-ASCII, so there
is no difference between levels 5 and 6 as far as 7-bit ASCII data is
concerned.
Clients can convert data between UTF-8 and the user's preferred
character set using the iconv program and library function which are
provided by glibc-2.2 or by the portable library libiconv. (They are
also provided by the C library on some non-glibc systems, but often in
a buggy or incompatible form.) For example, to convert data to UTF-8
from the character set of the current locale in a shell script use
"iconv -t utf-8 < in > out".
For more information about Unicode and UTF-8 see:
ftp://ftp.ilog.fr/pub/Users/haible/utf8/Unicode-HOWTO.html
http://www.cl.cam.ac.uk/~mgk25/unicode.html
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" should 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 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 (usually
http://freedb_server/~cddb/cddb.cgi) 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-URL" 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=6
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=5
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 e-mail mode (SMTP) commands is simple. A special subject line
lets the server know that the e-mail contains a command, and somewhere in the
body there should be a HTTP-style server command; the server will execute
only one such commands per e-mail.
The subject for e-mail 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 e-mail should be exactly one server command. For
example:
cmd=motd&hello=joe+my.host.com+xmcd_via_email+v1.0&proto=6
As you might have noticed, this command is exactly the same as a HTTP-mode
CDDBP command. The command response will be mailed to the sender. Upon
successful completion of an e-mail command request (even if the command
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 e-mail 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 e-mail.
APPENDIX D - OFFICIAL FREEDB SOFTWARE DISTRIBUTION SITES
--------------------------------------------------------
All freedb-related software and archive distribution is via the
freedb web page (in the downloads section):
http://www.freedb.org/
There you can find an actual list of ftp and http-mirrors to download the
freedb database archives and server software.