PGCEdit: MBS detected

[ggtop]

Hi,

I had some DVDs containing multiple sets of bottons in menu domains in the past, but despite the warnings PGCedit displayed editing the buttons has never been a problem. But now I have one that has an "unselectable" menu after editing. the functions behind the buttons are still there but i can't see button highlighting...
I read in an earlier post (http://forum.doom9.org/showthread.php?t=146972) that PGCEdit always keeps the first set and overwrites all subsequent ones. Is there a safe way to edit those menus with keeping button highlighting intact?

BTW Normally I process all my backups with VOBBlanker, edit navigation, buttons and so on with PGCEdit, "shrink" the menu with NuMenu4U (does anybody still knows this one? :)) and finally with DVDRebuilder. I assume that also NuMenu4U only keeps the first set because after re-encoding with NuMenu4U PGCEdit had never complained about MBS...

Any suggestions?

ggtop

Edit: I wonder why PGCEdit still reports MBS altough I edited and saved the menu?
And is it "safe" to edit such a menu if the button data is identical?

Edit2: OK, PGCEdit doesn't change the number of sets. That's probably why MBS are still reported...

Edit3: I tested it again from scratch and button highlighting seems to be OK before processing with NuMenu. I tested with MPC-HC on my PC.
I will try NuMenu again one differently preprocessed sources and reported again...

[r0lZ]

The button highlights (in the subpic stream) are never modified by PgcEdit. But, as you know, PgcEdit saves the edited buttons in all sets. If, for example, there is an additional button appearing in a subsequent set, it will be completely suppressed, as it is not present in the first set. The same thing is true also for the colour schemes. The buttons may be invisible after your edits if the transparency was animated with a fade in, as the first set is probably completely transparent. I suggest to verify the colour scheme, but I can't be sure it's the problem without examining the DVD.

AFAIK, MenuEdit can edit all button sets independently, but the free version can only edit the first button group (and therefore is not suitable for 16:9 menus), and if there are many button sets, you have to edit them all manually. However, you can perhaps use it to examine the original sets.

[ggtop]

Hi rOlZ,

I will give MenuEdit a try and report later. I also found a setting in NuMenu I want to try. I'm curious to find out what has happened.

ggtop

[ggtop]

OK, I tried MenuEdit (Free), but I couldn't see anything like sets. I only see the groups.
But I think I have a lack in understanding buttons in general...
Is there a guide about that issue? Maybe in PGCEdit Help file?

I would assume that I need 2 sub streams. One for the button itself and one for the highlighting. The streams are muxed into the vob (pgc, cell) that represents the menu domain. But maybe I'm totally wrong....:confused:

What does it mean that the cell contains different sets?
Does it mean that at a certain LBA the sub streams might be different to the previous one?

Is it possible to set the set-counter to 1 after altering the menu with PGCEdit?

I'm confused...

ggtop

[r0lZ]

The definition of the buttons (that you can edit with PgcEdit) are stored in the nav packs. (Nav packs are not a stream, but you can consider them as a stream if you wish, as they are placed at relatively regular intervals of approx. 0.5 second in the VOBs. Each nav pack defines a new VOBU, that is an independent and indivisible portion of the VOB cell.)

In the other hand, the button highlights are stored in one or several subpic streams, just like regular subtitles. (Only one stream is necessary for 4:3 menus, but 2 or 3 streams are necessary for 16:9 menus, due to the different wide screen and pan & scan and/or letterboxed display modes supported by the DVD.) PgcEdit has no provision to edit the subpic streams, but you can do it with DVDSubEdit.

The buttons sets are defined in the nav packs. Usually, there is only one single set per cell (spread over several VOBUs), but in some special cases, it might be necessary to define several sets. See this post at VideoHelp (http://forum.videohelp.com/threads/323612-Need-FREE-DVD-Authoring-Software-%28Which-Authors-VOBs-Allows-Menus-Etc%29?p=2004854&viewfull=1#post2004854) for a complete description.

As you can see, yes, it is possible to change completely or partially the buttons at each new VOBU. (More precisely, the button definitions contain also timing information, and they can therefore start or end in the middle of a VOBU, but the definition itself has to be in a nav pack.)

There is no "set-counter", but PgcEdit counts the sets (by examining the HLI_GI values) when it parses the VOB files. There is currently no way to clear the HLI_GI bits, but that's useless IMO, as if you edit the menu buttons, the values of the buttons are overwritten anyway, making the whole cell behave as a single set, except for the highlights, that can still be animated. (If the HLI_GI bits were cleared, the animation would be lost.)

[EDIT] My post at VideoHelp has been written because DVDAuthorGUI seems to always define a new set at each VOBU. Of course, it's an authoring error. Usually, commercial DVDs have not that kind of error, but when it's the case, you can of course safely edit the menus, as nothing will be lost. But in some cases, it's dangerous. I remember a problem I had with Pixar's Cars. In that DVD, an Easter egg button appears after the other buttons in the main menu. If you click it when it is active, it leads to a semi-hidden bonus. Of course, editing the menu has had the effect of killing that button (as PgcEdit has copied the "normal" buttons present in the first nav pack over all nav packs with buttons of the cell, therefore removing the additional button). A bonus was therefore lost. BTW, it's also why PgcEdit displays additional warnings when you use functions that need to know all commands in the DVD to work correctly, such as Find or Delete Uncalled PGCs. In the case of Cars, PgcEdit would have probably missed the hidden bonus, wrongly considered as unreferenced, simply because its calling command was not known. However, now, PgcEdit checks all commands, including in MBS, so that should not occur any more. But the menu editor is still limited to a single set (mainly because it is too difficult to imagine a simple way to edit a multitude of sets with ease).

[ggtop]

It's always a pleasure to read your posts as they are very informative. I don't want to get on your nerves but it leads to some more questions...:rolleyes:

Only one stream is necessary for 4:3 menus, but 2 or 3 streams are necessary for 16:9

That means 1 stream represents a group up to a maximum of 3 groups. Is that correct?

Does that mean that the Menu Editor in PGCEdit shows the buttons that are defined in the first VOBU with HLI_GI value=01?
PGCEdit further checks this value till the end of the cell against value 10 or 00. If it is 01 or 11 MBS warning pops up. Also Correct?

In your case of CARS you didn't see the "hidden" button because it was not present in the initial VOBU containing a button (in this cell).

So the only way to verify this is to call Info -> multiple Sets of Buttons/BOVs and look if the number of buttons change between sets.

So in my case where the number of buttons and the commands are equal across all sets it's obviously an authoring error and can be ignored. So if I remove a button in the menu editor this (all buttons and their commands) is written to all nav packs leaving HLI_GI untouched.

The buttons may be invisible after your edits if the transparency was animated with a fade in, as the first set is probably completely transparent. I suggest to verify the colour scheme

Can I verify this when there's no chance to get to another set or is this color scheme definied at PGC level?

I checked this in the menu editor...each button can use 1 of 4 schemes (schema?) and 3 of them can be definied individually. Is this fixed or can I define new schemes in every VOBU?

ggtop

[r0lZ]

That means 1 stream represents a group up to a maximum of 3 groups. Is that correct?
Yes. More precisely, there is a stream per group, and also different button data per group, although usually only the position and size of the buttons differ in each group, to reflect the different position and size of the highlight in the subpic stream of the group. (But again, it's not a rule. I have seen menus with a different button command in each group.)

Does that mean that the Menu Editor in PGCEdit shows the buttons that are defined in the first VOBU with HLI_GI value=01?
Yes.
You can use the Image [|<] [<] and [>] buttons in the main menu viewer window to show the background of a different VOBU, but only the background image changes. The data displayed in the editor window are alwas the data read during the parsing of the buttons, corresponding to the first VOBU with buttons.

PGCEdit further checks this value till the end of the cell against value 10 or 00. If it is 01 or 11 MBS warning pops up. Also Correct?
Yes. (Although some additional checks are made. For example, PgcEdit checks also if the button commands changes, and if it's not the case and the value is 11, then that value is obviously wrong and it is not taken into account by PgcEdit.)

In your case of CARS you didn't see the "hidden" button because it was not present in the initial VOBU containing a button (in this cell).

So the only way to verify this is to call Info -> multiple Sets of Buttons/BOVs and look if the number of buttons change between sets.
That's right, but PgcEdit is now a bit smarter, as it knows that there is an hidden command in a button. The button cannot be edited, but it is taken into account by functions such as Find Uncalled PGCs.

So in my case where the number of buttons and the commands are equal across all sets it's obviously an authoring error and can be ignored.
Unfortunately, that's not sure. There might be other good reasons for the MBS. For example, a button command can change during the playback of the menu. (I have never seen that, but it's possible.) Also, when the HLI_GI value is 01, any button data could have changed, such as the position of the button. Again, if you edit the menu, the button will be frozen at the same place, and the highlight could not be visible during some parts of the playback. It's extremely rare, but "bouncing buttons" have been made in some commercial DVDs.

So if I remove a button in the menu editor this (all buttons and their commands) is written to all nav packs leaving HLI_GI untouched.
Right. The problem is that currently, all values (except HLI_GI, not editable anyway) are written, including the values that have not been modified. So, even if your edit consists only in deleting or hiding a specific button, the other buttons will be "frozen" as well.

Can I verify this when there's no chance to get to another set or is this color scheme definied at PGC level?

I checked this in the menu editor...each button can use 1 of 4 schemes (schema?) and 3 of them can be definied individually. Is this fixed or can I define new schemes in every VOBU?
The colour schemes are defined with the buttons, in the nav packs. They can therefore also change during the playback of the menu cell. However, the colours referenced by the colour schemes are defined in the PGC, and they cannot be animated. It is only possible to change which colour is used in the PGC CLUT to somewhat animate them. The opacity values can also be animated.
BTW, colour scheme 0 is defined in the subpic stream, just like the colours of a standard subtitle. It can also be animated, of course, and you can edit it with DVDSubEdit.

If you wish to examine exactly what changes in the different sets, use VobEdit. It can display the button information in the nav packs. (Take care: if you change them, your edits are saved in the VOB immediately!)
With DVDSubEdit to examine the subpic streams, you have all the tools needed to understand what changes in the MBS.
PgcEdit is designed to edit easily the DVD, not to examine it. You can edit the MBS with VobEdit, but as you will realize, it's extremely tedious, as you have to edit all nav packs individually, and VobEdit is not very intuitive.

BTW, I have noticed that when there is a lot of sets in a menu (more precisely when the set changes at each VOBU), it's *usually* due to an authoring error, or because the button highlights or the colour schemes are animated. In that case, you can verify easily if the buttons are really animated just by playing the menu with a good DVD player. It you cannot see button changes, you can *probably* assume that it is safe to edit the menu. But when there are only 2 or 3 sets (like in Cars), it's probably because the menu behaviour changes somewhere, and it is much more dangerous to edit it.

[ggtop]

Hi r0lZ,

ich (what means "I" in English :)) multi-read your response and tried to understand...

The groups are definied in the nav packs and they say use subpic stream 0x20 for group 1 e.g.

Is the position and the size of buttons also stored in the nav packs? I thought only the subpic streamknows about size and position. the command has to be in the nav packs. That's clear to me.

How is button animation made? A simple fade can be made with different opacities at each VOBU. Right?

What about splitting the cell? Couldn't a cell containing MBS be split at those LBAs where a new set is definied?

Or maybe PGCEdit could ask for user input to determine which VOBU should be taken as default in the menu editor?
In this case your kids wouldn't cry each time they miss the easter egg on CARS and beg for the original disc ;-)

But I'm only thinking loud...PGCEdit is already (nearly) perfect :)

ggtop

[r0lZ]

Groups and sets are two totally different things. But yes, the group determines which subpic stream to use.

Everything that you can edit with PgcEdit's menu editor is stored in the nav packs. (It's why you cannot edit colour scheme #0, that is in the subpic stream.) The size and position of the buttons define only the "hot spot" (the clickable area) of the button. It's also in that area that a portion of the subpic stream is shown, using the relevant colour scheme, when a particular button is highlighted or activated. (The rest of the subpic stream is shown using the default colour scheme #0, usually full transparent, so the inactive buttons are not highlighted.)

Honestly, I have never studied how subpic animation is made, but it is certainly possible to change the subpic image at each new VOBU. The transparency can be animated the same way, but there are other methods. In the subpic stream, there are special commands (not at all related to the navigation, so it's not the job of PgcEdit to deal with them) to instruct the player how and when it must display the subpic. These commands can be used to animate the subpic transparency with more precision than the VOBU method. Have a look at DVDSubEdit. It can add fades to the normal subtitles, using that method. The commands are displayed in the "info" window in the bottom left corner, under the DCSQT labels. A DCSQT contains usually several commands, to define the position of the subpic (not the button hot spot!), the colour indexes to use, the transparency, etc. Usually, there is only one DCSQT (#0) per subpic, but it is possible to define several DCSQTs to animate the subpic transparency. Anyway, even if you use the DCSQT method, the animation is limited to a short time, and you have to define new DCSQTs in subsequent nav packs to build complex animations, and therefore you need also MBS. Note that the DCSQT method animates the subpic image as a whole. There is nothing related to buttons in the subpic stream itself.

Usually, when there are major changes in buttons, a new cell is defined. But unfortunately, it's not always the case. PgcEdit cannot split the cell automatically, as that would require to process the whole VOB file, and I'm not a specialist of the VOBs. VobBlanker can do that, but it has no provision to automatically split at MBS changes. But with the info displayed by PgcEdit, you can certainly manually split the cell at the right LBA with VB, and then edit the cells with PgcEdit without having to worry about MBS. Your idea is good, but note that it is not suitable when there are many sets (one new set per VOBU), as that would require to define a multitude of new cells (probably too many to respect the DVD-Video standard), and anyway it will be impossible to edit them all manually.

My idea to implement a menu editor dealing with MBS is to remember which values have been edited, and overwrite that values and only them when the buttons are saved. So, if a button appears later, it will not be overwritten. But it will still not be editable. Maybe I'll implement that idea, but honestly, problems with MBS are relatively rare, and I have many other things to improve in PgcEdit.

[ggtop]

I analyzed some menus and just want to make sure I got it now...Normally in a menu cell with buttons:
1. There is a video stream of course
2. There are some buttons (definied in the nav packs)
3. Playback scenario: The player is instructed to play a certain group due to preferences and/or capability of video modes. This group leads to a subpic stream which is enabled but invisible (because opacity is 0%). The subpic stream is a static bitmap (~normally) and has e.g. only a few lines that are used for highlighting.
4. The hot spots of the buttons act as a mask, so the bitmap can only be seen through the rectangles of the buttons, no matter how the bitmap looks like.
5. If there is no button highlighting opacity is 0% and nothing can be seen. As soon as I move the cusor to a button the button state changes and I will see what is definied for this state in the button color scheme.

ggtop

[r0lZ]

Right. :-)

But there are exceptions to points 3 to 5. It is possible to invert the logic. The default colour scheme is used for the part of the image not included in button hot spots, and for the inactive buttons. I have said that it is *usually* full transparent, but it's not always the case. If the default colour scheme 0 is not fully transparent and the colour scheme used for the active button is fully transparent, the highlights over the *inactive* buttons are opaque (or semi-transparent), and there is no highlight over the selected button. Using this technique, it is possible to obscure or completely hide the inactive buttons, and display the normal background image without highlight for the active button.

BTW, it's also a technique to animate the current button (without MBS): Here, the video representing the button has to be animated, but not the highlight. The advantage is that the animation of the button is not limited to 4 colours with 4 transparency levels. I have seen this technique only once, on Roman Polanski's "Le Bal des Vampires" (I don't know the English title), zone 2 second edition. There were realistic blood drops falling on the active button. Very impressive!

[ggtop]

The title is "Tanz der Vampire" in Germany. Maybe I can get my hands on this edition sometimes.

It is possible to invert the logic.

I have to take a closer look into that and play with these values. Also DVDSubEdit drove me nuts cause I edited the wrong subpic stream all the time. But only this way one can learn :)

Getting back to my initial problem I found out using DSE that the subpic image is placed wrong after processing with NuMenu4U and therefore the functionality (command) is still there but I don't see thre HL. But I think I'm too late cause it's unsupported since 2005 I think. But nevertheless I'm happy to know where I have to look after in the future.

BTW The title I currently test with is "Marc Pease Experience" and to be honest is not worth to spend so much time on :rolleyes:
But I have another one with the same effect: "Extraordinary Measures".

Just to clarify for other readers: There is no bug in PGCEdit! The reason the HL doesn't work is because of NuMenu4U (and Scenarist maybe).

ggtop

[r0lZ]

There is no bug in PGCEdit!
:)

The problem is probably related to wrong subpic position offsets. The image in the subpic stream can cover (almost) the entire video, and in most commercial DVDs it's how the subpic streams are made, but it is possible also to crop the subpic image to include only the part really necessary in the stream, and to position it on screen with X and Y offsets defined in the DCSQT. I guess NuMenu4U resets the offsets to the default values, assuming that the subpic covers the whole image. (You can force DVDSubEdit to crop a subpic, and place it at a different position.)

BTW, why do you need NuMenu4U? IIRC, it's a tool to create a new menu from scratch, but I don't think is is suitable to rebuild an existing menu. (And, personally, when I need to shrink a menu to copy a DVD-9 to a DVD-5, I prefer to convert the menu to still with MenuShrink, or I use DVDRB or DVDShrink to shrink the menu more than the main movie.)

[ggtop]

You can force DVDSubEdit to crop a subpic, and place it at a different position

I already saw this option and tried it. That was how I saw that the image for the button HL is there, but not at the right place. But I also saw that in the new menu the position between the pics doesn't fit as in the original. Maybe I'll make a screenshot later.

BTW, why do you need NuMenu4U? IIRC, it's a tool to create a new menu from scratch, but I don't think is is suitable to rebuild an existing menu. (And, personally, when I need to shrink a menu to copy a DVD-9 to a DVD-5, I prefer to convert the menu to still with MenuShrink, or I use DVDRB or DVDShrink to shrink the menu more than the main movie.)

You don't remember remember correctly :)
NuMenu4U is a frontend for various apps like PGCDemux, VobSub, CCE and Screnarist for muxing (or MuxMan in the "Pro" Edition). Development has stopped very long time ago, but it works good in 98% of all cases.

Still Menus are also ok for languages other than mine (I blank everything except EN and DE and change the navigation accordingly). I prefer VB for this job.

I don't like transcoders and that's why I haven't Shrink installed. But honestly I wasn't aware that Shrink can be used to just process the menus until I read a post some days ago in "your" subforum.

I'm one of the the biggest fans of DVDRB, but I had problems with menu encoding (http://forum.doom9.org/showthread.php?t=137204) some time ago with "American Gangster" and "88 Minutes" and nobody had an explanation for that. DVDRB also doesn't process VMGM...

ggtop

I just tried the split cell feature in VB. I only had some work with cell commands and a dummy PGC which referenced a splitted cell, but the result plays fine now and PGCEdit doesn't reported any MBS. I will process that one with NuMenu tomorrow...

[r0lZ]

I use mainly DVDShrink to strip unnecessary streams (it has an interesting option to remap the streams automatically), and sometimes to cut the logos or credits of the main movie (in re-author mode). But I use it also when there is not much space to regain. In that case, imo, it can give *better* results than DVDRB, as it removes only some noise in the original vidoe, and that's not really perceptible. A true re-encoding adds usually additional artefacts. But I agree that Shrink is not good when you have to shrink at more that 85% or 90%, and in that case I prefer DVDRB.

I did not know that DVDRB problem with the menus. It's good to know.

I'm happy that the split MBS cell trick works as expected. Also good to know! :)

[ggtop]

Mmmmh, I splitted cell 1/2 (VIDEO_TS.VOB) into 1/2, 1/3 and 1/4. When I load this into DSE I only see 1/* and 1/2. Is this because there are no SPUs?

After rebuilding with NuMenu4U Button HL still doesn't work in MPC-HC, but I can see them in DSE (at the correct position this time). This is very strange and I suppose I reached a point where I don't know any further.

ggtop

[r0lZ]

Yes, normally, DVDSubEdit shows only the cells with subpics. Are you sure you have split the cell at the right LBAs?

I give up too. Sorry, but I can't analyse the problem without the original DVD.

[r0lZ]

Well, I've finally had a look to the original VOBs, and I see only one point that can be responsible of the problem.

The fact that, after having split the cells with VB, only cell 1/2 has highlights (according to DVDSubEdit) seems to indicate that VobBlanker did not find any subpic corresponding to the LBAs of cells 1/1 and 1/3. Honestly, I don't know if, when there are MBS in a PGC, the subpic has to be redefined for each set, but if it's the case, it is normal that VB has not included the subpic in the first and last cell. I don't know if it's the cause of the problem, but perhaps the image of the subpic highlight is declared too late in the subpic stream, or the subpic streams begins too late. So, when the player finds the buttons in the nav pack of the first set, it cannot display them because it has not read the highlights yet. Similarly, it doesn't display them for the third set because they have not been redefined. But it should display them during the playback of the second set, unless there is a bug in the player regarding MBS. Please note that this is pure guessing. I'm not familiar enough with the button highlights and the VOBs to be sure. But I'm almost certain that the original DVD has been badly authored.

Anyway, I see no good reason to define several sets of buttons in the menus of this DVD. They seem to contain exactly the same button definitions, and the highlight is not animated. So, IMO, since there is only 2 or 3 sets per menu, it is easy to remove the MBS by editing the "Highlight Status" of the additional sets with VobEdit.

I have also found a NuMenu4U bug, not related to the problem of the button highlights, and present only in VIDEO_TS.IFO. After the NuMenu4U processing, all PGCs of the VMGM are flagged as Title Menu entry PGC! This means that the player cannot know for sure where it has to jump when the Title Menu is called (by a VM command or with the remote). I suppose that it will jump to the first PGC, and *usually* it's the right Title Menu entry PGC, but it's not always the case. So, VMGM menus processed by NuMenu4U can lead to important navigation problems. (BTW, to fix the problem with PgcEdit, simply assign the Title Menu to the right PGC. PgcEdit will clear the wrong flags on the other PGCs.)

I can't help much more. Sorry.

[ggtop]

...but perhaps the image of the subpic highlight is declared too late in the subpic stream, or the subpic streams begins too late.

Do you know a way to alter this timing? I loaded the menu domain into DSE but could't change this. Or it is not possible without remuxing?

So, IMO, since there is only 2 or 3 sets per menu, it is easy to remove the MBS by editing the "Highlight Status" of the additional sets with VobEdit.

You mean load loading VIDEO_TS.ifo/.vob into VOBEdit and then edit the "HL Status" in the nav packs at the LBAs PGCEdit reports for MBS? Are you sure it's easy :confused:?

After the NuMenu4U processing, all PGCs of the VMGM are flagged as Title Menu entry PGC!

I can confirm this. I wonder why I didn't notice this in the past???
Mostly I don't load the processed DVD into PGCEdit. I just check using a player. But I will in the future.

Thank you for your investigations!

[r0lZ]

DVDSubEdit should let you change the timing, but if it doesn't, that means probably that it can't. Not sure why. Perhaps because there are MBS?

Yes, in the case of your DVD, it is not too tedious to remove the MBS, as there are only a few sets. Load the VOB in VobEdit. Use the [Jump] button to go to the LBA of the second set (you should NOT modify the first set), and click it in the left pane. Tick the "Button" checkbox to see the button information in the nav pack. At offset [008d] you should see the "Highlight status". This is the HLI_GI value, discussed above. Change it to 2. Repeat for all subsequent sets in the cell. You don't have to save, as the edited values are saved to disc immediately by VobEdit. (BTW, work on a copy, as VobEdit has some bugs, and in some rare cases, it can destroy your VOB file!)

[ggtop]

I changed the values using VOBEdit as you described. Nice you mentioned the VOBEdit bug. On my first attempt one nav pack got delete and PGCEdit reported an error on opening reading nav pack at that sector.
But now it worked and PGCEdit doesn't report MBS anymore.
I'll try NuMenu4U on this source again.

Just to be clear on this...changing that value just "fools" the player as it doesn't read button information again at these sectors. Even if the buttons would have changed there. Right?

[r0lZ]

Well, probably right, yes. But some players will read the button information anyway, I suppose. But at least, with that trick, you will not be annoyed by useless PgcEdit warnings any more.

Maybe, when I'll have some free time, I'll write a plugin to check if the button information changes really in the new sets, and if it's not the case and if the user can confirm that there is no highlight animation, the plugin will clear the flags automatically (like you did manually), and therefore merge the useless MBS in one single set. So, if you use that technique and you find that something doesn't work as expected, please let me know. (For example, it is possible that the button highhlight disappears too early.)

[ggtop]

I finally found some time to process with VobEdit'ed source with NuMenu4U and this time it worked :)
I only processed VM but I will do this on the whole DVD and report back. I also have another disc I want to test with this strategy.

A plugin would be a great idea.

ggtop

[ggtop]

I processed 3 different sources on which PGCEdit found MBS last night and all menus work fine after NuMenu4U.

What I did? 1. Open DVD with PGCEdit and run Info-> Multiple sets of buttons/BOVs, Open appropriate VOB in VOBEdit and jump to all LBAs after the first set and change HLI_GI value to 2 (as r0lz described earlier). After that NuMenu4U works fine on these sources (Marc Pease Experience, Iron Man 2, Extraordinary Measures (all german releases))


@r0lz: Thanks for all your help. Maybe there will be a plugin in the future?

ggtop

[r0lZ]

Thanks for the confirmation.

@r0lz: Thanks for all your help. Maybe there will be a plugin in the future?
I need some time to write it, but that should not be too difficult...