Would you consider TMPGEnc or Cinema Craft's Encoder to be "Freeware Bootlegging Tools"?

I'm not sure what you mean here SonicEPM. Including the option to Frame serve simply allows Vegas to utilize third party encoders without the nauseating intermediate step of rendering to an uncompressed video file.

The built in encoders/compressors are good for the most part, but they are not perfect and they do not suit every need.

Let's take DVD for example. I use an authoring tool called Spruce-Up, which I don't believe is available anymore, but it's a good one. The files that come from the Main Concept encoder do not work directly with Spruce Up. I have to render the audio and video separately, and then Multiplex them with TMPGEnc. Then they work perfectly. (yes, I'm using the updated MC codec in VV3a)

On the other hand, if I do the MPEG2 encoding with TMPGEnc in the first place, there is no need for extra steps, and no need to render audio and video separately, since the TMPGEnc generated files are compatible with every DVD authoring tool I've ever used. And let's not forget the encoder is far more powerful than the built in MC one. Manually setting 'I frames' is sometimes critical to getting the best encodes possible. Also almost every setting in the encoder is documented in the program, or on the web with lots of support from the user community.

Also, TMPGEnc utilizes multithreading better than a lot of other encoders, so even though the built-in MC encoder should be faster, it's only using half of the processing resources available to it!

Enter 'Frame Serving'. Vegas could render directly into the TMPGEnc program or any other program with frameserving capability, and that would result in:

- less time/frustration dealing with intermediary steps
- Vegas users could take advantage of the latest developments in encoding technolgy without waiting for them to be directly implemented into Vegas's built-in encoders.

Maybe someone could help me here to point out what the negatives are... since I can't seem to think of any. (I have no idea what this 'freeware bootlegging' stuff has anything to do with implementing frame serving in VV)

- ben

My apologies about the frameserver comments- there ARE a ton of people who are bootlegging DVDs and VHS movies and we want no part of that.

I agree that frameserver capability would be useful in certain circumstances. If you would like to contact your favorite MPEG provider, I'll be happy to discuss helping them write a plug-in or perhaps implement frameserver capabilty.

SpruceUp, I believe, required separate elementary streams. This is a render option in the MPEG>custom>systems page of Vegas. My old contacts at Spruce our no longer taking my calls...some guy named "Steve" keeps answering the phone and he always says the same thing: "Make it look like a Sunflower".

Quite a ridiculous comment to make don’t you think (bootlegging)? Considering the financial difficulty Sonic Foundry are in at present, I hardly think you should be concluding that everyone operates on such a level.. and therefore attempt to keep your user-base as happy and contented as you possibly can. Its hardly surprising that Vegas Video (being as wonderful as it is) is not getting the press it deserves with mightier-than-thou attitudes like that.

The frame-serving argument was put over wonderfully by the earlier poster, therefore little need to go over old ground again; but just to reiterate a point, that I wish to use the frame-serve method purely to have as complete to perfect a final encode as I possibly can. This currently means translating as much footage that was made to a trip to Sicily last year as close to perfect for SVCD use. If I use the ‘forced upon’ MC MPEG codec supplied with VV3 the results are less than perfect.. infact, woefully imperfect if the truth be told.. with numerous imperfections within the final render (irregardless of settings, be they default or otherwise used). TMPGEnc provides one of the highest quality renders for SVCD (and DV) encoding. Is it so wrong for to ask for such a wrapper to be made..?

TMPGEnc are not going to write a wrapper for the program, that is going to be left to you. Possibly you can get in contact with http://www.videotools.net and ask the author of the "Video Server Plugin" (which is really quite useful and far easier to use than AviSynth) to create one for Vegas Video (I think he has more important projects at the moment, however) .. or better still, spend a few hours writing one of your own. It can hardly be that difficult from SF’s point of view.. and peeking into one of the Ulead Media Studio forums recently, it seems that it is high on the list of priorities to have something available for its users.. with Ulead recognising (but they are in a financially secure position, so it seems they have a more rounded outlook on these sorts of things) that its users demands have been listened to.

Audio, Video, and File Format sdks are available for Vegas. If you don't like the plug-in options that are available now, contact your favorite plug-in provider and ask them to consider porting to Vegas.

I'd just like to say that I would gladly pay extra for a Good Encoder.
As I've mentioned in previous posts, before long most of our output is going to finish up on a video disc of one format or another, rather than tape.
The company that delivers this will be the one that prospers: build a better mousetrap...
I'm not over impressed with any currently available encoder, although Tmpgenc does seem better than most. I'm sure SF is going to be the one to deliver the killer encoder, but in the meantime it might as well hedge its bets by letting Vegas users plug in their encoder of choice.

-Pete

The problem is that unless SF manage to add the kind of functionality that we are asking for, no one else is going to bother. Lets be quite honest about this, Sonic Foundry Vegas Video is *not* that popular. We all know that its an exceptional piece of software, but 90% of the general market haven't a clue what it is.. Its had one or two 10/10 reviews.. thats hardly going to set the world on fire when you almost everyone else is using either Avid Xpress DV, Ulead Media Studio or the more robust Adobe Premiere 6; the fact is that VV3 is right at the very bottom.. cult status almost. People are also concerned about investing in VV3 with regard to the fiancial problems SF are having.. SF might not be around in a years time, and if they are the development of VV3.5 or 4.0 might have to take a set back due to cuts..

Its not going to be that hard for them to write a wrapper.. I'm sure it would take no more than an afternoon to get something available as an addon-util that we use at our own risk and is not 'officially' supported by SF.

Companies like Abobe systems are also having a hard time making money since part of their income comes from putting their sofware with the hardware capture cards. My beef against Tmpgenc is that they did not make their program a standard codec plugin that would allow other editing programs to use it directly. I find that the quality that I am getting from Video Vegas better than the some of the other programs that I using even when using Tmpgenc for the final output.

We are currently shipping with the MC encoder, as you all know. This is a replacement for the L**os encoder, which we were not happy with. We have been running many tests with MC, refining different functions along with MC engineering. We believe we have made significant progress with the version included with the Vegas 3.0a release. I have personally burned a bunch of test DVDs from ultra-high quality source material (digital betacam masters of feature films, test patterns etc), we've been checking everything with scopes and production monitors, and just about everybody I have shown the output to has been pretty impressed (this includes members of this forum- our customers).

Some of you are apparently still unhappy with the encoder that shipped with 3.0a. We have an excellent relationship with MC and are in constant contact with their developers. If something needs changing/fixing, we can make that happen. If you can send me a sample of problem footage (sonicepm@sonicfoundry.com), and also a sample of footage that was done with what you think is a better encoder, we'll take a close look at both and adjust our encoder if needed.

Finally, if you believe you could personally code robust bug free frameserver capability for Vegas in "one afternoon", please send your resume, immediately, to the above email address.

I am afraid I have to disagree with you there.

Sonic Foundry is one of the few companies that reply directly to questions asked on their forum and takes customer requests into consideration.

I am behind their strategy to support one MPEG plugin fully and replace it if necessary, like they did (I switched from TMPGEnc, since Vegas 3.0a). I dread what is going to be the main topic of this forum when they release unsupported wrappers and plugins.

It is indeed surprising that such a high quality product does not have the recognition in the market, but looking at the latest reports (magazines in the UK) they are getting there.

It is a fact that good marketing and distribution can conquer the world (Microsoft) and I hold my breath if MGI would stay successfull. So yes, on the marketing side, things need to happen. But product and support wise I am very impressed.

Finally, if you believe you could personally code robust bug free frameserver capability for Vegas in "one afternoon", please send your resume, "immediately", to the above email address.
-sonicepm@sonicfoundry.com

LOL...ed

[SF] "I have personally burned a bunch of test DVDs from ultra-high quality source material (digital betacam masters of feature films, test patterns etc), we've been checking everything..."


-- Possibly you should attempt to use footage from (say) a DV camera (PAL) and then use the footage to create SVCD material. The codec simply "chokes" on interlaced footage generating a lot of blocks in numerous situations. This has been verified with a number of other VV3 users from the Europe region. The blocky-ness of the picture is sadly lacking when compared against TMPGEnc that gives outstanding results when frame-served from Adobe Premiere.

I also doubt very much that creating a frame-server would be as time consuming as you feel it to be.


[SF] "Finally, if you believe you could personally code robust bug free frameserver capability for Vegas in "one afternoon", please send your resume, immediately, to the above email address."


--- as the other poster said, if your looking for an email address then possibly start at Sonic Foundry.. there are surely tallented people there who are capable of creating a robust (or not so robust) wrapper? Have you actually tried writing to the guys at http://www.videotools.net/ .. Really, if your after doing any justice to VV3a you should at the very least attempt to make it more of a rounded product, eat some humble pie and work a little harder to do it justice. Its all very well having a wonderful editing interface, but if the final outcome is going to be second rate than we might as well stick with something else.. lets not get into the lack of comercial plug-ins (HollywoodFX, etc..) which is doing a fine job on Avid, Ulead MS and Premiere.

Are you or aren't you going to send SOFO your material so that they can see first hand how the MCplugin "chokes" on certain footage/settings? Will you send them a version done in TMPGEnc to show how its done? Settings as well.

This has been verified with a number of other VV3 users from the Europe region.-What difference would someone have from europe than from the U.S.A.?

Last but not least what type of projects are you working on. How many tracks of audio/types of audio [wav,aiff,pca,MP3,etc...]. Could any of this be a config problem other than plugin prob? I say this because a while ago somebody was complaining about the output rendering. From what I can remember it was the fact that he was using MP3 audio instead of .wav that was causing him grief. Not knocking you but the little things are what get any of us. Please add more info next time. Later.

Hello,

>What difference would someone have from europe than from the U.S.A.?

Maybe, PAL vs NTSC

Bye

> What difference would someone have from europe than from the U.S.A.?

Its much more of a PAL related issue than NTSC.. combined with being interlaced there seems to be much more of an issue regarding blocks in final renders.

> Will you send them a version done in TMPGEnc to show how its don...

Its quite pointless to send footage via email of the size we are talking, even a small clip would result in the email server aborting the transfer part way through. SF do not have any 'upload' system (via ftp) so calls of this nature are a little silly on SFs part [or not thought through properly]..

Its a simple fact that the MC codec is not up to the same standard as TMPGEnc, there can be *no* argument over this. Possibly go and do a little comparision of your own and i'm sure you will be able to see the differences immediately -- generate a clip and instead of watching it on the PC author a back-2-back clip (same clip) on SVCD and view the results on your TV; then single clips.. either way, computer or TV the results are the same.. blocks that take your attention away from the picture.

Mail NOT email. Burn a disk with a "before" and "after" using EACH technique and point out the flaws so that sofo and MC can make adjustments.It doesn't have to be that long. Just enough to get the point across [1 cd worth]. If you meant email then [sonicepm] can you be more specific?

Finally, if you believe you could personally code robust bug free frameserver capability for Vegas in "one afternoon", please send your resume, "immediately", to the above email address.


Hmmm..Why would this capability be held to a higher QA standard (Bug Free) than the rest of the product..Sorry..Couldn't resist..

Seriously..I would estimate that this is probably about a 1 man month task to do well and get integrated into a new release (assuming the standard release overhead stuff was covered by roll in of other bugs)..

Not a huge deal but not cheap either...

1) "SF do not have any 'upload' system (via ftp) so calls of this nature are a little silly on SFs part [or not thought through properly]"

Who at SF told you that there was no way to ftp files to an SF server? Did you actually ask anybody?

2)"Its a simple fact that the MC codec is not up to the same standard as TMPGEnc, there can be *no* argument over this. "

Can you please point to some scientific test that backs up the statement above?

I can see why SF would want to improve the MC plug-in rather than work on a frame-server plug-in.

one of us will have to use the sdk to write a freeware frame-server plug-in. it can't be that hard right? how do we get the sdk?

Hey guys! I have to agree with Lody. Hey Lody! How ya' doing?

Anyway, after being abused by MGI, it is refreshing to own a product (VV 3.0a) and have it work so well. No home NLE will be perfect, but VV 3.0a sure comes damn close! I see reps from Sonic Foundry in here really helping people and asking for suggestions to improve their products. They actually acknowledge their customers and give explanations for things.

And I really do believe them about it taking more than an afternoon to create a "bug free" wrapper or plug-in or whatever. That's what's wrong with some other companies. They quickly throw something together without properly testing it. Proper testing takes time.

I really feel that the folks at SF care about their customers and the products they make. How else can I explain the great reliability and superb functionailty of VV? I think if you all really want to see an improvement in VV's encoder, be specific and provide examples. I think the people at SF will listen, review the information and take appropriate action if necessary. I have no other reason not to believe that.

For my needs, their encoder is just as good, if not better, than TMPGEnc... but I live in the states and don't use PAL.

Just my 2 cents.

> Who at SF told you that there was no way to ftp files to an SF server? Did you actually ask anybody?

I have had an experience in the past regarding a problem that should have required me to send over a CLIP over.. but SF declined the offer to correct as they had no way of accepting uploaded files.

>"Its a simple fact that the MC codec is not up to the same standard as TMPGEnc, there can be *no* argument over this. "

> Can you please point to some scientific test that backs up the statement above?

Yes, fortunately I can, but as with most things I am losing a little interest myself now and really doubt that I can be bothered singing the same old chant any more. I have been moving back to Premiere 6 (grrh!) as VV3 will not generate decent SVCD material. I explained in an earlier post that all SF need to do is put the "extreme high quality footage" down for a moment [will they ever listen], get out in the real world with a *PAL* DV Cam [that interlaces footage in its record] and then firewire it to a PC and do some comparisions of their own.. they'd soon see that the MC codec is entirely pathetic in *all* renders. I have been performing a number of renders over the past few days from the Ligos 1.5 codec (Premiere + Stand alone) TMPGEnc (Premiere + Stand alone) CCE ( Evaluation release 2.64 Prem + Stand alone) and MC in VV3a.. the results are there for all to see and for SF to view should they wish to get off their backsides for a moment and look at a problem that is *issing a lot of people off.

Look, lets close the book on this now. SF can't be bothered, its really that simple. Its all very well having a "SonicEPM" guy responding to messages and making us all feel like "SF really care.." but the reality is that he's just another "yes man" .. whose here to listen but do nothing. I just hope that Premiere 7.0 comes out sooner rather than later. Why the hell did SF have to create a wonderful editing interface that just makes me want to cry when I have to use anything else :>

Following the kicking and gouging - er, debate - that's going on here, I went out yesterday to test my Sony TRV900E (that's PAL of course). I took some shots at a harbour near where I live with the camera mounted on a proper video tripod with fluid head. Conditions were very bright Spring sunshine. Many of the shots included rippling water, a difficult subject to encode.

I put a number of representative shots on the timeline and rendered a couple of MPEGs from VV; one was SVCD the other DVD. I used the standard settings.

I then exported the timeline as an AVI and used Tmpgenc to do the same thing. Again, I used the standard settings. The first thing I was bemused to find, because I hadn't expected it, was that Tmpgenc took approximately *half* the time of the VV encoder! I thought it would take longer.

I burnt a SVCD and DVD containing the appropriate output from each encoder. I viewed them on the computer (using Power DVD) and on a Sony 100Hz widescreen TV, via a Pioneer 545 DVD player.

The VV output wasn't bad, especially if the shot wasn't panned, but against the Tmpgenc output it was decidedly in second place. Decidedly. Contrast was better, sharpness was maintained and, where the shot was panned, flickering and blockiness kept to an absolute minimum. In contrast, the VV output looked blotchy and dull. It was a bit like the difference between VHS and S-VHS.

Since Tmpgenc is the work of one man and not some corporation, I would have thought there was plenty of scope for SF to sort some sort of royalty deal with him. After all, even if Tmpgenc were not the best, it's still *perceived* to be, and in marketing that's what counts. I'd have thought it was a good way of increasing sales; most buyers would gladly pay the extra for this feature.

-Pete

PS If SF would like copies of this footage and renders, I'd be glad to send them.

"Can you please point to some scientific test that backs up the statement above? "

Not a Scientific Test with the full majesty those words imply, but see my note above.
Would you like copies of the results?

-Pete