rOLZ, a little guidance...

[kikatu]

Dear rOLZ:

Hi, while trying to figure out some commands of a DVD and delete useless commands... will need a little help if possible, here are two pictures:

http://img513.imageshack.us/img513/5236/dmrmel3.pnghttp://img180.imageshack.us/img180/791/partamkb1.png

1) Is part of the motion Root Menu, the goal here is to knockout the NOP which can cause problems & an understanding of how does the rules of SET GPRM* & IF GPRM* go around, if there is an order placing these commands. (don’t want to break it)

2) Part of the Audio Menu, the same goes here, useless commands will be gone, but what does the LinkTopCell will do in this case.


Since PGCEdit can sometimes detect abnormal time duration and automatically change the frame rate from 25 to 30 if needed in a NTSC project, it would be a time saver if we can change the frame rate manually (in the IFOs) to our desires. E.g. a PAL to NTSC project which the conversion is finished and the original menu was saved with PGCEdit, then imported but obviously the frame+ information is wrong, locally PGCEdit can automatically detect time differences and fix it, but not always can do that.

Also would PGCEdit have a feature to add titles to a domain whether of not it already has titles? I have done this in two occasions in conjunction with IFOEdit & PGCEdit, but again it consumes a little bit of time. (learning the code as they come)

By the way I love this editor, VOB-Blanker has let me down a couple of times, so I spend the time editing the commands with your application. But not disrespect to VOB-Blanker Author(s)\Users, we appreciate the time & effort of these types (freeware, open source…) of programs, genuine thanks.

[r0lZ]

I don't understand what you want to do. The NOP commands are useless (except the last ones), that's right, but they are also harmless, and thanks to them the code is easier to read. Why do you want to remove them?

LinkTopCell restarts the current cell. It's a cell command, executed at the end of the playback of a cell of the PGC. It is probably used to repeat the animated menu indefinitely, until the user selects a button. You cannot remove it. Anyway, this command is totally independent of the pre and post commands.

PgcEdit doesn't export the frame rate of a menu. When it imports a menu, it is copied as it is, without modifications. You cannot change the frame rate of a PAL menu to NTSC, as this will almost certainly confuse the player. Converting a PAL menu to NTSC is a difficult job, as you have to convert also the button highlights. Anyway, PgcEdit can't do that. If you convert it manually or with another program, you (or the program) have to fix everything, including the frame rate to NTSC before importing the menu back in the original DVD.
I am strongly against the PAL to NTSC patching method, and don't want to implement that. Sorry. But if you really want to try to play a PAL video as NTSC, you can probably patch the IFOs with IfoEdit, and the VOBs with DVDPatcher. However, it's the best method to have a totally non-compliant DVD. You have been warned!

No, PgcEdit cannot append titles to an existing domain. There are many limitations when doing that (for example, the video, audio and subpic streams properties must be exactly identical) and it is usually easier to import the new titles as a new titleset and modify the navigation manually to call it when needed.

I have added several times some cells at the end of a PGC or in a new dummy PGC, and replaced those cells with VobBlanker without problem. It's a good trick to add a limited number of cells to an existing titleset, but again, you have to be sure that the streams are compatible. Anyway, VobBlanker is THE tool to do this kind of job, not PgcEdit.

[kikatu]

Hello, had the feeling, if a NOP command is at the bottom and nothing else follows, it could it be trouble.

OK I get the LinkTopCell Cell Command and its independence.

Sorry for not explaining much well. The conversion PAL to NTSC on the project was already done, including menus. Wanting to do the process keeping the menu, the PAL menu was exported, while later importing the new NTSC muxed DVD opened in PGCEdit, it detected irregularities on the IFO (exported from the menu) about the time not matching, and it fixed the frame rate of the old IFO from 25 to 30, not VOBs, just the menu IFO.

See, the only reason the question was raised, is because apparently PGCEdit did change the frame rates information on the IFO from the menu, not VOBs. The "Pacthing Method" was never an option. Also by accident I learned to restore the highlights button information using VOBEdit. rOLZ I hope you understand what I mean, since you are the developer, I do not want to post something which confuse us.
No, PgcEdit cannot append titles to an existing domain. There are many limitations when doing that (for example, the video, audio and subpic streams properties must be exactly identical) and it is usually easier to import the new titles as a new titleset and modify the navigation manually to call it when needed.

It is indeed easier, but for some reason a new tittleset was not the wish, still it can be done on IFOEdit.

I have added several times some cells at the end of a PGC or in a new dummy PGC, and replaced those cells with VobBlanker without problem. It's a good trick to add a limited number of cells to an existing titleset, but again, you have to be sure that the streams are compatible. Anyway, VobBlanker is THE tool to do this kind of job, not PgcEdit.

Cool, it is funny because on our first conversion by trial\error we learned:

- How restore the highlight buttons with VOBEdit.
- Create a custom Layer-Break cell (not a visible chapter) with zero padding.
- Managed to do a new "dummy title" in an already created domain using IFOEdit.

Recently by conclusion, the DVD-Player does not care how much clean the commands are, if there is additional titlesets for a dummy title & etc... I would have to discipline my vision, because sometimes we can overspend time in something which is only our own perception of how it should look or be... But alternatives, more knowledge applied give us our personal signature to our custom job, art, work and so on... In this case, it might be wise to simply change what is only need it, and not trying to get every little command out of the IFO.

One last unanswered question, how does the rules of SET GPRM* & IF GPRM* go around, if there is an order placing these commands?

Thanks again for the timely respond, enjoy the rest of the weekend rOLZ.
:thanks:

[blutach]

Hello, had the feeling, if a NOP command is at the bottom and nothing else follows, it could it be trouble.

On a well authored DVD, the button range will not ever be such that the last Goto is ever executed. If you are worried, either:


Replace the last NOP with a link to a newly authored PGC which zeros all GPRMs and jumps to the First Play PGC (effectively re-inserting the DVD); or

Delete (or replace with NOPs), for example, line 20 in picture 1 and line 12 in picture 2.

Of course, if this last command is ever executed, it means the nav is wrong. A trace will help.

Regards

[r0lZ]

Hello, had the feeling, if a NOP command is at the bottom and nothing else follows, it could it be trouble.No, a NOP does nothing, and therefore cannot cause trouble. You MUST keep the last NOPs in your case, as they are target for GOTOs. (However, see the side note below. You can delete them, as they are dead-ends anyway. But you must understand what you are doing first!)

Sorry for not explaining much well. The conversion PAL to NTSC on the project was already done, including menus. Wanting to do the process keeping the menu, the PAL menu was exported, while later importing the new NTSC muxed DVD opened in PGCEdit, it detected irregularities on the IFO (exported from the menu) about the time not matching, and it fixed the frame rate of the old IFO from 25 to 30, not VOBs, just the menu IFO.

See, the only reason the question was raised, is because apparently PGCEdit did change the frame rates information on the IFO from the menu, not VOBs. The "Pacthing Method" was never an option. Also by accident I learned to restore the highlights button information using VOBEdit. rOLZ I hope you understand what I mean, since you are the developer, I do not want to post something which confuse us.
No, I still don't understand. What did you exactly? How did you convert the menu to NTSC? If it has been correctly converted, it should have a NTSC frame rate.
Do you mean that you have replaced the menu VOB only, keeping the original IFO? You can't do that! If you convert something, the VOB and IFOs must be converted, as they are interrelated.

One last unanswered question, how does the rules of SET GPRM* & IF GPRM* go around, if there is an order placing these commands?
Of course, the order is important. But I can't explain the "rules", as the order and content of the commands depends of what you want to do. I can't teach you how to program.

However, in the post-commands of your examples, things are simple to understand. They are typical examples of menus with LinkTailPGCs in all buttons. When a button is activated, its value (the number of the button multiplied by 1024) is stored automatically in SPRM 8, and LinkTailPGC trsansfers the control to the post-commands.

The first post-commands line stores 0 in GPRM 3. I don't know why, but GPRM 3 is probably used later, in another PGC, to decide what to do.

After that, the highlighted button number value is copied from SPRM 8 to GPRM 0. As this value is now the number of the button you have activated in the menu multiplied by 1024, the next line divides it by 1024 to convert it to the real button number.

Line 4 compares this value to 1. If the first button was selected, the comparison is false, and the next commands are executed. They do the action that should be done when button 1 is selected. Otherwise, the GOTO is executed, and it jumps to line 8, where GPRM 0 is compared with 2. The method is identical, except that this time it concerns button 2. Again, if button 2 was not selected, the GOTO is executed and jumps to line 12, where button 3 is tested, etc...

Use the trace mode (with the watch window opened) to understand how it works.

Side note: you can certainly delete line 20 in the first example and line 12 in the second one, as their condition cannot be true because there are only 5 and 3 buttons in the PGCs. The next lines must be executed anyway, or the nav will jump to the last NOP, where it will stop. If you remove the last GOTO, the last NOP line will not be a target any more (and will therefore not be highlighted in yellow any more) and you can safely delete it, although it's not necessary.

[kikatu]

On a well authored DVD, the button range will not ever be such that the last Goto is ever executed...

Hello blutach:

Yes, basically this was a cleaning job after another program did its job poorly. Thanks you blutach.

Hi rOLZ:

No, a NOP does nothing, and therefore cannot cause trouble. You MUST keep the last NOPs in your case, as they are target for GOTOs. (However, see the side note below. You can delete them, as they are dead-ends anyway. But you must understand what you are doing first!)

Well the understanding was no operations was excuted, but the dead-ends was one curiosity to raise a question. Also guessing some NOP commands need to be in place in order not to break the commands sequence.

No, I still don't understand. What did you exactly? How did you convert the menu to NTSC? If it has been correctly converted, it should have a NTSC frame rate.
Do you mean that you have replaced the menu VOB only, keeping the original IFO? You can't do that! If you convert something, the VOB and IFOs must be converted, as they are interrelated.

Demuxed the original PAL DVD including the subpics, encoded the movie & menu elementary streams to NTSC, later they were muxed. Opened the new NTSC DVD (basic without a menu) and imported the PAL Menu. Now whatever happened here since this was months ago, and I don't have the PAL files to be replicated, probably I forced the NTSC encoded Menu VOB file to stay in the original PAL VIEDO_TS folder (renamed the PAL) and it was replaced by PGCEdit when trying to import the menu, one thing happened... PGCEdit complained, but the changes to the IFOs frame rates happened when the DVD was saved. I will have to replicate this on a very very small sized PAL DVD with menus as an example to alleviate confusion. By the way, this was not a fluke, since the testing was done twice, the first time PGCEdit left a few cells with its original 25 fps information on the IFO, the second time it changed all 25s to 30s.

Well guys, I might need to do some studies about the use and meanings of some of these commands rules. Thank you for the tips, explanations, side notes & etc... Cannot complain guys.:thanks:

[blutach]

I don't have the PAL files to be replicated
May I ask that you re-read rule 6 please?

Regards

[kikatu]

May I ask that you re-read rule 6 please?Regards

Rule #6: No warez, cracks, serials or illegally obtained copyrighted content! Links to content of a questionable nature, asking for, offering, or asking for help/helping to process such content in any way or form is not tolerated.

Hi blutach:

Re-read them. There is nothing to worry about, unless my visa expired, then I would be breaking somebody else's rule. Although rule number six seems a little bit sensitive here, but is not an issue.

[blutach]

Just that you say you now no longer have access to the source material. If you don't, we can not offer advice and assistance. Even if you bought the DVD and subsequently disposed of it (lost/gave it away/whatever), you have no further right to the files. That is what rule 6 in this case is directed at (illegal copying of copyrighted material).

If you do still have the (original PAL) DVD in your possession, then there's no issue.

Regards

[kikatu]

Hello bluetach:

Just that you say you now no longer have access to the source material.Yep, both DVDs are not mine, but I was the one who did the project, and I can have access to the materials previously mentioned, they are not simply in my PC and never were.

That is what rule 6 in this case is directed at (illegal copying of copyrighted material).It does not apply, is not an issue as stated before. The sensitivity to this topic related to rule number six, is simply a misunderstanding.

[Doom9]

We do need to have a simple yet effective way to determine whether we're dealing with a legitimate or illegitimate backup. Towards that end, we've established that access to the original source material constitutes proof enough to ensure the validity of a project.
There's nothing wrong with you doing a backup from somebody else (copyright law requires that if you do that project on your own machine, you get rid of any copies once you return the source disc), but you cannot ask questions about it here once the source has left your hands. We do not have time or resources to go into lengthy determinations about source validity, hence we have a simple rule that is effective and covers the large majority of cases we encounter. As with other rules, we never attain 100% reliability, but in the real world we have courts, lawyers, the police and DAs and around here we have to keep things more simple and hence, according to the well established interpretation (with me being the final instance when there are any doubts), you can no longer ask questions about this project.