PgcEdit v7 discussion thread

[r0lZ]

Given that the Non-Resume-Play (Stop/Stop/Play) on Sony's DVD players skips the FirstPlay PGC and goes directly to playing Title-1, what changes could I make in the PGC's code to accomplish:

1) Displaying the Menu when a disc is 1st inserted (it already does this now via the FirstPlay PGC)
2) Displaying the Menu from a Non-Resume-Play (Stop/Stop/Play)
3) *NOT* displaying the Menu if I jump directly to Title-1 via Sony's "Direct_Play_Disc/Title/Chapter" feature via my HTPC's serial control cmd.

Hum, difficult to imagine what to do without knowing exactly which PGC the player plays first after a non-resume-stop, and if the GPRMs are reset to 0.

The basic method to deal with this kind of situation is to insert a GPRM test at the beginning of the title 1 PGC, to jump to the menu or play the title. The easiest way is to do something like that (assuming GPRM 15 is never initialized in the DVD):

********** Title 1 pre commands:
1 if ( gprm(15) > 0 ) then { Goto line 4 }
2 Set gprm(15) =(mov) 1
3 (CallSS) Call the VTSM Root menu of the current VTS, resume cell 1
4 NOP // continues with normal playback of Title 1

Then, jump directly to title 1 from FP-PGC.
It's simple, but that doesn't work for your point 3, since all GPRMs are forced to 0 when a title is called directly with the remote. Not sure it works for point 2 neither, since I don't know if a non-rsm-stop forces the GPRMs to 0.

But you can invert the test by initializing the free GPRM to any non-zero value in FP-PGC, and jump to title 1. Works fine for point 3. Again, I don't know for the non-rsm-stop situation.

[Surgeon]

Yeah, that's the problem with not knowing exactly what Sony's N-R-P actually does with the registers... (I've also tested on both an Apex and a Cyberhome model I own and they do the same skipping of the FirstPlay PGC when you do a N-R-P.)

Does anyone have, or know of, a "testing" disc that could be played on a machine and show what the registers are while playing? I know I've got a disc, written by someone, that shows the player's region-code settings when played, but haven't found one that will show all the registers...

-Surgeon-

[blutach]

@ron spencer

Yes, of course. v7.3 produces compliant ISOs which ImgBurn (www.imgburn.com) can burn. But you may like to work with ImgBurn (www.imgburn.com) alone now that its build function is fully operational.

Regards

[r0lZ]

Does anyone have, or know of, a "testing" disc that could be played on a machine and show what the registers are while playing?I did one some time ago. You have to merge your own DVD structure to create the right conditions for the test, and call a PGC that will show on screen the content of a specific register in hexadecimal.
If you are interested, here it is: Test_GPRM.zip (http://www.videohelp.com/~r0lZ/pgcedit/third_party/r0lz/Test_GPRM.zip)
In the archive, the FP-PGC is programmed to call the function to display the contents of SPRM 0. It is copied in GPRM 15, and PGC 3 of the VMGM is called to display the content of GPRM 15.
Note that the four hexadecimal digits of the value are displayed sequentially. (I was too lazy to create manually 65536 video frames with a different number in each! ;) )

But to check if the GPRMs are reset to 0 after a specific action, we don't need to know exactly the value of the register. It is enough to branch to PGC-A if the reg is zero, or PGC-B otherwise, and display something different in each cases. The problem with the non-rsm-play, is that we don't know neither where the navigation will be restarted, and therefore we don't know in which PGC the test must be inserted.

[r0lZ]

Well, I was totally wrong. I've made a test-DVD to test the "non-resume-play" function on my Sony, and the result is not what I thought. You were right, Surgeon.

When a title is called directly with the remote, all GPRMs are cleared, and a direct jump to the pre-command of the title is executed.

When an Exit command is encountered, the playback stops. If the user press Play at this time, the same thing happens, except that it is always Title 1 that is called. (I have verified: it's really Title 1, not the first TTN of the first VTS.) The pre-commands of title 1 are executed too.

Pressing twice the stop button (the "non-resume-stop") acts exactly like if an Exit command was encountered. Pressing play resumes also to the pre-commands of Title 1, with the GPRMs clear.

I'm still not sure the SPRMs are cleared also, but I suppose so.

In summary, the FP-PGC is automatically called ONLY when the DVD is physically inserted in the drive (and the FP-PGC exists.) In all other situations, when the DVD is restarted, the GPRMs are forced to 0 and the navigation begins at the pre-commands of Title 1.

This means that it is not possible to distinguish between a title call with the remote or a play after a non-resume-stop or after an Exit command.
Also, in my example in post #351 (http://forum.doom9.org/showpost.php?p=859903&postcount=351), the menu is called after a non-resume-play. To play the title instead, it is necessary to invert the test in line 1 and to initialize the GPRM to a non-zero value in FP-PGC.

[Surgeon]

Could you possibly repeat that part about me being right one more time??? I'd like my wife to see it... She's got her entire circle of friends & family convinced I never am... :D :D :D

Like I stated previously, I see the same behavior on both my Apex and CyberHome players also... That's why I felt it must have been a documented behavior somewhere in the dvd specs...

If nothing else, it may be a special functionality you might want to implement in a future release of PgcEdit's trace mode...

----------

BTW: I've done a little testing and it looks like those changes you made to the DvdTitle stuff work great! THANKS!

-Surgeon-

[r0lZ]

:cool: You were perfectly right, indeed! :goodpost: :D

If nothing else, it may be a special functionality you might want to implement in a future release of PgcEdit's trace mode...I'll do.
In the meantime, you can simulate the non-resume-play simply: click on the eject/insert button to reset the GPRMs and SPRMs, but before launching the trace, click on the Title 1 PGC. This way, you will begin the navigation at the right place, with the GPRMs cleared, and the SPRMs initialized to the default values.

I have just checked with my Sony if the SPRMs are reset or preserved in this situation, and I can confirm that they are forced back to the default values. (That means, among other things, that the audio and subpic selections are lost when the Title 1 is called by a non-rsm-play.)

[voo_doo99]

Hi r0lZ,
Will PgcEdit adds features to support new ImgBurn 2.0 BUILD mode, including passing DVD-TEXT field as volume label? :D Thanks.

[r0lZ]

Well, I'm not sure.

I like the burn mode of ImgBurn, but I think PgcEdit is not needed to launch it. The burn function of PgcEdit was necessary because there was no good app to burn a DVD-Video at this time, and it was necessary to prepare the IFOs before calling mkisofs, but now ImgBurn has integrated the whole process.
I don't want to continue to develop this part of the program, now almost useless. Also, it is not easy to integrate the new build mode in the burn function, because everything is designed to work with mkisofs. Calling ImgBurn is not the difficult part.

However, I may add a new CLI option in the Tools configuration dialog to pass the DVD-Text general name field to the called program. This way, you should be able to call ImgBurn in build mode, with the right parameters. Is it OK for you?

[voo_doo99]

Well, I'm not sure.
However, I may add a new CLI option in the Tools configuration dialog to pass the DVD-Text general name field to the called program. This way, you should be able to call ImgBurn in build mode, with the right parameters. Is it OK for you?
Yes, it is what I am asking. :thanks:

[r0lZ]

It's already done.

Works well, but unfortunately, there is a little problem in ImgBurn v2.0.0.0.
If the original DVD-Text General Name is passed via CLI, it is used as it is for the UDF file system, and that's OK.
But the same string is simply converted to upper case and truncated to 32 characters for the ISO file system. This means that an illegal character (such as a space or a punctuation sign) is not removed or converted to an underscore, and the resulting string is still illegal.
I have therefore added 2 options to pass the DVD-Text General Name as a CLI argument: %t is the original, unmodified string, possibly with lower case characters, and %l (letter L) is the string used to generate the ISO filename and the default volume label in PgcEdit, converted to upper case and stripped of the illegal characters by PgcEdit.
Since ImgBurn has only one CLI argument to specify the labels for all file systems, you have to use %l to be sure the label is legal for both file systems.
I've contacted LUK! The next version of ImgBurn will have a better conversion routine, and you should be able to pass the original label with %t.

Also, if the DVD-Text General Name is not specified, %t and %l are currently derived from the DVD folder name. For example, if your DVD files are in C:\rip\My DVD\VIDEO_TS, %t will be "My DVD" and %l will be "MY_DVD".

I have also tried the /IBG option with /IBG "C:\%l.ibg", and the graph data file is correctly saved automatically under a name that is easy to identify. Nice!

[dirio49]

Great, thanks:)

[blutach]

Unnecessary to do anything in parsing the DVDTX name to ImgBurn (www.imgburn.com). The update to version 2.0.0.0, to be released very shortly, will automatically do this by default.

I tested this extensively today and it worked, irrespective of the complexity of the VMG_TXTDT_MG table.

Save yourself the effort r0lZ.

Regards

[Jeffster]

@blutach
Will the updated version auto generate the iso filename as well as filling in the volume label?

[blutach]

LOL, no but you can pick any one out the MRU list. For example, I build test ISOs and just call them xxx.iso

Next one I build, I just select xxx.iso. I have the delete ISO/MDS after successful burn option set, so it is easy to name. Or if I haven't deleted it yet, it will overwrite without hassle.

If you wish to retain the ISO (perhaps you have lots of hard drive capacity), then by all means name it something meaningful. Or use an IBB project file.

And the volume label auto fillin works very well with proper capitalisation and spacing. If, on the other hand, you want to fill in the label yourself, it's best to start in the UDF field and you will be able to push a little icon to fill in the ISO/Joliet ones.

Regards

[r0lZ]

Unnecessary to do anything in parsing the DVDTX name to ImgBurn (www.imgburn.com). The update to version 2.0.0.0, to be released very shortly, will automatically do this by default.Yes? Good news.
I've read somewhere that the new version will be able to retrieve the DVD name from the folder name, but not from the DVD-Text data. Seems LUK! has changed his mind. Good!

Anyway, I've already added the code to provide the %t and %l substitution in the arguments field of the PgcEdit tools. It might be useful, for example to pass the ISO filename, and anyway, it was very easy to do.

[blutach]

Good to see!

Is there a new beta due out soon? With that and the SPRM 20 fix?

Regards

[r0lZ]

I don't think a beta is needed. I've only fixed some easy things, and I'm sure I haven't introduced new bugs. Also, I am currently on holidays, and I don't want to have to work much!
However, if you really need a new version, send me a PM or a mail...

[Sir Didymus]

While using PgcEdit for exporting the PGC color palette, in ascii format, of a movie authored with MuxMan, I noticed some rounding errors in the color values (for example Color 1 below should be 255, 0, 0):


Color 0=0, 0, 255
Color 1=254, 0, 0
Color 2=0, 0, 0
Color 3=255, 255, 255
Color 4=0, 254, 0
Color 5=255, 0, 254
Color 6=255, 255, 0
Color 7=1, 124, 124
Color 8=125, 125, 125
Color 9=225, 225, 225
Color 10=123, 0, 1
Color 11=0, 124, 0
Color 12=1, 0, 123
Color 13=222, 1, 253
Color 14=221, 125, 1
Color 15=125, 0, 124


Of course it's a kind of problems not urgent at all, and I am not totally sure the issue is inside PgcEdit or MuxMan... Anyway the palette above is not the same as it should be (the Scenarist default...)...

All the best,
SD

[r0lZ]

There are several formulas to convert the CLUT to RGB. None are perfect, but I'm not sure I've used the best one. Do you have a suggestion?

[Sir Didymus]

No, afraid, I have not...

But your question enlightned the source of my troubles: I simply forget the colour format of entries in the CLUT is (YCrCb). For some reason I - wrongly - reminded the format should have been RGB...

It's evident the rounding error is introduced by the color space conversion. I say again, I don't know if a discrete formula exist to map 24 bit (RGB) --> to (YCrCb) back to --> (RGB) without introducing rounding errors for all of the possible RGB entries...

:(

SD

[r0lZ]

That's what I thought. Anyway, a small rounding error has no visible consequence on the subpics.

[Surgeon]

Wadda' ya mean small... In the conversion shown above you've got a color shift of a full 1/16,777,216 for the affected pixels!

I would think even a blind man would notice that... :D :D :D

(Just kidding, of course...)

-Surgeon-

[Sir Didymus]

No person would see the difference, but a computer program definitely (and easily) would. If you write an sst subpicture definition file with statements like this:


BG (0 0 0 = = =)
PA (255 255 255 = = =)
E1 (255 0 0 = = =)
E2 (128 128 128 = = =)


You assume, in the bitmap files containing the pictures, a precise match of a pure red color to the E1 index. If you miss the match by 1/16,777,216 you lose the whole colour content from your DVD subtitles.

It's just an example, showing that sometimes a single bit out of 24 is important... :)

Anyway, I admit the issue I raised is not an issue at all, since it was originated by a mistake from my side (I did not remind the storage format of the CLUT palette in the PGC) so - again - afraid for the above message I posted.

Cheers
SD

[Surgeon]

Yeah, I know what you mean... I know it would be a big effort for such a tiny conversion discrepancy, but what may work is for r0lZ to post-apply a "fudge-factor" table to the calculated results. That is, to always "fudge" the more commonly used values like 255 instead of 254, 128 instead of 129, 0 instead of 1, etc... Kinda a pita to have to code it that way though...

-Surgeon-

[frank]

There is a little bug in the function Call Cross references.
In every case the pre/Post commands will be deleted if there is no access (red color) from commands.
But the menu button of the remote control will jump to this point.
TitleM commands should never be changed.

[r0lZ]

Hum, I can't reproduce that. I have just tested with a TitleM w/o direct calls, and the pre/post commands are not deleted.
Could you give me more info? What DVD is it? Which version of PgcEdit did you use?

[bigotti5]

Pgcedit show this if no command link to a root or title menu

Callable with remote control TitleMenu button.

Callable with remote control RootMenu button.

[frank]

Sorry for my late answer.

The DVD is Antarctica.
But now I have taken a look closer. The TitleM was not referenced but there were PUOs.

In Call Cross references was the message:
NOT callable with remote control TitleMenu button due to PUOs!

All right, rOlZ. :D
A very improbable case.
But a little info in the label text column would be very useful.

[r0lZ]

It's not so improbable. It's something I've seen often, though I don't understand why the Title Menu is defined if it can never be called with the remote, since it is possible to call the same PGC with a JumpSS/CallSS by PGC number. Doing this trick in a VTSM domain is more comprehensible.

BTW, I forgot completely that I've taken the PUOs into account for this function! PgcEdit is better than I thought! :p

[Video Dude]

Thanks for the seamless option for burning DL discs. All the DVDs I have done have played with no pause at the layerbreak, even though they had a high mux rate. Works on all my DVD players.

:thanks:

[r0lZ]

Good to know. Thanks for the info.

[pygmalion]

Hello!

EditPGC enables changing the action of NEXT and PREV buttons on remote controller while in menus. Does it also eanble changing the action of PLAY button and how?

Thanks for the answer,

Marko

[bigotti5]

These buttons are hardwired by the manufacturer.
You cant change the action of PREV and NEXT button - you can define a PrevPGC/NextPGC and taking advantage of the action
The PLAY button on most players does the same thing as the
ENTER key when in a menu, but maybe there are players setting a title play command if you press PLAY.

Edit: You should respect forum rule #8 - no crossposting

[r0lZ]

I have replied almost the same thing in this thread (http://forum.doom9.org/showthread.php?p=871214#post871214).
BTW, pygmalion, please observe rule 8 (http://forum.doom9.org/forum-rules.htm).

[pygmalion]

r0lZ: I apologise. I thought this is not quite the same question.

But then, I have another question. Can you control with PGCEdit, which button is activated by default? Usually, this is button 1, but I rather see to be let's say button 7.

Marko

[bigotti5]

Can you control with PGCEdit, which button is activated by default?

Do you mean "which button is selected by default"?

[pygmalion]

At the start of menu, one button is already enlighted. So if you only press OK, you will start whatever this button stands for.

[blutach]

Yes, you can control it. You will need to program the precommand to higlight button #. And ensure no button in the menu is force highlighted.

Regards

[r0lZ]

Well, both methods are possible.

You can program the highlighted buttons with a SetHL_BTN command. In this case, the force select button parameter must be 0. With this method, it is possible to highlight a different button each time the PGC is entered, for example to automatically select the next episode, but this method requires some knowledge.

You can also use the force select button parameter in the menu itself. It has precedence over the VM commands. It's very simple to do, but the same button will be highlighted by default each time the menu is entered, as this parameter cannot be programmed dynamically.

[pygmalion]

Thanks guys for the reply. I will try that and I hope I will not have to bother you again.

Marko

[architect]

How about getting it to work under wine in linux? we can't makw pls2 files under linux without it.

[blutach]

PgcEdit (http://www.videohelp.com/~r0lZ/pgcedit/index.html) DOES work under Linux

http://www.videohelp.com/~r0lZ/pgcedit/index.html#download

As for the PSL2 plugin, r0lZ did not author that. Somoeone calling himself The Mad Monk did.

Regards

[r0lZ]

PgcEdit v7.4 released: A. New function Info -> Find Never-Called PGCs, to mark the PGCs and VTSs that are never called explicitely (without having to clear the VM commands and Prev/Next/GoUp PGCNs).
A. New function Trace menu -> State -> Restart Playback from Exit Domain, to begin the playback at Title 1 instead of at the First-Play PGC.
A. New Option -> Functions -> DVD-TEXT General Name to set the max length of the Volume General Name string, since the number of characters that can be displayed on screen is player dependent.
A. Added "%t" and "%l" substitutions in the command line string of the Tools Setup dialog to be able to pass the DVD-Text General Name (%t) and the default DVD label of the burn function (%l) as arguments. Calling ImgBurn with the volume label already in place is now possible with the arguments: /MODE ISOBUILD /BUILDMODE DEVICE /FILESYSTEM "ISO9660 + UDF" /SRC "%d" /VOLUMELABEL "%l" /NOIMAGEDETAILS /ERASE /VERIFY /IBG "C:\%l.ibg"
E. When a PGC or a cell is never called directly by a VM command or by a Prev Next or GoUpPGCN link, it was previously considered as unreferenced, even if it was referenced in some IFO tables. Now, in this situation, the word "unreferenced" has been replaced by "never-called" to avoid the confusion with truely unreferenced cells (which are never referenced in the IFOs.)
E. Rebuild Time Map functions: the cell times and the PGC playback time are now updated also in the VTS_PGCITI table. Therefore, after using this function, the times shown in the PGC Editor should be accurate.
E. Create New Cell and Reassign VOB/Cell ID: New option to rebuild the time map tables. It is now possible to skip the Time Map creation. Useful to speed up things when using those function several times.
E. The error message "Can't create backup" is not displayed any more when the DVD is loaded from the DVD drive, and is therefore read-only.
E. Improved Read DVD functions, to cope with some severe authoring errors.
E. Added a note in the Check DVD-R Size dialog to warn the user that this function ignores the DVD-ROM files in the computation of the DVD size.
F. Trace mode: SPRM 20 (Player region code) was wrongly initialized with the region code value of VMGM_MAT instead of a bitwise XOR of this value.
F. Trace mode: In case of arithmetic overflow in Set operations, the result was rounded to 0 or 0xFFFF. Now, the right value, not rounded, is used.
F. PGC Editor -> remap VOB/Cell ID did not work on a menu PGC if the VOB file was not successfully scanned for menu buttons when the DVD was opened, for example because the menu VOB file was not present or was CSS encrypted. Similarly, Remove Cell did not update the PGC playback time.
F. When a menu PGC was killed and the video removed, the audio and subpic attributes were not cleared in the PGC.
F. Kill playback: a warning was sometimes issued when it was not needed.
F. Little bug fixed when PgcEdit was called with an invalid path as CLI arg.


DVDShrink plugin updated to v2.1: F. Bug in DVDShrink Remote Buttons's Always allow the 'Title Menu' button to skip to the next title? function fixed. The Title button was ineffective in some cases.

New VOBU plugin: With this plugin, you can change the entry VOBU sector and the last VOBU sectors of any PGC.
Handy to skip intros, logos or credits embedded in the main movie.
Please note that this method is not standard compliant, and may fail with some players!

Enjoy!

[Rippraff]

Thanks a lot for the new version, r0lZ! :) :thanks:

Cu Rippraff

[[Tobi]]

The new version looks robust and speaks once again for the abilities of the author.

:thanks:

[r0lZ]

Thanks Tobi, Rippraff and everybody! :)

[dirio49]

Thanks for the new Version. :)

[David Star]

¡¡Congratulations, Roiz!!. Thank you very much for giving us your powerful program as a present. ¿Some day Pgcedit will work hd-dvd?

[r0lZ]

¿Some day Pgcedit will work hd-dvd?I don't think so. I don't like too much those new formats. IMO, it's mainly commercial business.
Anyway, currently there is still too few technical info to be able to do something. Maybe later...