Question for multiplexer experts!

[Greycat]

I have some doubts about VCD 2.0 multiplexers.
This is the way I used to make MPGs for VCDs:

- Encode with TMPGEnc (2.58.44.152), stream type: System (Video+Audio) and several GOP structure settings.
- Burn with VCDEasy (1.1.5)

Result: All VCDs played with annoying motion problems on my standalone DVD player (Philips 615): more precisely, every 5 to 7 minutes the movies speed up and/or slow down for half a second (the video apparently tries to catch the audio). Clips with less then 6 minutes generally don't have problems -- but some times they do. Movies with more than 6-10 minutes always have those problems.

Then I started doing this:

- Encode with TMPGEnc, stream type ES (Video+Audio) and several GOP structure settings
- Multiplex with VCDMUX (from Philips VCD 2.0 Toolkit). This multiplexer is known to be fully VCD 2.0 compliant.
- Burn with VCDEasy; now all MPGs require autopadding on-the-fly.

Result: Despite the autopadding, all VCDs play smoothly on my DVD player. No more motion problems of any kind!

I could be satisfied and stick with this solution, but lots of people in this forum claim that padded MPGs must be avoided because something is wrong with the way those files are being multiplexed and hence VCDs made with them may or may not play correctly on some DVD players.

My doubts:

1) Isn't TMPGEnc's multiplexer fully VCD 2.0 compliant?

2) On the other hand, if VCDMUX is fully compliant, why do MPGs multiplexed by it need to be padded on-the-fly by VCDEasy (vcdxbuild)?

3) After all, why do all VCDs made by the first method play with motion problems on my Philips DVD player while by the second one (which MPGs always require autopadding) play perfectly?

I'm very puzzled with this. I've posted almost the same doubt two or three times in this forum and nobody gave me any answer. This is my last attempt.

[spectroelectro]

I'll give it a try, no doubt earning a slap in the face for my trouble.
The answer is that there's no reason to mulitplex or demultiplex encoded MPEG-1 or MPEG-2 files. TMPGEnc offers the facility to use an external audio MPEG encoder. So if you don't like the TMPGenc audio encoder (and it's not great) you can use TooLame from within TMPGenc.
Once you encode the audio + video stream, there's not reason to demux it. I have never had any of the problems you describe because I line up all the AVIs, edit 'em together into one long file, then run TMPGEnc to produce a single large MPEG-1 file.
Then I burn the MPEG-1 file to VCD CD-R using Nero.
Never any problems with playback, regardless of the DVD player.
The solution seems simple: avoid muxing or demuxing. Any time you edit encoded compressed digital files, you're always asking for trouble. Don't do it. Just capture to AVI, edit the AVIs together into one large AVI, run TMPGenc (with TooLame or Fraunhofer or some other audio codec called externally if you want), then burn the resulting MPEG-1 file to VCD.
Under what circumstances would anyone ever want or need to mux or demux MPEG-1 files to produce a VCD...?

[lordsmurf]

I say it's not the mux/demux, but something else. Look at the capture, encode, burn, media, etc.

[Greycat]

spectroelectro, you said:

The answer is that there's no reason to mulitplex or demultiplex encoded MPEG-1 or MPEG-2 files.

Once you encode the audio + video stream, there's not reason to demux it.

Sorry, but I'm not demultiplexing any MPEG-1. Where did you read that on my post?

TMPGEnc offers the facility to use an external audio MPEG encoder. So if you don't like the TMPGenc audio encoder (and it's not great) you can use TooLame from within TMPGenc.

Sorry again, but I have no complaints about the audio quality (the main reason for changing audio encoders).

Let me try to rephrase my doubt about multiplexers:

Using TMPGEnc's more-commonly-used multiplexing method (System Video+Audio) to produce "ready-to-use" interleaved MPEGs (that happen not to require posterior autopadding) always gives me VCDs that have playback problems (fast-forward and/or slow-motion effects from time to time) on a DVD player.

On the other hand... using TMPGEnc just to create elementary streams (ES Video+Audio), then using VCDMUX (the fully VCD 2.0-compliant mux) to multiplex them into proper interleaved MPEG files (that I-don't-know-why happen to require posterior autopadding) always gives me VCDs with no playback problems at all.

So, summing it up even more: The first case (no autopadding needed = desirable) do not work properly, and the second case (autopadding needed = undesirable) does work.

Please don't tell me it isn't puzzling!

=================

lordsmurf:

I say it's not the mux/demux, but something else. Look at the capture, encode, burn, media, etc.

lordsmurf, if it's not a muxing issue, why using VCDMUX instead of TMPGEnc's internal mux did solve the playback problem (creating another one however, i.e. requering autopadding)? And I don't think it's capture, encode, burn or media, since the second method (the one that requires autopadding) solved at least the playback problem, using the same source video, the same encoding method, the same burning software/hardware and the same media!!

I thought it could be my DVD player... but it's a Philips, from the company that created the VCD standards... it's hard to believe they would make a player with compatibility issues with their own standards... (and I tested my VCDs on another player of a friend of mine, same model, with same results)

Thanks in advance for any enlightening answer.

[xtreemkareem]

I have always used TMPGenc to encode as Sytem (Audio + Video) single mpg, and I have burned using Nero (works fine) and VCDEasy (does the stupid autopadding thing, nothing seems wrong) and I never noticed many playback problems, except when encoding as NTSCFilm as opposed to NTSC... I forgot which one authoring program I used in which I got playback problems (despite perfect PC playback.... you know... maybe it's just NTSCFilm playback that's the problem, never mind!). If TMPGenc gives you problems, as opposed to using another Multiplexer, use the one provided in MPEG tools... besides, it gives you all the specs of the Audio and Video ES before multiplexing so you can tell whether or not you want to multiplex as MPEG-1 VideoCD Standard or MPEG-1 VideoCD Non-Standard. But be warned. THe final mpg will be larger than both ES combined if you choose MPEG-1 VideoCD Standard... that may be your problem..... make sure that your system setting is set to VideoCD Non-Standard (most players won't give a hoot as long as you author/burn corretly so give it a try). Works for me. Try and get back to me.

[Greycat]

xtreemkareem:

maybe it's just NTSCFilm playback that's the problem, never mind!).

That's not my case. I made tests with NTSC template (29.97 fps MPEGs) and with NTSCFilm template (23.97 fps IVTC-ed MPEGs) and both give me playback problems...

If TMPGenc gives you problems, as opposed to using another Multiplexer, use the one provided in MPEG tools...

I don't know where to find that multiplexer you suggested.

Ops, shame on me. Of course you're talking about TMPGEnc's MPEG Tools!

Are you telling me that there is a difference between the multiplexer used by the option "System (Audio+Video)" and the one in MPEG Tools? I thought they are the same...

But be warned. THe final mpg will be larger than both ES combined if you choose MPEG-1 VideoCD Standard... that may be your problem..... make sure that your system setting is set to VideoCD Non-Standard

I don't know whether I want to make non-standard VCDs and create more doubts and maybe problems than I already have...

Anyway, using VCDMUX solved all playback problems. It's actually the autopadding stuff that is driving me crazy. I don't like to do something without knowing why it's not 100% correct (and it should be!)

[vcd4ever]

Greycat,

Tmpgenc is not capable of producing a fully vcd 2.0 compliant file and it doesn't matter if you are encoding or multiplexing with tmpgenc. The vcdmuxer doesn't pad the audio because the philips vcd 2.0 toolkit program does the audio padding instead, and this is the reason why vcdeasy is padding the audio. Some players that supports the vcd format requires that the vcd is fully vcd 2.0 compliant for playing it without any problems. Your dvdplayer requires this and because the vcdmuxer in combination with vcdeasy is fully vcd 2.0 compliant it works.

vcd4ever.

[RabidDog]

have you tried taking apart a "good " vcd ( sound and audio) and then multipleex them back together with Tmpgenc? Also auto padding is only really needed for older dvd players, to maintain a certain minimum bitrate, if your player is newer(less than three years old) then dont bother with autopadding.

[vcd4ever]

have you tried taking apart a "good " vcd ( sound and audio) and then multipleex them back together with Tmpgenc?.

Yes, i have tried that from a original vcd released by philips and tmpgenc did not multiplex the elementary streams to a fully vcd 2.0 compliant file.

Also auto padding is only really needed for older dvd players, to maintain a certain minimum bitrate, if your player is newer(less than three years old) then dont bother with autopadding.

The audio padding has nothing to do with the dvd player being older or newer because the vcd 2.0 spec requires the audio to be padded. Also if you import a mpeg file without the audio padded in a vcd authoring program the vcd authoring program will pad the audio.

vcd4ever.

[Greycat]

vcd4ever, thanks for your reply. My original post has three doubts and you answered all of them.
I think you right, my DVD Philips is demanding a fully VCD 2.0 compliant VCD (and I cannot expect less than that from a Philips!)

Do you (or anybody else) know an external multiplexer that is fully VCD 2.0 compliant which resulting MPEGs do not need autopadding?

[BJ_M]

doesnt vcdmux still work ? Its in the old phillips vcd 2.0 toolkit

(i dont deal with vcd much) -- you can get it here anyway and on this (dvdrhelp) site is full instructions ..

http://www.icdia.org/sw_pc/vcd2tk.zip



info found here http://www.icdia.org/sw_pc/vcdtools.html

[Greycat]

VCDMUX works and I use it, but this is an old muxer that (see vcd4ever reply) doesn't pad the audio, and I want to avoid the autopadding that VCDEasy makes on-the-fly (people say it's not good...)

[vcd4ever]

I want to avoid the autopadding that VCDEasy makes on-the-fly (people say it's not good...)

The audio padding done by vcdeasy can cause playback problems, but this is not because the audio has been padded by vcdeasy. The problem is that vcdeasy has padded the audio on a imported mpeg file that was not fully vcd 2.0 compliant. This problem also happens if you imported the same mpeg file in nero or roxio vcd creator or any other vcd authoring program (exept philips vcd 2.0 toolkit).

vcd4ever.

[Greycat]

Ok.

But anyway... is there any other muxer that I can use which is completely, absolutely and full-proof VCD 2.0 compliant and more recent than VCDMUX? (The one in bbMPEG, perhaps?) As I said, I want to avoid that autopadding stuff.

[vcd4ever]

Greycat,

I have been using the vcd format now for 5 years and i haven't yet found any muxer that is fully vcd 2.0 compliant with the audio padded.

vcd4ever.