-
Notifications
You must be signed in to change notification settings - Fork 0
/
cddb-howto.txt
1350 lines (1045 loc) · 44.4 KB
/
cddb-howto.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
USE OF CDDB SERVICE IN YOUR SOFTWARE
------------------------------------
Copyright (c) CDDB, Inc.
@(#)cddb.howto 1.25 98/09/28
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 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. Users of CDDB-capable freeware
and shareware applications 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 [email protected] for more
information.
If you plan to use CDDB and/or the CDDB servers in your software, please
notify [email protected] of your intent. Also, we appreciate that you
keep us posted as to your development/test progress and release schedules.
You must explicitly give credit to CDDB, Inc., both in all documentation and
when the product is operating. The latter should appear visibly for a short
time during CDDB server accesses (at least 5 seconds).
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). Users appreciate a the ability to import
CDDB data from and export to a variety of formats.
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 require 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 CDDB.
Moreover, if your software submits CDDB entries with bad disc IDs to the
CDDB archives, it could compromise the integrity of the CDDB.
We suggest installing one of the disc ID checker programs listed on the
CDDB web page at http://www.cddb.com/downloads, and then testing the discx
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. Bugs
in disc ID calculation can be subtle, and history shows that it sometimes
takes hundreds of discs to find problems.
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 provided 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, as it is guaranteed to exist
on a permanent basis.
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 it
to the CDDB archives. The method of submission is to send the entry to
following address via electronic mail:
You may implement a button or somesuch in your software's user-interface
to facilitate this. The destination e-mail address should not 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-1 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 to ensure 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). Please design your client
with this in mind. 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. 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.
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 the
following e-mail address:
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. Please do not send test submisions to
[email protected], as this address is used only for submissions
by client applications which have been fully approved.
When you feel your application is ready to support submissions, please contact
us at [email protected]. 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 send any questions or comments to [email protected].
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. 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
-----------------------------
Database entries must be in the ISO-8859-1 character set (the 8-bit ASCII
extension also known as "Latin alphabet #1" or ISO-Latin-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. For more information, see Appendix A.
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
Level: is a positive number.
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 (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. 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. There is no practical limit to the size
of any of the textual fields or a database entry itself, though the CDDB server
software may place a restriction on especially large entries. Valid keywords
are as follows:
DISCID: The data following this keyword should contain the 8-byte disc ID.
indicated by the track offsets in the comment section. The algorithm
for generating the disc ID is explained in Appendix A.
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. 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.
An example database entry follows:
# xmcd
# Copyright (C) 1993-1998 CDDB, Inc.
#
# Track frame offsets:
# 150
# 47275
# 76072
# 89507
# 117547
# 136377
# 157530
#
# Disc length: 2663 seconds
#
# Revision: 2
# Submitted via: xmcd 2.3beta PL0
#
DISCID=470a6507
DTITLE=Led Zeppelin / Presence
TTITLE0=Achilles Last Stand
TTITLE1=For Your Life
TTITLE2=Royal Orleans
TTITLE3=Nobody's Fault But Mine
TTITLE4=Candy Store Rock
TTITLE5=Hots On For Nowhere
TTITLE6=Tea For One
EXTD=Producer: Jimmy Page\nExecutive Producer: Peter Gr
EXTD=ant\n\nUPC: 7567-90329-2\nLABEL: Atlantic Recordin
EXTD=g Corporation\nYEAR: 1976
EXTT0=Jimmy Page and Robert Plant
EXTT1=Jimmy Page and Robert Plant
EXTT2=John Bonham, John Paul Jones, Jimmy Page and\nRob
EXTT2=ert Plant
EXTT3=Jimmy Page and Robert Plant
EXTT4=Jimmy Page and Robert Plant
EXTT5=Jimmy Page and Robert Plant
EXTT6=Jimmy Page and Robert Plant
PLAYORDER=
Please note that the EXTD section above is split into three pieces. When
displayed to the user, it should appear like this:
Producer: Jimmy Page
Executive Producer: Peter Grant
UPC: 7567-90329-2
LABEL: Atlantic Recording Corporation
YEAR: 1976
APPENDIX C - CDDB SERVER PROTOCOL
---------------------------------
CDDB 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
It is best if client applications treat response codes generically when
possible, rather than having hard-coded "expected" or known codes in the
application.
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 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.
417 Access limit exceeded, explanation follows (until marker)
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: