I'm creating a VCD using VCDEasy, using an mpg file created using dvd2svcd and bbMPEG (VCD settings). I'm using VCDEasy to get better control of chapters, etc.
When I load my mpg file into VCDEasy, I get the Warning "bbMPEG_Muxed_File00.mpg" This MPEG file requires autopadding... you may be unable to watch it correctly... Do you want to add this file anyway? I say yes and proceed to build the image and burn.
The VCD burns fine, and plays fine in my standalone. I notice this in the log:
autopadding requires to insert additional 901740 zero bytes into MPEG stream (due to 45087 unaligned packets of 275246 total)
Everything is standard in the VCD creation, except I don't downsample audio from 48k to 44.1k. I'm setting the frame rate at 23.976 (NTSC Film) and this is a standard VCD setting.
Since my output 'works', I'm not overly worried, but ... it's always good to get rid of errors. Any ideas why I'm getting this error?
+ Reply to Thread
Results 1 to 5 of 5
Probably you have to fix the blocksize from 2048 (or something else) to 2324.
Previously I have made over 200 (S)VCD's. Never got a comlain of any software. And they all played. Now with the new VCDEasy I get the same message with every film I make.
VCDEasy nor TMGGenc Tools cannot fix this. I found VCDGear can correct this perfectly. After VCDGear corrected the problem (which wasn't a problem befor ) VCDEasy loads the MPEG without problem/error and burns it.There R 3 sides on every story;
Yours, Mine and the truth
Is this 'blocksize' an element of the CD itself, the MPEG file, or what?
Presumably, since your VCDs and mine both played OK before, and continue to do so, this is not a very strict 'rule' (the need for 2324). Is it that some new version of VCDEasy suddenly started to enforce a 'rule' or 'standard' that it previously ignored?
Well I've been searching/reading about this issue. Still unsure exactly what's going on, but ... seems like the 2324 number is the number of data bytes allowed in a non-error-corrected sector on a (S)VCD. If your data packets are not this size, then they are padded to fill this size, since they need to be aligned on sector boundaries.
I found this on a dvd2svcd page:
Pad VCD audio
VCD audio sectors are specified to be 2304 bytes long. If this option is checked, the sectors are zero padded to 2324 bytes. Some Video CD authoring software expects the padding to be present and some do not, if an authoring program does not accept files made with this option enabled, disable it and and it should be accepted.
But anyway - since VCDEasy is detecting this condition, and is doing the padding on the fly, is this a real issue - isn't VCDEasy simply 'fixing' the problem for me - doing the same thing that I would be doing elsewhere if I 'fixed' it earlier in the process? But then why does VCDEasy warn me that 'you may be unable to watch ...'? And why are you saying that VCDEasy cannot fix this problem - it seems to fix it by autopadding during the process.
Am I still missing the point here? Thanks!
I had this problem when I was cutting some MPEGS and reordering them. The problem occured on MPEGS where the audio finished, only approx 250ms, before the video. It seems like VCDEasy was padding the audio stream up to the full movie length. This was confirmed when I demuxed the audio from the source clip. The lengths were different.
Although VCDEasy autopadded I got an audio click between the clips which should have run smoothly.