Cleaning Edls

Cleaning edit decision lists is an important part of Edl management. It is usually performed by a computer program external to the editor. It assures that the events in the Edl represent the material recorded on the edit master precisely and are organized in a meaningful way. While the need for cleaning is more obvious in conventional video editing it still has relevance to non-linear systems.

What is Edl "cleaning"?

In conventional video editing, edits are recorded to tape and "events" representing them are recorded in the Edl. As editing progresses it may become necessary to re-record a section of the master. This changes the contents of the tape and adds an event to the Edl, but it does not, generally, update the previously recorded event (or events) at that location of the master. This leaves a "dirty" event (or events) in the list.

 

Over-records

The first most obvious example of a "dirty" event is the situation where the tail of a previous event is over-recorded:

A previously recorded event:

001  001   V     C        01:35:11:00 01:35:26:00 01:00:00:00 01:00:15:00

Now the current event "over-records" the tail of it:

002  002   V     C        02:02:16:22 02:02:18:22 01:00:14:00 01:00:16:00

 

Note that edit 002 goes in at 01:00:14:00, a second earlier than the out point of edit 001. Pictorially:

 

An Edl cleaning program would change these edits to:

001  001   V     C        01:35:11:00 01:35:25:00 01:00:00:00 01:00:14:00

002  002   V     C        02:02:16:22 02:02:18:22 01:00:14:00 01:00:16:00

 

Note that the source OUT and record OUT of edit 001 have been trimmed 1:00 earlier. The list (only two edits) is now "clean" - the extra frames on the tail of edit 001 are removed and edit 002 follows it exactly.

 

Inserts

Another slightly more complex example is the situation where an event is "inserted" into a previous event. First, a previous event exists in the list:

001  001   V     C        01:35:11:00 01:35:26:00 01:00:00:00 01:00:15:00

Now the current event is "inserted" in the middle of it:

002  002   V     C        02:02:16:22 02:02:21:22 01:00:07:00 01:00:12:00

 

To clean this situation we need to make a new event. An Edl cleaning program would change these edits to:

001  001   V     C        01:35:11:00 01:35:16:00 01:00:00:00 01:00:07:00

002  002   V     C        02:02:16:22 02:02:21:22 01:00:07:00 01:00:12:00

100  001   V     C        01:35:24:00 01:35:26:00 01:00:12:00 01:00:15:00

 

The first edit has been broken in two by the second edit - edit 001s OUT points have been trimmed to match the IN of edit 002, and edit 100 (the third "created" edit) is the remainder of edit 001 (the tail of it).

These two examples illustrate the essence of cleaning Edl's. Needless to say, it becomes rather complex as the subtleties of Video and 4 Audio channels, dissolves, wipes, keys, split edits, etc. are considered.

 

Why is cleaning important?

A clean list is important for several reasons:

A "raw" or "dirty" Edl is virtually impossible to read. For any event you may be scrutinizing it is very difficult to see whether another edit somewhere in the list may have altered it. When you are looking for a shot, or using the list for logging purposes, etc. a clean list is a must.

A clean list is critical for ON-line assembly. If the assembly proceeded exactly the way the "raw" list was created, it would work, but it is obviously inefficient to execute all the edits of the Off-line. A strictly "sequential" (A-mode) assembly can be very in-efficient, especially when creative and technical requirements of ON-line are considered. Effects, audio mixing/levels, TBC "painting" all effect the order in which events are selected for execution. With a clean list, the show will fit together no matter the order it is done. If the list is dirty, you have a nightmare.

Sorting Edl's is a useful tool for may purposes, especially optimizing Edl's for assembly. A list must be clean if it is to be sorted. If the list is dirty and the order of the events is changed, the Edl may be wrong. Consider what would happen if the two edits of the "over-record" example, above, were to be reversed in order (edit 002 preceding edit 001). The assembly of those two edits would be entirely incorrect!