Creating Lossless Intermediate Video in Adobe Premiere Elements

I had some video. I wanted to edit it, save the resulting file, and then edit that. I knew that running video through multiple generations of lossy editing would make it lose quality. My goal was to minimize or eliminate that loss of quality.

Considering Options

I was planning to use Adobe Premiere Elements for my video editing, so I posted a question on this in an Adobe forum. I got several suggestions in response. I understood those suggestions as follows:

  • Since I was using 1280×720 video input, one suggestion was to designate M2T or MP4 output. Unlike AVI, Premiere Elements would allow me to output 1280×720 video in these formats. Besides, the output would be much more compact than AVI.
  • Since I thought I might be doing more than one intermediate edit, I was reluctant to incur even the otherwise barely noticeable loss of quality that M2T/MP4 would entail. So I was interested in the suggestion that I create a 1280×720 Lagarith AVI as my output.

Using the Lagarith Option

To make the Lagarith option work, I began by downloading the Lagarith codec (from Softpedia rather than from the Lagarith homepage). I followed the advice to download and run the installer, and then reboot. Then I started Premiere Elements, assembled my input video, and went looking for the output codec. In Premiere Elements 12, I found it at Publish + Share > Computer > AVI > Advanced > Video tab > Video Codec: Lagarith Lossless Codec.

While I was there, I set Width at 1280. That made the Height 853. But according to the Properties > Details tab in Windows Explorer (and also Media Tab), my input video definitely was 1280×720. So I unchecked the link box next to Width, eliminating the automatic change of Height, and instead manually entered a height of 720. I changed other settings there as desired (including Render at Maximum Depth of 32 bit), and named the resulting preset Lagarith AVI.

Comparing Lagarith Outputs

The input videos, with a combined playtime of 3:55 (i.e., not quite four minutes), totaled 236MB. The Lagarith output file was 3.6GB. It took about four minutes to create on drive D, using an Intel Core i7-4790 machine running Windows 7 x64, where drive C was an SSD. Media Tab confirmed that the output was 1280×720. It played without extreme distortion in Windows Media Player (WMP), VLC Media Player 2.2.1, and MPC-HC (Media Player Classic). It did not play at all in Quick Time Player 7.7.8.

I emphasize “extreme” distortion because it did not play well in 32-bit IrfanView. But even when played in WMP, VLC, or MPC-HC, the output was still somewhat distorted. Specifically, when compared to the original, it was squashed: things were too wide. I also noticed that, when viewed in fullscreen as distinct from the default window size, all of these players added undesirable windowboxing (i.e., black space on the sides as well as the top and bottom). Apparently that was just because the output was not optimally sized for my monitor.

I tried again, accepting the 1280×853 dimensions originally favored by Premiere Elements. The output file took about the same amount of time to produce as before, and was only slightly larger, at 3.8GB. But it was still squashed.

For purposes of comparison, I tried outputting to the regular DV NTSC Standard and DV NTSC Widescreen presets in Premiere Elements. In both cases, the resulting files were created in about one minute, they were only 872MB, and the quality was much worse than in the Lagarith outputs. But neither produced squashed output.

In further experimentation, I tried Lagarith with 1280×640 and 1280×960. Then I compared screenshots from the four dimensions I had tried. Aside from screen fit, none seemed to be producing any difference. The size specified in the output dialog did seem to be affecting the dimensions of the actual output: the Details tab in Windows Explorer > Properties was reporting different sizes. When I tried importing those various outputs into a new Premiere Elements project, I saw that windowboxing varied considerably from one size to another.

As far as I could tell from these experiments, the best solution would be to output a Lagarith AVI file measuring 1280×720, same as the input files, and then resize that output to remove squashing. To resize and produce the final output, I went into Applied Effects > Motion > uncheck the Constrain Proportions box > set Height to 110 and Width to 100. That setting filled the screen. The video no longer seemed squashed. I tried outputting that into an MPEG file, using the HD 720p 30 preset. That was the solution. There was neither squashing nor windowboxing in the final Lagarith output.

Comparing M2T

Now I wondered how that MPG file, produced via Lagarith, would compare to a file produced via the other route. I reloaded the original project and, this time, output it to M2T format. To do this, I chose Publish + Share > Computer > AVCHD > M2T – HD 720p 60. That took about 4:45, rather than the approximately 3:45 needed to produce the Lagarith file. (Maybe one of the other presets would have been faster.) The resulting M2T was only 616MB. It did not appear to have problems with video being squashed or windowboxed.

Then I used that output M2T as my import M2T, and again produced an MPEG file using the HD 720p 30 preset. This step was much faster than it had been in the Lagarith approach — taking maybe half the time, or less — probably because the intermediate file was so much smaller. The resulting output file was slightly larger than the MPEG produced from the intermediate Lagarith AVI file: 404MB vs. 392MB. With just one intermediate generation, I saw (as predicted) no difference in the output files.


Given the minor hassles of installing the Lagarith codec, and of editing the intermediate file to remove squashing, and the larger file size, it did seem that the M2T approach was fine, when there was only one intermediate generation. But the lossless Lagarith codec would presumably be superior to lossy (e.g., M2T) intermediate files, in a project involving repeated editing generations, recurrently treating one output as yet another input.

This entry was posted in Uncategorized and tagged , , , , , , , , , , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.