Get Firefox! Viewable with any browser! Valid HTML 4.01! Valid CSS!
Text size: 

Please note that this is a work in progress. There is sufficient information in this howto to justify its early publication, but more is to be added and what's up here right now is liable to change. Please don't mirror this document yet.

Backing up your DVD-Video discs

Please note that I do not condone piracy in any way. The following guide is intended to help the reader make a backup for personal use, NOT for distribution of copied works, whether for a fee or not. The former is allowed in the European Union at least, the latter is not.

Please behave responsibly.

Copyright © 2006-2024 Howard Pritchett.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is available from the Free Software Foundation.

Blank media
What makes up a DVD-Video?
Required hardware
Required software
Extracting a title from the DVD-Video
Demultiplexing the audio and video
Shrinking the video stream
Remultiplexing audio and video
Using dvdauthor
Burning the DVD
Extracting subtitles
Multiplexing the subtitles into the movie
Menus and multiple titles


The information I'm about to give below is very much simplified compared to the real DVD-Video standard, but sufficiently detailed for the purposes of this guide − I have neither the intention nor the know-how to turn anyone into a pro of the video-montage world!

DVDs are not invulnerable. They are much more durable than video tapes since there is no physical contact between the playing surface and the device used for reading it − unlike a VCR, which has various tape heads, guides and pinch rollers in contact with the tape, not to mention elements of the tape housing itself. However, this is far from meaning that the DVD gets no wear and tear at all.

What do you do to feed the DVD into the player? First of all, you have to handle it to transport it to the player. You could drop it, need to wipe it get dust off it, and some of the boxes trap the disc so tightly that you think you're going to break it getting it out. Then, once you've got it to the player, what do you do? you put it on a tray that could have abrasive particles on it, or you push it in a slot that'll "swallow" it by feeding it through rollers…

There are 1001 ways to scratch a DVD to a point that renders it unusable.

The solution is to make a backup of the DVD and play it while keeping the original in a safe place where it won't get harmed. Maybe your copy will get scratched sooner or later, but who cares? Blank DVDs are cheap (I pay around $0.35 for a blank 4.7GB DVD+R), so you make another copy.

This guide's purpose is to show you how to make that copy. In order for you to grasp what you're doing we'll need to explain a little about what makes up a DVD-Video and the tools you'll be needing to extract the individual elements of a DVD-Video, manipulate them and bind them together in a new DVD-Video − your copy.

REMINDER: There's a word for making copies of a movie that you distribute. It's piracy. Piracy, apart from being unethical, can land you in hot water.



DVDs to which you can burn data that can subsequently be played back by a set-top DVD player are broken down into two main families: DVD-R and DVD+R. Without going into details (see here for more than you ever wanted to know about +RW and -RW), suffice it to say that what differenciates them is the writing techniques you can use with them. There is a trade-off. More set-top DVD players are likely to be compatible with DVD-R than with DVD+R, but the DVD+R system is more tolerant of minor problems encountered while burning the disc. I happen to have a DVD player that'll eat just about any kind of disc so I usually stick with DVD+R because the hardware I use for burning them is not exactly high end. Yet…

R or RW?

Just like there are rewriteable CD-RWs there are also rewriteable DVD±RWs. They only cost about twice as much as plain DVD±Rs and you have the obvious advantage of being able to scrub them and put something else on them instead. Bear in mind, however, that not all set-top DVD players can play back rewriteable media. More and more present-day ones can but one from a few years ago might not be able to play back anything other than commercial DVDs and DVD-Rs.

Single or dual layer?

A single layer DVD can contain up to 4.7 gigabytes of data. Note that this is 4.7GB as understood by media manufacturers, i.e.: 4,700,000,000 bytes (which is really about 4.38 gigabytes since a real gigabyte is 2^30 bytes, not 10^9). This is enough for 2 hours of perfectly good video. By compressing the video more than may be good for it and therefore degrading the picture quality somewhat, I've been able to get 3h44 of video onto one disc. The effects of the compression really become visible if you try and put more than 2h30 or 3h of video onto the disc, but in this instance it didn't matter too much.

Dual layer DVDs have a capacity of 8.5 gigabytes (salesman's gigabytes, so that's about 7.9 real gigabytes). This is enough for 4 hours of reasonable quality video. Dual layer DVDs need a dual layer burner to burn them, although they don't cost much more than single layer burners now. What does cost more still is blank media: $2.50 PER DISC.


Remember: the information below is extremely simplified. For far more detailed information, refer to the Unofficial DVD Specifications Guide.

The bulk of the data on a DVD-Video is simply MPEG2 files. They are further wrapped in files in the "VIDEO_TS" directory of the DVD that carry the ".VOB" filename extension, and the ".IFO" files instruct the DVD player how to access the MPEG2 data. The .BUP files are simply backup copies of the .IFO files.

The MPEG2 data carries the movie itself. The lowest level of data with which the DVD authoring team interacts is the cell. A cell can be anything from a single frame to the entire movie but usually a cell equates to a chapter. Thus, a chapter, which can contain several cells, usually only contains one cell.

Chapters are strung together to make Program Chains. Although there are subtle differences between the two, a Program Chain (or PGC) is, to all intents and purposes, the same thing as a title.

Multiple titles are grouped together into Title sets. Each title set can have its own menus (root, audio, subtitles etc.). All the titles in a title set must share the same major attributes such as aspect ratio (16:9 or 4:3), picture resolution, number and language of audio and subtitle channels, audio format (AC3, PCM, MP2 etc.).

At the top of this hierarchy sits the Video Manager (or VMG).

A DVD player includes a Virtual Machine which has registers that define how playback occurs (such as which audio track to play back, which set of subtitles, which region the disc is intended for or whether or not Macrovision copy protection should be activated) and a simple instruction set to access these registers and to allow the user to access various parts of the disc.

Any part of any title in any title set can be accessed from the VMG. From within a given title, however, it is only possible to access parts of the same title set, or the VMG menu (or VMGM) − it is not possible to access a menu or a title in a different title set.

The MPEG data sewn up in the .VOB files is in fact a kind of digital sausage. If you feed pork, herbs and a few other things you probably don't want to hear about into a mincer and stuff what comes out of the mincer into a casing, you get a sausage with all these ingredients mixed into it. In the digital world, a multiplexer plays the role of the mincer: you put video data, audio data and (optionally) subtitles in one end and out the other end you get an MPEG file.

The big difference between an MPEG file and a sausage is that it's possible to demultiplex the MPEG file and get back all the individual elements that constitute it. You can't feed a sausage into a "demincer" and get your pork and other ingredients back…

What you'll be learning to do here is extract individual titles from a DVD-Video, demultiplex the resulting data in order to obtain individual audio, video and subtitle channels, shrink the video channel so that the whole lot once reassembled into a DVD-Video structure will fit onto a blank DVD, multiplex the lot into a new, smaller "sausage", build the DVD structure and finally burn it to a DVD. We'll then add a VMGM, which will be useful for backing up your series with multiple titles (episodes) on one DVD.


Obviously, you'll need a DVD burner (doh…). The aim here is to do things the economical way, without requiring blank media at several dollars each, so we're sticking with single layer media. Consequently, a single layer DVD burner is adequate.

You'll need plenty of disk space. You can need up to 30GB of available disk space to rework a DVD-Video. While processing the DVD you're going to be processing files that are several gigabytes each in size, and you're going to be performing some pretty fast throughput, such as when demultiplexing the original video stream from the DVD, so ideally you'll have two hard disks on seperate controllers, arranged so that data can be read from one and written to the other simultaneously. Without this, the I/O subsection of your computer will be quite a bottleneck and it will slow down operations.

Finally, you'll need plenty of processing muscle power. Up until now I've been doing this with a rather aged Pentium-III running at 550MHz with 384MB of RAM. Such a setup is not, however, really up to the task. It's far too slow, taking up to an hour to process some movies. For x86-compatible systems I'd recommend at least a 2GHz processor with no less than 512MB of RAM. I don't know what that would equate to in terms of CPU power when dealing with other architectures. With any luck, this machine will be transformed into a Celeron D340 (2.93GHz) supported by 1GB of PC3200 RAM by mid September 2005, at which point I should notice a marked difference in performance. Thanks, Randy! :o)


Before going any further, be forewarned that you should grab and install binary packages of the software enumerated below whenever possible. Compiling from source, I had a few problems with circular dependencies, which meant compiling most of the software twice. Some of the projects are large and take a long time to compile on a system like mine.

tcprobe, tccat, tcextract and tcrequant are what we're going to be using to extract and process the data streams on the DVD-Video. These are all parts of the transcode project.

When building menus that require a background image, we'll need to convert a JPEG image to MPEG format for its inclusion into the DVD project. This requires a chain of three different conversion tools: jpegtopnm, which is part of the netpbm project that is installed with most Linux distributions, ppmtoy4m and mpeg2enc, which are part of the MJPEG Tools project.

The digital "mincer" we'll be using to multiplex audio and video together into an MPEG file is mplex, which is also part of the MJPEG Tools project.

Stitching all the processed data back together again in order to create a new DVD-Video is the task of dvdauthor and (if subtitles or menus are used) spumux, both of which are part of the dvdauthor project.

Burning the data produced by dvdauthor to a blank DVD±R is the job of growisofs, which is part of dvd+rw-tools. growisofs in turn calls mkisofs, which is an element of cdrtools.

A script I use for extracting the times at which chapters start in a title from the output of tcprobe is written in Perl. You'll therefore need Perl if you want to run this script. I have yet to see a Unix-like distribution that doesn't ship with Perl already installed. You have it, don't worry.

tccat makes use of libdvdread to access the data on the DVD-Video. If the DVD is CSS-encrypted then libdvdread will, in turn, make use of libdvdcss in order to descramble it.

In order to make things simpler, your Linux kernel (or the kernel of whatever operating system you're using) must be able to handle large files. You'll be dealing with files well in excess of the 2GB limit often imposed by 32-bit filesystems, sometimes up to 8GB.

I have not yet found a method to remultiplex back into the MPEG file a subtitle channel demultiplexed with tcextract. The only way to get subtitles back is to extract the graphics, reconstitute the text either manually or using an OCR package, then multiplex the new data into the MPEG file. The graphics extraction is done with subtitle2pgm. The OCR software that can interface with a tool called pgm2txt is GOCR, the text is then further processed with srttool before the final data is multiplexed with spumux. subtitle2pgm, pgm2txt and srttool are part of subtitleripper.

Curiously enough, the subtitleripper home page says that this package is part of transcode, but the area of the transcode project relevant to subtitleripper says to go and visit the subtitleripper home page. Talk about a circular definition…


Let's assume you want to make a backup of a movie. You only have one title to worry about and no menus. Most of the time, the feature movie will be the first title, but if you're unsure you can always play the movie back in your set-top player and once the movie proper has started, turn on the on-screen display to find out which title you are actually viewing.

Start by inserting the DVD-Video in your DVD-ROM drive or writer and mount it. From here onwards I'll assume the drive's mount point is /dvd.

Assuming the movie is in title nr. 1, this is how you'd extract it to a file on your hard drive, movie.vob:

$ tccat -i /dvd -T 1,-1 > movie.vob

If the title you wanted to rip was nr. 3 then you'd adjust the above command like so:

$ tccat -i /dvd -T 3,-1 > movie.vob


tccat is the command used to grab the data from the DVD-Video.

-i /dvd tells tccat to look for the DVD-Video structure in /dvd, i.e.: the mount point on which the DVD-Video is mounted.

-T 3,-1 tells tccat to grab title 3, with the "-1" meaning "all chapters in the title". Note that this is a figure "one", not a lowercase "L".

> movie.vob − tccat (just like the standard cat) sends its output to the console (stdout), so we redirect it to the file we want.

Depending on the speed of your DVD drive and the length of the movie this can take time &minus anything up to 15-20 minutes − but you'll end up with a large file containing the video, all the audio tracks (up to 8) and all the subpicture channels (up to 32). A DVD-aware media player such as mplayer or xine will be able to play back this movie.vob file for you.

Don't unmount and remove your original DVD-Video just yet, you're going to need it in place when extracting the chapter timings.


This is where we use the magic sausage demincer in order to extract the ingredients of the sausage. If you're making a backup of your DVD you'll only want one audio track and, if that audio track is not in your language, one subpicture channel to carry subtitles. We'll come back to the subtitles later on and concentrate on the rest, so what we're going to do next is extract the video portion and the sole required audio track from our movie.vob file.

Let's extract the audio track first. With the DVD-Video still mounted, use tcprobe to find out about the title you just ripped:

$ tcprobe -i /dvd -T 1
libdvdread: Using libdvdcss version 1.2.8 for DVD access
libdvdread: Attempting to use device /dev/hdc mounted on /dvd for CSS authentication
[tcprobe] DVD image/device
libdvdread: Using libdvdcss version 1.2.8 for DVD access
libdvdread: Attempting to use device /dev/hdc mounted on /dvd for CSS authentication
(dvd_reader.c) mpeg2 pal 16:9 only letterboxed U0 720x576 video
(dvd_reader.c) ac3 en drc 48kHz 6Ch
(dvd_reader.c) ac3 de drc 48kHz 6Ch
(dvd_reader.c) ac3 en drc 48kHz 2Ch
(dvd_reader.c) subtitle 00=<en>
(dvd_reader.c) subtitle 01=<de>
(dvd_reader.c) subtitle 02=<sv>
(dvd_reader.c) subtitle 03=<da>
(dvd_reader.c) subtitle 04=<fi>
(dvd_reader.c) subtitle 05=<is>
(dvd_reader.c) subtitle 06=<iw>
(dvd_reader.c) subtitle 07=<ar>
(dvd_reader.c) subtitle 08=<el>
(dvd_reader.c) subtitle 09=<en>
(dvd_reader.c) subtitle 10=<de>
(dvd_reader.c) subtitle 11=<en>
(dvd_reader.c) subtitle 12=<de>
(dvd_reader.c) DVD title 1/2: 41 chapter(s), 1 angle(s), title set 1
(dvd_reader.c) title playback time: 02:27:51.00  8872 sec
(dvd_reader.c) [Chapter 01] 00:00:00.000 , block from 0 to 40020
(dvd_reader.c) [Chapter 02] 00:01:46.600 , block from 40021 to 128527
(dvd_reader.c) [Chapter 40] 02:17:05.160 , block from 3163189 to 3298738
(dvd_reader.c) [Chapter 41] 02:18:35.080 , block from 3298739 to 3333288
[tcprobe] summary for /dvd, (*) = not default, 0 = not detected
import frame size: -g 720x576 [720x576]
     aspect ratio: 16:9 (*)
       frame rate: -f 25.000 [25.000] frc=3
      audio track: -a 0 [0] -e 48000,16,2 [48000,16,2] -n 0x2000 [0x2000]
      audio track: -a 1 [0] -e 48000,16,2 [48000,16,2] -n 0x2000 [0x2000]
      audio track: -a 2 [0] -e 48000,16,2 [48000,16,2] -n 0x2000 [0x2000]
[tcprobe] V: 221800 frames, 8872 sec @ 25.000 fps
[tcprobe] A: 138.62 MB @ 128 kbps
[tcprobe] CD:  650 MB | V:  511.4 MB @ 483.5 kbps
[tcprobe] CD:  700 MB | V:  561.4 MB @ 530.8 kbps
[tcprobe] CD: 1300 MB | V: 1161.4 MB @ 1098.1 kbps
[tcprobe] CD: 1400 MB | V: 1261.4 MB @ 1192.6 kbps

The six lines I have highlighted in red are the lines that tell me there are three audio tracks in this title. The first three lines tell me that the first track is in English (en), that its sampling rate is 48KHz and that it has 6 channels. This looks like a Dolby 5.1 sound track. The second audio track is in German (de) and it's also a Dolby 5.1 sound track. The third track is also in English but it only has 2 channels. It's a straightforward stereo sound track, probably the director's commentary.

The "ac3" in the first set of 3 lines and the "0x2000" in the second set confirm that the audio format used in these tracks is the AC3 format. Let's extract the first audio track from the .vob file:

$ tcextract -i movie.vob -t vob -x ac3 -a 0 > audio.ac3


tcextract is the command used to extract the various parts from our MPEG2 sausage.

-i movie.vob tells tcextract to take its input from our movie.vob file/sausage, i.e.: the title we ripped from the DVD-Video previously.

-t vob tells tcextract that its input file is a .VOB file. It can probably already infer this from the filename and from the logical structure of the file but I always make it explicit out of habit.

-x ac3 tells tcextract that we want to extract an AC3-encoded audio track from the .VOB file.

-a 0 − the audio and subpicture channels in an MPEG file are numbered because there can be more than one, unlike the video stream which is unique. This command line option tells tcextract to extract the first audio channel (the list is zero-based so 1 would be the second, 2 the third etc.).

> audio.ac3 − just like tccat, tcextract sends its output to the console. We therefore redirect the output to the required file.

Now, let's extract the video stream:

$ tcextract -i movie.vob -t vob -x mpeg2 > video.m2v

Depending on the speed of your computer and its disks, this can take quite a while…


tcextract -i movie.vob -t vob − as above.

-x mpeg2 − we no longer want AC3 audio, this time we want to extract the MPEG2 video channel. Since there's only one, we don't need to qualify it with -a.

> video.m2v − as above, we direct the output of tcextract to a file.

Let's take a look at the files we now have. Note that the file sizes you have will almost certainly be different from what I have unless by some magic fluke you're playing with the same DVD-Video as I am:

$ ls -lst
total 13262880
5839736 -rw-r--r--  1 howard users 5974039472 2005-09-04 14:43 video.m2v
 416244 -rw-r--r--  1 howard users  425808384 2005-09-04 14:36 audio.ac3
7006900 -rw-r--r--  1 howard users 7168053248 2005-09-04 14:28 movie.vob

A few points are worthy of note here. Firstly, we haven't even started processing the DVD yet and we already have over 12 gigabytes of data here. That's why you need plenty of available disk space to do this! Secondly, our original .VOB file is around 6.7 gigabytes in size, so we're definitely dealing with a dual layer DVD here. Thirdly, the combined size of the AC3 and MPEG2 streams we extracted from it is about 6 gigabytes, so what happened to the other 700 or so megabytes? They're used up by the alternative audio channels and subpicture channels that we're not going to bother about here. More precisely the combined size of the extracted audio and video streams is 6,399,847,856 bytes, which is much more than the 4,700,000,000 bytes we can squeeze onto a DVD±R. Something has to be shrunk…


But why not the audio stream? Well, the audio data represents less than 10% of what will be on the final DVD, so by messing with it we're not going to make much of a dent in the 2GB or so of data we need to shed. Also, the audio track is a big part of the experience. If you downmix the Dolby 5.1 to straightforward 2.0 stereo you're going to lose out on the surround and sub-bass effects, and if you MP3-encode the resulting sound you'll destroy even more of the quality. It really isn't worth it for the small amount of disk space you'll recover.

The video, on the other hand, can be shrunk (or requantized) considerably without having anywhere near as big an impact on the quality of the final DVD. Here's how it's done.

First of all, we need to determine by how much the stream must be shrunk for the whole lot, once recombined, to fit on the blank DVD±R. This method is somewhat empirical but seems to work well enough. The blank DVD can hold 4.7×10^9 (4.7 billion) bytes of data. If I allow for 200MB of filesystem overhead and safety margin (because a single byte too many in the resulting DVD structure means having to requantize the video again, which is a waste of much time), then I have 4.5 billion bytes left to play with. The audio stream uses 425,808,384 bytes of that, which means that there are 4,074,191,616 bytes for the video part. The original video stream is 5,974,039,472 bytes in size, and in order to find the shrink factor we simply divide the original size by the number of bytes we actually have left for the video:

5,974,039,472 / 4,074,191,161 = 1.46631283824

Round that up to the nearest hundredth and we get a shrink factor of 1.47.

Here's how we apply it:

$ tcrequant -i video.m2v -o video.shrunk.m2v -f 1.47

This can take a looooong time. It takes about 40 minutes on my Pentium-III/550 but should only take about 5 minutes, certainly less than 10 minutes anyway, once the system is upgraded.


tcrequant is the tool used to requantize MPEG2 video streams.

-i video.m2v tells tcrequant to take its input, i.e.: the data we want to requantize, from the file video.m2v.

-o video.shrunk.m2v − the output of tcrequant, i.e.: the shrunk video stream, will be sent to a file called video.shrunk.m2v.

-f 1.47 − this is the factor by which we want the video stream shrunk.

Let's take another look at the files we have:

$ ls -lst
total 17235788
3972908 -rw-r--r--  1 howard users 4064283599 2005-09-04 15:44 video.shrunk.m2v
5839736 -rw-r--r--  1 howard users 5974039472 2005-09-04 14:43 video.m2v
 416244 -rw-r--r--  1 howard users  425808384 2005-09-04 14:36 audio.ac3
7006900 -rw-r--r--  1 howard users 7168053248 2005-09-04 14:28 movie.vob

The new, shrunk MPEG2 video stream is only 4,064,283,599 bytes in size. Add that to the 425,808,384 bytes of audio data and we have 4,490,091,983 bytes. Just within the 4.5 billion byte limit we'd set ourselves.

Now that we have shrunk the video stream, we need to recombine it with the audio stream and generate a new MPEG file.


This is the easy bit:

$ mplex -f 8 -M -o newvideo.mpg audio.ac3 video.shrunk.m2v


mplex is the command that multiplexes the audio and video data together into a new "digital sausage".

-f 8 − there are several variants of MPEG file. This option instructs mplex to produce files that are compatible with dvdauthor, which we'll be using later.

-M − there may be "End Of Sequence" markers in the video stream. If there are, mplex will attempt to break its output up into several separate MPEG files. Using the -M option tells mplex to ignore these markers and spit all the data into one single file.

-o newvideo.mpg tells mplex to output the multiplexed MPEG data to the newvideo.mpg file.

audio.ac3 video.shrunk.m2v − these are the two separate streams that are to be multiplexed into the final MPEG file.

If we now look at what we have:

$ ls -lst
total 21721268
4485480 -rw-r--r--  1 howard users 4588632064 2005-09-04 16:03 newvideo.mpg
3972908 -rw-r--r--  1 howard users 4064283599 2005-09-04 15:44 video.shrunk.m2v
5839736 -rw-r--r--  1 howard users 5974039472 2005-09-04 14:43 video.m2v
 416244 -rw-r--r--  1 howard users  425808384 2005-09-04 14:36 audio.ac3
7006900 -rw-r--r--  1 howard users 7168053248 2005-09-04 14:28 movie.vob

The .mpg file is still a little under 4.6 billion bytes, so we're still within the physical limits of the DVD±R.

The next step in the process is finding out where the chapters are in the original movie so that you can split your reworked version at the same points. We're going to use tcprobe again for this.

Oh, and by the way, there's already roughly 20 gigabytes of data here and we still don't have the backed up DVD yet…


Take another look at the output of tcprobe above. I shortened it by cutting out a bunch of lines, all of which were indications of exactly when a chapter started. Copy the script below and paste it into a text editor. Then save it as tcprobe2chapters and make it executable. This script takes the output of tcprobe, isolates the lines that mention chapter start times, and outputs the results in a format directly usable later on by dvdauthor:


@output = grep /\[Chapter \d+\]\s+\S+/, <>;

foreach ( @output ) {
  /\[Chapter \d+\]\s+(\S+)/;
  push @times,$1;

print (join ",",@times)."\n";

We're going to use this script to extract the SMPT timestamps of the start of all of the chapters. Still with the DVD-Video in your drive and mounted:

$ tcprobe -i /dvd -T 1 2>&1 | tcprobe2chapters > chapters


tcprobe -i /dvd -T 1 − look at the DVD-Video mounted on /dvd and output information pertaining to title 1.

2>&1tcprobe outputs most of its results to the standard error stream, stderr instead of the usual channel, stdout. This construct diverts it back through stdout so that we can pipe it through our tcprobe2chapters Perl script and extract the chapter start times from it.

| tcprobe2chapters − pipe the output from the preceding command through our tcprobe2chapters script.

> chapters − send the output of the tcprobe2chapters script to a file called chapters.

In fact, if you now look at the content of our chapters file, you get something like this:

$ cat chapters; echo

You see here a comma-separated list of SMPT (Standard Motion Picture Time) timestamps of the form HH:MM:SS.sss, which is exactly how dvdauthor wants them. Keep this file to one side, you'll be needing it in the next step.


As its name suggests, dvdauthor is the tool we'll be using to reassemble our MPEG file into the structure of a new DVD-Video that we'll be burning to a DVD±R shortly.

dvdauthor uses an XML file to tell it what files to assemble and how to assemble them. Copy and paste the data below into a file called dvdauthor.xml − you'll be using it as a template for all your backups:

 <vmgm />
   <video format="pal" aspect="16:9" />
    <vob file="" chapters="" />

I'll give a few explanations about what this all means. For full details on what everything means, you'll want to consult the dvdauthor man page.

<dvdauthor>...</dvdauthor> − The whole XML file is enclosed in this tag.

<vmgm /> − We're not defining a VMGM (empty XML tag) so DVD-Video playback will start at the first title defined below.

The (only, in this instance) title set is defined in the <titleset>...</titleset> tag.

We could define menus for this title set in a <menus>...</menus> tag within the <titleset>...</titleset> tag but we're not going to here. Keep it simple and move straight onto the definition of the title(s) contained in the title set in the <titles>...</titles> tag.

Video standard (PAL/NTSC) and aspect ratios (4:3/16:9) can't be mixed inside a title set, nor can audio formats (AC3/MP2/DTS/PCM) and sampling rates. The relevant information for the whole title set is defined in the <audio> and <video> tags. Strictly speaking they aren't necessary in a project such as this with only one title in a single title set since the needed data can be inferred from the MPEG file. If you do keep them, remember to adjust them according to the movie you're processing. For example, if you're reworking a Zone 1 DVD-Video you'll probably need to use format="ntsc" instead of format="pal".

Next we move on to the list of PGCs (=titles) in the title set. In this instance there's only one PGC (in a <pgc>...</pgc> tag) which is described in the <vob /> tag.

There are two crucial pieces of information we have to include in this tag: the name of the MPEG file we want to insert in this PGC and the definition of the chapters in it. The MPEG file we need to include here is newvideo.mpg, and the chapters' start times are in our chapters file. Simply type the movie's filename between the quotes after file= and insert the contents of the chapters file between the quotes after chapters= (make sure that the opening quote, the entire list of chapter start times, the end quote and the "/>" closing the XML tag are all on the same line − I'm simply displaying an ellipse below to denote the continuation). Your XML file should now look like this:

 <vmgm />
   <video format="pal" aspect="16:9" />
    <vob file="newvideo.mpg" chapters="00:00:00.000,00:01:46.600,00:05:23.800,00:09:32.880,00:13:24.120,..." />

We're now ready to build the new DVD-Video's filesystem structure:

$ dvdauthor -o DVD -x dvdauthor.xml

If all went well then this operation (which should take a few minutes) will have created a new directory called DVD containing the usual AUDIO_TS and VIDEO_TS directories to be found on a DVD:

$ ls -ls DVD
total 8
4 drwxr-xr-x  2 howard users 4096 2005-09-06 21:48 AUDIO_TS/
4 drwxr-xr-x  2 howard users 4096 2005-09-06 21:54 VIDEO_TS/

The VIDEO_TS directory should contain the usual .VOB and .IFO files:

$ ls -ls DVD/VIDEO_TS/
total 4485664
      8 -rw-r--r--  1 howard users       6144 2005-09-06 21:54 VIDEO_TS.BUP
      8 -rw-r--r--  1 howard users       6144 2005-09-06 21:54 VIDEO_TS.IFO
     80 -rw-r--r--  1 howard users      75776 2005-09-06 21:52 VTS_01_0.BUP
     80 -rw-r--r--  1 howard users      75776 2005-09-06 21:52 VTS_01_0.IFO
1049572 -rw-r--r--  1 howard users 1073709056 2005-09-06 21:53 VTS_01_1.VOB
1049572 -rw-r--r--  1 howard users 1073709056 2005-09-06 21:53 VTS_01_2.VOB
1049572 -rw-r--r--  1 howard users 1073709056 2005-09-06 21:54 VTS_01_3.VOB
1049572 -rw-r--r--  1 howard users 1073709056 2005-09-06 21:54 VTS_01_4.VOB
 287200 -rw-r--r--  1 howard users  293795840 2005-09-06 21:54 VTS_01_5.VOB

You can now test this DVD with your media player before burning it to DVD±R.

For users of xine:

$ xine -V xv "dvd:$PWD/DVD"

For users of mplayer:

$ mplayer -dvd-device "$PWD/DVD" dvd://

Whichever media player you use, you should be able to do everything with this data that you would with a real DVD-Video: fast-forward, pause, skip chapters etc.

The next step is to commit the work to a DVD±R in order to make a DVD-Video that's playable in a set-top box.


This can be done in a single step, but for the time being we're going to split the operation into two distinct steps in order to verify that the resulting DVD-Video filesystem image will indeed fit on your blank media.

The first thing that needs doing is to create the image of the filesystem that will eventually be burned to your blank DVD±R:

$ mkisofs -dvd-video -o dvd.iso -V "DVD Title" "$PWD/DVD"


mkisofs is the tool used to assemble the files on your disk into a structure ready for burning to DVD. Its original sole purpose was to create ISO9660 filesystems for burning to CD-R, hence the name mkisofs.

-dvd-videomkisofs has since been updated to create filesystems that are to be burned to DVDs in order to create DVD-Videos. This is precisely what the -dvd-video command line option tells mkisofs to do.

-o dvd.iso − output the filesystem we're making to a file called dvd.iso.

-V "DVD Title" − many media players and some set-top DVD players will display the title of the DVD being played back. This is how you specify one. Note that you're limited to 31 characters if I recall correctly.

"$PWD/DVD" − the directory containing the DVD data to be added to the filesystem image and subsequently burned to the DVD±R. (Reminder: the $PWD environment variable is your current working directory).

Now let's take a look at what we have:

$ ls -ls
total 26207784
 416244 -rw-r--r--  1 howard users  425808384 2005-09-04 14:36 audio.ac3
      4 -rw-r--r--  1 howard users        532 2005-09-04 22:25 chapters
      4 drwxr-xr-x  4 howard users       4096 2005-09-06 21:48 DVD/
4486504 -rw-r--r--  1 howard users 4589680640 2005-09-04 16:14 dvd.iso
      4 -rw-r--r--  1 howard users        718 2005-09-06 21:47 dvdauthor.xml
7006900 -rw-r--r--  1 howard users 7168053248 2005-09-04 14:28 movie.vob
4485480 -rw-r--r--  1 howard users 4588632064 2005-09-04 16:03 newvideo.mpg
5839736 -rw-r--r--  1 howard users 5974039472 2005-09-04 14:43 video.m2v
3972908 -rw-r--r--  1 howard users 4064283599 2005-09-04 15:44 video.shrunk.m2v

The filesystem image is 4,589,680,640 bytes in size. That should fit onto one of my blank DVD±Rs. Let's check. Place a blank DVD±R in your burner and run this:

# dvd+rw-mediainfo /dev/hdc
INQUIRY:                [_NEC    ][DVD_RW ND-2500A ][1.06]
 Mounted Media:         1Bh, DVD+R
 Media ID:              AML/001
 Write Performance:     3.9x1385=5408KB/s@[0 -> 2295104]
 Speed Descriptor#0:    03/2295104 R@3.9x1385=5408KB/s W@3.9x1385=5408KB/s
 Speed Descriptor#1:    03/2295104 R@2.3x1385=3245KB/s W@2.3x1385=3245KB/s
 Disc status:           blank
 Number of Sessions:    1
 State of Last Session: empty
 Number of Tracks:      1
 Track State:           blank
 Track Start Address:   0*2KB
 Next Writable Address: 0*2KB
 Free Blocks:           2295104*2KB
 Track Size:            2295104*2KB
READ CAPACITY:          1*2048=2048

The above assumes that your DVD writer is IDE device /dev/hdc (secondary master). Substitute as necessary on your system. Note the '#' prompt as well − this needs to be run as root unless you've set yourself up with privileges to access the device as a normal user.

Note the highlighted line that starts "Free Blocks:". 2,295,104 sectors at 2KB (2048 bytes) per sector means 4,700,372,992 free bytes on the disc. Good − that means there's room for the filesystem on the disc. Now let's burn it. Had there not been enough room, you'd have had to delete the DVD structure previously built (rm -Rf DVD) and then go back to the section entitled Shrinking the video stream and use a larger shrink factor than the one calculated.

The two highlighted lines towards the top of the output of dvd+rw-mediainfo show us at what speeds we can burn the disc. The 2.3× and 3.9× speeds are usually rounded to 2× and 4× respectively. Most systems less than 4 years old can cope with 4× easily, so this is how you'll get the DVD filesystem image onto the DVD:

# growisofs -Z /dev/hdc=dvd.iso -speed=4

For a full DVD, this process should take around 20 minutes at 4× speed. A little under double that at 2× speed. Presumably half that at speed 8× for those lucky enough to have the hardware able to do it.

Theory has it that you can now feed this disc to a set-top DVD player and you'll have a DVD-Video that plays back your movie, and nothing but your movie (no trailers, advertisements, nag screens about viewing rights etc…)

This was the long-winded version. There is also a way of doing it that combines the creation of the DVD-Video filesystem image and burning it to the DVD±R in one step. This is indeed the way you'll do things normally in due course, once you get the feel for how much data you can burn − the reason I showed you this way first of all is so that you can learn to check first.

This is the shorter version:

# growisofs -Z /dev/hdc -speed=4 -dvd-video -V "DVD Title" "$PWD/DVD"

You should be able to infer the meanings of all the parameters from the explanations given above.

Oh, and while we think of it:

$ du -sm
29975   .

That's just shy of 30 gigabytes…


First, let's get rid of the ISO image and the DVD filesystem structure it was built from earlier. If we're adding subtitles, these have to be rebuilt anyway. We can also dump the non-shrunk MPEG2 video stream since we won't be using that either:

$ rm -Rfv dvd.iso DVD video.m2v
removed `dvd.iso'
removed `DVD/VIDEO_TS/VTS_01_1.VOB'
removed `DVD/VIDEO_TS/VTS_01_2.VOB'
removed `DVD/VIDEO_TS/VTS_01_3.VOB'
removed `DVD/VIDEO_TS/VTS_01_4.VOB'
removed `DVD/VIDEO_TS/VTS_01_5.VOB'
removed `DVD/VIDEO_TS/VTS_01_0.IFO'
removed `DVD/VIDEO_TS/VTS_01_0.BUP'
removed directory: `DVD/VIDEO_TS'
removed directory: `DVD/AUDIO_TS'
removed directory: `DVD'
removed `video.m2v'

Let's get another look at the subtitle channels present in the movie:

$ tcprobe -i /dvd -T 1 2>&1 | grep subtitle
(dvd_reader.c) subtitle 00=<en>
(dvd_reader.c) subtitle 01=<de>
(dvd_reader.c) subtitle 02=<sv>
(dvd_reader.c) subtitle 03=<da>
(dvd_reader.c) subtitle 04=<fi>
(dvd_reader.c) subtitle 05=<is>
(dvd_reader.c) subtitle 06=<iw>
(dvd_reader.c) subtitle 07=<ar>
(dvd_reader.c) subtitle 08=<el>
(dvd_reader.c) subtitle 09=<en>
(dvd_reader.c) subtitle 10=<de>
(dvd_reader.c) subtitle 11=<en>
(dvd_reader.c) subtitle 12=<de>

The 2-letter codes for the languages are those of ISO 639.

The DVD-Video I was using for these examples is the "Last Samurai" that's available in the UK. Quite a bit of the conversation in this movie is in Japanese and English subtitles are provided for these parts. A few other incidental subtitles are in subtitle channel 11 along with them.

Unlike the audio channels, which start at number "0", the subtitle channels are numbered from 32 onwards in the VOB file extracted from the DVD. Therefore, if I want subtitle channel number 11, I need to extract channel 11+32=43 from my .VOB file:

$ tcextract -i movie.vob -t vob -x ps1 -a 43 > subtitles.ps1


tcextract -i movie.vob -t vob − as usual.

-x ps1 − The type of stream we want to extract from the VOB file this time is known as a "private stream" and its type is "ps1". Note that it's a figure 'one' at the end, not a lower-case 'L'.

-a 43 − This is the number of the channel we want to extract.

> subtitles.ps1 − Output the data to a file called subtitles.ps1

Subtitles are in fact graphics. They almost always have a transparent background in order to enable the picture to show through them. The following stage extracts the graphics from the subtitle channel and also creates a file with information on when each graphic is to be shown so that they're synchronised with the voices. This is going to create a large number of graphics files − one for each subtitle − so it's a good idea to create a new subdirectory and work in there in order to avoid cluttering up the main working directory:

$ mkdir subtitles
$ cd subtitles
$ subtitle2pgm -o subs -c 255,255,0,255 < ../subtitles.ps1


subtitle2pgm − this is the command used to extract the graphics from the subtitle stream.

-o subs − the radix for the filenames to which the data will be output. The individual graphics files will be output to files named subs0001.pgm, subs0002.pgm, subs0003.pgm etc… and the file that tells us when each subtitle is meant to appear will be subs.srtx.

-c 255,255,0,255 − defines the colours of the graphics files output by subtitle2pgm. See here for further information.

< ../subtitles.ps1 − take the data from the subtitle data we extracted earlier from the .VOB file and process that.

A quick list will show you what's in there now (you'll obviously have more or less files than this if you're working with a different movie, title or subtitle stream):

$ ls
subs0001.pgm  subs0023.pgm  subs0045.pgm  subs0067.pgm  subs0089.pgm  subs0111.pgm  subs0133.pgm  subs0155.pgm  subs0177.pgm
subs0002.pgm  subs0024.pgm  subs0046.pgm  subs0068.pgm  subs0090.pgm  subs0112.pgm  subs0134.pgm  subs0156.pgm  subs0178.pgm
subs0003.pgm  subs0025.pgm  subs0047.pgm  subs0069.pgm  subs0091.pgm  subs0113.pgm  subs0135.pgm  subs0157.pgm  subs0179.pgm
subs0004.pgm  subs0026.pgm  subs0048.pgm  subs0070.pgm  subs0092.pgm  subs0114.pgm  subs0136.pgm  subs0158.pgm  subs0180.pgm
subs0005.pgm  subs0027.pgm  subs0049.pgm  subs0071.pgm  subs0093.pgm  subs0115.pgm  subs0137.pgm  subs0159.pgm  subs0181.pgm
subs0006.pgm  subs0028.pgm  subs0050.pgm  subs0072.pgm  subs0094.pgm  subs0116.pgm  subs0138.pgm  subs0160.pgm  subs0182.pgm
subs0007.pgm  subs0029.pgm  subs0051.pgm  subs0073.pgm  subs0095.pgm  subs0117.pgm  subs0139.pgm  subs0161.pgm  subs0183.pgm
subs0008.pgm  subs0030.pgm  subs0052.pgm  subs0074.pgm  subs0096.pgm  subs0118.pgm  subs0140.pgm  subs0162.pgm  subs0184.pgm
subs0009.pgm  subs0031.pgm  subs0053.pgm  subs0075.pgm  subs0097.pgm  subs0119.pgm  subs0141.pgm  subs0163.pgm  subs0185.pgm
subs0010.pgm  subs0032.pgm  subs0054.pgm  subs0076.pgm  subs0098.pgm  subs0120.pgm  subs0142.pgm  subs0164.pgm  subs0186.pgm
subs0011.pgm  subs0033.pgm  subs0055.pgm  subs0077.pgm  subs0099.pgm  subs0121.pgm  subs0143.pgm  subs0165.pgm  subs0187.pgm
subs0012.pgm  subs0034.pgm  subs0056.pgm  subs0078.pgm  subs0100.pgm  subs0122.pgm  subs0144.pgm  subs0166.pgm  subs0188.pgm
subs0013.pgm  subs0035.pgm  subs0057.pgm  subs0079.pgm  subs0101.pgm  subs0123.pgm  subs0145.pgm  subs0167.pgm  subs0189.pgm
subs0014.pgm  subs0036.pgm  subs0058.pgm  subs0080.pgm  subs0102.pgm  subs0124.pgm  subs0146.pgm  subs0168.pgm  subs0190.pgm
subs0015.pgm  subs0037.pgm  subs0059.pgm  subs0081.pgm  subs0103.pgm  subs0125.pgm  subs0147.pgm  subs0169.pgm  subs0191.pgm
subs0016.pgm  subs0038.pgm  subs0060.pgm  subs0082.pgm  subs0104.pgm  subs0126.pgm  subs0148.pgm  subs0170.pgm  subs0192.pgm
subs0017.pgm  subs0039.pgm  subs0061.pgm  subs0083.pgm  subs0105.pgm  subs0127.pgm  subs0149.pgm  subs0171.pgm  subs0193.pgm
subs0018.pgm  subs0040.pgm  subs0062.pgm  subs0084.pgm  subs0106.pgm  subs0128.pgm  subs0150.pgm  subs0172.pgm  subs0194.pgm
subs0019.pgm  subs0041.pgm  subs0063.pgm  subs0085.pgm  subs0107.pgm  subs0129.pgm  subs0151.pgm  subs0173.pgm  subs0195.pgm
subs0020.pgm  subs0042.pgm  subs0064.pgm  subs0086.pgm  subs0108.pgm  subs0130.pgm  subs0152.pgm  subs0174.pgm  subs0196.pgm
subs0021.pgm  subs0043.pgm  subs0065.pgm  subs0087.pgm  subs0109.pgm  subs0131.pgm  subs0153.pgm  subs0175.pgm  subs.srtx
subs0022.pgm  subs0044.pgm  subs0066.pgm  subs0088.pgm  subs0110.pgm  subs0132.pgm  subs0154.pgm  subs0176.pgm


The next step is to use gocr to perform OCR (Optical Character Recognition) on all of the graphics files in order to convert them to text. The subtitleripper project provides a script called pgm2txt, which wraps around gocr and will help for this:

$ pgm2txt subs


pgm2txt − this is the command that will go through all of the graphics files converting them to text.

subs − the filename radix is used by pgm2txt so that it can determine which graphics files to process.

When the process kicks off you might be told that the wherewithall to perform a spelling check is not installed on your system. This doesn't matter, it won't prevent the OCR from happening. If, on the other hand, spellchecking software is installed on your machine, you'll still want to check the results manually just in case.

Also, you will be asked about some of the graphics the OCR software is unable to deal with on its own. You will be shown an ascii-art representation of the graphic that can't be decoded and asked to say what it is:

# list pattern   x= 159   15 d= 20  13 t=1 1
The upper char was not recognized. Enter correct ASCII char, "string" or 4 to 8 digit hex unicode:

This is evidently (to a human!) a 'W', so just type W and hit Enter. Had it been two or more characters, like "IN" for example, you would have typed them enclosed in double quotes and hit Enter.

You will then be asked if you want to store the pattern so that the OCR software knows what it is next time it sees it. The best thing to do is "store to database" so that the pattern will be recognised again in other graphics, so hit 2 and then Enter.

Once the processing is complete, you'll have a .txt file for each graphic. The thing to do now is run our subs.srtx file through srttool in order to replace the references to text files in subs.srtx with the texts contained in the files:

$ srttool -s -w < subs.srtx >

The last but one stage is to check the newly created file for speling missteaks in the subtitles. Open the file in the text editor of your choice (users of Linux and other Unix-like systems are spoilt for choice and I really don't want to start yet another vi/emacs/pico religious war... nano rul3z!!) and you'll see stuff like this:

00:02:12,689 --> 00:02:13,909
San Francisco, 1876

00:07:23,370 --> 00:07:24,959
He's rude.

00:07:25,129 --> 00:07:28,279
That's how it is here.
A land of cheap traders.

The OCR won't be perfect, and always bear in mind that it'll be thrown for a loop by things that only a human could guess correctly because of context. The errors it makes tend also to be difficult to spot, such as mixing lower-case 'L', capital 'I' and the figure '1', so always proofread the .srt very carefully. Pay attention to punctuation, too. It tends to add full stops after exclamation and question marks, and the latter seem to get transformed into figure 7s ("Is this a question7.").


Technically, both subtitles and DVD menus are subpicture, or "SPU", data. The tool we use to multiplex them into the MPEG file containing the movie is spumux. spumux is told what data to add to the MPEG data in an XML file, the original MPEG data is fed to it through stdin and it spits out the modified MPEG data (with the SPU channel) on stdout.

The final stage is therefore to feed and the MPEG file without the subtitles through spumux in order to obtain a new MPEG file with the subtitles. For this, we're going to meet one of the XML file formats that spumux uses (there's another for menus). Go back up one directory level, to the directory with the newvideo.mpg video file, and create an XML file called spu.xml containing the following:

    <textsub filename="subtitles/" characterset="ISO8859-1"
      fontsize="24.0" font="arial.ttf" horizontal-alignment="center"
      vertical-alignment="bottom" left-margin="60" right-margin="60"
      bottom-margin="30" subtitle-fps="25" movie-fps="25"
      movie-width="720" movie-height="574" />

The whole structure is enclosed in a <subpictures> tag. This structure contains our subtitle stream, itself enclosed in a <stream> tag. The description of our subtitle stream is in the <textsub> tag. This tag has several key attributes that define how the subtitles will appear on the screen.

filename="subtitles/" − This is the file containing the texts of all of the subtitles and the timestamps when each one is to be shown/hidden.

characterset="ISO8859-1"spumux uses freetype2 to render the subtitles. freetype2 works with the UTF-8 character set, so subtitles need to be converted into that character set before being rendered. This is achieved using libiconv, which needs to know which character set we're converting from, ie: the character set the subtitles are in. The subtitles here are in English so it doesn't make much difference which one we use. If, however, they were in a language that uses accents or a different alphabet altogether, then this attribute tells libiconv which character set the text is in so that it knows exactly how to convert it into UTF-8.

fontsize="24.0" − This is the size, in pixels, of the subtitles. 24 is a good starting point but you might have to reduce it if you have very dense information to display. Conversely, if there isn't much to display and they won't get in the way of the movie itself, then you can probably afford to increase the size a little. Don't go much above 30 or you'll just be watching a subtitle show with something going on in the background.

font="arial.ttf" − This is the truetype font in which the subtitles will be rendered. spumux expects to find your truetype fonts in your ~/.spumux directory, but rather than have multiple copies of truetype fonts spread all over the place I decided to symlink the directory actually containing all these fonts to ~/.spumux:

$ ln -s /usr/X11R6/lib/X11/fonts/TTF ~/.spumux

horizontal-alignment="center" − Defines whether the subtitles will be centered horizontally or, if values "left" or "right" are used, aligned to the left or right of the picture.

vertical-alignment="bottom" − Displays the subtitles at the bottom of the picture. Other possible values with obvious effects are "center" and "top".

left-margin="60" right-margin="60" bottom-margin="30" − Your TV screen doesn't display the entire image coming from your decoder, DVD player, VCR, whatever. Part of the image spreads off-screen. These margins ensure that the subtitles will be displayed within them and therefore on-screen instead of off the edge. Another attribute, not used here but useful if the subtitles are displayed at the top of the screen, is top-margin="…".

subtitle-fps="25" movie-fps="25" − Depending on the subtitle file format used, the times at which subtitles are shown and hidden can be represented in hours, minutes, seconds and milleseconds or in frames. You'd think that it doesn't matter which notation you use, except that different parts of the world have different television standards with different frame rates. Here in North America and in Japan, NTSC is used with a frame rate of 29.97 frames per second, while elsewhere people use either PAL or SECAM with a 25 frame per second frame rate. Subtitle timings expressed in frames for one standard do not map to the same timestamps in another standard.
Consider this scenario. You have a movie such as Das Boot in German language and you've just prepared the subtitles in Spanish for the Hispanic market. Your movie is in NTSC at 29.97 fps and you prepared your subtitle cues in frames. All goes well. Now suppose you want to prepare the same movie for the market in Spain. Over there, they use PAL at 25 fps, so your subtitle cues are all going to be wrong. No need to worry, you don't need to recalculate them all. All you have to do is tell spumux that the movie-fps is 25 and that the subtitle-fps is 29.97, and spumux will make the necessary adjustments automagically.

movie-width="720" movie-height="574" − This is the resolution of the movie, in pixels. It is used to calculate the size of the channel that will bear the subtitles and be overlayed onto the picture. The real picture size is usually 720×576, but for some reason or other only known to their manufacturers, some DVD players prefer it if the subtitle channel is a few pixels smaller than that, so we "lie" about the frame size and pretend that it is, in fact, a little smaller.

Okay, so now we need to combine the original movie and the subtitles into a new MPEG file. This is done with spumux:

$ spumux spu.xml < newvideo.mpg > videowithsubtitles.mpg
DVDAuthor::spumux, version 0.6.11.
Build options: gnugetopt magick iconv freetype
Send bugs to <>

INFO: Locale=en_IE@euro
INFO: Converting filenames to ISO-8859-15
INFO: Detected subtitle file format: subviewer
INFO: Opened iconv descriptor. *UTF-8* *ISO8859-1*
INFO: Read 195 subtitles
INFO: Unicode font: 1185 glyphs.
STAT: 0:07:23.634

The last line will be updated showing the time of the next subtitle to be added while spumux is working its way through our subtitles. Once the last subtitle has been added, it'll read:

INFO: Found EOF in .sub file.

When all of the movie file has been passed through spumux, some statistics will be displayed:

INFO: 195 subtitles added, 0 subtitles skipped, stream: 32, offset: 0.26

- Processed 195 subtitles.
- The longest display line had 43 characters.
- The maximum number of displayed lines was 2.
- The normal display height of the font arial.ttf was 28.
- The bottom display height of the font arial.ttf was 39.
- The biggest subtitle box had 2752 bytes.

MPlayer can play back this new file and display the subtitles. Fire it up and use the keyboard to advance to where the first subtitle is. The "→" key advances 10 seconds, the "↑" key one minute, and "PgUp" 10 minutes:

$ mplayer -aspect 16:9 -sid 0 videowithsubtitles.mpg

Press "Q" to kill mplayer when you're satisfied with the result.

So there you are. You have an MPEG file with subtitles. Now all we have to do is burn a DVD-Video in a way that allows set-top DVD players to know that the included subtitles are in English. And while we're at it, we might as well build things so that set-top boxes know that the audio track is in English too. Load the dvdauthor.xml file we used earlier into your text editor. The parts displayed in bold here are additions or changes to the original file:

 <vmgm />
   <video format="pal" aspect="16:9" />
   <audio lang="en" />
   <subpicture lang="en" />
    <vob file="videowithsubtitles.mpg" chapters="00:00:00.000,00:01:46.600,00:05....

Obviously, we substitute the new filename in the <vob> tag. The <audio> and <subpicture> tags that we added above it will cause information to be packaged into the DVD-Video structure informing the player that the audio and subpicture (subtitles) channels are in English. While this isn't of much importance when there is only one of each, remember that there can be up to 8 audio channels and 32 subpicture channels, and that set-top players are usually programmed to choose a particular language (rather than channel number) automatically. Providing the language of each audio and subpicture channel that you mix into your titles enables the set-top player to choose the correct one automatically.

Build the DVD structure as before:

$ dvdauthor -o DVD -x dvdauthor.xml

Once dvdauthor has finished, we can check that the language information was recorded correctly:

$ tcprobe -i $PWD/DVD -T 1
libdvdread: Using libdvdcss version 1.2.8 for DVD access
libdvdread: Couldn't find device name.
[tcprobe] DVD image/device
libdvdread: Using libdvdcss version 1.2.8 for DVD access
libdvdread: Couldn't find device name.
(dvd_reader.c) mpeg2 pal 16:9 pan&scan+letterboxed U0 720x576 video
(dvd_reader.c) ac3 en drc 48kHz 6Ch
(dvd_reader.c) subtitle 00=<en>
(dvd_reader.c) DVD title 1/1: 41 chapter(s), 1 angle(s), title set 1
(dvd_reader.c) title playback time: 02:27:50.24  8871 sec

Looks good, so burn your DVD as before, and this time a set-top player will "know" what language your subtitles and audio are in.

Note that we didn't even attempt to recalculate the "shrink" factor and requantize the video stream in order to create more space for our subpicture channel. The space used by our subtitles is negligeable compared to that used even by the audio stream. We're dealing with single-digit megabyte amounts of data here, something like 0.1% of the data on the disc at the very most − nearer 0.03% in this particular instance.


>> /

Last update: 24-OCT-2006
This page has been served 40169 times since 05-JUL-2006