Unless it is a factory pressed ROM medium you will have to determine the size of the ISO filesystem before copying it to hard disk. Most media types deliver more data than was written to them with the most recent burn run.

+

You should determine the size of the ISO filesystem before copying it to hard disk. Most media types deliver more data than was written to them with the most recent burn run.

Use program {{ic|isosize}} out of package {{Pkg|util-linux}} to obtain the image size

Use program {{ic|isosize}} out of package {{Pkg|util-linux}} to obtain the image size

About the changes on the wiki

Hello. I appreciate your great interest and I agree with some of your requests, especially on clarity. Do not use the main page for experience any changes, because it is a reference page for the entire community. You have to follow a path, discuss the changes, what to change and how to change, apply a "template" to signal to the whole community of possible changes etc. .. Also, any changes must be described on the main page, and in the event of major changes effettualri step by step. Other users can't understand all the changes made. This procedure may seem slow, but considering that it is not a personal wiki, but Community. good weekend.Veleno (talk) 11:00, 27 July 2013 (UTC)

It is well understood that i need approval. Especially since i am an interested party in the field of optical media. The proposed changes are listed at the talk page. What kind of approval do i have to wait for ?

How do i apply a "template" ? (I guess it is a way to expose an implemented proposal for approval.)

Your proposed changes are wide margin, reflecting a possible reorganization of the entire page. You rightly point out that there are gaps and that it can improve the whole. I answered you on the talk. I think you can from your proposal to amend the best across the page, for example, by combining the relative sections of CD and DVD in one section. does not exist a body that approves, you expect a few days, if no one dissenting opinions, you can operate to change. What you propose is not a small change, but I think a broader change that, in my opinion, it should be well organized. that's all. I apply a template that links to the discussion. ;) Veleno (talk) 11:37, 27 July 2013 (UTC)

Test area

Burning

<!ex CD burning , replacing section 1>

The burning process of optical disc drives consists of creating or obtaining an image and writing it to an optical medium. The image may in principle be any data file. If you want to mount the resulting medium, then it is usually an ISO 9660 filesystem image file. Audio and multi-media CDs are often burned from a BIN file, under control of a TOC file or a CUE file which tell the desired track layout.

Install burning utilities

The programs listed here are the back ends which are used by most free GUI programs for CD, DVD, and BD. They are command line oriented. GUI users might get to them when it comes to troubleshooting or to scripting of burn activities.

You need at least one program for creation of filesystem images and one program that is able to burn data onto your desired media type.

The traditional choices are wodim for CD and growisofs for DVD and Blu-ray Disk. For growisofs and BD-R see the bug workaround below.
For writing TOC/CUE/BIN files to CD, install cdrdao.

The free GUI programs for CD, DVD, and BD burning depend on at least one of the above packages.

The programs genisoimage, mkisofs, and xorrisofs all three support the genisoimage options which are shown in this document.

The programs cdrecord, cdrskin, and wodim all three support the shown wodim options. Program xorrecord supports those which do not deal with audio CD.

Note:

The installed files of packages cdrkit and cdrtools are in conflict.
If you want to install cdrtools, make sure that you build a package using makepkg and install with pacman. Pacman wrappers may resolve to cdrkit instead.

Enables the recognition of "pathspecs" which consist of a target address in the ISO filesystem (e.g. "/photos") and a source address on hard disk (e.g. "/home/me/photos"). Both are separated by a = character.

So this example puts disk directory /home/me/photos into ISO as directory /photos, disk directory /home/me/mail into ISO as /mail, and /home/me/holidays/photos into ISO as /photos/holidays.

Programs mkisofs and xorrisofs accept the same options. For sincere backups consider to use xorrisofs with option --for_backup, which records eventual ACLs and stores an MD5 checksum for each data file.

Learning the name of your optical drive

For the remainder of this section the name of your recording device is assumed to be /dev/cdrw.

Check this by

$ wodim dev=/dev/cdrw -checkdrive

which should report "Vendor_info" and "Identification" of the drive.
The next guess could be /dev/sr0.

If no drive is found, check whether any /dev/sr* exist and whether they offer rw-permission to you or your group.
If no /dev/sr* exists then try

$ modprobe sr_mod

Reading an ISO image from a CD, DVD, or BD

<!ex Making an ISO image from an existing CD, replacing section 1.8>
(moved before sections about burning)

You should determine the size of the ISO filesystem before copying it to hard disk. Most media types deliver more data than was written to them with the most recent burn run.

Use program isosize out of package util-linux to obtain the image size

$ blocks=$(expr $(isosize /dev/cdrw) / 2048)

Have a look whether the obtained number of blocks is plausible

$ echo "That would be $(expr $blocks / 512) MB"

That would be 589 MB

Then copy the determined amount of data from medium to hard disk

$ dd if=/dev/cdrw of=isoimage.iso bs=2048 count=$blocks

Omit count=$blocks if you did not determine the size. You will probably get more data than needed. The resulting file will nevertheless be mountable. It should still fit onto a medium of the same type as the medium from which the
image was copied.

If the original medium was bootable, then the copy will be a bootable image. You may use it as pseudo CD for a virtual machine or burn it onto optical media which should then become bootable.

Burning an ISO image

To burn a readily prepared ISO image file isoimage.iso onto an optical medium, run for CD:

$ wodim -v -sao dev=/dev/cdrw isoimage.iso

and for DVD or BD:

$ growisofs -dvd-compat -Z /dev/cdrw=isoimage.iso

The programs cdrecord, cdrskin, and xorrecord may be used on all kinds of media with the options shown with wodim.

Note:

Make sure that the medium is not mounted when you begin to write to it.
Mounting may happen automatically if the medium contains a readable filesystem. In best case it will prevent the burn programs from using the burner device. In worst case there will be misburns because read operations disturbed the drive.
So if in doubt, do:

# umount /dev/cdrw

Note:

growisofs has a small bug with blank BD-R media. It issues an error message after the burning is complete. Programs like k3b then believe the whole burn run failed.
To prevent this, either

format the blank BD-R by dvd+rw-format /dev/cdrw before submitting it to growisofs

or use growisofs option -use-the-force-luke=spare:none

Verifying the burnt ISO image

<!ex Verify the burnt ISO image , replacing section 1.5>

You can verify the integrity of the burnt medium to make sure it contains no errors. Always eject the medium and reinsert it before verifying. The kernel will learn about the new content only by that reinsertion.

First calculate the md5sum of the original ISO image:

$ md5sum isoimage.iso

e5643e18e05f5646046bb2e4236986d8 isoimage.iso

Next calculate the md5sum of the ISO filesystem on the medium.
Although some media types deliver exactly the same amount of data as have been submitted to the burn program, many others append trailing garbage when being read. So you should restrict reading to the size of the ISO image file.

Both runs should yield the same MD5 sum (here: e5643e18e05f5646046bb2e4236986d8). If they do not, you will propbably also get an i/o error message from the dd run. dmesg might then tell about SCSI errors and block numbers, if you are interested.

ISO 9660 and Burning On-The-Fly

(new section)

It is not necessary to store an emerging ISO filesystem on hard disk before writing it to optical media. Only very old CD drives at very old computers could suffer misburns due to empty drive buffer.

If you omit option -o from genisoimage then it writes the ISO image to standard output. This can be piped into the standard input of burn programs.

Option -waiti is not really needed here. It prevents wodim from writing to the medium before genisoimage starts its output. This would allow genisoimage to read the medium without disturbing an already started burn run. See next section about multi-session.

On DVD and BD you may letgrowisofs operate genisoimage for you and burn its output on-the-fly

Multi-session

(new section, in part from remaindings of "DVD burning")

ISO 9660 multi-session means that a medium with readable filesystem is still writable at its first unused block address, and that a new ISO directory tree gets written to this unused part.
The new tree is accompanied by the content blocks of newly added or overwritten data files. The blocks of data files, which shall stay as in the old ISO tree, will not be written again.

Linux and many other operating systems will mount the directory tree in the last session on the medium. This youngest tree will normally show the files of the older sessions, too.

Multi-session by wodim

CD-R and CD-RW stay writable (aka "appendable") if wodim option -multi was used

$ wodim -v -multi dev=/dev/cdrw isoimage.iso

Then the medium can be inquired for the parameters of the next session

$ m=$(wodim dev=/dev/cdrw -msinfo)

By help of these parameters and of the readable medium in the drive you can produce the add-on ISO session

Programs cdrskin and xorrecord do this too with DVD-R, DVD+R, BD-R and unformatted DVD-RW. Program cdrecord does multi-session with at least DVD-R and DVD-RW. They all do with CD-R and CD-RW, of course.

Most re-usable media types do not record a session history that would be recognizable for a mounting kernel. But with ISO 9660 it is possible to achieve the multi-session effect even on those media.

growisofs and xorriso can do this and hide most of the complexity.

Multi-session by growisofs

growisofs forwards most of its program arguments to a program that is compatible to mkisofs. See above examples of genisoimage.
It bans option -o and deprecates option -C.
By default it uses the installed program named "mkisofs". You may let it choose one of the others by setting environment variable MKISOFS

$ export MKISOFS="genisoimage"
$ export MKISOFS="xorrisofs"

The wish to begin with a new ISO filesystem on the optical medium is expressed by option -Z

$ growisofs -Z /dev/cdrw -V "ARCHIVE_2013_07_27" -r -J ./for_iso

The wish to append more files as new session to an existing ISO filesystem is expressed by option -M

Multi-session by xorriso

xorriso learns the wish to begin with a new ISO filesystem from the blank state of the medium. So it is appropriate to blank it if it contains data. The command -blank as_needed applies to all kinds of re-usable media and even to ISO images in data files on hard disk. It does not cause error if applied to a blank write-once medium.

BD Defect Management

(new section)

BD-RE and formatted BD-R media are normally written with enabled Defect Management. This feature reads the written blocks while they are still stored in the drive buffer. In case of poor read quality the blocks get written again or redirected to the Spare Area where the data get stored in replacement blocks.

This checkreading reduces write speed to at most half of the nominal speed of drive and BD medium. Sometimes it is even worse. Heavy use of the Spare Area causes long delays during read operations. So Defect Management is not always desirable.

cdrecord does not format BD-R. It has no means to prevent Defect Management on BD-RE media, though.

growisofs formats BD-R by default. This can be prevented by option -use-the-force-luke=spare:none. It has no means to prevent Defect Management on BD-RE media, though.

Additions to the list of GUI tools

Burn Backend Problems

If you experience problems, you may ask for advise at mailing list cdwrite@other.debian.org . Or ask for advise at the support mail addresses if some are listed near the end of the program's man page.

Tell the command lines you tried, the medium type (e.g. CD-R, DVD+RW, ...), and the symptoms of failure (program messages, disappointed user expectation, ...).
You will possibly get asked to obtain the newest release or development version of the affected program and to make test runs. But the answer might as well be, that your drive dislikes the particular medium.

Translators: What advise do you have for people who cannot communicate in english language ?

GUI program log indicates problems with backend program

(new section for section 6 "Troubleshooting")

If you use a GUI program and experience problems which the program's log blames on some backend program, then try to reproduce the problem by the logged backend program arguments.
Whether you succeed with reproducing or not, you may report the logged lines and your own findings to the places mentioned in section Burn Backend Problems.

See some typical messages about the drive disliking the medium, which can only be solved by using a different drive or a different medium. A different program will hardly help.