[Libburn] Announcing cdrskin 0.1.0

scdbackup at gmx.net scdbackup at gmx.net
Fri Jan 13 03:28:38 PST 2006


Hi,

> It would be very interesting to test cdskin as a replacement of
> cdrecord for nautilus-cd-burn. I am the developer of Serpentine[1], a
> audio-cd writer software which uses nautilus-cd-burn. So if serpentine
> works with cdrskin that means that:
>  1- cdskin is compatible with nautilus-cd-burner (at least in the audio part)
>  -2 cdskin can burn audio cds

Could you please find out what calls of cdrecord are issued
by nautilus-cd-burn resp. serpentine ? 
Our task would obviously be to identify the options yet 
unsupported by cdrskin and to find appropriate ways to
perform their semantics via libburn.

Is there some technical specs of nautilus-cd-burn ?
I googled "nautilus-cd-burn":
... result list begins with the rumor that nautilus-cd-burn is
    being switched to libburn ...
... "nautilus-cd-burner" brings better results ...
... "libnautilus-burn" ...
... http://s1x.homelinux.net/projects/libnautilus-burn-python ...
Oh, hello Tiago ! :))
You are the guy to ask where to find that libnautilus-burn 
sourcecode.


I got the suspicion that K3b 0.10 kills the ability of my
CD devices to load the tray on read attempt. At least after
i run it in my absolutely non-KDE-non-Gnome desktop environment.
(Still using up the old .fvwmrc files which i got since a decade.)

So i am not too eager to experiment with Nautilus myself.


> As a side note, could libburn be released as LGPL?
> One problem I'm facing with serpentine is that nautilus-cd-burner is GPL.
> 
> Since GPL is incompatible with patent libraries it's incompatible with
> gstreamer's mp3 decoding plugin.
> 
> If libburn was LGPL I could change serpentine's license to LGPL and
> ship it with gstreamer+mp3 whithout licensing problems.

I would love to release it under a less restrictive
license. Usually i publish under BSD license which is
quite free of lawyers' artwork and therefore very fair
to programmer and user.

You may have the current source of the cdrskin wrapper
under BSD and then spawn your own desired license.
(I am quite opposed to those license splits but if one
 has to cope with GPL one has to make compromises ...)

I would have to look wether there is still real code
from Derek's test/*.c programs in it. I hope he isn't
picky by byte. Overall it is my own handwork.
The largest piece of potential Derek original code i can 
find is in cdrskin.c,Cdrskin_blank():
 while(burn_drive_get_status(drive,NULL))
   sleep(2);
 while ((s = burn_disc_get_status(drive)) == BURN_DISC_UNREADY)
   sleep(2);
I think that's free of copyright claims, isn't it, Derek ?
There are a few more original lines in Cdrskin_burn(). One will
recognize them by the different style of using blanks.


Nevertheless the essential work is done by libburn
which is under GPL. In order to avoid collisions with
the unpatched libburn i currently link the cdrskin
wrapper code with the .o files from libburn-0.2.ts.
If libburn was LGPL then i'd see no obstacle on my side
to make cdrskin LGPL. If cdrskin would use a LGPL libburn
via dynamic linking then even a BSD license for cdrskin
would become possible.
But i still hope to get cdrskin a part of libburn and
thus i will mainly try to stay compatible with the libburn
license.

We should first solve the technical issue and then try
to convince the copyright holders of libburn. :))
There is an invitation to co-developers in the preamble of
cdrskin.c . I will make it now:
"Interested users of cdrecord are encouraged to contribute further option
 implementations as they need them. Contributions will get published under GPL
 but it is essential that the authors allow a future release under LGPL and/or
 BSD license."

Would a potential BSD license for your own contributions be
an obstacle for you ? Do you know people who would seriously
refuse to cooperate under such a precondition ?
(A contributor who insists in LGPL would make BSD impossible.
 A contributor who insists in BSD did not read the license terms.:))


As a starter i'd like to ask you for trying wether the
data usage examples from cdrskin's README do work for you.
I would also be interested to learn wether the two binaries of
cdrskin run on your system. (I swear they are free of any malicious
code from my side and they run nicely for low-priviledged users.)

Get an overview of cdrecord style addresses of available devices
    cdrskin -scanbus 

Obtain some info about the drive
    cdrskin dev=1,1,0 -checkdrive 

Obtain some info about the drive and the inserted media
    cdrskin dev=1,1,0 -atip 

Thoroughly blank a CD-RW
    cdrskin -v dev=1,1,0 blank=all eject_device=/dev/cdrom -eject 

Blank CD-RW sufficiently for making it ready for overwrite
    cdrskin -v dev=1,1,0 blank=fast eject_device=/dev/cdrom -eject 

Burn image file  my_image.iso  to CD
    cdrskin -v dev=1,1,0 speed=12 fs=8m -sao driveropts=burnfree padsize=300k \
            eject_device=/dev/cdrom -eject  my_image.iso 

Burn compressed afio archive to CD on-the-fly
    find . | afio -oZ - | cdrskin -v dev=1,1,0 fs=32m speed=8 -sao \
                                  driveropts=burnfree padsize=300k tsize=650m - 

You may burn multiple data tracks like with cdrecord but i
do not see much use for such a CD structure yet. This feature
is just a preparation for future audio enhancements.

There is option -dummy to avoid media waste while testing.
My LG GSA burner does not obey it in RAW96 mode, though.


In any case i would be interested to learn about the cdrecord
gestures of your package.


Have a nice day :)

Thomas



More information about the libburn mailing list