     [file version.texi not included]

This manual documents libcdio, the GNU CD Input and Control Library.

Copyright © 2003, 2004, 2005, 2006, 2007, 2008 Rocky Bernstein and Herbert Valerio Riedel.

     Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts.  A copy of the license is included in the section entitled ``GNU Free Documentation License''.

GNU libcdio
***********

This manual documents libcdio, the GNU CD Input and Control Library.

History
*******

As a result of the repressive Digital Millennium 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.

Later on, the ISO-9660 filesystem handling component from vcdimager was extracted, expanded and made a separate library. Next the ability to add MMC commands was added, and then CD paranoia support. And from there, the rest is history.

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

If around the year 2002 you were to look at the code for a number of free software 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 sprinkled with conditional compilation for this or that platform. That is there was no OS-independent programmer library for CD reading and control even though the technology was over 10 years old; yet there are media players which strive for OS independence.

One early 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 is Jörg Schilling's SCSI library. You can use that to make a non-SCSI CD-ROM act like one that understands SCSI MMC commands which is a neat thing to do. However it is a little weird to have to install drivers just so you can run a particular user-level program. Installing drivers often requires special privileges and permissions and it is pervasive on a system. It is a little sad that along the way to creating such a SCSI library a library similar to libcdio wasn't created which could be used. Were that the case, this library certainly never would have been written.

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, however this ``standard'' lacked adoption on OS's other than GNU/Linux. Or maybe it's the case that the standard on other OS's lacked adoption on GNU/Linux. For example on FreeBSD there is a ``Common Access Method'' (CAM) used for all SCSI access which seems not to be adopted in GNU/Linux. (And I'm thankful for that since, at least for MMC commands, it is inordinately complicated and in some places arcane.)

Finally at the hardware level where a similar chaos exists, there has been an attempt to do something similar with the MMC (multimedia commands). This attempts to provide a uniform command set for CD devices like PostScript does for printer commands. (I wrote ``attempts'' because over time the command set has changed and now there are several different commands to do a particular function like read a CD table of contents and some hardware understands some of the version of the commands set but might not others) In contrast to PostScript where there one in theory can write a PostScript program in a uniform ASCII representation and send that to a printer, for MMC although there are common internal structures defined, there is no common syntax for representing the structures or an OS-independent library or API for issuing MMC-commands which a programmer would need to use. Instead each Operating System has its own interface.  For example Adaptec's ASPI or Microsoft's DeviceIoControl on Microsoft Windows, or IOKit for Apple's OS/X, or FreeBSD's CAM. I've been positively awed at how many different variations and differing levels of complexity there are for doing basically the same thing. How easy it is to issue an MMC command from a program varies from easy to very difficult. And mastering the boilerplate code to issue an MMC command on one OS really doesn't help much in figuring out how to do it on another OS. So in libcdio we provide a common (and hopefully simple) API to issue MMC commands.

What is in this package (and what's not)
****************************************

The library, libcdio, 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.

Also included is a library, libiso9660, for working with ISO-9660 filesystems, libcdio_paranoia, and libcdio_cdda libraries for applications which want to use cdparanoia's error-correction and jitter detection.

Some support for disk-image types like cdrdao's TOC, CDRWIN's BIN/CUE and Ahead Nero's NRG format is available, so applications that use this library also have the ability to read disc images as though they were CDs.

libcdio also provides a way to issue SCSI ``MultiMedia Commands'' (MMC).  MMC is supported by many hardware CD-ROM manufacturers; and in some cases where a CD-ROM doesn't understand MMC directly, some Operating Systems (such as GNU/Linux, Solaris, or FreeBSD or Microsoft Windows ASPI to name a few) provide the MMC emulation. (This concept of software emulation of a common hardware command language is common for printers such as using ghostscript to private postscript emulation for a non-postscript printer.)

The first use of the library in this package are the Video CD authoring and ripping tools, VCDImager (http://vcdimager.org). See http://www.gnu.org/software/libcdio/projects.html for a list of projects using libcdio.

A version of the CD-DA extraction tool cdparanoia (http://www.xiph.org/paranoia and its library which corrects for CD-ROM jitter are part of the distribution.

Also included in the libcdio package is a utility program cd-info which displays CD information: number of tracks, CD-format and if possible basic information about the format.  If libcddb (http://libcddb.sourceforge.net) is available, the cd-info program will display CDDB matches on CD-DA discs. And if a new enough version of libvcdinfo is available (from the vcdimager project), then cd-info shows basic VCD information.

Other utility programs in the libcdio package are:

cdda-player

     shows off libcdio audio and CD-ROM control commands. It can play a track, eject or load media and show the the status of a CD-DA that is might be currently played via the audio control commands.  It can be run in batch mode or has a simple curses-based interface.

     If libcddb is available or a CD has CD-Text and your CD-ROM drive supports CD-Text, track/album information about the CD can be shown.

cd-drive

     shows what drivers are available and some basic properties of cd-drives attached to the system. (But media may have to be inserted in order to get this info.)  lists out drive capabilities

cd-read
     performs low-level block reading of a CD or CD image,

iso-info

     displays ISO-9660 information from an ISO-9660 image. Below is some sample output

          iso-info version 0.72
          Copyright (c) 2003, 2004, 2005 R. Bernstein
          This is free software; see the source for copying conditions.
          There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
          PARTICULAR PURPOSE.
          __________________________________
          ISO 9660 image: ../test/joliet.iso
          Application: K3B THE CD KREATOR VERSION 0.11.12 (C) 2003 SEBASTIAN TRUEG AND THE K3B TEAM
          Preparer   : K3b - Version 0.11.12
          Publisher  : Rocky Bernstein
          System     : LINUX
          Volume     : K3b data project
          Volume Set : K3b data project
          __________________________________
          ISO-9660 Information
          /:
           Oct 22 2004 19:44  .
           Oct 22 2004 19:44  ..
           Oct 22 2004 19:44  libcdio

          /libcdio/:
           Oct 22 2004 19:44  .
           Oct 22 2004 19:44  ..
           Mar 12 2004 02:18  COPYING
           Jun 26 2004 07:01  README
           Aug 12 2004 06:22  README.libcdio
           Oct 22 2004 19:44  test

          /libcdio/test/:
           Oct 22 2004 19:44  .
           Oct 22 2004 19:44  ..
           Jul 25 2004 06:52  isofs-m1.cue

iso-read

     extracts files from an ISO-9660 image.

At present, there is no support for writing CD's. Nor is there any support for reading or writing DVDs. For some of these, there are other libraries (e.g. libdi, libscg, or libdvdread) may be helpful.

I'm not theoretically opposed to putting support like this into libcdio. However at present there are already many gaps in this package, so narrowing its scope in order to focus on these things I think is a good idea.

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 (CD-DA)
================

The first type of CD that was produced was the Compact Disc Digital Audio (CD-DA) or just plain ``audio CD''. The specification, ICE 60908 (formerly IEC 908) is commonly called the ``Red Book'', http://en.wikipedia.org/wiki/Red_Book_(audio_CD_standard). 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 up to 2,352 bytes. To play one 44.1 kHz CD-DA sampled audio second, 75 sectors are used.

The minute/second/frame numbering of sectors or MSF format is based on the fact that 75 sectors are used in a second of playing of sound. (And for almost every other CD format and application the MSF format doesn't make that much sense).

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

In addition the the audio data ``channel'' a provision for other information or subchannel information) can be stored in a sector. Other subchannels include a Media Catalog Number (also abbreviated as MCN and sometimes a UPC), or album meta data (also called CD-Text). Karioke graphics can also be stored in a format called CD+G.

CD Text, CD+G
-------------

CD Text is an extension to the CD-DA standard that adds the ability to album and track meta data (titles, artist/performer names, song titles) and and graphical (e.g. Karaoke) information.  For an alternative way to get album and track meta-data see CDDB.

Information is stored in such a way that it doesn't interfere with the normal operation of any CD players or CDROM drives. There are two different parts of the CD where the data can be stored.

The first place the information can be recorded is in the R-W sub codes in the lead in area of the CD giving a data capacity of about 5,000 ASCII characters (or 2,500 Kanji or Unicode characters).  This information is stored as a single block of data and is the format used in virtually all of the CD Text CDs shipping today. The method for reading this data from a CDROM drive is covered under the Sony proposal to the MMC specification. The format of the data is partially covered in the MMC specification.

The second place the information can be recorded is in the R-W sub codes in the program area of the CD giving a data capacity of roughly 31MB. This information is stored in a format that follows the Interactive Text Transmission System (ITTS) which is the same data transmission standard used by such things as Digital Audio Broadcasting (DAB), and virtually the same as the data standard for the MiniDisc. Traditionally the R-W sub codes have been used for text and graphics in applications such as CD+G (CD w/graphics) or in the case of most audio CDs, not at all. The methods for reading this data from a CD-ROM drive is covered by the programming specs from the individual drive manufacturers. In the case of ATAPI drives, the SFF8020 spec covers the reading of the RW subcodes.

Not all drives support reading the RW subcodes from the program area. However for those that do, libcdio provides a way to get at this information via cdtext_get() and its friends.

Internet CD Database (CDDB)
---------------------------

CDDB is an database on the Internet of of CD album/track, artist, and genre information similar to CD Text information. Using track information (number of tracks and length of the tracks), devices that have access to the Internet can query for meta information and contribute information for CD's where there is no existing information.  When storage is available (such as you'd expect for any program using libcdio, the information is often saved for later use when the Internet is not available; people tend request the same information since they via programs play the same music.

Obtaining CD meta information when none is encoded in an audio CD is useful in media players or making ones own compilations from audio CDs.

There are currently two popular CDDB services on the Internet. The original database has been renamed Gracenote and is a profit making entity. FreeDB (http://freedb.org is an open source CD information resource that is free for developers and the public to use.

As there already is an excellent library for handling CDDB libcddb (http://libcddb.sourceforge.net we suggest using that. Our utility program cd-info will make use it if it is available and it's what we use in our applications that need it.

Yellow Book (CD-ROM Digital Data)
=================================

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: Mode 1 and Mode 2.

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.

Joliet Extensions
.................

Joliet extensions were an upward-compatible extension to the ISO 9660 specification that removes the limitation initially put in to deal with the limited filename conventions found in Microsoft DOS OS. In particular, the Joliet specification allows for long filenames and allows for UCS-BE (BigEndian Unicode) encoding of filenames which include mixed case letter, accented characters spaces and various symbols.

The way all of this is encoded is by adding a second directory and filesystem structure in addition to or in parallels to original ISO 9600 filesystem. The root node of the ISO 9660 filesystem is found via the Primary Volume Descriptor or PVD. The root of the Joliet-encode filesystem is found in a Supplementary Volume Descriptor or SVD defined in the ISO 9660 specification. The SVD structure is almost identical to a PVD with a couple of unused fields getting used and with the filename encoding changed to UCS-BE.

Rock Ridge Extensions
.....................

Using the Joliet Extension one overcome the limitedness of the original ISO-9660 naming scheme. But another and probably better method is to use the Rock Ridge Extension. Not only can one store a filename as one does in a POSIX OS, but the other file attributes, such as the various timestamps (creation, modification, access), file attributes (user, group, file mode permissions, device type, symbolic links) can be stored. This is much as one would do in XA attributes; however the two are not completely interchangeable in the information they store: XA does not address filename limitations, and the Rock Ridge extensions don't indicate if a sector is in Mode 1 or Mode 2 format.

The Rock Ridge extension makes use of a hook that was defined as part of the ISO 9660 standard.

Mode 1 (2048 data bytes per sector)
-----------------------------------

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.

In libcdio when you you want to read a mode1 sector you call the cdio_read_mode1_sector() or cdio_read_mode1_sectors().

Mode 2 (2336 data bytes per sector)
-----------------------------------

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.

In libcdio when you you want to read a mode1 sector you call the cdio_read_mode2_sector() or cdio_read_mode2_sectors().

Green Book (CD-i)
=================

This was a CD-ROM format developed by Philips for CD-i (an obsolete embedded CD-ROM application allowing limited user user interaction with films, games and educational applications). The format is ISO 9660 compliant and introduced mode 2 form 2 addressing. It also contains XA (Extended Architecture) attributes.

Although some Green Book discs contain CD-i applications which can only be played on a CD-i player, others have films or music videos. Video CDs in Green-Book format are labeled "Digital Video on CD." The Green Book for video is largely superseded by White book CD-ROM which draws on this specification.

White Book (DV, Video CD)
=========================

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 cdio_read_mode2_sector() or cdio_read_mode2_sectors() setting b_form2 to true.

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

In both the cdrdao and bin/cue formats there is one meta-file with extensions .toc or .cue respectively and one or more files (often with the extension .bin) which contains the content of tracks. The format of the track data is often interchangeable between the two formats.  For example, in libcdio's regression tests we make use of this to reduce the size of the test data and just provide alternate meta-data files (.toc or .cue).

In contrast to the first two formats, the NRG format consists of a single file. This has the advantage of being a self-contained unit: in the other two formats it is possible for the meta file to refer to a file that can't be found. A disadvantage of the NRG format is that the meta data can't be easily viewed or modified say in a text file as it can be with the first two formats. In conjunction with this disadvantage is another disadvantage that the format is not documented, so how libcdio interprets an NRG image is based on inference. It is recommended that one of the other forms be used instead of NRG where possible.

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

This is cdrdao's CD-image description format. Since this program is GPL and everything about it is in the open, it is the preferred format to use. (Alas, at present it isn't as well supported in libcdio as the BIN/CUE format.)

The toc-file describes what data is written to the media in the CD-ROM; it allows control over track/index positions, pre-gaps and sub-channel information.  It is a text file, so a text editor can be used to create, view or modify it.

The cdrdao(1) manual page, contains more information about this format.

CDRDAO Grammar
--------------

Below are the lexical tokens and grammar for a cdrdao TOC. It was taken from the cdrdao's pacct grammar; the token and nonterminal names are the same.

     #lexclass START
     #token Eof		"@"
     #token                  "[\t\r\ ]+"
     #token Comment          "//~[\n@]*"
     #token                  "\n"
     #token BeginString      "\""
     #token Integer          "[0-9]+"
     #tokclass AudioFile     { "AUDIOFILE" "FILE" }

     #lexclass STRING
     #token EndString        "\""
     #token StringQuote      "\\\""
     #token StringOctal      "\\[0-9][0-9][0-9]"
     #token String           "\\"
     #token String           "[ ]+"
     #token String           "~[\\\n\"\t ]*"

     <toc>  ::= ( "CATALOG" <string> | <tocType> )* { <cdTextGlobal> }
                ( <track> )+ Eof

     <track> ::= "TRACK" <trackMode>
         { <subChannelMode> }
         (  "ISRC" <string> | { "NO" } "COPY" | { "NO" } "PRE_EMPHASIS"
         | "TWO_CHANNEL_AUDIO"  | "FOUR_CHANNEL_AUDIO" )*
         { <cdTextTrack>  }
         { "PREGAP" <msf> }
         ( <subTrack> | "START" { msf } | "END" { msf } )+
         ( "INDEX" <msf> )*

     <subTrack> ::=
          AudioFile <string> { "SWAP"  } { "#" <sLong>  }  <samples>
          | "DATAFILE" <string> { "#" <sLong> { <dataLength> } }
          | "FIFO" <string> <dataLength>
          | "SILENCE" <samples>
          | "ZERO" { dataMode  } { <subChannelMode>  } <dataLength>

     <string> ::=  BeginString ( String | StringQuote | StringOctal )+
                 EndString

     <stringEmpty> ::= BeginString ( String | StringQuote | StringOctal )*
                     EndString

     <uLong> ::= Integer

     <sLong> ::= Integer

     <msf> ::= Integer ":" Integer ":" Integer

     <samples> ::= <msf> | <uLong>

     <dataLength> ::= <msf> | <uLong>

     <dataMode> ::=  "AUDIO" | "MODE0" | "MODE1" | "MODE1_RAW" | "MODE2"
          | "MODE2_RAW" | "MODE2_FORM1" | "MODE2_FORM2" | "MODE2_FORM_MIX"

     <trackMode> ::= "AUDIO" | "MODE1" | "MODE1_RAW" | "MODE2"
          | "MODE2_RAW"  | "MODE2_FORM1" | "MODE2_FORM2" | "MODE2_FORM_MIX"

     <subChannelMode> ::= "RW" | "RW_RAW"

     <tocType> ::= "CD_DA" | "CD_ROM" | "CD_ROM_XA" | "CD_I"

     <packType> ::= "TITLE" | "PERFORMER" | "SONGWRITER" | "COMPOSER" | "ARRANGER"
          | "MESSAGE" | "DISC_ID" | "GENRE" | "TOC_INFO1" | "TOC_INFO2"
          | "RESERVED1" | "RESERVED2" | "RESERVED3" | "RESERVED4" | "UPC_EAN" |
          "ISRC" | "SIZE_INFO"

     <binaryData> ::=  "{"
         { Integer ( "," Integer  )* }
         "}"

     <cdTextItem> ::= <packType>  ( <stringEmpty> | <binaryData> )

     <cdTextBlock> ::=  "LANGUAGE" Integer "{" ( <cdTextItem> )* "}"

     <cdTextLanguageMap> ::=
         "LANGUAGE_MAP" "{"
         ( Integer  ":" (  Integer | "EN"  ) )+
         "}"

     <cdTextTrack> ::=  "CD_TEXT" "{" ( <cdTextBlock> )*  "}"

     <cdTextGlobal> ::= "CD_TEXT" "{" { <cdTextLanguageMap> } ( <cdTextBlock> )* "}"

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

The format referred to as CDRWIN 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 used in libcdio and vcdimager in an EBNF-like notation:

BIN/CUE Grammar
---------------

     <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 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 intended to be edited through a text editor.

The units that make up a CD
***************************

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

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

A CD is formatted into a number of tracks, and a CD can hold at most 99 such tracks. This is defined by CDIO_CD_MAX_TRACKS in cdio/sector.h. Between some 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 lead-in and lead-out 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 or frames. Whereas tracks may have a gap between them, a block or sector does not. (In libcdio the block size constant is defined using CDIO_CD_FRAMESIZE_RAW).

A Compact Disc has a limit on the number of blocks or sectors.  This values is defined by constant CDIO_CD_MAX_LSN in cdio/sector.h.

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). It is best suited in audio (Red Book) applications. In libcdio, the type msf_t can be used to declare variables to hold such values. Minute, second and frame values are one byte and stored
BCD notation. (Perhaps this is a libcdio design
flaw. It was originally done I guess because it was convenient for
VCDs.) There are libcdio conversion routines cdio_from_bcd8() and cdio_to_bcd8() to convert the minute, second, and frame values into or out of integers. If you want to print a field in a BCD-encoded MSF, one can use the format specifier %x (not %d) and things will come out right.

In the MSF 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. A frame is also sometimes called a sector, analogous to hard-disk terminology.

Even more confusing 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 CDIO_CD_FRAMES_PER_SEC 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 12x CDIO_CD_FRAMES_PER_SEC CDIO_CD_FRAMSIZE_RAW-byte blocks in a one second of time.

When programming, unless one is working with a CD-DA (and even here, only in a time-like fashion), 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 usually from 0 on. fix me: LSNs can be negative up to the pregap size? 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 associated 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, perhaps this has something to do with ``multisession'' CDs.

track pre-gaps -- CD-DA discs and gaps
======================================

Gaps are possibly one of the least understood topics in audio discs. In the case of CD-DA discs, standards require a silent 2 second gap before the first audio track and after the last audio track (in each session.)  These are respectively referred to as lead-in and lead-out gaps.  No other gaps are required. It is important not to confuse the required lead-in and lead-out gaps with the optional track pre-gaps.  Track pre-gaps are the gaps that may occur between audio tracks. Typically, track pre-gaps are filled with silence so that the listener knows that one song has ended, and the next will soon begin. However, track pre-gaps do not have to contain silence.  One exception is an audio disc of a live performance.  Because the performer may seamlessly move from one piece of the performance to the next, it would be unnatural for the disc to contain silence between the two pieces.  Instead, the track number updates with no interruption in the performance.  This allows the listener to either hear the entire performance without unnatural interruptions, or to conveniently skip to certain pieces of the performance.  Finally, some CD-DA discs--whose behavior will be described below--lack track pre-gaps altogether although they must still include the lead-in and lead-out gaps.

In order to understand the track pre-gaps that occur between audio tracks, it is necessary to understand how CD players display the track number and time.  Embedded in each block of audio data is non-audio information known as the Q sub-channel.  The Q sub-channel data tells the CD player what track number and time it should display while it is playing the block of audio data in which the Q sub-channel data is embedded.  Near the end of some tracks, the Q sub-channel may instruct the CD player to update the track number to the next track, and display a count down to the next track, often starting at -2 seconds and proceeding to zero.  This is known as an audio track pre-gap.  It may either contain silence, or as previously discussed--in the case of live performances--it may contain audio.  Almost as often as not, there is no pre-gap whatsoever.  Regardless, an audio track pre-gap is purely determined by the contents of the Q sub-channel, which is embedded in each audio sector.  This has some interesting implications for the track forward button.

When the track forward button is pressed on a CD player, the CD player advances to the next track, skipping that track's pre-gap. This is because the CD player uses the starting address of the track from the disc's table of contents (TOC) to determine where to start playing a track when either the track forward or track backward buttons are pressed.  So to hear a pre-gap for track 4, the listener must either listen to track 3 first, or use the track forward or backward buttons to go to track 4, then use the seek backward button to back up into track 4's pre-gap, which is really part of track 3, at least according to the TOC.  Track 1 pre-gaps are especially interesting because some commercial discs have audio hidden before the beginning of the first track!  The only way to hear this hidden audio with a standard player is to use the seek backward button as soon as track 1 begins playing!

Audio track pre-gaps may be specified in a couple of different ways in the popular cue file format.  The first way of specifying a pre-gap is to use the PREGAP command.  This will place a pre-gap containing silence before a track.  The second way of specifying a pre-gap is to give a track an INDEX 00 as well as the more normal INDEX 01. INDEX 01 will be used to specify the start of the track in the disc's TOC, while INDEX 00 will be used to specify the start of the track's pre-gap as recorded in the Q sub-channel. INDEX 00 is ordinarily used for specifying track pre-gaps that contain audio rather than silence.  Thus, the cue file format may be used to specify track pre-gaps with silence or audio, depending on whether the PREGAP or INDEX 00 commands are specified.  If neither type of pre-gap is specified for a track, no pre-gap is created for that track, which merely means the absence of pre-gap information in the Q sub-channel, and the lack of a short count down to the next track.

Various CD-DA ripping programs take various approaches to track pre-gaps.  Some ripping programs ignore track pre-gaps altogether, relying solely on the disc's TOC to determine where tracks begin and end.  If a disc is ripped with such a program, then re-burned later, the resulting disc will lack track pre-gaps, and thereby lack the playback behavior of counting down to the next track.  Other ripping programs detect track pre-gaps and record them in the popular cue file format among others.  Such ripping programs sometimes allow the user to determine whether track pre-gaps will be appended to the prior track or pre-pended to the track to which they "belong".  Note that if a ripping program is ignorant of track pre-gaps, the track pre-gaps will be appended to the prior track, because that is where the disc's TOC puts them.  Thus, there are many different ways an application may chose to deal with track pre-gaps. Consequently, libcdio does not dictate the policy a ripping program should use in dealing with track pre-gaps.  Hence, libcdio provides the cdio_get_track_pregap_[lba|lsn]() interfaces to allow the application to deal with track pre-gaps as it sees fit.

Note that the cdio_get_track_pregap_[lba|lsn]() interfaces currently only provide information for CDRDAO TOC, CDRWIN BIN/CUE, and NRG images.  Getting the track pre-gaps from a CD drive is a more complicated problem because not all CD drives support reading the Q sub-channel directly at high speed, and there is no interface to determine whether or not a drive supports this optional feature, aside from trying to read the Q sub-channel, and possibly incurring IO errors.  However, all drives do support reading the Q sub-channel indirectly while playing an audio disc by asking the drive for the current position.  Unfortunately, this occurs at normal playback speed, and requires a certain settling time after the disc starts playing.  Thus, using this slow interface requires a more sophisticated algorithm, such as binary search or some heuristic, like backing up progressively from the end of the prior track to look for the next track's pre-gap.  Note that CD drives seek slowly, so it is better to simply use a drive that can read the Q sub-channel directly at high speed, and avoid complicated software solutions.  (Not to mention that if the user has an older system with an analog audio cable hooked up between their soundboard and their drive, and a ripping program uses the slow interface, the user will hear bits of the audio on the disc!)  Consequently, because there is no good universal solution to the problem of reading the Q sub-channel from a drive, libcdio currently leaves this problem up to the application, a problem which is readily approachable through either libcdio's MMC interface or libcdio's cdda interface.  For an example of one such application, see https://gna.org/projects/cued/.

The preceding section on track pre-gaps and CD-DA was contributed by Robert William Fuller (hydrologiccycle@gmail.com).

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

The libcdio package comes with a number of small example programs in the directory example which demonstrate different aspects of the library and show how to use the library. The source code to all of the examples here are contained on the package.

Other sources for examples would be the larger utility programs cd-drive, cd-info, cd-read, iso-info, and iso-read which are all in the src directory of the libcdio package.  See also Utility Programs.

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

Here we will give an annotated example which can be found in the distribution as example/tracks.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_t *p_cdio = cdio_open ("/dev/cdrom", DRIVER_DEVICE);
      8:  track_t first_track_num = cdio_get_first_track_num(p_cdio);
      9:  track_t i_tracks        = cdio_get_num_tracks(p_cdio);
     10:  int j, i=first_track_num;
     11:
     12:  printf("CD-ROM Track List (%i - %i)\n", first_track_num, i_tracks);
     13
     14:  printf("  #:  LSN\n");
     15:
     16:  for (j = 0; j < i_tracks; i++, j++) {
     17:    lsn_t lsn = cdio_get_track_lsn(p_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(p_cdio, CDIO_CDROM_LEADOUT_TRACK));
     23:  cdio_destroy(p_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 2 to:

     #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_t 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.

If there is no CD in any of the CD-ROM drives or one does not have access to the CD-ROM, it is possible that libcdio will find a CD image in the directory you run this program and will pick a suitable CD-image driver. If this is not what you want, but always want some sort of CD-ROM driver (or failure if none), then use DRIVER_DEVICE instead of DRIVER_UNKNOWN.

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: list 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 derivatives, 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_t *p_cdio = cdio_open (NULL, DRIVER_DEVICE);
      8:   driver_id_t driver_id;
      9:
     10:  if (NULL != p_cdio) {
     11:    printf("The driver selected is %s\n", cdio_get_driver_name(p_cdio));
     12:    printf("The default device for this driver is %s\n\n",
     13:           cdio_get_default_device(p_cdio));
     14:    cdio_destroy(p_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: }

Example 3: figure out what kind of CD (image) we've got
=======================================================

In this example is a somewhat simplified program to show the use of cdio_guess_cd_type() to  figure out the kind of CD image we've got. This can be found in the distribution as example/sample3.c.

     #ifdef HAVE_CONFIG_H
     # include "config.h"
     #endif
     #include <stdio.h>
     #include <string.h>
     #include <sys/types.h>
     #include <cdio/cdio.h>
     #include <cdio/cd_types.h>

     static void
     print_analysis(cdio_iso_analysis_t cdio_iso_analysis,
     	       cdio_fs_anal_t fs, int first_data, unsigned int num_audio,
     	       track_t i_tracks, track_t first_track_num, CdIo_t *cdio)
     {
       switch(CDIO_FSTYPE(fs)) {
       case CDIO_FS_AUDIO:
         break;
       case CDIO_FS_ISO_9660:
         printf("CD-ROM with ISO 9660 filesystem");
         if (fs & CDIO_FS_ANAL_JOLIET) {
           printf(" and joliet extension level %d", cdio_iso_analysis.joliet_level);
         }
         if (fs & CDIO_FS_ANAL_ROCKRIDGE)
           printf(" and rockridge extensions");
         printf("\n");
         break;
       case CDIO_FS_ISO_9660_INTERACTIVE:
         printf("CD-ROM with CD-RTOS and ISO 9660 filesystem\n");
         break;
       case CDIO_FS_HIGH_SIERRA:
         printf("CD-ROM with High Sierra filesystem\n");
         break;
       case CDIO_FS_INTERACTIVE:
         printf("CD-Interactive%s\n", num_audio > 0 ? "/Ready" : "");
         break;
       case CDIO_FS_HFS:
         printf("CD-ROM with Macintosh HFS\n");
         break;
       case CDIO_FS_ISO_HFS:
         printf("CD-ROM with both Macintosh HFS and ISO 9660 filesystem\n");
         break;
       case CDIO_FS_UFS:
         printf("CD-ROM with Unix UFS\n");
         break;
       case CDIO_FS_EXT2:
         printf("CD-ROM with Linux second extended filesystem\n");
     	  break;
       case CDIO_FS_3DO:
         printf("CD-ROM with Panasonic 3DO filesystem\n");
         break;
       case CDIO_FS_UNKNOWN:
         printf("CD-ROM with unknown filesystem\n");
         break;
       }
       switch(CDIO_FSTYPE(fs)) {
       case CDIO_FS_ISO_9660:
       case CDIO_FS_ISO_9660_INTERACTIVE:
       case CDIO_FS_ISO_HFS:
         printf("ISO 9660: %i blocks, label `%.32s'\n",
     	   cdio_iso_analysis.isofs_size, cdio_iso_analysis.iso_label);
         break;
       }
       if (first_data == 1 && num_audio > 0)
         printf("mixed mode CD   ");
       if (fs & CDIO_FS_ANAL_XA)
         printf("XA sectors   ");
       if (fs & CDIO_FS_ANAL_MULTISESSION)
         printf("Multisession");
       if (fs & CDIO_FS_ANAL_HIDDEN_TRACK)
         printf("Hidden Track   ");
       if (fs & CDIO_FS_ANAL_PHOTO_CD)
         printf("%sPhoto CD   ",
     		      num_audio > 0 ? " Portfolio " : "");
       if (fs & CDIO_FS_ANAL_CDTV)
         printf("Commodore CDTV   ");
       if (first_data > 1)
         printf("CD-Plus/Extra   ");
       if (fs & CDIO_FS_ANAL_BOOTABLE)
         printf("bootable CD   ");
       if (fs & CDIO_FS_ANAL_VIDEOCD && num_audio == 0) {
         printf("Video CD   ");
       }
       if (fs & CDIO_FS_ANAL_SVCD)
         printf("Super Video CD (SVCD) or Chaoji Video CD (CVD)");
       if (fs & CDIO_FS_ANAL_CVD)
         printf("Chaoji Video CD (CVD)");
       printf("\n");
     }

     int
     main(int argc, const char *argv[])
     {
       CdIo_t *p_cdio = cdio_open (NULL, DRIVER_UNKNOWN);
       cdio_fs_anal_t fs=0;

       track_t i_tracks;
       track_t first_track_num;
       lsn_t start_track;          /* first sector of track */
       lsn_t data_start =0;        /* start of data area */

       int first_data = -1;        /* # of first data track */
       int first_audio = -1;       /* # of first audio track */
       unsigned int num_data  = 0; /* # of data tracks */
       unsigned int num_audio = 0; /* # of audio tracks */
       unsigned int i;

       if (NULL == p_cdio) {
         printf("Problem in trying to find a driver.\n\n");
         return 1;
       }

       first_track_num = cdio_get_first_track_num(p_cdio);
       i_tracks      = cdio_get_num_tracks(p_cdio);

       /* Count the number of data and audio tracks. */
       for (i = first_track_num; i <= i_tracks; i++) {
         if (TRACK_FORMAT_AUDIO == cdio_get_track_format(p_cdio, i)) {
           num_audio++;
           if (-1 == first_audio) first_audio = i;
         } else {
           num_data++;
           if (-1 == first_data)  first_data = i;
         }
       }

       /* try to find out what sort of CD we have */
       if (0 == num_data) {
         printf("Audio CD\n");
       } else {
         /* we have data track(s) */
         int j;
         cdio_iso_analysis_t cdio_iso_analysis;

         memset(&cdio_iso_analysis, 0, sizeof(cdio_iso_analysis));

         for (j = 2, i = first_data; i <= i_tracks; i++) {
           lsn_t lsn;
           track_format_t track_format = cdio_get_track_format(p_cdio, i);

           lsn = cdio_get_track_lsn(p_cdio, i);

           switch ( track_format ) {
           case TRACK_FORMAT_AUDIO:
           case TRACK_FORMAT_ERROR:
     	break;
           case TRACK_FORMAT_CDI:
           case TRACK_FORMAT_XA:
           case TRACK_FORMAT_DATA:
           case TRACK_FORMAT_PSX:
     	;
           }

           start_track = (i == 1) ? 0 : lsn;

           /* save the start of the data area */
           if (i == first_data)
     	data_start = start_track;

           /* skip tracks which belong to the current walked session */
           if (start_track < data_start + cdio_iso_analysis.isofs_size)
     	continue;

           fs = cdio_guess_cd_type(p_cdio, start_track, i, &cdio_iso_analysis);

           print_analysis(cdio_iso_analysis, fs, first_data, num_audio,
     		     i_tracks, first_track_num, p_cdio);

           if ( !(CDIO_FSTYPE(fs) == CDIO_FS_ISO_9660 ||
     	     CDIO_FSTYPE(fs) == CDIO_FS_ISO_HFS  ||
     	     CDIO_FSTYPE(fs) == CDIO_FS_ISO_9660_INTERACTIVE) )
     	/* no method for non-ISO9660 multisessions */
     	break;
         }
       }
       cdio_destroy(p_cdio);
       return 0;
     }

Example 4: use libiso9660 to extract a file from an ISO-9660 image
==================================================================

Next a program to show using libiso9660 to extract a file from an ISO-9660 image.  This can be found in the distribution as example/iso3.c. A more complete and expanded version of this is iso-read, part of this distribution.

     /* This is the ISO 9660 image. */
     #define ISO9660_IMAGE_PATH "../"
     #define ISO9660_IMAGE ISO9660_IMAGE_PATH "test/copying.iso"

     #define LOCAL_FILENAME "copying"

     #ifdef HAVE_CONFIG_H
     # include "config.h"
     #endif

     #include <sys/types.h>
     #include <cdio/cdio.h>
     #include <cdio/iso9660.h>

     #include <stdio.h>

     #ifdef HAVE_ERRNO_H
     #include <errno.h>
     #endif
     #ifdef HAVE_STRING_H
     #include <string.h>
     #endif
     #ifdef HAVE_UNISTD_H
     #include <unistd.h>
     #endif
     #ifdef HAVE_SYS_TYPES_H
     #include <sys/types.h>
     #endif

     #define my_exit(rc)				\
       fclose (p_outfd);				\
       free(p_statbuf);				\
       iso9660_close(p_iso);				\
       return rc;					\

     int
     main(int argc, const char *argv[])
     {
       iso9660_stat_t *p_statbuf;
       FILE *p_outfd;
       int i;

       iso9660_t *p_iso = iso9660_open (ISO9660_IMAGE);

       if (NULL == p_iso) {
         fprintf(stderr, "Sorry, couldn't open ISO 9660 image %s\n", ISO9660_IMAGE);
         return 1;
       }

       p_statbuf = iso9660_ifs_stat_translate (p_iso, LOCAL_FILENAME);

       if (NULL == p_statbuf)
         {
           fprintf(stderr,
     	      "Could not get ISO-9660 file information for file %s\n",
     	      LOCAL_FILENAME);
           iso9660_close(p_iso);
           return 2;
         }

       if (!(p_outfd = fopen (LOCAL_FILENAME, "wb")))
         {
           perror ("fopen()");
           free(p_statbuf);
           iso9660_close(p_iso);
           return 3;
         }

       /* Copy the blocks from the ISO-9660 filesystem to the local filesystem. */
       for (i = 0; i < p_statbuf->size; i += ISO_BLOCKSIZE)
         {
           char buf[ISO_BLOCKSIZE];

           memset (buf, 0, ISO_BLOCKSIZE);

           if ( ISO_BLOCKSIZE != iso9660_iso_seek_read (p_iso, buf, p_statbuf->lsn
     						   + (i / ISO_BLOCKSIZE),
     						   1) )
           {
     	fprintf(stderr, "Error reading ISO 9660 file at lsn %lu\n",
     		(long unsigned int) p_statbuf->lsn + (i / ISO_BLOCKSIZE));
     	my_exit(4);
           }

          fwrite (buf, ISO_BLOCKSIZE, 1, p_outfd);

          if (ferror (p_outfd))
             {
               perror ("fwrite()");
               my_exit(5);
             }
         }

       fflush (p_outfd);

       /* Make sure the file size has the exact same byte size. Without the
          truncate below, the file will a multiple of ISO_BLOCKSIZE.
        */
       if (ftruncate (fileno (p_outfd), p_statbuf->size))
         perror ("ftruncate()");

       my_exit(0);
     }

Example 5: list CD-Text and disc mode info
==========================================

Next a program to show using libcdio to list CD-TEXT data. This can be found in the distribution as example/cdtext.c.

     /* Simple program to list CD-Text info of a Compact Disc using libcdio. */
     #ifdef HAVE_CONFIG_H
     # include "config.h"
     #endif
     #include <stdio.h>
     #include <sys/types.h>
     #include <cdio/cdio.h>
     #include <cdio/cdtext.h>

     static void
     print_cdtext_track_info(CdIo_t *p_cdio, track_t i_track, const char *message) {
       const cdtext_t *cdtext    = cdio_get_cdtext(p_cdio, 0);
       if (NULL != cdtext) {
         cdtext_field_t i;

         printf("%s\n", message);

         for (i=0; i < MAX_CDTEXT_FIELDS; i++) {
           if (cdtext->field[i]) {
             printf("\t%s: %s\n", cdtext_field2str(i), cdtext->field[i]);
           }
         }
       }

     }

     static void
     print_disc_info(CdIo_t *p_cdio, track_t i_tracks, track_t i_first_track) {
       track_t i_last_track = i_first_track+i_tracks;
       discmode_t cd_discmode = cdio_get_discmode(p_cdio);

       printf("%s\n", discmode2str[cd_discmode]);

       print_cdtext_track_info(p_cdio, 0, "\nCD-Text for Disc:");
       for ( ; i_first_track < i_last_track; i_first_track++ ) {
         char psz_msg[50];
         sprintf(msg, "CD-Text for Track %d:", i_first_track);
         print_cdtext_track_info(p_cdio, i_first_track, psz_msg);
       }
     }

     int
     main(int argc, const char *argv[])
     {
       track_t i_first_track;
       track_t i_tracks;
       CdIo_t *p_cdio;
       cdio = cdio_open (NULL, DRIVER_UNKNOWN);
       i_first_track = cdio_get_first_track_num(p_cdio);
       i_tracks      = cdio_get_num_tracks(p_cdio);

       if (NULL == p_cdio) {
         printf("Couldn't find CD\n");
         return 1;
       } else {
         print_disc_info(p_cdio, i_tracks, i_first_track);
       }

       cdio_destroy(p_cdio);

       return 0;
     }

Example 6: Using MMC to run an INQURY command
=============================================

Now a program to show issuing a simple MMC command (INQUIRY). This MMC command retrieves the vendor, model and firmware revision number of a CD drive. For this command to work, usually a CD to be loaded into the drive; odd since the CD itself is not used.

This can be found in the distribution as example/mmc1.c.

     #ifdef HAVE_CONFIG_H
     # include "config.h"
     #endif
     #include <stdio.h>
     #include <sys/types.h>
     #include <cdio/cdio.h>
     #include <cdio/scsi_mmc.h>
     #include <string.h>

     /* Set how long to wait for MMC commands to complete */
     #define DEFAULT_TIMEOUT_MS 10000

     int
     main(int argc, const char *argv[])
     {
       CdIo_t *p_cdio;

       p_cdio = cdio_open (NULL, DRIVER_UNKNOWN);

       if (NULL == p_cdio) {
         printf("Couldn't find CD\n");
         return 1;
       } else {
         int i_status;                  /* Result of MMC command */
         char buf[36] = { 0, };         /* Place to hold returned data */
         scsi_mmc_cdb_t cdb = {{0, }};  /* Command Descriptor Buffer */

         CDIO_MMC_SET_COMMAND(cdb.field, CDIO_MMC_GPCMD_INQUIRY);
         cdb.field[4] = sizeof(buf);

         i_status = scsi_mmc_run_cmd(p_cdio, DEFAULT_TIMEOUT_MS,
     				&cdb, SCSI_MMC_DATA_READ,
     				sizeof(buf), &buf);
         if (i_status == 0) {
           char psz_vendor[CDIO_MMC_HW_VENDOR_LEN+1];
           char psz_model[CDIO_MMC_HW_MODEL_LEN+1];
           char psz_rev[CDIO_MMC_HW_REVISION_LEN+1];

           memcpy(psz_vendor, buf + 8, sizeof(psz_vendor)-1);
           psz_vendor[sizeof(psz_vendor)-1] = '\0';
           memcpy(psz_model,
     	     buf + 8 + CDIO_MMC_HW_VENDOR_LEN,
     	     sizeof(psz_model)-1);
           psz_model[sizeof(psz_model)-1] = '\0';
           memcpy(psz_rev,
     	     buf + 8 + CDIO_MMC_HW_VENDOR_LEN +CDIO_MMC_HW_MODEL_LEN,
     	     sizeof(psz_rev)-1);
           psz_rev[sizeof(psz_rev)-1] = '\0';

           printf("Vendor: %s\nModel: %s\nRevision: %s\n",
     	     psz_vendor, psz_model, psz_rev);
         } else {
           printf("Couldn't get INQUIRY data (vendor, model, and revision\n");
         }
       }

       cdio_destroy(p_cdio);

       return 0;
     }

Example 7: Using the CD Paranoia library for CD-DA reading
==========================================================

     #ifdef HAVE_CONFIG_H
     # include "config.h"
     #endif

     #include <cdio/cdda.h>
     #include <cdio/cd_types.h>
     #include <stdio.h>

     #ifdef HAVE_STDLIB_H
     #include <stdlib.h>
     #endif

     int
     main(int argc, const char *argv[])
     {
       cdrom_drive_t *d = NULL; /* Place to store handle given by cd-paranoia. */
       char **ppsz_cd_drives;   /* List of all drives with a loaded CDDA in it. */

       /* See if we can find a device with a loaded CD-DA in it. */
       ppsz_cd_drives = cdio_get_devices_with_cap(NULL, CDIO_FS_AUDIO, false);

       if (ppsz_cd_drives) {
         /* Found such a CD-ROM with a CD-DA loaded. Use the first drive in
            the list. */
         d=cdio_cddap_identify(*ppsz_cd_drives, 1, NULL);
       } else {
         printf("Unable find or access a CD-ROM drive with an audio CD in it.\n");
         exit(1);
       }

       /* Don't need a list of CD's with CD-DA's any more. */
       cdio_free_device_list(ppsz_cd_drives);

       /* We'll set for verbose paranoia messages. */
       cdio_cddap_verbose_set(d, CDDA_MESSAGE_PRINTIT, CDDA_MESSAGE_PRINTIT);

       if ( 0 != cdio_cddap_open(d) ) {
         printf("Unable to open disc.\n");
         exit(1);
       }

       /* Okay now set up to read up to the first 300 frames of the first
          audio track of the Audio CD. */
       {
         cdrom_paranoia_t *p = cdio_paranoia_init(d);
         lsn_t i_first_lsn = cdio_cddap_disc_firstsector(d);

         if ( -1 == i_first_lsn ) {
           printf("Trouble getting starting LSN\n");
         } else {
           lsn_t   i_cursor;
           track_t i_track    = cdio_cddap_sector_gettrack(d, i_first_lsn);
           lsn_t   i_last_lsn = cdio_cddap_track_lastsector(d, i_track);

           /* For demo purposes we'll read only 300 frames (about 4
     	 seconds).  We don't want this to take too long. On the other
     	 hand, I suppose it should be something close to a real test.
            */
           if ( i_last_lsn - i_first_lsn > 300) i_last_lsn = i_first_lsn + 299;

           printf("Reading track %d from LSN %ld to LSN %ld\n", i_track,
     	     (long int) i_first_lsn, (long int) i_last_lsn);

           /* Set reading mode for full paranoia, but allow skipping sectors. */
           paranoia_modeset(p, PARANOIA_MODE_FULL^PARANOIA_MODE_NEVERSKIP);

           paranoia_seek(p, i_first_lsn, SEEK_SET);

           for ( i_cursor = i_first_lsn; i_cursor <= i_last_lsn; i_cursor ++) {
     	/* read a sector */
     	int16_t *p_readbuf=cdio_paranoia_read(p, NULL);
     	char *psz_err=cdio_cddap_errors(d);
     	char *psz_mes=cdio_cddap_messages(d);

     	if (psz_mes || psz_err)
     	  printf("%s%s\n", psz_mes ? psz_mes: "", psz_err ? psz_err: "");

     	if (psz_err) free(psz_err);
     	if (psz_mes) free(psz_mes);
     	if( !p_readbuf ) {
     	  printf("paranoia read error. Stopping.\n");
     	  break;
     	}
           }
         }
         cdio_paranoia_free(p);
       }

       cdio_cdda_close(d);

       exit(0);
     }

Those who are die-hard cdparanoia programmers will notice that the libcdio paranoia names are similar but a little bit different. In particular instead of paranoia_read we have above cdio_paranoia_read and instead of cdda_open we have cdio_cddap_open.

This was done intentionally so that it is possible for the original paranoia program can co-exist both in source code and linked libraries and not conflict with libcdio's paranoia source and libraries.

In general in place of any paranoia routine that begins paranoia_, use cdio_paranoia_ and in place of any paranoia routine that begins cdda_, use cdio_cddap_. But for a limited time libcdio will accept the old paranoia names which may be useful for legacy paranoia code. The way this magic works is by defining the old paranoia name to be the libcdio name.

In the unusual case where you do want to use both the original paranoia and libcdio routines in a single source, the C preprocessor symbol DO_NOT_WANT_PARANOIA_COMPATIBILITY can be define'd and this disables the #define substitution done automatically. The may still be a problem with conflicting structure definitions like cdrom_drive_t.

A list of all sample programs in the example directory
======================================================

The example directory contains some simple examples of the use of the libcdio library.

A larger more-complicated example are the cd-drive, cd-info, cd-read, iso-info and iso-info programs in the src directory.

Descriptions of the sample are as follows...

cdchange.c

     A program to test if a CD has been changed since the last change test.

cdtext.c

     A program to show CD-Text and CD disc mode info.

drives.c

     A program to show drivers installed and what the default CD-ROM drive is and what CD drives are available.

eject.c

     A program eject a CD from a CD-ROM drive and then close the door again.

isolist.c

     A program to show using libiso9660 to list files in a directory of an ISO-9660 image.

C++/isolist.cpp

     The same program as isolist.c written in C++.

iso2.c

     A program to show using libiso9660 to extract a file from a CDRWIN cue/bin CD image.

C++/iso2.cpp

     The same program as iso2.c written in C++.

iso3.c

     A program to show using libiso9660 to extract a file from an ISO-9660 image.

C++/iso3.cpp

     The same program as iso3.c written in C++.

isofuzzy.c

     A program showing fuzzy ISO-9660 detection/reading.

mmc1.c

     A program to show issuing a simple MMC command (INQUIRY).

C++/mmc1.cpp

     The same program as mmc1.c written in C++.

mmc2.c

     A more involved MMC command to list CD and drive features from a SCSI-MMC GET_CONFIGURATION command.

mmc2a.c

     Prints MMC MODE_SENSE page 2A parameters. Page 2a are the CD/DVD Capabilities and Mechanical Status.

C++/mmc2.cpp

     The same program as mmc2.c written in C++.

paranoia.c

     A program to show using libcdio's version of the CD-DA paranoia.

paranoia2.c

     A program to show using libcdio's version of the CD-DA paranoia library. But in this version, we'll open a cdio object before calling paranoia's open. I imagine in many cases such as media players this may be what will be done since, one may want to get CDDB/CD-Text info beforehand.

tracks.c

     A simple program to list track numbers and logical sector numbers of a Compact Disc using libcdio.

sample2.c

     A simple program to show drivers installed and what the default CD-ROM drive is.

sample3.c

     A simple program to show the use of cdio_guess_cd_type().  Figures out the kind of CD image we've got.

sample4.c

     A slightly improved sample3 program: we handle cdio logging and take an optional CD-location.

udf1.c

     A program to show using libudf to list files in a directory of an UDF image.

udf2.c

     A program to show using libudf to extract a file from an UDF image.

Diagnostic programs: cd-drive, cd-info, cd-read, iso-info, iso-read
*******************************************************************

cd-drive
========

cd-drive lists out drive information, what features drive supports, and information about what hardware drivers are available.

cd-info
=======

cd-info will print out the structure of a CD medium which could either be a Compact Disc in a CD ROM or an CD image. It can try to analyze the medium to give characteristics of the medium, such as how many tracks are in the CD and the format of each track, whether a CD contains a Video CD, CD-DA, PhotoCD, whether a track has an ISO-9660 filesystem.

cd-read
=======

cd-info can be used to read blocks a CD medium which could either be a Compact Disc in a CD ROM or an CD image. You specify the beginning and ending LSN and what mode format to use in the reading.

iso-info
========

iso-info can be used to print out the structure of an ISO 9660 image.

iso-read
========

iso-read can be used to extract a file in an ISO-9660 image.

CD-ROM Access and Drivers
*************************

Multimedia Commands (MMC)
=========================

In contrast to the rest of the sections in this chapter, MMC (Multimedia commands) is not a driver per se, although many of the CD-ROM drivers do in fact issue MMC commands. MMC commands gives (in theory) a broad and uniform way to access a CD-ROM drive.

If your CD-ROM drive understands MMC commands this is probably gives the most flexibility in control. SCSI and ATAPI CD-ROM devices generally support a fairly large set of MMC commands.

The name ``SCSI MMC'' is often found in the literature in specifications and on the Internet. The ``SCSI'' part is probably a little bit misleading because a drive can understand ``SCSI MMC'' commands but not use a SCSI interface---ATAPI CD-ROMs are one such broad class of examples. In fact there are drivers to ``encapsulate'' non-SCSI drives or a non-MMC-compliant drives and make them act like MMC drives. I believe that many OS SCSI ``pass-through'' mechanisms do roughly the same thing.

The name ``SCSI MMC'' is no doubt due to the fact that these commands grew out of the SCSI command set and thus were bundled in them.

For clarity and precision we will use the term ``MMC'' rather than ``SCSI MMC''.

One of the problems with MMC is that there are so many different ``standards''. In particular there are MMC ftp://ftp.t10.org/t10/drafts/mmc/, MMC 2 ftp://ftp.t10.org/t10/drafts/mmc2/, MMC 3 ftp://ftp.t10.org/t10/drafts/mmc3/, MMC 4 ftp://ftp.t10.org/t10/drafts/mmc4/, and MMC 5 ftp://ftp.t10.org/t10/drafts/mmc5/ standards several ``drafts'' for each standard. The good news about ATAPI drives is that they too understand some sort of MMC subset. The bad news (as I understand it) is that they do not understand any full MMC command set.

Another problem with the MMC commands related to the variations in standards is the variation in the commands themselves and there are perhaps two or three ways to do many of the basic commands like read a CD frame.

There seems to be a fascination with the number of bytes a command takes in the MMC-specification world. (Size matters?) So often the name of an operation will have a suffix with the number of bytes of the command (actually in MMC jargon this is called a ``CDB'' or command descriptor block). So for example there is a 6-byte ``MODE SELECT'' often called ``MODE SELECT 6'' and a 10-byte ``MODE SELECT'' often called ``MODE SELECT 10''. Presumably the 6-byte command came first and it was discovered that there was some deficiency causing the longer command. In libcdio where there are two formats we add the suffix in the name, e.g. CDIO_MMC_GPCMD_MODE_SELECT_6 or CDIO_MMC_GPCMD_MODE_SELECT_10.

If the fascination and emphasis in the MMC specifications of CDB size is a bit odd, equally so is the fact that this too often has bled through at the OS programming API. However in libcdio, you just give the opcode in scsi_mmc_run_cmd() and we'll do the work to figure out how many bytes of the CDB are used.

Down the line it is hoped that libcdio will have a way to remove a distinction between the various alternative and alternative-size MMC commands. In cdio/scsi-mmc.h you will find a little bit of this for example via the routine scsi_mmc_get_drive_cap(). However much more work is needed.

GNU/Linux
=========

The GNU/Linux uses a hybrid of methods. Somethings are done vai ioctl and some things via MMC. GNU/Linux has a rather nice and complete ioctl mechanism. On the other hand, the MMC mechanism is more universal.  There are other ``access modes'' listed which are not really access modes and should probably be redone/rethought.  They are just different ways to run the read command. But for completeness These are ``READ_CD'' and ``READ_10''.

Microsoft Windows ioctl and ASPI
================================

There are two CD drive access methods on Microsoft Windows platforms: ioctl and ASPI.

The ASPI interface specification was developed by Adaptec for sending commands to a SCSI host adapter (such as those controlling CD and DVD drives) and used on Window 9x/NT and later. Emulation for ATAPI drives was added so that the same sets of commands worked those even though the drives might not be SCSI nor might there even be a SCSI controller attached.

However in Windows NT/2K/XP, Microsoft provides their Win32 ioctl interface, and has taken steps to make using ASPI more inaccessible (e.g. requiring administrative access to use ASPI).

Solaris ATAPI and SCSI
======================

There is currently only one CD drive access methods in Solaris: SCSI (called ``USCSI'' or ``user SCSI'' in Solaris). There used to be an ATAPI method and it could be resurrected if needed. USCSI was preferred since on newer releases of Solaris and Solaris environments one would needs to have root access for ATAPI.

FreeBSD ioctl and CAM
=====================

There are two CD drive access methods on Solaris: ioctl and CAM (common access method). CAM is preferred when possible, especially on newer releases. However CAM is right now sort of a hybrid and includes some ioctl code.

More work on this driver is needed. Volunteers?

OS X (non-exclusive access)
===========================

A problem with OS/X is that if the OS thinks it understands the drive it gains exclusive access to it and thus prevents a library like this to get non-exclusive access.

Currently libcdio access the CD-ROM non-exclusively. However in order to be able to issue MMC, the current belief is that exclusive access is needed. Probably in a future libcdio, there will be some way to specify which kind of access is desired (with the inherent consequences of each).

More work on this driver is needed. Volunteers?

Internal Program Organization
*****************************

file organization
-----------------

Here is a list of libcdio directories.

  * include/cdio

     This contains the headers that are public. One that will probably be used quite a bit is <cdio/cdio.h>.

  * lib

     Code for installed libraries. See below for further breakout

  * lib/driver

     Code for various OS-specific CD-ROM drivers, image drivers, and common MMC routines.

     This code comprises libcdio.a (or the shared version of it).

  * lib/iso9660

     Code for to extract or query ISO-9660 images.

     This code comprises libiso9660.a (or the shared version of it).

  * lib/paranoia

     This is from cdparanoia. It is the OS- and hardware- dependent code to detect and correct jitter for CD-DA CDs.

  * lib/cdda_interface

     This is also from cdparanoia. It is the OS- and hardware- independent code to detect and correct jitter for CD-DA CDs.

  * doc

     A home for fine documentation such as this masterpiece.

  * example

     Here you will find various small example programs using libcdio which are largely for pedagogical purposes. You might be able to find one that is similar to what you want to do that could be extended. In fact some these are contain the kernel ideas behind of some of the larger programs in src.

  * src

     Various stand-alone utility programs. See below.

  * src/paranoia

     libcdio's version of cdparanoia. Except for the fact that the back-end CD-reading code has been replaced by libcdio's routines the code is pretty much identical.

  * test

     Regression tests

libcdio
-------

libcdio exports one opaque type CdIo_t. Internally this a structure containing an enumeration for the driver, a structure containing function pointers and a generic ``environment'' pointer which is passed as a parameter on a function call. See lib/driver/cdio_private.h. The initialization routine for each driver sets up the function pointers and allocates memory for the environment. When a particular user-level cdio routine is called (e.g cdio_get_first_track_num for lib/driver/track.c), the environment pointer is passed to a device-specific routine which will then cast this pointer into something of the appropriate type.

Because function pointers are used, there can be and is quite a bit of sharing of common routines. Some of the common routines are found in the file lib/driver/_cdio_generic.c.

Another set of routines that one is likely to find shared amongst drivers are the MMC commands. These are located in lib/driver/scsi_mmc.c.

There is not only an attempt to share functions but we've tried to create a generic CD structure generic_img_private_t of file lib/driver/generic.h. By putting information into a common structure, we increase the likelihood of being able to have a common routine to perform some sort of function.

The generic CD structure would also be useful in a utility to convert one CD-image format to another. Basically the first image format is ``parsed'' into the common internal format and then from this structure it is not parsed.

libiso9660
----------

To be completed....

Coding Conventions
------------------

In libcdio there are a number of conventions used. If you understand some of these conventions it may facilitate understanding the code a little.

namespace names
...............

For the most part, the visible external libcdio names follow conventions so as not to be confused with other applications or libraries. If you understand these conventions, there will be little or no chance that the names you use will conflict with libcdio and libiso9660 and vice versa.

All of the external libcdio C routines start out with cdio_, e.g. cdio_open; as a corollary, the libcdio CD-Paranoia routines start cdio_cddap_, e.g. cdio_cddap_open.  libiso9660 routines start iso9660_, e.g. iso9660_open.

libcdio C-Preprocessor names generally start CDIO_, for example CDIO_CD_FRAMESIZE_RAW; libiso9660 C-preprocessor names start ISO9660_, e.g. ISO9660_FRAMESIZE.

suffixes (type and structure names)
...................................

A few suffixes are used in type and structure names:

  * _e

     An enumeration tag. Generally though the same name will appear with the _t suffix and probably that should be used instead.

  * _s

     A structure tag. Generally though the same name will appear with the _t suffix and probably that should be used instead.

  * _t

     A type suffix.

prefixes (variable names)
.........................

A number of prefixes are used in variable names here's what they mean

  * i_

     An integer type of some sort. A variable of this ilk one might find being iterated over in for loops or used as the index of an array for example.

  * b_

     A Boolean type of some sort. A variable of this ilk one might find being in an if condition for example.

  * p_

     A pointer of some sort. A variable of this ilk, say p_foo one is like likely to see *p_foo or p_foo->....

  * pp_

     A pointer to a pointer of some sort. A variable of this ilk, say pp_foo one is like likely to see **p_foo or p_foo[x][y] for example

  * psz_

     A char * pointer of some sort. A variable of this ilk, say psz_foo may be used in a string operation. For example printf(%s\n", psz_foo) or strdup(psz_foo).

  * ppsz_

     A pointer to a char * pointer of some sort. A variable of this ilk, say ppsz_foo is used for example to return a list of CD-ROM device names

There are a some other naming conventions. Generally if a routine name starts cdio_, e.g. cdio_open, then it is an externally visible routine in libcdio. If a name starts iso9660_, e.g. iso9660_is_dchar then it is an externally visible routine in libiso9660. If a name starts scsi_mmc_, e.g. scsi_mmc_get_discmode, then it is an externally visible MMC routine. (We don't have a separate library for this yet.

Names using entirely capital letters and that start CDIO_ are externally visible #defines.

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 _

Glossary
********

     [file glossary.texi not included]

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

     [file fdl.texi not included]