Maybe we should encourage TMPGenc to write his codec as a plugin for Vegas. I got QuickTime and DivX codecs as plugins and they're now available to me when i render in Vegas.

Who makes the U-lead encoder? What was your main compliant with Main concepts encoder in Vegas?

1. Ligos - I *think*, which suprises me because I think their stand-alone encoder is awful.
2. Washed out colours; blockiness in 'busy' shots

Bear in mind I'm talking of SVCD quality here, DVD bit rates being higher tend to even out the differences between various encoders. I am also aware of the gamma correction advised by SoFo for MPEG rendering: it improves, but not enough.

-Pete

The ligos encoder which plugs in premiere is decent also but the stand alone that comes along with it in the suite IS awful so I understand where you're coming from. Sit tight & don't give up on Main concept. The 3.0a update which should post any day now not only is bug fixes but from my understanding it addresses the colors issue so you should be very satisfied with the update.

I can't agree more. I've been using TMpgEnc for many months and still don't know what all the settings do. I've posted suggestions over on his board, but I think the guy is swamped. Here are some things I'd like to see - maybe MainConcept would be interested...

Let me specify the media I am targeting (650 MB VCD, 4.7 GB DVD, etc.) and have the application choose the perfect bitrates to maximize that storage. There might be other settings needed from the user like the preferred audio rate and quality settings, but this shouldn't be that complicated. Right now, I have all these spreadsheets I've written that tell me what rates to use based on the length of my movie and the media I'm targeting.

Better help. Please! Why can't any Mpeg encoder actually tell us what settings do. One-liners like "Audio Rate: This is the rate of the audio" do not really help. Please tell us what each settings does in human terms, how it effects quality, and how it effects encoding speed.

Quality, Quality, Quality. To me anyway, quality comes first, speed second. I spend a lot of time working on my video - I don't want the default settings to produce crappy results. I want 2-pass VBR with the best motion detection possible. I don't care how long it takes. It is nice to have faster settings for doing test runs.

Icing on the cake: Give us a live estimated time the file will take to encode, which changes as we change settings in the configuration dialogs. The only way I could see this really working is if the encoder had background threads that actually went off and started encoding with the current settings so that it could calculate the estimated time based on the speed of the machine. If the user changes a setting, the background threads would stop and start encoding using the new settings.

I think that what everyone is asking for is nice but it really is impossible at the moment. Encoding (especially with software) to MPEG 2 is a complex process. Every situation from scene to scene has very differnt parameters if you are looking for a clean encode. It really is an art more than a set science. Some hardware is very good at figuring out all of it, but it requires a lot of onboard processing to figure it out. With software encoding you have to make those choices yourself. Yes some software works better than others but the choices are not standard. All those settings in TMPGEnc actually make a difference although some really only apply to encoding for satellite transmission HD.

The Main Concept MPEG output as it exsists in the templates in VV3.0 is not the best out there. It is a solution for many people. MC is working with SF and I am confident that it will continually improve.

The point that I want to make though is, the settings need to be there to fine tune a good encode. MC and SF as well as TMPGEnc provide default templates that are as generally a good setting as you can get without analizing each piece of video. Those templates do what you are asking for. Short of that, you need to spend some time and study MPEG formats and encodes. In that you will need a little knowledge of DV fomat as well as component and composite formats to grasp how those settings are really there for your benefit. Let's face it, when I don't want to sit and figure it out, I pick a template and off I go.

I think that when a consumer demand exists (and this one not only exists but is also increasing at a phenomenol rate) then commercial interests will marshall to supply a solution. Let's face it, until the last year or so most people couldn't have cared less about MPEG, it dwelt in the domain of professional studios and nerdsville.
But, we are now getting affordable DVD recorders, and DVD players that will play video CDs. Before very long VCRs will be quaint mementos of an analogue past.
We really do need easy to use and, above all, high quality encoders. If the state of the art currently precludes all this being done automatically - and I, for one, am not persuaded that it does - then we should at least have more meaningfully named parameters, perhaps even a whole range of templates for different types of footage.
The situation we have now reminds me somewhat of the way it was when we first started to program Windows. We'd write the code in DOS based editors, with the API manuals propped up in front of us, trying to second guess what the results of our efforts would look like when actually running - and of course we always guessed wrong. And now, look at all the RAD systems that make a programmer's life so much easier by freeing him from abstruse technicalities and allowing him to concentrate on the end result.
So should we videographers be freed to concentrate on the artistic side of our practice; the nitty-gritty technicalities of transcription quality should not concern us. I believe there is a very real opportunity for SoFo with its admirable design skills to seize the upper ground here. If not, someone soon will, possibly one of the hardware suppliers such as Canopus.

-Pete

-Pete

>How is it that one programmer who gives away his program writes a better encoder >than larger companies with teams of programmers?

He, he,
in the past, he must pay more attention at school...:)

It happens though.
If you want another example, take a look at ScenalyzerLive and compare it with Pinnacle's DV Tools II. One's written in a bedroom and costs next to nothing; the other's written on Mars (no way was it ever designed for humans).
The inescapable conclusion is that this one-man-band can program the DV500 card better than its makers. What's more Andi [SCLive's author] can do scene detection even when the source is not digital and thus has no timecode to help.

I think I'll ask him if he's ever thought of writing an MPEG encoder :)

The hardware solutions are the place where the function that you are talking about is now available. At work I use an OptiBase card that does the encoding and has the ability to process and make the choices. Still not as good as an encode specialist analysing each scene but I can hardly tell the difference until I need a 4m bitrate. As long as I stay at 6m the hardware can figure it out and it is beautiful.

K