PDA

View Full Version : PAL to NTSC Conversion: Combing in Credits


czerro
6th July 2008, 23:17
I have an odd problem. I have a PAL DVD that I want to convert to NTSC. The entire movie is 25fps Progressive, which includes the credits at the end of the movie. Using TIVTC I simply decimated to 24fps (NTSC film). When looking through the footage I noticed the credit phenomena (combing in every frame of credits). Double checking the original 25fps Progressive PAL source reveals the same combing. Next step was to check DGIndex and make sure there were no framerate changes at the credit portion of the film. DGIndex continues to report 25fps PAL Progressive. I'm really confused. It seems like whoever authored the PAL DVD, somehow rendered all the fields in the credits as frames. Additionally, since field matching and bobbing does not result in a correct image either, it seems like the credits were converted from an odd (non NTSC standard) interlaced framerate. The fields were then separated and rendered as frames and then the framerate was converted to PAL.

I don't know if I have done a good job of describing this situation or not, but if anyone has converted PAL to NTSC and come across this anomoly and can suggest a workaround that will at least decently repair the source please let me know.

jeffy
6th July 2008, 23:24
Have you checked in an AviSynth script that you are not dealing with field blended credits, i.e. can you see the blends?

DGDecode_MPEG2Source("video.d2v")
separatefields()


Their framerate might have originally been 23.976 fps.
The possible solution might be:
tdeint(mode=1)
mrestore()

http://forum.doom9.org/showthread.php?t=95924

Atak_Snajpera
6th July 2008, 23:26
Use assumefps(23.976) and adjust audio tempo in order to maintain synchronization

czerro
7th July 2008, 01:14
Have you checked in an AviSynth script that you are not dealing with field blended credits, i.e. can you see the blends?

DGDecode_MPEG2Source("video.d2v")
separatefields()


Their framerate might have originally been 23.976 fps.
The possible solution might be:
tdeint(mode=1)
mrestore()

http://forum.doom9.org/showthread.php?t=95924

AH, you are correct. I don't really understand though. SeparateFields(), cleans up the image a bit resulting in a pretty consistent 1 in 4 fields rendered as a complete non-interlaced image. The remaining 3 fields contain significant ghosting and slight combing in ghosted areas. I might be misinterpreting the function of SeparateFields(), but it seems like the logical result would be interlaced images without the ghosting observed in the source.

The mrestore() function does a good job as well, though not noticeabley more so than separatefields(). I will play around with this function some more.

czerro
8th July 2008, 07:16
mrestore() did the job. After experimenting with all the parameters, I managed to have a pretty good result with most of the images being fully (or appearing to be) fully recovered with maybe 10 percent of the frames containing some ghosting below the text.

I am curious though, is it impossible in most cases to remove the ghosting and combing completely? I understand that the true source isn't being recovered but interpolated and most ghosting is removed through masking and tweaking of blend vs nonblend sensitivity? Which is fine with me, as I don't really care about frame integrity, more than I care about frame clarity, BUT, can someone explain some of the causes behind these abnormalities? I think I kind of have a grasp. Progressive frames contain identical fields, if you insert an interlaced source (credits in this case) to a Progressive source, and flag them as progressive for compatability AND decimate them to reduce them to 25 fps(is this something they really do with NTSC content in non NTSC regions?!) then you get blended fields that more than likely don't match?

Another thing. IF the source is NTSC interlaced shouldn't I have observed a similar result as when observing an NTSC interlaced stream after performing SeparateFields()? Instead I get a consistent '1000' instead of the usual '10100'. Well, I guess when I put it that way, the two full frames in five will be the most alike according to a decimation algorithm to reduce NTSC to 25fps PAL.

This is just mind boggling. The credits are unreadable through PowerDVD or WinDVD. This is a store bought DVD, a consumer level professional produced product purchased in the UK. DVD source is UK but obviously credits were created digitally for NTSC interlaced format. Yet no effort was made to conform them to PAL standard? Are PAL region DVD producers really this halfassed about their releases?

Because the source is very minimalist, it seems like an ideal source for tweaking these restore functions (mrestore, restore24). If anyone would care for a minimalist stream to test restore functionality/tweaking let me know.

Comatose
8th July 2008, 16:22
I'd like a sample please :p