The great thing about standards is there are so many to choose from.
- Someone

undvd 0.5.0 introduced a new option to choose the codec and container for the rip. The only problem is that you have to know which ones to choose. mencoder supports a staggering number of codecs and containers, most of which are now exposed also in undvd. The resulting rip can also be remuxed to a couple of other popular containers with additional tools.

But I wasn't content with solving a problem by introducing a new problem. Now, it's not so easy to say exactly which combinations are good and bad, but if at least you knew which ones definitely do not work, that would be a start, wouldn't it? Then at least you can rescue the user from phase one of the Monte Carlo method in getting something that actually works.

The methodology is like this:

1. Rip 5 seconds of the dvd using undvd with a given container/video codec/audio codec combination.
2. Attempt playback with mplayer.

This is what codectest does. The result is either a text file showing line by line whether or not the given combination successfully produced a rip, or a pretty matrix picture. This gives you an idea of what you can expect to use. If you run this on your system, it's also a tip off if you see something that should work but doesn't.

I must stress that if the given combination of codecs does produce a file, this is no guarantee that the file is to be considered a good rip. It may not play on other media players, it may not even play on mplayer (incidentally, this is something akin to a fuzzer, I've discovered that some combinations really aren't expected :D ). So if codectest says it works, verify that you get a working video file out of it!

The standard set looks something like this:

It's also possible to run it on the full combination of all codecs and containers that are now exposed in undvd. You'll need a few hours to do it:

I have been very skeptical about adding options for other codecs in undvd, purely because of the test burden. With a single combination of container and pair of audio/video codecs I can be reasonably confident that I've done enough manual testing (and judging video quality doesn't trivially lend itself to automated testing, sadly) to account for most potential problems.

But at the end of the day it's a question of priorities, and having scratched all the important technical itches by now, if anything this is the right time for it. I got some user feedback recently that set me onto this path. The user was having trouble playing the files encoded in the classical avi+h264+mp3 format on other platforms, and that's when I asked myself how important is it really to have a single format? As long as the default still works well, what's the harm in offering a little customization?

Testing is a huge problem, which is why this new feature is considered to be experimental. The most common seems to be bad a/v sync. There is just no way to account for all the possible combinations of codecs and containers, and to maintain an up-to-date document for this as things evolve. So the burden of testing is squarely on the user here (which is quite unfortunate).

The new functionality is available in undvd 0.5 and up. Here's a shot of the new goodness. All these files were encoded from the same dvd title. A 22 minute title was ripped with different containers (represented with different filenames). The audio codec is mostly the same in all cases (mad = mp3), except for 1.mp4 (faad = aac). The video codec is also mostly the same (h264 = avc1), except for 1.flv. The only variation here is the container being set to different values, all the other settings are defaults. You can also witness that some containers are more wasteful than others (given the same a/v streams), but not by a huge amount. (The audio bitrates shown are actually misleading, mplayer seems to give the lowest bitrate in a vbr setting.)

This demo is by no means exhaustive of the full collection of codecs that can be used, for that see the user guide. There is also an option to use the copy codec, which just copies the audio/video stream as is.

So you wanna drive coast to coast huh? That's what people say anyway, "oh how romantic, all those small towns, the landscapes".

Some people have a dream of driving in the US. I guess they relish an exciting drive across the Bible Belt and then desert country.

According to Google, you can do New York-LA in a day and 17 hours, provided you pick the shortest (and fastest?) roads and drive non-stop.

What about coast to coast somewhere closer to home? Every summer a bunch of tourists pack into their cars and drive up to the north or Norway for a relaxing road trip on our narrow and windy roads.

The scale here is 1:2.

I had to put in two extra pins on the map, or Google would send me into Sweden. But there's your Lindesnes-Nordkapp connection.

It turns out the East-West coast span of the US isn't even twice as wide as our North-South run, and you can do it in roughly the same amount of time.

So basically if you've done North-South in Norway you've done more than half the distance across the US. Doesn't sound that impressive at all anymore, does it? :D

Ps. In the Netherlands you can do Maastricht-Groningen in 3 hours, it's like a paper route. :howler:

What is this obsession people have with books? They put them in their houses - like they're trophies. What do you need it for after you read it?
- Jerry Seinfeld

I think it's because reading a book takes a lot of effort, and we want to get credit for it. Reading a big book takes considerably longer than anything else you might do for "fun". And then you can point to it and say, "look, this is what I know".

I have a bunch of computer books, a lot of them from college, that I'll probably never toss out even though I'm unlikely to ever re-read them. Meanwhile, I can do what a lot of people are doing and put them on display. "Look, I must be really clever, I have all these books!"

Frankly that's all they're good for after I'm done with them.

The word tuple is used quite a lot in computing. That's what database people call a row in a table. It's also what several programming languages call a structure where the fields are ordered but not named.

It seems to be one of those words that is hard to translate, so other languages often use the English word. And yet there is some confusion about pronunciation. Some say tahple, some say twople. As far as I know there is no dispute about the spelling, it's tuple. So where do you get twople from that?

I think having a lot of exceptions on pronunciation from what is the obvious pronunciation is bad for language. There are words that are fancy or interesting enough to perhaps deserve it, but tuple isn't one of them. So I'm going to keep saying tahple.