PgcEdit v8.6 released (January 12, 2008)

[r0lZ]

Strange. I'm unable to reproduce the problem. I have renamed one of the sound files, and of course it is not played any more, but the default bell is played instead (and playing the default bell works always.)
Furthermore, I have verified my code, and I check if the sound file exists before launching its playback.
However, in the registry, the files names contain ofter substitution variables (enclosed between % characters) that must be substituted to build the path. Maybe there is a bug occurring in some circumstances here. Can you confirm that there are % substitutions in the path names stored in the registry of your PL system? Can you copy here one of the filenames (as they are stored in the registry) that caused the problem?

[M_Knox]

In HKEY_CURRENT_USER\AppEvents\Schemes\Apps\.Default\SystemAsterisk key, both .Default and .Current subkeys contain %SystemRoot%\media\Windows XP Error.wav (and both are of REG_EXPAND_SZ type). However, the file on disk is "C:\WINDOWS\Media\Windows XP - Błąd.wav", and when I copied it under the "Windows XP Error.wav" name, all went okay.

As I said, I have no idea why it is so - I mean registry entries pointing to nonexistant files.

Additional info:
I did a little bit of testing on Windows 2000 and Windows XP, and found out the following:

1. It happens only on Windows XP
2. On Windows XP the application tries to play the "SystemAsterisk" sound only (falling into some endless loop when the sound is not found)
3. On Windows 2000, when the "SystemAsterisk" is not available, the application resorts to the ".Default" sound if available, otherwise it does not play any sound and does not hang.

(I checked only the Info dialog, but I assume other dialogs will behave the same).

There must be something. From the ProcessMonitor log I read, that the application first tries to open C:\WINDOWS, then C:\WINDOWS\Media (both operations successfull). Then it tries TWO TIMES to open the nonexistant sound file (these operations fail), and finally the application tries to open the C:\BOURNE_IDENTITY\VIDEO_TS folder (the one I started it from). Then it starts all over again - C:\WINDOWS, C:\WINDOWS\Media, sound files, VIDEO_TS folder, C:\WINDOWS, ...

[r0lZ]

Hum, really strange. Especially as I have XP, and no problem. Thanks anyway.

You have confirmed that a variable is used. %SystemRoot% expands usually to C:\WINDOWS. This is why that directory is opened first. Then the complete path is built, and C:\WINDOWS\media is opened, and the file is checked. If it is not found, several default locations are checked also:
%SystemRoot%\media
%windir%\media
%HOMEDRIVE%\Windows\media
%SYSTEMDRIVE%\Windows\media
C:\Windows\Media
and finally, the default path of the media folder is retrieved from the registry (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\MediaPath)

Most of those paths expands to the same location, so it is normal, if the sound file doesn't exists, that the same path is checked several times, but, of course, not indefinitely.

Note also that the snack library is used to play the sound normally associated with the current level of the dialog box (info, question, warning or error.) If the sound file doesn't exist, or if snack cannot play it, the default bell (that doesn't use the snack library) is played instead. If the bug is in the way the bell command is implemented in Tcl/Tk, I have no way to fix it. However, I don't think so, because you should have the same problem elsewhere in the program, as the bell is often used.

SystemAsterisk is used for the info dialog. The other sounds used by PgcEdit are SystemQuestion (question), SystemExclamation (warning) and SystemHand (error). The sound stored under HKEY_CURRENT_USER\AppEvents\Schemes\Apps\.Default\.Default\.Current is probably used by the default bell. On my system, it is "%SystemRoot%\media\Windows XP Ding.wav".

I will try to clone exactly your installation, and check again...

[mikenadia]

The movie is Hairspray. Processed the ripped DVD with PGCEdit (did not do anything special: Parental management,uncalled PGCs...), run "ReBuild all timemaps". Everything OK (no warning...).Load in VOBblanker without processing. Everything OK (did not get the ILVU message).
Run DVD-RB 98.2 . Rebuild timemaps in PGCEdit (first time I was doing that after reencoding) and got the following warning

Dialog title: "PgcEdit: Rebuild Time Map"
Dialog type: warning
Dialog message:
WARNING: There is a discrepency in the VOBU End Presentation Time
of the nav pack at LBA 370631 (sector 370631 in VTS_01_1.VOB.)
The VOBU End Presentation Time value is less than the previous one:
110835957 < 110835957 !

I cannot compute the cell time of cell 4 of VTS 1, PGC 1!

If you have removed the Angles or the ILV information of the title,
this message is normal and you can freely answer "No to All".
Don't forget to process the domain with VobBlanker!

(This discrepancy can also be caused by VobBlanker if you have
replaced a single cell by several cells with different VOB IDs.)

Abort the rebuild of the time maps of VTS 1? (recommended)
Dialog buttons: [No to All] [Yes] [No]

I did not replace a single cell by several cells with different VOB IDs and I did not remove the Angles or the ILV information of the title (I checked : There is an AngleM but did not even get close to it). I loaded in VOBlanker (No ILVU message and no space to regain).
I would like not to lose the ILVU (if there is one. BTW, how can I check it?: Is it the AngleM?)
I redid the whole process twice (with the same movie) and can redo the same procedure with another movie if you wish so.
Thx

[M_Knox]

Yeah, I agree this is strange. As to Windows XP, I checked it on two computers, both running WinXP Professional PL, and both produce the same error (hang if sound file unavailable).

Anyway, I've got something else for you, regarding the "GPRM Labels Editor and Usage Count". Sometimes, when you click the usage count button, and the "Found gprm ... in DVD" window pops up, the usage count on the button does not match with the one in the popup caption. As an example I can send you an archive (500KB) containg a DVD, that:

1. the Label Editor shows a "75" as the usage count of GPRM 11

2. after pressing the usage count button on the dialog, the popup windows says "Found gprm\(11:[)] 82 times in DVD"

3. when manually counted, the occurences of gprm(11) in the popup add up to a total of 85 (3 command with "if" using gprm(11))

[blutach]

@M_Knox

This is a cunning one. It counts lines and usage separately.

Eg. Take a stupid looking command:

[61 50 0B 0B 00 0B 00 0B] 1 if ( gprm(11) > gprm(11) ) then { Set gprm(11) =(mov) gprm(11) }

Here the usage count is 4 but it will find it only once.


@mikenadia

You can tell if a title is interleaved or has angles. Double click it to bring up the PGC editor. Check the flags to interleave (interleaved allocation = bit 2 set) and the First ILVU End Sector (if no interleaving, all will be 0). It has nothing to do with the Angle Menu.

If VobBlanker doesn't report interleaving is present, there is none. Something's not quite right with the VOB.


Regards

[r0lZ]

OK, I've found and fixed the sound bug. What's really strange is that it happened only when both the default bell AND the Asterisk were not present. In this case, an infinite loop occurred.

For the GPRM count, I'm aware of a discrepancy. The usage count is obtained by counting the occurrences of the string "GPRM(X)" in the text of the VM commands. Therefore, if the same GPRM is used twice in the same command, it is counted twice also. But when the commands containing the GPRM are displayed, the command is present only once in the list. Hence the difference.

Another problem can happen when there are VOB cells with buttons or BOVs using the GPRM, but that cells are unreferenced. When PgcEdit checks the VOB files for menu buttons, it scans the whole file, including the unreferenced cells. Therefore, the number of occurences is sometimes increased by some commands that are not really a part of the DVD. Of course, stripping the unreferenced cells out of the VOBs fixes that problem.

Anyway, in your example, the label editor should display 85 (or more), and not 75. So, yes, please send me your test DVD. There might be another bug as well...

[Blu was faster than me, again!]

[r0lZ]

@mikenadia:

Funny, I have had exactly the same warning yesterday, but with a RipGuard protected DVD. The problem was, of course, in a protected cell.

I'm not sure if the problem was already present in the original DVD. If it's the case, and if that DVD is protected, you can try to remove the cell. But according to what you did, I suspect a bug in DVD-RB. Anyway, you can check easily if the problem was already present in the original DVD. Please let us know.

[M_Knox]

@blutach:

I figured it out already, but I'd expect the button show a higher value than the popup caption, which is not in my case (b:75, c:82), and that's why I pointed it out.

@r0lZ:
E-mail sent.

And here's another one for you: as the AND, OR and XOR are bit operations, I'd like to see them in the hex notation, not in decimal. For example:

Set gprm(0) &=(and) 65280 (0xFF00)

or even

Set gprm(0) &=(and) 0xFF00

or something similar (whatever the hex numbers look like in Tcl/Tk). And yes, I know I can enable hex-codes display, but displaying the values as hex would increase readability, in my opinion.

[r0lZ]

Nice suggestion, but difficult to implement, as the same code is used to display all integers, no matter which operand is used. And showing the additional hex value always is probably even more confusing. But I will see what I can do.

Thanks for the mail.

[r0lZ]

M_Knox, I've analysed your test DVD. Again, it's not really a bug. The difference is caused by the fact that some cells with buttons are reused often. When PgcEdit counts the occurrences of each gprm, it counts them in the buttons only once. But, again, when the result is displayed, it is sorted by PGC and cell, therefore the reused cells are displayed several times, for each PGC that references it.

In other words, the number displayed in the right column of the main Info -> GPRM window is the number of occurrences of the GPRM in the whole DVD, including in buttons of unreferenced cells, and each occurrence is counted once and only once. That means that if you want to change a GPRM to another one, you have to change that many occurrences.

In the other hand, the window displayed when you click on the button shows only the commands that are really used by the DVD, in referenced cells, and a button command of a cell that is reused in several PGCs is displayed several times. If you edit a reused button command, and then you refresh that window, you will see that the number of commands is decreased by more than one. (Furthermore, currently, when the same command is present in the same button of several groups, when you edit it, you change all groups at once. So, if a cell has two groups and is reused once, editing the command once decreases the number of commands in the list by 4. 2 groups x 2 PGCs = 4.)

That might be confusing, but IMO, it's the best way to present the results. You have the real number of occurrences, and the commands containing them. They are not the same thing.

[mikenadia]

Reripped the DVD ( "Hairspray"). Run (without going to PGCEdit) DVD-RB 98.2 with "No compression" (Phase 1 and 3 only). No problem. Rebuild timemaps ( a couple of minor changes in the timemaps but no warning).
Run (straight from the rip ) DVD-RB with "HC encoder" (phase 1 ,2 and 3). No problem during the run (no error from DVD-RB). Able to start the movie.
Went to PGC Editor and got at cell 4
Last VOBU Start :370265
Last VOBU End :370266
Rebuild timemaps (got the warning for cell 4 and unable to complete successfully the procedure).

From the rip and also after the " No compression " build, the difference between the Start and the End of the Last VOBU was more than 100.

Obviously, this will not happen with other movies but I am clueless.

[r0lZ]

What is the duration of cell 4 in the cell table of the PGC? Maybe HC Encoder is wrong when it encodes a tiny cell. Or maybe it's a slideshow cell (one single frame with audio)?

[blutach]

Why not delete that tiny cell?

Regards

[r0lZ]

Not sure it's a tiny cell! And if it is in the middle of the movie, that might be dangerous.

[mikenadia]

Playback time for cell 4 ( in PGC Editor) is 00:04:02:00 .

[r0lZ]

Not a tiny cell, then. There is probably something wrong with HC Encoder.

[mikenadia]

I am going to try with Quenc and post the results. I was using HC 022.
Thx again.

P.S. May be , this should be moved to the MPEG2 forum!

[blutach]

Let's see your results. That last VOBU looks all wrong.

How does a mock strip go?

From what I read, people had a lotta trouble ripping this movie - maybe the rip was bad.

Regards

[mikenadia]

I did a mini mock strip ( after reencoding) with FixVTS. Did not fix anything and will do it later with IFOEdit.
Thx

P.S. the rip is probably bad ( I will try to rerip it with other rippers ) but I should have got an error along the way or I should always rerun PGCEdit (rebuild timemaps...) after reencoding?

Edit: Mock Strip with IFOEdit did not fix anything.

DVD-RB (with Quenc 0.72 -VBR) is OK.
No warning for cell 4 in PGCEdit after reencoding.

Will try now with older HC versions and with HC022 and default INI ( I had Lumgain=3).