Yesterday I had a most successful translation of Pal Video to NTSC. I've had some success before, but this was by far the best. I've been testing and refining for some time.

First of all know that I use DVCII to encode, and Procoder to reencode. I have a VCR that reads Pal and NTSC, but its Pal to NTSC is only fit for the TV screen. I therefore need to record in Pal and do my translation on the computer.

I've had to contend with synch issues, but I'd also been having some problems reencoding from 25 frames to 29.97 without a shimmer, or ghosting.

The shimmer tended to be a result with TMPGEnc, and minor ghosting is an issue with Procoder. Synch issues tended to result in certain mux-demux scenarios, or when reencoded with audio muxed.

I'll go directly to the formula that is working well for me:

I encode at 9MB per sec MPEG2. I had gone as high as 10MB, but backed off of that because I feared that totally throttled up I might be dropping some frames.

I also encode with CBR only for the initial encode and the reencode. It has been my experience with encoding and then reencoding that CBR reduces the possibility of synch issues. That too is empirical, but I have been more successful with it.

Next, I use DVCII's facility to encode audio as a separate file. This complicates the process because I must be very careful to start and stop the encode at the right points since separately trimming the video and sound to the right lengths is a challenge for me...perhaps others know of a good strategy for this. In any case, additional editing of separate sound and video is a step best avoided both for the trouble and the possible synch issue it can introduce.

I take the video file and then input into Procoder. I use highest (not mastering) setting on procoder and use an elementary stream as a target. You do not want to create an empty sound file muxed in with your reencoded video.

The video I did yestderday was particularly difficult because it was 153 minutes long. The length means it will be more susceptible to synch issues, and it also means I must reencode at a low bit rate if I want to squeeze the whole thing onto a single DVDR...and I did.

I set Procoder to create an elementary video stream at 3.6MB CBR. Now, even though I'm only trying to create a video file, it creates a separate but empty audio file. I don't know how to get procoder not to bother. I'm also not certain that it isn't compensating for the audio and actually encoding the video at 3400. That seemed to be what bitrate viewer was showing me, it probably is, but I'm uncertain. However, because the original file was encoded at 9MB, it had a lot of material to work with.

It took Procoder 5.5 hours to do the 2.5 hour video, and it was SWEET! I absolutely cannot tell the difference on my TV from the original video. Mind you, there are only a few action scenes in the production, but they looked very good. Any ghosting was so minor enough that it didn't draw attention to itself. I rather wonder if the high original bitrate doesn't give Procoder more to interpolate with, and therefore provides a superior result at a lower bit rate reencode.

I used Spruce Up to author and generated a title set, and then used the latest Nero to burn. I burn on TDKR47A's.

In testing the resulting DVDR for synch issues I zipped through all 15 chapters and found nothing...it was good to the last drop. I even tried FF to try and confuse the DVD player, but it all held its synch to the last.

I think the combination of encoding to a separate file at high video bitrate, and reencoding video only at a lower bitrate and strictly using CBR are the primary keys to success here. It also helps to have good reflexes in starting and stopping your production so that no trimming is required.

It is certainly possible to do the original encode muxed and then demux before encoding the video with success, so if you need to trim I'm confident it can be done, but if you're handy with timed mouseclicking you can eliminate the step. I think a high initial bitrate, and using CBR throughout are the most important steps.

It works, and it works well.

cheers,
mark

My wife says this forum is a bad influence on me. I'm not supposed to play here anymore....<yeah right..>

So much on my plate I can't imagine throwing PAL-NTSC in there too. I vowed to never buy another convertor when mine dies? Thaks to you Mark for smoothing the edges to getting started with Procoder so....

Curiosity will definitely kill the tech-head!

Mark... So the only thing you have done different is create a source file with a high bitrate ?

I have ran procoder with a DV avi file (PAL) and output to a DV avi file (NTSC) and have so far always recieved noticeable ghosting on the output. I have tried it to MPEG2 also withthe same results.

Theres another program called aDVanced DV PAL/NTSC Converter which (to me) looks slightly better than procoders results, but still not 100%.

It makes one wonder how badly those cheaper converter boxes must work when a good piece of software (which doesnt need to be done in realitime) struggles with the same operation.

Apart from the high bitrate, I encoded the audio separately...demuxing should have the same effect of course, and I used CBR exclusively, which I think helps eliminate the possability of audio synch, and may indirectly help with ghosting for all I know.

I'm tempted to try this on a Dr Who movie clip, since that has some extreme motion in it...however "As you Like It", which I encoded the other day has some very fast panning in it, and it looked quite effortless even at the low bitrate it was reencoded at. I was thouroughly impressed by that.

In going through the 2.5 hour production I found at least one instance where the production skipped several frames....it just skipped...brief, but noticeably. Audio stays in perfect synch, but it seems to be a rare but re-occurring flaw in the frame interpolation scheme. That's a guess if you like, but I think a canny one. Nevertheless, the production looks flawless otherwise, and in moving from 25 to 29.97 frames it may be unavoidable unless I change settings to "always interpolate"...which I'm loathe to do, but will probably try out. I've not even attempted to work with the gop size, and theoretically that should help high motion.

There is SO much testing that can be done on something like this.

cheers,
mark

Just in case you didn't know it Mark, the bitrateviewer reports Kbit/s where K=1024. So if bitrateviewer tells you an average bitrate of 3400 Kbit/s that would be equal with 3482 kbit/s in TMPGEnc and CCE. Probably also in Procoder. Well it still is below 3600...

It's generally best to encode the source as little as possible when you are capturing. I have also got hold of a copy of Provoder now and my first encoding should be ready by now. I captured Terminator 2 from an old VHS tape (as huffyyuv AVI with some filtering) and encode it as 2-pass VBR 2200 kbit average and 352x576 pixels DVD-resolution. I plan to use half of the DVD-R space to be able to fit another movie. The movie is 131 minutes long. I used mastering quality and frameserved via avisynth and Link2 to Procoder. Do you get better quality with High quality compared with mastering quality? Anyway the encoding took 15 hours and 30 minutes totally (2-pass). Not too bad I think! I beleive TMPGEnc is slower in highest quality.

Ronny

I have been doing some testing and found the following.
DVD to VCD
I get a non compliant message in nero but continue and the VCD looks great. I did get some temporary freezes on the player after 10 minutes may need to reduce cdr burn speed.
SVCD to AVI and then AVI to DVD
SVCD to DVD
Can not tell the difference in Quality between the two but it is an easy way to get your SVCDs converted and burnt to DVD-Rs.

Slideshow with music created in Premiere 6 and exported to Procoder
Works fine no field order Problem. One curious thing a blemish in audio for less than a second at 23 seconds into the show went away when I rerendered the target. I am looking forward to Ronny's input as well as the rest of the gang. The idea of using DVD as a base Title Set with the best resolution and creating SVCDs or VCDs on cheap CDROMs looks sweet.

CaptKrunch

Go to Highest Quality Ronny unless you're archiving for duplication. I cannot tell the diff, and HQ is so much faster. The manual recommends NOT using Mastering except in rare instances of archiving for later duplication or an extremely complex job.

Highest makes a sweet encode and much faster. TMPGEnc can't compare, although I agree that at this point TMPGEnc has some flexiblility that Procoder lacks at 1.0.

Cap'n, Procoder does indeed make sweet MPEG1 VCD from MPEG2, and my results have been completely compliant. You shouldn't be getting a complaint from Nero.

cheers,
mark