| Open-DML - output | You must select this option of you want to create files larger than 2000 MB. Note that files created using this setting usually don't work on hardware mpeg4 players. Open-DML AVI files have 33% less overhead than standard AVI files, unless you have AVI-Mux GUI created an additional legacy index. |
| standard indexes per stream | This option is only of importance if you select Open-DML - output. There are 3 possibilities:
|
| make legacy index | This option is only of importance if you select Open-DML - output. The output file will then have an additional legacy index. Use this to prevent Windows XP from hanging each time you click on an Open-DML AVI files. |
| RIFF AVI - size | Set the size of the first RIFF AVI list, over which the legacy index is formed.
Recommended: 1 MB. Larger values will only increase the overhead of your output files. |
| Low-overhead mode | When this mode is enabled, Open-DML files (without a legacy index) will have almost 50% less overhead compared to "normal" Open-DML files. This is achieved by putting several frames of the same stream, even the video stream, into one chunk, but keeping one index entry per frame. The AVIF_MUSTUSEINDEX flag will be set, so that an AVI parser is forced to rely on the index only when reading individual frames from the file. This means that, in the case the index is lost, there is no way to retrieve it! VirtualDub's reindexing function will fail! The specification does not explicitely allow this, but it does not forbide it either. Thus, this mode might bend the Open-DML specification a bit, especially it might bend it beyond what other programmers read into it when making their own AVI parsers. Files created this way are compatible to Microsoft's AVI splitter and to VirtualDub (tested with 1.6.1 and ~mod 1.5.10.1), but version 6.4.8.4 of MPC is required for its internal AVI splitter to recognise such files. |
| make rec-lists | rec-lists will be created to improve seeking behaviour of Microsoft's AVI splitter. Such files may be incompatible with hardware mpeg4 players. |
| audio interleave | The entered numer of frames will be stored consecutively into the output file, then the corresponding audio data will be added. If you create rec-lists, then this number of frames will be stored in one rec-list together with the corresponding audio data. You can select whether you want to specify the interleave scheme in units of kBytes or frames. If you select kBytes, then this will be the size of one rec list or one combined video-/audio-block. Recommended: 100 - 250 kByte |
| MP3 CBR Frame Mode | If activated, MP3-CBR streams will be read frame by frame, so that MP3 frames will not
be split. Note: If you set a delay for an MP3-CBR stream, frame mode will be activated automatically! Recommended: activated |
| preload | Same purpose as in VirtualDub |
| AC3 frames per chunk | Indicate how many AC3 frame are going to be stored in one AVI chunk. If there were no b0rked decode software and hardware, you could select a large number here, to decrease overhead. Unfortunately, any numbers except for 2 might cause compatibility issues. Use any number different from 2 on your own risk!. recommended: 2 |
| MP3 frames per chunk | When muxing MP3-VBR to AVI, this number of MP3 frames will be put into each
chunk. Numbers larger than 1 decrease overhead, but cause some AVI tools not to recognise the stream as VBR any longer. Values larger than 3 could impair file splitting. On the other hand, I have received a report that a certain hardware MPEG4 player played MPEG2 Layer3 audio streams only when this setting was set to 2 (!) recommended: 1, but try other values in case of trouble |
| DTS frames per chunk | When muxing DTS to AVI, this number of DTS frames will be put into each chunk. Numbers larger than 2 decrease overhead, and numbers as high as 20 seem to work in my system, however, I can't promise that it works with hardware decoders or other software decoders Large values should not impair file splitting. Use any number different from 2 on your own risk!. recommended: 2 |
| add JUNK before headers | Typical AVI files always have their first header at the same location. Consequently, some applications assume that this first header were always found at that location. When enabling this setting, 8 bytes of padding will be added before the first header, so that the first header is moved. If you find an application that rejects such files, contact its author. |