l i n u x - u s e r s - g r o u p - o f - d a v i s
Next Meeting:
July 7: Social gathering
Next Installfest:
Latest News:
Jun. 14: June LUGOD meeting cancelled
Page last updated:
2003 Mar 07 00:00

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] Burning CD's in Linux
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] Burning CD's in Linux

On Wed, Mar 05, 2003 at 11:47:31AM -0500, Mike Simons wrote:
> On Tue, Mar 04, 2003 at 05:30:38PM -0800, Michael J Wenk wrote:
> > the general command I use is:
> > cdrecord dev=0,0,0 speed=8 -data -dao /tmp/myiso.iso
> [...] 
> > (my windows burner is also quite a bit faster than
> > my linux one, though I don't make as many coasters with linux.)
> Mike,
> Two things:
> - When you say the windows burner is faster, do you mean actual burn
>   time or your time spent to get a burn setup?
> - When you say you make coasters under Linux is that because the
>   cdrecord couldn't keep up with the data needs of the drive, or 
>   because you selected the wrong set of files?
> ... 
>   If the windows software actually burns to disk faster, it seems you
> should raise the "speed" option higher... to whatever your drive's rated
> speed is.  If the cdrecord is told to burn at the same speed as the
> windows software the burn time should be within a few seconds of each
> other.
>   Perhaps you lowered the burn speed because you are making coasters,
> and are making toasters due to buffer underruns... there are two options
> to look into to fix this:
> - cdrecord uses a buffer to send things to the drive, the default size 
>   4meg is the _minimum_ recommended size, it should be increased if you
>   are running high speed burns... check out the "fs" option.  The man
>   page talks about correct sizing of this buffer... then doing a number
>   of test runs (--dummy) to verify the speed and buffer are working
>   together.
> - cdrecord will run as a real-time process which will prevent other
>   normal CPU load from interfering with a data burn (*).  However,
>   in order to raise the scheduling mode from normal to real-time
>   the cdrecord process must be running as root.  If you normally run 
>   burns as a user you should try having cdrecord run as root even when
>   normal users run it... with chmod and such (example below).
> *: massive amounts of disk activity could still interfere with retrieving
>   the data from disk enough to cause buffer underruns.

There is a third option; if your drive supports buffer-underrun
protection, cdrecord can use it, but does not do so by default. Use
"driveropts=burnfree" as a parameter to cdrecord to enable the

[stuff on setting as SUID removed] 

Samuel Merritt
OpenPGP key is at http://meat.andcheese.org/~spam/spam_at_andcheese_dot_org.asc
Information about PGP can be found at http://www.mindspring.com/~aegreene/pgp/

Attachment: pgp00001.pgp
Description: PGP signature

LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
Sunset Systems
Who graciously hosts our website & mailing lists!