> > > > "Another possibility, if you have the RAM, is to use the team(1)
> > > > program (it's in the ports) to buffer the data as it goes to the burner.
> > >
> > > Any reason not to use ``cdrecord -fs=64m'' (or some simular size)
> >
> > Any reason to? I mean, I never had to go over the defaul
> As David O'Brien wrote ...
> > > "Another possibility, if you have the RAM, is to use the team(1)
> > > program (it's in the ports) to buffer the data as it goes to the burner.
> >
> > Any reason not to use ``cdrecord -fs=64m'' (or some simular size)
>
> Any reason to? I mean, I never had to g
> Then there is no advantage in using `team' vs. ``cdrecord -fs=XX'', right?
>
> --
> -- David([EMAIL PROTECTED] -or- [EMAIL PROTECTED])
As far as I can tell there is no difference other one component less to use
and ease of use.
Cheers
--
Amancio Hasty
[EMAIL PROTECTED]
> > > "Another possibility, if you have the RAM, is to use the team(1)
> > > program (it's in the ports) to buffer the data as it goes to the burner.
> >
> > Any reason not to use ``cdrecord -fs=64m'' (or some simular size)
>
> Any reason to? I mean, I never had to go over the default cdrecord u
As David O'Brien wrote ...
> > "Another possibility, if you have the RAM, is to use the team(1)
> > program (it's in the ports) to buffer the data as it goes to the burner.
>
> Any reason not to use ``cdrecord -fs=64m'' (or some simular size)
Any reason to? I mean, I never had to go over the def
> If you have the physical memory sure however if you don't then
> you will start swapping and most likely your cd recording will
> fail.
>
> Hence my recommendation for a small size buffer.
Then there is no advantage in using `team' vs. ``cdrecord -fs=XX'', right?
--
-- David([EMAIL PRO
>If you don't have the time to trim, we don't have the time to read your
Easy , Easy we are coming along fine so far so please keep
the flame temperature down. If you are compelled or annoyed
at the poster send him private e-mail and possibly a pointer
to net - etiguette. If you do it nicely you
If you have the physical memory sure however if you don't then
you will start swapping and most likely your cd recording will
fail.
Hence my recommendation for a small size buffer.
And to the list.
Please keep the comments or suggestions rolling and hopefully
by early next we will have a nice
On Fri, Aug 20, 1999 at 01:04:47PM +0200, Werner Griessl wrote:
Werner, like you we all got 246 line email message. You did not have to
quote the *ENTIRE* thing back to us just to add 3 lines.
If you don't have the time to trim, we don't have the time to read your
reply.
--
-- David([EMA
> "Another possibility, if you have the RAM, is to use the team(1)
> program (it's in the ports) to buffer the data as it goes to the burner.
Any reason not to use ``cdrecord -fs=64m'' (or some simular size)
--
-- David([EMAIL PROTECTED] -or- [EMAIL PROTECTED])
To Unsubscribe: send mail
On Fri, Aug 20, 1999 at 01:04:47PM +0200, Werner Griessl wrote:
#
# Don't forget cdrdao, it's able to read and burn "video(cdi)"-cd's.
# Successfully done here with a philips cdr2600 burner for a philips cdi player.
# It's also in ports.
>From what I recall, tosha's been able to deal with vcd's
On 20-Aug-99 Amancio Hasty wrote:
> This is a summary of the information that I gather over the last
> few days with respect to CD recorders.
>
>
> It appears that the preferred and better supported CD recorders are
> scsi . To shorten the gap what is needed is for ATAPI cd recorders
> to be i
This is a summary of the information that I gather over the last
few days with respect to CD recorders.
It appears that the preferred and better supported CD recorders are
scsi . To shorten the gap what is needed is for ATAPI cd recorders
to be integrated into CAM so that we may present a unifi
13 matches
Mail list logo
