hi zenterz, actually I am bassically interested in data-cd writing but that goes wrong, so writer sg0 and reader sr0? piet zentara wrote:

On Tue, 02 Apr 2002 15:17:40 +0200 PR <prooroa@wanadoo.nl> wrote:

...

hi zentara, I always thought my cdrom and cdwriter (both scsi) would be in /dev/scsi or something, but they 're not, should they? the cdrom is working ok, the writer used to... now I have problems with my cdwriter refusing to eject my cd giving me a warning: kernel: cdrom(ioctl) reports ILLEGAL REQUEST. I looked if I had scsi emulation on by mistake, but I don't I use an Adaptec 2930 adapter

On mine, when it's a reader, it's /dev/sr0 when it's a writer, it's /dev/sg0.

many people have a tough time with Xcdroast, it is best to use cdrecord directly. Xcdroast uses cdrecord, so you may as well go to the source. :-)

Here is a snippet from a howto.

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 "cat2" ==========

cat2 /dev/scd0 -o /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 "cat2" 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 who exceed this limit and are also able to create special tables within each mastered directory with references to the real file names. cat2 instead only concatenates all files to one big file and keeps the filenames unchanged. So, cat2 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 device-name "sgb" is the generic SCSI device "b". SCSI-id 2 is "sgb", SCSI-id 3 is "sgc", and so forth. So, if your CD-ROM device is using SCSI-id 5 the generic SCSI device would be "sge". You get the picture. 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

cat2 /dev/scd0 -o /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 2. Afterwards "cdda2wav" is used to copy the five audio-tracks (beginning from step 2 because the data-track represents step 1).

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

EXAMPLE 5: Writing an image-file mastered with mkisofs (like in ========== EXAMPLE 1) or cat2 (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. $$$$$ You can insert the -dummy switchto test: cdrecord -v -dummy -eject speed=3 dev=1,0 /D/image.raw then if test passes: cdrecord -v -eject speed=3 dev=1,0 /D/image.raw ---------------------------------------------------------------------------

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.

These eight examples should suffice the most common procedures of creating CDs. Sounds easy? Well, it IS 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 for more info.

Always keep in mind to take reference to the documentation shipping with cdrecord, mkisofs or cdda2wav for more options and 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 corresponding docs would be a good idea.

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.

*

AFTER A SHORT WHILE, CDRECORD SHOWS 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 cat2 ARE INACCESSIBLE IN MS DOS

Like mentioned before, cat2 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 cat2 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, cat2 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 and see what's 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 cat2 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 cat2 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...

On-The-Fly copying of CDs -------------------------

"mkisofs", together with "cdrecord", is able to directly stream data from a mounted directory to the CD-recorder without creating any image file at all. This can be done with:

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

This pipes the output of /home/tom to cdrecord which writes it to the CD-recorder attached to SCSI-id 5, LUN 0.

This is a very smart way of creating backups on the fly, especially if you keep in mind that you don't necessarily have to finish the CD at once but you can append new sessions to it step by step till it's full, but - there's always a chance of complete loss of data if one session gets corrupted by a system crash or SCSI-error of some sort. Remember that creating a CD is a tough task for the system. There's not much space in the SCSI-buffers for other data left... To be blunt: Use On-The-Fly only on reasonably fast machines (Pentium 166 and up) and try to keep the concurrent load of your system as low as possible.

SCSI troubles -------------

If you experience unusual SCSI-errors make sure your kernel has been compiled with generic SCSI and the appropriate driver for your host-adapter. Check your kernel-configuration. If you do not know how to do this, refer to the documentation shipped with your Linux distribution, or otherwise ask ;)

*

SUPPORT =======

If you have 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-adapter - 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.

ACKNOLEDGEMENTS ===============

Credits are due to Joerg Schilling for his excellent "cdrecord" tool, and to Linux for existing. At least, why not.

(w) 1998 Boris M. Lorenz (cidher@usa.net) [EOF]