Very Computer

I did find the reason of my late error message : "The TOC of this CD
reports an impossible track size...". There is, in xcdroast, a feature
that is somewhat confusing. If you press the "verify burnt CD" right
after a simulation, it does not reckognize the CD and speaks out said
error message. Once this has happened, the CD is wasted and you have to
throw it out.

I then made a test in not making use of the verify button after
simulation ; I did physically burn the cd and verified only afterwards.
this time, it worked... but not as I would have expected. The verify
function says :

"verify failed !    Files differ on block 17 !"

However, the burnt cd is readable in either one of my two cdrom drives ;
I can find the copied files, open them etc... There must be some wrong
files somewhere, but I haven't discovered them yet.

I understand that the reason of such failure may be on the burning speed
(X2), but, what I would like to know is how to carry a check on the
simulated burnt image rather than on the burnt cd, when it is too late.
As previously said, the "verify burnt image" on a simulated burnt image
fails and wastes the CD.

Thanks for any hint

and Happy New Year to everyone !

]files somewhere, but I haven't discovered them yet.

]I understand that the reason of such failure may be on the burning speed
](X2), but, what I would like to know is how to carry a check on the
]simulated burnt image rather than on the burnt cd, when it is too late.
]As previously said, the "verify burnt image" on a simulated burnt image
]fails and wastes the CD.

You cannot verify a simulated burn. Nothing was burned. Tehre is nothing
on the CD to verify. It is still a blank pristine CD waiting to have
something written to it, untouched by a laser.

xcdraost (the latest .98) has a little bar while the burning is going on
which shows how full your FIFO is. It should sit up there around 90%. If
it drops repeatedly to less than 50% you should worry.
I burn CDs at 8x ( bigger than 2x) on a P233 machine with no trouble. Not ssure what
yours is, but 2x should not be the problem unless you are running
someting in the background.
This is the ONLY reason for simulation-- to see if the fifo stays
relatively full during a burn, or whether you are burning faster than
your system can handle.
(Note that xcdroast .98test8, the latest, has a bug where when burning
audio tracks it briefly shows the buffer as empty (0%) between tracks.
This should not happen, as it is not true. So if it sits at 90-100% and
just dips to 0% each time the new track is sarted to burn, do not worry
about that. It is the dips to 30% or whatever during the burning of a
track that should worry you.

Note, I do not know what you think your CD is wasted. It should simply
have come back with an error message, since the CD has nothing burned on
it at all. Ie, you should still be able to use that CD to burn an image
onto it.

Quote:

> I burn CDs at 8x ( bigger than 2x) on a P233 machine with no trouble. Not ssure what
> yours is, but 2x should not be the problem unless you are running
> someting in the background.

Quote:

> This is the ONLY reason for simulation-- to see if the fifo stays
> relatively full during a burn, or whether you are burning faster than
> your system can handle.
> (Note that xcdroast .98test8, the latest, has a bug where when burning
> audio tracks it briefly shows the buffer as empty (0%) between tracks.
> This should not happen, as it is not true. So if it sits at 90-100% and
> just dips to 0% each time the new track is sarted to burn, do not worry
> about that. It is the dips to 30% or whatever during the burning of a
> track that should worry you.

> Note, I do not know what you think your CD is wasted. It should simply
> have come back with an error message, since the CD has nothing burned on
> it at all. Ie, you should still be able to use that CD to burn an image
> onto it.

Quote:> Hi there,
> I did find the reason of my late error message : "The TOC of this CD
> reports an impossible track size...". There is, in xcdroast, a
> feature that is somewhat confusing. If you press the "verify burnt
> CD" right after a simulation, it does not reckognize the CD and
> speaks out said error message. Once this has happened, the CD is
> wasted and you have to throw it out.
> I then made a test in not making use of the verify button after
> simulation ; I did physically burn the cd and verified only
> afterwards. this time, it worked... but not as I would have
> expected. The verify function says :
> "verify failed !    Files differ on block 17 !"
> However, the burnt cd is readable in either one of my two cdrom
> drives ; I can find the copied files, open them etc... There must be
> some wrong files somewhere, but I haven't discovered them yet.
> I understand that the reason of such failure may be on the burning
> speed
> (X2), but, what I would like to know is how to carry a check on the
> simulated burnt image rather than on the burnt cd, when it is too
> late. As previously said, the "verify burnt image" on a simulated
> burnt image fails and wastes the CD.

That said, I did use xcdroast for a while, but its incorporation of
internal versions of mkisofs and cdrecord can be both a blessing and a
prisoners ball and chain.  The blessing is that its dead stable.  I
first recompiled it to use the newer versions, but the gui itself only
knows about what the older versions can do, so thats a waste of time and
effort.

I've been using GToaster (aka Gnome Toaster) because that allows one to
update cdrecord etc, 95% of the time without breaking anything.  Its
also being developed at a higher pace than xcdroast with at least 4
releases in the last half of '00 to date, 12 hours to go here.

Cheers, Gene
--

        email gene underscore heskett at iolinc dot net
#Amiga based X10 home automation program EZHome, see at:#
# <http://www.thirdwave.net/~jimlucia/amigahomeauto> #
ISP's please take note: My spam control policy is explicit!
#Any Class C address# involved in spamming me is added to my killfile
never to be seen again.  Message will be summarily deleted without dl.
This messages reply content, but not any previously quoted material, is
? 2000 by Gene Heskett, all rights reserved.
--

The latest version of xcdroast (.98test8) does allow the inclusion of
the new cdrecord (1.9 I think) etc. It also allows the use of more of
the properties of cdrecord ( bootable disks especially).

]I've been using GToaster (aka Gnome Toaster) because that allows one to
]update cdrecord etc, 95% of the time without breaking anything.  Its
]also being developed at a higher pace than xcdroast with at least 4
]releases in the last half of '00 to date, 12 hours to go here.

Well, xcdroast I think has had about 8 but then those are "test
versions. Until test6, the author advised sticking with .96 but now he
advises switching even though .98 is not yet finished. It works well-- a
few cosmetic bugs (The audio play says it is playing a new track but
keeps playing the old one in certain conditions, the fifo buffer report
reports an empty buffer between tracks, when it is not empty) Not that
I have tried GToaster.
-- Just did Certainly a very different layout from xcdroast, and the
cdplayer software has a hard time keeping the buffer fulll- all sorts of
glitches in the playing of a file. (woops that was the ESD sound system,
the OSS seems to work much more reliably).

So many possibilities. Isn't Linux frustrating and great. It reminds me
of collegues from Russia who visited me in the late 70's. The would go
into a department store and just wander for hours unable to buy anything
because there was so much choice.

 BU> Well, xcdroast I think has had about 8 but then those are "test
 BU> versions. Until test6, the author advised sticking with .96 but
 BU> now he advises switching even though .98 is not yet finished.

I take it not all of these have been advertised on Freshmeat then, I
don't recall that many, 3 maybe.

 BU> It
 BU> works well-- a few cosmetic bugs (The audio play says it is
 BU> playing a new track but keeps playing the old one in certain
 BU> conditions, the fifo buffer report reports an empty buffer
 BU> between tracks, when it is not empty) Not that I have tried
 BU> GToaster.
 BU> -- Just did Certainly a very different layout from xcdroast, and
 BU> the cdplayer software has a hard time keeping the buffer fulll-
 BU> all sorts of glitches in the playing of a file. (woops that was
 BU> the ESD sound system, the OSS seems to work much more reliably).

Thats something I hadn't tried at all, I use xmms for all that, and with
an SBLive, its not OSS or ESD dependant, using emu10k1 built as a module.

 BU> So many possibilities. Isn't Linux frustrating and great. It
 BU> reminds me of collegues from Russia who visited me in the late
 BU> 70's. The would go into a department store and just wander for
 BU> hours unable to buy anything because there was so much choice.

Thats a pretty darned good description, Bill.

Part of my problem is that I tend to only dig into what has immediate
utility for me, or possibly at the tv station.  The other part is of
course the limited number of hours in a day that I can honestly say that
what I do is a learning experience, at 66 they seem to be getting
scarcer, which is at times quite frustrating.

Cheers, Gene
--

        email gene underscore heskett at iolinc dot net
#Amiga based X10 home automation program EZHome, see at:#
# <http://www.thirdwave.net/~jimlucia/amigahomeauto> #
ISP's please take note: My spam control policy is explicit!
#Any Class C address# involved in spamming me is added to my killfile
never to be seen again.  Message will be automaticly deleted without dl.
This messages reply content, but not any previously quoted material,
is ? 2000 by Gene Heskett, all rights reserved.
--