View Full Version : PgcEdit v7 discussion thread
Pages :
1
2
3
[
4]
5
6
7
8
9
10
11
12
ux-3, I'll look into it...
Thanks!
ux-3, you're right. The Kill Playback function is broken.
Will release a bugfix as soon as possible...
I just burned the first GB to DVD+RW. Stand alone skips the killed "whatever" and goes right to the clip that initialises the menu, as I wanted it. This worked with 7.0
With 7.1, I am stuck after hitting "kill PGC".
Phew... glad its not me... no need to hurry for me, I am still discovering 7.0... ;)
The bugfix is not only for you, ux-3! I know that Kill Playback is one of the most used functions of PgcEdit. It should work as expected! Anyway, PgcEdit v7.1.1 is already available. Please download it!
As discovered by ux-3, the Kill Playback function is broken in v7.1. Please update to v7.1.1!
Sorry for the trouble!
blutach
2nd June 2006, 14:01
Thanks for the quick update r0lZ and another big changelog :)
It reads v 7.0.1.1 though, is that right?
Regards
Oh, no! :( Yet another error!
I'll post v7.1.1 final immediately!
Thanks, blutach!
Jeffster
2nd June 2006, 14:10
Thanks for the new version, r0lZ :)
I have a slight problem with ISO creation in this version though. It get's to 100% and the log pop's up as usual but at the bottom of the log it says "NEQ was unexpected at this time" and the ISO file doesn't exist. :(
If it makes any difference, I'm still using the mkisofs from Image Tool, not the new faster one.
(ISO creation is successful if I step back to v7.0)
Edit:
Tried again with the new faster mkisofs and still get the same error with v 7.0.1.1
Hum, "Jamais deux sans trois!" as we say in french!
OK, it's another bug. It is fixed in v7.1.2, already available.
3 releases in one hour! I think it's my record! I hope it's the last one!
Sorry again. I stop smoking, and my brain works slowly!
Jeffster
2nd June 2006, 14:55
And as we say here, "Third time's a charm"... ;)
Thanks again for the new version, r0lZ.
LIGHTNING UK!
2nd June 2006, 17:38
Well, it's because ImgBurn needs 2,4 instead of 2.4 on european systems (where a floating point number is really a floating coma number.) Since I don't know how to test the locale settings, I kept both numbers.
If somebody can tell me how to know the numbers format, I'll change that.
Ok, basically you want to be doing something like this...
char GetDecimalSeparator(void)
{
LCID CurrentLCID;
int RetVal;
TCHAR Buffer[2];
CurrentLCID = GetThreadLocale();
RetVal = GetLocaleInfo(CurrentLCID, LOCALE_SDECIMAL, &Buffer, sizeof(Buffer));
if(RetVal > 0)
{
return (char) Buffer[0];
}
else
{
return '.';
}
}
I've not tested that code so don't blame me if it doesn't compile :p
Just run that function once at startup and use its return value to fill a global variable or something. Then refer to that variable throughout your code wherever you want to use a decimal separator.
Thanks, LUK! However, I can't use this code from Tcl/Tk. GetThreadLocale() and GetLocaleInfo() have no equivalent in Tcl. I need something to retrieve this value directly from the registry, for example. But I'll try to find a way myself. I have a good tool to compare the registry before and after a change in the user environment. It should be sufficient. Thanks again.
dirio49
2nd June 2006, 19:33
Thanks for the new version.:)
:thanks: :thanks:
ron spencer
2nd June 2006, 23:11
thanks rolz.....not sure if this has been added or not, but can you add a check to ensure that the first cell is not seamless (ie., not 8 0 but 2 0)? see posts 124 and 125
selyb
3rd June 2006, 00:28
Sorry again. I stop smoking, and my brain works slowly!
lol
around here, when someone 'smokes', their brain works slowly
Grave
3rd June 2006, 02:28
@Grave:
No, to be able to display really meaningful info on the time maps, I have to read all nav packs of the VOBs, and that's very long.
But I can add a function to display a summary of all PGCs of all VTS, with the time unit and number of entries in the map, if you wish. It's not sufficient to be sure the time map is correct, though.
thanks, the summary would be quite sufficient (just to see which time maps are missing/empty), i dont think ifoedit scans nav packs either :)
thanks rolz.....not sure if this has been added or not, but can you add a check to ensure that the first cell is not seamless (ie., not 8 0 but 2 0)? see posts 124 and 125
Currently, the so called "Layer break?" checkbox of the first cell is highlighted in red if the cell is seamless. But the seamless joint flag is not automatically changed. The STC discontinuity flag is not checked at all.
thanks, the summary would be quite sufficient (just to see which time maps are missing/empty), i dont think ifoedit scans nav packs either :)
OK, i'll try to implement the summary, probably also with the total duration of the time map, so that you can easily compare with the PGC duration. I think I'll implement this function in a plugin.
bigotti5
3rd June 2006, 11:41
thanks rolz.....not sure if this has been added or not, but can you add a check to ensure that the first cell is not seamless (ie., not 8 0 but 2 0)? see posts 124 and 125
Neither Philips nor Interra verifier will complain if the first cell of a PGC is flagged as seamless :confused:
thanks, the summary would be quite sufficient (just to see which time maps are missing/empty), i dont think ifoedit scans nav packs either :)
OK, the tmap plugin v1.0 (http://www.videohelp.com/~r0lZ/pgcedit/beta/tmap_plugin_v10.zip) is ready. It has only one function to display a summary of the time maps of the DVD.
If it detects some missing time maps, or some time maps with a wrong duration, a dialog pops up to ask the user if he wants to rebuild the bad time maps. (This operation is made when the DVD is saved.)
Note that this check is only a basic check. Only the global duration of the PGC is checked. If, per chance, a time map has the right duration but with wrong LBA values, it will be considered valid!
Also, I don't understand why the time map begins with the very first LBA of the first cell of the PGC (and has therefore one extra entry) on some of the commercial DVDs I have tested. I'm not sure it's illegal. Currently, the plugin doesn't check this case. So, a time map is considered valid if its duration (number of entries x time unit) is almost equal to the PGC duration, with a tolerance of 1 entry. Let me know if you think it's not correct.
Great work r0lZ, PgcEdit just keeps getting better and better.
Just curious, what kind of symptoms (on hardware players) have you seen or heard of when a PGC's timemap is missing? Or when it contain the wrong duration?
When a time map is missing, you cannot jump to a specific time in the title. (On software players, you cannot use the time slider.)
When a time map is wrong, the jumps will be made to an incorrect location in the title. If the time map is really wrong, you can even jump in another title, or crash the player.
Note that the Fast Forward and Rewind functions are based on different pointers, and will still work as expected.
Also, it is theoretically not possible to use the time functions on non-sequential titles (titles that are composed of several PGCs) and sequential pgcs with random or shuffle playback mode. For those titles, the time map is usually empty. However, some non-compliant players are able to use the time map table anyway. Therefore PgcEdit can rebuild all tables, including for those non-sequential, shuffle or random titles.
A menu PGC cannot have a time map.
blutach
4th June 2006, 09:53
@kumi - to test this for yourself. Backup your IFOs and change the timemap for a title. Make the 1st 20 entries the same. Then from somewhere before entry 20 (80 seconds if each unit is 4 seconds) press go back 5 seconds on your software player.
You will go back to the start!!!! To fix, restore your IFOs (or run PgcEdit's new function).
This new functionality of PgcEdit (http://www.videohelp.com/~r0lZ/pgcedit/index.html) is very very good. I have had some DVDs which have ended up with bad time maps and so this is a very cool thing to have fixed up.
Merci beaucoup r0lZ!!!
Regards
I have had some DVDs which have ended up with bad time maps and so this is a very cool thing to have fixed up.
I just went through 30 of my backups, and 9 have wrong TMAP durations in the main PGC :scared: (usually too small by 1 time unit) So this is a most welcome addition.
By the way, PgcEdit runs some sort of sanity check when loading the PGC Editor window. If there's a problem, it offers to fix a discrepancy (related to PGC playback time I think...) via a popup window. I haven't seen this in a while, so I can't remember the details, and it's not documented in the manual AFAIK.
What does this check do? Compare PGC header playback time vs. cumulative cell playback time?
EDIT: Ah, I guess so. Just checked the source: if {$end_time != -1 && $end_time != $::pgced::__pgcpbtime} {
set txt "WARNING: The PGC Playback Time ([BCDtime $::pgced::__pgcpbtime true]) doesn't match"
set txt "$txt\nthe total of the cells times ([BCDtime $end_time true])."
set txt "$txt\n\nFix it?"
Exactly. But that's not a guarantee that the total time of the PGC is wrong. It can be one or several wrong times in the cells (for example with ARcc0$ protected titles.)
Also, note that a single missing entry in the time map is probably not really a big problem, especially if the PGC is followed by a tiny black cell of one second or so. This cell is there so that you can use the Next Chapter button of the remote when the real last chapter is playing, and is usually intentionally not included in the time map, because it doesn't make sense to jump to that black cell.
jm1647
5th June 2006, 11:07
@r0lZ I was able to repeat this 3 times while trying to blank cells. In the trace in the movie VTS I wanted to blank the studio logo intro and a warning. I followed the prompts about kill play back etc. I hit save dvd and then quit and then the window this DVD has been modifed save it popped up again. I hit save and then quit and it kept popping up. The only way I could get out of Pgcedit was emergency exit. I'm running XP Pro SP2 on a AMD 1500+ 1GB RAM.
Hum, strange. Could you confirm some things?
1) How did you blank the logo and warning? Have you used the "Blank this cell" option from the preview in trace mode?
2) There are no warning or error messages when the DVD is saved?
3) Options -> User Interface -> Expert Mode is not ticked?
jm1647
5th June 2006, 11:25
Hum, strange. Could you confirm some things?
1) How did you blank the logo and warning? Have you used the "Blank this cell" option from the preview in trace mode?
2) There are no warning or error messages when the DVD is saved?
3) Options -> User Interface -> Expert Mode is not ticked?
!. yes
2. No
3. expert mode is tick, I guess by deafual I never ticked it
OK, thanks. I'll try to figure out the problem...
jm1647
5th June 2006, 11:47
OK, thanks. I'll try to figure out the problem...
I'll try it again here also
Thanks!!
jm1647
5th June 2006, 11:59
I'll try it again here also
Thanks!!
The movie is Dr Doolittle 3 and the same thing just happened. Trace mode, preview window, blank cell I chose on 2 different cells. I hit close trace and break. Save dvd, chose quit and the window to save dvd has been modified pooped up hit yes, hadda emergency quit to get out.
President
5th June 2006, 12:16
@r0lZ
Great! Many thank's!
President
5th June 2006, 13:03
@jm1647
Kill playback? Skip ads&warning? I am never doing this automatically. Because a some company including in its products a hidden protection from this trick "post to pre commands":-). Try to find like line in pre PGC section (may be last or near last):
XXX if (any condition) then break.
Break - is a key word and condition is always true. You must to analyse all commands after Break line attentively. Most likely, all of it - any commands which will never executed (abstractive, trash commands). Or this line is LAST of pre commands section. It's a very stupid. Why Break command placing in LAST line??? Just to protect DVD from automatically cleaners:-).
It's a favourite trick for protect from automatically ads killers:-).
Just to replace this line with post command(s) manually and be happy without annoying ads:-).
The Break command has never been a problem, and is still not a problem in the case you describe, at least for PgcEdit.
PgcEdit's Kill Playback replaces the break by a GOTO to the first post-command that is copied to the pre-commands area. The condition is left untouched. Therefore, if the condition is always true, the GOTO will always be executed, as well as the post commands, and the playback will be skipped (as well as the fake pre-commands.)
Anyway, the problem reported by jm1647 has nothing to do with the fact that Kill Playback works well or not, but is related to the way the DVD is saved.
But I have never noticed the protection you describe. Do you have an example? Could you send me the original IFOs?
jm1647
5th June 2006, 18:51
@rolZ - I reripped the DVD with a different ripper and went through the trace mode and blanked cells on the preview screen. I started at the first play PGC this time and got the kill playback popup , went thru to the movie and blanked the 20th century fox intro screen and another one. It worked. I think my early probem could have been also caused by operator error.
I am just getting into and learning all the great things PgcEdit can do. I have regulary using it to blank titlesets in the pgc and was used to the speed at which it done that. First time for me blanking cells.
Just in case I'm gonna do it again with the other ripper and see if that mighta caused the problem or it was me not waiting long enuff before I hit the quit button. I think this was the problem and not caused by Pgcedit.
Sorry for the false alarm, which I really think it was, because I was used to the speed of blanking the titlesets.
Hum, yes, it is possible that the new function to recompute the time maps (which takes usually a long time, and is necessary when you blank some cells of a PGC) was not finished yet when you tried to close PgcEdit. If the flag "DVD Modified" was still on, the "Are you sure" dialog was issued again. Normal.
I'll try to inhibit the action of the save and quit functions when a save operation is still in progress. That should be sufficient to avoid this problem.
Thanks for your help.
jm1647
5th June 2006, 21:06
Hum, yes, it is possible that the new function to recompute the time maps (which takes usually a long time, and is necessary when you blank some cells of a PGC) was not finished yet when you tried to close PgcEdit. If the flag "DVD Modified" was still on, the "Are you sure" dialog was issued again. Normal.
I'll try to inhibit the action of the save and quit functions when a save operation is still in progress. That should be sufficient to avoid this problem.
Thanks for your help.
I had the tower on the floor and didn't see the drive activity light lit...my bad...it's now on the table top :p
Maybe a busy hour glass or something for noobies like me.
As I said I am used to the speed of blanking titles and am just getting into blanking cells using the trace and preview window.
Thank you for the program !!!
Maybe a busy hour glass or something for noobies like me.
When a long operation is in progress, the status bar displays a progress indicator.
jm1647
5th June 2006, 21:27
When a long operation is in progress, the status bar displays a progress indicator.
Ah my bad again......I got to start looking...first long operation I ever attempted..I gotta get my wife a "I'm with stupid T shirt ":p
Thanks again!!!!
I've just added the check to ensure a save operation is not already in progress when you call the save or quit functions. It's a lot more secure now! :)
jm1647
6th June 2006, 01:58
I've just added the check to ensure a save operation is not already in progress when you call the save or quit functions. It's a lot more secure now! :)
Ya mean secure from jm1647 right :p
Thanks!!!
rpboy
6th June 2006, 08:13
I often use the option to create a new blank cell and replace titles with it. This doesn't seem to work with 7.1.2. I've tried with several DVDs (ripped to the HD with DVD Decrypter) and it just doesn't work.
I double-click on the Title to open the PGC Editor. I click on the VOB/Cell ID button and display the "Assign VOB/Cell ID..." window. I select the "Create a new blank VOB cell" option and uncheck the "Copy original VOB to Backup folder" option. I click OK and it just returns to the PGC Editor window. It doesn't say the DVD will be saved now. The VOB/Cell ID button was not changed.
If I go back to 7.0 and try the same thing on the DVD, it works fine.
What's up with that? :)
I did it just now, and it works fine.
It works exactly like before. However, the new function to recompute the time map takes some time, so, the save operation takes longer.
The function can fail if the VOB files are desynchrinized (not matching the IFOs.) But an error message should be displayed in this case.
Could you try with another DVD?
Note: I don't understand why you create a new VOB cell with the Assign V/CID function. With this function, a cell is added in the VOB file, but no new cell is created in the PGC. If you want to replace the cell with VobBlanker, you can probably replace the original cell directly. To create a new cell in a PGC, you should use the Create New Cell button.
Anyway, both functions work equally well.
President
6th June 2006, 13:26
...PgcEdit's Kill Playback replaces the break by a GOTO to the first post-command that is copied to the pre-commands area...
Very well. It's true and easy in one case only - if the Break command sets on the last line of pre commands. In this case a Break is 100% fake. But fake Break command not always placing at the last line (I has a many variations). How do you know what this command true or fake? Or PGCEdit has an artificial intelligence?:-)
Edited: Hmmm. I thinking now... yes, you're right. Correct way in all cases exclude this - full pre section:-).
...Anyway, the problem reported by jm1647 has nothing to do with the fact that Kill Playback works well or not, but is related to the way the DVD is saved...
I know. My post concerning all persons who wants to stop playback of ads and other rejects. jm1647 try to do this by using automatically function. IMO this operation demand a manually work with analysis of all commands.
...But I have never noticed the protection you describe...
Heh:-). You are living in LA with strong laws and copyrights (include ads time and quantity). But this "protection", I think, a new russian feature only:-). Our DVD-authors are know about "post to pre" trick and trying to take counteractions against it. Ads, ads and ads (PUOs, hidden Break, non one-sequential titles, full pre section without NOPs and many other)! A new russian cinema and TV policy:-). Without limits:-). But I want to have such DVD as I like. I hate any ads!!
...Do you have an example? Could you send me the original IFOs?...
Yes, I have. No problem. Catch here:
http://rapidshare.de/files/22341528/Wimbledon.zip.html (40 kb).
Unfortunately, I find only one DVD now with this "protection". All other I already break and rewrite. Sorry.
Very well. It's true and easy in one case only - if the Break command sets on the last line of pre commands. In this case a Break is 100% fake. But fake Break command not always placing at the last line (I has a many variations). How do you know what this command true or fake? Or PGCEdit has an artificial intelligence?:-)It's easy. As I said, the IF condition is left untouched. Therefore the GOTO is executed if the condition is true, and is skipped if it is false, exactly like the break command. No need for artificial intelligence to handle this very easy case! (However, there are some very difficult case where a full trace might be needed to correctly kill playback. Luckily, those cases are very rare.)
IMO this operation demand a manually work with analysis of all commands.True only in the rare cases I evoked above. Not for the Break command.
Heh:-). You are living in LA with strong laws and copyrights (include ads time and quantity).I live in Belgium, far away of LA! But that's not the point.
Yes, I have. No problem. Catch here:
http://rapidshare.de/files/22341528/Wimbledon.zip.html (40 kb).
Unfortunately, I find only one DVD now with this "protection". All other I already break and rewrite. Sorry.
Thanks. I'll try to do something to handle this kind of protection, when I'll have some free time.
If you can find some more examples, please send them, too.
President
6th June 2006, 14:28
True only in the rare cases I evoked above. Not for the Break command.
Yes. You're right. Very good idea! (However, as a many other your idea). Thank's. I don't think about replace to GOTO command. Sorry. Just Break is really not a problem. But always remove playback automatically is not recommended by me. To cast a look at pre section is needed in any case:-).
President
6th June 2006, 14:36
If you can find some more examples, please send them, too.
Sure.
frank
6th June 2006, 17:38
Originally posted by rOlZ:
There are many DVDs with the layer break inside a VOB (where only the cell ID changes.) The seamless flag is set, too. Can anyone give me an example? (PAL) I have so many DVDs but can't find such LB.
@rOlZ
In the Burn Double Layer DVD: Select LB window you should disable the red Seamless Layer Break option if the VOB ID changes (compliant to specs). As we discussed with mpucoder a change of VOB ID means that cells are non-seamless linked. I think to make such location seamless is one reason that beginners produce crashes on some standalones.
This is why the seamless LB option is highlighted in pink. Is it not right?
I don't want to prohibit completely its use, because the right way to use it is still in discussion. Seems it works pretty well, even on the non-seamlessly linked cells, on many players. However, a novice user should not leave the SLB option ticked when it is pink. IMO, this warning is sufficient.
bigotti5
6th June 2006, 19:10
As we discussed with mpucoder a change of VOB ID means that cells are non-seamless linked
mmmmh
non-seamless linked means the "seamless joint" flag is cleared
the mux itself of a VobID change can be seamless or non seamless
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.