PgcEdit 0.5.0 beta [Archive] - Page 2

r0lZ

16th February 2005, 17:18

Originally posted by goonix
I have been too fast!

After simply open and save without any changes, the DVD will play now, but the game doesn't work anymore. For example it loops to the 50 Euro question (if you know that game...) and I never become a millionaire. Sigh!

Comparing the original IFOs and the saved IFOs I can see a lot of differences, but this is above of my knowledge.

Maybe you should not spend a big amount of time on this issue, because it is a very special DVD and you have something more important on your todo list. But if it is your ambition that PgcEdit works proper even on unusual DVDs, I will continue testing new PgcEdit versions with great pleasure.

The requested stripped DVD is on the way.

goonix I have changed a couple of things in the way I rebuild the IFOs to save exactly the same way as in your "Millionnaire" DVD.

1. Wheen there are no commands in a PGC, the old version saved an empty command table (ie, a table was present, but with the number of pre, post and cell commands to 0). Now, the command table is not saved at all (the pointer to the table is set to 0).

2. The strange method used in this DVD to hide the chapter numbers is to define only one chapter with the program number being 0. The PGC number was sometime 1, and sometime the last PGC in the title domain.
I saved a PTT with program = 0, and PGC = 1. Now, the original PGC number is retained.

I have made a binary comparison between the original files and the saved ones, and there are now no differences at all.
As I don't have the VOBs, I made a Get VTS Sectors with IfoEdit to recalculate them without the VOBs. Of course, I cannot say for sure if IfoEdit changed anything else when doing his Get VTS Sectors.

I'm pretty sure the modifications I've made should not modify the behavior of the DVD.
However, could you test it with beta 10? If it doesn't work, then try to do a file comparison, and, if you find some differences, send me a copy of one modified IFO and the original.

Don't forget to switch off the 32K gap option, or you will have differences in the VTS sector pointers.

Thanks in advance...

lamster

16th February 2005, 18:38

Originally posted by r0lZ
New beta 10 available on my homepage at VideoHelp (http://www.videohelp.com/~r0lZ/pgcedit/index.html).

Minor correction - the new beta is available via the "All versions" link in r0lZ's home page.

goonix

16th February 2005, 19:06

Wow! It works!
After loading and saving without any changes, all IFO files are identical to the Original.
Then I have done a Kill PGC Playback of one PGC and only this IFO is now different (of course).
The change works as expected.

Now you can become a Millionaire like jsoto.:)

"Found a total of 23727 BOVs". Who can beat this?

Many thanks for this invaluable tool!
goonix

r0lZ

16th February 2005, 19:36

Originally posted by goonix
Wow! It works!
After loading and saving without any changes, all IFO files are identical to the Original.
Then I have done a Kill PGC Playback of one PGC and only this IFO is now different (of course).
The change works as expected.

Now you can become a Millionaire like jsoto.:)

"Found a total of 23727 BOVs". Who can beat this?

Many thanks for this invaluable tool!
goonix Great. Still wondering what was the problem before!

23727 BOVs! I wonder how many time PgcEdit spends to find them.
Your DVD is already verry long to load, even without searching for BOVs... It's a side effect of the Tcl/Tk language.

I go to the bank now. Some billions are awaiting. ;)

jsoto

16th February 2005, 21:03

Originally posted by r0lZ
Note that there are errors in the resolution stored in the IFOs.
Unfortunately, this bug is present in many programs, because the information on the usage of the Stream Attributes flags were wrong until recently.
Yes, you're right. 352x288 and 352x576 samples have a wrong (just the other one) info in the IFOs (although the VOBs are correct). Did you find any other mistake?

jsoto

EDIT: Uploaded again with these samples fixed, and including (not standard) 16_9 ones

r0lZ

16th February 2005, 23:38

Originally posted by jsoto
Yes, you're right. 352x288 and 352x576 samples have a wrong (just the other one) info in the IFOs (although the VOBs are correct). Did you find any other mistake?

jsoto

EDIT: Uploaded again with these samples fixed, and including (not standard) 16_9 ones No, I did not noticed another error. BTW, there was a bug in PgcEdit with the resolution, too. I discovered it by looking at your IFOs, but it was difficult to know what to do! Checking a bug with a buggy material is not easy! In fact, at the time I writed this part of the code, I used the info in the mpucoder site, which was also wrong. It's fixed there, too.

Speaking of non-standard resolution, I have noticed that DVD-Lab is able to generate 480x576 title VOBs! What is this resolution? Is it supported by the standard? Is is a bit somewhere in the IFOs to reflect that resolution?

jsoto

16th February 2005, 23:49

480x480/576 is SVCD resolution, NOT DVD standard supported.... but it is usually supported in settops able to play SVCDs (today, practically all of them)

SVCD is MPEG-2, but note you cannot code this resolution in the IFOs.

Many users, having old SVCDs, want to put their content inside a DVDR, in a loseless (without recoding) way. This is the main reason to use it in a DVD.

jsoto

EDIT: Curious... I'm saying "old SVCDs"... that was my preferred encoding method only one year and a half ago...

r0lZ

16th February 2005, 23:54

Thanks, jsoto.

There will be for sure a problem with that resolution if you display it in the PgcEdit's menubutton viewer, because I need to know the exact resolution by looking in the IFOs.
I suppose I may assume that this SVCD resolution will be used only in title VOBs, without BOVs.

blutach

17th February 2005, 01:00

My issues fixed in B10. Thnx r0lZ.

Have set VOBU scan at 30 and it goes in a flash. Thanks for the advice.

Regards

goonix

17th February 2005, 01:17

Originally posted by r0lZ
23727 BOVs! I wonder how many time PgcEdit spends to find them.
Your DVD is already verry long to load, even without searching for BOVs... It's a side effect of the Tcl/Tk language.
It needs 5:25 min to scan the BOVs every 30 VOBUs and 6:05 min to scan the BOVs every 1 VOBU.

Not a big difference. Both scans found the same count of BOVs (23727). The scans were done on a DVD5(folder) using a 2.8 GHz Pentium.

goonix

r0lZ

17th February 2005, 02:18

Verry slow! :(

The time difference is not verry sensible here because most of your PGCs are verry short ones. Scanning every 30 VOBUs is usefull for 'normal' DVDs.
I've never saw the scan missing a BOV, even when scanning every 30 VOBUs. I'm glad you confirmed that with such an heavy BOV usage.

Thanks for the info!

goonix

19th February 2005, 16:40

I have burned the same DVD with NERO (using DVD-Video) and with PgcEdit (mkisofs, DVDDecrypter).

After loading these DVDs in DVDDecrypter (File-mode), I found that the file order is different.NERO PgcEdit

VIDEO_TS.IFO [ 20 KB] VIDEO_TS.IFO [ 20 KB]
VIDEO_TS.VOB [ 52.796 KB] VIDEO_TS.BUP [ 20 KB]
VIDEO_TS.BUP [ 20 KB] VIDEO_TS.VOB [ 52.796 KB]
VTS_01_0.IFO [ 62 KB] VTS_01_0.BUP [ 62 KB]
VTS_01_0.VOB [ 416 KB] VTS_01_0.IFO [ 62 KB]
VTS_01_1.VOB [1.048.544 KB] VTS_01_0.VOB [ 416 KB]
VTS_01_2.VOB [1.048.544 KB] VTS_01_1.VOB [1.048.544 KB]
VTS_01_3.VOB [1.048.544 KB] VTS_01_2.VOB [1.048.544 KB]
VTS_01_4.VOB [ 528.942 KB] VTS_01_3.VOB [1.048.544 KB]
VTS_01_0.BUP [ 62 KB] VTS_01_4.VOB [ 528.942 KB]
VTS_02_0.IFO [ 18 KB] VTS_02_0.BUP [ 18 KB]
VTS_02_0.VOB [ 82 KB] VTS_02_0.IFO [ 18 KB]
VTS_02_1.VOB [ 84.168 KB] VTS_02_0.VOB [ 82 KB]
VTS_02_0.BUP [ 18 KB] VTS_02_1.VOB [ 84.168 KB]
VTS_03_0.IFO [ 20 KB] VTS_03_0.BUP [ 20 KB]
VTS_03_0.VOB [ 162 KB] VTS_03_0.IFO [ 20 KB]
VTS_03_1.VOB [ 206.598 KB] VTS_03_0.VOB [ 162 KB]
VTS_03_0.BUP [ 20 KB] VTS_03_1.VOB [ 206.598 KB]As you can see, in NERO the BUP-files are located always after the VOB-files.

Despite of the 32K issue of NERO, isn't it better to have a big VOB-file between IFO and BUP instead of in adjacent sectors?
I think a bigger scratch can damage more than one sector and if it happens on the border between IFO and BUP both aren't readable anymore.
Am I wrong?

goonix

r0lZ

19th February 2005, 17:17

The DVD Devrypter test is not a good test. It shows probably the order of the filenames in the directory, not the order of the data sectors on disc. Apparently, mkisofs stores the filenames in alphabetical order, but that doesn't matter.

I have verified again, to be sure. The datas are saved in the right order: IFO VOBs BUP...

You can verify with an hex editor. Search for ASCII "DVDVIDEO-" to find the beginning of the IFO and BUP files, and for binary 0x000001BA to find the data sectors.

Don't worry. The PgcEdit method is good. :)

Anyway, the data must be saved in IFO VOB BUP order. If not, the DVD will probably not play at all on a standalone.

goonix

19th February 2005, 17:52

If DVDDecrypter would show the files in the directory file names order, than both DVDs should have displayed equaly. Maybe an other algorithm is used.

But I trust your knowledge and my doubts are gone. I will do the Hex-editor search to learn something. Thanks for the information.

goonix

goonix

20th February 2005, 02:17

Just for confirmation (and to show that I really have learned something ;) ).

Mkisofs creates 2 filesystems on the DVD: ISO and UDF
Nero creates 3 filesystems on the DVD: ISO, UDF and Joliet

The file entrys in the filetables of each filesystem are in following order:mkisofs
ISO BUP IFO VOB
UDF BUP IFO VOB

Nero
ISO BUB IFO VOB
Joliet BUB IFO VOB
UDF IFO VOB BUPDVD Decrypter seems to display the files in the UDF entry order and this is different between mkisofs and Nero.

But the entry order of the filesystems has nothing to do with the real file order on the DVD (as you can see comparing the first LBA of the files).
It is in every case IFO VOB BUP.

So rolZ is right as always.
PgcEdit is the best choice for burning DVDs.

goonix

2COOL

20th February 2005, 03:59

Originally posted by goonix

Nero
ISO BUB IFO VOB
Joliet BUB IFO VOB
UDF IFO VOB BUPWe know you meant to say BUP.

blutach

20th February 2005, 08:41

Originally posted by goonix
PgcEdit is the best choice for burning DVDs. Fully agree!

Yet another Nero thingy, but I though the proper DVD filesystem spec did not include Joliet. Am I right?

Regards

r0lZ

20th February 2005, 10:58

Originally posted by blutach
Yet another Nero thingy, but I though the proper DVD filesystem spec did not include Joliet. Am I right? As far as it is an UDF filesystem on the disc, standalones are happy. I think adding a Joliet FS doesn't hurt, and may help with long filenames in the DVD-ROM part.

Maybe there is a flag to enable Joliet with mkisofs. If I find it and if it works, I'll add it to the Burn DVD GUI in PgcEdit.

[EDIT:] There is a -joliet option in mkisofs, but seems it is ignored when the -dvd-video option is used.

@goonix
How did you checked the filesystems on the nero image? IsoBuster reports only ISO and UDF.

goonix

20th February 2005, 18:39

Sorry for the typo, I always meant BUP.

I found the "different" file order in DVD Decrypter on a DVD I have burned on a PRINCO media in 2003. Now I would enjoy this movie again, but it was stuttering in my standalone. The check with plextools has shown me a horrorfying amount of PI/PO errors. For that reason I have burned this DVD with PgcEdit on a reliable media.

In sector 16 of the old DVD I can see that the burning application was Nero and the burning date was mid 2003, but couldn't find the version number. I think Nero 5.5 was used this time.

In my current version (6606) Nero seems to have changed its mind and creates only the ISO and UDF files systems. Even if I have an additonal DVD-ROM part with long file names, there is no Joliet filesystem. The long file names are in the UDF filesystem. The different entry order is still the same:
ISO -> BUP IFO VOB
UDF -> IFO VOB BUP

Next time I should spend more time for investigation before bothering this forum with stupid questions.

goonix

DiggnSaeg

21st February 2005, 00:15

Hi!

I have some questions about PgcEdit (more or less):

Is it possible to start PgcEdit maximized?

What about the layer break? PgcEdit can remove it, but it will
be added again when writing a DVD+R9 (what is IMHO right).
Nero sets this flag (checkbox in PgcEdit) but without setting
"Type Flags" to 0, which should be the correct value (there's a
"2" instead). Is that correct?

What if I write the files without having removed the layer break?
Will Nero add a 2nd one?

What if I don't remove the layer break but some of the extras?
Then the layer break (physically) moves, resulting in a wrong
position stored in the .ifo.

r0lZ

21st February 2005, 00:39

Hi, DiggnSaeg, welcome to the forum.
Originally posted by DiggnSaeg
Hi!

I have some questions about PgcEdit (more or less):

Is it possible to start PgcEdit maximized?No. It's a Tcl/Tk or a freeWrap limitation.

What about the layer break? PgcEdit can remove it, but it will be added again when writing a DVD+R9 (what is IMHO right).
Nero sets this flag (checkbox in PgcEdit) but without setting
"Type Flags" to 0, which should be the correct value (there's a
"2" instead). Is that correct?I really don't know. I'm not a specialist of DL problems. Anyway, I think that setting the STC Discontinuity doesn't hurt.

What if I write the files without having removed the layer break?
Will Nero add a 2nd one?I don't know. Burn an ISO image, and see what happens.

What if I don't remove the layer break but some of the extras?
Then the layer break (physically) moves, resulting in a wrong
position stored in the .ifo. Again, I don't know. Nero searches for a 'good' place for the layer break. But, of course, it may be wrong. I'm not sure you can force the layer break at a specific place.

Maybe you have to ask these questions in the Burning forum. Or try the mkisofs method, integrated in PgcEdit. Mkisofs should not move the layer break. But I have not tested it with DL discs. I have an old burner... :(

2COOL

21st February 2005, 00:43

Layer breaks are explained here (http://forum.doom9.org/showthread.php?threadid=58950) by mpucoder.

mrslacker

21st February 2005, 05:56

Originally posted by 2COOL
Layer breaks are explained here (http://forum.doom9.org/showthread.php?threadid=58950) by mpucoder.
I'm going out on a limb here, but is this (http://forum.doom9.org/showthread.php?s=&postid=264006#post264006) what you were refering to? Or this (http://forum.doom9.org/showthread.php?s=&postid=351549#post351549)?

2COOL

21st February 2005, 06:03

Well, mpucoder explains layer breaks in many threads but it's in the link I provided. Just scroll down a bit. ;)

mrslacker

21st February 2005, 06:41

Aha! I can read! Didn't see that part of the first post. Now we have a veritable mpucoder reference page on layer breaks.

DiggnSaeg

21st February 2005, 07:54

Thx. all for the replies for now!

@r0lZ: About Nero and the ISO image: Good idea! I'll give it a try.

DiggnSaeg

21st February 2005, 23:51

So... Here we go:

The upper one is the ripped DVD9 without resetting the bit (removing the "layer break").
The lower one is the upper one written with Nero as ISO image.

Decide for yourself.

Why can't I see my attached image (GIF / 63,594 bytes)?

Now it's there. Strange.

r0lZ

22nd February 2005, 00:47

Seems Nere has selected another layer break. Pitty.
If you are happy with Nero, then you should remove the original layer break, and thrust Nero.
Or you may want to try another burning software.
Could you make a test with PgcEdit/mkisofs/DVDDecrypter? In that case, you have probably to set the layer break yourself. But don't blame me if it doesn't work...

2COOL

22nd February 2005, 06:59

r0lZ

In Streams attributes dialog, can we have Stream IDs displaying also? Here's what I got in IfoEdit

SDSS AC3 DTS LPCM MPEG-1 MPEG-2

00 80 88 A0 C0 C8
01 81 89 A1 C1 C9
02 82 8A A2 C2 CA
03 83 8B A3 C3 CB
04 84 8C A4 C4 CC
05 85 8D A5 C5 CD
06 86 8E A6 C6 CE
07 87 8F A7 C7 CF

r0lZ

22nd February 2005, 09:58

Not now. The streams attributes displayed in PgcEdit are retrieved from the VMGM_MAT/VTSI_MAT table. The stream ID is not included in this table. And, apparently, the IDs are not included in the IFOs.

BTW, where did you got this table?
Are you sure the streams IDs are always sorted in the same order?
And what are the streams IDs for, say, an AC3 and a DTS? 80 and 88 or 80 and 89?
Are you sure the stream IDs are renumbered after a stream strip?

If you are sure the streams must be always in the same order, then it should be possible to calculate the stream ID from scratch, and display it.

Maybe someone here can confirm this. Thanks.

jsoto

22nd February 2005, 11:31

I believe 2COOL is wrong in SDSS...BTW which code is this? I know a Sony "special" DTS but I was convinced it is just semantics, and it can be considered as a "normal" DTS.

But all the rest is OK. The audio number is this index & 0x7, so,

"Are you sure the streams IDs are always sorted in the same order?"
--> Yes.

"And what are the streams IDs for, say, an AC3 and a DTS? 80 and 88 or 80 and 89?"
--> 0x80 and 0x89. And if there is an additional LPCM track, it should be 0xA2 (or higher).

"Are you sure the stream IDs are renumbered after a stream strip?"
--> No. I believe they aren't. (in IFOEdit)

NOTE:
"normal mono/stereo" or "multichannel" MPeg-2 is also 0xc0 to 0xc7.
Mpeg-2 Extension (something really rare, I've never see it in a DVD) is 0xc8 to 0xcf.

jsoto

r0lZ

22nd February 2005, 12:14

Thanks for the clarification, jsoto!

Originally posted by jsoto
NOTE:
"normal mono/stereo" or "multichannel" MPeg-2 is also 0xc0 to 0xc7.
Mpeg-2 Extension (something really rare, I've never see it in a DVD) is 0xc8 to 0xcf. So, when the stream type is MPEG-1 or MPEG-2, I should use the codes 0xC0 to 0xC7? I believe that a 'standard' MPEG-2 has a value 2, like MPEG-1, in the Audio attributes field (bits 7 to 5 of byte 0)?
So how could I know if the type is MPEG-1 or MPEG-2 (standard)?

jsoto

22nd February 2005, 12:25

Originally posted by r0lZ
So, when the stream type is MPEG-1 or MPEG-2, I should use the codes 0xC0 to 0xC7?Yes
I believe that a 'standard' MPEG-2 has a value 2, like MPEG-1, in the Audio attributes field (bits 7 to 5 of byte 0)?
So how could I know if the type is MPEG-1 or MPEG-2 (standard)? [/B] Yes, a standard MPEG-2 has a value 2. And, AFAIK, the only way to distinguish between mpeg-1 and mpeg-2 is looking inside the VOB. And, do not ask how to distinguish between mpeg-2 stereo and mpeg2-multichannel., you need to parse completely the mpeg-2 frame!!. (or trust the number of channels in the IFO...)
jsoto

mpucoder

22nd February 2005, 20:56

Isn't this fun? ISO 13818-3 (mpeg-2 audio) is not a whole new way of doing audio, but defines 2 ways to extend mpeg-1. One is the lower bitrates for streaming low quality audio (eg audio chat), and the other is the multichannel extension.

As far as I know the low bitrate is not allowed in DVD, although Scenarist 2.x accepts it as mpeg-2 but gets the bitrate wrong. Low bitrate audio has an mpeg header with the thirteenth bit clear (1111 1111 1111 0xxx).

The multichannel extension follows the mpeg-1 stereo data in the "ancillary data" area, so it is ignored by mpeg-1 decoders. Both mpeg-1 and mpeg-1 with MC extension begin with 1111 1111 1111 1xxx (for DVD xxx = 100). And both are called mpeg-1 audio (coding type 2, stream 0xc0 to 0xc7). The code in Muxman to skip the stereo data and read the multichannel extension to determine the channel count is longer than the mpeg-2 I frame encoder!

ISO 13818-3 also defines a way to carry the multichannel extension as a seperate stream. If placed on a DVD it uses stream 0xD0 to 0xD7 (according to the Philips verifier) and is coding type 3. Its header is 0111 1111 1111 0xxx, and its windows extension is .ext There are samples at http://www.mpeg2.de/audio/extensio/ along with their stereo main channel counterparts at http://www.mpeg2.de/audio/streams/

Also, according to Philips, SDDS is placed in substream 0x90 to 0x97. That information was not available when IfoEdit was written. Also substreams 0x60 to 0x7f are reserved for extended subpictures (whatever they are).

2COOL

22nd February 2005, 21:06

so, you are saying this is how it supposed to be laid out?

SDSS AC3 DTS LPCM MPEG-1 MPEG-2

90 80 88 A0 C0 D0
91 81 89 A1 C1 D1
92 82 8A A2 C2 D2
93 83 8B A3 C3 D3
94 84 8C A4 C4 D4
95 85 8D A5 C5 D5
96 86 8E A6 C6 D6
97 87 8F A7 C7 D7

If I do a SetSTN command with MPEG-2 audio (C8), would it work?

r0lZ

22nd February 2005, 21:11

Thanks mpucoder!

Also, according to Philips, SDDS is placed in substream 0x90 to 0x97. That information was not available when IfoEdit was written. Also substreams 0x60 to 0x7f are reserved for extended subpictures (whatever they are).And what is the code in the IFO Streams Attributes field? SDDS is not mentionned on your site. (Or am I wrong?)

mpucoder

22nd February 2005, 21:12

You don't use stream/substream numbers in a SetSTN command, just the track (0 to 7) number. The stream it then selects is determined by PGC_AST_CTL in the PGC.

2COOL

22nd February 2005, 21:16

Originally posted by mpucoder
You don't use stream/substream numbers in a SetSTN command, just the track (0 to 7) number. The stream it then selects is determined by PGC_AST_CTL in the PGC. You're right. I had a brief memory dump. :( But, is the updated table correct now?

mpucoder

22nd February 2005, 21:18

@Rolz - you mean the coding mode? I don't know, it's not mentioned. And, true, no mention of SDDS on the site, the only info I have is its substream number. No header info, frame rates and sizes, coding mode, sync byte, etc.

mpucoder

22nd February 2005, 21:20

@2COOL - looks right. I doubt anyone will ever see SDDS or mpeg-2 "simulcast" (although I still intend to try it sometime since my player DOES play multichannel).

2COOL

22nd February 2005, 21:23

Thank you mpucoder! BTW, to whoever wants to know what SDDS audio is...

SDDS (Sony Dynamic Digital Sound)

A multi channel audio format containing up to 8 discrete sound channels and capable of a high data rate in excess of 1280 kbps. SDDS is available only in cinemas and Sony currently has no plans to make it available for home use.

Here's more info on it (http://www.soundnow.com/formats.htm?sdds).

Sorry for the hijack r0lZ!

r0lZ

23rd February 2005, 00:43

Thanks mpucoder and 2COOL. Now, I see the picture.

Surf

23rd February 2005, 00:58

Master r0lZ,

after 4 pages of this thread, I still can't determine as to what I can do with BOV thingy....:o

Uncover the hidden buttons?

I have not been successful in blocking the buttons in this situation:

A motion menu with 3 cells, the 1st one without the buttons and the remaining two with. Menuedit only shows one of the 2nd or 3rd cell buttons, not both....

r0lZ

23rd February 2005, 01:19

Originally posted by Surf
Master r0lZ,

after 4 pages of this thread, I still can't determine as to what I can do with BOV thingy....:o

Uncover the hidden buttons?Well, the BOV support was needed for a while. For now, it's not possible to edit them. This is the next step.
But you may already see them, and the trace mode should be able to follow the navigation of all the DVDs now, including when the menus are authored in BOVs.

I have not been successful in blocking the buttons in this situation:

A motion menu with 3 cells, the 1st one without the buttons and the remaining two with. Menuedit only shows one of the 2nd or 3rd cell buttons, not both.... I don't understand. What do you mean by 'blocking'?

Seems there are sometimes some problems with Menuedit. I don't know for sure, because I've never had problems here.
Maybe you should verify the menu buttons definitions with VobEdit.
You can see the first LBA (aka sector) of the Nav Pack where the buttons are defined in the button editor. This is not necessary the first LBA of the cell. There is a tooltip on the topmost button of the menu editor. Note the LBA number, open VobEdit, go to the LBA, enable the 'buttons' checkbox, and examine the 'number of buttons' value.
If you find that PgcEdit doesn't work as expected, please report the problem here. After all, it's still a beta! Thanks.

blutach

23rd February 2005, 03:58

Originally posted by Surf
I have not been successful in blocking the buttons in this situation:

A motion menu with 3 cells, the 1st one without the buttons and the remaining two with. Menuedit only shows one of the 2nd or 3rd cell buttons, not both.... Menuedit won't show anything (other than the frame via the slider) in the transition cell 1, it's just a bit of video.

Cells 2 and 3 with buttons should both be selectable and editable in Menuedit.

If not, perhaps you should PM Dimad.

Regards