How to join mpeg2 elementary streams?

[NoX1911]

Since cce's built-in bitrate limiter (for credits) is corrupt i have to encode the parts manually ending up with two elementary streams.
How can i join them to use in IfoEdit?

[dgoodbourn]

You could always create a batch file and use the copy command. For example: copy/b video1.m2v+video2.m2v outputvideo.m2v
This will join the first 2 pieces of video and output it with the 3rd name. To create a batch file, just create a new text document in windows and when you name it, make sure the file extension is .bat Then right click on it and select edit. You cannow enter the command.

[NoX1911]

Thanks... worked fine!

[maa]

What then - do you re-write the time code with ReStream ?

[NoX1911]

I think IfoEdit rewrites the timecode since it is multiplexing.

[mpucoder]

AFAIK only the first timecode, if any, is used by authoring programs.
With Scenarist it is an option to use the timecode for sync, IfoEdit ignores it completely.
After multiplexing the individual stream timecodes are ignored by players.

[maa]

Hmm - how do players keep the audio and video in sync then ?

Many have compliained that DVD Lab causes sync errors but its usually with strange raw streams too. What does a program have to rely on ?

[mpucoder]

The multiplexing program may use the timecodes, assume all streams start at the same time, or allow the user to input sync information (either as a position on a timeline, or with delay values). After multiplexing the player uses PTS values, produced by the multiplexer, for sync.

[maa]

Ok, thanks mpucoder.

[RB]

Originally posted by HeldImZelt
Since cce's built-in bitrate limiter (for credits) is corrupt
Uh, are you sure? EclCCE uses this feature and it has been always working just fine. How are you using it, how is it "corrupt"?

[NoX1911]

I think EclCCE has nothing to do with it...
Find it at 'Multipass VBR Settings/Tweak...' called 'Bitrate Tweaker'. There you can enable 'Limit bitrate during ending credits' and enter 'Credits start (hh:mm:ss - why not frames?). But CCE always starts too early (over 30min in my case). Maybe its just my fault... dont know. I take values (hh:mm:ss) from ZoomPlayer or VirtualDub.

[Matthew]

Umm...try using CCE without eclcce and you'll find out pretty soon that eclcee has everything to do with it :P RB inserted that whole bit...

Anyway, when you use the values you have to be aware of timecode issues. For example, say the credits start at 2 hrs 4 mins and 37 secs.

If timecode is 00:00:00:00 you'd enter 2 4 37 but if the timecode is 01:00:00:00 (CCE default) then you'd enter 3 4 37.

[NoX1911]

I never realized its from EclCCE. Sorry for that.

My timecode is always 01:00:00:00 (cce default). So i'm always 1 hour early, right? What's the reason to change that timecode (to 00:00:00:00 for example)? Why doesn't EclCCE compensate that value?
edit: Wouldn't it be less confusing (and more precise) to use frames instead of timecode within bitrate limiter?

[Matthew]

Unless I'm mistaken the readme refers to the timecode issue.

You can change the timecode to 00:00:00:00 if you like, it won't have a negative impact.

I'm not in the habit of being sycophantic, but ECLCCE is an absolutely wonderful app, we are very lucky to have it. It's not the author's responsibility to make it babyproof.

When tweaking CCE's bitrate curve manually the input box uses timecodes not frames. Changing the input to frames would mean extra programming, I imagine.

[RB]

Matthew is right. The timecode issue is mentioned in the EclCCE manual. It would be quite difficult for me to automatically offset the credits start timecode to the CCE timecode. As for why I didn't make the credits start frame accurate - just thought it isn't worth it :) You should just set the timecode to 00:00:00:00 in your CCE templates.

[NoX1911]

I think i will stick with standard timecode and add relative values like mathew advised. You never know why they stated to not change that value to 00... but currently i'm pleased with my 500/0/1000 credits.

[mpucoder]

If you're curious why timecodes begin at 1:00:00.00 quite often, it is normal practice in the broadcast industry. The reason is that there is no negative time, and tapes (where it all started) require 2 to 5 seconds of "pre-roll". This is the area where the tape gets cue'd and held until a few seconds before airing. Just like phonograph records, video tape needs a little time to get up to speed and stabilize. So the pre-roll area will usually start at 0:59:55.00, and picture start is 1:00:00.00. Sometimes 23:59:55 was used, but there are a number of automated controllers (for very precise commercial inserts) that don't handle the rollover properly.

[dgoodbourn]

Originally posted by mpucoder
If you're curious why timecodes begin at 1:00:00.00 quite often, it is normal practice in the broadcast industry.

Yeah, 01:00:00.00 for the US and 10:00:00:00 for the UK. Other countries have their own start times. Not sure what they are though.

[mpucoder]

Originally posted by dgoodbourn
Yeah, 01:00:00.00 for the US and 10:00:00:00 for the UK. Other countries have their own start times. Not sure what they are though.

That's interesting, I wonder why the UK chose 10:00:00.00

[NoX1911]

Maybe transatlantic time change... :D
The two joined (and multiplexed) elementary streams run seamlessly and with correct time on my standalone player. PTS doing a good job. Thanks for explanation.

[dgoodbourn]

Originally posted by mpucoder
That's interesting, I wonder why the UK chose 10:00:00.00

Don't think it was a choice, more of a 'pull the names out of a bag' or a first ome first served thing! :)