Some input on the new AVI2SVCD beta feature

[mkanar]

Hello. I just thought I would post this right now as I haven't gotten around to making a super-detailed bug report as of yet.

I have an AVI file encoded using the PICvideo MJPEG codec along with a 44.1KHz/16-bit/stereo PCM audio stream (actually recorded at 44106.90 Hz). The BeSweet translation via AVI2SVCD resulted in a 48KHz MP2 file after executing this commandline:

"F:\ENC\DS\BeSweet\BeSweet.exe" -core( -input "F:\ENC\BIN\Extracted_audio_1.wav" -output "F:\ENC\BIN\Encoded_audio_1.mp2" ) -ota( -g max ) -2lame( -e -b 160 -m s )

I ran BeSweet (actually, the more recent version) like this:

F:\ENC\BS\BeSweet.exe -core( -input F:\ENC\BIN\Extracted_audio_1.wav -output F:\ENC\BIN\Encoded_audio_1.mp2 -logfilea f:\ENC\BS\BeSweet.log ) -ota( -g max -fs 44100 ) -2lame( -s 44.1 -m j -b 192 -e )

and I got a 44.1KHz MP2 file. I specified 44.1KHz in two places and I am unsure which one of the two did the trick. I am hoping that it is the "-fs 44100" instead of the "-s 44.1" because I would like to be able to specify "-fs 44107" in order to correct the audio sampling rate and syncronize my capture AVIs at the same time.

The next issue probably isn't an AVI2SVCD problem at all, but I think I should mentio it. bbMPEG kept getting stuck at 68% while muxing the .M2V (or was it .MPV...doesn't matter) and .MP2 streams. I then muxed the two streams with TMPGEnc and got all the way through with a properly sized .MPG file of 1.35G. Then I tried to use TMPGEnc to demux; I wound up with a .MP2 file of equal size to the original (about 20M) but the .MPV/.M2V video stream was only about 235MB instead of the 1.3G that was muxed in to begin with.

My assumption is that CCE didn't produce a compliant video stream. Perhaps I will restart this from scratch.

Also, my .AVI file is already resized to 480x480 (I don't use huffy because of the bad decompression speed, but I filter, resized, corrected the audio from 44107 to 44100 with VirtualDub, compressing again with picvideo MJPEG at quality preset 19. The audio correction brought the video stream within 0.01 frames unsynchronized with the audio, so I 'adjusted the fps so that the audio and video streams matched' in order to get a perfect synchronization. It was still out of sync because my audio card captures at exactly 44106.89Hz, but I had to specify a while number while 'forcing the audio sampling rate to ___ Hz' in the 'additional options while opening file' dialog box is VirtualDub. I realize that I loose some quality with MJPEG, but if I use huffy, is decompresses SLOW and this problem is amplified with CCE does 4-5 passes.

One last note. I know that since I already had a 480x480 video stream, it doesn't make sense to use the resize filter in AVISynth, so I clicked on 'Edit when dvd2avi processing is done' under 'Frameserver' in AVI2SVCD so that I could remove the resize line in the .AVS file. This was stupid of me as I obviously should have selected 'Edit as part of CCE encoding' and therefore, I never got the opportunity to remove the resize. For the morons, such as myself, it might be nice if the 'after DVD2SVCD' option was unavailable while in AVI2SVCD mode.

babble babble. I know that AVI2SVCD is only BETA....I'm am simply trying to give some input for the AWSOME PIECE OF SOFTWARE..THANK YOU DVD2SVCD!!!

MKanar

[mkanar]

Okay, I just tried AVI2SVCD with a completly different .AVI on a completely different computer with DVD2SVCD 1.0.6 build 2 pre 1 instead of 1.0.6 build 1. bbMPEG is stopping at 68%, just like the 68% issue mentioned in the message above this one.

Am I the only one with this issue? Seems very odd!

As always, thanks for a great piece of software!
MKanar

[Fastolfe]

I had a go yesterday at the AVI2SVCD with a DivX NTSC (visually good quality for a DivX) and transcoded with the standard settings of DVD2SVCD 1.0.6 build 2 pre 1.

I did use one pass vbr w/ TS 2,1; NTSC > PAL; birate: max 2400, min 300, min avg unchecked and max avg 2100 and 1 audio 160kb.
I did also test the Bilinear versus Simple Resize filter.

First, everything went smoothly on my PC (WinXP Pro on 2xP3@800 system), although you need to edit the AVS filter to select the resize filter and to adjust the AddBorders.

Secondly, about the visual quality (taking into account that the source was not a DVD), the BilinearResize looks better than the SimpleResize, the image is sharper, less blurry and the blocky effect less visible to me at least. As reported in other posts, SimpleResze was faster than Bilinear of about 10-15%.
I suppose next I will try the same kind of tests with a DVD source.

FF

[Mozart]

could you tell us the source resolution? If it is smaller than 480x512 it is not so good to use simpleresize neither bilinearresize. Try bicubicresize.

[Fastolfe]

The source resolution is 640x272 and you are right I should have complete the run with the BicubicResize.
I will try maybe tomorrow and post the results here.

FF

[Fastolfe]

Ok, I did the BicubicResize (could not wait :D) on the same divx and to my eyes, no doubt that Bicubic comes first then close Bilinear and last SimpleResize (relatively speaking fairly worse than the 2 first filters). Of course, the speed of the Bicubic is significantly lower (~25% slower than Simple).
The big difference to my eyes is especially the sharpness/level of details of the faces of the actors (basically everything on the foreground). With the SimpleResize, it is clear to me that they are all blurry (kind of misty effect). The backgrounds are all very similar as the source is still a divx after all, so not as sharp as I am sure it would have been with a DVD.
This is just a quick test with one divx source which tells me that to convert divx to SVCD, there is a need to test first which filter to use as the end result might be seriously affected (as we start with a degraded source already and there are so many different divx resolutions out there). But I would not recommend the SimpleResize just only because it so much faster.
Now, from I read in the other post testing these filters with a DVD as source, the story looks different (I see some new tests coming).

FF