Encoding DVD to AVI in High Quality

It's not so much what software as what codec you should use with the software. And for that, I recommend to download and install the free CamStudioCodec designed originally for the CamStudio screen capture software. This codec is completely lossless, just configure it to use the GZIP compression.

Then, with whatever editing software you use, just save your files to AVI using that codec. The files will be well compressed, but every pixel will be saved as is, so there is no loss of quality.

This, as far as I know, only works under Windows, so if you use a Mac, disregard my post.
 
Forgive me for being ignorant, but if you are compressing, how is it lossless? You say it's compressed, but all the data is still there? I guess I'm just confused how that can be true (maybe it's marketing gimmic, because as far as I know, when you compress, you take something out to save space and thus don't have all the data there).

As far as what you want to do, try doing a google search for DVD to AVI or something like that. There are tons of programs out there to do what you want, and a lot of them probably have quality options. Just make sure you have permission to use the movie's footage before you do so.
 
ralck said:
Forgive me for being ignorant, but if you are compressing, how is it lossless? You say it's compressed, but all the data is still there?
Yes, all data is still there. Data compression works because data is redundant, so a long string of data can be expressed by a small string of data.

Indeed, we do it in our everyday language. Instead of American Automobile Association, which is a string of 31 letters (including the blank spaces), we write down AAA, a string of three letters. As long as we know what that short string stands for, we can recover the original string from it.

Computers work in similar ways. They use two types of compression. One, quite well known in our circles here, is the lossy compression used by JPEG images and MPEG movies or MP3 audio. All of these change the image (or sound) to something that the average person cannot tell apart from the original, which results in fewer actual values, so they can be expressed in less than 8 bits per byte and similar. But by changing the image, it has thrown away some information, so it is lossy.

The other, lossless, works like that AAA example, compressing redundant data into smaller chunks of data that exactly represent the original data, so decompressing the compressed data will give us the exact same data as we had before compression.

One such compression is GZIP, which is a general compression, i.e., compression used for any kind of data. When used on redundant data, it compresses well. When used on random data with no redundancy, it performs poorly and can actually increase the size of the data.

The codec I mentioned takes advantage of the fact that in motion pictures, there is a lot of repetition from one video frame to the other. For example, if you show a person walking, the only thing that changes is that person. But the background stays the same, or mostly the same.

So, if you just subtract the value of each pixel from the corresponding pixel in the previous frame, you'll end up with a lot of small numbers and much repetition, so instead of something like 10, 230, 75, 131, you may end up with 1, 0, 1, 1, assuming that the corresponding values in the last frame were 9, 230, 74, 130. And GZIP does a great job in compressing a series of small numbers. In the above example, you need 8 bits per value for the original set (10, 230, 75, 131), but only two bits per the differences (1, 0, 1, 1), so you only need one fourth of the storage.

It is somewhat more involved than that, but that is the gist of it: Yes, you can compress video (and audio) and then decompress it to the exact original if you are using a good algorithm that takes advantage of the common redundancies in video (and audio) data.
 
Okay, so what you are saying is not true lossless. You say that it only records the 'new' pixels, and when playing back, keeps all other pixels the same. Great, but it's technically lossless because you don't have all the pixels for every frame. Lossless means exactly that; you have all the original data exactly and untouched.

Sure, that makes it look great when viewing it, but that's horrible for editing. When the user would try to cut two clips together when the compression was like that, would look horrible because the entire screen wouldn't change at once, but only the parts that moved. As you said, if you know what AAA stands for, you know what it means and can convert it to American Automobile Association. Notice that AAA does not have "merican", "utomobile", and "ssociation" in it, so if you don't know how to convert, you can not get all the data back. An NLE won't know this without you telling it to convert it, which simply converts it to a lossless format (if possible). For this kind of compression, you could convert to a lossless format, but why not just convert the original DVD to lossless?

So really, if you want to edit clips out of a DVD, you'll want to convert it into uncompressed AVI or as little compression as possible (if you can't do uncompressed). Keep in mind file sizes will be VERY big.

I'm a computer engineer and have actually studied compression in some of my classes (hence why I posed the question). The compression you mentioned, Red Prince, is one of the best for playback of a finished video, but is not good for editing with and is not lossless.
 
ralck said:
You say that it only records the 'new' pixels, and when playing back, keeps all other pixels the same.
I said no such thing.

That codec is truly lossless. If you are a computer engineer who has studied compression (and by the way, I have been programming computers since 1965), why is it so hard to comprehend that compression can be lossless.

It is very simple:
  1. You take some data, compress it, and the data is smaller.
  2. You decompress the compressed data, and you now have the exact same data you had before you compressed it.
The CamStudio codec does that with video data, which it prepares so GZIP compresses it even better. After GZIP decompresses it, the codec then restores the original data.

So, once again, before compressing it with GZIP, it calculates the difference of the current frame from the previous frame. That makes the data compress better. After it decompresses it, it combines the now restored differentials with the previous frame, thus restoring the exact same pixels it had originally.

In other words, to keep with the same example, if after unzipping it gets 1, 0, 1, 1, and the corresponding pixels in the previous frame were 9, 230, 74, 130, it knows that the current pixels are 9 + 1, 230 + 0, 74 + 1, 130 + 1, that is, 10, 230, 75, 131, which is precisely the same values of the original.

Obviously, it does not do this to the very first frame or any other key frame. Those it just compresses with GZIP.

That is completely lossless.

At any rate, the full C++ source code to the codec is available. So, if you don't believe me, go to the page I linked to above, find the source code, and see for yourself how it works.
 
I must appologize, as I read over your post a little too quickly. That codec does keep a value for every pixel (not the original value, but one that can retrieve the original when decoded, if I understand correctly).

I still say that this is not a good format to edit with. Lets look at your example, where it encodes the first frame, and then encodes the second frame being 1, 0, 1, 1, etc. What happens if you decide in your NLE that you want to cut off the first frame? The first frame it displays will then be 'wrong' pixels because the bits storing them are 'wrong'. Your NLE won't care because it just sees each frame as a series of bits, and as long as those bits are there, it will assume you want it to be 1, 0, 1, 1 (which with the first frame intact, you do). So what I'm saying is that isn't it better to just used uncompressed AVI? Unless I'm missing something else here...
 
No problem.

The editor and the codec, they each do their job separately from each other. The codec knows nothing about editing, the editor knows nothing about compression.

So when the editor reads the data from the file, it asks the codec to decompress it. The editor only sees each frame fully decompressed. It has no idea how it was stored in the file. It does not see the differentials, it only sees the fully restored pixels of each frame.

Then when the editor saves the changed video, again, it passes full frames to the codec, which then compresses them. Whatever becomes the new first frame is saved as is, the following frames are saved as differentials.

So, it does not matter that the original first frame is no longer there. You never lose anything.
 

Network Sponsors

Back
Top