Help with Vob files splicing and glitches

"Ken Maltby" <kmaltby@sbcglobal.net> wrote in message
news:NdOdne1m-pNO7_PXnZ2dnUVZ_sqdnZ2d@giganews.com...
>
> "CLicker" <CLicker@invalid.org> wrote in message
> news:dQqbm.17470$8B7.15955@newsfe20.iad...
>>
>> "Ken Maltby" <kmaltby@sbcglobal.net> wrote in message
>> news:hrqdnfjLOM0aJ_bXnZ2dnUVZ_vKdnZ2d@giganews.com ...
>>>
>>> "CLicker" <CLicker@invalid.org> wrote in message
>>> news8Gam.132$cf6.37@newsfe16.iad...
>>>> My you're full of yourself;-0)
>>>>
>>>> recap - meant to be brief, but became less than:
>>>>
>>>
>>> <Snip Clicker's version of history, the real history is all
>>> here in the thread. >
>>>
>>>>
>>>> Still does not realize that his "provided procedure" for
>>>> using join will not work to preserve orphan b/p frames in
>>>> Pierre's scenario.
>>>>
>>>> Hopeless.
>>>>
>>>
>>> Apparently, Clicker is not aware that VideoReDo (VRD)
>>> is a "frame accurate" editing tool. There are no "orphan
>>> frames" created in the process I described. (This assumes
>>> you haven't used the program's preference settings to have
>>> it function as a GOP accurate editor.)
>>>
>>> Luck;
>>> Ken
>>>
>>>
>>>
>>
>> What a [expletive deleted] ;-0) OK, it wasn't an expletive,
>> I was thinking . . . buffoon.
>>
>> p/b frames at the beginning of a file which precede the first
>> i frame are orphaned. Have you been reading this thread or
>> not?
>>
>> The OP's query regarding his "glitch" when concatenating two
>> files was properly answered by you in suggesting VRD -
>> regardless of which version.
>>
>> When "combining" two files which have been created by
>> arbitrarily splitting one, VRD of any flavor will concatenate
>> the orphaned p/b frames, if any, at the beginning of file two
>> using the last i frame of file one to do so. When "joining,"
>> using VRD of any flavor, it will drop those frames from file
>> two - because that is how join works. (Don't blame me for
>> the semantics, you seem to know the author)
>>
>> So , apparently you answered Pierre properly without even
>> knowing why your answer had worked! "Luck," seems an
>> appropriate sig after all;-) And, since you did not tell him
>> which to use (combine or join), it's fortunate that he's
>> knowledgeable enough to read instructions, because he got it
>> right.
>>
>> All your blather about how to make "join" work to accomplish
>> this is total nonsense.
>>
>> If you process file two of a split, all by itself, and there
>> are p/b frames preceding its first i frame, how the hell can
>> the program do anything but discard them? Going through your
>> machinations accomplishes nothing in this case - which was
>> the OP's issue and jmc's observation regarding the issue.
>>
>> Further, if you ask VRD to join cuts from a single file being
>> edited (notice there is no combine availabe in this case) and
>> any cut does not start on an i frame, VRD will drop the
>> leading orphan p/b frames from that cut because it has no i
>> frame from which to reassemble them.
>>
>> You're just blinded by your own opinion of yourself!
>>
>> Good luck,
>>
>> CLicker ;-0)
>>
>
> You are misstating how VRD works, as well as how
> things exist in the real world. You can't have a valid
> file made without complete GOPs, even if some are
> smaller than the others in the file, they are constructed
> with the proper associated files included (in the case of
> "closed GOP" files) or just not there to be made "orphans",
> in the case of an "open" GOP structure. One of VRD's
> exceptional features is that it will reencode the GOPs as
> needed to make frame accurate cuts possible, "open" or
> "closed" GOP structure.
>

Pedantry aside, this is absolutely what I would expect. But it
is not VRD's issue, if a file begins with b/p frames what else
can it do but discard them until it encounters the first
i-frame. That is the crux of VRD's help screen definition of
join. And the crux of our disagreement.

Despite snideness on my part, I don't have any issue with your
understanding of VRD, I even did a cutting, joining experiment
from the time line this AM and there is no difference in VRD's
processing of cuts from the same time line, whether I use "Save
as" or the joiner to "combine" the 2 cuts. That's because VRD
has access to the i-frame of the second cut and can convert the
selected starting p/b frames to a proper i-frame when using the
joiner. The number of frames selected and number of frames
output is the same in both cases.

We've only been in disagreement regarding multiple files, any of
which may (though should not) start with orphans. Although I
personally have not come across a file that NEEDED to be
combined rather than joined, I defer to the author's statement
as to why there are two methods. Yet, the OP and jmc have seen
differing results, the former in Premier Elements vs. VRD, the
latter in VRD itself, between the two choices.

The author doesn't, nor do I, assume that all files to be
processed were created by VRD from good input. Nor do either of
us expect VRD to be able to reconstruct missing i-frames.

I certainly expect VOB files to begin with i-frames and I've yet
to see my capture devices split files in an arbitrary manner.
As long as things go as expected, one can select *either* join
or combine when prompted. But it behooves the user to
understand the author's point of having the option.

Regardless, I see no reason whatever to go through any
machinations regarding combining or joining two files or two
segments of files other than what the program already makes easy
directly from the source material - be it a single or multiple
files. It can not reconstruct missing i-frames.

As to combining contiguous VOB files or contiguous capture
files, I'll continue to specify "combine" in the Enhanced Plus
Features option page. To date, I've had but one reason to join
non-contiguous files - other than inserting black GOPs at times,
which is a good use of the "joiner." That reason was to join Mo
Binder titles from the James Bond series. There were no
orphans.