I also got that Red Planet DVD too :)

Here is version 0.13b where I did some corrections on the pixelparser and also I corrected the second crop value info that it outputs a crop() variant without negative values. Also it should be a bit faster now as I do parse the sides using 1/6 of the total width from each direction and the height 1/4 from each direction as I dont think that Movies using Top/Bottom Border with more than 144px each will be used as source.

This is getting a very interesting thread :D.
Will try autocrop as soon as possible.
Thanks for sharing it with us Andrej :D.
Cheers

Hi Andrej,

Thanks for the update. :D

I don't what you did but it seems to have done the trick with regard to Red Planet. ;) It is good that you also have this DVD to test. :D

http://www.digitalfaq.com/archives/i...2005/08/31.jpg
Thanks to ImageShack for Free Image Hosting

If you look now at the above picture the cropping on Alien3 looks perfect. :D

I had to hit the Autocrop button twice because when I first loaded Alien3 and let it play for a bit and hit the Autocrop it messed up slightly in the left hand side on the first go, see picture below:

http://www.digitalfaq.com/archives/i...2005/08/32.jpg
Thanks to ImageShack for Free Image Hosting

The first picture is after I hit the Autocrop button twice. You will notice on the first picture the first value is 0 and the the left hand side on the crop is undershot.

The first picture after hitting the Autocrop for a second time it correct this and add a left value of 10.

I hope these tests of mine help you out in some way Andrej, for me this workaround of hitting the autocrop twice is o.k. :D

Thanks for updating and the changes that you have made to this excellent tool. :D

EDIT: Btw I love the fact that your tool give two different ways of adding crop values to your AviSynth script. :) In my case this is:

Crop(10,76,0,-76) or use
Crop(10,76,720,424)

Thanks again Andrej this is excelent work. :D

Do remember that you should not use directly any of that lines but put the values from the first one (ie 10 for left border, 76 for top, 0 for right and 76 for bottom) into FitCD and let it compute the correct Crop/Resize values.
Or wait to see if Inc decides to merge Mencalc and Autocrop as he planed to do :)

Thanks for the info Phil, I shall bear that in mind and do it via FitCD. :D

Entering those values into FitCD I get:
http://www.digitalfaq.com/archives/error.gif
Thanks to ImageShack for Free Image Hosting

Should the AddBorders line be used to replace the LetterBox command?

In DVD-RB I use as per your suggestion LetterBox(16,16,16,16), do the LetterBox and AddBorders work completely different?

Or could I use LetterBox(8,80,8,80)? Sorry for the dumb question but I still need to learn the differences between these two filters.

I take it if I use AddBorders that I don't need to add a LetterBox to my script is this true?

Also I agree I hope Inc does merge the MenCalc tool with this it will be awesome when that happens. :D

@Incredible

Btw my tests in my previous post was done using the latest version of your tool, I think I forgot to mention that. ;)

Yes they are. Letterbox put the border ON the picture, Addborder put it ARROUND the picture.
We have to use letterbox in DVD-RB because we can't resize. So the picture is the size of the source, that is 720*576. Then we "paint" the 16 pixels on each side in black, to gain some compressibility.

When you can use a resizer, it's a better idea to resize to something smaller than the targetted size (here your target 704*576) and add a border all arround to picture to reach the correct size.
That is exactly what FitCD does for you : it resizes to 688*416 than add 8+8 pixels on left/right (688 + 8 + 8 = 704) and 80+80 on top/bottom (416 + 160 = 576).

Yes it is. It either resize to target size + letterbox OR resize to a smaller res and addborder.

Did you notice that your last picture shows diffrent values than what you exposed ?
You said :
But your snapshot http://img291.imageshack.us/my.php?image=alien350hv.jpg shows that the values are Crop(10,72,-4,-74) 8O

Yeah sorry Phil I think I made a mistake when I inputted the values into FitCD, I don't know where my brains were at when I did that. :oops:

The correct values should have been: Crop(10,72,-4,-74)

Again thank you so much Phil for helping me understand how and when to use AddBorders and when to use LetterBox and for explaining why we use them a certain way. I now have a better understanding of how to go about manual encoding with these cropping values.

So thanks again. :D

You're welcome.

@Dialhot

Sorry Phil to bother you again, on one final note.

I was also doing some tests with Karl's MA optimal script, I know this uses GripFit and I thought if you enter these values in via MS then it would crop automatically for you.

However I notice near the end of the MA Script is the LetterBox command but with a # in front. I knows this turns it into a remark line and it will not be executed, it says depends on situation use MS.

Does this mean then if you choose not to use GripFit and do a manual resize via say FitCD or MS then you need to the values MS gives you for AddBorders and input that into the LetterBox params in the script?

I will use the FitCD method of resizing and do my script that way but I would appreciate some clarification with regard to matter please.

Thanks in advance.

Moviestacker let you choose between using addborders (resized overscan) OR using Letterbox (overlap overscan). You have to use exactly what is given by Moviestacker according to how you set it. FitCD manages only Addborders method.

Thanks for the added info Phil. :D

Which is a big pain in the a**.
That's one of the big reasons why I always liked MS better than FitCD.
I hope Andrej can go for a similar project as FitCD.
And since I know Andrej love's using overlaped resizing on his anamorphic KDVD encodes...
That means that he would add that feature to his project for sure.
I guess we'll have to wait and see where it all goes down to.
Cheers

8O
Letterbox just masks existing pixels so you loose them for ever ! Addborders is a lot better as you do not loose anything, but resize the frame to a lower res then add a border arround it. I really don't find letterbox better than addborders.

Well it depends actually I do prefer an overlapping Overscan.
Cause I want to maintain the size of the visible borders in case of 1.78 or 2.35:1 movies on my 16:9 Tv.

Does that mean that you don't mind to lose pixels on right/left side ?
(pixels that you don't see on the original DVD BTW, but as we are doing a resize, why not having all the pixels on the screen ?).

Right Phil, I see your taste as you want to "compensate" the TV's overscan for watching all the movietreatment of the original DVD Moviedata.

In case of 4:3 Sources I totally agree (btw. Im just talking about my taste not a suggestion or recommendation ;) ) But as said I like for my taste the compromise that I gonna loose Pixels on the side, but on the other hand I dont have larger top/bottom-borders when watching 1.78:1 or 2.35:1 stuff on my 16:9 tv. So the 16px Overlayed Overscan in this case is just a compression advantage for me.

I understood. Some times ago I prefered to use letterbox that to introduce artifacts in the source by resizing it. And I changed my mind finally. Nothing is for ever :)

Note: on a Philipps plasma screen I saw recently a "zoomed 16:9" mode that stretches vertically a 2.35 into a 2.21 (and probably a 2.21 into a 1.85). This is perfect for people that don't like when bars are too big :)
(the distortion in A/R, even if noticiable, is not too strong).

These zooming modes on displaydevices are nice.

I got 2 options: One on my DVD player where the Image can be zoomed continuously by keeping the PAR. And the Other is the Panasonic 16:9 itself. But there the zooms are fixed, means I can see 4:3 as 14:9 (top/bottom are a little cropped) and zooming for example a 2.35:1 to 1.788:1 (16:9 Full screen pan-scan).
What I dont like is the autoZoom mode on the Panasonic 16:9 in 4:3 input. There the TV keeps the middle as unstretched as possible and stretches only the sides. So a tall Man in the Middle becomes a fat boy if he moves to a side :lol:

Well this is it how it "should" look. But dont expect me to release it the next days as I gotta lot of work.

http://www.digitalfaq.com/archives/error.gif
Thanks to ImageShack for Free Image Hosting

;)

Andrej,

....shhhh...

looks GrEaT :wink:

I'll be sitting in front of PC monitor, waiting for the release... :D

:bigooh: :jawdrop: :jawdrop: :jawdrop: :jawdrop: :jawdrop: :jawdrop: :D
Supercalifragilisticexpialidotious :lol:
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 :D

@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.

http://www.digitalfaq.com/archives/i.../2005/08/3.gif

(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. :)

Read what I just saw on Doom9 news :
:x

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.

@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. ;) :D

Thanks in advance buddy. :)

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 :lol: ).

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. :D