Supercalifragilisticexpialidotious
Looks EXCELENT andrej

-kwag

I agree.
I wonder why Incredible developped it only for d2v projects as input.
What when I want to resize captured avis?
Or am I missing something?

I NEVER managed to say that word, and even to read it fluently

@Luis,
What you miss is that KVCD.net is aimed towards DVD backup. That's so simple.
(don't tell about capture that is perhaps 3% of members real occupation. Other avi are... you know.).

a) Phil is right related to DVD Sources and so as 95% of all users do resize d2v Stuff this is prority (now).

b) Also youre right Luis, for shure avi Sources have to be handled too.
As said at the beginning of this subject in this thread: This d2v reader was just a part of a project Im developing, so I separated the core to be usable as standalone appl. In the "other" application also a complete resizer will be included so a work on a new resizer has to be done so or so. Thats why I also will integrate it in that d2vAutoCropper.
AviResizing is very individual in case of captured avis, as maaany Cards in combination with individual drivers do result in diff. µs acitve areas, so that should to be taken into account, but needs a total rewritten Resize core from scratch. d2v Sources got standard µs acitve areas so thats not a problem.

Im thinking about the issue of handling PAR 1:1 Avi Inputs as 99% PAR 1:1 Avis except 768x576, 384x288, 640x480, 320x240 are already backuped original DVDs, so the user can backup those movies from scratch using the quality of the DVD Source, if that source isnt available: Its a warez avi!

Don't bother with avi. Add support for avs script (that is probably the same things for PureBasic). This way, whatever the source is, the app will support it. If the user is not abble to do an avs that can open its source, then it won't need your tool.

I didn't miss nothing.
Some times you seems a little bit senil.
Do you think that a programmer will leave a tool works only partially, when with a little more code, his tool could be useful for much more people.
You are missing that here we are talking of advanced video conversion.
Doesn't matter how percentage of people do capture, Incredible tool will be extremely useful for them.
Also you are forgetting that new codecs, rmvb, some related with Microsoft, etc., are really high quality (not all PCs could play it), inclusive as sources. Incredible tool would be better if it could load those files in any way. Some of those codecs encodings have rare resolutions (some as super, super wide screen)

First, this is not "little more" as explained by Inc.
Second, a tool that does not do exactly what you want does not work partially. It is just not the tool you need. A tool that works partially is a tool that does only half of the work it is supposed to do.
Third, no one is supposed to do tools that match every situation, moreover if the developper do not have this need for himself.
For instance, why don't you change your ASPA to be used with more than 3 files ? I'm currently doing DVD with 8 TV show ep on a disc, can you please modify your app ? (don't do, I'm just kidding to illustrate my words ).

Read my former post about that then... You asked for avi, I answered to use avs insteed.

Theres a problem when just imorting Avs's:

1. The avs bitstream will be recognised only as PAR1:1 and no aspectratio info will be served ... as you know its a simple bitstream withot a header.
So in case of d2v the very needed infos wont be available.

2. In case of avi you could be right as PARs etc. could be just read out of the sizes (via "if width = 720 and height = 576 then par= 128/117" for example).

But this tool should be able to import a native source incl. generating the avs script. So that avs script can be used for further editing etc.



He can easely do it:

One "audiosources" button is needed no more, each time you add an audio, an internal filesize parser will calculate the sum of all used audios. As audio in this case is a simple amount of space for his internal ASAP calculations. Also he can generate in the same logic a Button "Extras", there the Menues and subs, PC ROM data etc. in its sum of size will be added in its kb calculation.

Finally the more Appl.Window space which results by choosing the way above can be used for more avs inputs.
And even here he easely could reduce that as there will be only ONE avs inport button incl. a List-Box Gadget where all imported avs's will be listet (like the Batch Window in Packshot). If you want to delete one imported avs, simply go into that list box and delete the Name/Entry.



(nope I didnt build all Buttons from scratch, the lower part is a screen copy. *lol)

Shure the "Process" Button is needed on the side below

@Incredible

Hi Andrej,

The image you posted >here< a few posts up looks really cool. I can't wait to see your tool's next release when you have the time to do so.

It will really help me out to get the best out of my DVD backups and the resizing I need to do.

Can't wait to see it, for me I am more than happy it only supports d2v sources as all my projects are from DVD source, I am going to buy a capture card but I cant see that happening until after Christmas.

__________________
Regards.

Michael.

Read what I just saw on Doom9 news :

Well I was refering to hough differencies.

In DVD2AVI resulted project files there are some infos about the origin VOB stream not included like the AR i.e.

DgIndex outputs much more Infos in the first lines.

So the first line in a d2v could be like this...

DGIndexProjectFile10 (or now DGIndexProjectFile11)

or DVD2AVIProjectFile

This first line of the d2v I do parse in my appl. to see which dll (dgdecode or mpeg2dec3) has to be used. Also this gives me the advice IF I should use a VOB header parser to get the needed AR info, like in case of DVD2AVI where its needed. DGindex resultet Projectfiles dont have the need to be parsed in thier original linked VOB.

So, as my appl. does simply just "take" the first 18 Letters of the first line, only "DGIndexProjectFile" or "DVD2AVIProjectFile" will result. No more needed, as everything else according to compatibility refers to the correct dgdecode.dll, provided with the Dgmpgdec Package.

Means IF you do use the latest RC1 of DgIndex then ALSO use the latest dgdecode.dll in the applikationsfolder.

You're right. I did not think that you don't decode the file, you let the dll do that.

But even a to "DGIndexProjectFile" copped string for recognisition could be tricky as maybe Donald G. could do hughe changes which could affect further procedures, so I also should let parse out the Number of the "DGIndexProjectFileXX" String for comparing/Allocating functions.

IMHO FitCD is useless in its parsing when using DgIndex instead of DVD2AVI, as FitCDs internal parser messes up when entering the d2v. Im shure FitCD also takes the 3d line, crops the first 3 Letters of that line and takes that resulted/cropped string for getting the correct path as string to the orig VOB which is needed for AR recognision (even if would not make sense as its mentioned in dgindex's d2v files as textline). NOW in vers. RC1 of DGindex the resulted 3d line in the d2v directly starts using the path name, no Numbers before. Means the 3-letters-cut-at-beginning-of-that-string-routine will now be applied on the true path string = fatal.

I gave my statement at the doom9 DgMpegDec Thread but DG told me that he wont stop evolutions only cause 3dParity Apps. wont be kept updated by their developers. Imho FitCD has been updated in the last year, seems shh should update his code.
But anyway ... is such a change in a textline of a d2v such an evolution in relation to the fact that only because due such changes many people wont use latest dgindex versions no more due they still want to use exisiting good tools?!

@Incredible

Thanks for the info Andrej, this is why for the moment I am sticking with DGIndex 1.4.0 final and I haven't updated to the latest 1.4.1 betas as you dont know how much change is going to affect your encodes.

__________________
Regards.

Michael.

@Incredible.

Hi Andrej, I just wanted to know how the work was going with regards to incorporating mencalc into the autocrop tool like the picture you posted above.

Please don't think I am trying to harass you or push you into releasing it quick I am just curious that is all, as you have wet our appetite with that screenshot and I can't wait to see it in action.

Thanks in advance buddy.

__________________
Regards.

Michael.

Hi Michael,

yep, Im on it. The last 2 weeks I got a hell of work in my job, so I just had only a few evenings to get a bit further on coding.

The import, parser, display, cropper (till now on static frame) do work. The Autocrop procedure will also be copied into the new code.
Also a "rendered on screen movieinfo"! will be available means all useful infos will be text-rendered in a small box at the right side overlayed on the displayed frame. The user also can switch it off, so you decide.

The problem is ... Mencalc was written in a total naive and quick'n dirty basic code, the calls wheren't done one procedures. Now that Appl. is fully procedural coded. And thats the point, Ive totally to disassemble the mencalcs sources. Mencalc works totally ok. but for a programmer to get into it its a hell (seen with my eye now, ... I could constantly hit my neck ).

This weekend I sweared to myself to take some hours continuing developing.

Hi Andrej,

Thanks for the update info. I know you are vey busy at work and I im sure you will code all in good time and when you have some spare time.

I bet that is a real pain in the as* to try and recode the mencalc part seeing as it is such a quick 'n' dirty code.

I wish you luck in trying to get to grips with intergrating the Mencalc functions into in your Autocrop tool, this will be an awesome and extemely helpful tool once released.

Thanks again for the updated info it is much appreciated.

__________________
Regards.

Michael.