Limiting File Size in AVS Video Converter

[TJF]

I have been ripping DVDs with AVS for some time but recently, the output file size exploded to around 5G. The actual video content runs aout after 15% of the way into the file etc and remionder is simply black and taked several hours. I still get to see the movie etc but it is a waste of memory.
I'm not sure how that happened. I want it limited to the usual 700MB etc. The only reference to limiting file size seems to be in relation to the file split function - which I dont think is relevant to me. I asked the question on the AVS support site but the response was useless. I dont know too much about this but I expect it is simple enough.
Thanks

[Baldrick]

Just try another dvd converter like handbrake.

[TJF]

Many thanks Baldrick. I note from their site that they say that AVI is basically old-tech and H.264 is now preferred. Is that your view for a format for simple movie files being able to played on TV through your average media player?
Again, thanks.

[deadrats]

Many thanks Baldrick. I note from their site that they say that AVI is basically old-tech and H.264 is now preferred. Is that your view for a format for simple movie files being able to played on TV through your average media player?
Again, thanks.

if they do in fact say that on their website then that should be taken as a clear indication not to use their software. avi is a container (it actually stands for Audio Video Interleave) that can hold audio and video streams compressed by various methods. h264/avc is a method for compressing/decompressing a video stream. it's ridiculous to say that h264 is prefered over avi, it's a nonsensical statement. now if they were saying that m2t, m2ts, ts or mp4 were a better container over avi, then i would agree completely.

personally i wouldn't use avs if you gave it to me for free, i hate that software, almost as much as i hate the old blaze media pro con job.

[TJF]

Thats a great resoponse!! What is your preferred converter?

[Ai Haibara]

From Handbrake's homepage:

Focus on what we do best

As we've had on our roadmap for quite awhile now, one of our goals for version 0.9.4 was to refocus on HandBrake's key strengths and to remove dead weight. As part of this process, several containers and a codec have been removed from HandBrake.

AVI: AVI is a rough beast. It is obsolete. It does not support modern container features like chapters, muxed-in subtitles, variable framerate video, or out of order frame display. Furthermore, HandBrake's AVI muxer is vanilla AVI 1.0 that doesn't even support large files. The code has not been actively maintained since 2005. Keeping it in the library while implementing new features means a very convoluted data pipeline, full of conditionals that make the code more difficult to read and maintain, and make output harder to predict. As such, it is now gone. It is not coming back, and good riddance.

OGG/OGM: HandBrake's OGM muxer is just as out of date. It hasn't been actively maintained in years either, and it too lacks support for HandBrake's best features. It requires conditionals to work around missing functionality too...only this one gets tested so infrequently the conditionals were never even put in the code, so it just fails when you try to do anything advanced. This one is not coming back either. And yes, we're aware of HTML 5. For patent-free muxing, HandBrake still has Matroska, which is a much better container anyway.

XviD: HandBrake, these days, is almost entirely about H.264 video, aka MPEG-4 Part 10. This makes it rather...superfluous to include two different encoders for an older codec, MPEG-4 Part 2. When choosing between FFmpeg's and XviD's, it came down to a matter of necessity. We need to include libavcodec (FFmpeg) for a bunch of other parts of its API, like decoding. Meanwhile, XviD's build system causes grief (it's the most common support query we get about compiling, after x264's requirement of yasm). Since we mainly use MPEG-4 Part 2 for testing/debugging, and recommend only H.264 for high quality encodes, Xvid's undisputed quality edge over FFmpeg's encoder is inconsequential, while FFmpeg's speed edge over XviD is important to us.

Funny, I've used muxed-in subtitle streams in AVIs before...

[deadrats]

Thats a great response!! What is your preferred converter?

tmpg express or movavi's editor/encoder are my first choices.