[Libburn] Re: How to pipe stdin to CD-RW ?

[Derek Foreman]

On Fri, 2 Dec 2005, scdbackup at gmx.net wrote:

> Hi,
>
> Derek, by some reason i do not get your replies via mail
> but can only see them in the archives.
> My own postings do reach me.
> Any idea why this happens ?

In technical terms, I believe this happens because your mail provider 
"sucks". :)

telnet mx0.gmx.de 25
Trying 213.165.64.100...
Connected to mx0.gmx.de.
Escape character is '^]'.
Connection closed by foreign host.

I've tested a few other times, and it very rarely answers.
Also, their secondary MX seems to be the same IP as their primary, which 
seems to me to be a little daft.

I think I've got a few gmail invites if you're interested... not sure how 
I'd mail you one though. :(

>>> Currently i could need help with
>>> - the stdin problem
>>
>> Wow, that's a pretty bizarre request.  The whole idea behind libburn was
>> that you'd have a C api instead of wrappers on shell scripts.
>
> My project works with the tools as they exist. (shrug)
> I presume you are familiar with the situation about
> ISO-9660, CD, DVD on Linux systems since the end-90s.

Aye.

> I notice the existence of libburn when i researched
> about the spectrum of cdrecord clones. My project is
> up since december 1999 and yours since december 2003.
> It is about time that i make some use of your work.

Thanks :)

>>>        int (*get_size)(struct burn_source *);
>> iirc, we need that information to tell us when to start messing
>> with the p subchannel.
>
> Bear with me. My closest encounter with CD entrails
> is a C2-scan by Joerg's readcd. I've also read something
> about grooves and 1 error per million (ouch !).

Not sure where you got 1 error per million... The hardware can recover 
from much more serious damage than that.  In fact, that C2scan most likely 
showed a few more than that. :)

>>> libburn doesn't do tao (yet.  when I finally write that,
>>> I'll make the next libburn release...)
>
> The advantage for backup purposes would be substantial.
> A buffer file not only eats disk space which might be
> in short supply, it also opens a whole world of security
> threats.
> Besides the license issues i prefer growisofs over
> cdrecord-ProDVD because it does not ask for any size.
> This is very helpful with compressed archives where
> the size is only known after they are finished.
>
> The padding trick for sao has the disadvantage to need the
> writing time for a full CD regardless of the payload size.

I'm wondering if it's possible to determine the size of the output in an 
initial pass that doesn't create an image file.  It'd really only have to 
stat all the files involved, and that information should probably stay 
around in cache long enough that the second pass won't duplicate the 
effort.

(I'm not saying I'm not going to write TAO, but I'd really like a 
consistent interface amongst the three)

> My current weird idea is to start with test/burniso.c and
> to enhance it to a writer which is usable for scdbackup.
> That would be in fact the beginning of a cdrecord skin
> for libburn.

I've always thought this would be a really nice thing to have, but never 
bothered to do it myself.

> I myself, nevertheless, will _at most_ be able to implement
> those cdrecord data features which i use and know.
>  dev= -scanbus -atip blank= -sao -tao tsize= -eject
>  -help -v padsize=300k fs=8m driveropts=burnfree -data
>  (probably some more)
>  source file address or "-"
> All the audio stuff, multi session, helping the ISO formatter,
> piping multi-volume star backups, ... would have to be done
> by others who know what it is supposed to do. (If libburn supports it.)

libburn supports audio.  I know how I'm going to write multi-session, but 
it'll be a while before I get to it.

What are multi-volume star backups?

> Let me state that this effort is not directed against cdrecord
> or Joerg Schilling. I myself will not strive to achieve the
> versatility of cdrecord. It is just for creating an alternative
> tool for CD data burning on Linux.
> (I do not consider the cdrecord forks as such alternatives.)

Well, I strive to make a library that's capable of that versatility. :)

> Questions :
>
> What mode did i get with  libburn-0.2/test/burniso  ?
> Should i add some burn_* call to choose a mode that is better
> suited for data backups ?

At a quick glance... input is mode1 (your basic "iso image"), output is 
DAO R96 - disc at once with all subcodes generated by the software.

Any mode, tao dao or sao, should be fine for writing backups from iso 
files.

> Should i issue a call to close the disk ?
> My burner makes three moaning sounds when it is beginning
> to read or blank the libburn-CDs. With cdrecord-CDs it doesn't.

That might be optical power calibration, which I'm not sure is required 
all the time.  The disc should be closed automatically at the end of the 
burn.

>> Always interested in new functionality.
>> a diff -pRuN would be great, thanks
>
> In all those years of C programming i never submitted
> a patch or used cvs.
> The follwing diff is run versus the current libburn-0.2.tar.gz.
>
> The output of
>  diff -pruN libburn-0.2 libburn-0.2.ts
> was a bit overwhelming because of configure's work.
> (If you want it, just ask me.)
>
> I therefore ran :
>  for d in libburn test
>  do
>    cd "$base"/libburn-0.2/"$d"
>    for i in *.[ch]
>    do
>      diff -puN "$i" ../../libburn-0.2.ts/"$d"/"$i"
>    done
>  done
>
> The function name  burn_file_source_new3  might be
> used as the final one (i am not familiar with your
> naming scheme).
> It could be wrapped around  burn_file_source_new
> if this function would support "-" as address of
> stdin or if we would abandon that feature and rely
> on /dev/fd/0 or /proc/self/fd/0.
>  struct burn_source *burn_file_source_new3(...)
>  { struct burn_source *src;
>    src= burn_file_source_new(...);
>    if(retd!=NULL)
>      src->fixed_size= fixed_size;
>    return(src);
>  }
> For now it is a modified full copy of burn_file_source_new.
>
> The names  burn_iso3  and  parse_args4  in test/burniso.c
> are just to keep the functions distinct from the originals
> during experimentation. They are intended as replacements
> of burn_iso and parse_args, though.

I'll look this over properly sometime next week, I'm under a lot of time 
pressure right now.

Sorry for the delay :/