View Full Version : Removing PU-OPs in VOBs through DVD Decrypter
2COOL
25th September 2003, 15:12
Can DVD Decrypter remove the Prohibited U-OP in the VOBs? I'm not talking about the ones in the IFOs. Here's what I got from a VOB in my Friends Season 3 Volume 1 (R1) when inquiring in VOBedit.
[PCI Stream]
PCI General Information
this->lba 3968 [00000f80]
Macrovision (APS) 0 [0000]
Reserved 0 [0000]
Prohibited U-OP 29422608 [01c0f410]
The PU-OP here is disabling my remote buttons except Root. I can hexedit them out but it takes alot of memory and time. It would be great if it can be done on the fly while the VOBs are ripping.
LIGHTNING UK!
25th September 2003, 15:27
It could if I made it but I havent. I prefer giving people an exact copy of the disc as-is only without the region protection. I've even unchecked the remove puo's bit by default in the next version.
2COOL
25th September 2003, 15:40
Originally posted by LIGHTNING UK!
It could if I made it but I havent. I prefer giving people an exact copy of the disc as-is only without the region protection. I've even unchecked the remove puo's bit by default in the next version. Please! Pretty please!!! I'm trying to author a DVD and I need all my remote buttons available. Please make it an option, especially for IFO mode, on next version. There's no other ripper that can do it so it'll be a plus for DVD Decrypter. :D
LIGHTNING UK!
25th September 2003, 20:33
Pfffftttt...if I must! :rolleyes:
windtrader
25th September 2003, 21:46
Yeah. Get rid of all those stinking PUOPs. If you remove the PUOPs in all IFOs, won't that allow one to jump past any protected chapter/cell? For example, if copyright crap gets authored into a VTS IFO/VOB, then removing the PUO there will let me jump past it, right?
2COOL
26th September 2003, 02:07
Originally posted by windtrader
If you remove the PUOPs in all IFOs...A lot of people are still referring to PUOPS belonging ONLY in the IFOs. There are two types of PUOPs, ones in the IFO and the ones in the VOBs' Nav Packs. Their location are different but their functionality are the same.
Ever had a DVD that when you pressed your subtitle button and it doesn't go to the subtitle screen? The menu is configured in VTS_*_0.IFO / VTSM_PGCI_UT and with all the PUOPS removed in the IFO, it still doesn't have your screen pop-up. The cause of this is because of the PUOPs in the VOBs. See first post.
@LIGHTNING UK!
If you had really understood where I was coming from with the VOB PUOPs and not the IFOs, I give my deepest sincere thanks on your reconsideration.
windtrader
26th September 2003, 04:30
Thanks 2COOL. I never realized that PUOPs may be in the physical VOBS. I read your first post - it did not compute. :-)
So, are we saying that it is possible that PUOPs can be removed from the VIDEO_TS and VTS_xx_0.IFOs but a PUOP could still be hiding in a VTS_XX_0.VOB that would prohibts actions while that menu VOB was selected?
2COOL
26th September 2003, 06:31
@windtrader
Originally posted by windtrader
Thanks 2COOL. I never realized that PUOPs may be in the physical VOBS. I read your first post - it did not compute. :-)
So, are we saying that it is possible that PUOPs can be removed from the VIDEO_TS and VTS_xx_0.IFOs but a PUOP could still be hiding in a VTS_XX_0.VOB that would prohibts actions while that menu VOB was selected? Yes but the PUOPs I'm talking about are in the main VOBs, not the VTS_XX_0.VOB Menu VOB. When I had removed them all using a hex editor, my remote menu buttons are enabled again in my Friends backup. In IFOedit, they were greyed out except for Root.
LIGHTNING UK!
26th September 2003, 08:58
Yup I understood what you meant. I had a word with mpucoder the other day and he pointed that out to me along with some other stuff. As I already remove macrovision, patching this stuff will be easy peasy!
It'll just be another checkbox in the IFO/FILE/ISO mode tabs in the settings.
I was actually going to do it lastnight but I got caught up doing some other stuff. I'll see if I cant fit it in tonight before I go out and get p1ssed :)
LIGHTNING UK!
27th September 2003, 12:08
Oh well, failed to do it lastnight but ive done it thismorning for ya. Just thought I'd let you know :)
2COOL
28th September 2003, 02:24
Sweeeet!:D Much thanks. This will definitely be much better because even the best hex-editors can't handle files over 1GB too well. Doing it on the fly while ripping is the way to go. Again thanks!
Grave
25th August 2004, 14:22
did it work for you?
because i doesnt work for me with dvddecrypter (tried 3.2.3.0)
the prohibitions (cannot seek) are on extras vobs (e.g. bonus video clips on VADER dvd, or mr.bean3 bonus clips)
could you post how to find the right offsets/values, i'll try hexediting
2COOL
26th August 2004, 03:17
@Grave
I'm surprised that DVD Decrypter didn't take them out with the option checked.
Anyways, how I found out that I had Prohibited U-OP in my VOBs, I just opened up the VOB, in question, using VobEdit. Click on a Navigation Pack on the left to show data on the right. Look at Byte [0035].
[0035] Prohibited U-OP 0 [00000000]
If it's not a zero, then you have it present. Just use your hex-editor to search the hex value and replace with 00000000. You might have different values present in certain Nav packs so you have to check for those too. Keep in mind that some Hex-Editors are very slow in with large files, e.g. 1 GB. I believe I was using Hex Workshop at the time.
LIGHTNING UK!
26th August 2004, 15:18
Hmmm should this not work 2COOL? I'd have expected you to report it as not working if it didn't!
It works for me in recent versions.
2COOL
26th August 2004, 15:54
Originally posted by LIGHTNING UK!
Hmmm should this not work 2COOL? I'd have expected you to report it as not working if it didn't!
It works for me in recent versions. I guess I have to apologize for not confirming earlier and YES, it did work like a charm for me. :D
Grave
26th August 2004, 18:11
thanx for reply
i went through vobs and interesting enough, there werent any puops
so i re-checked everything (including dvdecrypter/ifoedit puops removal - resulted in same situation)
finally i found in ifoedit/video_ts/vmg_ptt_srpt/title_playback_type set to 84 (puops set to "no" according to ifoedit, using remove puops buttons said there are no puops to remove)
when i replaced 84 with 20 (as in other titles which worked fine), affected titles were working finally as expected
now i'm not really skilled with ifoedit or dvd structure, so i'm bit puzzled why the puops werent removed by either ifoedit or dvddec (well if that thing i changed has anything to do with puops thats it :))
LIGHTNING UK!
26th August 2004, 21:57
afaik, only the last two bits in that byte are anything to do with PUOs.
84 = 0101 0100
(Last 2 (far right) bits are both 0)
20 = 0001 0100
Same as above.
Maybe mpucoder could shed some more light on this?!
2COOL
27th August 2004, 01:07
Well, this is what I gathered in IfoEdit with these values for now.
Jump/Link/Call commands only in pre/post
Decimal = Binary
20 = 0001 0100
21 = 0001 0101
22 = 0001 0110
23 = 0001 0111
Title_#: Title playback type 20
type details:
one_sequential_pgc
Jump/Link/Call commands only in pre/post 0
Prohibited user op. PTT play or search no
Prohibited user op. Time play or search no
Title_#: Title playback type 21
type details:
one_sequential_pgc
Jump/Link/Call commands only in pre/post 0
Prohibited user op. PTT play or search no
Prohibited user op. Time play or search yes
Title_#: Title playback type 22
type details:
one_sequential_pgc
Jump/Link/Call commands only in pre/post 0
Prohibited user op. PTT play or search yes
Prohibited user op. Time play or search no
Title_#: Title playback type 23
type details:
one_sequential_pgc
Jump/Link/Call commands only in pre/post 0
Prohibited user op. PTT play or search yes
Prohibited user op. Time play or search yes
_________________________________________________
Jump/Link/Call commands in all places
Decimal = Binary
60 = 0011 1100
61 = 0011 1101
62 = 0011 1110
63 = 0011 1111
Title_#: Title playback type 60
type details:
one_sequential_pgc
Jump/Link/Call commands in all places 0
Prohibited user op. PTT play or search no
Prohibited user op. Time play or search no
Title_#: Title playback type 61
type details:
one_sequential_pgc
Jump/Link/Call commands in all places 0
Prohibited user op. PTT play or search no
Prohibited user op. Time play or search yes
Title_#: Title playback type 62
type details:
one_sequential_pgc
Jump/Link/Call commands in all places 0
Prohibited user op. PTT play or search yes
Prohibited user op. Time play or search no
Title_#: Title playback type 63
type details:
one_sequential_pgc
Jump/Link/Call commands in all places 0
Prohibited user op. PTT play or search yes
Prohibited user op. Time play or search yes
Now if I had inputted a 84, I get an invalid line.
Title_1: Title playback type 84
type details:
not one_sequential (random, shuffle, stills, loops, or more than one pgc)
Jump/Link/Call commands invalid 0
Prohibited user op. PTT play or search no
Prohibited user op. Time play or search no
Grave
27th August 2004, 18:47
i have seen also 85 on another dvd (vader), 52 (shrek dvd)
i've been looking for some info about the values, but found nothing so far, so your information is appreciated, thanks
mpucoder
27th August 2004, 21:20
I just tried 84, and it shows the JLC (Jump/Link/Call) as invalid, but that must be a bug in IfoEdit (along with calling the table vmg_ptt_srpt - it is vmg_tt_srpt). It translates to "only in pre/post"
The difference between 84 and 20 is bit 6 meaning "Not one-sequential". Certain operations, such as time seek, cannot be performed unless the PGC is one-sequential. So the relevant PUOp's don't matter if the operation cannot be performed. Changing the PGC to 20 says that it is one-sequential, which, if it truly is not, can lead to problems with some players. Things that make a PGC not one-sequential and the consequence of clearing the bit:
The PGC is linked to others (worst offence)
Random and shuffle play (minor problems in some players)
Stills and looping (probably work OK on most players)
Other values that Grave mentioned
85 same as 84, but specifically prohibits time search (won't work anyway)
52 JLCs in pre, post, and cell
2COOL
27th August 2004, 22:15
@mpucoder
Thanks for your input! :)
Originally posted by mpucoder
I just tried 84, and it shows the JLC (Jump/Link/Call) as invalid, but that must be a bug in IfoEdit (along with calling the table vmg_ptt_srpt - it is vmg_tt_srpt). It translates to "only in pre/post" So, if you say it's a bug, then 84 is really "valid"?
Out of curiousity, Jump/Link/Call commands only in pre/post holds a zero dec value. I'm assuming that this is a flag that can be set. If so, how to you set that? Or does that line suppose to hold a "yes/no" value?
Also, can you enlighten/clarify us on the use of values 60 to 63?
mpucoder
27th August 2004, 23:18
Originally posted by 2COOL
So, if you say it's a bug, then 84 is really "valid"?
AFAIK, there's no reason why JLCs would be restricted to one-sequential. Just the opposite, in fact. If it's not going to play sequentially then there's probably a lot of branching.
Jump/Link/Call commands only in pre/post holds a zero dec value.
I never noticed that before. Actually, it is the interpretaion of bits 5-2 of the byte. It really is the value interpretted. Maybe a better way to display it would have been
Jump/Link/Call commands : only in pre and post
Also, can you enlighten/clarify us on the use of values 60 to 63?
Before I do, here's the breakdown of the bits
7 - reserved
6 - 1 = not one-sequential
5 - 1 = JLC in cell commands
4 - 1 = JLC in pre/post commands
3 - 1 = JLC in button commands
2 - 1 = JLC present (must be set if 5, 4, or 3 is set)
1 - 1 = PTT play or search prohibited (for entire title, overrides PGC)
0 - 1 = time play or search prohibited (for entire title, overrides PGC)
So 60 decimal is 0011 1100 binary, meaning (bit 6) one-sequential, (bits 5-2) JLCs can be found in cell, pre/post, and button commands, (bit 1) PTT play/search allowed (subject to PGC PUOp), (bit 0) time play/search allowed (subject to PGC PUOp)
63 decimal is 0011 1111 binary, so the same as 60 except the both PTT and time play/search are prohibited.
Note that I did not mention the VOBU PUOps for PTT/time play/search. These are not allowed to be set (but someone might break the rules, so check anyway).
The PUOps not allowed in a VOBU are 0, 1, 2 (title play), and 17 (button select or activate)
The only PUOp not allowed in a PGC is 4, GoUp
2COOL
27th August 2004, 23:27
Thank you mpucoder for another session of enlightenment. We all know you live for this stuff! You probably have the official DVD specs right there on your nightstand to read up every night! :p Sooner or later, this subject matter would have to come up. Thanks Grave for your findings.
mpucoder
27th August 2004, 23:54
Originally posted by 2COOL
You probably have the official DVD specs right there on your nightstand
You know that would be a violation of the NDA ;) No, it really is all reverse engineered.
That reminds me (a little OT) right now I'm working on video_rm. This is made by DVD recorders and NeroVision. Similar in function to DVD-VR, but compliant to DVD-Video.
2COOL
27th August 2004, 23:57
@mpucoder
So, with the info that you gave, this is my assumption that IfoEdit supposed to display instead of current view for better understanding.
60 = 0011 1100
Title_#: Title playback type 60
type details:
one_sequential_pgc
Jump/Link/Call commands:
In cell commands yes
In Pre/Post commands yes
In button commands yes
In any commands yes
Prohibited user op. PTT play or search no
Prohibited user op. Time play or search no
Though 36 shows invalid in IfoEdit, it supposed to be valid too. Again, below is my interpretation of 36 should be.
36 = 0010 0100
Title_#: Title playback type 36
type details:
one_sequential_pgc
Jump/Link/Call commands:
In cell commands yes
In Pre/Post commands no
In button commands no
In any commands yes
Prohibited user op. PTT play or search no
Prohibited user op. Time play or search no
BTW, what's NDA?
mpucoder
28th August 2004, 03:19
Yeah, that would make more sense - just leave out the word "only".
I checked version 0.96 - no problem with 36
Non-Disclosure Agreement, signing it is the only way to legally obtain the specs.
2COOL
28th August 2004, 04:20
Originally posted by mpucoder
Yeah, that would make more sense - just leave out the word "only".OK.
I checked version 0.96 - no problem with 36I didn't check 0.96 but you're right. I'm still using 0.95 out of personal preference.
Non-Disclosure Agreement, signing it is the only way to legally obtain the specs. Well, I don't have $$$ for it either. :(
2COOL
28th August 2004, 05:16
Here's what I got on valid codes in IfoEdit 0.96 for Title Playback Type setting in VMG. For people who just want to know. ;)
About VMG_PTT_SRPT Title Playback Type Bit Settings
Bit breakdown
JLC(Jump/Link/Call) Command
7 - reserved (default 0)
6 - not one-sequential (0 = not present, 1 = present)
5 - JLC in cell commands (0 = not present, 1 = present)
4 - JLC in pre/post commands (0 = not present, 1 = present)
3 - JLC in button commands (0 = not present, 1 = present)
2 - JLC present (0 = if bits 5, 4, and 3 are not set, 1 = if bits 5, 4, or 3 are set)
1 - PTT play or search prohibited (for entire title, overrides PGC) (0 = Don't prohibit, 1 = prohibit)
0 - time play or search prohibited (for entire title, overrides PGC) (0 = Don't prohibit, 1 = prohibit)
one-sequential PGC
In no Commands
bit
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
dec |---|---|---|---|---|---|---|---|
0 = | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
1 = | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 |
2 = | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 |
3 = | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 1 |
In button commands
bit
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
dec |---|---|---|---|---|---|---|---|
12 = | 0 | 0 | 0 | 0 | 1 | 1 | 0 | 0 |
13 = | 0 | 0 | 0 | 0 | 1 | 1 | 0 | 1 |
14 = | 0 | 0 | 0 | 0 | 1 | 1 | 1 | 0 |
15 = | 0 | 0 | 0 | 0 | 1 | 1 | 1 | 1 |
In Pre/Post commands
bit
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
dec |---|---|---|---|---|---|---|---|
20 = | 0 | 0 | 0 | 1 | 0 | 1 | 0 | 0 |
21 = | 0 | 0 | 0 | 1 | 0 | 1 | 0 | 1 |
22 = | 0 | 0 | 0 | 1 | 0 | 1 | 1 | 0 |
23 = | 0 | 0 | 0 | 1 | 0 | 1 | 1 | 1 |
In Pre/Post and button commands
bit
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
dec |---|---|---|---|---|---|---|---|
28 = | 0 | 0 | 0 | 1 | 1 | 1 | 0 | 0 |
29 = | 0 | 0 | 0 | 1 | 1 | 1 | 0 | 1 |
30 = | 0 | 0 | 0 | 1 | 1 | 1 | 1 | 0 |
31 = | 0 | 0 | 0 | 1 | 1 | 1 | 1 | 1 |
In cell commands
bit
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
dec |---|---|---|---|---|---|---|---|
36 = | 0 | 0 | 1 | 0 | 0 | 1 | 0 | 0 |
37 = | 0 | 0 | 1 | 0 | 0 | 1 | 0 | 1 |
38 = | 0 | 0 | 1 | 0 | 0 | 1 | 1 | 0 |
39 = | 0 | 0 | 1 | 0 | 0 | 1 | 1 | 1 |
In cell and button commands
bit
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
dec |---|---|---|---|---|---|---|---|
44 = | 0 | 0 | 1 | 0 | 1 | 1 | 0 | 0 |
45 = | 0 | 0 | 1 | 0 | 1 | 1 | 0 | 1 |
46 = | 0 | 0 | 1 | 0 | 1 | 1 | 1 | 0 |
47 = | 0 | 0 | 1 | 0 | 1 | 1 | 1 | 1 |
In cell and Pre/Post commands
bit
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
dec |---|---|---|---|---|---|---|---|
52 = | 0 | 0 | 1 | 1 | 0 | 1 | 0 | 0 |
53 = | 0 | 0 | 1 | 1 | 0 | 1 | 0 | 1 |
54 = | 0 | 0 | 1 | 1 | 0 | 1 | 1 | 0 |
55 = | 0 | 0 | 1 | 1 | 0 | 1 | 1 | 1 |
In cell, Pre/Post, and button commands
bit
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
dec |---|---|---|---|---|---|---|---|
60 = | 0 | 0 | 1 | 1 | 1 | 1 | 0 | 0 |
61 = | 0 | 0 | 1 | 1 | 1 | 1 | 0 | 1 |
62 = | 0 | 0 | 1 | 1 | 1 | 1 | 1 | 0 |
63 = | 0 | 0 | 1 | 1 | 1 | 1 | 1 | 1 |
Not a one-sequential PGC
In no Commands
bit
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
dec |---|---|---|---|---|---|---|---|
64 = | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 |
65 = | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 1 |
66 = | 0 | 1 | 0 | 0 | 0 | 0 | 1 | 0 |
67 = | 0 | 1 | 0 | 0 | 0 | 0 | 1 | 1 |
In button commands
bit
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
dec |---|---|---|---|---|---|---|---|
76 = | 0 | 1 | 0 | 0 | 1 | 1 | 0 | 0 |
77 = | 0 | 1 | 0 | 0 | 1 | 1 | 0 | 1 |
78 = | 0 | 1 | 0 | 0 | 1 | 1 | 1 | 0 |
79 = | 0 | 1 | 0 | 0 | 1 | 1 | 1 | 1 |
In Pre/Post commands
bit
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
dec |---|---|---|---|---|---|---|---|
84 = | 0 | 1 | 0 | 1 | 0 | 1 | 0 | 0 |
85 = | 0 | 1 | 0 | 1 | 0 | 1 | 0 | 1 |
86 = | 0 | 1 | 0 | 1 | 0 | 1 | 1 | 0 |
87 = | 0 | 1 | 0 | 1 | 0 | 1 | 1 | 1 |
In Pre/Post and button commands
bit
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
dec |---|---|---|---|---|---|---|---|
92 = | 0 | 1 | 0 | 1 | 1 | 1 | 0 | 0 |
93 = | 0 | 1 | 0 | 1 | 1 | 1 | 0 | 1 |
94 = | 0 | 1 | 0 | 1 | 1 | 1 | 1 | 0 |
95 = | 0 | 1 | 0 | 1 | 1 | 1 | 1 | 1 |
In cell commands
bit
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
dec |---|---|---|---|---|---|---|---|
100 = | 0 | 1 | 1 | 0 | 0 | 1 | 0 | 0 |
101 = | 0 | 1 | 1 | 0 | 0 | 1 | 0 | 1 |
102 = | 0 | 1 | 1 | 0 | 0 | 1 | 1 | 0 |
103 = | 0 | 1 | 1 | 0 | 0 | 1 | 1 | 1 |
In cell and button commands
bit
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
dec |---|---|---|---|---|---|---|---|
108 = | 0 | 1 | 1 | 0 | 1 | 1 | 0 | 0 |
109 = | 0 | 1 | 1 | 0 | 1 | 1 | 0 | 1 |
110 = | 0 | 1 | 1 | 0 | 1 | 1 | 1 | 0 |
111 = | 0 | 1 | 1 | 0 | 1 | 1 | 1 | 1 |
In cell and Pre/Post commands
bit
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
dec |---|---|---|---|---|---|---|---|
116 = | 0 | 1 | 1 | 1 | 0 | 1 | 0 | 0 |
117 = | 0 | 1 | 1 | 1 | 0 | 1 | 0 | 1 |
118 = | 0 | 1 | 1 | 1 | 0 | 1 | 1 | 0 |
119 = | 0 | 1 | 1 | 1 | 0 | 1 | 1 | 1 |
In cell, Pre/Post, and button commands
bit
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
dec |---|---|---|---|---|---|---|---|
124 = | 0 | 1 | 1 | 1 | 1 | 1 | 0 | 0 |
125 = | 0 | 1 | 1 | 1 | 1 | 1 | 0 | 1 |
126 = | 0 | 1 | 1 | 1 | 1 | 1 | 1 | 0 |
127 = | 0 | 1 | 1 | 1 | 1 | 1 | 1 | 1 |
LIGHTNING UK!
28th August 2004, 09:02
So basically as long as I take that byte and '&= 0xFC' it, I'm doing it right?
That'll turn the two least significant bits to zeros.
mpucoder
28th August 2004, 11:57
@2COOL: looks good
@LIGHTNING UK: that's correct for removing PUOps, which is what the thread is about, right? (I came in late)
btw, I just tried the latest Decrypter (haven't done a rip in awhile, just replaced the worn out drive last week), very nice.
LIGHTNING UK!
28th August 2004, 15:40
Thanks for confirming that mpucoder. That's what I've been doing all along so it's not an error on my part which is all I'm concerned about.
BTW, the 'latest' version wont be the latest for much longer, I'm about to release another one today :)
2COOL
28th August 2004, 22:23
@mpucoder
Just to fully understand and confirm. If the bits 0 & 1 are set to 1 (prohibit)...
bit 1 : PTT play or search prohibited // Set to 1
bit 0 : time play or search prohibited // Set to 1
...it doesn't matter if it's set in the PGC to prohibit, right? You mentioned that the PUOps takes priority over the PGC ones. But if I select to not prohibit PTT play or search and time play or search in VTS_PGC, I would also have to reset the bits in the TT_SRPT table to zeroes if I want true non-prohibition. IfoEdit doesn't automatically do this.
On the flip side, if the bits are set to 0's for non-prohibition...
bit 1 : PTT play or search prohibited // Set to 0
bit 0 : time play or search prohibited // Set to 0
...does it mean the PUOps are truly non prohibited even though they are set to prohibit in the PGC? Again, on the override issue.
mpucoder
28th August 2004, 23:06
I guess I could have worded that better. The bits are or'ed together, so that a set bit in vmg_tt_srpt, pgc, or vobu_uop_ctl will prohibit the action. In order to do a particular action all the respective bits, even those not supposed to be set in a VOBU (bits 0, 1, 2, and 17), must be == 0.
2COOL
28th August 2004, 23:17
Originally posted by mpucoder
In order to do a particular action all the respective bits, even those not supposed to be set in a VOBU (bits 0, 1, 2, and 17), must be == 0. What action is that when == 0? Clear PUOps, in question, entirely?
mpucoder
28th August 2004, 23:44
Say you want to do a time search, then bit 0, the bit which can prohibit that action, must be equal to 0 in all three places where PUOps are stored - the PGC, vmg_tt_srpt, and vobu_uop_ctl
2COOL
29th August 2004, 01:18
Originally posted by mpucoder
Say you want to do a time search, then bit 0, the bit which can prohibit that action, must be equal to 0 in all three places where PUOps are stored - the PGC, vmg_tt_srpt, and vobu_uop_ctl I see. :) It's all 1's or all 0's! So IfoEdit's not doing the job correctly in clearing the bits, in question, in ALL three places when doing removal of POUps. Just like Grave confirmed.
Thanks for the clarification. You know...this thread sure provides good reading material.:p
Grave
27th December 2004, 10:35
bringing back this very nice thread, coz i'm stuck or i missed something :)
i have been trying to fix prohibited time search on "legend of drunken master" dvd (interview, vts 3) with no apparent success
already tried everything i could think of (dvddecrypter, pgcedit, vobpuo, ifoedit)
no vob puos according to vobpuo and vobedit (0)
none in vts3 pgc (0)
vmg_ptt_srpt 124 (tried other values too using very useful table from this thread)
any ideas what should i try?
r0lZ
27th December 2004, 12:02
Are you sure your title is a non sequential one? Value 124 in VMG_TT_SRPT means that it is a Title to be played in random or shuffle mode, or stills, or that the Title is spread over several PGCs. This may be the problem... Have you tried value 60 (same flags, but without the non sequential PGC flag)?
Grave
27th December 2004, 20:08
yes, 60, 64 and many other values with no effect.
btw thanx for great pgcedit esp. its very helpful trace mode :)
stripy
31st March 2005, 14:29
A bit late, but I've just started DVD reauthorin business.
I had the same problem as grave. I also removed all PUOPs in all IFOs and there were none in VOBs, but still time search didn't work. After some examination I noticed that my VTS_TMAPTI (time map) was empty.
Q: Is there a tool that just creates a time map for VOB?
With reauthoring in IfoEdit I created a new movie with time map, but I tried to make non-sequential like the original. Unfortunately time search still didn't work. I could click on time line now, but the movie just jumped back. In the end I reauthored complete DVD using IfoEdit and PgcEdit and now it works great. Kudos to the makers of these programs.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.