Take the 2-minute tour ×

I have a minor dilemma, in that I need to be able to burn multiple CDs at once, but with a GUI.

I have run into solutions using cdrao (did I get that right) and scripts, but as I'm not the only one who will be responsible for burning (I am not teaching a child to use the command line in 5 minutes, :), I need a GUI solution.

Turbojet2 is one of the potential solutions I came across, but its last release was in 2007... so I'm a bit wary to try it on my system (currently dual booting between 13.10 and elementary OS) (not that it will damage my system, but just that it likely won't work or even compile).

I also read that it has some problems with speed, which is a big deal (fastest speed possible is a necessity when you have to serve several people within a few hours, if that long).

Would it be possible to use K3b or Brasero or Xfburn, or XCDRoast, etc to burn multiple CDs at once? When I attempted it with Brasero and K3b at the same time, one of the CDs gets ejected each time.

My setup is as follows:

  • A laptop with a built in optical drive.
  • An external optical drive that talks to the laptop via USB.

K3b detects them separately; Brasero... well you know how it is with Gnome. It doesn't really seem to be able to tell the difference between two separate drives.

However, I see no option to burn to each separately.

share|improve this question
To my knowledge there's not much that can do this because of hardware issues, buffers and what not. i.e. Not a lot of people can even do it, let alone do it and want to from a GUI. I would also assume that the libs "scan" the optical drives and if done while burning makes coasters. Not saying it can't be done, just that it's very uncommon. Command line might be the way, can you use zenety to help make the scripts more kid proof? –  coteyr Sep 13 '13 at 17:35
I didn't fully understand your comment (what is "makes coasters?"). I'm thinking it is possible, from what I read, but just seems not to be common. –  RolandiXor Sep 13 '13 at 17:55
buffer under-runs, data bleed over, and other things that would make the burned materials useless. It's less of a problem in your case but two ide (or sata) drives trying to burn at the same time would cause it, or maybe two USB drives at the same time. Maybe if you had some kind of other IO bottle neck. These days the drives are pretty good about not doing that, but they still can. –  coteyr Sep 13 '13 at 19:40
add comment

1 Answer

up vote 1 down vote accepted

There is a project named qmultirecord:


which promises to do this on top of my burn program cdrskin. I did not test it myself, because i am a command liner.

Is it really that hard to create one or two scripts which the kids can start from icons or by easy to memorize command line words ? (Kid brains are very elastic, aren't they ?)

As for the scruples of coteyr: There is no obstacle for doing this in principle. Occasionally i burn with two drives while having another two drives reading for verifying. (I have 2 PATA, 1 SATA, 3 USB.)

A burn backend, that automatically scans for all drives before burning, would be quite hostile towards other users of the system and get bad critics from multi-user sysadmins. Some GUI burn programs might indeed do this.

Bad would be PATA attached drives which share the same IDE controller (e.g. on older Linux: hdc and hdd). But PATA is becomming rare.

Another obstacle is the fact that burning is a synchronous userspace process. We do not have the priorities which the kernel can use and we have to wait for each WRITE command to end, before we can send a new one. The kernel can queue multiple such commands without waiting for the first to finish. So you need some CPU reserve for good reactivity.

Further your hard disk will have to jump between the two data sources from which the burn processes read. I am sure that my olde system would not be able to feed two DVD burns with 20x speed (27 MB/s each). But hey, even 40x CD speed is just 6 MB/s.

Have a nice day :)


share|improve this answer
Thanks for your in depth answer. I really want to avoid the command line for this as we to do things quickly and using long paths that change every month. The complication would stack up quickly, and I'm averse to adding that kind of trouble to the existing workload. I do plan to teach my "protege" the command line, but not yet, and not for this task of course. (The command line is wonderful, but there are times when it is not advisable/faster/better/useful). –  RolandiXor Sep 15 '13 at 0:34
Well understood. What about an icon starting a script that pops up a window where to enter the parameters ? Then the script runs one of the command line programs for CD burning. I would use Tcl/Tk for the GUI, because it is lean, i have some example code at hand, and it is nearly as ugly as a shell window. :)) Actually one could strip down my demo xorriso-tcltk. See: gnu.org/software/xorriso/xorriso-tcltk-screen.gif Regrettably, packages.ubuntu.com only lists versions which are too old. You'd need e.g. gnu.org/software/xorriso/xorriso-1.3.2.tar.gz –  Thomas Schmitt Sep 15 '13 at 8:01
I'll give the first solution a try when I get some time, and then your other suggestion. I tried burning with the internal burner today and ran into a niggling bug again (it fails to burn about half-way through, then refuses to burn anything until the system is restarted. Seems software related as it happened with two different drives). Hopefully I can eventually get a desktop for this task system back up and running. –  RolandiXor Sep 15 '13 at 20:07
Misfunctioning burners are always of interest to me. But i will not watch here for a long time. You may contact me for advise (or consolation) via scdbackup@gmx.net. –  Thomas Schmitt Sep 16 '13 at 9:51
add comment

Your Answer


