Quote:
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.
Quote:
|
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
Quote:
|
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