Re: cdrtools cdrecord/cdrecord.c
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
Reply to: