[VirtualDubMod] 1.5.4.1

[Belgabor]

Belgabor:
- Fixed I18N not working in HexViewer
- Fixed I18N/p18 related bugs in VirtualDub.rc
- OpenGL32.dll and Glu32.dll for the about box are now loaded dynamically.
This may speed up loading of VirtualDubMod and reduce memeory cost.
(Well, as long as you don't open the about box ;) )
- Fixed P4 build. LibEBML doesn't work with the Intel compiler, so its compiled
with the normal M$ one.
- Added "LoadAviSynth(string path)" to sylia functions.
- Since AviSynth 2.5.2 the special code to allow coloring of external plugin
commands is part of the offical codebase. Therfore the special avisynth.dll that
was available from our page will be removed.
- New icon, designed by mf.
- Updates to the script editor:
* Added a new mode to the script editor for Decomb override files. So far this is
nothing special, except ranges are copied with "," like for the Avisynth
handling (also see next point). Requests are taken for improvements =).
This mode is auto-set for the extensions ".tel", ".fb" and ".dec".
* The 'None' mode in the script editor now pastes ranges with "-".
* Filenames can now be inserted with a nice file open dialog. In 'None' mode they
are inserted as-is, in AviSynth mode with "'s around them.
- Fixed a stupid bug with the 'Save & open in Virtualdub' function in the Editor.

Cyrius:
- Fixed a bug that would multiply the number of audio streams coming from the
opened video file when using the Refresh feature.
- Fixed bug not showing properly the video panes when opening via AviSynth.
- Fixed crash when opening via AviSynth without using a script.
- Fixed bug reseting the frame position to 0 when refreshing.
- Really added the SaveMKV functions for Sylia (better for batch mode :p).
- Fixed ending crash when compressing to MP3 inside VirtualDubMod.
- Fixed bug where disabled streams would still be written in the Job file.
- Quick fix (seems to work) for the program crashing when being called with
the /x commandline options, and when the input file is in YV12 (i.e.
generally an avs file).
- Fixed bug generating invalid OpenDML (>2GB) AVI files introduced in 1.5.1.1a
when using audio streams.
- Fixed a bug (generally a crash) when reading Matroska files in CBR mode
(e.g. 'Preview' instead of 'Preview VBR')
- Externalized the modified resize filter (the one based on and replacing the
internal VirtualDub resize filter in 1.4.x versions of VirtualDubMod).
Fixed some bugs in it as well :)
- Coded an extended TreeView control for the Preferences.
- Added support of 'rec' lists when writing AVI files (similar to AVI-Mux GUI).
Finalization of AVI files takes some time when using this option.
- Updated libebml/matroska to latest versions (fixed some memory leaks).
- Fixed some memory leaks in Matroska support.
- Fixed bug preventing VDubMod from accepting AC3 files with a bitstream
version lower than 8 (current specs version is v8).
- Fixed some crashes when reading mkv files (demuxing / transmuxing, ...).
- 'Interleaving' item of the 'Audio' menu is now accessible to subtitle streams
when right-clicking in the stream list. Allow to change the stream offset.
- Fixed some bugs in the Matroska support.
- Matroska files with unknown audio tracks (unhandled IDs) are now accepted.
Those tracks will only remain valid when being remuxed in a Matroska file.
- Added an option (Preferences) to speed up Matroska reading in VirtualDubMod.
This requires more memory but Matroska reading part is 5x faster.
- Fixed another crash in the CBR reading code of Matroska files.
- Lowered a bit memory consumption when parsing OGM/MKV files (<10% gain).
- Moved VirtualDubMod preferences in its own registry binary entry to prevent
any future conflict with VirtualDub (in case Avery Lee adds preferences).
Nb : those settings have thus been reseted to default values. Matroska prefs
were already in a separate registry entry and aren't reseted.
- Added audio clipping settings in the 'Interleaving' window, which allow to
have different settings for each track. Changing those settings in the
'Video->Select range' window (which show you the default values when adding
a new track) will apply it to all streams.
- Fixed bug with matroska support where we would write wrong audio IDs ^^; ...
- Fixed rare bug where MP3 streams in AVI may be read as using Nandub tricks
while they don't (thus leading to out-of-synch issues when editing).
- Fixed bug with AVI 'rec' lists (last one not being properly closed).
- Merged 1.5.4 changes (and added a bunch of brand new bugs :p)
- When opening a video for which no VfW decompressor could be found the program
forces 'Direct stream copy' mode and uncheck the 'Show input/output video' menu
items. A warning will appear to let you know about that.
- Now handle unknown Matroska video stream IDs. In this particular case you are
only allowed to 'Direct stream copy' to another Matroska file.
- Can now process subtitle streams in Matroska files (only properly handle non
overlapping subtitle streams).
- Gained some more space in the way Matroska information are stored in memory
when parsing a file. The new (faster) read method is always used now.
- Fixed bug where keyframes reported when reading a Matroska file would be wrong
when there are consecutive dropped frames in the stream.
- Fixed bug where keyframes reported when reading an OGM/Matroska file would be
wrong in the last 7 frames.
- Native MPEG4 streams (with B-frames) coming from Matroska files are supported
(for editing and recompressing; uses XviD codec).
- (Log) Error appears when you open / append an OGM file containing errors.
- (Log) Error appears when you open an SRT file containing errors.
- Bad subtitles (invalid times, ...) in SRT files are discarded and don't stop
the file processing anymore.
- Thanks to 'The Crazy Rabbit' for updating codecs.ini with the help of abcAVI.
- Now uses libebml class that should handle >2GB matroska files.
- The 'Mpeg Audio' import filter should better import all kind of streams now
(MPEG v.1/2/2.5, Layer I/II/III).
- Now handle even overlapping subtitles in Matroska files (may still be buggy).
- Fixed bug where some frames were considered as dropped ones while lacing was
used on the video track (happen with some files not muxed with VDubMod).
- Support basic (not nested) tags and chapters in Matroska files (see the doc).


Have fun =)

[stax76]

great work! I think I'm gonna start now to serious mess around with MKV :D

[puschpull]

Thank You, Belgabor!
Super!

[Selur]

Thx for the new build.

"Native MPEG4 streams (with B-frames) coming from Matroska files are supported"
Is VirtualDubMod able to produce such (native) files?

[stax76]

Is VirtualDubMod able to produce such (native) files?


good question

again thx for this new version

[Suiryc]

Originally posted by Selur
Thx for the new build.

"Native MPEG4 streams (with B-frames) coming from Matroska files are supported"
Is VirtualDubMod able to produce such (native) files?
Nope. This would require for us lo link directly to XviD (either statically - i.e. we would have one version of the XviD codec inside the exe - or dynamically - you would need an XviD.dll on your system) and bypass VFW in the video compression core (also we would have to find a way to change the XviD settings :p) to be able to get a somewhat normal MPEG4 stream (i.e. no dummy frames and the like).

There is a tool (avs2matroska, developped by DaveEL ... but a little broken ATM, and DaveEL may have no time to keep on working on it) that produced some (test) matroska files with a native (XviD) MPEG4 stream and we used some of those test files to get this feature working in VirtualDubMod.

[stax76]

which filter and player is required to display subtitle and audio track tags in MKV? I have a little problem to display the tags here :)

[Selur]

"you would need an XviD.dll on your system"
Can't see the problem there :D
But anyway thx for answering. Native mkv support would rock. :D

Cu Selur

[stax76]

is that supposed to mean Microsoft API's which VirtualDubMod is based on are are not capable of creating nativ MKV files?

[Kika]

Hm, the new Version still does not sove my old problem (http://forum.doom9.org/showthread.php?s=&threadid=57203&highlight=virtualdubmod)

That's crazy, the old Version can load the Filebut isn't able to demux the SRT-Stream, the new one say's: "No duration found for a subtitle", after scanning the Video. After that, no Video is loaded.

[Belgabor]

Originally posted by Dolemite
is that supposed to mean Microsoft API's which VirtualDubMod is based on are are not capable of creating nativ MKV files?
Ok, I'm no pro on this, but thats how I understood it: VfW which VDub(Mod) is based upon doesnt support out of order frames which is the native form of MPEG streams (meaning B frames are stored in the stream after all frames they depend upon). In matroska there are elemets for each frame giving references on which frames they depend. In fact I dont know in which order they are stored, but due to the reference pointers it doesnt matter. In VfW all MPEG codecs using b-frames cheat. They insert dummy frames to represent b-frames that should be there chronoligically. Actually they are stored with the P/I frame they depend upon in one 'frame'. This crutch/hack can also be used in matroska, but as said is a windows specific crutch giving all platform independeant programmers a headache.
Just to repeat, this is the situation as I understood it, probably there are ppl that can explain it better :p

Oops, forgot to clarify this: The trouble is not the MKV native format, its the basic MPEG4 out-of-order coding. Afaik you'd have the same problem if you'd try to make a native MPEG4 stream with a VfW codec.


Originally posted by Dolemite
which filter and player is required to display subtitle and audio track tags in MKV? I have a little problem to display the tags here
See the thread for the new matroska release in the new formats section :)

[Suiryc]

Originally posted by Dolemite
is that supposed to mean Microsoft API's which VirtualDubMod is based on are are not capable of creating nativ MKV files?
Short answer : yes

Longer answer :
The problem is due to the nature of VCM (the - old - API on which is based Virtual(Dub)) and the principal of B-frames.
First of all there is the Display order (the order in which you see the frames, thus with timecode increasing). B-frames will use backward and forward frames as reference. So to encode and decode a B-frame you need to read this forward frame too.

However VCM is a "one frame in, one frame out" system, meaning that you are supposed to give it a frame on input and it will give you a decoded/encoded frame as output. As you can see this is problematic with B-frames because you need to wait for next frames in the stream before encoding them.
The same goes on the decoding side. Since the codec needs to get the references of a B-frame before decoding it, they introduced the so-called coding order. It places the frames out-of-order so that a B-frame is always placed after its 2 references in the stream (this way the codec is sure to get the 2 references before the B-frame).
As a consequence those codecs produce 'dummy' frames (empty data) in the stream to compensate for the wait of forward references of B-frames.

Also VCM is only able to differentiate Key and Delta frames (it doesn't know anything about B-frames). So when you have a frame you only know if it's a Keyframe or not.


avs2matroska was able to produce 'native' MPEG4 streams because it was linking against XviD (so using the XviD API, which knows about B-frames and much more) and was bypassing the VCM API. The frames were still placed in coding order (it still need to get the backward and forward references of B-frames) and stored as such in the matroska file (i.e. frames are stored out of order).

[stax76]

thanks for the information, it's not easy to understand...

So when VFW/VCM is the problem maybe a new codec manager could be build on top of DirectShow which I asume is more flexible (although this obviously wouldn't be portable)

[bond]

great news!!!

but why isnt there aac/mp4 audio input possible till now? :(

[Suiryc]

Originally posted by Kika
Hm, the new Version still does not sove my old problem (http://forum.doom9.org/showthread.php?s=&threadid=57203&highlight=virtualdubmod)

That's crazy, the old Version can load the Filebut isn't able to demux the SRT-Stream, the new one say's: "No duration found for a subtitle", after scanning the Video. After that, no Video is loaded.
Well this error will be turned to a warning in next bugfix ...
First 1.5.1.1a version couldn't open it because it wouldn't handle subtitles in matroska files.

Originally posted by Dolemite
thanks for the information, it's not easy to understand...

So when VFW/VCM is the problem maybe a new codec manager could be build on top of DirectShow which I asume is more flexible (although this obviously wouldn't be portable)
Unfortunately DirectShow isn't flexible enough for a precise editing application. (... last time I heard of it Avery Lee somewhat gave up the idea of using DShow as basis of VirtualDub 2).

But yes using another (more recent and flexible) API would help. That's why you heard a lot about UCI (Universal Codec Interface) by some people for a certain format (;) :p).

Originally posted by bond
great news!!!

but why isnt there aac/mp4 audio input possible till now? :(
AAC may come later (we will have to see how is made an AAC stream).
MP4 is another thing (it's a complete format and as for OGM and Matroska it would need a lot of work and source code) ...

[bond]

hm, seems that reading rv9 content muxed with mkvmerge works fine in vdm but rv9 content muxed with gabest's matroskamuxer isnt working! i get the following error message: "found a frame with only one (forward) ref, unhandled!"

btw. i get the same error message when i try to open this (http://matroska.free.fr/downloads/mp4-small.mkv) file, which should include native mpeg-4 content...

Originally posted by Suiryc
AAC may come later (we will have to see how is made an AAC stream).
MP4 is another thing (it's a complete format and as for OGM and Matroska it would need a lot of work and source code) ...i see :(
hm, imho aac/mp4 is THE coming format, especially since he-aac is available, hope it isnt getting ignored or so :(


btw. to the .mp4 container:
you allow .mp? (mpeg audio file) input -> this would also mean .mp4 input support of course (although .mp4 files are chooseable, mp4 isnt obviously supported now)
i guess you just wanted to summarize .mp2 and .mp3 support under this option!? to avoid any confusion perhaps it would be better to write .mp2 and .mp3 in the drop down list i think...

[r0cket]

Originally posted by bond
seems that reading rv9 content muxed with mkvmerge works fine in vdm but rv9 content muxed with gabest's matroskamuxer isnt working! i get the following error message: "found a frame with only one (forward) ref, unhandled!"

i'm not able to open matroska with realvideo9 content in vdubmod at all: "Couldn't locate decompressor for format 'ỹỹỹỹ' (unknown)". i have also vorbis audio stream in the file. (tried video only too)
is CFR means constant framerate? how to produce CFR stream with helix producer?

[Suiryc]

Originally posted by r0cket
i'm not able to open matroska with realvideo9 content in vdubmod at all: "Couldn't locate decompressor for format 'ỹỹỹỹ' (unknown)". i have also vorbis audio stream in the file. (tried video only too)
This is normal, except for MPEG4 streams (fow which we trigger the XviD VFW codec) we set rhe video codec to unknown and only allow Direct stream copy of the clip.

Originally posted by bond
hm, seems that reading rv9 content muxed with mkvmerge works fine in vdm but rv9 content muxed with gabest's matroskamuxer isnt working! i get the following error message: "found a frame with only one (forward) ref, unhandled!"

btw. i get the same error message when i try to open this (http://matroska.free.fr/downloads/mp4-small.mkv) file, which should include native mpeg-4 content...
Dunno about your first mkv file, but the mpeg4 sample appears to have a wrong frame reference in the middle (it uses 2 forward frames as reference). Guess it's a bug (and since in theory this sort of thing is allowed in matroska - but not used by any codec that I know - but doesn't correpond to MPEG4, that's why this triggered the error).

[itsme_4ucz]

Thank You, Belgabor!
Super!

[Didée]

* Post deleted *
The bug was in my system, not in VdubMod. ;)

- Didée

[r0cket]

Originally posted by Suiryc
we set the video codec to unknown and only allow Direct stream copy of the clip.
so in fact editing is not fully supported, right? because i have only 2 keyframes detected by vdm in my 3216 frames file. and after cutting on a kf file is no watchable.

[jorel]

wonderful work Belgabor
:)

congratulations and thank you very much!

[Suiryc]

Originally posted by r0cket
so in fact editing is not fully supported, right? because i have only 2 keyframes detected by vdm in my 3216 frames file. and after cutting on a kf file is no watchable.
The other possiblity is that the video stream is not a 'perfect' Constant FrameRate one and since VirtualDub core only handle perfect CFR (it uses frame numbers and frame times so the time information is lost except if you have a constant framerate) ...

[Latexxx]

Originally posted by Suiryc
Nope. This would require for us lo link directly to XviD (either statically - i.e. we would have one version of the XviD codec inside the exe - or dynamically - you would need an XviD.dll on your system) and bypass VFW in the video compression core (also we would have to find a way to change the XviD settings :p) to be able to get a somewhat normal MPEG4 stream (i.e. no dummy frames and the like).


It would also be possible to read the data from existing .mp4 file.

[JimiK]

Thank you for this wonderful tool.
What is this "error handling" for video streams. I did a search, but without result. Does it just set some flag? Because no matter which mode I use, I always get the same video size.
Concernig size of a matroska file. I muxed a file with Gabests' matroska muxer (for ssa). Now that VDubMod supports ssa I did a remux just for fun. The resulting size is 6Mb smaller. I did my calculations with the 2nd pass avi file and after muxing with Gabests' tool it came out as exspected. How can it be smaller now (there was already not much overhead).
Best regards,
JimiK

[Suiryc]

Originally posted by JimiK
Thank you for this wonderful tool.
What is this "error handling" for video streams. I did a search, but without result. Does it just set some flag? Because no matter which mode I use, I always get the same video size.
You mean "Error mode" ?
This comes from VirtualDub. This is a way to tell VirtualDub what to do in some cases when encountering errors / unexpected things in the input data (while decoding generally).
So this setting won't affect anything if all is fine in your file.

Concernig size of a matroska file. I muxed a file with Gabests' matroska muxer (for ssa). Now that VDubMod supports ssa I did a remux just for fun. The resulting size is 6Mb smaller. I did my calculations with the 2nd pass avi file and after muxing with Gabests' tool it came out as exspected. How can it be smaller now (there was already not much overhead).
First, is the remuxed file fine ? (i.e. I hope nothing is missing otherwise there would be a bug ^^; ).
What is the total size of your mkv ? (6Mb may be a lot for small files)

I dunno exactly how Gabest's muxer works compared to VDM, but many things may make your final mkv smaller when remuxing :

1. Maybe Gabest's muxer reserved a lot of space at the beginning of the file for the MetaSeek information (position in file of elements), and maybe VDubMod made a better estimation and reserved less space.
Nb : since the overhead in mkv is variable we estimate how many space we need to write the MetaSeek at the beginning of the file. By default VirtualDubMod index the Clusters (see the specs of matroska (http://www.matroska.org) for more information) in the MetaSeek element.

2. Maybe Gabest's muxer uses a lower 'time range' for clusters (i.e. the average time that covers data written in a cluster). For VirtualDubMod the first (in 1.5.1.1a) default value was 5 second (i.e. when a cluster holds 5 seconds of data, we close it and start a new one). This default value has been changed to 1 second (which is the one used - since the beginning - in Mosu's tools IIRC) in latest (1.5.4.1) version. You can check this value in the 'Preferences' ('matroska' section, 'Limit clusters to (<32768ms) :' setting).
Of course lowering this value makes you will have more clusters in your mkv file, wich means more overhead for the cluster themselves and more entries in the MetaSeek if the tool store their position there.

3. Maybe Gabest's muxer muxed more data for audio streams. i.e. maybe the audio streams last a few seconds more than the video. When you edit a clip in VDM by default it will trim the other (audio / text) streams to match the video length.

And I guess there may be a few more reasons (bug in our code being one of them :p) ...

[JimiK]

Thank you for this exhaustive answer and sorry for not providing enough information. I was not on my own computer and was quite in a hurry.
You mean "Error mode" ?
Yes, that's what I meant. So it has nothing to with decoding in Players. What about the CRC32 error correction. Where is it set if it should be used or not? (At least robUx4 wrote that there is something like that in this version).

First, is the remuxed file fine ? (i.e. I hope nothing is missing otherwise there would be a bug ^^; ).
What is the total size of your mkv ? (6Mb may be a lot for small files)
The total size is 700Mb. Well, fine? Yes and no. First: I remux the "small" file with Gabests' muxer and it came out 7Mb bigger. So it's likely to contain everything (it's a 2 hour movie and I'm not willing to check it completely :) ) But then I watched a few scenes and in one scene a person that was moving blocked up (you know, like shit frames in old DivX 3). That's not the first time that happened to me, so maybe it's my computer. Later I remuxed the original mkv with VDubMod again and at least that scene was fine again. (I posted such a "blocking up" pic in the avs2avi thread in the developers forum long time ago when I thought it was avs2avi related).
Best regards,
JimiK

[Erhune]

Congratulations to all VDubMod developers. That's great work !

Erhune

[stax76]

I have a few problems with tags described here (http://forum.doom9.org/showthread.php?s=&threadid=59063), probably a bug but I don't know exact from which software

[Manao]

Bug report ( @suiryc, I think ) :

I have an avi file, with mp3 vbr audio. When I when to change the container to ogm ( to add subtitles ), VDubMod hangs ( the the fps stays at 0 forever when saving as ogm, and when I abort the dub, nothing happens, and worst, when I want to close VDub by clicking on the cross, nothing happens neither ). It's not the fault of the subs ( just opening the avi, and saving as ogm is enough to make VDubMod hang )

It's specific to this avi file, others work fine. Tell me what you want as information on the file to help you find what gone wrong.

It's an appearing bug, since VDubMod 1.5.1.a works fine with this file.

[Suiryc]

Originally posted by Manao
Bug report ( @suiryc, I think ) :

I have an avi file, with mp3 vbr audio. When I when to change the container to ogm ( to add subtitles ), VDubMod hangs ( the the fps stays at 0 forever when saving as ogm, and when I abort the dub, nothing happens, and worst, when I want to close VDub by clicking on the cross, nothing happens neither ). It's not the fault of the subs ( just opening the avi, and saving as ogm is enough to make VDubMod hang )

It's specific to this avi file, others work fine. Tell me what you want as information on the file to help you find what gone wrong.

It's an appearing bug, since VDubMod 1.5.1.a works fine with this file.
Does this also happen when you disable the audio track ? (i.e. when you only want to save the video)
Does it also freeze when trying to demux the mp3 track ?

I don't think I will be able to fix this problem soon since I will be away (without internet access) for 3 weeks starting tomorrow :(

[Manao]

Well in fact, I should have check the resulting ogm obtained with vdubmod 1.5.1.a, because the audio is out of sync :(

So perhaps the avi file is wrong somehow. I will make some more tests and report what I will find.

Edit : It works when I disable the audio. But I can't demux the audio ( trying to do it make vdubmod crash writing after a moment "thread deadlock detected attempting to abort - killing process" )

Finally, demuxing works with 1.5.1.a, and remuxing with 1.5.4.1 makes
a file not perfectly sync ( half a second out of sync, I would say, it's a cartoon, so it's hard to say ) but much better than previously ( 1.5.1.a is also better if we demux then mux the audio in this particular case )

Edit 2 : don't work neither for mkv, same bug, and with the 'workaround', same desync. The audio track must have a problem. I checked the avi, the audio is sync here. When you come back, if you want some data, I'll be able to provide it to you.

[alx]

Hi ppl, really thanks for this new version of VDM...
I want to ask one question, because i didn´t find anything related in the forum already.
First, i would like to apologize by my poor english, but i am a spanish speaker, inglish is not my mother tongue.
Until past week, i was using VDM 1.5.1.a without a problem, but my hdd died so i have to buy a new one and install all again. Since that i cannot join fine an avi file with its mp3 vbr track again.....the audio went asynch........at the begining and at the end is ok, but in the middle is asynch.
Curious thing is VDM 1.4 WORKS FINE!!!....same avi and same mp3 and VDM 1.4 joins them perfectly........i tried VDM 1.5.1a and 1.5.4.1 and i get the same error............i installed windows xp twice, and w98 and same thing happen....
I downloaded the full version ("VirtualDubMod_1_5_4_1_All_inclusive") and still the same problem, but 1.4 works fine.
Hope you could give me some help.
Really thanks
alx

[yaz]

@manao/alx
the same here :-(( siince i use vdm15x i have always problems with synching vbr/abr mp3.
i have lots of avis muxed with vdm14x, all in synch. from some of them, i tried to demux the mp3 with vdm15x. it was only possible when i allowed the 'correction' for the header. anyway, overkill on demux, incomplete operations on 'save wav'. audio demuxed this way can't be muxed again wout manual synch adjustments. no problems with nandub on the same streams, demux/mux is perfect.
what happened with this part of vdm???

y

[EDIT] oops, i've missed the bugfix-release ... maybe that

[Belgabor]

@alx (and yaz): There are three options that could be the cause of / solution to your problem.

Do not correct MPEG Layer III audio streams
By default try [...] like Nandub
Keep corrupt data (Audio section)

Please try to toggle them and see if one helps with your problem. Also plase check if in your case the problem is specific to avi output or whether it's correct in OGM and/or matroska.

Originally posted by yaz
[B]it was only possible when i allowed the 'correction' for the header.

Why?

[Suiryc]

Originally posted by Manao
So perhaps the avi file is wrong somehow. I will make some more tests and report what I will find.

Edit : It works when I disable the audio. But I can't demux the audio ( trying to do it make vdubmod crash writing after a moment "thread deadlock detected attempting to abort - killing process" )

Could you go in the 'File information' window and see what VirtualDub(Mod) says about the audio stream (especially the 'min/avg/max framesize') ?
The dubbing core changed in 1.5.4.1 compared to 1.5.1.1 (as for VirtualDub 1.5.2 and next), that would explain why 1.5.1.1 could process the audio stream ...

[Manao]

The min/avg/max/total numbers are : 96/397/14208 (92656K)
Number of chunk : 238814
But the strange thing is : length : 4:37:02.18 ...

I hope this will help...

[Suiryc]

Originally posted by Manao
The min/avg/max/total numbers are : 96/397/14208 (92656K)
Number of chunk : 238814
But the strange thing is : length : 4:37:02.18 ...

The min and avg values seems quite ok. However, in my opinion, the max value (14208) indicates that the original MP3 stream was corrupted. I also think this value indicates that it's likely that the original MP3 file has been muxed using Nandub or a (really) old version of VirtualDubMod.
According to the average size of the mpeg audio frames in your file (397 bytes) and assuming that there is only one corruption point in your file (that is where you have an AVI audio chunk of 14208 bytes) then the corruption may represent a bit less than 1 second of audio data (for a 44.1/48kHz stream) (maybe the cause of the delay you can notice).

Thanks to your information I was able to reproduce the bug (that is I corrupted an mp3 file almost as much as yours, and muxed it in an AVI file using Nandub).
I think this bug is fixed now :). I may upload the fixed exe somewhere soon, so that you can test it if you want.

[EDIT]
You should find it here (http://cyrius.bunkus.org/VDubMod_Release.zip). It's a Release build. It also fixes a few other bugs.

[iago]

Suiryc,

Are these bug-fixes in the release build that you link to included in the latest "VirtualDubMod_CVS_20030809.zip"? Thanks.

iago

[Suiryc]

Originally posted by iago
Are these bug-fixes in the release build that you link to included in the latest "VirtualDubMod_CVS_20030809.zip"? Thanks.
Nope.

This release is one month old (was made on August, the 9th, not September, the 8th ;)).