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.
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.
Introduction
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
Chapters
Using dvdauthor
Burning the DVD
Extracting subtitles
OCR
Multiplexing the subtitles into the movie
Menus and multiple titles
INTRODUCTION
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.
BLANK MEDIA
DVD+R or DVD-R?
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.
WHAT MAKES UP A DVD-VIDEO?
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.
REQUIRED HARDWARE
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)
REQUIRED SOFTWARE
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…
EXTRACTING A TITLE FROM THE DVD-VIDEO
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.vobIf 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.vobExplanations:
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.
DEMULTIPLEXING THE AUDIO AND VIDEO
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 kbpsThe 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.ac3Explanations:
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.m2vDepending on the speed of your computer and its disks, this can take quite a while…
Explanations:
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.vobA 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…
SHRINKING THE VIDEO STREAM
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.47This 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.
Explanations:
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.vobThe 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.
REMULTIPLEXING AUDIO AND VIDEO
This is the easy bit:
$ mplex -f 8 -M -o newvideo.mpg audio.ac3 video.shrunk.m2vExplanations:
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.vobThe .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…
CHAPTERS
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:
#!/usr/bin/perl @output = grep /\[Chapter \d+\]\s+\S+/, <>; @times=(); 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 > chaptersExplanations:
tcprobe -i /dvd -T 1 − look at the DVD-Video mounted on /dvd and output information pertaining to title 1.
2>&1 − tcprobe 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 00:00:00.000,00:01:46.600,00:05:23.800,00:09:32.880,00:12:40.040,..........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.
USING DVDAUTHOR
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:
<dvdauthor> <vmgm /> <titleset> <titles> <video format="pal" aspect="16:9" /> <pgc> <vob file="" chapters="" /> </pgc> </titles> </titleset> </dvdauthor>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:
<dvdauthor> <vmgm /> <titleset> <titles> <video format="pal" aspect="16:9" /> <pgc> <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,..." /> </pgc> </titles> </titleset> </dvdauthor>We're now ready to build the new DVD-Video's filesystem structure:
$ dvdauthor -o DVD -x dvdauthor.xmlIf 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.VOBYou 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.
BURNING THE DVD
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"Explanations:
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-video − mkisofs 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.m2vThe 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] GET [CURRENT] CONFIGURATION: Mounted Media: 1Bh, DVD+R Media ID: AML/001 GET [CURRENT] PERFORMANCE: 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 READ DISC INFORMATION: Disc status: blank Number of Sessions: 1 State of Last Session: empty Number of Tracks: 1 READ TRACK INFORMATION[#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=2048The 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=4For 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…
EXTRACTING SUBTITLES
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 `DVD/VIDEO_TS/VIDEO_TS.IFO' removed `DVD/VIDEO_TS/VIDEO_TS.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.ps1Explanations:
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.ps1Explanations:
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.pgmOCR
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 subsExplanations:
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 > subs.srtThe last but one stage is to check the newly created subs.srt 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:
1 00:02:12,689 --> 00:02:13,909 San Francisco, 1876 2 00:07:23,370 --> 00:07:24,959 He's rude. 3 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.").
MULTIPLEXING THE SUBTITLES INTO THE MOVIE
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 subs.srt 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:
<subpictures> <stream> <textsub filename="subtitles/subs.srt" 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" /> </stream> </subpictures>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/subs.srt" − 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 ~/.spumuxhorizontal-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 <dvdauthor-users@lists.sourceforge.xxx> 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.634The 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 Statistics: - 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.mpgPress "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:
<dvdauthor> <vmgm /> <titleset> <titles> <video format="pal" aspect="16:9" /> <audio lang="en" /> <subpicture lang="en" /> <pgc> <vob file="videowithsubtitles.mpg" chapters="00:00:00.000,00:01:46.600,00:05.... </pgc> </titles> </titleset> </dvdauthor>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.xmlOnce 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.
MENUS AND MULTIPLE TITLES
Last update: 24-OCT-2006
This page has been served 40658
times since 05-JUL-2006