Replacing all cells at once

[Kayaker]

I'm asking if this could be done.

I'm encoding LPCM audio to AC3, and to do this I did the usual way, pgcdemux by PGC with celltimes.txt, encode to AC3, remux with muxman and replace PGC with VobBlanker ( I haven't tested yet replace PGC with PGCEdit )
As far as I can see VobBlanker replaces all the cells in a PGC except the reused ones.

The question is, is there some way to, for instance extract/demux all the cells some way in one pass, change audio, video, subs, what you need, remux everything with muxman, and replace (with some kind of celltimes prepared before in the demuxing process) _ALL_ the cells together ?
I mean not one PGC at a time ?
skipping the cells reused of course.

In the demuxing process we need to build some kind of "map" or table (to replace back the remuxed cells where they belong) and a celltimes.txt to feed to muxman of course.

Sorry is this is kind of stupid question.

Thanks.

[blutach]

You can build the PGC structure with muxman to imitate the original one (at least with muxman pro). After that, you can use PgcEdit's File --> Replace VTST Titles.

Regards

[Kayaker]

Can PGCEdit replace an whole VTST ?
Unlike VobBlanker that can only replace at PGC level ?

How does it match the cells ? without a previous table ?
I suppose the structure must be exactly the same.

Gotta try it. thanks.

[blutach]

What it needs is a structure with the same number of PGCs - so, if you have a VTS with just 1 PGC, that is simple (and fast). Or 2, where one is a small extra, which can be imitated. It is very fast. Read the screens as you go through. You can't hurt anything. The originals are moved to backup. I'd make an incremental backup first though.

http://www.digital-digest.com/~blutach/gl2.gif

Regards

[r0lZ]

PgcEdit cannot replace at the cell level. It replaces the VTST domain as a whole. The replacing VTS must have at least as many Titles than the original VTS.

The perfect situation is same number of Titles, PGCs, and cells, programs and chapters per PGCs. In this case, PgcEdit can (optionally) keep the data from the original DVD whenever possible: VM commands, cell command, some cell flags, stream attributes, etc... It is therefore possible to re-import easily one (or several) re-encoded titles without modifying the navigation at all. (I did that this way to simulate the old VTS replacement method with IfoUpdate. IMO, my method is easier and faster.)

On the other hand, if the replacing VTS has not the same structure than the original, it is not possible to keep the original structure, and you will have to modify some things yourself. For example, if the replacing VTS has more titles than the original one, the first titles will replace the original ones, and the remaining titles will be added to the compilation, using the tables and VM commands of the replacing VTS. Of course, you will have to modify manually the navigation of the original DVD to call them and return to the menu. Similarly, a different number of programs or chapters implies that PgcEdit will not be able to keep the original chapters.

PgcEdit cannot replace a VTS if the replacing VTS has fewer titles than the original, as it will be necessary to remove some titles from the original DVD, and to renumber the other titles to fill the gaps. In this case, you should manually remove the additional titles in the original VTS or add dummy titles to the replacing VTS before calling the function.

Note also that the import function of PgcEdit works in place, and the original VOBs are (optionally) moved to the backup folder. You don't have to recreate the DVD. Also, if the replacing VTS is on the same HDD and you don't need to keep the replacing VTS intact, you have the option to move the replacing VOB files instead of copying them. This function is therefore extremely fast.

[Kayaker]

Blue & r0lZ, very clear.

But therefore the limitation would be in the demuxing. PGCdemux can only do it by PGC or VOBId.

Gotta think about it.

Thanks.