PgcEdit v9.2 released! (16 February 2009)

[r0lZ]

Well, sometimes, the preview stays blocked on a badly formatted still-frame VOB. Its window is not visible, and you cannot launch another preview from the same instance of PgcEdit. But it is usually enough to kill the preview from the task manager, or to reboot to fix the problem. I suppose you have tried that, right?

You should also try to change the options in the Preview menu. In particular, try to disable the DirectDraw overlays. (If it works, then you have probably installed a program that causes a conflict with your DirectX filters.) Try also to change the playback mode, although I doubt that this option could help.

I can't help much more.

[arrirc]

Thank you for developing PgcEdit, its an excellent tool, even for a 'not so advanced user' like myself. I have been going through the help of PgcEdit looking for a way to delete one angle from the DVD (I was planing to back up), but unfortunately I could not fathom the guidance, and I could not match the screen shot with the present version (pardon my ignorance, if any). So could it be possible to clarify "Angle Deletion Process" a little bit more?

Secondly, I found one function in PgcEdit named "Remove Useless Stuff" under Menu>DVD. Is it safe to use for users like me? Could you please elaborate it a little bit more? I have applied this macro on 2 DVDs and it seems it really cleans up things, but I must admit that my understanding of this feature is rather very superficial.

Lastly, can "Domain Stream Attributes" function be used directly to remove any unwanted Audio and subtitle stream?

I am using the latest version of PgcEdit.

Thanks again.

[blutach]

1. Click Del Angles in the PGCEditor. Tick the angle(s) you want to keep (you can preview these beforehand with the previewer, but typically, you'd want to keep angle 1). OK and then reclaim the space with VobBlanker y loading the project into VobBlanker and clicking Process for the VTS and then Process down the bottom.

2. Yes, it is totally safe. It does all the things in the dialogue. You can safely keep them all ticked. The help file is very detailed on what this function does.

3. No - you need something like VobBlanker to strip streams from the VOBs. However, if you only remove them from the IFOs via the DSA, then, if space is not an issue, they won't show up when you cycle the remote.

Regards

[r0lZ]

I agree with blu, but here are some precisions.

1. It is usually safe to keep ONE angle ONLY! Many programs, including VobBlanker and FixVTS cannot properly rebuild the angle pointers in the VOBs if you strip some of them but leave several angles in place. If you want lo leave, say, two angles, you can use DVDShrink to compress the unreferenced angles at the maximum compression ratio and remove their audio tracks completely, but afaik, there is currently no easy way to remove them completely without reencoding. Anyway, use VB or FixVTS only if you leave all angles or only one.

2. Remove Useless Stuff is a collection of safe functions that you can use independently also, grouped together to quickly simplify the DVD. In some rare cases, a function can be unsafe, but in that case, you will be prompted to continue anyway, or abort that particular function.
BTW, I am currently working on new functions that will be added to Remove Useless Stuff in PgcEdit v9.3.

3. The Delete Stream function in DSA has been added so that you can rearrange the streams left over after having stripped them, for example with DVDShrink with the option to remap the streams off. However, as blu explained, it cannot be used to remove the stream from the VOB. (Unfortunately, if you have removed the stream references with PgcEdit, you have no way to tell DVDShrink to strip it from the VOBs as it not visible in its GUI any more. To remove a stream and regain its disc space, you should always use Shrink before PgcEdit. Same thing for VobBlanker.)

[arrirc]

Thank you very much- blutach and r0lz.

Firstly,
BTW, I am currently working on new functions that will be added to Remove Useless Stuff in PgcEdit v9.3.
I am eagerly looking forward, thanks again for your excellent effort and the result. :)

Now,
and then reclaim the space with VobBlanker y loading the project into VobBlanker and clicking Process for the VTS and then Process down the bottom.
I know this thread is not exactly for this question, but could it possible for you to elaborate it a little more? Please note, that I have never used VB as such.

Regarding backing up a DVD with multiple angles, I think DVDFab can rip a DVD to HDD stripping all the unnecessary angles (sorry I really do not much about this particular type of DVD or the ripping process of the same). In that case I believe the result can be fed both in VB and PgcEdit?

Thanks again :)

EDIT: the multi-angle DVD that I am referring to is of ALIEN Quadrilogy series.

[r0lZ]

VobBlanker drops the unreferenced cells (including unused angle cells) automatically when it process the VOBs. So, just be sure that it will process the domain with the angles to strip, and it will do the job. You can untick the menu processing and the other VTS if you wish, to speed the processing up. It is easy to figure out how VB works. There is no need to manually specify which angle cells to remove but you must have removed the angle references with PgcEdit (or Jsoto's DelAngles) before using VB, or it will complain.

If you want to remove all angles but one with PgcEdit, I suggest using FixVTS to strip them. It cannot be easier to use, and is very fast.

Of course, if you remove the angles during the rip, there is no problem. But take care. Rebuilding the remaining angle blocks when some but not all of them have been removed is not easy, and can be a source of numerous bugs. I don't know if Fab can do that, but verify if the DVD plays correctly, including when you use the FF and Rew buttons on a cell that was previously multi-angle.

[mikenadia]

I have 3 root menus but the first one VTSM1 is not callable from remote control since no titles in VTS1 are called.
VTSM2 and 3 are callable from remote control.
in my software player ,nothing is happening when I click on "Root menu". I would like it to go to VTSM2 when called from the remote control.
Is it just a "software player" issue, and if not, what can I do ?

Thanks a lot in advance.

Edit:
Thanks, r0lZ. It was the PUO.

[r0lZ]

The fact that no title is called in a VTS does not mean that the menu of that VTS cannot be called. The Root/Audio/Subpic... menus can be called from the VMGM, just like a Title.

We have not enough information to know how to jump to the VTSM 2. First, you would like to go to that menu when what is playing? A title in VTST 2, or in another VTS? It it's form another VTS, is it already a RootM in that VTS? Have you verified if you can reach it with the PgcEdit virtual player's Root Menu button, even if that menu has no video?

Have you verified the PUOs?

[goonix]

Hi r0lZ

I use PgcEdit as main authoring tool for my music concert recordings. For that reason there are a lot of buttons in the track selection menu. These buttons are sometimes very close together. Especially in the letterbox part of the menu, it is difficult to set the hotspot rectangles precisely, because the sliders sometimes jump in 2 pixel steps.

If the lower line of a button and the upper line of the next button can't be set exactly at the same time (it happens...), my current solution is to edit the saved button ascii text.

Is it possible to change the slider resolution to always 1 pixel steps?
If not, can you add small "<" ">" buttons to the sliders?

goonix

[r0lZ]

You can already move the slider by 1 pixel by clicking in the white area of the slider, to the right or the left of the handle. :)

[goonix]

Wow, although I use PgcEdit since the beginning, there are still undiscovered jewels inside this great tool.
You have thought at almost everything...

Thanks, r0lZ!

[turbojet]

Is there any chance the sub color palette can import from vobsub idx files?

It would take out the guessing game when it comes to colors when doing BD to DVD subs.

[r0lZ]

Honestly, I don't know the idx format and I don't use VobSub. Apparently, the idx file contains the indexes to each subtitle of the sub file, but I don't know if it holds a CLUT. If it's the case, I can try to implement a function to import its color palette in PgcEdit, but I need more info. I haven't been able to find a doc about the file format. Can you help me? Can you send me an example?

[turbojet]

Sure here's a sample (http://www.mediafire.com/download.php?nnuytudzjjn).

I'm guessing this line is all that needs to be read: palette: 000000, cbcbcb, 000000, 000000, 000000, d6ec38, 000000, 000000, 000000, cbcbcb, 000000, 000000, 000000, cbcbcb, 000000, 000000

Thanks for looking into it.

[r0lZ]

Yep, thanks. I guess the colors are expressed in RGB values. Most of the colors are black, plus 3 light greys and a yellow. Can you confirm that?

[r0lZ]

OK, done. You will be able to import the palette from a VobSub index file with the next version of PgcEdit.

In attachment is the example palette you gave me, converted to the PgcEdit YCrCb raw format (VTS_05_0.clb). Please confirm that it is correct. Thanks.

[turbojet]

Thanks, here's the results

new on top
original on bottom

http://i44.tinypic.com/10p0eax.png

[r0lZ]

Oops, my bad. I forgot to accept the changes after having imported the IDX and before exporting the CLB, and, of course, PgcEdit has saved the original palette of my test DVD. I've updated the ZIP two posts above with the right CLB, but given your screenshot, I can confirm that it works well.

[turbojet]

Thanks, just waiting on approval of that file and I'll double check. Do you know when you might be releasing the next version with this added?

[r0lZ]

Currently, I haven't much time, but I should release it soon...

[turbojet]

I found 2 little discrepancies

color 5
http://i41.tinypic.com/2qjvbsz.png

colors 1, 9, 13
http://i42.tinypic.com/2laa5gh.png

the other color, solid black, is correct

[r0lZ]

Some little errors are due to rounding problems when converting the YCrCb format to or from RGB. The conversion algorythms used by PgcEdit are correct, and they have already been verified several times. Of course, a little difference is still possible, and inevitable by nature, but it should never be superior to 1 (or -1).

Anyway PgcEdit is right:palette: 000000, cbcbcb, 000000, 000000, 000000, d6ec38, [...]
The yellow is 0xD6EC38, in other words red = 214, green = 236 and blue = 56. Similarly, the grey is 0xCB for each component, and 0xCB is 203 in decimal. So, the NEW screenshots reflect (almost) perfectly the content of the IDX file, and it's either your ORIGINAL screenshots that are wrong, or the conversion to RGB made by VobSub.

The little difference in the red and blue component of the yellow slot are due to the rounding errors when the RGB values are converted back to YCrCb, and cannot be avoided.

BTW, how have you produced your ORIGINAL screenshots of the color picker? Obviously, they do not match the IDX file.

[turbojet]

Original comes from original DVD.

I used vobsub 2.33 to create the idx. I also tried vsrip and the original DVD palette line was identical. However the custom colors line changed but does this have any effect in this situation?

I'm only using DVD to DVD for testing purposes now, if that was all I ever wanted to do I'd use pgcedit color copy/paste. My goal is to be able to do BD to DVD conversions with the most original looking subtitles as possible. My only option currently is BD sup -> vobsub -> DVD sup.

This result is plenty good enough for this particular DVD, it only uses grey and I have trouble telling the difference. However in a situation with colored subs I wonder if there's situations where it could look pretty ugly.

[r0lZ]

Original comes from original DVD.And displayed by PgcEdit? Right? Then it's the proof that VS doesn't generate its IDX file with the right values, or at least that it uses another formula than PgcEdit to do the conversion. Unfortunately, they store the values in the IDX file in already-converted RGB instead of the original YCrCb, therefore I can't use my own formula to convert and display them. I just take the RGB values from the IDX files, and display them unmodified. They are converted back to YCrCb when you click OK in the PGC Editor window. Of course, since the formula used by SubRip is not the same, that operation introduces an error.

There are many different formulas to convert from YCrCb to RGB and vice-versa, and I cannot be totally sure that PgcEdit uses the right one, but as I said previously, the PgcEdit formulas have been checked by several users and they seem to be accurate. Anyway, I'm not going to change them, unless someone can prove that they are wrong, and give me the right formulas.

BTW, can you send me the original palette, extracted by PgcEdit in raw .CLB format? They are the original YCrCb colors, directly extracted from the DVD, without any conversion. I would like to have a look.

[r0lZ]

I've double-checked again the conversion formulas, and I use (almost) exactly the formulas recommended in Keith Jack's Video Demystified to convert between 8-bit digital RGB (full 0-255 range) and YCrCb (SDTV 601). If you are interested, here are the formulas:

Y = 0.257*R + 0.504*G + 0.098*B + 16 (rounded, and clipped to valid range 16-235)
Cr = 0.439*R - 0.368*G - 0.071*B + 128 (rounded, and clipped to valid range 16-240)
Cb = -0.148*R - 0.291*G + 0.439*B + 128 (rounded, and clipped to valid range 16-240)

R = 1.164*(Y-16) + 1.596*(Cr-128)
G = 1.164*(Y-16) - 0.813*(Cr-128) - 0.391*(Cb-128)
B = 1.164*(Y-16) + 2.018*(Cb-128)
(All RGB values are rounded and clipped to valid range 0-255)

The last two formulas were slightly different in PgcEdit:

G = 1.164*(Y-16) - 0.813*(Cr-128) - 0.392*(Cb-128)
B = 1.164*(Y-16) + 2.017*(Cb-128)
Those little errors can explain a slight difference with the correct values, but they are certainly not important enough to explain the differences with the values stored in the VobSub IDX files.
Anyway, I have fixed those errors now, as Video Demystified is cited as THE reference book by many specialists, and I trust it.

Additional note: Do NOT trust the converters at DVD Replica (YCrCb to RGB (http://www.dvd-replica.com/DVD/colorrgb.php) and RGB to YCrCb (http://www.dvd-replica.com/DVD/coloryuv.php)), as they are wrong (and there is a bug in the RGB to YCrCb applet preventing to specify a R value > 0).

[turbojet]

BTW, can you send me the original palette, extracted by PgcEdit in raw .CLB format? They are the original YCrCb colors, directly extracted from the DVD, without any conversion. I would like to have a look.

Sure here it is (http://www.mediafire.com/download.php?gmhtgxmzldz)

Anyway, I have fixed those errors now, as Video Demystified is cited as THE reference book by many specialists, and I trust it.

Did it have any effect on the output?

[r0lZ]

Thanks!
Did it have any effect on the output?Perhaps some minimal effects on the rounding of the divisions, but certainly no more than a difference of 1 in each RGB component. As I said before, those rounding errors are inevitable. The new formulas are perhaps more accurate, and may avoid some rounding errors, but probably not all.
Anyway, it's not a solution for the IDX problem.

[EDIT] I've just imported the original palette in a DVD to verify the values. Of course, PgcEdit shows the colors like in your ORIGINAL screenshots above. (And BTW the difference in the formulas have no effects on the result.)
So, IMO, VobSub should store 218, 204, 38 (DACC26) for the yellow and 204, 204, 204 (CCCCCC) for the greys in the IDX files (or store the original YCrCb values instead of already converted RGB values), but it stores the wrong values D6EC38 and CBCBCB. Black is correctly converted to 000000. The greys are close enough to the original, but the yellow is very different. That's not surprising, as the difficulty with the conversions is the color components.

Unfortunately, I can't do much more. If you wish, try to contact the author of VobSub...

[turbojet]

Do you mean vobsub / vsrip author, Gabest?

Unfortunately he's been gone for years but I see vsrip is open-source, if only I could make sense of any of the code.

Or would SubRip dev be able to help in some way?

[r0lZ]

No, my bad. I mean VobSub, of course. (I've fixed the "typo")

Unfortunately, if the development of VobSub has ceased, I suppose there is no simple solution. Try to find a program that can output the original palette in YCrCb format. If you need it, I can probably implement an import function in PgcEdit.

[turbojet]

I've been talking to BDSup2Sub dev about outputting dvd sup with one of the 2 pgcedit import formats. He said the txt format should be fairly simple but is there any advantage to using clb over the txt format?

[r0lZ]

No. The CLB format is just a binary dump of the palette as it is stored in the IFO. The important thing is to output the original color values, without converting them. The file format doesn't matter much, as long as it can be easily parsed.

[turbojet]

Ok I'll have to wait and see what that program will output. Currently only seems like a standalone ifo is in the works which I don't think will help my situation one bit.

In the mean time I can use pgcedit's idx import feature for everything but colored subs. I don't mind the 1 tone lighter gray, in fact I wouldn't even notice it without comparing to original.

Thanks for adding it and will I'll patiently await the release.

[turbojet]

I thought of another way to get sub colors (maybe accurate?) in BDtoDVD process is from the BDsup (http://www.sendspace.com/file/m1t7m0). Is there any chance of adding support for this?

[r0lZ]

Hum, I don't think so. The SUP file does not contain the palette information. Furthermore, it contains several subpics, and they may have different colors.

[0xdeadbeef]

Just in case anybody is interested: BDSup2Sub is now able to optionally export the text file containing the palette when exporting SUB/IDX or SUP/IFO.
A quick test indicates that it seems to work although I took the liberty of adding a comment line (starting with "#") and removing the leading tabs.
Hope this helps.

[r0lZ]

Thanks for your work, 0xdeadbeef!

Can you post an example of a file produced by BDSup2Sub here?

[0xdeadbeef]

Thanks for your work, 0xdeadbeef!

Can you post an example of a file produced by BDSup2Sub here?

Sure. It's not overwhelmingly interesting though:
# Palette file for PGCEdit - colors given as R,G,B components (0..255)
Color 0=0, 0, 0
Color 1=240, 240, 240
Color 2=204, 204, 204
Color 3=153, 153, 153
Color 4=51, 51, 250
Color 5=17, 17, 187
Color 6=250, 51, 51
Color 7=187, 17, 17
Color 8=51, 250, 51
Color 9=17, 187, 17
Color 10=250, 250, 51
Color 11=187, 187, 17
Color 12=250, 51, 250
Color 13=187, 17, 187
Color 14=51, 250, 250
Color 15=17, 187, 187

As I said, I just added a comment line and removed the tabs. PGCEdit seems to cope with that just fine though.

[Robotik]

wow, i'm so outdated! i expected the new version to be announced in the 8.6 thread, kept on checking it :)))))
even though i haven't been doing much dvd editing nowadays, i'm so glad v9 is out!
what else did i miss? i'm gonna check for VobBlanker, too, right away!

maybe i should post to all previous PgcEdit posts that the new version is out for losers like me to notice it :)
who knows it might boost the donations, too :)

anyway, as always, thanks for all your effort and keep up the good job.

[r0lZ]

Why don't you use the Check For New Version option in the Help menu from time to time?
Remember also that you can be noticed of the changes on my homepage. See the changedetection gadget at the bottom of the page. It works well, it is more reliable then the thread notifications, and is totally SPAM free. I try to modify my homepage only when it's really needed to avoid "false positives".

[mikenadia]

Is it safe to blank all those cells whose duration is equal or less that 1/4 s (size going from 384K to 10K), and if the answer is "yes" , any function in PGCedit that will help me speed us the process.
Thanks in advance.

[blutach]

Not all of them. Say they have cell still time and some buttons. Then you'd be causing errors.

Otherwise, yes. No function available (yet).

Regards

[Robotik]

grammatical mistake in 9.2, when can't open a dvd (double negation):
*** Dialog title: "PgcEdit: Read DVD"
*** Dialog type: warning
*** Dialog message:
Can't open VIDEO_TS.IFO
or file empty!
No BUP file available neither. This is not a DVD folder.
*** Dialog buttons: [OK]

the correct sentence would be:
No BUP file available, either.

btw, it seems to be a bug as both video_ts.ifo and bup are present. i go and check it

[M_Knox]

Windows or Linux version? If the latter, please check the filenames - they have to be all-uppercase.

[r0lZ]

Under Windows, check also the path name. Tcl/Tk has trouble with foreign or accented characters, and some special characters like [ and ].

[Robotik]

Hi,

it is the Windows version and yep, it is the path name, it contains the Hungarian character, ő.
i know that the easy way to make it work is renaming the folder, but i tried to make it work with PGCEDIT_ENCODING, and also with the command lines 'pgcedit -e=unicode' and 'pgcedit /E=utf-8', and i couldn't. how does it go?

also, is it possible to check for foreign characters in the path during startup, so it doesn't give a false alert of having an empty file? it gave me the creeps :)
and is it possible to check if the path can be opened before the nag screen comes up? it took me some time to test what the problem is, having to wait quarter a minute each time :D

[r0lZ]

I have to say that I have never really understood the origin of the foreign characters problem. I have added the encoding option so that you should be able to specify the right character encoding for your system, but I have no way to know what encoding must be used (otherwise I would have added the code to select it automatically.) So, sorry, but you have to experiment with the different encoding schemes supported by Tcl/Tk, until the problem disappears. I gave up when I have tried with a French system. If you can find the right encoding for your language, please let me know.

Note that the problem with the [ and ] characters is not related to the encoding, and appears only in some functions of PgcEdit (such as when you launch a tool that contains such characters from the Tools menu.)

Unfortunately, I can't check for the problem at startup, as the filename appears correctly to PgcEdit. I have no way to compare it with the real filename. It's only when PgcEdit has to call an external program that the problem occurs, and PgcEdit can only understand that the program has failed, but doesn't know the exact reason.

It is easy to remove the nag screen. Just donate! ;)

[Robotik]

hmm

i tried to open the dvd from command line and if i use the short dos name, it works!
i wasn't sure of the naming convention of dos, so i looked it up on Microsoft's site (http://support.microsoft.com/kb/101601).

in the command window, instead of writing
pgcedit "F:\FullDisc\1 reteg\A csendőr nősül\VIDEO_TS"
i wrote
pgcedit "F:\FullDisc\1 reteg\ACSEND~1"
and PgcEdit opened it with no complaints, saved it with no complaints, even more the window title says PgcEdit - "F:\FullDisc\1 reteg\A csendőr nősül\VIDEO_TS" - untitled

maybe there is a similar workaround possible in Tcl/Tk.

[r0lZ]

Nice trick. I'm not sure it is possible to know the DOS pathname from PgcEdit, but I will have a look...

[M_Knox]

@r0lZ:
This is damn strange.

I have this folder: E:\ĄĘ\VIDEO_TS
When I double-click the VIDEO_TS.IFO in the Explorer, I get the message:

*** Dialog type: error
*** Dialog message:
Error 1 opening file "E:/ﾥÊ/VIDEO_TS/VIDEO_TS.IFO" for read:
couldn't open "E:/ﾥÊ/VIDEO_TS/VIDEO_TS.IFO": no such file or directory
*** Dialog buttons: [OK]

Now, I go to the console mode, chdir to E:\ĄĘ\VIDEO_TS and issue:
"c:\program files\dvdutils\pgcedit\pgcedit" video_ts.ifo

Everything goes fine (because PgcEdit does not receive diacritical charactes on the command line).

This one:
"c:\program files\dvdutils\pgcedit\pgcedit" e:\ąę\video_ts\video_ts.ifo
gives the same error as double-clicking VIDEO_TS.IFO

But this one:
"c:\program files\dvdutils\pgcedit\pgcedit" - e:\ąę\video_ts\video_ts.ifo
goes JUST FINE :)

Instead of "-" you may place whichever character (well, almost) you want, even a diacritical one :)

(all of the above done with PGCEDIT_ENCODING environment variable NOT SET)

[r0lZ]

Ah, yes, that's really strange! Maybe the presence of a second argument forces PgcEdit to try to interpret it as a change of encoding. I have to read my code...