Deleting audio-tracks: adjust SetSTN

[Calimari]

When deleting an audio track, the SetSTN commands have to be adjusted.
When the SetSTN is set directly, it's sufficient to change the track number. When it happens indirectly (gprm-value), I have to search where that gprm is set and modify the values. Am i right so far?

Now, I have found this:
4 Set gprm(1) =(mov) sprm(1:Audio stream number)
5 Set gprm(1) &=(and) 3

So, the current audio stream number is stored in gprm(1), and then there's a logical AND. The value of gprm(1) doesn't seem to change when I trace through these commands.
How do i have to interprete this? Normally, a logical AND gives true when both conditions are true.

Second question: Suppose I delete an audiotrack in VTS1. Do I have to change SetSTN commands in the whole dvd or only in the VTS1 domain?
(Does each domain has its own SetSTN command set?).

[Calimari]

I found out:

62 AND 95 = 30
0 AND 3 = 0

This can be confirmed by using the Calculator in Windows, using decimal mode.
What does these values mean? They aren't track numbers.

[blutach]

The AND command is there as a little check to ensure the highest value that the register can be is 3 (ie 4 audio tracks for 0 to 3). Strictly speaking, in this case, it is unnecessary.

So if the stream number was 6 (somehow), the AND would make it a 2. Think of the AND as a way to strip off high bits. The lower the AND, the more high bits get stripped.

Q2: Change the SetSTNs everywhere. They can be set in another VTS even and then applied to the VTS you are working on.

Regards

[Calimari]

blutah, thanks for the quick response.
Now I understand what the AND does, though I still can't place that '62 AND 95 = 30' in the maximum value philosophy.

Anyway, so far the mathematics.
It seems that deleting audio tracks and modifying the SetSTN's isn't always an easy thing to do. Another possibility is to use PgcEdit's PGC Editor, and assign another VOB audio stream number to the (empty) tracknumber, a stream number from an audio track that's present on the disc of course.

My question on this one is: will this affect the end-size of the DVD when loading it into DVD-RB? And is it necessary to strip out the unwanted audiotrack before loading it into PgcEdit?
If it is not, shouldn't it be easier to do this rather than deleting and audio track, and then set the PUO 'audio stream change' for the edited PGC?

Thanks in advance.

[r0lZ]

The audio stream numbers are easy to interpret. 0 is the first audio track, 1 the second one, etc...
Subpic stream numbers are more difficult to understand, as they have to be ORed with 0x40 (decimal 64) to be ON. Therefore, you must use 64 to enable the first track, 65 for the second one, etc... Furthermore, there are special values for specific usages. (Look at the hex digits in the command editor of PgcEdit when you change the streams to understand what I mean.)

Your trick of filling the gaps in the stream list with PgcEdit is good. I use it often myself. Take care however: if you fill a gap in the audio streams, you have to be sure that the definition in Domain Streams Attributes shares the same characteristics than the original stream. (In other words, you cannot copy a DTS stream over an AC3, for example, unless you modify also the stream attributes.)
And no, using this trick doesn't change the size of the DVD. It should be accepted by DVD-RB without problem, but I'm not sure DVD-RB is smart enough to strip the unused streams automatically.

It is useless to strip the unused streams before using PgcEdit, but it might be necessary to strip them with DVDShrink or VobBlanker before using DVD-RB. (To be confirmed!)

[Calimari]

Take care however: if you fill a gap in the audio streams, you have to be sure that the definition in Domain Streams Attributes shares the same characteristics than the original stream.

Thanks. Damn, I wouldn't have checked this if you didn't bring it up.
I suppose that's why the audio stream type pop-up windows have copy-paste? Isn't it a good idea to provide a warning or a pop-up in the next version of PgcEdit whenever a user re-assigns an audio track? I'm sure I'm not the first one who forgot to check the attributes, and I won't be the last.

[r0lZ]

Yes, it's a good idea, but not really easy to implement, as I have to verify if something has changed in the stream numbers when the user clicks on OK. Not sure I'll do it...

And yes, it's why there are copy/paste functions in DSA. I have just added them in PgcEdit v8.0.