
#####################################################################
#                                                                   #
# Original filename: README                    Created on: 01/29/98 #
#                                            Last changed: 01/06/99 #
#				             This version: 2.1	    #
# Author: Boris Lorenz (bolo@cts-gmbh.com)         Status: free/GPL #
#                                                                   #
# Purpose: Information about the create-a-cd package                #
#          and the apps within                                      #
#                                                                   #
# CAUTION: Please read this file carefully to avoid serious damage  #
#          to your HD and/or system!                                #
#                                                                   #
#####################################################################

DISCLAIMER
==========

Yep, the legal stuff... I am not responsible for any kind of damage to
your harddisks/your system connected with the use of my scripts and the
binaries of this archive (here: create-a-cd-2.1.tar.gz). Use at own risk.
Furthermore, copying copyrighted software from one CD to another is a nasty
thing to do, the same goes for audio CDs which are copyrighted as well and
should not be duplicated for other purposes than security backups,
even if it's working ...;)  


GENERAL INFORMATION
===================

The examples in this README have been tested on a Pioneer DR-U12X
CDROM and an Yamaha CDR-100 recorder. Refer to chapters INSTALLATION and
CONFIGURATION for more info about other hardware.

If you have additional information about particular hardware specifications
or the like you are encouraged to mail me the details.


WARNING
=======

Please DO NOT execute ANY of the apps/examples of this package without
a closer look a this README. The results could be at least demoralising...
You have been warned.

TAKE THIS AS AN ENHANCED HOWTO - This is by far no "release" at all,
just some hints and apps to create your own CD-ROMs. Therefore reading
of the whole README may lead you to successfully created Compact
Discs of any kind. 

If not: Forget it, you won't get your money back.

Batteries not included.


HARDWARE, SOFTWARE AND KNOWLEDGE REQUIREMENTS
=============================================

------
System
------

- Linux (of course)
- Kernel with SCSI low level support compiled in

--------
Software
--------

For a complete compatibilty list of the tools I use with my scripts
to read and write data/audio-tracks from/to cd (mkisofs, cdda2wav and
cdrecord) please refer to the various readmes and docs shipping with
them. The latest versions of these apps have been included in this
package, obtained from these sites:

cdrecord and mkisofs:	ftp.fokus.gmd.de/pub/unix/cdrecord/
cdda2wav:		ftp.fokus.gmd.de/pub/unix/cdrecord/alpha/

All software applications you need are included in this package.

--------
Hardware
--------

You need:

- a SCSI-adaptor supported by your Linux distribution
- a supported SCSI- or ATAPI CD-recorder
- a supported SCSI- or ATAPI CD-ROM (optional, you can use the CD-recorder
  for both reading and writing)

If you are not sure take a look at /var/log/messages or /var/adm/messages
and several other places where you can find information about your system.
Also consider taking a look into the documentation shipped with your
Linux distribution.

---------
Knowledge
---------

At first you should thouroughly read the information found in this
README. 

Next you have to know a thing or two about the SCSI system of your
Linux box; for a quick start, here are the important facts:


	1. The generic SCSI devices

	Any application trying to communicate with SCSI devices
	other than harddisks (such as CD ROMs, CD recorders, scanners
	and so forth) has to use the generic SCSI devices usually found
	in /dev of your Linux system. These generic SCSI devices are
	named sg1...16 and/or sga...h. 

	If there are no such devices you can create them with
	the command lines:

	> cd /dev
	> ./MAKEDEV sg

	This has to be done as root. Now the generic SCSI devices should
	appear.

	These generic SCSI devices are dynamically mapped to the
	logical unit numbers (LUNs) of the SCSI adaptor(s) found in your
	system. sga for example would represent the first generic SCSI
	device found on the first SCSI adaptor, sgb would represent
	the second one, and so on. 

	Another example:

	Say you had hooked two SCSI CD ROMs and one CD recorder onto
	your SCSI controller. CD ROM a had SCSI id 1, CD ROM b 
	had SCSI id 3 and the CD recorder sat on SCSI id 5.
	Now the generic SCSI device names would be:

		CD ROM a ----> /dev/sga
		CD ROM b ----> /dev/sgb
		CD recorder -> /dev/sgc
		
	Please note that the SCSI id has nothing to do with the
	generic SCSI device name! These device names are given
	step-by-step by the system as it sequentially detects the
	connected SCSI devices; first one is sga, second one is sgb,
	third one is sgc, fourth one is sgd and so on and on and on...

	Here you have my SCSI configuration:

	Attached devices: 
	Host: scsi0 Channel: 00 Id: 01 Lun: 00
	  Vendor: IOMEGA   Model: ZIP 100          Rev: E.08
	  Type:   Direct-Access                    ANSI SCSI revision: 02
	Host: scsi0 Channel: 00 Id: 02 Lun: 00
	  Vendor: PIONEER  Model: CD-ROM DR-U12X   Rev: 1.06
	  Type:   CD-ROM                           ANSI SCSI revision: 02
	Host: scsi0 Channel: 00 Id: 05 Lun: 00
	  Vendor: YAMAHA   Model: CDR100           Rev: 1.12
	  Type:   WORM                             ANSI SCSI revision: 02
	Host: scsi0 Channel: 00 Id: 06 Lun: 00
	  Vendor: QUANTUM  Model: FIREBALL_TM3200S Rev: 300N
	  Type:   Direct-Access                    ANSI SCSI revision: 02

	The generic SCSI device names would then be sga for the IOMEGA
	ZIP on id 1, sgb for the PIONEER CD ROM on id 2, sgc for the YAMAHA
	CDR-100 recorder on id 5 and sgd for my QUANTUM hd on id 6.


	2. Compiling a decent kernel with SCSI low level support

	On the command line, issue

	> cat /proc/devices
	
	and you'll get something like this:

	> Character devices:
	> 1 mem
	> 2 pty
	> 3 ttyp
	> 4 ttyp
	> 5 cua
	> 7 vcs
	>10 misc
	>14 OSS/Linux
	>21 sg		<---- This is the generic SCSI charakter device
	>43 ttyI	      as needed by the system to communicate with
	>44 cui		      various SCSI appliances. If it is not in your
	>45 isdn	      list, you have to recompile the kernel.

	>Block devices:
	> 2 fd
	> 3 ide0
	> 8 sd		<---- This is the device for SCSI HDs
	> 9 md
	>11 sr		<---- This is the device for SCSI CD-ROMs

	To set up your system in order to communicate with generic
	SCSI/low level devices you have to compile a kernel with the
	SCSI low level support option built in. Alternatively you can
	modularize this support for less kernel memory consumption.

	Additionally you have to specify the brand and model of your
	SCSI adaptor of your Linux box.

	Change to /usr/src/linux, check your .config (for example with
	'make menuconfig' or (under X) 'make xconfig' or just 'make
	config' if you're in a non-graphical shell) and rebuild your
	kernel by giving 'make clean && make dep && make zImage'.
	
	CAUTION: This is just a guideline how to do it, you should	
	not start to alter any config-files and/or compile a new kernel
	without any precautions (backups of the old kernel and
	config files, backup of the system map, etc.) if you are not
	so sure about what you're doing.
 

INSTALLATION 
============

If you have any older versions of the create-a-cd-package installed
please note that the main application to write data to CD has been
changed from "cdwrite" to "cdrecord". The command-line options of
these apps are nearly the same but the functionality of cdrecord
is much more enhanced. If the scripts and tools of a former version
of create-a-cd worked well in your system till today you should take
a closer look at the README of "cdrecord" (included in this package)
to make sure "cdrecord" fully supports your CD-recorder BEFORE you
occasionally delete or irreversibly alter old scripts and/or tools.

The executables of cdrecord, cdda2wav and mkisofs are provided
as executables, so you don't have to unpack and make them by
yourself. Of course you can do this if you want/have to. In this case,
unpack the archives with:

tar xvfz <archivname>.tar.gz

change to the newly created directory and refer to the corresponding
instructions for making and installing.

Step-by-step installation:

	1.) Create a directory under /usr/local (e.g. /usr/local/create)
	
	2.) Copy the create-a-cd archive into this new directory and
            unpack it with "tar xvfz <archivname>"

	3.) Optionally, you can unpack the shipping-versions of
	    "cdwrite" and "cdda2wav", also with "tar xvfz <archivname>
            to read the documentation (which is recommended)

	4.) Make sure the directory where "cdrecord", "mkisofs" and 
	    "cdda2wav" are stored is in your path


CONFIGURATION
=============

Now you have to find out wether "cdrecord" needs a specific driver to
perform any writing on CDs with your CD-recorder. Normally "cdrecord"
automatically detects the CD recorder and uses the appropriate driver
if necessary. Please note that in this case the word "driver" does not
refer to an additional software plug-in to "cdrecord" as merely the
hardware-specific functions of the tool. In case of an Yamaha recorder
for example the byte-order of audio-tracks has to be swapped if the
stream of audio-data is in Intel format. There's also a -swap option
for "cdrecord" but it is not recommended to use it since "cdrecord"
activates the swapped byte-order for audio tracks by itself if needed.

For your convenience, here's a complete list of all supported and not
supported devices of "cdrecord". The list has been compiled by its
author Joerg Schilling (joerg@schily.isdn.cs.tu-berlin.de):

All SCSI-3/mmc compliant drives
All ATAPI/mmc compliant drives

COMPRO CW-7502
Dysan CR-622 ???? See Wearnes 622
Dysan CR-1622
DynaTec CDM-240J (see Pinnacle RCD-4x4)
DynaTec CDM-240  (use cdrecord driver=yamaha_cdr100)
DynaTec CDM-400  (use cdrecord driver=yamaha_cdr100)
Grundig CDR-100
Hewlett Packard 4020i
Hewlett Packard 6020i
HP C4324/C4325 (HP SureStore 4020i/6020i)
HP 7100
HP 7110
Hi-Val CD-R (see Pinnacle RCD-4x4)
JVC XR-W2001 (uses TEAC code - see below - audio not working)
JVC XR-W2010 (uses TEAC code - see below - audio not working)
JVC XR-W2020 (uses TEAC code - see below - audio not working)
Kodak PCD-200 or Kodak PCD-200 Plus
Kodak PCD-225
Kodak PCD-240
Kodak PCD-600 (not tested)
Matsushita CW-7502
Memorex CR-622 ???? See Wearnes 622
Memorex CR-1622	
Microboards PlayWrite 2000 (use cdrecord driver=sony_cdu924)
Microboards PlayWrite 4000 (use cdrecord driver=yamaha_cdr100)
Microboards PlayWrite 4001RW
MicroNet MasterCD Plus 4x4 (use cdrecord driver=yamaha_cdr100)
MicroNet MasterCD Plus 4x6
Mitsumi CR-2401-TS (not tested)
Mitsumi CR-2600-TE
Olympus CDS615E
Olympus CDS620E (use cdrecord driver=sony_cdu924)
Olympus CD-R2x6 (use cdrecord driver=sony_cdu924)
Optima Dis Kovery 650 CD-R (use cdrecord driver=sony_cdu924)
OTI CDRW 965
Panasonic CW-7502
Philips CDD 521 (CDD521/02  Revision: 2.06 has bad firmware - seems not to work)
Philips CDD 521 (upgraded units only: ID: CDD521/10  Revision: 2.07)
Philips CDD 522
Philips CDD 2000
Philips CDD 2600
Philips CDD 3600
Philips CDD 3610
Philips Omniwriter 26
Philips Omniwriter 26A
Pinnacle Micro RCD-1000 (see TEAC/JVC): Need to upgrade firmware to 2.35
Pinnacle Micro RCD-5020 (see TEAC/JVC - audio not working)
Pinnacle Micro RCD-5040 (see TEAC/JVC - audio not working)
Pinnacle Micro RCD-4x4
Pioneer DW-S114X
Plasmon CDR 4220 (not tested)
Plasmon RF-4100
Plasmon RF-4102
Plasmon CDR 4400 (use cdrecord driver=yamaha_cdr100)
Plasmon CDR 480
Plextor PX-R24CS (use cdrecord driver=ricoh_ro1420c)
Plextor PX-R412C
Procom PCDR 4 (use cdrecord driver=yamaha_cdr100)
Ricoh RO-1420C
Ricoh MP-6200
Ricoh MP-6200I
Ricoh MP-6201
Smart & Friendly CD-R1002 (use cdrecord driver=sony_cdu924)
Smart & Friendly CD-R1004 (use cdrecord driver=yamaha_cdr100)
Smart & Friendly CD-R2004 (use cdrecord driver=sony_cdu924)
Smart & Friendly CD-R2006 PLUS
Smart & Friendly CD-R2006 PRO
Smart & Friendly CD-R4000 (use cdrecord driver=yamaha_cdr100)
Smart & Friendly CD-R4006
Smart & Friendly CD-R4012
Smart & Friendly CD-RW226
Sony CDU920S
Sony CDU924S
Sony CDU926S
Sony CDU940S
TEAC CD-R50S
TEAC CD-R55S
Taiyo Yuden CD-WO EW-50
Traxdata CDR-4120
Traxdata CDRW-4260
Turtle Beach 2040R (use cdrecord driver=ricoh_ro1420c)
Wearnes CD-R622
Wearnes CD-R632P
Yamaha CDR-100
Yamaha CDR-102
Yamaha CDR-200
Yamaha CDR-400(Firmware revision 1.0d and up otherwise upgrade)
Yamaha CDR-401
Yamaha CRW-4001
Yamaha CRW-2260
Yamaha CRW-4260

Multi-session has not been tested with the Plasmon RF-4100

The following drives will never be supported by cdrecord because they are
too old:

JVC XR-W1001
Pinnacle Micro RCD-202
Ricoh RS-9200CD


EXAMPLES FOR READING AND WRITING CDs
====================================

I like examples...! A lot of HOWTO documents or other ressources of help
deal with a lot of theoretical problems (so do I, but later on),
but they do not give any examples of correct use of different command-line
switches or options. So, here are some basic suggestions of how to read
and write data from and to harddisk or CD:

---------------------------------------------------------------------------

EXAMPLE 1: Mastering an ISO0660 image-file to a path from your /home
==========

	mkisofs -R -o /mnt/image.raw /home/tom

This creates an ISO9660 image-file called "image.raw" in /mnt from the 
contents of Tom's home-directory (/home/tom/) with Rock Ridge extensions.
This means that also filenames who break the 8.3-rule will be copied
correctly (this is needed by most unixish systems).
---------------------------------------------------------------------------

EXAMPLE 2: Mastering an image-file from CD to a path using "cat"
==========

	cat /dev/scd0 >/mnt/image.raw

This creates an writeable image-file called "image.raw" in /mnt from
the contents of the first CD-ROM drive (scd0). Please note that "cat"
is only capable of reading a single session of data (one session per
disc, single data-CD), it does not copy audio-tracks or multisession-
discs, although you can use it within scripts to do so.

Note that all filenames on a CD considered to be ISO9660 compliant must
be in the 8.3 format (8 characters, period, 3 characters, all uppercase).
"Real" pre-mastering apps like "mkisofs" truncate files which exceed this
limit and are also able to create special tables within each mastered
directory with references to the real file names. cat instead only
concatenates all files into one big file and keeps the filenames
unchanged. So, cat is a very good tool for some sort of "complete
snapshot" of a mounted volume, say a CD or similar, but NOT, I repeat
that, NOT to master a real ISO9660-image. Use "mkisofs" (like in example 1)
for this purpose! Also take a look at chapter TECHNICAL APPENDIX.

---------------------------------------------------------------------------

EXAMPLE 3: Copying audio-tracks from CD to harddisk 
==========

	cdda2wav -D/dev/sgb -Igeneric_scsi -max -t1 /mnt/track01.wav

This copies track one of an audio-disc present in the CD-ROM device
with SCSI-id 2 (sgb) to /mnt with the name "track01.wav" and maximum
output quality (44.1 KHz, 16-bit, stereo).
The option -I specifies the interface to be used for CD-ROM access.
Valid interfaces are generic_scsi, cooked_ioctl or scsi_ioctl. Please
refer to the cdda2wav-package for more information.

---------------------------------------------------------------------------

EXAMPLE 4: Copying a mixed-mode CD (one data track and five audio
========== tracks) to harddisk

	cat /dev/scd0 >/mnt/image.raw
	cdda2wav -D/dev/sgb -Igeneric_scsi -max -t2 /mnt/track01.wav
	cdda2wav -D/dev/sgb -Igeneric_scsi -max -t3 /mnt/track02.wav
	cdda2wav -D/dev/sgb -Igeneric_scsi -max -t4 /mnt/track03.wav
	cdda2wav -D/dev/sgb -Igeneric_scsi -max -t5 /mnt/track04.wav
	cdda2wav -D/dev/sgb -Igeneric_scsi -max -t6 /mnt/track05.wav

This copies the data-track of the mixed-mode CD to /mnt with the name
"image.raw". The CD in this case resides in the CD-ROM on SCSI-id 1
(second device on the SCSI bus, so its generic SCSI device name is
'sgb').

Afterwards "cdda2wav" is used to copy the five audio-tracks (starting
from step 2 because the data-track represents step 1). 

---------------------------------------------------------------------------

EXAMPLE 5: Writing an image-file mastered with mkisofs (like in
========== EXAMPLE 1) or cat (like in EXAMPLE 2) to CD

	cdrecord -v -eject speed=2 dev=5,0 driver=yamaha_cdr100 /mnt/image.raw

This writes the image "image.raw" in /mnt to the Yamaha-compliant CD-recorder
on SCSI-id 5 and LUN 0, prints the ongoing writing process and ejects the
CD after it has been written. Please note that there must not be any
minus "-" signs before the switches "speed", "dev" and "driver".
If you do not set the "driver" switch "cdrecord" tries to figure out
what driver to use, and IMHO it is quite good in that, so you can give
it a try. "cdrecord" also determines the correct writing-speed to be
used, so you also can lose the "speed" switch, especially if you own
a CD-recorder directly mentioned by the "driver" switch of "cdrecord".
For enhanced information about this topic refer to the documentation
of "cdrecord" found in its package.

---------------------------------------------------------------------------

EXAMPLE 6: Writing one or more audio-tracks from harddisk to CD 
==========

cdrecord -v -eject speed=2 dev=5,0 driver=yamaha_cdr100 -audio /mnt/track*.wav

This writes all track*.wav-files found under /mnt in alphabetical order to
CD using the Yamaha-driver with a device on SCSI-id 5, LUN 0 and with a
writing-speed of 2. The ongoing process of writing will be shown. After
writing the CD will be ejected.

---------------------------------------------------------------------------

EXAMPLE 7: Writing one data-track and five audio-tracks to CD (mixed-mode)
==========

cdrecord -v -eject speed=2 dev=5,0 driver=yamaha_cdr100 -data /mnt/image.raw    -audio /mnt/track*.wav

This writes one data-track named "image.raw" and all track*.wav-files to
CD within one session, thus creating a mixed-mode CD like used for most
commercial games and stuff. The CD-recorder in this example resides on
SCSI-id 5, LUN 0. The CD will be ejected after writing it.

---------------------------------------------------------------------------

EXAMPLE 8: Mounting the mastered image (as in examples 1 and 2) before
========== writing to CD in order to check it

	mount image.raw -r -t iso9660 -o loop /mnt

	and afterwards give

	ls -Rl /mnt

	to see the contents. Don't forget to unmount /mnt using

	umount /mnt

With this useful procedure (taken from the "cdrecord" manpage) you are
able to mount the mastered image on the auxiliary mountpoint /mnt and
directly interact with it. The command line "ls -Rl" gives you a complete
listing of the whole tree with all subdirectories. Check wether all
dirs are present and the files are okay.
  Of course this is no really perfect way of checking, especially if
the image is very big and/or the directory structure is complex.
In this case, the good old "diff" will lead to more exact results,
but is also quite slow.

--------------------------------------------------------------------------

EXAMPLE 9: Creating on-the-fly (1:1) backups with a CD-ROM and a CD recorder
========== 

	cdrecord -v dev=5,0 speed=4 -isosize /dev/scd0

This copies the data stream coming from the SCSI CD-ROM scd0 directly to
the CD recorder on SCSI id 5, LUN 0, with quadruple speed. Again you should
keep in mind to change my example devices and IDs to the ones suitable for
your system.

CAUTION: Before trying to create on-the-fly backups first use the -dummy
switch of cdrecord to test the whole thing; any disturbances during the
writing process lead to ruined discs and thus are waste of money, so
try not to perform any Lord Of The Dance movements or other silly walks
in front of your computer while burning, some sensitive recorders will
probably make you regret to have done that...

Note that your CD-ROM has to be at least twice as fast as your CD recorder.
If you can not assure this, do not use on-the-fly, there's no real
advantage in it except for some saved minutes of time and harddisk space
because you don't need to store a huge image on disk.

--------------------------------------------------------------------------

EXAMPLE 10: Creating 1:1 backups with only a CD recorder
===========

	dd if=/dev/scd1 of=/mnt/image.raw bs=1c count=`isosize /dev/scd1`

This one here streams the data from the CD recording device (/dev/scd1)
trough the filter "dd" which is capable of converting bitstreams while
they are written, in our case to the file image.raw in path /mnt.
The argument 'isosize /dev/scd1' calculates the size of the image data in
order to properly convert it to the image file. "isosize" is part of the
cdrecord package.

The resulting huge image file should be an exact copy of the original data.
Note that you can not clip audio tracks out of CDs with this method, only
raw data can be read and processed. Needless to say also that you have to
provide at least a couple of hundred MBs of free harddisk space; remember
that a CD can hold up to 700 MB of data, so it's a good idea to issue

	isosize /dev/scd1

first, which will give you the exact size of the image data.

Finally, the image can be written to CD like described in EXAMPLE 5.

--------------------------------------------------------------------------

EXAMPLE 11: On-the-fly mastering
===========

	mkisofs -R /home/tom | cdrecord -v speed=2 dev=5,0

Here mkisofs creates an iso9660 filesystem together with a load of
stuff from path /home/tom directly on the CD in recorder on SCSI id 5,
LUN 0 with double speed.

It seems a little more reliable mastering data directly from harddisk to
CD instead creating an on-the-fly backup of another CD as harddisks normally
have a higher data transfer rate than CD-ROMs, but arising problems often
lead to the same results - charred CDs.

So if you do not own reasonably fast SCSI or ATAPI devices and a good
harddisk you should stay away from mastering on-the-fly, not without
the -dummy switch enabled anyway.

--------------------------------------------------------------------------

This stuff should suffice the most common procedures of creating
CDs. Sounds nice? Well, it's easy, at least the technical side with all
the options and switches, but there are more serious obstacles in your way
to a perfectly recorded CD, such as bad CD-recordables, improper formats
(non-ISO CDs, hfs(MAC-)CDs), jittering in audio tracks and plenty of other
annoyances. To help you out there, read chapters TECHNICAL APPENDIX 
and TROUBLESHOOTING. 

Always keep in mind to take reference to the documentation shipping with
cdrecord, mkisofs or cdda2wav for more options, switches and info
how to create for example CD-I, CD-XA, multisession-discs and other
more complex stuff. Virtually all kinds of CD-data can be created with
"cdrecord" or "mkisofs", so a proper understanding of the its manuals 
is quite helpful.


TROUBLESHOOTING
===============

Any troubles? Look in here:

"MKISOFS" AND "CDRECORD" OFTEN CRASH DURING READING OR WRITING DATA

	Creating images with "mkisofs" and specially writing data to
	a CD-recorder are real-time tasks with quite a serious need
	of system ressources. If you do not own a reasonably fast
	CD-recorder ( >=4x writing speed ) try not to master or
	burn images when the system is heavily loaded (use the
	application "top" to determine the current system load).

	During writing data to CD a CD-recorder needs a clean,
	uninterrupted stream of data to its buffers. If something
	(or someone...) disturbs this stream, the "buffer-refill"
	is unable to provide enough data, the stream of data breaks
	up and the whole process stops with errors. A CD currently
	"under construction" would be dead in this case, so use
	the option -dummy with "cdrecord" when experimenting.
	-dummy turns the laser of the CD-recorder off, so no
	real writing is done, the CD is safe from your experiments.
	This mode will be optically confirmed by a flashing "write"
	LED of your CD recorder instead of a constantly burning one.

				*

AFTER A SHORT WHILE, CDRECORD SHOWS AN OUTPUT LIKE:

cdrecord: I/O error. test unit ready: scsi sendcmd: no error
              status: 0x2 (CHECK CONDITION)
              Sense Bytes: 70 00 05 00 00 00 00 0A 00 00 00 00 25 00 00 00 00 00              Sense Key: 0x5 Illegal Request, Segment 0
              Sense Code: 0x25 Qual 0x00 (logical unit not supported) Fru 0x0

	This is the standard error-message of an gone-mad SCSI-command.
	In the first line you see the kernel-message, the second line
	gives informations derived from the SCSI-device itself, the
	third line is a hex-dump of the sense information of the crashed
	command, in the fourth line we find the error-message of the
	corresponding sense key, and in the fifth line we see the
	errormessage decoded from the tables in scsierrs.c of the
	kernel-sources (if available). What you can do with this info
	depends on your knowledge of the kernel and several SCSI-related
	topics. In most cases these errors are the result of a buffer-
	underrun. Try to increase the priority of "cdrecord" and
	avoid concurrently running larger applications.
	If such errors occur after trying to directly master from a
	mounted CD in a CD-ROM drive to the CD-recorder you should
	create an ISO9660 imagefile on hd instead.

				*

CDs FROM IMAGES CREATED WITH cat ARE INACCESSIBLE IN MS DOS

	Like mentioned before, cat does not create a real ISO9660
	compliant image, it only concatenates files into one big
	file which can be written to CD. In Linux you shouldn't have
	any trouble when mounting such CDs, but DOS may have some
	trouble with it, especially if there are lowercase-files
	and so forth. Use cat only for 1:1-copies of CDs (e. g.
	for backups of your original application CDs) or for CDs
	only used within more liberal systems (like unix or MAC).
	For a real ISO9660 compliant image use "mkisofs" (see
	EXAMPLE 1). On the other hand, cat can be very useful
	if the CD to be created should definitely NOT contain
	ISO9660-truncated data.

				*

SOME CDs CANNOT BE COPIED USING MY CD-ROM DRIVE AS READING DEVICE

	Some models of CD-ROM drives show somewhat strange reactions
	to several SCSI commands. Especially if you own a fully
	supported CD-recorder (such as the Yamaha CDR-100) you should
	consider using your recorder both for reading and writing.
	Give it a try - you may be surprised. Furthermore, some
	CD-ROM drives go mad if you try to set the speed-value
	to an exaggerated rate; of course it is nice to see the
	bytes rushing by when reading audio-tracks with 8x speed,
	but the result can be buggy - so slow down.

				*

AFTER READING AUDIO-TRACKS FROM A CD-DA (DIGITAL AUDIO), STRANGE SCRATCHES
AND OTHER OCCASIONAL NOISES ARE HEARD DURING PLAY

	Welcome to the world of audio - What you have experienced is
	called "jittering" - a nasty, digital screech, only a fraction
	of a second long, but enough for spoiling an entire recording.
	Jittering happens when the bytestream from the wav-file on
	the harddisk is undergoing minimal turbulences when being written
	to CD, leaving some kind of digital garbage - the screeching
	noise.
	  The most effective cure against jittering is to lower the
	writing speed, depending on your recording-hardware and the
	system load. Setting the speed of a CD-recorder which is
	-technically- able to reach x4 to its maximum while at the
	same time surfing the net under X-Window is not a good idea...
	To give you a glimpse of experience I can tell you that
	I very seldom have problems with jittering when copying
	and writing audio tracks on my Yamaha CDR-100 with x2 speed
	on my system without any seriously concurrent apps.

				*

WHEN TRYING TO COPY PLAYSTATION- OR SEGA SATURN CDs, ERRORS OCCUR
EVERYTIME ON THE SAME SPOT DURING THE PROCESS

	Well, I received some mails with questions about how to
	copy PlayStation or Saturn CDs for backup purposes.
	There are quite a few applications around (mostly for
	different flavours of MS Windows) with whom complete
	backups of several console-CDs are possible, so you
	should easily be able to obtain at least a shareware
	version of the software if you really need to back up
	a console-CD.
	  Technically, the problem on backing up an entire PSX-CD
	is the so-called country-track, a sixteen blocks long
	information-ressource for the PlayStation-console to
	correctly identify the game to set up the output-format
	(european PAL or american/japanese NTSC). Because of
	certain pre- and postgap-tricks on PSX-CDs the country-track
	is left uncopied by most programs, so the resulting image
	won't work if written to CD. Try to obtain the country-tracks
	as binaries and concatenate them in front of your PSX-image.
	An image prepared this way can be written to CD and successfully
	booted provided you have a MOD-CHIP in your PlayStation or
	an older revision of the console to perform the infamous
	"swap trick"... 'Nuff said. Please DO NOT send any mails
	with this thread again. Thank you.
 
				*

AFTER SUCCESSFULLY COPYING A CD CONTAINING A GAME OR SOME MULTIMEDIA
APPS STRANGE "HICKUPS" AND STOPS DURING AVI-MOVIES OR ANIMATIONS CAN
BE NOTICED

	No two CDs purchased in various shops are the same, especially
	if you have bought some "budged occasions"... It heavily depends
	on the coating used for finishing the CD how good the written
	CD will perform - Some manufacturers do not take the right
	care when choosing a cheap finish, and the customers have to
	cope with this loss of quality. The current situation on the
	CD market is too fast moving to give any recommendations,
	but you should not believe anything the distributors say -
	it's not so much a matter of the color of the coating
	(blue, gold, silver, whatever)... Here you can only try
	some and see which are best for your needs.	

				*

In any case - if you experience any trouble with "cdrecord", please mail
your problem together with a list of your system configuration to the
author, Joerg Schilling (joerg@schily.isdn.cs.tu-berlin.de).


TECHNICAL APPENDIX
==================

	Critical problems of the ISO9660 standard
	-----------------------------------------

	If a filename which exceeds the 8.3-rule has to be truncated,
	tools like "mkisofs" will take care that no equal filenames
	will exist after truncating. For example, if you have two
	files, one named "filename_number_one" and "filename_nummer_one",
	no two apps can exist in one path with the truncated names
	"filenam~.one", so "mkisofs" cuts the names and creates a
	entry in a table called TRANS.TBL, which can be created by
	giving the option -T with "mkisofs". This table, written to
	every directory on the CD, contains all filenames and the
	references to the truncated files for recovery.

	Tools like cat do give a f**k on any standard, they just
	create a concatenated file which can be written to a CD
	(or to tape for backup purposes). The advantage of cat
	lies in its ability to directly access an unmounted CD-ROM
	drive and writing the contents of the CD in it to disk,
	thus creating a 1:1 copy.

	
	What brand of CDs to use
	------------------------

	This is another canonical question. Some people made a big
	story out of the color of the CD recordables. Some say, CDs
	with a golden surface finish are better than blue ones,
	and the best are those halfway transparent ones with also
	a golden surface. Forget that - it's not a question of
	color, it's a question of quality. The more care has been
	taken on putting a incredibly thin layer of finish onto the
	CD in the factory the better it will perform in your CD-recorder.
	Currently I use CDs from Philips which have an overall excellent
	performance for both data and audio. But since I don't know
	which manufacturer is hiding behind "your" flavour of Philips-CDs
	I hestitate to directly recommend it... It's best to go and try
	for yourself. As a rule of thump you should notice that the
	most expensive brands of manufacturers like TDK, Maxell or
	Sony are not necessarily your best buy...


	The SCSI troubles	
	-----------------

	If you first equip your system with a SCSI adaptor, together with
	other SCSI hardware, you will sooner or later stumble across the
	somehow stupid kinda way Linux handles this wonderful interface.
	There are generic devices, logical devices, charakter devices,
	block devices... Why all that fuzz?

	First there were some practical thoughts about the need to transfer
	software applications from one unixish system to another. The amount
	of time you probably spend on reprogramming one application for
	another system (say when coming from SunOS and moving to HP-UX) is
	called 'portability', and this variable should be as low as possible
	in terms of time and money spent to conduct some extensive
	porting projects.
	On the mass storage side Linux offers its generic SCSI devices
	as a clean and fast method of communicating with all kinds of
	SCSI hardware, say Scanners, disc retrieval systems, CD recorders
	and so forth. Because every device has its own features and therefore
	needs special commands from a higher level software you will need
	some interface between the software application and the device;
	the generic SCSI devices provide this interface.

	On the other hand, handling (and correctly naming) these generic
	devices are no fun at all, especially when coming from a pure
	IDEish background. So, for example, what are block devices,
	character devices, and why not communicating directly with
	the SCSI hardware instead of all that driver and interface
	mess?

	At first we take a look at the character devices, such as the
	memory, the (virtual) terminals and the generic SCSI devices.
	All of them are interfaces for programs and libraries to control
	applied hardware. Next there are the block devices, such as
	the floppy disk drive, the harddisks and the CD-ROMs; with
	these you can directly send data to the attached hardware,
	in a common way all block devices can process. Unfortunately
	this is not possible with devices like CD recorders, because
	a normal Linux kernel and its devices do not know how to
	"speak" to a laser device burning little grooves into
	coated plastic discs :)
	Here the system depends on the software, and the software makes
	use of the generic low level SCSI devices found in /dev of your
	Linux box to control the dice. Proprietary, specially designed
	procedures can then be performed by hardware like CD recorders
	or Scanners where it's necessary to control a small step motor
	via the SCSI bus in order to position the scan device. This
	complex flow of commands can not be a part of a standard kernel
	SCSI subsystem as it would break all rules of size and function;
	furthermore, endless orgies of errors would result in the fact
	that every single proprietary command of every single device
	attached to the bus had got to be in the kernel or at least
	present as loadable module. You sure will agree that this would
	ruin the advantages of Linux compared to some whacky Windows
	machine...!


	Why no "cdwrite" anymore?
	-------------------------
	
	This reference table shown below (taken from the CD-Writing-HOWTO)
	describes why this change took place:

	Feature         cdwrite-2.1     cdrecord-1.6
	--------------------------------------------
	ATAPI support   no              yes
	Multisession    only partial    yes

	RockRidge       yes (mkisofs)   yes (mkisofs)
	El Torito       yes (mkisofs)   yes (mkisofs)
	HFS             yes (mkhybrid)  yes (mkhybrid)
	Joliet          yes (mkhybrid)  yes (mkhybrid)

					*

SUPPORT
=======

If you have any problems running the tools included in this archive or if
you don't understand some of my previous utterances, feel free to send
me some mail, I will try to help you. Please read this file completely
before sending in any comments, and be sure to include the following
information:

- manufacturer and name of SCSI-adaptor
- name and version of the Linux distribution
- version of the tool or script which gives you trouble
- wether you're using the tools and scripts in the shell or X-window
- general system information (CPU, memory, harddisks...)

Thank you.

(w) 1998,1999 Boris M. Lorenz (bolo@cts-gmbh.com)
[EOF]
