Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I have a bunch of media files which I want to record to DVD, but since each DVD only fits 4.5GB, I have to find the optimal way to organize the files to use the minimum number of DVDs (otherwise the empty space left in each DVD can easily add up). Are there any tools to help with this?

Many years ago there was a DOS utility to do this with floppy disks.

share|improve this question
1  
No, I'm not looking for compression & splitting. I want to distribute the files natively (filesystem) so that each disk may be used directly. –  Alex R Dec 19 '09 at 21:01
    
Just felt that this was a good page for anyone searching: howtogeek.com/76264/… –  Nav Aug 28 '13 at 4:48

5 Answers 5

up vote 2 down vote accepted

Try the free DVD Span :

DVD Span is a backup tool for writing the contents of large folders to multiple DVDs. DVD Span can automatically determine the best organization of each disk in order to fit the maximum amount of data on the minimum number of disks. DVDSpan is a great tool for backing up your music collection, photos, or even your entire hard disk to DVDs. And because it produces regular DVDs (or CDs), no special software is required to read or restore your backups.

share|improve this answer

You could use any compression tool that allows splitting of an archive i think

share|improve this answer
1  
Compression is not what I'm looking for. That makes it too cumbersome to access the files. –  Alex R Dec 19 '09 at 21:02

Ah, the Knapsack problem. I could only find one online solver for this, here. Your knapsack size would be 4.5GB, and each packet would be your file sizes. You'll need to massage its output a little bit to fit your particular application, but it should be workable. This wont run very fast though, because this problem is hard.

share|improve this answer
    
Yes indeed it's an NP-complete problem, but for this practical application, a brute-force solution is fast enough :) –  Alex R Dec 20 '09 at 4:45

You can take one of the variants of the program in Hitchhiker's guide to Haskell, perhaps after working through some part of that tutorial; the tutorial is written around solving exactly yours problem of distributing things onto several disks whereby the solution is incrementally refined, as exemplified by the following passage from Chapter 3 of the tutorial:

Enough preliminaries already. let's go pack some CDs.

As you might already have recognized, our problem is a classical one. It is called a "knapsack problem" (google it up, if you don't know already what it is. There are more than 100000 links).

let's start from the greedy solution...

More ideas: a related question

Here is a similar question (although not the same: it's not being asked for optimization there), where you may find more useful solutions/programs for your task (if they will be posted):

Some hints for understanding the programming in the suggested tutorial

In general, the Haskell code is quite expressive (since Haskell is a language for programming on a high level of abstraction), and hence can be easily grasped.

When looking at the code of one of the solutions, remember that the top-level structure of the program we want to write is quite simple, as put in Chapter 1 of the tutorial:

Now let's think for a moment about how our program will operate and express it in pseudocode:

main = Read list of directories and their sizes.
       Decide how to fit them on CD-Rs.
       Print solution.

Sounds reasonable? I thought so.

Let's simplify our life a little and assume for now that we will compute directory sizes somewhere outside our program (for example, with "du -sb *") and read this information from stdin.

and look further more closely at the parts of the solution.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.