\input texinfo @c -*-texinfo-*-

@c %**start of header

@setfilename libcdio.info

@include version.texi

@settitle GNU @code{libcdio}: Compact Disc Input, Output, and Control Library

@c %**end of header

@c Karl Berry informs me that this will add straight quotes in

@c typewriter text.

@c See the "Inserting Quote Characters" node in the Texinfo manual

@set txicodequoteundirected

@set txicodequotebacktick

@copying

This manual documents @code{libcdio}, the GNU CD Input, Output, and Control

Library.

Copyright @copyright{} 2003-2008, 2010, 2012-2014 Rocky

Bernstein and Herbert Valerio Riedel.

@quotation

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''.

@end quotation

@end copying

@paragraphindent 0

@exampleindent 0

@set libcdio @code{libcdio}

@set program @kbd{libcdio}

@c A macro for defining terms variables.

@macro term{varname}

@c @cindex{\varname\}

@emph{\varname\}

@end macro

@dircategory Software libraries

@direntry

* libcdio: (libcdio).           GNU Compact Disc Input, Output, and Control Library.

@end direntry

@titlepage

@title GNU @code{libcdio}

@subtitle GNU Compact Disc Input, Output, and Control Library

@subtitle for version @value{VERSION}, @value{UPDATED}

@author Rocky Bernstein et al. (@email{bug-libcdio@@gnu.org})

@page

@vskip 0pt plus 1filll

@insertcopying

@end titlepage

@contents

@ifnottex

@node Top

@top GNU @value{libcdio}

@insertcopying

@menu

* History::           How this came about

* Previous Work::     The problem and previous work

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

* CD Formats::        A tour through the CD-specification spectrum

* CD Image Formats::  A tour through various CD-image formats

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

* How to use::        Okay enough babble, lemme at the library!

* Utility Programs::  Diagnostic programs that come with this library

* CD-ROM Access and Drivers::     CD-ROM access and drivers

* Internal Program Organization:: Looking under the hood

Appendices

* ISO-9660 Character Sets::

* Glossary::

* GNU Free Documentation License::

Indices

* General Index::       Overall index

@end menu

@end ifnottex

@node History

@chapter 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 @kbd{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: @code{xine},

@code{MPlayer}, and @code{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 @value{libcdio} rather than

@kbd{libvcdio}.

While on the topic of the name @value{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 @code{libcdi} that might be

confused with a particular CD format called CD-I.

Later on, the ISO-9660 filesystem handling component from

@kbd{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.

@node Previous Work

@chapter 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 @emph{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, @kbd{xmcd} by Ti Kan, was I think a bit better

than most in that it tried to @emph{encapsulate} the kinds of CD

control mechanisms, e.g.\ SCSI, Linux ioctl, Toshiba, in a "CD Audio

Device Interface Library" called @code{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.

@quotation

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

@end quotation

Many of the media players mentioned above do in fact can make use of

the SDL library but for @emph{video} output only. Because the encapsulation

is over @emph{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@"org 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

@value{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.@footnote{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.@footnote{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 @value{libcdio} we provide a common (and hopefully

simple) API to issue MMC commands.

@node Purpose

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

The library, @command{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, @command{libiso9660}, for working with

ISO-9660 filesystems.

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.

@command{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.@footnote{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.}

As a separate package under a separate GPL2 license are

@command{libcdio_paranoia}, and @command{libcdio_cdda} libraries for

applications which want to use cdparanoia's error-correction and

jitter detection.

The first use of the library in this package are the Video CD

authoring and ripping tools, VCDImager

(@url{http://vcdimager.org}). See

@url{http://www.gnu.org/software/libcdio/projects.html} for a list of

projects using @command{libcdio}.

A version of the CD-DA extraction tool cdparanoia,

@url{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

@command{cd-info} which displays CD information: number of tracks,

CD-format and if possible basic information about the format.  If

libcddb (@url{http://libcddb.sourceforge.net}) is available, the

@command{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 @command{cd-info} shows basic VCD

information.

Other utility programs in the libcdio package are:

@table @code

@item @code{cdda-player}

shows off @value{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.

@item @code{cd-drive}

shows what drivers are available and some basic properties of

cd-drives attached to the system. Media may have to be inserted

in order to get this info. The program also lists out drive capabilities

@item cd-read

performs low-level block reading of a CD or CD image

@item @code{iso-info}

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

sample output

@smallexample

iso-info version 0.82 x86_64-unknown-linux-gnu

Copyright (c) 2003, 2004, 2005, 2007, 2008 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...

Preparer   : K3b - Version 0.11.12

Publisher  : Rocky Bernstein

System     : LINUX

Volume     : K3b data project

Volume Set :

__________________________________

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

@end smallexample

@item @code{iso-read}

extracts files from an ISO-9660 image.

@item @code{mmc-tool}

a program for issuing some MMC commands

@end table

Historically, @code{libcdio} did not support write access to

drives. In conjunction with additional work in a separate project

@code{libburn}, Thomas Schmitt has modified @code{libcdio} to enable

sending SCSI write commands on some of the drivers. This enables other

programs like @code{libburn} to write to CD's, DVD's and Blu-Ray

discs.

For the OS drivers which are lacking write access, volunteers are

welcome.

@node CD Formats

@chapter CD Formats

Much of what I write in this section can be found elsewhere. See for

example @url{http://www.pctechguide.com/08cd-rom.htm} or

@url{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.

@menu

* Red Book::        Red Book (CD-DA) CD Text, CDDB

* Yellow Book::     Yellow Book (CD-ROM Digital Data)

* Green Book::      Green Book (CD-i)

* White Book::      White Book (DV, Video CD)

@end menu

@node Red Book

@section Red Book (CD-DA)

@cindex Red Book

@menu

* CD Text::         CD Text and CD+G

* CDDB::            Internet CD Database (CDDB)

@end menu

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'',

@cite{@url{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 @value{libcdio} when you you want to read an audio sector, you call

@code{cdio_read_audio_sector()} or @code{cdio_read_audio_sectors()}.

@cindex subchannel

In addition the the audio data ``channel'' a provision for other

information or @term{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 @term{CD+G}.

@node CD Text

@subsection CD Text, CD+G

@cindex CD Text

@cindex 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 graphical (e.g. Karaoke) information.  For an

alternative way to get album and track meta-data see @xref{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.  This information is stored as a

single block of data and is the format. 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.

CD Text information is stored in this area. The format that follows

the Interactive Text Transmission System (ITTS) 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.

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. CD+G (CD w/graphics) uses this method.

The methods for reading this data from a CD-ROM drive were first

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. Subsequently it has been encorporated

into the MMC specifications.

Not all drives support reading the RW subcodes from the program

area. However for those that do, @value{libcdio} provides a way to get

at this information via @code{cdtext_get()} and its friends.

There is a separate document in this distribution describing CD-Text

information and how it is encoded.

@node CDDB

@subsection Internet CD Database (CDDB)

@cindex 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 @value{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 (@url{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

(@url{http://libcddb.sourceforge.net} we suggest using that. Our

utility program @command{cd-info} will make use it if it is available

and it's what we use in our applications that need it.

@node Yellow Book

@section 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.

@menu

* ISO 9660::

* Mode 1::           Mode 1 Format

* Mode 2::           Mode 2 Format

@end menu

@node ISO 9660

@subsection ISO 9660

@cindex ISO 9660

@menu

* ISO 9660 Level 1::

* ISO 9660 Level 2::

* ISO 9660 Level 3::

* Joliet Extensions::

* Rock Ridge Extensions::

@end menu

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.

@node ISO 9660 Level 1

@subsubsection 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 @xref{ISO-9660 Character

Sets}.

@node ISO 9660 Level 2

@subsubsection ISO 9660 Level 2

Level 2 ISO 9660 allows far more flexibility in filenames, but isn't

usable on some systems, notably MS-DOS.

@node ISO 9660 Level 3

@subsubsection 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.

@node Joliet Extensions

@subsubsection Joliet Extensions

@cindex 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 @term{Primary Volume Descriptor} or @term{PVD}. The root of the

Joliet-encode filesystem is found in a Supplementary Volume

Descriptor or @term{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.

@node Rock Ridge Extensions

@subsubsection Rock Ridge Extensions

@cindex 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 @emph{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.

@node Mode 1

@subsection Mode 1 (2048 data bytes per sector)

@cindex Mode 1

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 @value{libcdio} when you you want to read a mode1

sector you call the @code{cdio_read_mode1_sector()} or

@code{cdio_read_mode1_sectors()}.

@node Mode 2

@subsection Mode 2 (2336 data bytes per sector)

@cindex Mode 2

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 @value{libcdio} when you you want to read a mode1

sector you call the @code{cdio_read_mode2_sector()} or

@code{cdio_read_mode2_sectors()}.

@node Green Book

@section Green Book (CD-i)

@cindex Green Book

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.

@node White Book

@section White Book (DV, Video CD)

@cindex Green 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 @value{libcdio} when you you want to read a mode2 format 2 audio

sector you call the @code{cdio_read_mode2_sector()} or

@code{cdio_read_mode2_sectors()} setting @code{b_form2} to @code{true}.

@node CD Image Formats

@chapter CD Image Formats

@menu

* CDRDAO TOC Format::

* CDRWIN BIN/CUE Format::

* NRG Format::

@end menu

In both the @command{cdrdao} and bin/cue formats there is one meta-file with

extensions @code{.toc} or @code{.cue} respectively and one or more

files (often with the extension @code{.bin}) which contains the

content of tracks. The format of the track data is often

interchangeable between the two formats.  For example, in

@value{libcdio}'s regression tests we make use of this to reduce the

size of the test data and just provide alternate meta-data files

(@code{.toc} or @code{.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 @value{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.

@node CDRDAO TOC Format

@section CDRDAO TOC Format

This is @command{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 @value{libcdio} as the BIN/CUE format.)

The @emph{toc}-file describes what data is written to the media in the

@acronym{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 @cite{cdrdao(1) manual page}, contains more information about this

format.

@subsection 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.

@example

#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 ]*"

@end example

@example

<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> )* "@}"

@end example

@node  CDRWIN BIN/CUE Format

@section CDRWIN BIN/CUE Format

@cindex BIN/CUE, CD Image Format

The format referred to as @emph{CDRWIN BIN/CUE Format} in this manual

is a popular CD image format used in the @acronym{PC} world. Not

unlike @command{cdrdao}'s TOC file, the @emph{cue} file describes the

track layout, i.e. how the sectors are to be placed on the CD

media. The @emph{cue} file usually contains a reference to a file

traditionally having the @file{.bin} extension in its filename, the

@emph{bin} file. This @emph{bin} file contains the sector data payload

which is to be written to the CD medium according to the description

in the @emph{cue} file.

The following is an attempt to describe the subset of the @file{.cue}

file syntax used in @value{libcdio} and vcdimager in an EBNF-like

notation:

@subsection BIN/CUE Grammar

@example

@cartouche

<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>

@end cartouche

@end example

@node  NRG Format

@section NRG Format

@cindex Nero NRG, CD-Image format

The format referred to as @emph{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 @command{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.

@node CD Units

@chapter The units that make up a CD

@menu

* Tracks::   Tracks

* Sectors::  Block addressing (MSF, LSN, LBA)

* Pre-gaps::  Track pre-gaps

@end menu

@node Tracks

@section tracks --- disc subdivisions

@cindex track

@cindex gaps