Hi there,

I read a lot of the threads about autopadding and remuxing with either bbmpg or tmpgenc and tried about all I can think of to "fix" my mpg file so to prevent it from being "autopadded on the fly" by VCDEasy.

Scenario:
VCD mpg file that requires autopadding (according to VCDEasy)

So I remux it first. Thing is that after I do a simple multiplex in tmpgenc (V 2.510.49.157) the audio is WAY out of sync! There weren't any noticeable sync problems before muxing, however the original file already contains a padding stream of 789 KB size (tmpgenc named it video-0xBE.dat and it contained just one long line of spaces)

I then tried bbmpg, same result. Audio is out of sync after muxing. I tried MPG Corrector. Audio out of snyc. Last I tried VCDGear, it "fixed" and "padded" the file, but that fixed mpg file no longer is accepted by vcdeasy as valid mpeg file... Lastly I re-rendered it out with VEGAS: audio was out of sync then, too, just as the rest.

Since vitualis said that autopadding is highly undesireable (and I believe and agree with him I wonder what other options I have to prevent this or what settings it takes to "fix" the padding without losing the audio sync?

Thanks a lot for your time!

Cheers
Alex (Eke)
---
here's the mpg details:
MPEG1, PlayingTime=2559.225s, Bitrate=1411200bps, PtsOffset=0232s, 191944 packets

Video Stream: Motion Video, 352x240, 29.97003fps (NTSC), 1150kbps
Audio Stream: Audio Standard MPEG layer2 Stereo, 44100Hz, 229376bps
---
the vcdeasy warnings:
mpeg stream will be padded on the fly -- hope that's ok for you!
autopadding requires to insert additional 627280 zero bytes into mpeg stream (due to 31364 unaligned packets of 191944 total)
---
and here the VCDGEAR LOG:
Setting multi-file output convention to '_%02d'
thread priority : normal
processing method : mpg => mpg
Setting read size to: 2324
Setting write size to: 2324
processed Track 1 : 0 hours 0 mins 47 seconds
15 MPEG block correction(s) applied
31308 Blocks padded
---