diff --git a/cdrskin/wiki_plain.txt b/cdrskin/wiki_plain.txt new file mode 100644 index 0000000..351395c --- /dev/null +++ b/cdrskin/wiki_plain.txt @@ -0,0 +1,212 @@ +-------------------------------------------------------------------------- + cdrskin Wiki - plain text copy +-------------------------------------------------------------------------- + +cdrskin is the cdrecord compatibility middleware of libburn. + +Its paragon, cdrecord, is a powerful GPL'ed burn program included in Joerg +Schilling's cdrtools. cdrskin strives to be a second source for the services +traditionally provided by cdrecord. Currently it does CD-R and CD-RW. +Its future ability to burn DVD media depends on the development of libburn. + +cdrskin does not contain any bytes copied from cdrecord's sources. +Many bytes have been copied from the message output of cdrecord +runs, though. The most comprehensive technical overview of cdrskin +can be found in cdrskin/README . + +-------------------------------------------------------------------------- + +cdrskin with CD media fails to match its paragon cdrecord on three major +fields: convenient TAO burn mode, multi session, audio features. + +Audio features are the only topic where cdrskin did not yet exploit current +libburn to the maximum. This is due to my own lack of audiophile motivation +and due to the lack of sincere users who provide me with cdrecord use cases, +help me to explore the original cdrecord behavior and serve as dedicated +testers for eventual newly introduced cdrskin audio features. + +cdrskin does not provide DVD burning yet. See advise to use dvd+rw-tools +at the end of this text. + +-------------------------------------------------------------------------- + +About the command line options of cdrskin: + +There are two families of options: cdrecord-compatible ones and options +which are specific to cdrskin. The latter are mostly used to configure +cdrskin for its task to emulate cdrecord. There are some, nevertheless, +which provide rather exotic unique features of cdrskin. + +The cdrecord-compatible options are listed in the output of + +cdrskin -help + +where the option "help" has *one* dash. +For these options you may expect program behavior that is roughly the +same as described in original man 1 cdrecord . + +Online: http://cdrecord.berlios.de/old/private/man/cdrecord-2.0.html + +The cdrskin-specific options are listed by + +cdrskin --help + +where the option "help" has *two* dashes. + +Those have no man page yet. Some are very experimental and should only be +used in coordination with the libburn developer team. +Some are of general user interest, though: + +-------------------------------------------------------------------------- + +--devices allows the sysadmin to scan the system for possible drives +and displays their detected properties. +The drives are listed one per line, with fields: + +libburn-drive-number sysadmin-device-file permissions : vendor type + +0 dev='/dev/sg0' rwrw-- : 'HL-DT-ST' 'DVDRAM GSA-4082B' + +This feature is valuable since cdrskin -scanbus will not give you +the device file name and its current permissions. +cdrskin will accept of course the proposed dev= option as address +for any usage of the drive. + +Different from cdrecord, cdrskin is intended to be run without special +privileges, i.e. no superuser setuid. It is intended that the sysadmin +controls drive accessability by rw-permissions of the drive rather than +by x-permission of the burn binary. To be usable with cdrskin, the drive +has to offer both, r- and w-permission. + +-------------------------------------------------------------------------- + +eject_device= is needed to work around yet broken tray ejection of +drives. cdrskin makes a bold shell call to program "eject" and regrettably +this program does not like our addresses for SCSI devices. +/dev/hdX work fine and /dev/sg0 is quite safely guess-translated to +/dev/sr0 . /dev/sg1 et.al. need the user's help. must work with eject. + +-------------------------------------------------------------------------- + +dev_translation= is needed to foist cdrskin to frontend +programs of cdrecord which do *not* ask cdrecord -scanbus but which make +own assumptions and guesses about cdrecord's device addresses. +cdrskin project - at least for now - refuses to try to provide a similar +guesswork but uses own cdrecord style addresses which have a mere +semi-automatic text mapping to real libburn addresses. See cdrskin/README, +"Pseudo-SCSI Adresses". + +If you need to foist cdrskin under a frontend then you may be lucky and +both ideas of an address coincide. Especially if the frontend has the +decency to ask its "cdrecord" via option -scanbus for a list of drives. +If not, look into the error protocol of the frontend, look at the output +of a run of cdrskin --devices and give cdrskin the necessary hint. + +If your frontend insists in using "0,0,0" and --devices reported +dev='/dev/sg0' resp. cdrskin -scanbus reported "1,0,0" then this +would be the appropriate translation + +dev_translation=+0,0,0+/dev/sg0 + +The "+" character is a separator to be choosen by you. +Currently i am not aware of the need to choose any other than "+" +unless you get playful with custom translations like + +dev_translation=-"cd+dvd"-1,0,0 + +See http://scdbackup.sourceforge.net/k3b_on_cdrskin.html +for an illustrated example with K3b 0.10 . + +-------------------------------------------------------------------------- + +--fifo_start_empty is a throughput enhancer for unsteady data streams +like they are produced by a compressing archiver program when piping to +CD on-the-fly. It makes better use of the general property of a FIFO +buffer to transport surplus bandwidth into the future. Yep. A time machine. +One-way, i fear. + +FIFO originally was introduced by cdrecord's author Joerg Schilling in order +to protect mediocre burner hardware from suffering buffer underruns +and thus producing misburns (at 1x speed on CD-R media at the price of a +DVD-RAM nowadays). This purpose would not justify a fifo any more - +given the limited life time of burners and the seamless underrun protection +of contemporary consumer drives. + +With an unsteady data stream the task of the buffer is to soak up peak +performance and to release it steadily at the drive's maximum speed. +The larger the buffer the more reserves can be built up and the longer +input drought can be compensated. + +Original cdrecord has the historical property, though, to first wait until +the buffer is completely filled. Best practice for fighting drive +underruns, of course. +With a very fat fs=# buffer (128 MB for 12x CD is not unrealistic) this +can cause a big delay until burning finally starts and takes its due time. + +--fifo_start_empty makes cdrskin start burning without waiting for the +FIFO to be full resp. the data stream to end. It can make use of the +seconds spend with drive preparation and lead-in, it risks a few drive +buffer underruns at the beginning of burn - but modern drives stand this. + +Note: no FIFO can give you better average throughput than the average +throughput of the data source and the throughput of the burner. +It can be used, though, to bring the effective throughput very close +to the theoretical limit. Especially with high speed media. + +-------------------------------------------------------------------------- + +--no_rc allows you to surely ban influence from systemwide or user specific +default settings of cdrskin. Possible locations for such settings: + +/etc/default/cdrskin + +/etc/opt/cdrskin/rc + +$HOME/.cdrskinrc + +-------------------------------------------------------------------------- + +tao_to_sao_tsize= allows the - actually unsupported - cdrecord option +-tao and defines a default track size to be used if - as custom with -tao - +no option tsize=# is given. + +As in general with cdrskin tsize=# the data source does not have to provide +the full annouced amount of data. Missing data will be padded up by 0-bytes. +Surplus data is supposed to cause an error, though. The burn will then +be a failure in any way. + +-------------------------------------------------------------------------- + +DVD advise: + +For burning of DVD media the cdrskin project currently advises to use +Andy Polyakov's dvd+rw-tools which despite their historic name burn +for me on above burner: DVD+RW, DVD+R, DVD-RW, DVD-R . + +http://fy.chalmers.se/~appro/linux/DVD+RW/tools + +They are not compatible or related to cdrecord resp. cdrecord-ProDVD +(now obsoleted by original source cdrtools cdrecord with identical +capabilities besides the license key). + +If there is sincere and well motivated interest, the cdrskin project could try +to employ growisofs as DVD burning engine. The cdrskin project would prefer to +wait for DVD support being included in libburn, though. +A very limited and specialized cdrecord-compatibility wrapper for growisofs +serves in my project scdbackup. It is not overly hard to make one that serves +some very few fixed use cases. + +To my knowledge, Linux kernels 2.6 do write to DVD+RW via block devices as +they would write to a traditional tape device. Try old tape archiver +commands with addresses like /dev/sr0 or /dev/hdc rather than /dev/mt0 . +I have heard rumors that DVD-RW in mode "restricted overwrite" would be +block device ready, too. My burner is not a real friend of DVD-RW and +in an experiment the burn worked fine - but the result was not identical +to the stream sent to the device. I had similar failure with DVD-RAM, too. + +Beware of the impact of a slow block device on overall system i/o buffering. +It is wise to curb its input to a speed which it is able to deliver to media. +Else your i/o dedicated RAM might buffer a big amount of stream data. + +-------------------------------------------------------------------------- +