Replace a Cell then Rebuild time map??

[meRobs]

To save space the credits at the end of a movie may be trimmed or deleted if in a cell on their own. However, I would rather replace the cell containing the credits with a customized version - maybe involving audio fade and the inclusion of a personal-touch clip of my own. I have Adobe Premier to edit.

So, (1) I extracted the credit cell with VobBlanker to VOB, (2) since Premiere dislikes VOBs and AC3 (2) I converted the VOB to AVI (PCM) with Kate's Toolkit and (3) imported the AVI into Premier for editing and when done exported it as M2V and WAV. Then, (4) in Super I converted the WAV to AC3 6-ch to match the original.

(5) I used the M2V and AC3 in an authouring App to create a VIDEO_TS folder. (6) I re-opened the original disc in PGCedit and then via Tools opened VobBlanker and replaced the cell with the new VIDEO_TS > VTS_01_1.VOB.

(7) Once processed I returned to PGCedit only to find the new cell had 2 'cells' ?? So, I deleted the last cell (a blank) in PGCedit and tidied up with FixVTS.

(8) in PGC Editor the cell times looked appropriate but to be safe I hit 'DVD > Rebuild time maps', which took 2 min, only to find there was no change!

So, if you can pardon the tortuous path I had followed, my question is: is a Rebuild of time maps necessary?

Maybe someone might also answer: why did my authoring App (Encore) add a blank?

Or, is there an easier path?

Sorry for the length of this thread.
If you get this far : thanks
Robin

[blutach]

The time maps rebuild is necessary if the sectors had changed (which they most likely would have). However, VobBlanker does have a Time Map routine built in, so you were probably OK. Any time you delete a cell, even a tiny one at the end, PgcEdit tells you to rebuild the timemaps. You can ignore this if it is the last cell and it is tiny (the authoring app probably adds this by default).

You can use the timemap plugin to "verify the time map coherence" (this will be built into the main GUI of version 9).

BTW: Steps 1-4 must be torturous for you. All that conversion and loss of quality! For fades, edits and fancy stuff, consider Womble Video Wizard DVD. Feed in m2v and ac3 (from PGCDemux) and output the same - it is very quick; only the changed bits are re-encoded. Remux in (incl the subbies, if any, with muxman - step 5).

Regards

[meRobs]

VobBlanker does have a Time Map routine built in, so you were probably OK.
BTW: Steps 1-4 must be torturous for you.
Remux in (incl the subbies, if any, with muxman - step 5).


Are you saying that since I did a Replace (a cell) in VobBlanker that it would automatically adjust the time maps?

Actually, steps 1 to 4 are quite quick and Premiere allows me to be creative.

Also, I had forgotten about Muxman!
Maybe if I used it to remux instead of Encore (also quick) I would not have had the problem of an extra cell.
I shall have a bash!

Thanks
Robin

[r0lZ]

IMO, the extra cell is not a problem. When it is absent, I usually add one with PgcEdit. Associated with a new chapter point, it allows the user to skip to the end of the movie with the Next Chapter button. Without that last chapter, on most players, the Next Chapter button cannot be used when the last chapter is playing, and on some (luckilly rare) players, the nav jumps to the next Title of the DVD!
Anyway, the additional cell has certainly been created intentionally.

About the time maps: PgcEdit must scan all VOB files of the title to rebuild the time map. (And it modifies it anyway, without verifying if the original values were identical.) That's a time consuming procedure, and it's why, if you know what you are doing, you can skip it. The "verify time map coherence" function examine the IFOs only, and warn the user if it finds major discrepancies, but cannot verify if all values of the time map are correct. On the other hand, this function is very fast.

VobBlanker must rewrite the VOBs anyway, so it rebuilds the time maps anyway when it knows that it's important (such as after having replaced a cell.) BTW, it uses a slightly different method than PgcEdit, and there are some minor differences in the maps, but both methods are OK.

[Alex_ander]

Also, I had forgotten about Muxman!
Maybe if I used it to remux instead of Encore (also quick) I would not have had the problem of an extra cell.

100% true, it will only create cells by celltimes file. Other authoring applications (even TDA1.6) use some strategy in selecting number of cells for programs/chapters. Not a big problem, but needs attention and extra steps at replacement.

[blutach]

Associated with a new chapter point, it allows the user to skip to the end of the movie with the Next Chapter button. If, and only if, there are no VOB UOps prohibitiing such an operation...

Regards

[meRobs]

As for the 'blank cell' there are two issues: (1) for the few DVDs I have examined, the Credit's cell is followed by a blank, probably for the reasons rOlZ gave, and I leave it in place; (2) muxing by Encore adds a blank to the new cell, also for this reason, but not acceptable by VobBlanker when a cell is replaced. It had to be deleted by PGCedit.

I tried Muxman and, as Alex_ander said, it does not add an extra cell.

As for PUOs: I tend to remove all.

So, all is now clear!
Thanks folks
Robin

[Alex_ander]

As for the 'blank cell' ... It had to be deleted by PGCedit.

Since that cell can be useful, I think it would be possible to split the last cell of the old movie in VOBBlanker before replacement.

[meRobs]

Alex_ander and I have a misunderstanding.

In my original disc, the last 3 cells may have been c28, c19 and c20, say, where c20 was a blank (and useful).
Cell c19 had the credits and needs editing, so I extracted it and modified it to M2V/AC3.
When muxed in Encore it gave one VOB that had two cells: a true replacement for c19 and an extra blank.
If muxed in Muxman, the resultant VOB has only the one (edited credits) cell.

When, the VOB from Encore is used to replace c19 in VobBlanker, PGCedit then screams that it is illegal (too many cells) and I delete this blank -- still leaving the original blank c20.

Fortunately, the output from Muxman has only one cell, suitable for replacing c19, and all is well.

Has Alex_ander misunderstood me or do I not understand why he suggests splitting the last cell (c20, a blank - how?)?

Regards, Robin

[meRobs]

2 related issues:

1) if I Extract a cell using VobBlanker without first removing unwanted audio streams (assume there are at least 2), which one enters the VOB? How do I tell?

2) I have Muxman ver. 0.15R, which opens too small: I need to drag it out to see the browse and 'Start' buttons every time. And after a single use, it auto closes! Is there a version without these idiosyncracies?

Thanks
Robin

[blutach]

1) They are both there.

2) Muxman 1.1.4 Pro! See here (http://www.mpucoder.com/Muxman/versions.shtml) for a comparison (the latest demo version is 0.16.6 anyway).

Regards

[meRobs]

Thanks Les shall get.
Robin

[meRobs]

Because I wish to use Premiere to edit and add my personal touch to the replacement clip for the credits, I want to use the method I described above. This path is easier than it looks and in my 50" plasma TC it is hard to spot any loss in video quality. However, the audio is the problem!

The main problem is that the original cell often has multi-audio streams and my method results in only one. Of 3 discs I tried, one ended up with the second stream (commentary).

Since I need to DELETE all but one audio stream, the use of VobBlanker for stripping does not appear clear cut! After the strip, it and PGCedit still see the unwanted stream, as does DVDshrink, even though the latter sees the stream as 0 MB.

Question: what is the best method of Extracting only the one stream I want. I do not mind if the unwanted streams are not fully deleted (can complete in DVDshrink when I compress), although, there may be a problem with unmatched attributes when Replace is done!

Any comments?
Thanks
Robin

[r0lZ]

PgcDemux can extract the audio streams of any PGC, chapter or cell.

Some additional remarks:

- The streams are defined at the PGC and domain level, not at the cell level. Therefore, if you replace a cell with a replacing cell containing less streams, the missing streams are simply silent, but they remain in the stream definitions, and the user will still be able to select them.

- If you are really re-authoring a menu, there should be only one audio stream, as only the title domain can have several audio streams. (However, it is possible to author a menu with BOVs in a title domain.)

- When you replace a cell with VobBlanker, it must have exactly the same structure than the original domain: same number of streams, in the same order, and with the same attributes. (BTW, the order of the streams is determined by their IDs. When they have been extracted by PgcDemux, the alphabetical order of their filenames is the right order to remux them.)

So, if you don't need to modify the audio, you should extract ALL audio streams of the cell with PgcDemux, and remux them in the right order with Muxman. Of course, you can modify all streams before remuxing them, but be sure to encode them using the right parameters.

[blutach]

Once you strip in VobBlanker, reload in PgcEdit and it will tell you if the streams can be removed from the IFO. Or run the DVD --> Fix # of streams function. Usually, you can delete the streams from the IFO (unless there are other titles in the domain using the stream).

Regards

[meRobs]

Thanks rOlZ, however, is there not a contradiction here?

First you state that "if you replace a cell with a replacing cell containing less streams, the missing streams are simply silent, but they remain in the stream definitions, and the user will still be able to select them".
Then: "... replace a cell with VobBlanker, it must have exactly the same structure than the original domain: same number of streams, ..."!

Hope I haven't been delaying work on the new PGCedit!

Regards
Robin

[blutach]

Just cos it needs to have the same structure, doesn't mean the stream needs to have anything in it.

Regards

[r0lZ]

Well, IIRC, VobBlanker is smart enough to warn you if it finds a different number of streams, but it can proceed anyway. The missing streams are simply missing in the replaced cell, and therefore will be silent when that cell is playing. Also, VobBlanker cannot verify if you have rebuilt the cell with the streams in the right order.

[meRobs]

Not being familiar with the nuts & bolts of DVD programming, I need to confirm what you guys have said!

Suppose I had a movie VTS that had 4 audio streams and 6 sub-picture streams and instead of stripping 3 audio and all the sub-picture streams I, simply, replaced one cell with a cell that had only one audio and no sub-picture.

Then, from what you say, I could leave things like that?
Moreover, the single audio stream in the new cell would be audio 0?

However, it would be better if while DVDshrink did the compression it deleted (not include) the 3 audio and all sub-pics?

Thanks

[blutach]

Yes, but you better make sure the language and attributes in track 0 for the replaced cell matches that in the rest of the movie (ie It would be peculiar to have Italian in your last cell for track 0 if for the rest of the movie, track 0 was English).

Regards

[meRobs]

Yes Les, I realised I had to be careful.

So, I'll take your answer as a 'yes' to all 3 questions in my previous response.

Regards
Robin

[blutach]

Yes (yes, yes)! :)

PS. Sorry about the Swans last night. Wish the 'Pies luck today!

Regards

[meRobs]

Thanks for all your help Les
Regards
Robin

[r0lZ]

I disagree, blu!

Suppose you have something like that:

VTS 2 VOB streams attributes (VTS_02_0.IFO): 4 Audio, 0 Sub-picture streams.
- Video: 16:9 PAL (720x576), MPEG-2 (VBR), Automatic Letterbox (letterbox: not cropped)
- Audio 0: en, unspecified, AC3 (6 channels), Unspecified application mode
- Audio 1: fr, unspecified, AC3 (6 channels), Unspecified application mode
- Audio 2: es, unspecified, AC3 (6 channels), Unspecified application mode
- Audio 3: en, director comment, AC3 (2 channels), Unspecified application mode

The stream IDs are respectively 0x80, 0x81, 0x82 and 0x83 in the VOB files.

Now, you extract the streams from a specific cell of a title, then you edit only ONE audio stream (say it's stream#1, french) and remux it with muxman. Muxman will create a new title with this:

VTS 1 VOB streams attributes (VTS_01_0.IFO): 1 Audio, 0 Sub-picture streams.
- Video: 16:9 PAL (720x576), MPEG-2 (VBR), Automatic Letterbox (letterbox: not cropped)
- Audio 0: fr, unspecified, AC3 (6 channels), Unspecified application mode

The stream ID will be changed from 0x81 to 0x80.

When you replace the cell with VobBlanker, it will probably complain as there is fewer streams than in the original, but since the first audio stream of the original title (ID 0x80) has the same characteristics (AC3 6 channels...) than the first stream of the replacing cell (same ID 0x80), it will be able to continue anyway.

When you play the PGC, the ID of the stream that is playing cannot change (except if the user changes explicitly the current stream.) Therefore the english audio stream will be replaced during the playback of the replaced cell by the modified french stream, as the player continues with the stream having the same ID. And if the user selects stream #1 (fr), the replaced cell will be silent, as there is no stream with ID 0x81 in the replaced cell. Same thing for streams #2 and #3.

So, to be on the safe side, you have to strip out all streams but one from the entire domain before extracting and replacing the cell.
You can also keep all streams in the original DVD, and provide all streams (modified or not) when muxing the replacing cell. Of course, if several cells have the same attributes (except the language code and extension) like streams 0, 1 and 2 in my example, you can use the same modified stream several times, but in my example, that doesn't work for stream #3, as it has a different number of channels.

The same thing is right for the subpic streams, but since all subpic streams have the same characteristics, it is always possible to replace a stream with another one.

Note also that the problem is different if you want to replace a stream in a whole PGC rather than in a specific cell. As long as the stream characteristics are identical in the original PGC and in the replacing PGC, you can use only one stream, and modify the PGC decoding streams with PgcEdit to duplicate the same stream "virtually" by assigning it to all streams defined in the domain. In other words, no matter what stream has been selected by the user, the stream with ID 0x80 will always play. But that's not what meRobs wants to do.

[blutach]

The stream ID will be changed from 0x81 to 0x80.
Of course! And therefore, you are right, as always :)

Regards

[meRobs]

My guess is that rOlZ had just mis-interpreted what Blutach had said when he gave Yes, Yes Yes to my 3 questions. The disagreement seems to relate to a "Yes" to my question "single audio stream in the new cell would be audio 0?".

From what Blutach had said earlier, I assumed he meant that whatever Audio I had placed in the new cell (En or It, in his example), it would sit in stream 0 (if Italian, it would sound odd), so a Yes.

I had not meant in my question that the new cell with a single stream would always have audio from the original stream 0!
The comments by rOlZ seem to address this question!

Once again, I may have got this wrong as well?

Regards
Robin

[blutach]

Either way, I hope you now understand what will happen and can plan accordingly. :)

Regards

[r0lZ]

My previous post was an answer to blu's post #20.
When you ask:
Then, from what you say, I could leave things like that?
I would say NO, for reasons that should be obvious now.

Of course, if you don't need the audio in the replaced cell when playing stream #1, 2 or 3, replacing the cell with a new cell containing only one stream is OK, but in that case, it might be better to strip off all streams but one, as I suggested.

To your other questions, the answer is yes.

[meRobs]

Thanks for all your help folks.
You have obviously had enough of me and I am finally confident now to replace credits-cells. I have just tried 4 different methods and have settled on one.

Thanks again.
Robin

[blutach]

You have obviously had enough of me
Not at all - please ask anything that is concerning you.

Regards