libcdio
This manual documents
libcdio, the GNU CD Input, Output, and Control
Library.
Copyright © 2003-2008, 2010, 2012-2014 Rocky Bernstein and Herbert Valerio Ried”.
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.
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, e.g.\ SCSI, Linux ioctl, Toshiba, 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.(1)
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.(2) 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.
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.
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.(3)
As a separate package under a separate GPL2 license are
libcdio_paranoia, and
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
(). See for a list of
projects using
libcdio.
A version of the CD-DA extraction tool cdparanoia,, and its library which corrects for CD-ROM jitter are part of the distribution.:
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. Media may have to be inserted in order to get this info. The program also 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-read
extracts files from an ISO-9660 image.
mmc-tool
a program for issuing some MMC commands
Historically,
libcdio did not support write access to
drives. In conjunction with additional work in a separate project
libburn, Thomas Schmitt has modified
libcdio to enable
sending SCSI write commands on some of the drivers. This enables other
programs like
libburn to write to CD’s, DVD’s and Blu-Ray
discs.
For the OS drivers which are lacking write access, volunteers are welcome.
Much of what I write in this section can be found elsewhere. See for example or
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.
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”,. 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 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 See section Internet CD Database (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,
libcdio provides a way to get
at this information via
cdtext_get() and its friends.
There is a separate document in this distribution describing CD-Text information and how it is encoded.
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 ( 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
( 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.
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.
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.
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 See section ISO-9660 Character Sets.
Level 2 ISO 9660 allows far more flexibility in filenames, but isn’t usable on some systems, notably MS-DOS.
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 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.
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 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 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().
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.
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.
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.
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.
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.
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:
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.
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.
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.(4) 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.
A simpler way to address a block is to use a “Logical Sector Number” (LSN) or a “Logical Sector Number” (LBA). In the MMC-5 glossary these are synonymous terms. However historically it has been used differently. In libcdio, to convert a LBA into an LSN you just subtract 150. Both LBA’s and LSN’s can be negative.
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.
The preceding section on track pre-gaps and CD-DA was contributed by Robert William Fuller (hydrologiccycle@gmail.com).
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
See section Diagnostic programs:
cd-drive,
cd-info,
cd-read,
iso-info,
iso-read.
<cdio/cdio.h>
libcdio installs
<cdio/cdio_config.h>. This file contains all of
the C Preprocessor values from
config.h (created by configure).
This header can be used to consult exactly how libcdio was built. Initially I had selected “interesting” values, but this became too hard to maintain.
One set of values that libdio needs internally is the whether the CPU
that was used to compile libcdio is BigEndian or not; it can get this
from libcdio’s
config.h which is not installed and preferred or
cdio/cdio_config.h.
Some of the libcdio programs like the demo programs include
config.h for the generic reasons that the configuration-created
config.h file is used: to figure out what headers are available.
For example, do we have
<unistd.h>?
The file
config.h is generated by an autotools-generated
configure script. It doesn’t check to see if it has been included
previously.
Later, the demo programs include
<cdio.h> to get libcdio headers.
But because libcdio needs some of the same information like the BigEndian
value, this creates a duplicate include.
The way I get around this in the demo programs is by defining
__CDIO_CONFIG_H__ after
including
config.h as follows:
Applications using libcdio may find it handy to do something like this as well.
Defining
__CDIO_CONFIG_H__ will make sure
config_cdio.h
which is internally used, doesn’t try to redefine preprocessor symbols.
Ok. But now what about the problem that there are common preprocessor
symbols in
config_cdio.h that an application may want to define in a
different manner, like
PACKAGE_NAME?
For this, there is yet another header,
<cdio/cdio_unconfig.h>.
This file undefines any symbol that
config.h defines. And now we
bounce to the problem that there may be symbols that are normally
defined (
HAVE_UNISTD_H) and you want to keep that way, but others that
you don’t. So here is what I suggest:
The solution isn’t the most simple or natural, but programming sometimes can be difficult. If someone has a better solution, let me know.
Between header files
cdio_config.h and
cdio_unconfig.h and
all the fact that almost all headers(5) define a symbol to indicate they
have been included, I think there is enough mechanism to cover most
situations that may arise.
Here we will give an annotated example which can be found in the distribution as ‘example/tracks.c’.
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:
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.
One thing that’s a bit hockey 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.
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’.
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/isofile.c’. A more complete and expanded version of this
is
iso-read, part of this distribution.
Next a program to show using
libcdio to list CD-TEXT data.
This can be found in the distribution as ‘example/cdtext.c’.
INQURYcommand
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’.
Note the include of
#define of
__CDIO_CONFIG_H__ towards
the beginning. This is useful if the prior
#include of
config.h refers to libcdio’s configuration header. It indicates
that libcdio’s configuration settings have been used. Without it, you
may get messages about C Preprocessor symbols getting redefined in the
#include of
<cdio.cdio.h>.
The below program reads CD-DA data. For a more complete program to add a WAV header so that the CD can be played from a copy on a hard disk, see the corresponding distribution program.
This can be found in the distribution as ‘example/paranoia.c’.
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.
Sometimes in tracking down a problem in your code or libcdio’s you may
want more information about what is going on inside the
libcdio library.
The setting global variable
cdio_loglevel_default defined in
header file
<cdio/logging.h> controls the verbosity level. By
default, only warnings, errors, and fatal errors are printed. However
by setting this variable you can get either debug or informational
messages, or cause the normal messages that appear to be suppressed.
The verbosity levels defined in the library are from lowest number to highest are:
CDIO_LOG_DEBUG(value 1)
These are of a debugging nature and are give the most verbose output.
CDIO_LOG_INFO(value 2)
These are informational message.
CDIO_LOG_WARN(value 3)
These are warning message. Not an error, per se, but something that might be of concern.
CDIO_LOG_ERROR(value 4)
These are error messages that force program termination.
CDIO_LOG_ASSERT(value 5)
These are error messages that represent an internal inconsistency in
the
libcdio library. In the absence of
libcdio
bugs, these should never appear.
Setting a lower or more verbose log level will cause higher-level
messages to appear, but not those that are less than the set verbosity
level. The “debug” level is the lowest. So setting
cdio_loglevel_default to level causes all other levels of
messages to be displayed. However setting the verbosity level to
“warn” will cause debug and informational messages (lower
level messages) to be ignored while still showing warning, error, and
fatal error messages.
Another thing that can be done is to write a custom log handler that
will be used instead of
libcdio’s default handlers. Using
this, you have complete control of how you want logging to be handled.
Here is an example adapted from example program
logging.c.
exampledirectory
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...
audio.c
A program to show audio controls.
cdchange.c
A program to test if a CD has been changed since the last change test.
cd-eject.c
A a stripped-down "eject" command to open or close a CD-ROM tray.
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.
isofile.c
A program to show using libiso9660 to extract a file from an ISO-9660 image.
isofile2.c
A program to show using libiso9660 to extract a file from a CDRWIN cue/bin CD image.
C++/isofile2.cpp
The same program as
isofile2.c written in C++.
isofuzzy.c
A program showing fuzzy ISO-9660 detection/reading.
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++.
C++/isolist.cpp
The same program as
isolist.c written in C++.
isofuzzy.c
A program showing fuzzy ISO-9660 detection/reading.
logging.c
A program to show to to set log verbosity levels and how to write a custom log handler.
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.
cd-drive,
cd-info,
cd-read,
iso-info,
iso-read
‘cd-drive’ lists out drive information, what features drive supports, and information about what hardware drivers are available.
‘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-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’ can be used to print out the structure of an ISO 9660 image.
‘iso-read’ can be used to extract a file in an ISO-9660 image.
Historically, SCSI referred to a class of hardware devices and device controllers, bus technology and the data cables and protocols which attached to such devices. This is now called “Parallel SCSI”.
A specification standard grew out of the commands that controlled such SCSI devices, but now covers a wider variety of bus technologies including Parallel SCSI, ATA/ATAPI, Serial ATA, Universal Serial Bus (USB versions 1.1 and 2.0), and High Performance Serial Bus (IEEE 1394, 1394A, and 1394B).
Another similar class of hardware devices and controllers is called ATA and a command interface to that is called ATAPI (ATA Packetized Interface). ATAPI provides a mechanism for transferring and executing SCSI commands.
MMC (Multimedia commands) is a specification which adds special SCSI commands for CD, DVD, Blu-Ray devices.
If your optical drive understands MMC commands as most do nowadays, this probably gives the most flexibility in control. SCSI and ATAPI CD-ROM devices generally support a fairly large set of MMC commands. Unfortunately, on most Operating Systems one may need to do some additional setup, such as install drivers or modules, to allow access in this manner.
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 bus protocol—ATAPI CD-ROMs are one such broad class of examples. In fact there are drivers to “encapsulate” non-SCSI drives to make them act like more like SCSI drives, such as by adding SCSI address naming.
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:
along with the several “drafts” of these.
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.
Finally, in
libcdio there is a driver access mode (not a
driver) called “MMC”. It tells the specific drivers to use MMC
commands instead of other OS-specific mechanisms.
There are serveral ways that you can open a CD-ROM drive for subsequent use. Each way is called an access mode. Historically libcdio only supported a reading kind of access.
Adding the abilty to writing to a drive for “burning” is being added
by Thomas Schmitt, and this is accomplished by opening the drive in a
read-write mode. Currently writing modes are only supported via the
MMC command interface. Under this, one can get exclusive read-write
access or non-exclusive read-write access. The names of these two
modes are
MMC_RDWR_EXCL and
MMC_RDWR respectively.
On various OS’s often there are two kinds of read modes that are
supported, one which uses MMC commands and one which uses some sort of
OS-specific native command interface. For example on Unix, there is
often a access mode associated with issuing an device-specific
ioctl’s that the OS supports.
To specify a particular kind of access mode, use
cdio_open_am
which is like
cdio_open but it requires one to specify an
access mode.
cdio_get_arg
Once a driver is opened, you can use call
cdio_get_arg to get
information about the driver. Each driver can have specific features
that can be queried, but there are features that are common to all
drivers. These are listed below:
access-mode
This returns a string which is the name of the access mode in use.
mmc-supported?
This returns a string “true” or “false” depending whether the driver with this access mode support MMC commands.
scsi-tuple
On drivers that support MMC commands, this returns the SCSI name or a faked-up SCSI name that ripping front ends typically use.
The GNU/Linux uses a hybrid of methods. Somethings are done via 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”.
Writing/burning to a drive is supported via access modes
MMC_RDWR_EXCL or
MMC_RDWR.
There are two CD drive access methods on Microsoft Windows platforms: ioctl and ASPI.. The DLL is not part of Microsoft Windows and has to be downloaded and installed separately.
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).
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 need to have root access for ATAPI.
There are two classes of access methods on FreeBSD: 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.
Writing/burning to a drive is supported via access modes
MMC_RDWR_EXCL or
MMC_RDWR which underneath use CAM access.
A problem with libcdio on OS/X is that if the OS thinks it understands the drive, it will get exclusive access to the drive and thus prevents a library like this from obtaining 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?
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
test/data
Disk images and image meta-data used in tests
test/driver
Unit tests centered around the libcdio library (
libcdio, source
location
lib/driver
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.
This library is intended to give access CD-DA disks using Monty’s cd-paranoia library underneath.
To be completed....
This library is intended to give access Monty’s cd-paranoia library. It is the gap detection and jitter correction part without the part dealing with CD-DA reading.
To be completed....
This library is intended to give access and manipulate a ISO-9600 file image. One part of it is concerned with the the entire ISO-9660 file system image, and the other part access routines for manipulating data structures and fields that go into such an image.
To be completed....
This library is intended to give access and manipulate a UDF file image.
To be completed....
In
libcdio there are a number of conventions used. If you
understand some of these conventions it may facilitate understanding
the code a little.
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.
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.
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.
For a description of where are used see See section ISO 9660 Level 1.
Thomas Schmitt has made significant contributions to this glossary. See also.
See Win32 ASPI
Advanced Technology Attachment (ATA). The same thing as IDE.
Advanced Technology Attachment (ATA) Packet Interface. The interface provides a mechanism for transferring and executing SCSI CDBs on IDE CD Drives and DVD Drives.
IDE (also called ATA) was originally designed for hard drives only, but with help of ATAPI it is possible to connect other devices, in particular CD-ROMS to the IDE/EIDE connections.
The ATAPI CD-ROM drives understand a subset of SCSI commands. In particular multi-initiator commands are neither needed nor defined for ATAPI devices.
A CD-image format developed by Jeff Arnold for CDRWIN software on
Microsoft Windows. Many other programs subsequently support using this
format. The
.CUE file is a text file which contains CD format
and track layout information, while the
.BIN file holds the
actual data of each track.
Optical media with capacity of 25 GB as single layer and 50 GB as double layer. See also see "Media models and profiles".
Compact Disc. Capacity up to 900 MB. See also see "Media models and profiles".
Compact Disc Digital Audio, described in the “Red Book” or IEC 60908 (formerly IEC 908). This commonly referred to as an audio CD and what most people think of when you play a CD as it was the first to use the CD medium.
See
Compact Disc + Graphics. An extension of the CD audio format contains a limited amount of graphics in subcode channels. This disc works in all audio players but the graphics portion is only available in a special CD+G or Karaoke player.
Compact Disc Interactive. An extension of the CD format designed around a set-top computer that connects to a TV to provide interactive home entertainment, including digital audio and video, video games, and software applications. Defined by the “Green Book” standard.. CD-i for video and video music has largely (if not totally) been superseded by VCDs.
A standard allowing CD-ROM XA discs to play on CD-i. Kodak PhotoCDs are CD-XA Bridge discs.
Compact Disc Read Only Memory or “Yellow Book” describe in Standards ISO/IEC 10149. The data stored on it can be either in the form of audio, computer or video files.
The Yellow Book specifies two types of tracks, Mode 1 and Mode 2. Mode 1 is used for computer data and text and has an extra error correction layer. Mode 2 is for audio and video data and has no extra correction layer. CD-ROM/XA An expansion of the CD-ROM Mode 2 format that allows both computer and audio/video to be mixed in the same track.
CD Text is a technology developed by Sony Corporation and Philips Electronics in 1996 that allows storing in an audio CD and its tracks information such as artist name, title, songwriter, composer, or arranger. Commercially available audio CDs sometimes contain CD Text information.
Information on how CD Text is stored can be found in in older MMC standards. Specifically, try “Annex J” of “mmc3r10g.pdf”.
An “Unofficial CD Text FAQ” is at
CD-ROM EXtended Architecture. read CD-XA discs even if its own ‘Green Book’ file system only resembles ISO 9660 and isn’t fully compatible.
Digital Versatile Disc. Capacity up to 4.5 GB as single layer and 8.5 GB as double layer media. See also see "Media models and profiles".
A method to compensate small amounts of bad spots on media by replacing them out of a pool of reserve blocks and performing address translation. The necessary checkreading slows down write performance by a factor of 2 or 3. Defect management applies by default to DVD-RAM and BD-RE. Optionally it can be formatted onto CD-RW and DVD+RW, where it has the name "Mount Rainier". Sequential BD-R can be formatted for defect management too.
The data structure that is used to issue an ATAPI command. It contains a SCSI Command Descriptor Block (CDB).
( is a freely available specification which is technically identical to ISO 9660.
( is a freely available specification which is also approved as ISO 13346. It serves as base for UDF.
( is a freely available specification which is also approved as ISO 13490.
Free Software Foundation,
GNU is not UNIX,
Integrated Drive Electronics. This is a commonly used interface for hard disk drives and CD-ROM drives. It is less expensive than SCSI, but offers slightly less in terms of performance.
International Standards Organization.
ISO 13346 / ECMA-167 is a filesystem framework for data exchange on overwriteable or pseudo-overwriteable media. It serves as base of UDF.
ISO 13490 / ECMA-168 is an attempt to replace ISO 9660 by a format that allows finer write granularity and representation of typical disk file properties. It resembles ECMA-167 which led to UDF.
ISO 9660 / ECMA-119 is an operating-system independent filesystem format originally intended for CD-ROM media. It was standardized in 1988 and replaced the High Sierra standard for the logical format on CD-ROM media (ISO 9660 and High Sierra are identical in content, but the exact format is different). ISO 9660 and ECMA-119 are technically identical meanwhile.. Level 3 allows data file sizes to be 4 GB or larger. File data content is stored in extents, i.e. contiguous sequences of blocks. A single extent can hold only up to 2 exp 32 - 1 bytes. So files of 4 GB or larger need more than one extent to be stored. Older operating systems might have trouble with multi-extent files.
This ISO-9660 upward-compatible standard was developed for Windows 95 and Windows NT by Microsoft as an extension of ISO 9600 which allows the use of Unicode characters and supports file names up to 64 characters.
See for the Joliet Specification.
The name Joliet comes from the city in Illinois (U.S) that the standard was defined.
Logical Block Addressing. Mapped integer numbers from CD Red Book Addressing MSF. The starting sector is -150 and ending sector is 449849, which correlates directly to MSF: 00:00:00 to 99:59:74. Because an LBA is a single number it is often easier to work with in programming than an MSF.
The area of a CD where the Table Of Contents (TOC) and CD Text are stored. I think it is supposed to be around 4500 (1 min) or more sectors in length. On a CDR(W) the lead-in length is variable, because manufacturers have a different starting position indicated by the ATIP start of lead-in position that is recorded in the ATIP groove on the disk. For example:
97:27:00, 97:27:06, 97:27:66
97:34:21 to 97:34:25
Logical Sector Number. Mapped integer numbers from CD Red Book Addressing MSF. The starting sector is 0 and ending sector is 449699, which correlates to MSF: 00:00:00 to 99:59:74. Because an LSN is a single number it is often easier to work with in programming than an MSF. Because it starts at 0 rather than -150 as is the case of an LBA it can be represented as an unsigned value.
Media Catalog Number. A identification number on an audio CD. Also called a UPC. Another identification number is ISRC.
MMC (Multimedia Commands).
MMC are raw commands for communicating with CDROM drives, CD-Rewriters, DVD-Rewriters, etc. The are subset of the larger SCSI command set. See also see SCSI.
Many manufacturers have adopted this standard and it also applies to ATAPI versions of their drives.
The documents
libcdio makes use of are described in the
Multi-Media Commands standard (MMC). This document generally has a
numeric level number appended. For example MMC-5 refers to
“Multi-Media Commands - 5.
MMC classifies media as models, which describe their logical structure, and as profiles, which describe the capabilities of the drive with the particular media. So both are closely related but not identical.
There are three model families: CD, DVD, Blu-ray. CD allows special sector formats like audio as well as data sectors of 2048 bytes. DVD and Blu-ray only record data sectors.
Profiles depend on drive type and media state. They are expressed as numbers. It is unfortunate that formatted CD-RW have the same profile number as unformatted ones.
ROM drives often announce all media as ROM profiles. Some writer drives show closed sequential media as ROM profile.
Sequentially recordable profiles allow multisession in most cases. Special burn programs are needed for writing to them.
They can assume three states:
CD-RW and DVD-RW can be brought back to blank state, or they can be formatted to become overwriteable.
Overwriteable profiles allow random read-write access with a granularity of 2 kB or 32 kB. One can hope for having read-write access via the normal POSIX operations lseek(), read(), write() of the operating system.
BD-R profile 0x42 is defined by MMC but not implemented by the consumer priced Blu-ray burners as of year 2010.
A Mixed Mode is a CD that contains tracks of differing CD-ROM Mode formats. In particular the first track may contain both computer data (Yellow Book) CD ROM data while the remaining tracks are audio or video data. Video CD’s can be Mixed Mode CDs.
A way of writing to a CD , DVD or Blu-ray Disc that allows more data to be added to readable discs at a later time. The media must not have been closed by the previous write session. This applies originally to unformatted CD-R, CD-RW, DVD-R, DVD-RW, DVD+R, and sequential BD-R which all can record more than one session. They hold a table-of-content with sessions and tracks. Formatted CD-RW, DVD-RAM, DVD+RW, DVD-RW, and BD-RE have only one track. Multisession on these media needs help by the recorded data formats.
Multisession can be used to add a changeset to an existing ISO 9660 filesystem. Typically the add-on session contains a whole new filesystem tree with old and new files. It also contains the data blocks of the newly introduced or freshly overwritten files. The convention for mounting multisession ISO 9660 images is to load the superblock from the start of the first track in the last session as listed in the media table-of-content. Formatted media are assumed to have a single track starting at block 0. So ISO 9660 multisession on formatted media has to overwrite the volume descriptors at block 16 ff. with every new session. A chain of recognizable sessions can be achieved by starting the first ISO 9660 image at block 32 so that its descriptors get not overwritten later.
A proprietary CD image file format use by a popular program for Microsoft Windows, Ahead Nero. The specification of this format is not to our knowledge published.
An extension to the ISO-9660 standard which adds POSIX information to files.
It allows long file names, owner, group, access permissions
ugo+-rwx,
inode numbers, hard-link count, file types other than directory or regular
file. Rock Ridge is described by unapproved standard IEEE P1282 / RRIP-1.12
and based on unapproved IEEE P1281 / SUSP-1.10. It has become a de-facto
standard on X/Open systems like GNU/Linux, FreeBSD, Solaris, et.\ al.
Small Computer System Interface. A set of ANSI standard electronic interfaces (originally developed at Apple Computer) that allow personal computers to communicate with peripheral hardware such as CD-ROM drives, disk drives, printers, etc.
Although the original hardware is outdated since years, the SCSI command set nowadays controls most storage devices including all optical disc drives. The contemporary electronic technologies which transport SCSI commands to optical drives are P-ATA, SATA, and USB.
A SCSI programming specification made by the SCSI committee T10 organization.
The documents
libcdio makes use of are described in SCSI
standards documents SCSI Primary Commands (SPC), SCSI Block Commands
(SBC), and Multi-Media Commands (MMC). These documents generally have
a numeric level number appended. For example SPC-3 refers to
“SCSI Primary Commands - 3’.
In year 2010 the current versions were SPC-3, SBC-2, MMC-5.
SCSI Command Descriptor Block. The data structure that is used to issue a SCSI command.
Yet another way of issuing MMC commands for accessing a CD-ROM. As with MMC or ASPI, the CD-ROM doesn’t necessarily have to be a SCSI-attached drive. See also see MMC and see ASPI.
A fully readable complete recording that contains one or more tracks of computer data or audio on a CD. On a DVD or Blu-ray Disc, there are only data sessions.
Super VCD
An improvement of Video CD 2.0 specification which includes most notably a switch from MPEG-1 (constant bit rate encoding) to MPEG-2 (variable bit rate encoding) for the video stream.
Also added was higher video-stream resolution, up to 4 overlay graphics and text (OGT) sub-channels for user switchable subtitle displaying, closed caption text, and command lists for controlling the SVCD virtual machine.
See
(Compact Disc) Table of Contents. The TOC contains a list of sessions and their tracks. For sessions, it records the starting track number and the last track number. For tracks it records starting time block address, size, copy protection, linear audio preemphasis, track format (CDDA or data) in that order. Session and track information is also available on sequential DVD and Blu-ray Discs. Several track properties are fixed to equivalents of CD data.
A unit of data of a CD. The size of a track can vary; it can occupy the entire contents of the CD. Most CD standards however require that tracks have a 150 frame (or “2 second”) lead-in gap.
An abstraction of tracks for CD, DVD and Blu-ray Discs is the Logical Track as of MMC specs. Overwriteable media have a single logical track, sequential media can have one or more logical tracks which they describe in their TOC.
Universal Disc Format was designed as successor of ISO 9660. It allows to record long file names and advanced file properties. Although intended as format for data exchange its main importance is with DVD video players. Video DVDs have to bear a simple UDF filesystem with a prescribed set of files.
The Video Compact Disc (Video CD or VCD) is a standardized digital video storage format. It is based on the commonly available Compact Disc technology, which allows for low-cost video authoring. Video CD’s can be played in most DVD standalone player, dedicated VCD players and finally, modern Personal Computers with multimedia support.
A Video CD is made up of CD-ROM XA sectors, i.e. CD-ROM mode 2 form 1 & 2 sectors. Non-MPEG data is stored in mode 2 form 1 sectors with a user data area of 2048 byte, which have a similar L2 error correction and detection (ECC/EDC) to CD-ROM mode 1 sectors. While real-time MPEG streams is stored in CD-ROM mode 2 form 2 sectors, which by have no L2 ECC, yield a ~14% greater user data area consisting of 2324 bytes(6).
However in Windows NT/2K/XP, Microsoft provides their Win32 ioctl interface, and has take steps to make using ASPI more inaccessible (e.g. requiring administrative access to use ASPI).
See also see MMC.
Ioctl (Input Output ConTroLs). A Win32 function, implemented in all Microsoft Windows. It is used for sending commands to devices using defined codes and structures.
See CD-ROM XA..
And I’m thankful for that since, at least for MMC commands, it is inordinately complicated and in some places arcane.
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
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.
Perhaps this is a
libcdio design
flaw. It was originally done I guess because it was convenient for
VCDs.
<cdio_unconfig.h> is
one of the few headers that doesn’t set a preprocessor symbol: it does
its thing every time it is
#included
actually raw mode 2 sectors have a 2336 byte user data area, but parts of it are used for error codes and headers when using the mode 2 form 1 or form 2 configurations.
<cdio/cdio.h>
INQURYcommand
exampledirectory
cd-drive,
cd-info,
cd-read,
iso-info,
iso-read
cdio_get_arg
This document was generated by b on September 29, 2014 using texi2html 1.82.
The buttons in the navigation panels have the following meaning:
where the Example assumes that the current position is at Subsubsection One-Two-Three of a document of the following structure:
This document was generated by b on September 29, 2014 using texi2html 1.82.