Hi, > > informing you in advance about my upcoming cdrecord > > compatibility wrapper around libburn: cdrskin . > > What kind of advantage should this have? > > Cdrecord is opensource and portable to 30 different platforms. > > Why do you spend time on this?
The fundamental motivation is as always, of course: Curiosity, dark and stormy nights, the will not to give up on the first serious obstacle, the pride to see it working, ... Plus, there is the need to give scdbackup development a rest before the upcoming next stable release. :)) > What problem does it solve that cannot be solved by cdrecord? It is because of a long term strategic consideration. My backup tool can make use of three different formatters and three different burn facilities. In both categories, two of three are made by you: mkisofs, star, cdrecord for CD, cdrecord for DVD. With CD backups i did not have any alternative. Up to cdrskin there was only one processing chain where your software was not crucial (namely DVD via afio + growisofs). Such a monoculture is unhealthy. We all are not immortal and we all are prone to changes in our personal interests. One reason why i made a new google survey on CD writing in december was that troll who nearly let you pop a heart valve. (Don't get me wrong, but sometimes you are very unrelaxed.) Since quite a while i was looking for some way to write CDs without using cdrecord and without patching a Linux kernel. (Actually i would have expected a simple CD burn device driver to become part of the Linux system some day. But i am still waiting for a thing like that.) Whatever, a few weeks ago i discovered that there is libburn waiting for applications since february 2004. I began to explore its capabilities and limitations and managed to overcome two obstacles which would make it unsuitable for my own backup tool. cdrskin has become a useable program for data recording on CD meanwhile. As long as i do not write small amounts of data via a stdin pipe the performance is comparable to cdrecord. (The lack of TAO makes it necessary to announce generous track sizes in advance and to pad up the CD content. The same usability problem is present with cdrecord-ProDVD when writing DVD. Not with growisofs, though.) Joerg, i do not try to convince you that cdrskin is any better than cdrecord. I do not even try to convince myself although it has some loveable detail features in comparison to cdrecord. It would have been a waste to let libburn lying around in the web with a quite unknown GUI frontend and a few rather exotic language bindings. At least now it is ready for evaluation tests via cdrskin. You can submit it to K3b and it burns a data project. For my backup tool it provides a lean burner binary. I consider to prepare an extra lean version with reduced compatibility and feature set. Maybe some interested people help to add missing features and maybe it will open a path to get rid of the quarrel around patched cdrecord. http://scdbackup.sourceforge.net/cdrskin_eng.html See the positive aspect, Joerg. This time it is not a fork but an emulation. It is meant neither hostile nor obtrusive. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
