(2) Lossy Editing
« BACK Method 2: Lossy EditingNEXT »
(Not Recommended)

"...dude, look. I made an AMV lol"

Lossy Editing

I hesitate to even write this section because the alternatives are much much better, but truthfully, there are some formats and encoding techniques that allow you to throw away some quality... and are still suitable for editing, though uncommon. Some of these formats can be accessed the same way as Lossless Codecs:

But whatever you do, DON'T use Distribution Formats like XviD or DivX in your editing program. What does is mean? Well, there are two groups of video formats: those that are made for sharing over the internet, typically characterized by small file sizes at the expense of some quality loss, for 'Distribution;' and the second type are those that are lossless in quality and are made for editing. We obviously want to use the second type. Distribution/lossy formats use inter-frame compression techniques that, while good for reducing file sizes, can unfortunately cause problems in your editing program. (like frame-inaccuracy, slow seek-times in your timeline, low quality, instability, unreliability, or even nasty program crashes).

Now... if you are really set on doing lossy editing, I can't stop you, but it's best if you at least know what you are doing. In that case, you'll have to read the long explanation below; otherwise just forget about it... and use one of the other methods-- like you probably should be doing in the first place.

Why are some formats 'bad?' An explanation for the curious.

This has a lot to do with the trade-off between quality and file-size. See, there aren't that many formats that allow you to throw away quality to reduce file size and are still suitable for editing. One reason for this is because of something called inter-frame compression, where a frame isn't really a frame; but rather, it is made up of parts of the next frame to reduce file size.

"Inter-frame compression uses one or more earlier or later frames in a sequence to compress the current frame, while Intra-frame compression uses only the current frame." (See: Data Compression and GOP Structure.)

To help understand... think of a video that consists of two frames only: Frame 1 is of your favourite anime character sitting there doing nothing. Frame 2 is the same image, but with their mouth slightly open, about ready to talk. If you saved *all* the data from both frames, Frame 1 takes up 1KB, and Frame 2 also takes up 1KB for a total of 2KB. However, if Frame 2 is virtually identical to Frame 1, besides a moving mouth, why should Frame 2 take up the same amount of file space when it could simply use data from Frame 1? I mean, the background of the image doesn't change... the character is still sitting in the same chair... and the character doesn't really even move... except for their mouth...

This is pretty much where inter-frame compression comes in: because with inter-frame-compression, NOW Frame 2 only takes up 0.1KB worth of data since it only contains information for the moving mouth; the rest of the data can come from Frame 1. So, the total file size is drastically reduced to a mere 1.1KB for both frames. Now this is great if you need to send the file over the internet; and it works fine if you are watching the footage from start to finish. But with video editing, that's not the case. Often times, you seek forwards and backwards, or you begin somewhere in the middle of your footage. So, think about how your editing program is going to handle that? If you start at Frame 2, your program is going to get confused because there isn't really a full frame at that moment --only part of a frame. And in order to re-create the full image, your program has to look backwards to the previous frame to get the rest of the data. This requires more processing power to handle, expecially when there is a long chain sequence of frames that rely on each other. So naturally, reading the footage is going to be slow and lag in your editing program. Not only does this make editing more painful to perform, but this whole process of decoding previous frames can cause programs to lose track of what information goes where, leading to frame-inaccuracies where something you thought was supposed to happen at a certain time, ends up occurring at a different moment, which can screw up your AMV timing/synchronization, or in some cases, even cause nasty program/system crashes.

To overcome this issue, Editing-Friendly formats don't use inter-frame compression, and save every frame as a keyframe-- a full frame. Of course, this means your file sizes will be much larger; but when you seek through your footage in your timeline, there is almost nothing to decode; so the frames are displayed pretty much instantly. This makes for a much more pleasant editing experience where there is no lag: you don't have to wait for your computer to catch up when performing simple actions like: making your cuts, fades, and moving your clips around in the timeline. For this reason, you generally find good Editing-Friendly formats to be rather large in file size; and if a file is small in size, that is an indication it is highly compressed; and almost certainly uses inter-frame compression, which, as we have established, would make it 'bad' for editing. Alright. Now that you know all that, I think I'll tell you how to edit using lossy-- ohwait. nvm. I changed my mind. Just don't do it. Use one of the other method instead, please.

  • Good editing formats are not just about Quality: it's about Frame-Accuracy and Decoding/Reading Speed.
  • If you really like the anime, wouldn't you want it to look nice? Don't use lossy compression unless you have to.
  • Bad quality can be distracting in an AMV. It is also kind-of like a disservice to the original anime creators.

« BACK (DONE: Method 2:
Lossy Editing)
NEXT: Method 3:
FrameServing »

1 comment:

AMVGuide said...

Questions/Comments? Typos/Errors? Tips? Related Links?
Feel free to post a comment below. Your feedback is valuable.

Post a comment