DVD only burn with 6x although media and burner are 16x


As the linux community here on cdfreaks seems a little small, I don’t know if there is anyone out there able to give me a hint on this, but it doesn’t hurt to try, right? :wink:

So well the problem is this: I can only burn dvd 's at 6x even though the media (Tried two brands: verbatim 16x and sony 16x) and the burner (optiarc ad7173) are 16x capable. It’s no transmission speed related problem (dma and everything is fine, also tried readcd to test it, gave me above 16000kB/s), I discovered it doesn’t give a higher speed as option (looking into dvd+rw-mediainfo gives a good clue: as current write speed 6x is selected…). So, although growisofs accepts the speed=16 command and starts saying speed is selected 16x, it never reaches it as internally something says: only 6x is available. And that’s what happens: takes about 13 mins and on the end says average write speed 6.1x or something. Any idea how to solve this ??? Firmware update maybe? At the moment I can’t test if this is linux specific, but seems to be… also tried cdrecord (wodim, from cdrkit), it also wants to start with only 6x…

You don’t mention your Linux distro or burning application.
At present i’m using an AD-7173A with ubuntu Studio and Nero Linux beta 3 and it burns at 18x without problems.

You can get Nero Linux 3 beta here. http://club.cdfreaks.com/showthread.php?t=216352

Small but growing. Welcome to CD Freaks.

I would expect the drive to have a proper write strategy for
Verbatim 16x media so it looks like something is wrong.

Try running "dmesg | grep DMA"
You should have DMA enabled for your DVD writer and your

If hdparm is installed on your system, you can use it to
check and change your DMA settings.

Is your hard-drive working properly? Have you got the right
kernel drivers for your drive controller? Is it IDE, SATA or
SCSI? You can do a hard-drive read speed test with hdparm
or dd.

hdparm -tT /dev/xxx where xxx is the drive device name. Usually
hda or sda for your hard-drive.


dd bs=512 count=1000000 if=/dev/xxx of=/dev/null

Both of these commands need root privileges so be careful
how you use them.

Small but growing. Welcome to CD Freaks.

Yes, to get such quick replies it seems to be the case, great :slight_smile:

At present i’m using an AD-7173A with ubuntu Studio and Nero Linux beta 3 and it burns at 18x without problems.

Good to know. So your drive takes like, say 5:30 minutes or so to burn a whole dvd, right? That would be ± 18x speed typical. Just to be sure we are all talking about the same here :wink: because as I said, my drive also says it does the burn at 18x, and produces readable dvd without problems, only that it takes much much longer, so that the final REAL speed is about 6x… :rolleyes:
Could you do me a favor and make your next burn with growisofs or k3b? or even cdrecord/wodim whatever? To see if it takes the same time… then at least I can be sure that nor those burn programs nor the drive itself are causing the slowdown, in that case it would be my pc. But if you do get slower speed with growisofs et al, then it would be a bug in those programs or something…

Because, the problem is that I’ve already tried everything…
but for your all information, here it goes:
I have Mandriva 2006 with custom kernel working fine, my hardware is not the newest but has decent speed (AMD Athlon XP1500) my drives are EIDE, harddisks on first channel, dvd is single master on second channel.
I have DMA working (did a readcd which gave me about 16000kB/s, and my harddisks are giving me (output of hdparm -tT) about 46MB/s). dvd drive is in udma4.
I can burn cds at full speed, and everything else seems fine, except for the fact that burning dvds seems to happen at 6x speed, and apparently not due to system slowdown, but to using wrong speed…

running growisofs at the command line (or over k3b, doesn’t matter, i’ve tried both) starts the burn saying speed is set at 18x, but then the values reported in the meantime go around 5 to 7x and at the end it says: average write speed: 6.1x or something like that.
If I run wodim it doesn’t even want to start with more than 6x…

Funny thing is I pretty much know why all this happens, just don’t know what to do against it and what is causing this: dvd+rw-mediainfo reports 6x as current write speed if I have a dvd+r in the drive (with both sony 16x and verbatim 16x), although in the list of write strategies correctly appears all speeds up until 18x!
So I think that’s why it only burns with 6x… wodim -prcap also reports current write speed 6x (=48x cd). Actually that indication is something that bothers me! Because as we know, 48x is drive’s max cd speed… could it be a bug in those tools or kernel or whatever, causing them to set the drives’ max speed at its max cd speed, 48x, which equivals to 6x dvd speed?! Because yes, the drive does have proper writing strategies with those medias, just had a look at the firmware excerpts here on another thread in the forum. Also just did a boot with win, quickly installed nero from some disc lying around here and did a test burn, it said burn speed to be 16x, and finished 2100MB in 3,5 minutes, which seems pretty decent to me… so it’s not hardware nor drive or media… now I’d really like to find out what is wrong then… because if there is one thing I do NOT want to do is start burning with nero for linux… I think, being this the linux area here, I don’t have to explain why, no? :wink:
(Though I might do it for testing purpose, to see if it then reaches max speed… this at least would help me to isolate the cause).

So, any comments or ideas are much appreciated. Let’s get to the bottom of this! :bigsmile: (because I did a little search on google, and seems there are quite a few people having the same issue…).

Well, just installed nero for linux and did a test burn of 4.4GB dvd. Amazingly, it was successfully burnt in 7 minutes, which is about typical for 16x. So, it really seems to come down to growisofs and wodim/cdrecord, and not linux or hardware or whatever… seems like I’ve just provided some answers to my own questions hehe :bigsmile:
Still, I want to solve this. Because although nero seems much better than I thought (must have been remembering the first ugly days of nero for linux where wine was still involved and all), I prefer open-source tools and then I have grown quite familiar with k3b and everything… so I’d rather much like to get it working like it should… if anyone here can help me, great, if not then I’ll look for other ways (maybe contacting author of k3b, or dvdrtools, etc…).

My very first 20x DVD burn. And K3b debugging file. This shows the full
output from growisofs and mkisofs. The speed reached 15x at 50% and
almost 20x at the end.

You could reduce the load on your system by unchecking
"On the fly" in the K3b burn window. K3b will then create
a temporary DVD image instead of running mkisofs
while it is burning the DVD.

Try playing with the “Manual writing buffer size” in
Settings : Configure K3b : Advanced

Next time you do a burn with K3b, save the debug file,
zip it and post it here.

Well, afterall it seems the problem is something different: speed…
Seems that my pc couldn’t keep up with the 16x speed on-the-fly if using a buffer smaller than 64MB… so it never reached top speed and as the values strangely always were around 6x, I thought growisofs was suffering from the same write speed indicator confusion like cdrecord (which only wanted to start at 6x), while in reality growisofs detected and set perfectly well the right write speed, only to see the buffers going madly up and down, so burnfree taking over and speed never went past 6x or something (remember this drive starts at 7x)…
Now, I set the buffer to 64MB and did a 16x burn (still on the fly, I don’t want to do images, that’s an illusion: what does burning quicker help me if making the image takes 6 minutes or more… and waste of hdd activity (remember they are mechanical… don’t want to stress them for nothing), and everything seemed to be perfect, buffers were steady, starting at 7x and going up. But then when it reached about 12x, sofware buffer started to go down, and from then on buffers didn’t recover correctly, speed was going lower to 8x, then 6 and finally ending the disc with 4x… I’ve saved the debug report from k3b, but don’t know if it’s worth sending, as I just explained what happened. But if you want to see it, I’ll post it. Ah, and total time taken for the burn was 8 minutes, that’s very nice compared to what I got before! So, afterall growisofs works correclty with my burner, only the general speed of harddisk/pc/apps was slowing it down.

So, problem solved. Thanks for the help. Ah, and next burn I’ll try with 128MB, maybe then it goes til end with high speed hehe :bigsmile:
I just don’t understand WHY it has this slowdown, if dma is in mode 4 and harddisks do up to 46MB/s… :confused:
Anyway, I can live with that.

I’m glad you are making progress with it. I reckon you should be
able to get at least 16x burns with an Athlon-XP machine. What mainboard
you are using? I wonder if there any known issues with the IDE controller
chip and the Linux kernel?

Try running "lspci | grep IDE "

This gives me:
skelton@debian:~$ lspci | grep IDE
00:0d.0 IDE interface: nVidia Corporation MCP51 IDE (rev a1)
00:0e.0 IDE interface: nVidia Corporation MCP51 Serial ATA Controller (rev a1)

Also try running top in a terminal to see if anything is hogging
a lot of CPU cycles or memory while you are burning a disc.

Well I just wanted to say I have been trying to solve this since sept. 06 and just bump my thread at ubuntu forums. Asking again why for k3b.

I have a p1.3ghz with 640mb ram with a nec-3550a burner using Verbatun 16x mcc004’s all the way.

As in my thread here http://ubuntuforums.org/showthread.php?t=262473 I show that I can burn in gnomes buitin at 8mins and all windowsXP in 8 mins. And there is no frigging way k3b should not also be able to.

Any suggestions would be appreciated.

It seems like this is a common issue (just took a quick look at you thread over at ubuntu forum). But I don’t think the fault is to find at k3b (most used burning app under linux, now in v1.0, etc… doesn’t make sense to have this kind of bug, would have been solved long ago). It either is caused by a specific hardware combination (maybe something in kernel IDE drivers… I remember someone reporting full speed with a SATA burner under linux), or specific burner/firmware. But even this I am not very sure about, having in mind that I tried Nero linux and it did full speed… One thing I’m pretty sure though: it has to do with system speed and (at least for me) it doesn’t seem related to k3b: even if I burn the dvd manually in terminal with growisofs, it starts correctly at 16 (or whatever I set), but gets the same slowdowns due to software buffer underruns, resulting in lower speed (about 6x here).
And even Nero had difficulties keeping the buffer full, but seems to have better methods and thus was able to keep up with the speed.
Actually the second highest speed I got until now, as you can see above, was with k3b, due to its capability of passing parameter to growisofs that sets the buffer size, and I did set it to 64MB… as I said, the next dvd I will try with 128MB and follow the other suggestions of skeleton. I’ll then report my experience here.
Anyway, as I said, I’m not too unhappy with current situation (since finding out that increasing the buffer gave me almost good speed). Try it. At least for me it helps. But still it’s like Skeleton said, our systems should be able to do full speed burns…

I finally got around to doing a few tests with an old PC.

My main PC is an Athlon-64 3700+ with 1GB of RAM. This machine
has a very fast SATA2 HD and a Liteon 20X burner. I can burn
DVDs at up to 20x in this machine without any problems.

My old machine is an Athlon-XP 2100 which is overclocked to
XP 2400 speed (2000MHz). I have burned hundreds of DVDs
at 16x in this machine.

Now we get to the old clunker. This machine was pulled from a
dustbin a couple of years ago. It has an Athlon CPU running at
850MHz and 384MB of RAM. The DVD burner is a BenQ DW1640.
The mainboard is based on a Via KT133 chipset which supports
IDE modes up to UDMA-66.
The OS is Slackware Linux 11.0 running the optional 2.6.x kernel.
This computer was state-of-the-art back in 1999-2000, but would
be considered as nothing more than a doorstop in 2007 :slight_smile:

I tried burning a large collection of files using K3B 1.0 in
on-the-fly mode. The burn started out at about 6x and gradually
increased until the burn speed reached 11-12x. At this point,
the pitch of the spindle motor dropped and the write speed
reduced to 8x for the rest of the burn (4331MB). The
resulting DVD reads perfectly and scans well.

I did a few tests to try to determine the cause of the slowdown.
For the first test, I used K3b to record the same collection of
files to an ISO image. This process took just over 7 minutes!
Not looking too promising for 16x burns :frowning:

I checked the DMA settings using dmesg and hdparm and
discovered that DMA was enabled for the HD and the DVD

The HD is a fairly slow 5600RPM 80GB Samsung.
Reading 512MB from the drive gave a read speed of 35MB/s

skelton@charon:~$ dd bs=512 count=1000000 if=/dev/hda of=/dev/null
1000000+0 records in
1000000+0 records out
512000000 bytes (512 MB) copied, 14.4466 seconds, 35.4 MB/s

Reading 4GB from the DVD-RW drive gave an average
speed of 15.1 MB/s
skelton@charon:~$ dd bs=2048 count=2000000 if=/dev/hdc of=/dev/null
2000000+0 records in
2000000+0 records out
4096000000 bytes (4.1 GB) copied, 272.023 seconds, 15.1 MB/s

It seems that it should be just about possible to burn
at 12x on this machine. I used growisofs run as root
to burn the image created by K3b.

from memory:
growisofs -speed=12 -Z /dev/hdc=linux.iso

The burn went smoothly with growisofs reporting a
burn speed of 11-12x with no slowdown, even at the
end of the burn.

For the final test, I used K3b to burn the image to a
DVD at 12x. The burn went well. Total burn time

If you want to burn DVDs with a PC from the end of the
last century, don’t use on-the-fly burning and keep your
burn speed down to 12x or less.

A newer 1GHz+ PC with an ATA100/133 IDE controller
and a faster HD should be able to burn a bit faster.

Hi Skelton.
Sorry for not keeping up with the thread lately, but I’ve been busy.
Yes, you’re totally right, your findings prove what I was suspecting.
DVD burning afterall seems to be a harder task then we thought, and it’s not enought to have a harddisk that does 40 something MB/s…
The 12x is exactly what I can get here aswell… but ONLY if I set the buffer to 128MB… that’s very important… at least with K3B/growisofs… then I can burn a full dvd in 7 minutes, that’s quite good. nero linux seemed to be a little smarter, taking care of this by itself (that explains why I got that result without tweaking anything.). Now, I also had the prove that it isn’t anything to do with linux: under windows with nero it did 7 minutes aswell, so it all comes down to the same thing…

now, to repeat the conclusions: anyone having trouble to get decent speed with k3b and dvd burning on a fairly old pc, increase that buffer size! then you’ll get at least something like 12x speed (7 minutes or so, and not 13 (!) minutes like I had before… 64MB seems to be the minimum, 128 is better…)

So, for me this topic is done. I am happy now with my dvd recording speeds. And even more happy to know that this isn’t some “linux issue” or whatever, you know, like those “windowists” like to say ehehe :stuck_out_tongue:

The Optiarc burners seem to be MMC-5. cdrkit-1.1.6 (wodim) doesn’t seem to understand MMC-5 and hence gets the speed wrong. I’m using a cdrtools (cdrecord) beta right now because of this. dvd+rw-tools (growisofs) works fine as well.

Regarding the buffer: Some distros (mine included) don’t set the setuid bit when the user install the burning apps. My burner device (/dev/hdc) is writable for the ‘cdrom’ group, so users of the group are allowed to burn. What I do is change the group of the burning apps (cdrecord, wodim, growisofs and cdrdao) to ‘cdrom’ and change their mode to 4710. So only users that inherit the cdrom group are allowed to use these setuid binaries. Now the apps can raise their process priority (which they do) to decrease the risk of buffer starvation. I’m using a 32MB buffer and all is well.

I don’t know if this is right. The cdrcord announcements for 2.01.01a10 says:

Added a workaround for a NEC DVD firmwarebug that caused cdrecord to use the
CD write speed instead of the DVD write speed.

Maybe that’s it and cdrkit doesn’t have the workaround yet.