Cdrtools-3.0-final is out: Cdrtools-3.0 release announcement
Cdrtools-3.0 release notes
This is the last result of the logo contest. All current logos are on this page
OSSCC we collaborate with you
Cdrtools - Highly portable CD/DVD/BluRay command line recording software
Cdrtools is a set of command line programs that allows to record CD/DVD/BluRay media.
Cdrecord started in December 1995. On 4 February 1996 cdrecord was initially published as OpenSource, on 4 February 2021 we celebrate the 25th anniversary of cdrecord as OSS.
In June 1986 the SunOS scg driver and libscg was initially written, in June 2021 we celebrate the 35th anniversary for the SCSI pass through concept.
The suite includes the following programs:
- cdrecord A CD/DVD/BD recording program
- readcd A program to read CD/DVD/BD media with CD-clone features
- cdda2wav The most evolved CD-audio extraction program with paranoia support
- mkisofs A program to create hybrid ISO9660/JOLIET/HFS filesystes with optional Rock Ridge attributes
- isodebug A program to print mkisofs debug information from media
- isodump A program to dump ISO-9660 media
- isoinfo A program to analyse/verify ISO/9660/Joliet/Rock-Ridge Filesystems
- isovfy A program to verify the ISO-9660 structures
- rscsi A Remote SCSI enabling daemon
Cdrtools is a set of 100% free true OpenSource programs
that follow the definitions from OSI (originally written by Bruce Perens).
Cdrtools is under constant free and open development since February 1996.
The goal for cdrtools development is to
permanently provide a free suite of programs
for writing CD/DVD/BD media and succeeding similar products (like e.g. HD-DVD).
Since more than 19 years and differently from the dead forks from this suite,
the original software points out that permanent
development to the benefit of the users is the intention of this project.
Warning: users on Linux distributions please read this information on bugs and license problems.
Use the most recent original software to avoid bugs and license problems.
Cdrtools device naming
Cdrtools are based on libscg (the world's first SCSI Pass Through Interface library, created in 1986).
Libscg allows to send arbitrary SCSI commands to arbitrary devices and libscg supports 28 different OS platforms.
The vast majority of these platforms have no way to access SCSI devices via /dev/* based device nodes.
The 5 platforms: AIX, Solaris, Linux, NetBSD, SCO OpenServer are the exceptions that support /dev/*
but together they only have aprox. 1% coverage on the installed computer base of the world.
Common platforms like Microsoft Windows and OS X (the latter is a POSIX certified platform) that give a
99% coverage of the installed computer base do not implement /dev/* based SCSI access at all.
This is why libscg
implements the portable interface via the SCSI Common Access Method
(CAM) standard addresses
instead of using /dev/* entries.
Even on Linux, using /dev/* based access to devices is extremely risky as Linux implements
more than a single driver per device. Because Linux does not provide a unified DMA implementation
for kernel drivers, some of the SCSI drivers that are available for a specific hardware device do not
implement DMA at all, while others implement DMA with a too small blocksize.
Because DVD writers require working DMA, users that offer /dev/* based SCSI address information
may force libscg to use a Linux driver that does not implement DMA and thus cause the write operation
to fail.
Omitting the cdrtools dev= parameter at all or offering standard CAM addresses allows
libscg to auto-select a working Linux driver for the named hardware.
The following OS platforms directly implement the CAM standard for their SCSI generic
pass through interface:
BeOS See BeOS on Wkipedia
FreeBSD See FreeBSD on Wikipedia
Haiku See Haiku on Wikipedia
OSF-1 and True-64 See OSF-1 on Pikipedia
QNX See QNX on Wikipedia
ZETA See Magnussoft ZETA
Special privileges to dispatch SCSI commands
Cdrecord, cdda2wav and readcd use libscg to communicate with SCSI devices.
As many devices in a modern computer are SCSI based, the privilege to dispatch SCSI
commands needs to be limited on multi user aware platforms in order to prevent a
privilege escalation.
All usual modern operating systems thus limit the permission to dispatch arbitrary SCSI commands
to programs with special privileges. This includes MS-Win, Solaris and Linux.
To avoid the need to start cdrtools from an administrator account, there are special
methods:
MS-Win by default configures the default account to include administrator privileges
Solaris introduced a fine grained privileges system in 2004. Pivileged programs can be configured via /etc/security/exec_attr
Linux introduced a fine grained privileges system that became usable in 2012. Privileged programs can be configured via setcap
Cdrtools supports the fine grained systems on Solaris and Linux and thus does not need to be root
on these operating systems. On other platforms, cdrecord, cdda2wav and readcd usually need to
be installed suid root.
The Linux SCSI kernel driver story
The original state
In 1992, Lawrence Foard wrote a driver called "sg" that allowed to send arbitrary SCSI commands
to arbitrary devices.
This driver was not well planned but secure and usable. It implemented the
following access method:
Yo need to be root to be able to open /dev/sg* read/write.
Anybody can open /dev/sg* read-only but this does not give permission
to send SCSI commands.
SCSI commands are sent using write(2) and read(2) calls.
Once you have an open fd for read/write, you are allowed to send arbitrary SCSI commands to the
device related to the open fd for the /dev/sg node.
So a suid root program could open a /dev/sg node
and then give up root privileges for the rest of it's lifetime but still was allowed to send arbitrary
SCSI commands.
If you chgrp the /dev/sg node for a CD-ROM, to "cdrom" and chmod g+w
that /dev/sg node, any user
in group "cdrom" is able to issue any SCSI
command to the device related to the modified /dev/sg node.
The relation between /dev/sg nodes and the hardware is not stable on Linux,
so doing the chgrp/chmod
mentioned above is a security problem. But whether your system is secure or insecure was your decision.
The vulnerable state
Around 2000, Douglas Gilbert was given permission by Linus Torvalds to enhance the sg driver.
The main modification he introduced at that time was an ioctl() interface to dispatch SCSI commands
in addition to the existing write(2)/read(2) method.
Because of missing skills in kernel security, he did
not check for a read/write file descriptor in that ioctl().
As a result of this change, these new rules applied:
You still do not need special privileges to open /dev/sg read-only, anyone can do that.
If you have any fd for a /dev/sg* node, you can send arbitrary SCSI commands
to the related device using
the ioctl() introduced by Douglas Gilbert.
This is of course a security problem as now any user is able to send arbitrary SCSI commands to abitrary SCSI devices.
The current state
In spring 2004 this security problem was discovered and discussed in public.
Linus Torvalds personally took care of the problem but instead of just fixing the security problem by requiring
a read/write file descriptor for the ioctl(), he decided to introduce an incompatible driver interface change.
This driver interface change was introduced even though all developers in the Linux kernel mailing voted against that change.
After Linus Torvalds introduced the incompatible interface change these rules apply:
You still do not need special privileges to open /dev/sg read-only, anyone can do that.
You now need to be root to be able to send arbitrary SCSI commands on a related file descriptor.
Later, a white list was defined that contains some SCSI commands that may be sent by any user.
This white list however, does not include all SCSI commands that are needed by cdrecord, cdda2wav and readcd.
Cdrecord, cdda2wav and readcd need to send SCSI commands not in the white list in order to implement the
documented behavior. Cdda2wav e.g. cannot extract many defective audio CDs known as un-CDs because this
requires non-standard SCSI commands from a SONY vendor-unique set that was licensed by many drive vendors.
Cdrecord cannot support all drives correctly or with the full documented feature set without sending vendor
unique SCSI commands.
Due to the fact that SCSI is a communication protocol, cdrtools check for the availability and usability of
special commands and fall back to a dumb state when these enhanced SCSI commands are not available.
Not being able to send all required SCSI commands may cause cdrtools to be unable to implement the expected
features or observe a late unspecific failure.
Debian's reaction
In May 2004, the Debian packetizer Eduard Bloch was unwilling to understand the background explained above.
He claimed that no incompatible Linux kernel interface change did take place and that the rules from before
April 2004 still apply. He stopped upgrading Debian's cdrtools source from the original sources and removed
all warnings that would identify privileges problems.
In other words, Debian started a fork from the cdrtools in May 2004.
As a result, the number of bugs in the Debian fork of cdrtools increased to approx. 100 bugs. Most of these bugs
were caused by Debian's removal of critical parts of the original source code. Concequently, these bugs only exist
in the fork by Debian. The remaining bugs were caused by Debian's refusal to integrate into their fork the
changes (fixes and workarounds) that were made in the original cdrtools to cope with the incompatible interface
change introduced in the Linux kernel.
Debian is therefore responsible of all the bugs in their fork since May 2004. At the same time, all the bugs
in the original cdrtools were fixed and every new bug in cdrtools is quickly fixed. So almost all of the bugs
in the fork are bugs that never existed in the original cdrtools.
These bugs have been documented in the bug
tracking systems from various Linux distros and they confirm the existence of the Debian fork since May 2004.
In September 2006, Heiko Eißfeldt and Jörg Schilling urged Debian to no longer use the original names
for the defective fork. This resulted in the Debian name change to "cdrkit" for the fork from May 2004.
The list of bugs that are specific to the Debian fork from May 2004 was unaffected by the name change from
September 2006. The Debian fork still does not include support for the Linux kernel interface change and
you need to run wodim from a root shell in order to make it halfway working.
The most prominent changes in the Debian fork since September 2007 are:
Removal of Copyright messages, something that no OSS project before did ever try to do
Replacing the working autoconfiguration and makefile system by a half-baken system that even no longer
support all Linux variants correctly
Since May 2007, the Debian fork did get no more than typo corrections, while the original software
meanwhile more than doubled it's features since May 2004.
Cdrecord news ticker
Images from Loveparade '99
Images from Loveparade 2000
Images from Loveparade 2001
About cdrecord's Y2k compliance
Linux on my Sony VAIO with Transmeta Crusoe
Soon: Cdrtools 3.02
Related features: sound output support for more platforms and enhanced paranoia features for cdda2wav.
August 26th 2015, Cdrtools 3.01 released
June 2th 2010, Cdrtools 3.00 released
June 4th 2007, Cdrecord adds the first Blu Ray support
The related code is in cdrtools-2.01.01a29.
In 2006 we were celebrating the 20th anniverary of the scg driver and libscg
In the first week of August 1986, I created the world's first SCSI generic pass-through system
on/for SunOS-3.0. Other similar ideas (such as ASPI from Adaptec) did appear 1988 or later.
Libscg is one of the oldest parts of cdrtools. It is needed to grant platform-independent
generic SCSI transport.
Cdrtools are now available under a OSS license that gives more freedom than the GPL
On May 15th 2006, most of the code has been relicensed under the CDDL.
Cdrtools is now under a true free license since more than 4 years and the new license does not try to impose unneeded restristions on developers and users.
The CDDL has been selected as one of 8 preferred licenses by the OSI.
Important information: Linux-2.6.8.1 breaks CD/DVD writing for suid root applications
If you have related problems, use a recent original cdrecord and install cdrecord suid-root
Warning: do not use Debian binaries/sources as they include many Debian specific bugs and still do not run correctly on Linux-2.6
Be careful with cdrecord derivates/forks from Debian, Debian seems to ignore the new constraints for
SCSI pass through on Linux-2.6. As a result, that they still incorrectly believe that it is possible
to use SCSI pass through as non-root on Linux-2.6, they created a cdrecord variant that tries to hide
the problems instead of dealing with the problems.
The Debian fork is based on an extremely outdated version of cdrtools.
The Debian fork of cdecord did rip off DVD support for no reason and
the mkisofs version distributed by Debian misses find(1) support, correct file meta data support
and the UDF enhancements as well as useful UTF-8 support is missing.
An original recent cdrecord is the preferred software.
Cdrecord supports DVD+-R and DVD+-RW with all known DVD-writers on all UNIX-like OS and on Win32.
DVD writing support is implemented in cdrecord since march 1998. Cdrecord writes DVD media similar to CD media.
Here is the place from where you may download
the cdrtools source packages that include cderecord-ProDVD.
Important Information:
Both RedHat and SuSE started to publish the bastardized and defective variants of cdrtools from Debian in their
distributions.
If you have problems on RedHat or SuSE systems, first fetch a
recent original cdrtools source, compile
it yourself
and run the original instead of broken software that illegally claims to be cdrecord.
Vortrag DVD-Brennen bei den LinuxInfoTagen (29.6.2003) BeLUG
Yamaha DiskT@2 is supported since Sept. 1 2002 (cdrtools-1.11a32). Here are some images
from a user:
Image-1
Image-2
Personal support for cdrecord has been terminated!
This is not because I am a bad guy but because I am receiving far too much mail
that only wastes my time and prevents me
from doing serious work.
It seems that far too many people are antisocial and just too lazy to read the documentation
or are using an account that has been set up incorrectly.
For this reason, I cannot give personal support anymore.
If you cannot compile cdrtools,
ask your sysadmin or someone else from the net
but don't try to use my time.
If cdrecord does not work for you,
get the latest alpha
and read the documentation.
If you found a real problem,
you may continue to contact me, but be prepared that you
don't receive an answer as in most cases reports do not
describe a cdrecord bug but a broken drive or a broken Operating system or if your problem
is mentioned in the documentation.
Read this if you have problems with cdrecord
If you have a drive that does not work, send me a sample drive and documentation
that would allow me to add support.
If you have problems, always first check the latest alpha version before you report a bug.
Cdrtools-2.01 final is out and supports many new features (including cdrecord, cdda2wav and mkisofs/mkhybrid in a single source tree).
The millennium Logo contest. Win a free copy of cdrecord.
I am looking for a set of logos for cdrecord/mkisofs/cdda2wav/readcd.
All graphics will go to a web page.
If you have an idea or a ready bitmap, send me email:
joerg.schilling at fokus.fraunhofer.de
The best artwork will be used for cdrtools.
ESO, the owner of the world's largest supertelescope, now uses cdrecord-ProDVD for CD-R and DVD-R creation.
Starting in autumn 2000 for real work, ESO writes 50GB of data each day to DVD-R media.
This keeps a single DVD-R drive busy for more than 12 hours per day.
Read all man pages for cdrecord and other programs.
Supported Operating systems:
- If you are using an ATAPI CD-Recorder read these tips.
- SunOS 4.x
- SunOS 5.x (Solaris 2.x): read the Sun CD-ROM FAQ. On Solaris 7 FCS, install patch 107465-02 on Solaris 8 (SPARC). Install patch 108974-16 to fix the ATA DMA bug (if using ATAPI).
- SGI IRIX
- HP-UX
- Linux: read the most recent CD-Writing HOWTO.
- If you have any problems with SCSI on Linux, read the Linux SCSI notes and some notes on enhancing the Linux 'sg' driver interface.
- Linux & ParallelPort CD-Recorder read this about the actual status.
- NetBSD/FreeBSD/OpenBSD read these tips for FreeBSD.
- AIX - to create a bootable CD for CHRP you need mkisofs from cdrecord-1.8a39 or later.
- BSD/OS 3.x (BSDI) -> Port integrated in cdrecord-1.6.1
- FreeBSD-current (CAM SCSI transport) -> Port integrated in cdrecord-1.6.1
- OSF-1 -> Port integrated in cdrecord-1.6.1
- NeXt Step -> Precompiled Binary available here. Source available to the public in cdrecord-1.8a28 or later.
- Apple Rhapsody -> SCSI transport source available to the public in cdrecord-1.8a28 or later.
- MacOS X -> Port integrated in cdrecord-1.8a28.
- BeOS -> Port integrated in cdrecord-1.8a14
- VMS -> Port ready but does not use the makefile system. Immediate access is here. Also look at this location.
- For a Win32 development environment, look at: http://sources.redhat.com/cygwin/.
- WNT -> Port integrated in cdrecord-1.8a22, precompiled Binaries are available here or here old binaries at this place.
- W95 -> Port integrated in cdrecord-1.8a22, precompiled Binaries are available here or here old binaries at this place.
- W98 -> Port integrated in cdrecord-1.8a22, precompiled Binaries are available here or here old binaries at this place.
- NT-3.5 -> Port integrated in cdrecord-1.8a22, precompiled Binaries are available here or here old binaries at this place.
Make sure that you are using an ASPI layer that works for NT-3.5.
- SCO Openserver 5.x -> Port integrated in cdrecord-1.8a22, or get a binary from skunkware as custom installable binary.
- SCO Unixware 2 / Unixware 7 -> Port on skunkware as custom installable binary.
- DOS -> DOS/DJGPP port integrated in cdrtools-2.01a20; a binary may be retrieved from
here
- OS/2 -> Port integrated in cdrtools-2.0; a binary may be retrieved from
here (recent) or
here (outdated).
Operating systems with ports in alpha or beta:
Volunteers wanted for ports to:
- QNX -> Port for QNX Neutrino underway.
- Ultrix -> Any interest? an old port has been lost due to a disk crash.
- DG-UX -> May be out of interest, but if there is really interest please mail me.
The user land SCSI transport implementations on Linux and *BSD (except FreeBSD/cam) are the worst ones.
Linux will not tell you all errors while *BSD (except FreeBSD/cam) hides the device files from you.
SGI does not allow SCSI disconnects on odd-byte-count boundaries.
Look for my SCSI implementation ratings.
If you would like to get the latest news on CD recording and wish to actively help with developing the software you may join
the cdrtools developers mailing list at
http://lists.sourceforge.net/lists/listinfo/cdrtools-developers
or
check the cdrtools support mailing list at http://lists.sourceforge.net/lists/listinfo/cdrtools-support,
see all cdrtools related mailing lists.
...or his CD drive comparison list.
To be able to recognize all CD-R drives correctly, I need the Inquiry data of all drives.
Please email your inquiry data to me at:
joerg.schilling at fokus.fraunhofer.de. An Inquiry output looks like:
Device type : Removable CD-ROM
Version : 2
Response Format: 2
Capabilities :
Vendor_info : 'IMS '
Identifikation : 'CDD2000/00 '
Revision : '1.26'
...and may be retrieved by
cdrecord dev=target,lun -inq (replace target and lun with the correct values). cdrecord -scanbus will list the drives connected to your system.
Here is the Inquiry data that I already know.
Download cdrecord-2.0: NOTE: use the cdrtools package.
The Yamaha CDR-400, CDRW-4260, and CDRW-4416, and the Plexwriter PX-R412, Plexwriter 820, Plexwriter RW-4/2/20, Plexwriter RW-8/2/20, and Plexwriter RW-12/4/32
are the only CD-R drives I know of that have a jumper to set the sector size to 512 bytes.
NOTICE: it seems that all Plextor and all Yamaha CD-R and CD-RW drives support switching to 512 bytes/sector.
This should allow to use the drive as a boot drive and general-purpose drive
for SunOS and Solaris.
Drives that may get support if I have the time:
- Ricoh 1060C (if I manage to print the manual with Japanese characters)
- JVC, Pinnacle Micro (if I get support from the companies)
Cdrecord is free. Cdrecord is the only CD-R program available that supports most
CD-Recorders and comes with full source.
To be able to give continuous support for all recorders I need continuous access to
drives from all brands and all models.
I would be happy to see industrial sponsors supplying me with the needed drives.
I currently own the CD-Recorders from the hardware list below. If you would like to supply me with one
please contact me at joerg.schilling at fokus.fraunhofer.de
Thanks to the following companies for supplying me with needed materials.
Hardware (the hardware in this section is supported):
- COMPRO donated a COMPRO CW-7502 forever.
- TEAC donated a TEAC CD-R55S, a CD-R58S, and a CDW-54E forever.
- Yamaha donated a Yamaha CDR-400tx, a CRW4416S, and a
CRW8824SZ forever.
- Plextor donated a PlexWriter 8/20, a PlexWriter RW 4/2/20, a PlexWriter RW 8/2/20, a Plexwriter RW 12/4/32
, and an UltraPlex 40max forever.
- Sony donated a Sony CDU-948 and a CRX-145E forever.
- Ricoh donated a Ricoh MP-7040A and a MP-7040S forever.
- Ricoh donated a Ricoh MP-7060S to Thomas Niederreiter and Heiko Eißfeldt.
- This will help to implement additional features into X-CD-roast and cdda2wav, as these drives support all you might want from a CD-R/CD-RW drive.
- Ricoh donated a Ricoh MP-7080A and a MP-9060A forever.
- LG-Electronics (Goldstar) donated a CED-8080B drive forever.
- Freecom donated a Freecom Traveller with Parallel Port, USB and PC-Card cable as well as an external case for 5¼" ATAPI drives forever.
- Sanyo donated a CRD-Bp2 (BURN-Proof)
forever.
- Plextor donated a PX-W121032A (BURN-Proof) forever.
New Hardware (not yet supported or not yet fully supported):
Documentation:
- Still under construction.
If you have problems, please include the operating system and the hardware architecture in each email. I am getting dozens of emails each day and cannot remember your last email.
Access count:
since April 1997
Last Change 20/11/21
Schily's Homepage
. 
