VirtualDubMod Bugfix release

[Belgabor]

There've been some bad bugs in the last version (mostly related to the NET mod), so we decided to release a bugfix version. As not all bugs are fixed yet, this is just a prerelease (= exe+vdi only).


Cyrius:
- Some NET mode related bug fixes.

Belgabor:
- Reorganized the menu to make it clearer.
- Merged Streams and Cyrius' NET mod fixes.
- Release Notes more aptly named changelog

Stream:
- Fixed several bugs
* NET mod stop with script error on final stage of encode.
* NET mod crash when input path-name is too long.
* Can't load processing setting if external WAV file is set
as audio source.
* NET mod stop if output type is old format AVI.

Errata to the last changelog:
Its wrong that Cyrius didnt like '1337', he just didnt know what it means, :p


One last pice of info:
Doom9 rose our attetion to this thread (http://forum.doom9.org/showthread.php?s=&threadid=36094), which deals about ac3 mistreatment in nandub. Cyrius already had some how fixed this (citing his reply):

I saw this thread last month.
I couldn't read it entirely (there are a lot of posts ;), and it concerns MP3 and AC3 muxing in AVI) but as far as I could read (and remember) the AC3 parts explain that the problem with Nandub is that it cut the stream anywhere (i.e. generally in the middle of a frame).
I somehow corrected that (it is easily possible only when opening an AC3 file to mux) by adding the 'AC3 frame mode' feature (extra option proposed when opening an AC3 file in VDubMod). This force VDubMod to treat whole AC3 frames (and so will prevent it to cut in the middle ot those frames).
IIRC this is still effective (the fact VDub treat whole AC3 frames) when reopening the file in VDubMod (or VDub) since AVI header of the stream is modified accordingly.


Cheers
Belgabor

[Mystic-Dragon]

As always : Thnx!
And keep on the good work! I love what u guys included in VirtualDubMod :)

[Minako]

The Nandub AC3-Problem was basically the following: 'NanDub does not only store fracted multiples of AC3 frames as chunks, but even splits AC3 frames when splitting a movie.'

The workaround for the first problem (fracted frames) was to set interleaving values timebased as multiples of 32 ms (one ac3-frame is 32 ms), so you didn't get fracted frames. There was no workaround for the second problem (split frames when cutting a movie).

Is this both supposed to be fixed now? That would mean one could use any interleaving value and still have no fracted/split frames (and therefore smooth playback)? And even one could cut a movie without screwing the ac3-frames at the split point? Would be great!

One more thing from the thread was this one:

'Large audio interleave values in NanDub will create large audio blocks, causing less chunks and therefore less overhead.

AVI-Mux GUI doesn't create large chunks for AC3, since it seems to cause bad files. At least here, they replay at warp speed then. For MP3-CBR or other CBR formats, AVI-Mux GUI will also create such large chunks.'

'the files are valid in theory, they just don't play properly on my system. IMHO this is a bug in the playback filter. They way of interleaving should not be able to affect the speed the stream is replayed at.'

'AVI-Mux GUI always makes one "chunk" being one AC3-Frame, so another interleave value should not cause a different behaviour. The interleave value merely controls how many such chunks are stored consecutively. I've made the experience that too large AC3 audio chunks cause the file to be replayed at warp speed.'

Is this handled this way in VDubMod, too (one chunk=one AC3-Frame)? If not, it probably should...alexnoe, the author of AVIMuxGUI is probably the one to ask about details, I am just quoting him here...so don't ask me :D

[Suiryc]

Originally posted by Chibi Jasmin
The Nandub AC3-Problem was basically the following: 'NanDub does not only store fracted multiples of AC3 frames as chunks, but even splits AC3 frames when splitting a movie.'

The workaround for the first problem (fracted frames) was to set interleaving values timebased as multiples of 32 ms (one ac3-frame is 32 ms), so you didn't get fracted frames. There was no workaround for the second problem (split frames when cutting a movie).

Is this both supposed to be fixed now? That would mean one could use any interleaving value and still have no fracted/split frames (and therefore smooth playback)? And even one could cut a movie without screwing the ac3-frames at the split point? Would be great!

One more thing from the thread was this one:

'Large audio interleave values in NanDub will create large audio blocks, causing less chunks and therefore less overhead.

AVI-Mux GUI doesn't create large chunks for AC3, since it seems to cause bad files. At least here, they replay at warp speed then. For MP3-CBR or other CBR formats, AVI-Mux GUI will also create such large chunks.'

'the files are valid in theory, they just don't play properly on my system. IMHO this is a bug in the playback filter. They way of interleaving should not be able to affect the speed the stream is replayed at.'

'AVI-Mux GUI always makes one "chunk" being one AC3-Frame, so another interleave value should not cause a different behaviour. The interleave value merely controls how many such chunks are stored consecutively. I've made the experience that too large AC3 audio chunks cause the file to be replayed at warp speed.'

Is this handled this way in VDubMod, too (one chunk=one AC3-Frame)? If not, it probably should...alexnoe, the author of AVIMuxGUI is probably the one to ask about details, I am just quoting him here...so don't ask me :D
I just checked the code I made some weeks ago :) and actually when using 'Frame mode' for AC3 in VirtualDubMod data are processed this way :
1. routines will treat whole AC3 frames (i.e. it shouldn't cut in the middle of a frame :), and frames shouldn't be fragmented over multiple chunks)
2. each AC3 frame goes in its own chunk

2. is achieved by internal routines in VDubMod when reading the AC3 file.
However 1. could only be achieved (aiming a kind of 'compatibility' with VirtualDub or other editing tools) by setting nBlockAlign to the size of a frame (which shouldn't be a misuse of this field).
I am not sure but I recall alexnoe saying doing such a thing gave him problems on his computer (not sure though) and that's why I put a warning in the release notes concerning this feature.
With this value even VirtualDub shouldn't cut the stream in the middle of a frame (but may regroup AC3 frames in a chunk when reediting the clip ... as VDubMod would do btw ... but I am not sure of this either ^^').

As for AviMuxGUI the interleaving value (when using 'Frame mode' for AC3) would only change how many chunks (i.e. AC3 frames here) are stored consecutively.

[Blight]

Can you set that the window autosize won't kick in when the window is maximized, it goes all over the place when loading files which isn't very friendly.

[Stereodude]

Originally posted by Blight
Can you set that the window autosize won't kick in when the window is maximized, it goes all over the place when loading files which isn't very friendly. Good idea, that was pissing me off too. Of course the fact that the video isn't displayed at the right size in it bothers me also.

Stereodude

[Minako]

Originally posted by Blight
Can you set that the window autosize won't kick in when the window is maximized, it goes all over the place when loading files which isn't very friendly.

Can't we just have a preferences option to disable it completely, please?

[Minako]

Originally posted by Suiryc
I just checked the code I made some weeks ago :) and actually when using 'Frame mode' for AC3 in VirtualDubMod data are processed this way :
1. routines will treat whole AC3 frames (i.e. it shouldn't cut in the middle of a frame :), and frames shouldn't be fragmented over multiple chunks)
2. each AC3 frame goes in its own chunk

2. is achieved by internal routines in VDubMod when reading the AC3 file.
However 1. could only be achieved (aiming a kind of 'compatibility' with VirtualDub or other editing tools) by setting nBlockAlign to the size of a frame (which shouldn't be a misuse of this field).
I am not sure but I recall alexnoe saying doing such a thing gave him problems on his computer (not sure though) and that's why I put a warning in the release notes concerning this feature.
With this value even VirtualDub shouldn't cut the stream in the middle of a frame (but may regroup AC3 frames in a chunk when reediting the clip ... as VDubMod would do btw ... but I am not sure of this either ^^').

As for AviMuxGUI the interleaving value (when using 'Frame mode' for AC3) would only change how many chunks (i.e. AC3 frames here) are stored consecutively.

Well, sounds good, although, I don't know, if this nBlockAlign thing is a problem...please ask alexnoe about that...what problem was it that you think to remember? Apart from this, files should play fine then, no matter, what interleaving is set...will test, whenever I find the time...

EDIT: About the nBlockAlign, you mean, there's a better way, if you screw compatibility with VirtualDub? How does alexnoe solve this, I guess, his files are editable? Don't know, but if unsure, I vote for a working (and spec-compliant file) and not for compatibility with whatever editing-tool, that cannot deal with that file...well, maybe I got it wrong?

[Suiryc]

Originally posted by Chibi Jasmin
Can't we just have a preferences option to disable it completely, please?
This has been asked on the SourceForge page already (feature request).

Well, sounds good, although, I don't know, if this nBlockAlign thing is a problem...please ask alexnoe about that...what problem was it that you think to remember? Apart from this, files should play fine then, no matter, what interleaving is set...will test, whenever I find the time...

EDIT: About the nBlockAlign, you mean, there's a better way, if you screw compatibility with VirtualDub? How does alexnoe solve this, I guess, his files are editable? Don't know, but if unsure, I vote for a working (and spec-compliant file) and not for compatibility with whatever editing-tool, that cannot deal with that file...well, maybe I got it wrong?
I think the problem was that some decoders wouldn't play the file or something like that.
I think alexnoe uses a value of 1 as nBlockAlign (which is a kind of 'common' value used in a lot of formats).

I think we could still generate 'proper' AVI files (i.e. 1 AC3 frame per chunk, and not cut in the middle of a frame) in VDubMod, but this would not be the case when reediting the file in VDub or VDubMod if nBlockAlign is set to 1.

I think alexnoe retrieve an AC3 frame header to know the size of a frame each time his tool process files.

Setting nBlockAlign to the size of an AC3 frame (as it is done in 'Frame mode' under VDubMod) is not really a misuse of this field.

[Minako]

Yeah, well, okay...thinking about it, I just thought, it might be nice to make ac3 frame mode the default or even only mode to work in...then it should be possible to just open a badly muxed ac3-avi and save it with direct stream copy again to fix it without setting interleave values to 96/96 (the old way to fix badly muxed files). Or am I wrong, that frame mode is now only activated, when loading a separate ac3-file?

[Suiryc]

Originally posted by Chibi Jasmin
Yeah, well, okay...thinking about it, I just thought, it might be nice to make ac3 frame mode the default or even only mode to work in...then it should be possible to just open a badly muxed ac3-avi and save it with direct stream copy again to fix it without setting interleave values to 96/96 (the old way to fix badly muxed files). Or am I wrong, that frame mode is now only activated, when loading a separate ac3-file?
Yep this mode is only available when loading an AC3 file.
Doing so for AC3 streams in AVI files would need to read audio data in the file, get the header etc. and also modify (I think) routines in VDubMod so that AC3 data could be well rewritten (one frame per chunk, ...). I think AVIMuxGUI works this way but adapting VDubMod to this may be too complicated ...

[Blight]

Oh, and if you could also set it that the video size ratio (1/2 1/1 2/1) remains unchanged when opening new files, that would also be great.

[ChristianHJW]

We should note this on our VdubMod homepage that one of the best player developers ever is using VdubMod for encoding :d :D ... thanks for the input Blight, and please continue the good work on Zoomplayer and keep up the good and friendly relationship with BlackSun ... unlike other player developers ( i wont give names ) :(

[Minako]

Originally posted by Suiryc
Yep this mode is only available when loading an AC3 file.
Doing so for AC3 streams in AVI files would need to read audio data in the file, get the header etc. and also modify (I think) routines in VDubMod so that AC3 data could be well rewritten (one frame per chunk, ...). I think AVIMuxGUI works this way but adapting VDubMod to this may be too complicated ...

Well, it would be a huge achievement...if one of you modders ever finds the time to do it, I think it would be great! Maybe you should still consider making ac3frame mode the default mode (or even only mode) for adding ac3-audio to avi?

Thanx for explaining everything...

[neuron2]

I have the bugfix and it always starts with the panes at 1/2 size. If I resize to Normal and then hit F5 they jump back to 1/2.

Is there any way to get Normal by default and to keep it from changing when the F5 key is used? Thank you.

[Minako]

I just saw the following change in AviMuxGUI V1.11:

'changed interleave pattern for AC3: Now 2 AC3 frames are stored into one chunk.
This is required for some broken SB drivers to work correctly with SPDIF-Out.'

I just wanted to suggest to port this over to VDubMod...maybe ask alexnoe about the details...

Also look here, I have asked about it: http://forum.doom9.org/showthread.php?s=&threadid=38855

Also a few words about it here: http://forum.doom9.org/showthread.php?s=&threadid=41052(Basically only gabest saying: 'It just the matter of how the AVI->AC3 filter packaging the samples, it would be possible to accumlate a few samples and send them out together...')

[Belgabor]

Just a remark on the resizing stuff:

Stone-D is working on it, but he's on holiday and won't be back until 10th of January. I summed up the requests so far in a reply on the respective sf feature request. All that want something changed with it, please have a look if I mentioned what they want and if not, add a reply and say what they want.

Thx
Belgabor

[neuron2]

Why can't we just have the classic VirtualDub behavior?

Your current version often resizes such that I can't move the navigation bars on screen. It's a royal PITA.

[Belgabor]

New release (VirtualDubMod_070103)


Cyrius:
- Some NET mode related bug fixes.

Belgabor:
- Reorganized the menu to make it clearer.
- Merged Streams and Cyrius' NET mod fixes.
- Release Notes more aptly named changelog.
- Disabled resizing code till Stone-D implements preferences.
(I put it under a #define switch, see virtualdub.h)
- The time bar ticks are now switchable between
* Off
* Frame mode (normal)
* Source Key Frames
* Key Frames in divx3/xvid stats file (load via Tools/Open Stats File...)
(Comment: This is work in progress, so please don't report bugs & feature
requests on it yet)

Stream:
- Fixed several bugs
* NET mod stop with script error on final stage of encode.
* NET mod crash when input path-name is too long.
* Can't load processing setting if external WAV file is set
as audio source.
* NET mod stop if output type is old format AVI.
* NET mod stop if output type is OGM.
* NET mod freeze when input is too short.
* NET mod freeze when input file is MPEG-2.
* NET mod freeze when input file is OGM.
* CBR MP3 muxing cause audio being out of sync.

Errata to the last changelog:
Its wrong that Cyrius didnt like '1337', he just didnt know what it means :p

[Minako]

Originally posted by Belgabor
New release (VirtualDubMod_070103)
- The time bar ticks are now switchable between
* Off
* Frame mode (normal)
* Source Key Frames
* Key Frames in divx3/xvid stats file (load via Tools/Open Stats File...)
(Comment: This is work in progress, so please don't report bugs & feature
requests on it yet)

Work in progress refers to stats file thing or to the whole option? Just in case: selecting source key frames with no file opened results in crash...

[Belgabor]

I intended it mostly on the stats file stuff, but I hadn't tested it extendedly, so something like this was kinda expectable ;)
(I wanted to keep ppl from asking stuff like 'let me set keyframes and save!'. Thats what the feature is intended for, but its not ready)

Well, thx for telling me, this way I won't forget to fix it (hopefully)

[Minako]

Okay, fine...please one of you also have a look at this 2 ac3-frames/chunk thing from above...thanx in advance :D

[Blight]

Ok, window is not resizing. But can you please have the window size and maximized state remembered when exiting?

[Minako]

Originally posted by Chibi Jasmin
Okay, fine...please one of you also have a look at this 2 ac3-frames/chunk thing from above...thanx in advance :D

There's some more discussion here: http://forum.doom9.org/showthread.php?s=&threadid=38855

Maybe keep AC3-Frame mode as it is (an option), but making it 2 frames/chunk...and leave the rest of the code as it is? Fracted ac3-frames don't seem to be that much of a problem...

[Shayne]

Was looking for the right post to request this and it looks like i found it. This resize feature in VDMod 1.4.13.1 takes the best video editing proggy around and makes it totally useless. Please allow users to decide if they want this feature. Me for one would be the first to disable it. It is so user unfriendly i will stay with the older version for now.

[JuanC]

Originally posted by Shayne
Was looking for the right post to request this and it looks like i found it. This resize feature in VDMod 1.4.13.1 takes the best video editing proggy around and makes it totally useless. Please allow users to decide if they want this feature. Me for one would be the first to disable it. It is so user unfriendly i will stay with the older version for now. have you tried the bug fix released jan 7? The code for windows resizing behavior (Stone-D) was deactivated!

[Belgabor]

New Release (VirtualDubMod_170103)
Be careful to get the right one! Sourceforge doesn't sort this files by date


Cyrius:
- Some NET mode related bug fixes.
- Fixed crash when selecting a NULL LANGUAGE comment ('LANGUAGE=(null)')
- Fixed wrong interleaving in per-ms mode on a VBR MP3 stream ala Nandub.
Thanks to Steven Greenberg (Doom9's forum) for pointing out the problem
and providing a quick fix.
- When opening a file VDubMod should now show the first frame.
[known bug: doesn't work with MRU & drag'n'drop]
- Fixed bug when demuxing stream from an OGM file :
* SRT file wouldn't contain the subtitles (first one at most)
* When demuxing with WAV header and overwriting an existing file (longer
than the stream being demuxed) some bytes from the old file would remain
at the end of the demuxed stream
- Disabled initial resizing code as well.
Put in the same #ifdef test than other resizing code.
- Job Control window will now appear when launching VDubMod to process queued jobs.
This should prevent VDubMod to crash in those circunstances (e.g. when being
used by GKnot) because some variables are initialized when opening this window.

Belgabor:
- Reorganized the menu to make it clearer.
- Merged Streams and Cyrius' NET mod fixes.
- Release Notes more aptly named changelog.
- Disabled resizing code till Stone-D implements preferences.
(I put it under a #define switch, see virtualdub.h)
- The time bar ticks are now switchable between
* Off
* Frame mode (normal)
* Source Key Frames
* Key Frames in divx3/xvid stats file (load via Tools/Open Stats File...)
- Stats file savable
- Toggle Keyframes in stats file (default key: Space)
- Frame info from stats file
(Comment on stats file stuff:
xvid suff is ready for work [bug reports & feature requests welcome]
to do list [=dun request, we already thought about & will work on it]:
* Divx5 log file support
* Import from chapters file / ogm chapter info)


Stream:
- Fixed several bugs
* NET mod stop with script error on final stage of encode.
* NET mod crash when input path-name is too long.
* Can't load processing setting if external WAV file is set
as audio source.
* NET mod stop if output type is old format AVI.
* NET mod stop if output type is OGM.
* NET mod freeze when input is too short.
* NET mod freeze when input file is MPEG-2.
* NET mod freeze when input file is OGM.
* CBR MP3 muxing cause audio being out of sync.
* Script error occurred when OGM comments include special character.

[Suiryc]

Originally posted by Belgabor

Cyrius:
...
- When opening a file VDubMod should now show the first frame.
[known bug: doesn't work with MRU & drag'n'drop]
...

My fault, sorry for that but I promise this will be fixed in a next release :) (*hmm* it's already fixed in the CVS ;))

[llemor]

Excerpt from this thread http://forum.doom9.org/showthread.php?s=&threadid=38992
added a "Nandub VBR MP3 compatibility mode" when opening AVI files (disabled by default).This should allow you to work on VBR MP3 streams as in Nandub.

how can I enable it? :confused:

any setting in the gui?

[The Edge]

@llemor

When opening the avi on the bottom left of the file/open window.

Edge

[llemor]

thanks. if that's a snake i might be biten already:D

[DeXT]

A suggestion to ease its use: when you open an AVI file containing a VBR-MP3 stream, instead of showing that mighty box blaming you for using such weird audio encoding, you could ask if you want to open it in Nandub-compatibility mode or normal mode. It's just adding a Yes/No button to that message box :)

That additional checkbox on the bottom of the file dialog may be hard to find for a newbie user, and it's meaningless for non-AVI files such as MPG. So I think the above solution may be more appropiate.

[davexnet]

Thanks for posting the location of this mysterious switch.
I've been using drag and drop to drop the AVI from explorer to
the VDM icon forever, and because of that, I've never seen that switch.
Don't forget to take D&D into account!
Dave

[llemor]

Another suggestion: I think it's nice if the "Nandub Compatibility mode" setting could be saved on exit.:cool:

Is there any problem if this is enabled by default? Any issue with the other video formats, in case? ;)

[davexnet]

Another observation > this switch didn't fix the problem with
HP cd1 Dominion release dvdscr.
The AVI plays fine, but if you use VDM to spin of the WAV or MP3,
and then use that as input to tmpgenc, the resultant MPG has
audio that is way out of synch by the end of the file.
But perhaps the file is bad? But the AVI itself plays fine?
I don't get it.
Just doing what I always do, doesn't work here 23.976 avi >
29.97 MPG.

[tiki4]

Sorry,

I think I found an issue with latest (17012003) CVS version. I used it to compress 2-pass XviD in the combination Avisynth 2.5 beta, mpeg2dec3.dll, VirtualDubMod. I tried two different compiles of XviD (Koepi's 09122002 and UManiac's 13012003 build). For both encodes I got an unseekable AVI file. I don't know what went wrong, but I think the indeces (or something) weren't written correctly in the AVI file. I reverted to an earlier build of VirtualDubMod to check wether it is my source or it is really an issue of VirtualDubMod.

CU,

tiki4

[Suiryc]

Originally posted by DeXT
A suggestion to ease its use: when you open an AVI file containing a VBR-MP3 stream, instead of showing that mighty box blaming you for using such weird audio encoding, you could ask if you want to open it in Nandub-compatibility mode or normal mode. It's just adding a Yes/No button to that message box :)

That additional checkbox on the bottom of the file dialog may be hard to find for a newbie user, and it's meaningless for non-AVI files such as MPG. So I think the above solution may be more appropiate.
We will see what we can do here. However this message is sent at the end of the parsing (and after VDub routines corrected the 'bad' VBR values IIRC) so it will be possible only if we can use the correction routines after this message ...

Originally posted by llemor
Another suggestion: I think it's nice if the "Nandub Compatibility mode" setting could be saved on exit.

Is there any problem if this is enabled by default? Any issue with the other video formats, in case?
The only problem is that in this case you won't know when the audio was VBR (and so you won't know that you are editing a not 100% valid AVI file).


@davexnet:
This feature is of use when you keep the audio in the AVI file.
If extracted to a WAV file you will surely get out-of-sync issues because there is the same problem than in AVI files concerning VBR audio (except there are no tricks to make the audio work 'well' like in AVI).
When demxuxed to an MP3 file (i.e. without WAV header) if you get out-of-sync issues this would mean that either the program you use or the container you will use doesn't handle MP3 VBR.


@tiki4
What do you mean by unseekable? (when trying to seek in the file the player freeze or something like that?)
I just made a short XviD clip (15-01-2003 Koepi's build) with a recent CVS version of VirtualDubMod too and didn't get that kind of problem.
Does VirtualDub or VirtualDubMod complains when you open your files ?

[davexnet]

Hi Suiryc,
thanks for your answer to me re: issues with the AVI and the out of
synch sound. I did run the AVI thru tmpgenc using the sound from the
AVI file, and the resultant mpg had sound that was perfectly
in synch, if not a little scratchy.
Regarding demuxing the sound to mp3, I did what I always do and it
has always worked except for this particular AVI. I usually
drag and drop the mp3 into Sound Forge, wait till the file is expanded, downsample to 44.1 and save as pcm. In this case,
the PCM file had a running time of 71 Mins, 12 Secs, while the
AVI had a runing time of 71 Mins, 30 seconds.
Yet the AVI itself played perfectly all the way thru.
Also, the second part of HP2 cd2 was perfect.

I beleive there is something wrong with the AVI but I can't figure out what it is!
Dave
PS I don't know if this may be a clue, but in the end, I used sound
forge as mentioned above and as a final step "stretched" it to be the
same length as the AVI. After a small bit of synch fudging in tmpg,
it was acceptable.

[tiki4]

@Suiryc:

I'm very much sorry, I thought this was an issue with VirtualDubMod, but it wasn't. I don't know what exactly goes wrong but I could reproduce the corrupted AVI (players freeze, VirtualDub(-Mod) crashes when opening and seeking a little further than half the length) with an earlier version of VirtualDubMod. I tried another movie then and there isn't any problem.
On the other hand neither DVD2AVI nor mpeg2dec(3).dll nor Avisynth give any error. Seeking in GordianKnot or in the Avisynth script is no problem at all. I just can imagine it is a strange combination of (maybe) corrupted VOBs and the Avisynth 2.5 + mpeg2dec3.dll.

Once again, sorry for wrong alert.

Regards,

tiki4

P.S.: All of the VirtualDubMod developers provide great work and I really like to say thanks for such a great tool.

[Belgabor]

Yet another release ;) (VirtualDubMod_310203.zip)
Like with the last one be careful to get the right one!

Cyrius:
- Some NET mode related bug fixes.
- Fixed crash when selecting a NULL LANGUAGE comment ('LANGUAGE=(null)')
- Fixed wrong interleaving in per-ms mode on a VBR MP3 stream ala Nandub.
Thanks to Steven Greenberg (Doom9's forum) for pointing out the problem
and providing a quick fix.
- When opening a file VDubMod should now show the first frame.
- Fixed bug when demuxing stream from an OGM file :
* SRT file wouldn't contain the subtitles (first one at most)
* When demuxing with WAV header and overwriting an existing file (longer
than the stream being demuxed) some bytes from the old file would remain
at the end of the demuxed stream
- Disabled initial resizing code as well.
Put in the same #ifdef test than other resizing code.
- Job Control window will now appear when launching VDubMod to process queued jobs.
This should prevent VDubMod to crash in those circunstances (e.g. when being
used by GKnot) because some variables are initialized when opening this window.
- Added jonny's mods (Doom9 forum, DivX 5 Enc author) - commandline options :
* /log : generates (in the same directory) a vdenc.log file containing some
information (type and size of frame) about the clip.
* /nowrite : prevent VirtualDubMod from writing video data in the output file.
Nb : those options must be placed before any other because VirtualDub(Mod) parse
the commandline on sequence.
- Batch process still stop in NET mode when an error occurs for one job.
- MP3 VBR handling (a la Nandub) is now a preference setting (and so can be saved).
See the 'AVI' section in the 'Preferences' window. Each time a VBR stream is found
inside an AVI the VBR warning will be shown (like in VirtualDub) and you will be
asked if default setting must be applied or not for this stream.
- 'AC3 Frame mode' has been put in the preferences too. You will still be able to
enable/disable this feature when opening an AC3 file (for AVI audio), but the
checkbox is now set according to the default setting.
- Added the list of functions available in VirtualDubMod scripts in the Help file.

Belgabor:
- Reorganized the menu to make it clearer.
- Merged Streams and Cyrius' NET mod fixes.
- Release Notes more aptly named changelog.
- Disabled resizing code till Stone-D implements preferences.
(I put it under a #define switch, see virtualdub.h)
- The time bar ticks are now switchable between
* Off
* Frame mode (normal)
* Source Key Frames
* Key Frames in divx3/xvid stats file (load via Tools/Open Stats File...)
- Stats file savable
- Toggle Keyframes in stats file (default key: Space)
- Frame info from stats file
(Comment on stats file stuff:
xvid stuff is ready for work
to do list [=dun request, we already thought about & will work on it]:
* Divx5 log file support
* Import from chapters file / ogm chapter info)
[B]- Improved 'Scan video stream for errors'. As the classic vdub version didn't work
for me in two files i checked, I implemented an improved version which did. Alas
it's a bit slower so I left the classical version in.
Both versions do NOT mask frames by default, thus three new menu items have been
added:
* Show bad frames
* Mask bad frames (like what the classic scan did automatically)
* Delete bad frames (like marking the frames and pressing 'Del')
To prevent mistakes, the mask and delete commands flush the internal frame list, so
none of these three commands will work afterwards until you rescan the stream.

Stream:
- Fixed several bugs
* NET mod stop with script error on final stage of encode.
* NET mod crash when input path-name is too long.
* Can't load processing setting if external WAV file is set
as audio source.
* NET mod stop if output type is old format AVI.
* NET mod stop if output type is OGM.
* NET mod freeze when input is too short.
* NET mod freeze when input file is MPEG-2.
* NET mod freeze when input file is OGM.
* CBR MP3 muxing cause audio being out of sync.
* Script error occurred when OGM comments include special character.
* Whole batch process stopped after an error in a job.

Errata to the last changelog:
Its wrong that Cyrius didnt like '1337', he just didnt know what it means :p


Main reason for this release is I want you guys to test the new bad frame scanning features :)

[jonny]

Many thanks to you, Cyrius and all the other developers! :)

[DeXT]

I uploaded the 31-01-03 release with *.lst (VOB list) input support enabled to my homepage below. I also compiled the P4 optimized version as a bonus.

In case you think it may be useful to add *.lst support to the official release, the diff with the required changes is also available.

Get it here:

http://es.geocities.com/dextstuff

Bye!

DeXT

[Suiryc]

Thanks DeXt, just added it in our CVS.
The mod add the .lst & .m2v extensions in the VOB opening code.