Virtualdub

it's ussually not really the video causing the but the uncompressed audio anyway.

I'll second Harekiet. If you've ever tried using the WAV writing function of DOSBox, you'll know just how big the resulting files are, especially if you use high samplerates in dosbox.conf.

44100 Hz * 16 bits * 2 channels = 176400 bytes/sec

176400 bytes/sec * 60 sec = 10584000 bytes = 10.09 MB

Yup, I discovered all that myself last night actually. 😀

Thing is, when I try to use the LAME ACM codec with virtualdub to compress the audio, it won't sync properly with the video. The video keeps speeding up and pausing, and when you seek it completely loses sync. I think it's the LAME ACM plugin that's the problem.

OK, well thanks to this page http://www.looprecorder.de/tut_l3codec.php, I managed to tweak a few registry settings and get the WMP10 Fraunhofer MP3 codec to be recognised properly, and encoded the video with low quality MP3, doing a video stream copy (no change) - the new filesize is ~20MB!

In my 180MB video file, about 155MB was audio. 😀 Maybe in an upcoming version of DOSBox an option can be put in to slightly compress this (I know it would eat CPU, though it seems strange the video can be so small while still uncompressed).

I usually avoid using ACM to compress audio since it doesn't work most of the time (especially LAME ACM is not so stable). I just demux audio from video, encode it seperately and then mux it back together (using virtualdubmod which supports VBR streams).
But using something like LAME library (it's crossplatform 😀) in dosbox might not be such a bad idea...

I don't know, gulikoza. When I've used LAME to encode audio from Winamp, there is a significant slowdown compared to writing a PCM WAVE file. I don't know if DOSBox could afford such a big performance hit. My reccommendation would be for the DOSBox devs to come up with a lossless audio codec that's really fast to encode the audio with. It would have to be at least as fast as ZMBV is for video, though (and being able to encode 70fps and still have plenty of CPU power left over for all the emulation, it's screaming fast).

I think it's good to compress the audio, but I think audio compression on-the-fly is too slow sometimes. It's better to do it afterwards if possible. I also think it's best if users easily find instructions on how to do things. They'll probably look at the codec settings in the conf first, so that'd be the best place to find it. If dosbox enables it, then it's likely to be maintained.

So here's an idea..
The output could be written uncompressed as usual, but then be compressed by a scripted post-process when recording is completed. Emulation would pause until the process is complete and then resume. The tools called by the script wouldn't need to be shipped with dosbox, but should be easy to download. The scripted commands would be found commented-out within the conf file and optionally uncommented. This would let users see how to do it manually even if they don't configure it to be done at the end of recording. Of course, you could do all this without it happening while dosbox is running.. but then why would it be in the conf? ;)

Another possibility would be to compile the audio compression post-process into dosbox.. but I think that would take more effort to maintain and wouldn't be as flexible.

Hmm, I do kinda like the idea of lossless audio as well as video, it's just kinda funny that the video is much smaller than the audio. I guess it's because there are distinct frames/pixels you can capture with video and the framerate of many DOS games is pretty low, but with audio you always have to draw the sampling line somewhere if you're recording the whole thing as a wave file and the closest to lossless you can get is to draw it very high, which takes up huge amounts of data. You'd have to have something like a MIDI format to avoid this requirement. Difficult one. I guess the way it's currently recorded is best; assuming you know how to use Virtualdub.

Well, midi is recorded as a midi, but there's no way to convert digital audio to midi. Video compresses well since most dos games are 256 colors and games (unlike movies) usually have a lot of single color areas. The situation is quite different with audio...lossless audio codecs do not compress so well (50% max) and are quite cpu intensive. A bit of cpu usage for audio compression during recording wouldn't be so bad IMHO (mp3 compression doesn't take that much cpu, my old xp2200+ can compress at 3-4x real time).

Script post-compression can easily be achieved with virtualdub, dosbox doesn't have to know anything about it 😁

Here's another idea: combine the two previous ones.

Include options in dosbox.conf for recording. Here are some proposed default values.

# frame_rate - number of frames per second to record to the video file
# digital_compression_method - can be none (uncompressed audio), realtime (codec compresses audio in realtime, CPU intensive), endfile (compression performed when recording of current file completes), or exit (compression is performed after quitting DOSBox)
# digital_compression_codec - name of audio compression DLL to use. Configure the codec itself in compress.ini. DLL file must be in the DOSBox directory to make use of it.

[recording]
frame_rate=70
digital_compression_method=none
digital_compression_codec=

Of course, these example settings are for a Windows machine. I'm pretty sure the devs can work out some cross-platform method of specifying these values. Setting digital_compression_method=endfile would likely cause slowdowns at the end of each file's recording as the audio gets compressed, and digital_compression_method=exit would result in lots of drive activity when DOSBox is shut down. If digital_compression_method=exit and DOSBox crashes without the opportunity for a proper shutdown, the audio in the recorded files would be left uncompressed.

I highly doubt that you'll ever see lossy audio compression, your more than likely to always have to cut your final video file in virtualdub or whatever for the right pieces anyway. Only added zmbv so you wouldn't have to deal with the huge file size of uncompressed rgb video. At 70*320*200*3 that would be slightly more than 22050*4 per second for the audio.

Isn't ZMBV lossless anyway?

set audiorate of the mixer to something lower. should help with the resutling movies.