     [file version.texi not included]

This file documents GNU CD Input and Control Library

Copyright (C) 2003, 2004 Herbert Valerio Riedel <hvr@gnu.org> and Rocky Bernstein <rocky@panix.com>

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with the Invariant Sections being ``Free Software'' and ``Free Software Needs Free Documentation'', with the Front-Cover Texts being ``A GNU Manual,'' and with the Back-Cover Texts as in (a) below.

(a) The Free Software Foundation's Back-Cover Text is: ``You have freedom to copy and modify this GNU Manual, like GNU software.  Copies published by the Free Software Foundation raise funds for GNU development.''

The GNU Compact Disc Input and Control Library (libcdio)
********************************************************

This file documents GNU CD input and control library

Copyright (C) 2003, 2004 Herbert Valerio Riedel and Rocky Bernstein

History
*******

As a result of the repressive Digital Millenium Copyright Act (DMCA) I became aware of Video CD's (VCD's). Video CD's are not subject to the DMCA and therefore enjoy the protection afforded by copyright but no more. But in order for VCD's to be competitive with DVD's, good tools (including GPL tools) are needed for authoring and playing them. And so through VCD's I became aware of the excellent Video CD tools by Herbert Valerio Riedel which form the vcdimager package.

Although vcdimager is great for authoring, examining and extracting parts of a Video CD, it is not a VCD player. And when I looked at the state of Video CD handling in existing VCD players: xine, MPlayer, and vlc, I was a bit disappointed. None handled playback control, menu selections, or playing still frames and segments from track 1.

Version 0.7.12 of vcdimager was very impressive, however it lacked exportable libraries that could be used in other projects. So with the blessing and encouragement of Herbert Valerio Riedel, I took to extract and create libraries from this code base. The result was two libraries: one to extract information from a VCD which I called libvcdinfo, and another to do the reading and control of a VCD. Well, actually, at this point I should say that a Video CD is really just Video put on a existing well-established Compact Disc or CD format. So the library for this is called libcdio rather than libvcdio.

While on the topic of the name libcdio, I should also explain that the library really doesn't handle writing or output (the final "o" in the name). However it was felt that if I put libcdi that might be confused with a particular CD format called CD-I.

The problem and previous work
*****************************

If around the year 2002 you were to look at the code for a number of open-source CD or media players that work on several platforms such as vlc, MPlayer, xine, or xmms to name but a few, you'd find the code to read a CD sprinked with conditional compilation for this or that platform.

One CD player, xmcd by Ti Kan, was I think a bit better than most in that it tried to encapsulate the kinds of CD control mechanisms (SCSI, Linux ioctl, Toshiba, etc.) in a "CD Audio Device Interface Library" called libdi.  However this library is for Audio CD's only and I don't believe this library has been used outside of xmcd.

Another project, Simple DirectMedia Layer also encapsulates CD reading.

     SDL is a library that allows you portable low-level access to a video framebuffer, audio output, mouse, and keyboard. With SDL, it is easy to write portable games which run on ...

Many of the media players mentioned above do in fact can make use of the SDL library but for video output only. Because the encapsulation is over many kinds of I/O (video, joysticks, mice, as well as CD's), I believe that the level of control provided for CD a little bit limited. (However to be fair, it may have only been intended for games and may be suitable for that).  Applications that just want the CD reading and control portion I think will find quite a bit overhead.

Another related project J\"org Schilling's SCSI library. If I knew how to make this project hook into that I'd do it. If you want to volunteer to undertake, please let me know.

At the OS level there is the "A Linux CD-ROM Standard" by David van Leeuwen from around 1999. This defines a set of definitions and ioctl's that mask hardware differences of various Compact Disc hardware. It is a great idea and no doubt something similar exists on other platforms. However this "standard" lacked adoption on OS's other than GNU/Linux.

The library ``The Compact Disc Input and Control Library'' encapsulates CD-ROM reading and control. Applications wishing to be oblivious of the OS- and device-dependent properties of a CD-ROM can use this library. Some support for disk image types like BIN/CUE and NRG is available, so applications that use this library also have the ability to read disc images as though they were CDs.

A sample utility for displaying CD info is included.

CD Formats
**********

Much of what I write in this section can be found elsewhere. See for example http://www.pctechguide.com/08cd-rom.htm or http://www.pcguide.com/ref/cd/format.htm

We give just enough background here to cover Compact Discs and Compact Disc formats that are handled by this library.

The Sony and Philips Corporations invented and Compact Disc (CD) in the early 1980s. The specifications for the layout is often referred to by the color of the cover on the specification.

Red Book
========

The first type of CD that was produced was the Compact Disc Digital Audio (CD-DA) or just plain ``audio CD''. The specification, ICE 908, is commonly called the ``Red Book''. Music CD's are recorded in this format which basically allows for around 74 minutes of audio per disc and for that information to be split up into tracks. Tracks are broken up into "sectors" and each sector contains 2,352 bytes. To play one 44.1 kHz CD-DA sampled audio second, 75 sectors are used.

In libcdio when you you want to read an audio sector, you call the routine cdio_read_audio_sector().

Yellow Book
===========

The CD-ROM specification or the ``Yellow Book'' followed a few years later (Standards ISO/IEC 10149), and describes the extension of CD's to store computer data, i.e. CD-ROM (Compact Disk Read Only Memory).

The specification in the Yellow Book defines two modes: Mode1 and Mode2.

ISO 9660
--------

The Yellow Book doesn't specify how data is to be stored on a CD-ROM. It was feared that different companies would implement proprietary data storage formats using this specification, resulting in incompatible data CDs. To prevent this, representatives of major manufacturers met at the High Sierra Hotel and Casino in Lake Tahoe, NV, in 1985, to define a standard for storing data on CDs. This format was nicknamed High Sierra Format. In a slightly modified form it was later adopted as ISO the ISO 9660 standard. This standard is further broken down into 3 "levels", the higher the level, the more permissive.

ISO 9660 Level 1
................

Level 1 ISO 9660 defines names in the 8+3 convention so familiar to MS-DOS: eight characters for the filename, a period, and then three characters for the file type, all in upper case. The allowed characters are A-Z, 0-9, ".", and "_".Level 1 ISO 9660 requires that files occupy a contiguous range of sectors. This allows a file to be specified with a start block and a count. The maximum directory depth is 8. For a table of the characters, see ISO-9660 Character Sets.

ISO 9660 Level 2
................

Level 2 ISO 9660 allows far more flexibility in filenames, but isn't usable on some systems, notably MS-DOS.

ISO 9660 Level 3
................

Level 3 ISO-9660 allows non-contiguous files, useful if the file was written in multiple packets with packet-writing software.

There have been a number of extensions to the ISO 9660 CD-ROM file format. One extension is Microsoft's Joliet specification, designed to resolve a number of deficiencies in the original ISO 9660 Level 1 file system, and in particular to support the long file names used in Windows 95 and subsequent versions of Windows.

Another extension is the Rock Ridge Interchange Protocol (RRIP), which enables the recording of sufficient information to support POSIX File System semantics.

Mode1
-----

Mode 1 is the data storage mode used by to store computer data. There are 3 layers of error correction. A Compact Disc using only this format can hold at most 650 MB. The data is laid out in basically the same way as in and audio CD format, except that the 2,352 bytes of data in each block are broken down further. 2,048 of these bytes are for "real" data. The other 304 bytes are used for an additional level of error detecting and correcting code. This is necessary because data CDs cannot tolerate the loss of a handful of bits now and then, the way audio CDs can.

Mode2
-----

Mode 2 data CDs are the same as mode 1 CDs except that the error detecting and correcting codes are omitted. So still there are 2 layers of error correction. A Compact Disc using only this mode can thus hold at most 742 MB. Similar to audio CDs, the mode 2 format provides a more flexible vehicle for storing types of data that do not require high data integrity: for example, graphics and video can use this format. But in contrast to the Red Book standard, different modes can be mixed together; this is the basis for the extensions to the original data CD standards known as CD-ROM Extended Architecture, or CD-ROM XA.  CD-ROM XA formats currently in use are CD-I Bridge formats, Photo CD and Video CD plus Sony's Playstation.

White Book
==========

The White Book was released by Sony, Philips, Matsushita, and JVC in 1993, defines the Video CD specification. The White Book is also known as Digital Video (DV). A Video CD contains one data track recorded in CD-ROM XA Mode 2 Form 2. It is always the first track on the disc (Track 1). The ISO-9660 file structure and a CD-i application program are recorded in this track, as well as the Video CD Information Area which gives general information about the Video Compact Disc. After the data track, video is written in one or more subsequent tracks within the same session. These tracks are also recorded in Mode 2 Form 2.

In libcdio when you you want to read a mode2 format 2 audio sector you call the routine cdio_read_mode2_sector().

CD Terminology
**************

tracks --- disc subdivisions
============================

In this section we describe CD properties and terms that we make use of in libcdio.

A CD is formated into a number of tracks, and a CD can hold at most 99 such tracks. Between the tracks CD specifications require a ``2 second'' in gap (called a lead-in gap. This is unused space with no ``data'' similar to the space between tracks on an old phonograph. The word ``second'' here really refers to a measure of space and not really necessarily an amount of time. However in the special case that the CD encodes an audio CD or CD-DA, the amount of time to play a gap of this size will take 2 seconds.

The beginning (or inner edge) of the CD is supposed to have a ``2 second'' lead-in gap and there is supposed to be another ``2 second'' lead-out gap at the end (or outer edge) of the CD.

People have discovered that they can put useful data in the various gaps and their equipment can read this, violating the standards but allowing a CD to store more data.

In order to determine the number of tracks on a CD and where they start, commands are used to get this table-of-contents or TOC information. Asking about the start of the lead-out track gives the amount of data stored on the Compact Disk. To make it easy to specify this leadout track, special constant 0xAA (decimal 170) is used to indicate it. This is safe since this is higher than the largest legal track position. In libcdio, CDIO_CDROM_LEADOUT_TRACK is defined to be this special value.

block addressing (MSF, LSN, LBA)
================================

A track is broken up into a number of 2352-byte blocks which we sometimes call sectors. Whereas tracks have to have a gap between them, a block or sector does not.

One can addressing a block in one of three formats. The oldest format is by it's minute/second/frame number, also referred to as MSF and written in time-like format MM:SS:FF (e.g. 30:01:40). In this notation there are 75 ``frames'' in a ``second,'' and the familiar (if awkward) 60 seconds in a minute. Frame here is what we called a block above. The CD specification defines ``frame'' to be another unit which makes up a block. Very confusing.

Even more confusing is is using this time-like notation for an address or for a length. Too often people confuse the MSF notation this with an amount of time. A ``second'' (or 75 blocks) in this notation is only a second of playing time for something encoded as CD-DA. It does not necessarily represent the amount time that it will take to play a of Video CD---usually you need more blocks than this. Nor does it represent the amount of data used to play a second of an MP3---usually you need fewer blocks than this. It is also not the amount of time your CD-ROM will take to read a ``second'' of data off a Compact Disc: for example a 12x CD player will read 12x75 2352-byte blocks in a one second of time.

Furthermore when programming, it is generally more cumbersome to use an MSF rather than a LBA or LSN described below, since subtraction of two MSF's has the awkwardness akin to subtraction using Roman Numerals.

Probably the simplest way to address a block is to use its LSN or ``logical sector number.'' This just numbers the blocks from 0 on. The Lead-in and Lead-out gaps described above have LSNs just like any other space on a CD. The last unit of address is a LBA. It is the same as a LSN but the 150 blocks assocated with the initial lead-in is are not counted. So to convert a LBA into an LSN you just add 150. Why the distinction between LBA and LSN? I don't know.

How to use
**********

Example 1 --- list out tracks and LSNs
======================================

Here we will give an annotated example which can be found in the distribution as example/sample1.c.

      1: #include <stdio.h>
      2: #include <sys/types.h>
      3: #include <cdio/cdio.h>
      4: int
      5: main(int argc, const char *argv[])
      6: {
      7:  CdIo *cdio = cdio_open ("/dev/cdrom", DRIVER_UNKNOWN);
      8:  track_t first_track_num = cdio_get_first_track_num(cdio);
      9:  track_t num_tracks      = cdio_get_num_tracks(cdio);
     10:  int j, i=first_track_num;
     11:
     12:  printf("CD-ROM Track List (%i - %i)\n", first_track_num, num_tracks);
     13
     14:  printf("  #:  LSN\n");
     15:
     16:  for (j = 0; j < num_tracks; i++, j++) {
     17:    lsn_t lsn = cdio_get_track_lsn(cdio, i);
     18:    if (CDIO_INVALID_LSN != lsn)
     19:      printf("%3d: %06d\n", (int) i, lsn);
     20:  }
     21:  printf("%3X: %06d  leadout\n", CDIO_CDROM_LEADOUT_TRACK,
     22:         cdio_get_track_lsn(cdio, CDIO_CDROM_LEADOUT_TRACK));
     23:  cdio_destroy(cdio);
     24:  return 0;
     25: }

Already from the beginning on line 2 we see something odd. The #include <sys/types.h> is needed because libcdio assumes type definitions exist for uint32_t, uint16_t and so on.  Alternatively you change line 2to:

     #define HAVE_SYS_TYPES_H

and <cdio/cdio.h> will insert line 2. If you use GNU autoconf to configure your program, add sys/types.h to AC_HAVE_HEADERS and it will arrange for HAVE_SYS_TYPES_H to get defined. If you don't have <sys/types.h> but have some other include that defines these types, put that instead of line 2. Or you could roll your own typedefs. (Note: In the future, this will probably get ``fixed'' by requiring glib.h.)

Okay after getting over the hurdle of line 2, the next line pretty straightforward: you need to include this to get cdio definitions. One of the types that is defined via line 3 is CdIo and a pointer that is used pretty much in all operations. Line 6 initializes the variable cdio which we will be using in all of the subsequent libcdio calls. It does this via a call to cdio_open().

The second parameter of cdio_open is DRIVER_UNKNOWN. For any given installation a number of Compact Disc device drivers may be available. In particular it's not uncommon to have several drivers that can read CD disk-image formats as well as a driver that handles some CD-ROM piece of hardware. Using DRIVER_UNKNOWN as that second parameter we let the library select a driver amongst those that are available; generally the first hardware driver that is available is the one selected.

Note that in contrast to what is typically done using ioctls to read a CD, you don't issue any sort of CD-ROM read TOC command---that is all done by the driver. Of course, the information that you get from reading the TOC is often desired: many tracks are on the CD, or what number the first one is called. This is done through calls on lines 8 and 9.

For each track, we call a cdio routine to get the logical sector number, cdio_get_track_lsn() on line 17 and print the track number and LSN value. Finally we print out the ``lead-out track'' information and we finally call cdio_destroy() in line 23 to indicate we're done with the CD.

Example 2 --- lists drivers available and default CD device
===========================================================

One thing that's a bit hoaky in Example 1 is hard-coding the name of the device used: /dev/cdrom. Although often this is the name of a CD-ROM device on GNU/Linux and possibly some other Unix derivates, there are many OSs for which use a different device name.

In the next example, we'll let the driver give us the name of the CD-ROM device that is right for it.

      1: #include <stdio.h>
      2: #include <sys/types.h>
      3: #include <cdio/cdio.h>
      4: int
      5: main(int argc, const char *argv[])
      6: {
      7:   CdIo *cdio = cdio_open (NULL, DRIVER_UNKNOWN);
      8:   driver_id_t driver_id;
      9:
     10:  if (NULL != cdio) {
     11:    printf("The driver selected is %s\n", cdio_get_driver_name(cdio));
     12:    printf("The default device for this driver is %s\n\n",
     13:           cdio_get_default_device(cdio));
     14:    cdio_destroy(cdio);
     15:  } else {
     16:    printf("Problem in trying to find a driver.\n\n");
     17:  }
     18:
     19:  for (driver_id=CDIO_MIN_DRIVER; driver_id<=CDIO_MAX_DRIVER; driver_id++)
     20:    if (cdio_have_driver(driver_id))
     21:      printf("We have: %s\n", cdio_driver_describe(driver_id));
     22:    else
     23:      printf("We don't have: %s\n", cdio_driver_describe(driver_id));
     24:  return 0;
     25: }

Fill out examples for cdio_read_xxx or cdio_seek, More on drivers?.

ISO-9660 Character Sets
***********************

For a description of where are used see ISO 9660 Level 1.

ISO646 d-Characters
===================

       | 0 1 2 3 4 5 6 7
     --+-----------------
     0 |       0   P
     1 |       1 A Q
     2 |       2 B R
     3 |       3 C S
     4 |       4 D T
     5 |       5 E U
     6 |       6 F V
     7 |       7 G W
     8 |       8 H X
     9 |       9 I Y
     a |         J Z
     b |         K
     c |         L
     d |         M
     e |         N
     f |         O _

ISO646 a-Characters
===================

       | 0 1 2 3 4 5 6 7
     --+-----------------
     0 |       0   P
     1 |     ! 1 A Q
     2 |     " 2 B R
     3 |       3 C S
     4 |       4 D T
     5 |     % 5 E U
     6 |     & 6 F V
     7 |     ' 7 G W
     8 |     ( 8 H X
     9 |     ) 9 I Y
     a |     * : J Z
     b |     + ; K
     c |     , < L
     d |     - = M
     e |     . > N
     f |     / ? O _

CD Image Formats
****************

CDRDAO TOC Format
=================

This is cdrdao's own cd image description format. A snippet from the cdrdao(1) manual page, which you should refer to for more information about this format:

     The toc-file describes what data is written to the CD-R and allows control over track/index positions, pre-gaps and sub-channel information.  It is a simple text file, use your favorite text editor to create it.

We don't support this image format currently, but intend to in the future. Anyone want to volunteer?

BIN/CUE Format
==============

The format referred to as BIN/CUE Format in this manual is a popular CD image format used in the PC world. Not unlike cdrdao's toc file, the cue file describes the track layout, i.e. how the sectors are to be placed on the CD media. The cue file usually contains a reference to a file traditionally having the .bin extension in its filename, the bin file. This bin file contains the sector data payload which is to be written to the CD medium according to the description in the cue file.

The following is an attempt to describe the subset of the .cue file syntax as used in vcdimager in an EBNF-like notation:

     <cue-document> ::= +( <file-line> +<track-expr> )

     <digit> ::= "0" | "1" ... "8" | "9"
     <number> ::= +<digit>
     <msf> ::= <digit><digit> ":" <digit><digit> ":" <digit><digit>

     <file-line> ::= "FILE" <pathname-expr> <file-type> <EOL>

     <pathname-expr> ::= [ "\"" ] <pathname-str-without-spaces> [ "\"" ]
                       | "\"" <pathname-str> "\""

     <file-type> ::= "BINARY"

     <track-expr> ::= <track-line> [ <flag-line> ]
                      [ <pregap-line> ] *<index-line> [ <postgap-line> ]

     <flag-line> ::= "FLAGS" *<flag-type> <EOL>
     <flag-type> ::= "DCP"

     <track-line> ::= "TRACK" <number> <track-type> <EOL>

     <pregap-line> ::= "PREGAP" <msf> <EOL>

     <index-line> ::= "INDEX" <number> <msf> <EOL>

     <postgap-line> ::= "POSTGAP" <msf> <EOL>

     <track-type> ::= "AUDIO" | "MODE1/2048" | "MODE1/2352"
                    | "MODE2/2336" | "MODE2/2352"

     <comment-line> ::= "REM" *<char> <EOL>

NRG Format
==========

The format referred to as NRG Format in this manual is another popular CD image format. It is available only on using Nero software on a Microsoft Windows Operating System. It is proprietary and not generally published, so the information we have comes from guessing based on sample CD images. So support for this is incomplete and using this format is not recommended.

Unlike cdrdao's TOC file the BIN/CUE format everything is contained in one file. that one can edit Meta information such as the number of tracks and track format is contained at the end of the file. This information is not inteded to be edited through a text editor.

Glossary
********

     [file glossary.texi not included]

GNU General Public License
**************************

Version 2, June 1991

     [file gpl.texi not included]

GNU Free Documentation License
******************************

Version 1.1, March 2000

     [file fdl.texi not included]