DVX - converts DVD's and captures to XviD/DivX

[stax76]

Hi all,
after a longer period there is a new beta version of DVX
available, a mpeg4 encoding frontend similar to Gordian Knot.
The program is now pretty much feature complete and hopefully
stable, it can do everything that can be done manually like
cutting, mkv and ogm with support for container specific
overhead calculation, Vorbis audio and subtitles with full tags
support, chapters etc. The program is based on .NET, in order
to run DVX at least Windows 2000 or higher and Microsoft .NET 1.0
or higher is recommend.

here are the changes of version 3.042b:


merged auto crop and auto resize, it will only
performed once per source

added new dialog for multiple source files

added crop width mod and crop height mod option,
if the crop values don't fit these settings
DVX will highlight it and fix it automatically

the resize option source in the calculator dialog
will change width and size to the crop width and
crop size when cropping

added plugin to use mkvmerger to set the ar flag
for encoding without resizing, thanks to ChristianJHW

improved the online help (called help assistent in DVX)

reorganized the calculator dialog

changed XviD presets for standalone compatibility
and better quality

added job scheduler plugin to start the job list to a
given time, thanks to mumumat

added ConvertToRGB to the settings dialog to avoid
problems on systems with problematic graphic system,
thanks to Fallo

fixed a bug where trim wasn't added properly using
automatic source or IVTC with DivX and credits,
thanks to jernst and tsark

added a plugin to resize the main dialog,
thanks to spankmon

added Force Film to DVD2AVI dialog because don't
seem to work in some cases, thanks to JohnMK

fixed a bug that prevented the trackbar of the
preview to work properly using credits,
thanks to jernst

more precise overhead calculation for MKV and OGM

added new dialog "Common Codec Settings",
the settings in this dialog apply to all
passes, as well as to the credits and comptest

moved Demux and DVD2AVI dialog to options
so new users won't overlook the dialogs

main dialog and calculator redesigned

common codec settings updated to latest DivX
beta

improved the docking of the calculator form

fixed a bug where the crop and prview dialog
showed no picture on startup

changed the aspect ratio error assistent tip
in the advanced options from absolute to
minimal and maximal, default is -1 to 2

renamed many settings in the advanced options

many assistent improvements, assistent tips
and highlighting is now synchron, almost every
tip will also highlight one or more controls

main menu -> help -> guides updated with guide
by giotis at http://users.tellas.gr/~giotis23/index.htm,
thanks to giotis

added a button to select the size

added a feature to change the size according
to comptest available optional after the comptest
and via the button for the size selection

added the possibiliy to split at CD size

pressing page up/down when the size textbox has
the focus will now change the size according to
the target length, 1 MB on a 1 minute clip,
5 MB on a 10 minute clip etc.

fixed some problems with language tags in ogm and mkv

other small changes and tweaks

[bb]

Thanks for the information, Dolemite.
A question from my side: does DVX open DV type-1 and type-2 files correctly?

bb

[jernst]

I'm not DV specialist but I recently made DV->DivX using DVX without problem. I don't know what type of DV it was (I got it from my JVC DV camcorder).

Everything went alright !

[stax76]

I never testet such a source, DVX should be able to deal with any source AviSynth can deal with. By default DVX will demux and decode AVI files automatically (Options -> Demux -> Decode). The default script is the following:

(FindStr("%source_file%",".avi") > 0)
\ ? AviSource(%source_files_comma_separated%,false)
\ : MPEG2Source("%source_file%")
Crop(%left%,%top%,-%right%,-%bottom%)
BicubicResize(%target_width%,%target_height%,0,0.5)
Limiter()

it means if AVI then AviSource else MPEG2Source, the macro %source_files_comma_separated% will be replaced with the files selected in the dialog for multible source files which will pop up automatically as soon as you open a source file. If this script can't handle your source then you can customize the script in various ways, the easiest way is to use the AviSynth menu in the main dialog which is customizable. All settings to handle the source should be made before you open the source because as soon as you open it a couple of processes start automatically, for DVD and DVB the default settings work, for other source possibly some settings has to be changed

hope this helps

[bb]

Thank you, Dolemite,

I've seen a bunch of AVS scripts being generated in the same directory as the source file. Each of them had an AviSource command, but I'd need a DirectShowSource on the computers where no VfW DV driver is installed. Which is the easiest way to accomplish this?

bb

[stax76]

the easiest way is to customize the the AviSynth menu in the main dialog, the tooltip explains how it works. Left click on the item you want to edit while pressing Ctrl (most likely MPEG2 Post Processing). If you want DVX to start up with a DirectShowSource script you got to edit the default script, make your changes and go to main menu -> profiles -> save standard profile.

[bb]

For some reason DVC crashed without an error dialog when using DirectShowSource. I have to investigate further on this.

In the meantime I could successfully convert a type-2 DV file, but only after installing a VfW DV codec (Mainconcept). The same file as type-1 did not work; I guess DVX can't extract the audio (neither can AviSynth). Unfortunately I couldn't create a video without audio from the type-1 file either. I'll check this out again, too.

bb

[bb]

Just checked a simple AviSynth command like
AviSource("C:\...\DV_type-1.avi")
and it crashed in WMP 6.4 with an "Evaluate: Unrecognized exception!". So I guess AviSynth is to blame for the failure, not DVX. What a pity.

bb

[Barker]

Dolemite, I respect you, and your .net program, but can you please refrain from calling DVX "superior" to GKNOT?. A lot of people like both programs (myself included) for different reasons, and calling one superior to another comes off a bit arrogant, which might hurt the ideals of users to both programs in the future.

My 2 centz.

Barker

[stax76]

@Barker

you are probably right, I just changed it to Gordian Knot alternative

[kxy]

If the program is stable, maybe doom9 is willing to do a test and a guide on it this time.

[stax76]

If the program is stable, maybe doom9 is willing to do a test and a guide on it this time.


I had two long conversations with him, unfortunately there were too much things we couldn't agree. His idea from software is different from mine, starting by the plattform DVX is based on (.NET), ending by the concept DVX is based on (one screen concept). I assume Doom9 isn't very happy discussing such things in public so I better stop here ;)

[kxy]

Originally posted by Dolemite
His idea from software is different from mine, starting by the plattform DVX is based on (.NET), ending by the concept DVX is based on (one screen concept).

Those can be put into the con session. ;)

[stax76]

Those can be put into the con session.


well, .NET is actually brilliant technolgy or like Gnome Guru Miguel de Icasa would say it's beautiful. If you go to the Visual Basic homepage http://msdn.microsoft.com/vbasic/default.aspx Microsoft advertises VisualBasic for the most productive way to write .NET applications, actually it is the most productive way to write software. Code completion, IntelliSense and Auto indent are way better than C# and everything else. Unfortunately Microsoft didn't clean up the VB6 crap, syntax is too long and real hackers use nothing but C/C++/C# anyway so C# is the way to go. With .NET and excellent IDE's like VisualStudio or #Develop you write code three times faster than C/C++ and a lot faster than with anything else, that's one of the main reasons besides some others like portability why Gnome hackers work on Mono, they want to be able to write code 3 times faster and migrate Windows developers to Gnome because most Windows developers will work with C# in the future. To put it short, a .NET program is already finished while others aren't half. Delphi for instance which would be the only alternative for a application like DVX completely failed on Linux like Java completly failed on the client side, sure this won't happen with C#.

As for the program concept, I think it depends on personal taste. Most people prefer a wizard approach for complex procedures which is normally the most natural and comfortable way, the problem here it is not flexible enough for our purpose because most people play around a lot before they are satisfied, make several comptest, play around with the crop values, the resolution etc.
A tab approach can be similar to a wizard approach, you can follow a direction but can jump back and forth if necessary, the downside of most programs designed that way is important features are right besides rarely used features which should imo be better hidden in seperate dialogs or by expanding/colapsing dialogs for the purpose of simplicity which was the main deveopment goal for DVX otherwise all programs could be used manually.

[int 21h]

Originally posted by Dolemite
...well, .NET is actually brilliant technolgy or like Gnome Guru Miguel de Icasa would say it's beautiful. If you go to the Visual Basic homepage http://msdn.microsoft.com/vbasic/default.aspx Microsoft advertises VisualBasic for the most productive way to write .NET applications, actually it is the most productive way to write software. Code completion, IntelliSense and Auto indent are way better than C# and everything else. Unfortunately Microsoft didn't clean up the VB6 crap, syntax is too long and real hackers use nothing but C/C++/C# anyway so C# is the way to go. With .NET and excellent IDE's like VisualStudio or #Develop you write code three times faster than C/C++ and a lot faster than with anything else, that's one of the main reasons besides some others like portability why Gnome hackers work on Mono, they want to be able to write code 3 times faster and migrate Windows developers to Gnome because most Windows developers will work with C# in the future. To put it short, a .NET program is already finished while others aren't half. Delphi for instance which would be the only alternative for a application like DVX completely failed on Linux like Java completly failed on the client side, sure this won't happen with C#.
...

The parts about development time are entirely subjective. All RAD (Rapid Application Development) languages appear on the outside to accelerate your development, and for simple projects, they can. However, when you switch into projects that are not so simple, you find that the difference is minimal. Its a case of diminishing returns.

And since you feel so compelled to share with us all the advantages of .NET, I feel very moved to share some disadvantages.


Performance with any variable higher than float precision with C# is non-existant. Your dreams about all programmers using it in the future are flawed at best. Anything needing high performance, high precision calculations is doomed with C#'s current framework implementation.
While the JIT for C# is hardly noticable, the footprint from framework is massive. A C# application takes up as much memory as you have available (i.e. If you have 60MB free, it will take a bigger spot in memory than if you have 30MB free.), this means that a C# application will always use more memory than an equivalent C++ application.
DirectX interaction. DirectX is still written in C++. So when you interact with DirectX in C#, you have to go through a managed C++ layer, creating more overhead. If you're trying to write a Snood clone, this may not be an issue, but if you're trying to write the latest greatest 3d CAD modeling engine, this is quite unacceptable.
The .NET framework is not finalized, the details of many of the APIs are not completely finished, so adopting now will mean you will very likely have legacy code quite quickly. If you don't think so, ask anyone who jumped into the JSP and Java Servlet stuff when they first came out.


There are only 3 reasons I can think of to use .NET

RAD
You use alot of COM stuff
You are really bad at managing memory on your own and are prone to leaks.


Surely the fact that the IDE is 'nice' is convenient. Intellisense can be very efficient. At the same time, be careful not to become entirely reliant on these tools. When you go to an employer for an interview and he asks you to write an Object in C# on the whiteboard, there will be no Intellisense for you there.

On the subject of portability... the only portability .NET offers, and will ever reliably offer is among Windows platforms. Mono is never going to support the endless amounts of Win32 specific API calls available in the framework. Basically what you have is the equivalent to an ANSI specification for C# being generated, you're only going to be guaranteed is if you specifically stick to the standards that are established and stay on the API calls that are implemented across all of the platforms. This would still leave you up a creek if you tried to port a .NET DirectX app (i.e. using DirectShow) to another non-Windows platform that lacked the appropriate underlying API support.

[stax76]

The parts about development time are entirely subjective. All RAD (Rapid Application Development) languages appear on the outside to accelerate your development, and for simple projects, they can. However, when you switch into projects that are not so simple, you find that the difference is minimal. Its a case of diminishing returns.


I didn't do any project more complex than DVX, I'm believe developping DVX using
C++ would take 2-4 times more without counting the additional learning effort of C++


And since you feel so compelled to share with us all the advantages of .NET, I feel very moved to share some disadvantages.


just like people feel so compelled all the time to criticize .NET
I'm aware of the fact .NET is not suitable for all kind of tasks
just like C++ is not suitable for all kind of tasks.


Performance with any variable higher than float precision with C# is non-existant. Your dreams about all programmers using it in the future are flawed at best. Anything needing high performance, high precision calculations is doomed with C#'s current framework implementation.


such a task would probably require something like dll import, com, unsafe code etc. All programmers indeed would be a dream indeed, let's just say most programmers who write ordinary code, no low level stuff. Of course all the other languages will still be there but the majority will be .NET


While the JIT for C# is hardly noticable, the footprint from framework is massive. A C# application takes up as much memory as you have available (i.e. If you have 60MB free, it will take a bigger spot in memory than if you have 30MB free.), this means that a C# application will always use more memory than an equivalent C++ application.


memory consumption is indeed a problem, #Develop uses 45 MB after startup


DirectX interaction. DirectX is still written in C++. So when you interact with DirectX in C#, you have to go through a managed C++ layer, creating more overhead. If you're trying to write a Snood clone, this may not be an issue, but if you're trying to write the latest greatest 3d CAD modeling engine, this is quite unacceptable.


although there are great interop possibilities, such kind of task is surely not what .NET targets on


On the subject of portability... the only portability .NET offers, and will ever reliably offer is among Windows platforms. Mono is never going to support the endless amounts of Win32 specific API calls available in the framework. Basically what you have is the equivalent to an ANSI specification for C# being generated, you're only going to be guaranteed is if you specifically stick to the standards that are established and stay on the API calls that are implemented across all of the platforms. This would still leave you up a creek if you tried to port a .NET DirectX app (i.e. using DirectShow) to another non-Windows platform that lacked the appropriate underlying API support.


the mono project is evolving incredibly fast, currently more than 150 deveoppers working on it. Version 1.0 is scheduled by the end of the year which is supposed to support most of the Microsoft implementation. The main purpose of Mono is building Gnome/GTK+ applications, not be compatible with every Windows.Forms application although they want to achieve this as well. Programs that use Win32 P/Invoke sure won't work on Mono, that's not the way to write .NET apps anyway. Managed DirectX which is afaik currently very basic most likely will be supported at a given time using the .NET bindings of GStreamer. Everything else of course cannot be ported just like a C++ DirectX software

[int 21h]

A couple more words, and then I'll vanish back into the place I've been hiding these last few months...

Java failed because when Java came out years and years ago, it was slow and buggy, and now Java is still slow and buggy. .NET has overcome most of that, and .NET is a very natural extension building on alot of the principles that Java began. But in my mind, the next evolution from C++ should be minus any ridiculous runtime environments (REs). REs are simply a means of control. A way to control who uses your language and for what. Microsoft could have just as easily developed a more robust oO stand alone language, but instead took the route that hooked deeply into their other business models.

Continue the good work though, you have the skills, the patience, and courage to offer to the community what many others (including myself) will not.

Cheers.

[stax76]

Java failed because when Java came out years and years ago, it was slow and buggy, and now Java is still slow and buggy. .NET has overcome most of that, and .NET is a very natural extension building on alot of the principles that Java began. But in my mind, the next evolution from C++ should be minus any ridiculous runtime environments (REs). REs are simply a means of control. A way to control who uses your language and for what. Microsoft could have just as easily developed a more robust oO stand alone language, but instead took the route that hooked deeply into their other business models.


at least we could agree on Java :D (although I really don't know Java), maybe Java benefits by .NET as well because SUN has pressure now to improve it.
I think the main purpose of developing .NET was because they needed a technolgy to overcome the shortcomings of COM, a technology for connecting and communicating between different devices. One consistent technolgy for various task, like targeting different plattforms (for instance handhelds), Windows based, Web based programming etc. that offers benefits only a runtime based techology offers, of course a runtime based technology has shortcomings as well just like every language or plattform has advantages and disadvantages

Regards,
Dolemite

[Doom9]

int21h: I'm currently working on a rather complex project in C# so my point of view has changed a bit. I'm still thinking that having people install a 23mb runtime isn't a good choice for a ripping program if there's an alternative that is much smaller and not many people have Windows Server 2003 that has the runtime preinstalled.
As for the RAD perspective, several studies have shown that more powerful and complex languages are more error prone... according to what I read in c't ML is one of the least error prone languages, C# and Java are somewhere situated in the middle with C/C++ being on the most error prone end (of course that's excluding ASM). This doesn't mean that it has to apply for every project, but it's a general average that C apps have more bugs than ML apps when created by programmers having the same experience in their language.

Java failed because when Java came out years and years ago, it was slow and buggy, and now Java is still slow and buggyHave you looked at some stats on how many IT projects require Java knowledge and how many require C/C++ knowlege? Afaik Java is the number one requirement today so I think it's preposterous to call it failed and it doubt it will go away in the near future. As for .NET languages, C# knowledge is rated very low, which can be an indicator of the current importance of .NET for the industry (and the fact that anybody who knows either C++ or Java will have no problem migrating if requires is certainly another factor).

I fully agree with you though on aspects like interoperability, being non finalized and the performance of interoperating with native code (you can bring those float tests up to speed though if you're good with p/invoke and bypass the slow .NET wrappers). But the MFC wasn't finished in one day either, was it? If you're dealing with MS technology I doubt you can take anything as being final.

I tried to run a very simple sockets program on mono when I started with C#, it crashed instantly even though all API calls I used were supposed to be supported. I don't know if I should've recompiled with a mono aware compiled, but that was it for me. But the open source community has surprised many times and I think it would be great if they managed to get a large portion of .NET apps running on another platform.

But in my mind, the next evolution from C++ should be minus any ridiculous runtime environments (REs). REs are simply a means of control. A way to control who uses your language and for what. Microsoft could have just as easily developed a more robust oO stand alone language, but instead took the route that hooked deeply into their other business models.
Any such approach would once again be platform dependent.. I cannot imagine Microsoft creating anything that would not require their operating systems, and the immediate layer aka runtime at least make it possible to run code on platforms that have a different native API (I ported a complex C# desktop app to PocketPC within less than 2 days and a large part of those 2 days were spent on improving efficiency on the main app and backporting it.. the actual porting did only take a few hours). And if it weren't for the runtime, you couldn't use various different languages and use the same API to program in them all (VB, C#, Java, C++, Fortran, and maybe there are more I don't know of).

[Barker]

I am wondering when M$ will incorporate .net into their operating systems, (maybe in longhorn) as it is a additional update on their page, and hasn't bothered too many people other than the ones that say its bulky (well it hasn't broken anything on my end yet). Bulky really isn't a problem with the hd space available now. As far as programming latencies and overhead (memory leaks), I haven't experienced any on my end, but I don't work with it that much so I'm pretty much talking out of my ass.

Back on topic now, anyone tried this version? I haven't been able too, my encoding machine had a PSU problem that took out most of my components (ANTEC too, so no PSU is completely failsafe). Im interested to hear how everyone is doing with this new version.

Thanx Dolemite, for making the conversion process even easier than b4 :)

Regards,
Barker

[bb]

Ok, after all the programming language preaching, I'm back with my DVX test results regarding DV input.

My conclusions are:

- DVX crashes when using DirectShowSource instead of AviSource in the AVS scripts.
- DVX does not open type-1 DV AVIs (neither does AviSynth).
- The only way to convert a DV file via DVX is using a type-2 input, and you need a VfW DV codec installed. This scenario is handled well, and DVX can simplify the conversion process by much.

By the way: I couldn't open a DV AVI file directly via GordianKnot 0.28.5, neither type-1 nor type-2 (Access violation).

bb

[stax76]

Afaik Java is the number one requirement today so I think it's preposterous to call it failed and it doubt it will go away in the near future


I think it failed on the client side, I don't even have a Java Runtime installed, I worked once with ds.jar which is a great Java based DVB demuxer and I tested once Eclipse which is nice as well, that's it. The majority of applications are VB, C/C++ and Delphi, maybe also Phyton and Perl on Linux


I am wondering when M$ will incorporate .net into their operating systems, (maybe in longhorn) as it is a additional update on their page, and hasn't bothered too many people other than the ones that say its bulky (well it hasn't broken anything on my end yet).


Longhorn will ship with .NET 2.0, hopefully Linux distributions will ship with Mono as well soon


Back on topic now, anyone tried this version? I haven't been able too, my encoding machine had a PSU problem that took out most of my components (ANTEC too, so no PSU is completely failsafe). Im interested to hear how everyone is doing with this new version.


most likely there is a bug causing the application to crash after ripping, a workaround is to open the calculator dialog before. I didn't verify it yet but it was reported


- DVX crashes when using DirectShowSource instead of AviSource in the AVS scripts.


and it does work when you open the such a script in a media player, show a proper overall length?

[Doom9]

about managed DirectX: this may be interesting: .NET version on Quake2: http://www.vertigosoftware.com/Quake2.htm
according to some tests I found in a newsgroup, the managed version achieves 85% of the speed of the native version (using the same code), and compared to the original ID Q2 the speed loss is about 30%.

[Barker]

Dolemites code is just calling external code to do the work just like gknot, so the lag is just in the app transfer, not in the app itself, like the comparison to quake.

[stax76]

I did never bother for any kind of optimization because the application doesn't perform any task that would require much speed plus it's a application you use only once in a week. On larger projects you use on the daily basis the jit compilation can be a downside but there is also a ahead of time compilation to overcome this if necessary. The Quake test is interesting, I was reading on osnews M$ is doing research on compiler technologies for increasing the speed even more, here is the link http://osnews.com/story.php?news_id=4114

[bb]

Originally posted by Dolemite
and it does work when you open the such a script in a media player, show a proper overall length?
I made two single liners:
1: DirectShowSource("C:\DV\20030726_type1.avi", 25, false)

2: DirectShowSource("C:\DV\20030726_type2.avi", 25, false)


File length is exactly (to the frame) 20 minutes. WMP 6.4 shows 20:00 for both files.

This is what I did:
1. Started DVX
2. Clicked on the AviSynth Script Editor button
3. Changed the script to the following:
(FindStr("%source_file%",".avi") > 0)
\ ? DirectShowSource(%source_files_comma_separated%,25,false)
\ : MPEG2Source("%source_file%")
Crop(%left%,%top%,-%right%,-%bottom%)
BicubicResize(%target_width%,%target_height%,0,0.5)
Limiter()

4. Selected the input file, either a type-1 or a type-2 DV AVI (same effect with both types)
5. Get an error message indicating "R6025 - pure virtual function call"

The error is reproducable.

bb

[stax76]

this should normally work

DirectShowSource("%source_file%",...

DVX takes the script and creates a new
script called *_Source.avs with containing
only the function that opens the source file.
DVX is using DirectShow for getting
information about the avs files and of course
for displaying them. If the files *.avs
and *_Source.avs play and show a proper
overall length in a media player usually
it should work. If there is a AviSynth
error within DVX than I think there should
also be a AviSynth error outside of DVX which
can be verified by playing the avs files
created by DVX with a DirectShow based media
player like Zoom Player. What you can also
try is something like this

DirectShowSource("%source_file%",...).ConvertTo...

maybe there is a compatibily problem with the
colorspace

[stax76]

Hi all,
I've worked a little on getting a precise target size
and fixed some bugs, I really hope it stays in a
acceptable range of +-1 MB now. Jernst is at holiday
so no updater and SysPack updates and no installers atm.

download here

http://home.tiscalinet.de/pva2divx/dvx.rar


3.043a2

fixed a bug in the bitrate recalculation after
the credits encoding. This bug was almost as old
as DVX, it produced undersize depending on the
size of the audio tracks, large audio tracks
produced large undersize

some calculations improved, the final size normally
shouldn't be more than +-1 MB out of size, my last
three encoding with different settings tested were
all between 0 - 0,7 oversize which is a acceptable
range. My tests included XviD and DivX from 0 to 1
B-Frame, avi, ogm, mkv, mp3 vbr, mp3 cbr and vorbis
at 90 kbit/s

fixed the proper display of the help which was
broke because of the preview dialog

###############################################

3.043a1

the calculator will now be displayed at program
startup to avoid a bug I couldn't find

the log window will be displayed when the
joblist is used, I couldn't find a way to move
the program from the taskbar to the tray

credits for XviD will be encoded seperatly like
DivX because XviD has problems here

using credits the parts will be encoded direct
in the proper container format instead of first
avi because recent VirtualDubMod versions
support appending ogm and mkv segments

using credits appending the parts and muxing
will be all together in one process

[Latexxx]

It would great if I could choose the credits beginning point from the chapter list.

[stax76]

I think there is no way to avoid to set the credits start visually but I'm thinking of a way to jump to the point where the last chapter begins, the C key is used to set the credits start, maybe I could add Ctrl + C to jump to the start of the last chapter or when the credits are not selected already jump to this point automatically when the preview is opened

[Latexxx]

That sound pretty nice.

[stax76]

I did some improvements, jernst is still at holiday
so it comes without installers only available at the
link below

this is what I've worked on:


3.043a3

in the preview dialog, Ctrl + Up jumps to the
previous chapter, Ctrl + Down jumps to the next
chapter. To quickly search the credits start
press Ctrl + Right to jump to the end of the
movie and press Ctrl + Up to jump to the last
chapter where usually the credits start, thanks
to Latexxx for the suggestion

improved the message of the folder browser of
the decrypting target folder and added a warn
message if the returned folder has below 10 GB
free space

replaced the tab controls in the settings and
options dialogs with a TreeView control

added a DVD Decrypter section in the options
and added a option to demux all audio streams
with DVD Decrypter

if DVX finds ac3 files it will preselect AC3
files instead of lst files

improved tooltips in the options dialog

added toolbar button codec in main dialog
for opening the common codec settings
and drop down list for the individual
codec dialogs

various other small changes


have fun: http://home.tiscalinet.de/pva2divx/dvx.rar

[Latexxx]

It works like a charm.

[stax76]

nice to hear, please let me know if you have any problems, for instance over- or undersized files, this is something that cannot easily be tested because it takes some time to encode a full movie, although I just bought a new CPU :D

[Latexxx]

My newest and fastest processor ever, Pentium 3 500 MHz is so good for video encoding. I can do 2Hz XviD encoding using vhq-4 and 2 consecutive b-frames.

Ps. Why Hz instead of fps? Because of hertz is a SI-unit which measures something per second (1/s). It means just the same as fps.

[bilu]

@Latexxx

I admire your courage in using vhq-4 on a PIII-500.

I have a PIII-500 laptop where I do most of my Avisynth script tests with default XVID settings, and even with default I can't get better than 3.33 fps... :rolleyes:

One could say there's not much of a difference between 2 fps and 3.33 (1.33 fps) but it's 116% faster... :D

Bilu

[Latexxx]

It isn't 116% faster. It is only 66,5% faster :D

(3,33-2)/2=0,665

[stax76]

Hi all,
we prepared a new version, it's only available
for updating using the update plugin because
the way we release at SourceForge atm is a lot
work but we consider to change this

then we are always looking for contributors, work needs
the translations of course, the AviSynth XML filter
descriptions, the AviSynth plugin collection, a guide
about how to work with the new AviSynth script editor
for the help file and for avisynth.org wiki and maybe some
other things I've forgotten. Of course request for cool
new features and bug reports are always needed as well :D


3.51b

added option to create the target directory automatically

added option for applying changes at main dialog avs menu
either to the selected script or to both

added more values to the XviD B-Frames settings in
the common codec settings

improved dutch translation

improved assistent

improved the navigation for multible preview instances,
now not all instances get activated/focused all the time

improved the navigation for multible preview instances,
clicking the trackbar will affect all instances

improved the navigation for multible preview instances,
now owner dialog of the preview is always the main dialog

improved the navigation for multible preview instances,
now all locations from where the preview can be opened
will open multible instaces (changing settings won't
update the preview any longer)

fixed a bug were no image was displayed in the crop
dialog because of a threading problem

fixed a bug were no image was displayed in the crop
dialog because of a wrong filename

fixed starting of the decrypting automatically,
the option was inverted

fixed a bug were the credits script was corrupted
when opening a profiles while the credits script
is active