DVD Rebuilder: No PAL to NTSC option? Why?

[evansataz]

Avisynth can do soooooo many things. Maybe you should look into what i have posted before being quick to judge. Ive done 3 pal to ntsc conversions. Tested on a player that a patch only method never worked. Everything was kept and also played in my uncle's DVD player that wouldnt play anything but ntsc dvd's. DVD Rebuilder uses an Encoder and Avisynth should tell anyone that knows anything about this topic, that you can use DVD Rebuilder to re encode the movie and menu to whatever specs you want. I am obviously doing something you havent tried or took the time to check. It works for me and that is all that matters to me from this point on since this isnt a discussion and just a judge and jury.


Below is the before and after info. I used Mediainfo to get the specs of the video files.

Video
Format : MPEG Video
Format version : Version 2
Format profile : Main@Main
Format settings, BVOP : Yes
Format settings, Matrix : Default
Format_Settings_GOP : M=2, N=20
Duration : 8mn 53s
Bit rate mode : Variable
Bit rate : 5 748 Kbps
Nominal bit rate : 8 938 Kbps
Width : 720 pixels
Height : 576 pixels
Display aspect ratio : 4:3
Frame rate : 25.000 fps
Standard : PAL
Resolution : 8 bits
Colorimetry : 4:2:0
Scan type : Progressive
Scan order : Top Field First
Bits/(Pixel*Frame) : 0.554
Stream size : 366 MiB (96%)

The above was taken after DVD rebuilder did the encoding. It showed to still have pal specs for header but playback of the video clearly shows it has been deinterlaced, resized and changed fps. The video looked cropped from bottom since the original video was 720x576 and the new video was encoded to 720x480. Found the playback was like that due to the header still in pal format so all that was left was to patch and playback was PERFECT.


AFTER DVD Rebuilder and DVD Patcher

Video
Format : MPEG Video
Format version : Version 2
Format profile : Main@Main
Format settings, BVOP : Yes
Format settings, Matrix : Default
Format_Settings_GOP : M=2, N=20
Duration : 8mn 53s
Bit rate mode : Variable
Bit rate : 5 751 Kbps
Nominal bit rate : 8 000 Kbps
Width : 720 pixels
Height : 480 pixels
Display aspect ratio : 4:3
Frame rate : 29.970 fps
Standard : NTSC
Resolution : 8 bits
Colorimetry : 4:2:0
Scan type : Progressive
Scan order : Top Field First
Bits/(Pixel*Frame) : 0.555
Stream size : 366 MiB (96%)

Rebuilt DVD and used IfoEdit and pgcedit to complete my conversion.


I didn't run into any audio sync or subtitles issue. The only thing left was the menu buttons and pgcedit took care of that.

Works for me so you can do however you want that works for you.

[manono]

Then you shouldn't object to uploading short samples of the video and menus to show anyone interested. Open a video VOB and a menu VOB in DGIndex, use the [ and ] buttons to isolate small sections and File->Save Project and Demux Video. Upload the resulting M2Vs either here or to some third party file sharing site, ones such as MediaFire or Sendspace and provide the links. Or are you afraid people will discover the emperor has no clothes?

[usually_quiet]

I'm just beginning to learn avisynth scripting, so I'd be interested in seeing a list of the AVS-related menu options selected in DVD Rebuilder and the avisynth script entered in DVD Rebuilder's AVS Filter Editor.

[Noahtuck]

Or are you afraid people will discover the emperor has no clothes?

LMAO!!!!

The emperor has clothes, he is just in a hospital gown hooked up to machines because he is brain dead and needs a machine to breathe for him!!





Did i tell you about how i broke the speed of light last week on my skateboard ??
And as soon as i did, monkeys flew out of my butt!!!!!

LOL!!!

[AlanHK]

Avisynth can do soooooo many things.
....
The above was taken after DVD rebuilder did the encoding. It showed to still have pal specs for header but playback of the video clearly shows it has been deinterlaced, resized and changed fps.

This seems odd to me.

If you had reencoded via Avisynth, that would have generated a completely new MPEG file, so the MPEG headers would be correct and not needed to be patched. Also encoding a feature length video to MPEG normally takes a few hours, at least on my system.

[r0lZ]

I don't understand why you are so rude with evansataz, guys.

You are probably right when you assume that his method is not perfect. In particular, I don't think it is possible to apply the pulldown from within DVDRB, as that would change the duration of the video segments, and therefore that would require also to stretch the audio, and to inform DVDRB that the duration of the segments has changed. I don't know either if DVDRB can resize the subpic bitmaps.

But it is right that it is possible to do (almost) everything needed with avisynth, and that DVDRB uses anisynth anyway. (AlanHK, DVDRB re-encodes the files anyway. It's why it is much slower than a transcoder like DVDShrink.) It is also possible to insert your own script to force it to do other conversions than the standard ones it assumes normally. I have used that feature, for example, to remove logos. (Something much more easy that converting to another video standard, I agree!)

The output files produced by DVDRB need to be patched probably because when DVDRB rebuilds the DVD, it thinks that it is still a PAL DVD, and it creates the IFOs and VOB nav packs accordingly, even if the resolution of the video files modified by avisynth is now NTSC. (BTW, it should be possible to force it to consider the files as NTSC directly by editing its configuration files before launching the third DVDRB phase. An external script or program could do that relatively easily.)

Like you, I am suspicious, and I think that if converting from PAL to NTSC is so easy, someone else would have found a similar method since ages. But that doesn't mean that his method is not interesting at all. He might be close to a good solution, and perhaps it is only necessary to fix a few things (with a new little program, still to be written) to obtain a perfect conversion. So, imo, instead of assuming that he must be totally wrong, it is more interesting to try to understand how he did his conversion, and to help him improve it. Someone that searches a solution to a problem cannot be blamed.

Personally, I would like to see the avisynth script he has inserted in DVDRB. With that information, we will be able to understand what is still missing, and perhaps, find a way to improve it. I know that converting a DVD is not easy, especially when it has menu buttons, but why not try?

[jagabo]

I don't think it is possible to apply the pulldown from within DVDRB, as that would change the duration of the video segments

The whole point of using pulldown, hard or soft, is to avoid changing the running time. Some programs get confused by unusual soft pulldown patterns though.

[r0lZ]

Hum, I'm not a specialist of pulldown methods, but PAL runs at 25fps, and NTSC at 29.97 or something like that (and film at 24 fps). Right? So, when converting from PAL to NTSC, there should be a difference in time. Since if the pulldown adds 1 frame (or field) every 5, it should run at exactly 30 fps, but it's not the case. I agree that the difference is subtle, but it exists, and the IFO files must be modified accordingly.

But the NTSC standard is very complex, and maybe it uses drop frames to run at 29.97 instead of 30 fps. Honestly, I have never tried to understand that mess! IMO, NTSC is a standard of the stone age, and it should be abandoned as soon as possible!

[jagabo]

Hum, I'm not a specialist of pulldown methods, but PAL runs at 25fps, and NTSC at 29.97 or something like that (and film at 24 fps). Right? So, when converting from PAL to NTSC, there should be a difference in time. Since if the pulldown adds 1 frame (or field) every 5, it should run at exactly 30 fps, but it's not the case. I agree that the difference is subtle, but it exists, and the IFO files must be modified accordingly.

Pulldown can create exactly 59.94 fields per second (what NTSC video really is) from any progressive frame rate between 19.98 fps to 29.97 fps. DgPulldown can add pulldown flags to do this. With 25 fps frames you use 3:2:3:2:2 pulldown flags (which would give you exactly 60 fields per second, ie every 5 frames becomes 12 fields) except every ~208th frame (I think, I'm too lazy to do the math now) you substitute a 2 for one of the 3s to bring the final rate down to 59.94.

[r0lZ]

OK, you convinced me. But that means that it should be possible to convert the PAL VOBs to NTSC more easily than I thought, since there is no need to recompute the durations and to patch the original ones. Good news.

So, IMO, if it is true that DVDRB can, with the help of an avisynth script, convert the video to the correct image size and apply the right pulldown to convert also the frame rate, the remaining difficulties are probably relatively easy to overcome. After all, it is possible to move the subpics with DVDSubEdit, and to change the button positions with PgcEdit. There is still a problem with the resize of the buttons highlights, but it should be possible to do it.

Maybe I've forgiven something, but that seems doable.

[manono]

So, IMO, if it is true that DVDRB can, with the help of an avisynth script, convert the video to the correct image size and apply the right pulldown to convert also the frame rate, the remaining difficulties are probably relatively easy to overcome.

That's the point. It can't do all those things and trying to force DVD-RB into doing the parts it can do needlessly complicates things. It's much easier to do the reencoding yourself and leave DVD-RB completely out of the equation. I suspect evansataz is using DVD-RB bacause he can't do it manually. DVD-RB can't apply any kind of pulldown other than what flagging there was originally. If starting with a PAL DVD, no matter how you resize it or deinterlace it or do whatever else you do in DVD-RB, you'll get a resulting video with no pulldown. Hence the need for the useless and pointless DVD Patcher to add a header saying it's really 29.97fps, when it's really not. If done right (i.e., outside of DVD-RB), you'd apply pulldown yourself (or, if 3:2 pulldown after slowing the video to 23.976fps in the script, perhaps in the encoder). Trying to use DVD-RB for the job is like trying to fit a square peg into a round hole. Again, it's impossible to convert the framerate within DVD-RB, and since he says everything's in synch, he's leaving it at 25fps.

After all, it is possible to move the subpics with DVDSubEdit,

Which he hasn't done. And they're still 720x576.

Maybe I've forgiven something, but that seems doable.

I don't doubt that he has something that will play on his DVD player. It's just that he's used a modified version of the Patch trick. This isn't an NTSC DVD.

[r0lZ]

I'm still not convinced. I don't speak of the subpics and buttons, that are another problem. But for the video itself, it is possible to include an avisynth script in the DVDRB process. That script can (probably?) do anything that avisynth can do, including the pulldown. The advantage of using DVDRB is that it analyses the DVD structure during the first phase and it saves its config files. It's also during that first phase that it demuxes the cells. Then it re-encodes the video during the second phase. It's during that phase that you can apply your own avisynth script, and therefore convert the PAL format to NTSC. Finally, during the third phase, it rebuilds the same structure than in the original DVD. The problem is therefore with that "same" in the third phase.

I know that DVDRB saves the setup files in text format in a temp dir, and that it has a "3 clicks mode" to allow the user to modify them after each phase. So, it is normally possible to modify the files describing the structure of the original DVD before the last phase, so that it will rebuild a NTSC DVD directly. And we should not need DVD Patcher any more!

It will still be necessary to modify the subpics and fix the button positions, but that's another story. The key is that DVDRB can probably be used to avoid to have to rebuild the whole DVD structure manually, and that's probably a good point. It will probably be necessary to write a little program to patch the DVDRB config files before phase 3, just to avoid to have to do it manually, but that should be easy to do.

There might be some difficulties that I haven't taken into account, but I think that theoretically, that method should work. Please note that since I have never tried to do it, I can't be sure. I haven't said either that evansataz did it the right way, nor that it is possible to do the conversion with DVDRB only, but I continue to think that trying to do it with DVDRB as the basis is not a bad idea, unless there is really something that prevents totally that method to work. Currently, I don't think so. If I'm wrong, please tell me exactly why.

[manono]

Personally, except where it's necessary to reencode and rebuild DVDs with angles by cells, I don't believe cell-based encoding is nearly as good as encoding the whole thing in one crack. Almost no movies on retail DVD (except, perhaps, those with angles or interleaved cells) use cell-based encoding. If doing it via DVD-RB it means editing each AviSynth file. 30 cells? 30 edits, plus those for the kept extras. Do it yourself, only one script, except for those for any extras. Again, it's not possible to apply pulldown via DVD-RB, nor did evansataz claim he did so. He also says he deinterlaced which, as we all know, shouldn't be necessary for movies. And even if converting real interlaced footage, many believe it should be kept interlaced. In additon, I'm 99% sure that he used FieldDeinterlace for the deinterlacing (junk in this age of good AviSynth deinterlacers), and 75% sure that his main feature didn't need and shouldn't have been deinterlaced.

But for the video itself, it is possible to include an avisynth script in the DVDRB process.

What's the point? You need only a basic scripting knowledge to do it yourself.]

That script can (probably?) do anything that avisynth can do, including the pulldown.

Unless you're planning on hard telecining it (not a good idea), then AviSynth can't do it. Applying pulldown is a separate operation done with such apps as DGPulldown, or by Pulldown.exe or within the encoder if 3:2 pulldown (which this wouldn't be).

So, it is normally possible to modify the files describing the structure of the original DVD before the last phase, so that it will rebuild a NTSC DVD directly. And we should not need DVD Patcher any more!

Yeah, but that's not how he's claiming to have done it. And, not having tried that myself, I don't know if (and don't think) it can be done, not when you're starting with a PAL DVD, wanting to magically turn it into an NTSC DVD by the end. I don't know the internal workings of DVD-RB, but jdobbs has always claimed that in no way, shape, or form, can the framerate be changed. And I don't consider using DVD-Patcher on it as having changed anything. Even evansataz himself didn't actually change the framerate, but only patched it to fake it.

Maybe, just maybe, after you're all done with DVD-RB, you could take the whole thing apart again and go back to do such things as apply pulldown, resize the subpic BMPs, fix the buttons, and whatever else he didn't do. I agree that having a faked NTSC DVD to start with makes it easier to do a proper job by then making a real NTSC DVD. But he's using DVD-RB Pro, a commercial program, and the only version that will reencode menus. The Holy Grail, so to speak, is to use all freeware programs.

Nor has he deigned to show us samples of either his reencoded videos or his menus, or even any of his scripts. This is the work of someone that bit off more than he can chew.

[jagabo]

That script can (probably?) do anything that avisynth can do, including the pulldown.

Unless you're planning on hard telecining it (not a good idea), then AviSynth can't do it. Applying pulldown is a separate operation done with such apps as DGPulldown, or by Pulldown.exe or within the encoder if 3:2 pulldown (which this wouldn't be).

Just to clarify, pulldown flags are part of the MPEG stream. They are instructions that tell the DVD player how to produce 59.94 fields per second analog video from the progressive MPEG frames. AviSynth simply hands uncompressed video frames to the MPEG encoder. It's the MPEG encoder's or DgPulldown's (possibly some other program's) job to add pulldown flags.

It's possible to perform a hard pulldown in AviSynth and hand the MPEG encoder interlaced frames. But this would result in less efficient encoding and less sharp colors.

[r0lZ]

You convinced me. I didn't know that AviSynth is unable to do real pulldown. And I think also that using the pro version is not a good philosophy. Pity, that would have been great!

Anyway, I said that I don't want to participate at this discussion.

[ron spencer]

You convinced me. I didn't know that AviSynth is unable to do real pulldown. And I think also that using the pro version is not a good philosophy. Pity, that would have been great!

Anyway, I said that I don't want to participate at this discussion.

what do you mean not a good philosophy?

[r0lZ]

I prefer the solutions entirely based on freeware.

[Gavino]

I didn't know that AviSynth is unable to do real pulldown.

The reason is that Avisynth is not an encoder.
As a frame server, it just delivers uncompressed video and audio to its client.

[r0lZ]

Yes, but you can combine fields together. I thought it's the basis of pulldown. But as I said previously, I don't know pulldown well, as I don't need to convert from PAL or film to NTSC. Luckily, I live in PAL land.

[Gavino]

Yes, but you can combine fields together. I thought it's the basis of pulldown.

That's what's known as 'hard' pulldown.
See jagabo's post #44 above.

[Noahtuck]

Anyway, I said that I don't want to participate at this discussion.

That's funny!!!
Seeing as that's the 2nd time you have stated it yet here you are, more than anyone else!!!

LOL!!!

I may not be as specific or as detailed as some others here, but i still make the same point!!
LOL!!!

This dude is totally clueless!!!!!!

[evansataz]

Hello all,
I had some family issues i had to attend to and was gone for awhile but now i am back and started working on this PAL to NTSC project again. I am not doing this for myself because my dvd player will play PAL and NTSC. I am doing this for my friends and family that don't have a dvd player that will play both regions. A couple of people on this thread, though rude and pompous, they were correct to say it wasnt a compliant ntsc with the method i was using. I have decided to start over and try a different approach. I am still using DVDRebuilder as the main program and instead of using avs scripting, i am manually editing a few files that DVDRebuilder creates during the prepare phase. looks like with this method it is much easier and take way less time. I am however faced with the same problem with the menu buttons/highlights and cant get pgcedit to fix them correctly. i am currently in middle of a DVD9 PAL conversion and will keep you posted on my progress.

Pgcedit relocates the buttons but then i am left with buttons i can no longer see or highlight.
Is there another way to relocate these buttons/Highlights?

Hope there can be more help on this topic and less criticism on the attempts. I need some help on fixing the menu buttons/highlights.

[r0lZ]

Is there another way to relocate these buttons/Highlights?

Yes: manually!

Are you sure the subpics are correctly resized?
And import the color schemes separately. They are not included with the button definitions, so if all colors are transparent, it is normal to not see the button highlights.

[evansataz]

So far with the new method, everything seems to be NTSC compliant and the subtitles show at bottom of video as normal. The only thing i have an issue with is the menu. The hot spots are fine but the highlights are offset (below the hot spot). I could leave it this way and it works fine, but i want it to be perfect so it looks just like original PAL DVD. I have tried a few different programs to fix menu but haven't had success. PgcEdit will allow me to adjust the hot spots but i see no feature on any program that will allow me to adjust the highlights when a hot spot is selected. If anyone can help me to find a program that allows me to adjust highlights instead of hot spots, i think i can finally put together a tutorial that can help others in PAL to NTSC conversions.

[manono]

The hot spots are fine but the highlights are offset (below the hot spot).

As he asked before:

Are you sure the subpics are correctly resized?

[evansataz]

Thought subpics meant subtitles, and i stated that the subtitles show fine. If the highlights are subpics, then no I'm not sure they are resized and not sure how to resize them or i wouldn't have this issue. Thought i was pretty clear on the issue i have, and if its subpic resizing that needs to be done, how bout some help with how to do that.

[r0lZ]

The menu highlights are subpics, just like the regular subtitles, yes. But I guess that, for the subtitles, you don't need to resize them. It is (most often) sufficient to move them up. You can't do that with the button highlights.

IMO, you should try to extract all menu subpics as BMPs with a tool like subrip, then batch-resize them (for example with ImageMagick) and finally rebuild them with Subtitle Creator, and remux the menus. (Ideally, the subpic resize should be made automatically by a little program or script between part 2 and 3 of the DVDRB process, to avoid to have to remux manually.)

Take care. The subpics are 4 colors images. When you resize them, you might have to use a resize filter that doesn't create additional colors due to antialiasing. You can probably use the most basic resize algorithm (often called "pixel resize"), but the effect will probably be somewhat ugly.

DVDSubEdit can also be used to export and re-import the subpic images, directly from toe VOBs, but it is not possible to automate the task. However, it can import antialiased BMPs. It assigns the new colors to the nearest subpic color automatically.

If your method works well, it is perhaps possible to ask Jeanl to modify DVDSubEdit to add an automatic resize. (I can't be sure however, as Jeanl doesn't work much in the DVD scene any more.) In the past, I have also written a little AutoHotkey script to automate some things with DVDSubEdit. Perhaps it will be possible to adapt it to do the resize automatically. But first things first. Can you upload a short test DVD somewhere so that we can analyse it and see if it is really in true NTSC?

[manono]

But I guess that, for the subtitles, you don't need to resize them. It is (most often) sufficient to move them up.

For it to be done properly they should be resized. Sure, you can move them up and then forget about it, but they'll be 20% larger than they would be had they been resized for NTSC (which I think you know). I think the aspect ratio will also be slightly off, but maybe not noticeably so. Admittedly, it's easier not to have to resize them. I've done it both ways.

[r0lZ]

Yes, the aspect ratio might be a little problem, but resizing the 4 colors subpics is also a problem, due to the lack of real antialiasing. However, I've added "(most often)" in my sentence because there are some cases where simply moving the subpics is not sufficient. You might have subtitles at the top, and of course you can't move them up. Also, subtitles for the earing impaired are sometimes placed at a specific position in the image to show clearly who is speaking. Moving them around is not recommended. And, of course, you cannot just move the subpics used for the button and BOVs highlights. So, we really need a solution to automate the subpic resize. BTW, manono, what was your solution?

[manono]

My solution for what? The resizing? I extracted the menu subpics using SubRip before batch resizing them all in Photofiltre. I made little SST files for them all and recreated the individual menus using Muxman. I got them back into the DVD using VobBlanker's 'Replace' button.