@len0x: Please provide CLI support for AutoGK

[Darksoul71]

Hi len0x,

I´ve seen your comments in the long V1.70 thread. Although I definitely share your concerns about AutoGK being integrated into blatant ripping packages and being sold for money, I think it´s very narrow minded to not support CLI for this reason.

As already stated in the V1.7 thread it has been proven by several authors that a lot of "non-cli" appliations can be easily "wrapped" (e.g. AutoFitCD, MDVDAuth, DS Roba). I´ve done several CLI wrappers myself using AutoIt. Also I´ve seen a CLI wrapper fo rAutoGK at Snapstreams BB (http://forums.snapstream.com/vb/showthread.php?t=17894).

Using AutoIt anyone can easily "wrap" any GUI applications in a couple of minutes. You can extract informations from Text components and parse them quite easily. So will a "Non CLI" based version of AutoGK actually keep those m0r0n$ from integrating AutoGK into a "Ripping package" ? Defenitly not......

Think about the cool things you can do with a CLI enabled AutoGK. You could post-compress your MPEG2 recordings on a HTPC over night while not even touching the keyboard.

IMHO open interfaces are a must-have for any "freeware" application. Where would we be without AVISynth, DVD2AVI CLI, VOBSub with CLI, XML-based DVD authoring solutions, etc. ?

I can tell you: There would be no DVD2SVCD. There might be no GKnot. At least all those applications would not have such rich features.

Just my 2 cents,
-D$

[len0x]

First, its very interesing link you provided :)

Second, I did not think that without CLI its impossible to make AutoGK work for other tools/scripts. BUT I think its quite enough to protect it against massive use in those tools. Moreover I don't think its feasible to produce a commercially successful product based on wrapping up GUI clicks (unless you can actually refer me to such product).

Whoever wants to use such tools as AutoIt - still can. And if you say that its that easy to setup, then you should be able to solve all your needs locally without my efforts involved.

P.S. I never considered AutoGK as not standalone solution - that is the difference to all the tools that it uses. GK doesn't have a CLI either - because it is standalone solution as well (DVD2SVCD's CLI is somewhat limited I heard as it wasn't probably designed for CLI operations either).

[Darksoul71]

Hi len0x,

First, its very interesing link you provided
Oops, said the rabbit to the snake :D

Moreover I don't think its feasible to produce a commercially successful product based on wrapping up GUI clicks (unless you can actually refer me to such product).
Currently I don´t have the time to evaluate if it´s possible to "hide" AutoGK but I know at least one company that uses Vidomi to post-process their HTPC recordings in the background of their GUI. Vidomi is somewhat "integrated" in their Flash GUI ( Sonavis Homepage (http://www.sonavis.de/)). Of course they won´t mention the software they run in the background.

May be AutoGK is not "hideable" but other GUI apps are. I think you get my point.

I also think that you´ve provided a valuable counter-argument why AutoGK actually could provide CLI support:
It´s not really feasible to build "your own DVD ripping" app when a GUI (e.g. the AutoGK GUI) pops up. Be it script driven or CLI driven.

For an external application CLI support makes not big difference:
example:

External app -> AutoGK via CLI
External app -> wrapping script -> Standard AutoGK

Just imagine you are a mediocre developer (I suspect all those dumba$$ developers to be mediocre) who wants to develop his "own" ripping pack and sell it.

Which route would you choose ?
1) Ripping of the source code of available tools such as DVX or GKnot and integrate them in your "own tool" ?

2) Using all those CLI driven small application such as DGIndex, Besweet, etc and wrap them under a fast "developed" GUI in Delphi / VB ?

3) Using a tool with well-known GUI design such as AutoGK and "incorperate" it into your ripping pack ?

Just think about it for a minute.....

I think 2) will be mostly the answer.

So closed source will definitely keep away some of those stupids but "non CLI" as mode of control is a bit "strange" to me.

Whoever wants to use such tools as AutoIt - still can. And if you say that its that easy to setup, then you should be able to solve all your needs locally without my efforts involved.
Yeah, of course. Using programs is mostly about klicking with the mouse, pushing some keys, etc.

AutoIt emulates this (such as 10 gazillions of other scripting tools out there). So a free afternoon and some trial and error is mostly all it take to "CLI wrap" a standard GUI application. My point is just: A CLI makes it easier for "Non-Coders" to actually use batch-processing (and of course makes it easier for ripp-package-developers :p ).

MDVDAuth and DS2Roba are also written in AutoIt.

P.S. I never considered AutoGK as not standalone solution - that is the difference to all the tools that it uses. GK doesn't have a CLI either - because it is standalone solution as well (DVD2SVCD's CLI is somewhat limited I heard as it wasn't probably designed for CLI operations either).
Jupp, but neither GK, nor DVD2SVCD would actually be able to do all the stuff they currently can do without all those other CLI apps. DVD Author is not ment as CLI app itself but DVD2SVCD uses it nevertheless producing a XML config file in order to master DVDs.
VirtualDub itself is one (if not THE) mightiest freeware standalone applications but supports CLI. etc etc.

cu,
-D$