cdrdao

Hi all,

while doing the multiple copies thing, I got that I need a (in memory) 
copy of the Toc object, as I can't find any constructor to duplicate it, 
I'm using this bad hack:

   char *tocFileName;

   if ((tocFileName = tempnam(NULL, "toc")) == NULL) {
     message(-2, "Cannot create temporary toc-file: %s", strerror(errno));
     return 1;
   }

   if (tocEdit->toc()->write(tocFileName) != 0) {
     message(-2, "Cannot write temporary toc-file.");
     return 1;
   }

   tocEdit_->readToc(tocFileName);
   unlink(tocFileName);
   free(tocFileName);


It would be great if anyone has a better solution. A constructor for the 
Toc object will be great.

See you all :)

-- 
Manuel Clos
llanero@...

* Si no puedes hacerlo bien, hazlo bonito (Bill Gates)
* If you can't do it well, do it nice (Bill Gates)

Hey all,
        First off, thanks so much for a great set of tools.  This weekend
I had to master a bunch of wav files to cd. gcdmaster made it a breeze.

My burner is actually on my ibook, which is running linuxppc. On linuxppc,
the "play sample" functionality loses, since it appears that gcdmaster 
assumes that all linux is little endian.  

As I worked with gcdmaster, I kept wishing for a contextual menu.
It would be _really_ neat (And would really help with workflow) if
there was a right-click contextual menu with options such as:

        Play/Stop
        Cut
        Paste
        Insert track marker
        Zoom in
        Zoom out

Thanks for such great software,

        Jesse





-- 
jesse reed vincent -- root@... -- jesse@... 
70EBAC90: 2A07 FC22 7DB4 42C1 9D71 0108 41A3 3FB3 70EB AC90

pretty soon we're going to HAVE to have hypertext mail!
				--Tim Berners Lee. (8 Jan 1993 on www-talk)

Hi all!

... and also the problem with copying a CD with a single device.

My proposal is to add funcs to the GCDMaster class. We need RecordDao
and DuplicateDao, because are the only cases where extra high level
control is required. Since the dialogs are per Device and are
independent from the projects, there is no problem with the gcdmaster
object managing them.

So, the Audio Project requests to burn 5 copies of a Project. Instead of
calling CdDevice->RecordDao we will call gcdmaster->RecorDao that will
take care of calling CdDevice->RecordDao multiple times and also
requesting a new CD to be inserted.

For the duplication case, gcdmaster will start a CdDevice->ExtractDao
with a temporary name (we need a global temp dir in preferences!), and
after that it will start a CdDevice->RecordDao after requesting a new CD
to be inserted.

We should warn the user if multiple copies and on the fly are requested,
since only makes sense when you run out of space, gcdmaster should also
handle this to launch a Extract + many Records or always launch a
CdDevice->duplicateDao.

We can intercept the status signal in gcdmaster to know when a process
finished, or let the Progress Dialog inform gcdmaster.

We will have a queue of pending operations. Also we will have a list of
current operations, since it was already needed, because nowadays
gcdmaster will exit even if there is some recording going on!

If no one has objections I will implement it in the next days.

Any comments wellcomed.

-- 
Manuel Clos
llanero@...

* Si no puedes hacerlo bien, hazlo bonito (Bill Gates)
* If you can't do it well, do it nice (Bill Gates)

Hi!

I just compiled cdrdao-1.1.5 on my Alpha 164SX running RH 6.1 (with many
updates). I tried to copy an audio CD on the fly, but that failed (my
reader is an ATAPI Teac CD-540E and writer is a Teac CD-W58E) - probably
the reader is too slow.

That's not the problem, however. I'll just reduce the writing speed
or not use on-the-fly option at all.

Below are the warnings cdrdao has printed while it was busy and I'm not
sure what to do? If cdrdao cannot determine that, how can I?

WARNING: Could not determine if raw toc data is BCD or HEX. Please report!
WARNING: Using TOC data retrieved with generic method (no multi session
support).
WARNING: Use driver option 0x80000 or 0x100000 to assume BCD or HEX data.

Thanks, D.

PS: As I'm not on this list, please respond to me directly.

Hi all!

22/9/01:
* Blank CD Dialog now detects blanking end
* Progress Dialog: deactivate cancel button if a cancelation is in progress
* minor UI fixes

-- 
Manuel Clos
llanero@...

* Si no puedes hacerlo bien, hazlo bonito (Bill Gates)
* If you can't do it well, do it nice (Bill Gates)

Hi all,

I'm using cvs cdrdao.

My recorder is a Yamaha 8x8x24

When doing a blank...

Using libscg version 'schily-0.5'

0,0,0: YAMAHA CRW8824E	Rev: 1.00
Using driver: Generic SCSI-3/MMC - Version 1.2 (options 0x0000)

Blanking disk...
Blanking time: 2 seconds

Obviously, it returns before the blank is done. Anyway the blanking will 
finish without any problem.

Is this due to scslib or cdrdao??


Also, if I cancel the record process, I see the usual:
WARNING: Writing/simulation/read-test aborted on user request.

but gcdmaster still waits for cdrdao. cdrdao is still running, If I kill
cdrdao then I get:

?: Llamada al sistema interrumpida. Cannot send SCSI cmd via ioctl
This is: system call interrupted. Cannot ...

and gcdmaster freezes.

I kill gcdmaster. The recorder is also locked. Perhaps there is some
problem with the recorder?

I have not changed gcdmaster code related to this. I'm running
2.4.9-ac10. Can someone try to cancel a burning process?
I'm using CDRW media to do the tests.

-- 
Manuel Clos
llanero@...

* Si no puedes hacerlo bien, hazlo bonito (Bill Gates)
* If you can't do it well, do it nice (Bill Gates)

Hi all,

Andreas, can you implement the 0% and 100% messages in the blanking 
process? I will then catch them and start a timeout to show the progress 
bar in activity mode and a 100% when done.

Thanks.

-- 
Manuel Clos
llanero@...

* Si no puedes hacerlo bien, hazlo bonito (Bill Gates)
* If you can't do it well, do it nice (Bill Gates)

hi!

I tried to compile cdrdao-1.1.5 on my debian-potato system
with the following commands:

cd /usr/src/cdrdao
apt-get source cdrdao
cd cdrdao-1.1.5
dpkg-buildpackage 2> error (see attachment)

any clues how to solve the problem ?

-tzvetan

Manuel Clos wrote:

 > Andreas Mueller wrote:
 >
 >> Unfortunately, it will be named like "cd<pid>.toc" but I can change
 >> cdrdao to use a toc-file name given on the command line.
 >>
 >>> Well, gcdmaster should also handle in two runs the copy of a CD with a
 >>> single device, because cdrdao tells to change the CD but this won't be
 >>> visible to the user.
 >>>
 >>
 >> Oops, that's something we've missed. We would need some kind of two
 >> way communication with cdrdao to implement such interactive things.
 >> Maybe it is better to run separate read and write commands if
 >> doing non on-the-fly copies. This would also make the multiple copy
 >> stuff more easy.
 >
 >
 > Yes, I think implementing this in gcdmaster is easier, as gcdmaster must
 > handle it anyway. We can use two or more cdrdao runs, this way if
 > gcdmaster crashes only the current "burn in progress" cd will be made,
 > and not the 20 copies you asked for :)


I see what you mean. I thought about it and we could also let cdrdao do
the multiple copies. In remote mode it will send a certain message to
GUI and then wait for signal to continue with the next disk. The GUI
displays a message and sends the signal to cdrdao after the user has
confirmed the disk-change.

 >
 > Also, when we finish all this stuff we can have a release. It seems that
 > some people are getting perfomance problems with 1.1.5 and not with
 > 1.1.4. As well as some CDTEXT problems. It will be great to have a new
 > cdrdao release to fix them and to get out the new gcdmaster version.


What kind of performance problems were reported. I didn't notice such
reports?
I guess the CD-TEXT problem you mean are problems regarding setting up the
cue sheet, right?


About the release:

I'd like to complete the sub-channel stuff for cdrdao before we make
the next release. The major remaining task is the sub-channel reading
with the 'read-cd' command. This might take me a couple of weekends.
I hope you can wait this long. :)

Regards,
Andreas
-- 
Andreas Mueller                  Tel: +49 89 67808848
Ramsmeierstr. 1                Email: andreas@...
85579 Neubiberg, Germany

hi !

cdrdao-1.1.5 is working perfectly with 0x0 record flag - but
i've got a problem with the cd-text-record flag (0x10) - if anyone had
this problem solved please email me ... thanx in advance

cdrdao simulate --remote 9 -v0 --device 0,6,0 --driver generic-mmc:0x10
--buffers 10 /tmp/toc4d4qGD 
?: Input/output error.  : scsi sendcmd: no error
CDB:  5D 00 00 00 00 00 00 00 58 00
status: 0x2 (CHECK CONDITION)
Sense Bytes: 70 00 05 00 00 00 00 12 00 00 00 00 26 00 00 80
Sense Key: 0x5 Illegal Request, Segment 0
Sense Code: 0x26 Qual 0x00 (invalid field in parameter list) Fru 0x0
Sense flags: Blk 0 (not valid) error refers to data part, bit ptr 0 (not
valid) field ptr 0
cmd finished after 0.252s timeout 180s
ERROR: Cannot send cue sheet.
ERROR: Simulation failed.

-tzvetan

Gioele Barabucci wrote:


> your app is great, btw:
> 
> 1) can paranoia be updated to 9.8? or make the compilation process use the 
> lib found in my system...


I can do that if I find some time. You cannot use the library created by
the paranoia package because I have to make some slight changes to the
source code to make it compatible with cdrdao.

 
> 2) pccts are very non UNIXy and I think all the files written for them 
> will become unmainteable, at least they are more prone than files written 
> in flex/bison (or just lex/yacc).


Yes that's true. On the other hand the PCCTS is stuff is widely used by
IC-CAD groups so I don't think that it will vanish in future. I might have
to upgrade to the latest version though. Writing parsers with PCCTS is much
more easy than with flex/bison and the syntax description can be in form
like BNF. However, if someone re-implements the parsers with flex/bison I'll
take them as replacement for the PCCTS parsers.


> 3) what about some more --without- ./configure options? for example I'm 
> not interested in cddb, so I'd like to save some time (and possible bugs) 
> excluding it.


I don't like to put more branches in the software than absolutely required.
This means more testing effort for us. Usually, unused features like cddb
won't cause additional bugs if they are not used.


> 3a) --without-xdao


This makes sense. We will add this switch.


> 4) do you know that cue support is a little broken in 1.1.5? it does not 
> obey to FILE "X" BINARY directive, it always look for nameofcue.bin 
> (usually I use .iso instead of .bin).


That's a feature and described in the man page. Currently, cdrdao does not
support the full .cue format. At the time I did the cue parser implementation
I was in contact with a couple of users that requested the cue feature.
All of them meant that they've never seen a .cue file with multiple FILE
statement and the filename of the single FILE statement was usually wrong.
So we decided to do it this way.


> 5) .bz2 instead of .gz files. everybody has a bzip2 extractor nowaday, and 
> it is usefull for dialup users (most of the europeans).


Ok, I can do that for the next release.


> 
> bye bye
> 
> PS.: I'm not subscribed, CC me in case of reply
> 
> 


-- 
Andreas Mueller                  Tel: +49 89 67808848
Ramsmeierstr. 1                Email: andreas@...
85579 Neubiberg, Germany

Hi,

I've committed a couple of cdrdao related files which
implement the sub-channel writing. Currently, this
only works with the 'generic-mmc' and 'generic-mmc-raw'
driver.

If someone on the list wants to try it out you'll need
track images that already contain RW sub-channel data.
In the toc-file the sub-channel mode must be defined with
the 'TRACK' statement:

   TRACK <main channel mode> [ <sub-channel mode> ]

<sub-channel mode> may be

   o RW : the track image contains plain RW sub-channel data
          (additional 96 bytes per block)

   o RW_RAW: the track image contains already encoded (raw)
             sub-channel (additional 96 bytes per block)

If the recorder is just able to write raw sub-channels
cdrdao will encode given plain RW sub-channel data.

There is a new driver option for the 'generic-mmc' driver:

  0x80: indicates that the recorder does not support writing
        plain RW sub-channels, cdrdao will do the encoding
        and write them in raw mode

Please note that this new feature had a major impact on the
basic infrastructure of cdrdao so that now also the old non
sub-channel writing modes might have problems.

The next steps will be implementing PQ sub-channel writing
(only with the 'generic-mmc-raw' driver) and the extraction
of sub-channel data with the read-cd command.

Regards,
Andreas
--
Andreas Mueller                  Tel: +49 89 67808848
Ramsmeierstr. 1                Email: andreas@...
85579 Neubiberg, Germany