Does VCDEasy do "autopadding" if necessary?

[vcd-surfer]

Sometimes when I load a mpeg-file into VCDEasy it says the file requires autopadding.... and you are asked if you want to continue and load the file or not.

But it does NOT say anything about VCDEasy doing autopadding itself or not if you continue and load the file.


During the creation of the vcd image the log window shows the following message:

"autopadding requires to insert additional 1021380 zero bytes into MPEG stream (due to 51069 unaligned packets of 311748 total)"


Is that a message about doing the autopadding on the file?


I'm confused about it all.
Shall i do autopadding myself by demuxing/muxing with TMPGenc before or does VCDEasy do it itself during the creation of the image?


Thanks in advance for an answer.

[jester1x]

I would highly recommend doing your demuxing and muxing with TMPGEnc. In fact, it may be better to encode to elementary streams, then mux with TMPGEnc. That's the method I use to avoid the "autopadding" message from VCDEasy. Yes, VCDEasy will autopad on the fly, but your disc may or may not play smoothly on all dvd players. In my experience, the discs that were autopadded by VCDEasy choked when trying to play them.

It's weird, but I used to encode VCDs into regular mpegs. Then, VCDEasy starting to give me those "autopadding" messages. I used what I mentioned above as a solution to this problem. Otherwise, VCDEasy does its' job very well!

[vitualis]

Autopadding means that VCDImager forces the MPEG into the blocks on a VCD... meaning it will pad with null data to make it fit.

This rarely works well.

Remultiplexing with TMPGEnc means that you are actually arranging the MPEG data into the way that VCDImager EXPECTS so no padding is required.

Regards.

[mats.hogberg]

Shall i do autopadding myself

Yes, The mpeg file has to be multiplexed as VCD/VCD Non Standard to make it suitable for creating a VCD. If not, the symptoms you describe occur. You shouldn't even try to author a mpeg not muxed as VCD. If nothing else, you don't have any idea of how big the mpeg will be after padding.

/Mats

[Greycat]

jester1x:

I would highly recommend doing your demuxing and muxing with TMPGEnc. In fact, it may be better to encode to elementary streams, then mux with TMPGEnc. That's the method I use to avoid the "autopadding" message from VCDEasy. Yes, VCDEasy will autopad on the fly, but your disc may or may not play smoothly on all dvd players. In my experience, the discs that were autopadded by VCDEasy choked when trying to play them.

Strange, with me occurs exactly the contrary: VCDs burned with MPGs multiplexed by TMPGEnc always played jerky on my standalone DVD player (Philips 615). Every 5-6 minutes we had annoying "fast-forward effects", as if the video speeds up to catch the audio. But, if I encode with TMPGEnc and multiplex with VCDMUX (of Philips VCD 2.0 Toolkit), then the VCDs play perfectly - all of them! The only weird problem: VCDEasy always says autopadding is needed. Anyway, as I said, they play *perfectly* on my DVD player, while multiplexing with TMPGEnc don't!

If someone could explain me that...

[vitualis]

It may depend on the muxing program. Back in the "old" days of VCD authoring, there were two ways that the MPEG stream could be prepared ... either with the 20 null bytes or without (20 null bytes are required to fill the 2324 bytes per sector as the video + audio only makes up 2304 bytes). There was no set standard on whether the "mulitplexed" MPEG stream should include these null bytes or not.

I've never looked at it closely, but I think that the Philips muxer does not include the 20 null bytes per sector. VCDImager, however, expects that they should be there (and TMPGEnc by default multiplexes it that way too). Thus, VCDImager will "autopad" the Philips muxed streams. In general, this sort of "autopadding" is relatively safe as it is simply putting in null data where there would otherwise be anyway -- however, I don't trust it...

Regards.

[Greycat]

Vitualis, your explanation kills one of my doubt!

I think that the Philips muxer does not include the 20 null bytes per sector.

That's it! The old VCDMUX is not including those 20 null bytes as expected by VCDImager (I checked it with an hex editor). Anyway, the autoppading is working fine (although you don't trust it), since after that all VCDs play with no problem at all (at least on my DVD Philips -- don't know about other brands)

One last doubt remains: why the multiplexing made by the option "System (Audio+Video) of TMPGEnc doesn't work well with me? And more important, I question that came to my mind right now: Is the muxer in
"MPEG Tools" different from the one used in the option "System (A+V)"?

[mats.hogberg]

System (Audio+Video) muxing shouldn't be used when creating mpegs for use with (S)VCD, and won't work as such for anyone.
As far as I can tell, the muxing that takes place in line with encoding (immediately after encoding) works exactly the same as when you do it as a separate step using mpeg tools.

/Mats

[Greycat]

If I undestood correctly, mats.hogberg, the muxing process in TMPGEnc is the same no matter the way you choose to encode-and-mux: "at once" with "System (V+A)" option or in two steps with "ES (V+A)" followed by "Simple Multiplex" in MPEG Tools. Of course it sounds logical: TMPGEnc obviously has only one muxing routine. But then you say that the first choice must be avoided to make (S)VCDs. Could you tell me where is the flaw in the "System (A+V)" process of TMGPEnc?

Just curiosity...

[mats.hogberg]

where is the flaw in the "System (A+V)" process of TMGPEnc?

There is no flaw - it's just not intended for (S)VCD use. For VCD/SVCD, use VideoCD/VideoCD Non Standard or Super Video CD respectively, when multiplexing, either as the last part of the encoding process, or when muxing is a separate step (using MPEG tools).

/Mats

[Greycat]

where is the flaw in the "System (A+V)" process of TMGPEnc?

There is no flaw - it's just not intended for (S)VCD use.

Ok. But it's indeed strange: this stream type is exactly the default of all (S)VCD templates that come with TMPGEnc...

[mats.hogberg]

If I use any of the (S)VCD tempate (and don't start encoding), I can check the stream type settings on the System tab, and if i choose VCD, it says (greyed out) MPEG-1 Video-CD, and when a SVCD template is used, is says (not surprisingly) MPEG2 Super VideoCD (VBR).

If your (S)VCD templates tells TMPGEnc to use anything of the regular MPEG stream types, something's seriously wrong.
Keep in mind that those special (S)VCD multiplexing modes are a subset of System (A+V) muxing, so on the main UI in TMPGEnc, the radio button at System (Audio+Video) is on.


/Mats

[Greycat]

If your (S)VCD templates tells TMPGEnc to use anything of the regular MPEG stream types, something's seriously wrong.

Nothing wrong with my templates, they are the same as yours. That's not the point. I'll rephrase my doubt:

You stated that "System (Audio+Video) muxing shouldn't be used when creating mpegs for use with (S)VCD, and won't work as such for anyone" and I agree with you because it really produces VCDs with playback problem on DVD players (at least with me). What you still did not explain is why does TMPGEnc use this stream type as default in its (S)VCDs templates since (we both agree) they don't work well for VCDs (And please, by "stream type" I mean the greyed-out setting in TMPGEnc main window, not the sub-setting under MPEG Settings -> System) which, of course, is set to (S)VCD properly.

[mats.hogberg]

why does TMPGEnc use this stream type as default in its (S)VCDs templates since (we both agree) they don't work well for VCDs (And please, by "stream type" I mean the greyed-out setting in TMPGEnc main window, not the sub-setting under MPEG Settings -> System) which, of course, is set to (S)VCD properly.

Frankly, I've never had any troubles with TMPGEnc (except when I've by mistake set the mpeg settings to mpeg2 program or mpeg 1 system), so I can't say I do agree.
Since System (Audio + Video) is the only setting (on the main UI) that makes any sense at all (the rest are either audio only or video only) when it comes to encoding (S)VCD mpeg, let's leave it at that. It works. Well.

/Mats

[Greycat]

mats.hogberg, first you said:

System (Audio+Video) muxing shouldn't be used when creating mpegs for use with (S)VCD, and won't work as such for anyone.

and now you are saying:

Since System (Audio + Video) is the only setting (on the main UI) that makes any sense at all (...) when it comes to encoding (S)VCD mpeg, let's leave it at that. It works. Well.

mats.hogberg, you made me even more confuse than when this discussion has begun. Those two statements of yours are completely contraditory IMHO...

Ok, let's leave it that way. You stay using System (V+A) since it works well with your model of DVD player, and I stay using ES (V+A) plus VCDMUX since it works well with my DVD player. The only thing I know for sure is that my way is more VCD 2.0 compliant than yours, and thus my VCDs will probably play without strange playback problems no matter the model or brand of DVD players I use in the future.

[mats.hogberg]

Yes, I can understand that they might seem to be, but: The first comment (System muxing doesn't work) is about the multiplexer setting (which I believed this was all about!):

If you use one of the program or System types, you'll get a non working mpeg (for (S)VCD use).

The second comment is about what's reported by the radio buttons on the main UI (which I've never given any attention until this thread).


I agree - let's leave it. We'll just confuse eachother! It works for me, and that's all that matters to me (since I keep my VCD for my own use).
I do however find it hard to believe that the encoder par preferance among VCD creators, all along has been less than adequate at creating VCD mpegs...

/Mats

[cooljoe666]

I use the latest Tmpgenc Plus and it does as good as expected except for the annoying autopadding problem. I think if the SVCD option cannot live up to standard compliance they should eliminate the option in Tmpgenc. Of course lately I have not had the autopad prompt...now I have the chinese specification popup in Vcdeasy as expected though. Even with the update scan offset checked I still get the prompt. Weird.