lets get a new version of AutoGK out

[len0x]

First, let me say I'm still around and finally got to a point when I have a new dev environment set up and compiled current version of AutGK with it. Having not read last year+ of posts it would be good if you guys could brief me if there are any known/outstanding problems with the latest 2.48 version.

I've already updated DGIndex and filters to the latest versions and wanted to see if a new XviD version was out, so I checked out Celtic Druid's version from this spring and couldn't get it to work on my Vista64 box (can't even launch encoder configuration window) while last 12/06 version is working just fine.

I'm not actively resuming development though, but will have some time to work on it this winter.

[budwzr]

Whoo-Hoo!!!!!

[Barough]

Thats great news :)

[buzzqw]

welcome back len0x!

you will surely do a good work!

even if xvid is a little outdated...

BHH

[Sargon]

Lenox it is a pleasure to read your back . Agk will be improve definitly. There must be a lot of corrections. Since I use Agk, I always enjoy this program, easy to use, simple but so much powerful. There are no others that come close to AGK. My standalone runs always great, and the sound is beautiful and never too loud.... Again, I say thank you Lenox for what you already done in the past and for what's coming next.

[Codex0nz]

i remember using this app back before i went to megui and started annoying this forum with n00b questions :P

AutoGK is a wonderful application and i am very happy to see that the development of it is being revisited, this will surely help a lot of new people ease into the encoding scene and not kick & scream at it :D

[Taurus]

Boy, it's great to see you back on the tracks!
It was getting a little humdrum without you.
So here are the first todos:
A "new" XviD 1.2 stable just arrived.
And a so called 1.3 branch is open.
Many noobs got confused by video aspect ratios and therefore complaining.
Automatic detection is somewhat buggy.
I think older versions did a better job on this.
And you know, I'm into this since Prehistoric AutoGk..
(GordianKnotItFast4U)
Cheers

Taurus

[len0x]

And you know, I'm into this since Prehistoric AutoGk..
(GordianKnotItFast4U)


Ah, good old times :)

Anyway, I'm aware about XviD 1.2. Unfortuntely Celtic_Druid seems no longer around and I do need an MTK build of it...

And what about AR detection being buggy? Can I have some relevant threads about this? Cheers.

[CWR03]

How much trouble would it be to add support for episodic disks? I realize that different PGC's are selectable, but the output will always contain all eps in one file.

[linyx]

I know that this is not a feature request thread, but it might be a good idea to incorporate DivX 7 and its standalone profile(s) when it is released (soon, hopefully).

[len0x]

How much trouble would it be to add support for episodic disks? I realize that different PGC's are selectable, but the output will always contain all eps in one file.

That's because DGindex will load the whole vob set. We would need an option to do the cutting via CLI in it (assuming I can get the cut points from an IFO file, although I'm not really that familiar with DVD structure) which we do not have at the moment.

*EDIT* Actually we can select frame range in avisynth script, so in theory its possible even without DGIndex... I'm not clear how to find that frame range from IFO though yet...

[len0x]

I know that this is not a feature request thread, but it might be a good idea to incorporate DivX 7 and its standalone profile(s) when it is released (soon, hopefully).

I've been out of the loop with DivX7 - does that still have VfW interface?

[den78]

glad to see you back len0x :)
thanks for keeping agk alive m8.

[linyx]

I've been out of the loop with DivX7 - does that still have VfW interface?
Well, it supports avisynth, which is VfW, correct?

[Mtz]

Welcome back!
I that "old times" I asked you if you can implement "Keep interlaced". Your response was somethink like: "This is a useful feature". Now?
Regarding AR, try to make some test with a DV which was shoot in 16:9 mode. For pal is 720x576 but with 16:9 AR.
Mod 16 will be forever? At least mod 8 to have.

enjoy,
Mtz

[weaver4]

I made a comment a few months ago that I would like to be able to configure the location of the agk_tmp directory.

My reason for this is that I want the output of my encode to be on my media-server next to my TV, but I run autogk on my mainpc. So having the agk_tmp directory on my media-server over the network really slows down the encoding time and ties up my network.

[PoloZ7]

Great news, how long I have waited !

[len0x]

Well, it supports avisynth, which is VfW, correct?

Please don't me laugh :) (no pun intended)

[len0x]

I made a comment a few months ago that I would like to be able to configure the location of the agk_tmp directory.

Valid request. I'll be honest though - now that I look at the hidden options (where this option would go) it doesn't make sense to keep the kind of implemenation it is at the moment (via dot files), but rather make a proper registry entries. And this would not be the first thing I would like to do...

[len0x]

Welcome back!
I that "old times" I asked you if you can implement "Keep interlaced". Your response was somethink like: "This is a useful feature". Now?


I can only assume that should have been "This is not a useful feature", right? :) I still don't see this as a mass usage option (especially if not all the codecs support it, but I'm rusty in this department do x264/divx7 support interlaced encoding?).


Regarding AR, try to make some test with a DV which was shoot in 16:9 mode. For pal is 720x576 but with 16:9 AR.
Mod 16 will be forever? At least mod 8 to have.


This isn't AR problem, this sound more like "too much cropping" kind of problem...

[Brother John]

I've been out of the loop with DivX7 - does that still have VfW interface?
DivX 7 isn’t finished, so it’s too early to say anything final. Only betas (decoder (http://forum.doom9.org/showthread.php?t=141086), encoder (http://forum.doom9.org/showthread.php?t=137786)) are out. From what DivX Inc. has revealed so far they are going for H.264/MKV and abandoning VfW, which makes perfect sense for that codec/container choice. However nothing has been said if the DivX 7 package might include the traditional DivX ASP VfW encoder (possibly in an updated version?).

[linyx]

Please don't me laugh :) (no pun intended)

I don't know much about VfW, but AFAIK, AviSynth "outputs" its video format to VfW. Taken from wikipedia:
It stands as an intermediary between a digital video source, like an AVI or MPEG, and a VFW receiving program
That's just what i understand of it. Sorry for sounding stupid.

[len0x]

VfW is a codec interface that is being used by VirtualDubMod (and hence AutoGK) to communicate with encoding engine... Avisynth is just a video scripting environment that does processing before video even comes to VDubMod. So ability of a codec to support VfW interface means easier integration into AutoGK (and for example for x264 CLI version I would have to completelety rewrite the way AutoGK encodes video because its not VfW way of doing things).

[MasterNobody]

May be you can think about adding x264vfw (http://sourceforge.net/projects/x264vfw/) support to AutoGK (but you must be prepared that a lot of Doom9 members would start to blame you talking that MPEG-4 AVC unsuitable for AVI even though MPEG-4 ASP have the same limitations and this doesn't stop it using with AVI).

[linyx]

VfW is a codec interface that is being used by VirtualDubMod (and hence AutoGK) to communicate with encoding engine... Avisynth is just a video scripting environment that does processing before video even comes to VDubMod. So ability of a codec to support VfW interface means easier integration into AutoGK (and for example for x264 CLI version I would have to completelety rewrite the way AutoGK encodes video because its not VfW way of doing things).
Good explanation, thank you.:goodpost:

[den78]

May be you can think about adding x264vfw (http://sourceforge.net/projects/x264vfw/) support to AutoGK (but you must be prepared that a lot of Doom9 members would start to blame you talking that MPEG-4 AVC unsuitable for AVI even though MPEG-4 ASP have the same limitations and this doesn't stop it using with AVI).

vfw x264 sounds good to me ...& integrating mkv container in agk shouldn't be a problem, right?

[AMED]

I was wondering if it was at all possible to intergrate MeGUI or AutoMKV's auto deinterlacing into AutoGK?

[buzzqw]

autogk deinterlacing's routines is good
it was the base of megui and automkv works on auto detecting routines (thanks to IanB)

the only suggestion i can give is to update the deinterlacing filters

BHH

[len0x]

Deinterlacing filter AutoGk is using - LeakKernelDeint. Is there a new version out ?

[AMED]

I'm not sure that LeakKernelDeint is the best for all deinterlacing scenarios.

AutoGK and MeGUI analyze the video and based off the results choose the best deinterlacer.

e.g.
Yadif
TDeint
TDeint+EDI
Tomsmocomp
Fielddeinterlace
Fielddeinterlace (no blend)

Buzzqw has implemented it into Automkv so hopefully he can tell you more how it works.

[yetanotherid]

I made a comment a few months ago that I would like to be able to configure the location of the agk_tmp directory.

My reason for this is that I want the output of my encode to be on my media-server next to my TV, but I run autogk on my mainpc. So having the agk_tmp directory on my media-server over the network really slows down the encoding time and ties up my network.

I guess it can't hurt to have it configurable, but I like it defaulting to the output location for the reason you don't. I usually put the source file on one RAID volume and the output file on another. That way they seem to share the work and I can keep using the PC without hard drive activity seeming to slow it down much.

One thing AutoGK really could use is the ability to pause it and the ability to save jobs between sessions would be nice.
Being able to run the compressibility test and have AutoGK then tell you what resolution and quality you'll get for a chosen file size would be great. I find myself guessing as to the file size then having to run the compressibility test several times until I get it right.
It'd be handy to have the ability to re-use an already demuxed or encoded audio file or a previous compressibility test when re-encoding rather than have to start the process from scratch, and along those lines....
AutoGK clears it's temp folder before each job (if the output files are in the same directory). A separate temp folder for each job would mean that if you encode a batch of videos, then decide you want to re-encode a couple of them, you'd already have the demuxed, converted audio track to add manually later rather than AutoGK needing to convert it again.

Oh and given the proliferation of h.264 video in one container or another, if AutoGK could handle the appropriate file/video/audio formats to enable it to re-encode them to XviD.... I find myself more and more downloading an MP4 or sorts, but wanting video which will play on my standalone player I have to go through a convoluted process to convert it. Preferring to use AutoGK for the job, I'm often having to use another program to convert the MP4 to an AVI containing uncompressed video and audio, then using AutoGK to convert that to XviD. :-(

[Haubi]

Good news, len0x is back! :D

Here a few suggestions from the old topic "Auto Gordian Knot: current version 2.48 beta":

infiniter wrote:

- when opening an IFO with multiple PGCs and selecting one of them, the demuxer and the audio encoder process the whole VOB, not only the selected PGC. This consumes unnecessary time, because both tools are not able to transcode a multi-PGC VOB into single files. For every PGC and file, the complete VOB audio will be encoded, which stretches the audio encoding time to 6x if there are 6 PGCs.

- Audio encoding is done BEFORE video encoding (which seems illogical), though the picture is the most important item. Audio encoding mostly runs smooth without problems, while video encoding often results in bad quality (to blurry) or wrong resolution (if "Auto" is used). It would be better to encode a test sample of video from the source and show it to the user (as an option). Then the user can decide to take the settings and continue, to change them (and restart test encoding) or to discard. I know, this is intended to be automated because its "Auto"-GK, not the normal GK. But the normal GK is too complicated for occasional users.

- the preview mode has no relevance to the resulting picture quality and is thus useless

- VD still does not take advantage from multi-core processors

- no test encoding with preview

- if a transcoding session is aborted by any reason (error or by user) and the settings were not changed before it is started again, the whole demuxing/encoding thingy starts from the very beginning, instead of re-using the present files. This can be very annoying and extremely time consuming

- audio encoding is slooooooow! Only up to 8x on a Pentium D with 2.8GHz. Compared to old audio ripping tools like EAC, which would rip and encode a whole CD to MP3 in some minutes which results in 20x or higher, LAME or the other libs are medievally lame. (Uhm, err, I guess that's where LAME's got its name...)

- multi-core processors could easily encode audio and video at the same time - this is not used

[len0x]

vfw x264 sounds good to me ...

Is that actively developed alongside regular x264? I also have a general problem with x264 that (unlike XviD/DivX for example) it doesn't have a concept of a release. So lots of time could be spent just making sure bundled version is more stable than all the revisions that are getting out. After all, I take bugs in the tools I'm using personally :)

[len0x]

AutoGK and MeGUI analyze the video and based off the results choose the best deinterlacer.
e.g.
Yadif
TDeint
TDeint+EDI
Tomsmocomp
Fielddeinterlace
Fielddeinterlace (no blend)


There is one big difference from AutoGK to all those tools - you can always override automatic way of things with lots of manual options in them. So unless it can be proven that automatic deinterlacing is acceptable in 99% cases (and I haven't heard anyone complaning about deinterlacing in AutoGK in a while) I just don't see a reason for doing so (and frankly I prefer others copying me rather me copying them :) )

[buzzqw]

I haven't anything to teach to Len0x! always kudos the Master!

this was a little old (i no more use bautodeint, but my own routine based on bautodeint) but you can check this
http://forum.doom9.org/showthread.php?p=937978#post937978

BHH

[Barough]

It would be gr8 if u would add support for the official Xvid 1.2.1 using Koepi's builds.

[len0x]

I have built it (with 1.2.1) but ESS option isn't working there, so I don't know what to do with that yet...

[den78]

Is that actively developed alongside regular x264? I also have a general problem with x264 that (unlike XviD/DivX for example) it doesn't have a concept of a release. So lots of time could be spent just making sure bundled version is more stable than all the revisions that are getting out. After all, I take bugs in the tools I'm using personally :)
don't know 'bout active development m8, maybe it's because i don't use it that much, but it sounds good, cause no matter if it's vfw or cli, what matters is that it's x264 & hopefully it would be a part of next agk :)

I have built it (with 1.2.1) but ESS option isn't working there, so I don't know what to do with that yet...
1.3.0 cvs works ok with ess (xp sp2) ...i mean the final size is correct :)

[Carraway]

Welcome back, len0x. I'd like to throw my hat in the ring for x264/MP4 support. It's the next standard. Adding additional features to Xvid/AVI is fine, but realistically AutoGK has been rock solid for years and not a lot of developments have been made in that arena.

H.264 inside MP4 on the other hand is now the standard in every iPod, in Flash video, Quicktime, etc. It might be worth rewriting the encoding engine to support CLI. If an AutoGK-like program existed for X264 it would be a killer app; right now all we have is MeGUI, Stax and AutoMKV, all of which are more complicated and less stable than AutoGK in its current state (not to mention the first two are mired in .NET hell).

Thanks again for all your great work with AutoGK, it's saved me probably days or weeks of encoding work over the past several years.

[Sharktooth]

@lenox: just FYI, jawor made some xvid 1.2.1 builds with MTK and DivX profiles. check this: http://jawormat.republika.pl/xvid.html
oh... and welcome back :)

[len0x]

I was using Jawor's builds already and they do have problems with ESS option. I finally managed to build XviD from head myself though and my first test gave me spot on size with 2.48 which is promising, but I need to do more testing.

[Sharktooth]

right now all we have is MeGUI, Stax and AutoMKV, all of which are more complicated and less stable than AutoGK in its current state (not to mention the first two are mired in .NET hell).
+ ripbot264, autoff, bencos, avidemux... etc.
also, what's the problem with .NET? if you have problems with .NET then your system is misconfigured... and i guess you never tried the OneClick Encoder in megui...
btw, this is about autogk and i agree, x264 support would be great.

[Carraway]

+ ripbot264, autoff, bencos, avidemux... etc.
also, what's the problem with .NET? if you have problems with .NET then your system is misconfigured... and i guess you never tried the OneClick Encoder in megui...

This was a worthless derail. My system configuration is fine, and I've used the One Click Encoder about six-hundred thousand times, so I think I'm pretty well-versed in what I'm talking about. None of the programs you listed are anywhere near as simple, stable and intuitive as AutoGK is. If they were, I wouldn't bother asking len0x for x264 support.

[len0x]

I'm glad AutoGK still serves its purpose as simple and robust tool (in fact I don't consider it a tool, but rather a product) after all these years :)

My first priority atm is to get next stable version out with all the updated tools and only after that I can start doing something new like x264 (MKV support would probably have to be added first though). I was struggling with latest XviD for a while, but it looks like my own build is working correctly but I still have to test different platforms.

[len0x]

OK, so I got 2.50 alpha out. It contains 1.3.0 build of XviD and lots of updated tools.

[TheTooleMan]

Just downloaded 2.50 alpha and looking forward to trying it out.

I've been trying lots of conversion software and tools and find AutoGK gives great results more consistently than any other software I've used.

The one thing I would like to add to AutoGK is being able to turn on greyscale encoding for DivX and Xvid output. When encoding captures from DVD's made from B&W VHS tapes, quite often the output is green or bluish or has colored areas. True greyscale is much nicer to view. There's a greyscale checkbox in the hidden advanced options, but it only applies to Xvid and only to credits (or did I miss something).

Oh yeah, while you're at it, it would be nice to be able to mux an audio file while rendering DivX or Xvid in AutoGK.

Thanks for all your work! Glad to see this product hasn't been abandoned. ;-)

[buzzqw]

and now waiting for x264.exe , mp4, and mkv support!!!

(you can mutuate some profiles from megui/ripbot/automkv)

BHH

[len0x]

well, its not a stable version :) (well unless everything magically works)

I was hoping to build x64 binaries of XviD to bundle with the installer, but can't seem to use them yet (weird range check errors, which mean its not installed properly, I'm guessing x64 dll registartion is different from 32 bit...). Also I will need to check out that VAQ patch...

[Barough]

@ len0x

Is there a special reason why you don't use the latest stable release of Xvid instead of the v1.3.0 CVS?

[Sharktooth]

@lenox: VAQ for Xvid is good, not as good as in x264 though (due to the MPEG4 ASP quantizers distribution).
However avoid using it on hardsubbed sources or toons (actual/detailed anime are ok) since it will produce visible ringing around very hard edges.

[len0x]

@ len0x

Is there a special reason why you don't use the latest stable release of Xvid instead of the v1.3.0 CVS?

No, but at this point I don't think there is any difference, is there?

[len0x]

However avoid using it on hardsubbed sources or toons (actual/detailed anime are ok) since it will produce visible ringing around very hard edges.

So what would be the suggestion if it has to be always on or off then? In other words will the benefit of having it always on overshadow the cases when it should not be used?

[Sharktooth]

Since autogk supports soft subs i would add a "Source is cartoon" checkbox or "Cartoon mode" or something and set AQ accordingly.

[Barough]

Double post

[Barough]

No, but at this point I don't think there is any difference, is there?

Another software im Beta testing for don't like Xvid that ships with AutoGK, so i have to reinstall v1.2.1 when im gonna work with that one.

[len0x]

Another software im Beta testing for don't like Xvid that ships with AutoGK, so i have to reinstall v1.2.1 when im gonna work with that one.

Then ESS/MTK options may not work properly. If you don't use them then it pretty much doesn't make any difference (so far).

[ankurs]

^

i might be offtopic but autogk seems to have problems with wrongly flagged dvd's .

What i mean to say is for example a 16:9 source which is flagged as a 4:3 wrongly and autogk in return after reading the flag crops and then resizes to a FS resolution instead of a WS one and vice versa for the whole scenario and the other way around ...

this specifically does happen on old shit quality processed retail dvd's here in asia ( and on old dvds/movies/titles ) which have been barfed up from bloody FS to WS just by changing flags and adding borders taking the aspect ratio immensly off when the dvd is played on dvd players ,selecting 16:9 , 2.35:1 , 4:3 , 1.33:1 on your remote control's doesnt help much then ( the picture either gets vertically squished or horizontally stretched 95 % off the times ) .

How i know this ? cuz i started off on autogk back in start of 2006 and now ended up on commandline encoding / megui / cce etc ..

so yeah well , any way this could be solved ?

do let me know if u need a sample !

[manono]

AutoGK gets the DAR from DGIndex which gets it from the VOBs. But a DVD player usually gets it from the IFOs. So, the DVD can play properly in the standalone but you can wind up with an AutoGK produced AVI in the wrong aspect ratio. It's not AutoGKs fault; it's not DGIndex's fault. It's your responsibility (maybe after seeing the result) to go into the Hidden Options and change the DAR and do it over again. It doesn't happen all that often, but it does happen.

[Chumbo]

I don't remember if you package avisynth with AutoGK, but in case you didn't know, 2.5.8 is released.

+1 for x264 support. :)

[ankurs]

AutoGK gets the DAR from DGIndex which gets it from the VOBs. But a DVD player usually gets it from the IFOs. So, the DVD can play properly in the standalone but you can wind up with an AutoGK produced AVI in the wrong aspect ratio. It's not AutoGKs fault; it's not DGIndex's fault. It's your responsibility (maybe after seeing the result) to go into the Hidden Options and change the DAR and do it over again. It doesn't happen all that often, but it does happen.

totally agree to ur post , i dont use autogk now , used too when i started off back in the day , n00bs still might face the problems i mentioned and seemingly it can be solved from the hidden options so oh well cheers for that ! :D

btw big up to len0x for his work !

[len0x]

Since autogk supports soft subs i would add a "Source is cartoon" checkbox or "Cartoon mode" or something and set AQ accordingly.

I really don't want to add options at this stage though. However since AutoGK knows about hard subs it can switch AQ off for those ones automatically, but are cartoons with AQ on really bad? Any examples sources of that I can try myself?

P.S. Where can I find the definitive latest VAQ patch for XviD?

[len0x]

I don't remember if you package avisynth with AutoGK, but in case you didn't know, 2.5.8 is released.


Good to know, I wonder if they do x64 version of it...

[len0x]

Another software im Beta testing for don't like Xvid that ships with AutoGK, so i have to reinstall v1.2.1 when im gonna work with that one.

Btw, Is this pure DLL versioning thing or some other problems (like my build/installer of XviD)?

[Chetwood]

even if xvid is a little outdated...
Says who? It's the same with mp3 and ogg: I can easily "waste" a few more bytes to reach the same quality of current codecs and every darn device out there does playback mp3. Almost any standalone of the past years does xvid and most likely any future device will. I've tested my AutoGK rips on a 50" Plasma and there were no artifacts.

Having not read last year+ of posts it would be good if you guys could brief me if there are any known/outstanding problems with the latest 2.48 version.

Episodic discs being ripped as one large file
This has already been mentioned but it's also my main issue with AutoGK. Since opening such DVDs in DVD Decrypter shows all eps in the first PGC but also each ep with it's own PGC it might be possible to retrieve info on start/end points of each ep from the IFO after all?!


Messed up subtitle order
To workaround above mentioned problem I'm re-authoring episodic discs with DVD Shrink first, stripping all but english/german subs. So en-it-de becomes en-de and shows up as such when opened in AutoGK but after encoding only the first sub is there. Manually ripping the re-authored DVD's subs with Vsrip reveals that en is the first sub stream but de is still 3rd stream in the IFO whereas stream 2 is blank which AutoGK does not seem to realize. Also toggling "logical remapping of enabled streams" in DVD Shrink doesn't make a difference.


Switching subtitle order for external subs doesn't work
Some DVDs I rip come with en-de audio and sub streams so I switch them to de-en. This works for audio but not for external subtitles which always keep the original order.


Output file input box doesn't allow pasting
After having re-authored my episodic disc I open the first of the four eps in AutoGK and select the output file as d:\done\my.show.ep1x01. Now I can copy this line from the output file input box but I cannot paste it back there as d:\done\my.show.ep1x02 after having opened the second ep. I have to click the browse icon first and only then can paste the line. Minor thing but unnecessary, IMHO.


As everyone here I could come up with tons of suggestions on how to improve your great prog but I'll restrict myself to this: please add an option to start a program when a job and/or queue is finished. This way I could call a batch file that would do a netsend from my encoding machine in the basement or even use my telephone system to text my cell phone.

One more thing: I've read on some German forum that AutoGK's standalone profiles might be out of date when it comes to MTK chipsets used in current standalones. Any info on this? Thanks!

[len0x]

- Episodic discs being ripped as one large file

It might be possible to do that on avisynth level as I said before, but this would have severe implications on external subs...

- Messed up subtitle order

I would have to see an example of such re-authored IFO file before I can comment on this. It might be just a simple bug to solve.

- Switching subtitle order for external subs doesn't work

I have to look this up, but afaik its a limitation of vobsub which ignores the order of subs supplied to it.

- Output file input box doesn't allow pasting

This one won't be changed as parsing of the input file happens on selection and that can't happen on key press event, so another button to load the info would need to be introduced, which I'm against of.

Also I'll keep in mind batch option, but have no idea about standalone profiles as they are part of XviD and not AutoGK per say...

[Sharktooth]

I really don't want to add options at this stage though. However since AutoGK knows about hard subs it can switch AQ off for those ones automatically, but are cartoons with AQ on really bad? Any examples sources of that I can try myself?

P.S. Where can I find the definitive latest VAQ patch for XviD?
try encoding one of the simpsons episodes with VAQ. you'll notice ringing around hard edges.
for the VAQ patch, ask Dark_Shikari.

just a suggestion: i would consider changing the autogk encoding chain to something more flexible.
for example, replacing vdub with cli encoders (faac, lame, xvid_encraw, x264...) so you can eventually add avs2yuv on top of video encoders and use 32/64 bit versions accordingly to the host OS. also xvid and x264 cli encoders have VBV parameters... so you can eventually create as much standalones or devices profiles as you want...
that will require cli muxers too (mkvmerge for divx 7 compatibility, avimuxgui in cli mode for classic avi output and eventually mp4box for IPod and other devices...).
well, all depends on how much time you want to spend on autogk though... but those changes will take autogk to a new level... :)

[Chetwood]

- Episodic discs being ripped as one large file
It might be possible to do that on avisynth level as I said before, but this would have severe implications on external subs...
Such as? I'm not sure I'm getting what you say here. One could set the target size large enough to hold all 4 eps of a DVD with good quality and encode the main pgc with AutoGK and split the resulting avi into 4 parts. Splitting external subs manually to match the eps would of course be a PITA. Therefore one has to rip single eps first before feeding them to AutoGK.

Unless of course AutoGK would learn how to recognize single eps. I really do hope some expert with knowledge of ifos can chime in on this. Like I said before, the ifo does not only list the main pgc with all eps (basically pgc 1 is one huge mpeg with all eps in it) but also each ep's pgc (3-6 in screenshot below):

http://www.dvdshrink.info/chetwood/img/dvdd.episodic.png

Somehow it should be possible to calculate start/end point from this including subs. DVD Decrypter can derive this info from the ifos. Ripping single eps with DVDD in IFO mode allows to open those eps in AutoGK (but unfortunately not in Shrink or PowerDVD since DVDD does not generate the video_ts.ifo!) and get external subs just fine. I usually use this method as a workaround unless of course I'm dealing with any of the tough new copy protections (http://forum.doom9.org/showthread.php?p=1232897#post1232897).

[len0x]

The example above is a good one to demonstrate how difficult it could be. I can only derive where a PGC starts based on the timing above to calculate (approximate) start frame to pass to avisynth. So for PGC 3 - what would be the offset? 00:00 or 00:13? Also PGC 1 doesn't seem to be sum of any others exactly... So just based on the rough timings we are bound to have synch problems with subs if they are cut exactly by PGCs (as vobsub does). The more I think about this the more I don't like the idea (unless I disable subs processing in such mode completely for external subs, better than nothing I guess).

[Barough]

Btw, Is this pure DLL versioning thing or some other problems (like my build/installer of XviD)?

Sorry 4 the late reply......

When 'your' Xvid is installed so does not the encode not start @ all for me. No 'error' messages, nothing......

Will do some more tests when things have calm down a bit for me.

[TheResidentEvil]

great tool len0x.

[nevragain]

I have a small request having the program choose between auto and one of several types, would it be possible to "deselect" one and have the program choose between the remaing options.

[len0x]

The above post is definitely missing some keywords as I can't make head or tail of it...

[len0x]

When 'your' Xvid is installed so does not the encode not start @ all for me. No 'error' messages, nothing......


AutoGK or the other encoder?

[len0x]

Switching subtitle order for external subs doesn't work
Some DVDs I rip come with en-de audio and sub streams so I switch them to de-en. This works for audio but not for external subtitles which always keep the original order.


So I checked this and indeed VobSub doesn't do any re-mapping of subs - they all have exactly the same index position as in vobs (I guess that makes sense since it just extracts them from the source and not re-author). In AutoGK order matters only because the first one will be the default one to be displayed (just an entry in IDX file).

[len0x]

try encoding one of the simpsons episodes with VAQ. you'll notice ringing around hard edges.


Just tried that on the 11th season. Its not really noticable during playback, however when comparing frame-to-frame I can see that. So I'm guessing it should be an option to switch it off... oh wait I actually have "enable cartoon mode for XviD" option which can disable VAQ as well :) So, I think I'll go for that then...

[Sharktooth]

good :)

[yetanotherid]

I have a small request having the program choose between auto and one of several types, would it be possible to "deselect" one and have the program choose between the remaing options.

I think he's trying to ask if when selecting auto mode, auto could be any of the usual AutoGK options.... except for.... one particular option you'd like to tell it not to pick.

[Chetwood]

The example above is a good one to demonstrate how difficult it could be. I can only derive where a PGC starts based on the timing above to calculate (approximate) start frame to pass to avisynth. So for PGC 3 - what would be the offset? 00:00 or 00:13? Also PGC 1 doesn't seem to be sum of any others exactly...
Weird, PGC 1 is one second too long to be the sum of the 4 eps. Of course I don't know how accurate DVDD is here or what more/specific info could be derived from the ifos that DVDD just isn't depicting. Somehow it must be possible since DVDD's stream processing in ifo mode as well as DVD Shrink's re-author mode can split the eps accurately (Shrink except for the subs that is). Since dvdshrink himself has gone awol again (http://forum.doom9.org/showthread.php?t=137425), I hope we can find someone else here on this forum to provide the necessary information, gonna pm LUK! about that.

The more I think about this the more I don't like the idea (unless I disable subs processing in such mode completely for external subs, better than nothing I guess).
In that case it's actually better to leave it as it is. Some DVDs I rip do have en-de as the first two streams so the problem with wrong subtitle order does not occur. On other DVDs I can workaround this problem by ripping single eps with stream processing enabled with DVDD. As said before the problem with this method is that these rips can't be opened in Shrink (to trim first blank seconds left by the copy protection that would cause sync problem if left in) since DVDD does not generate an empty video_ts.ifo Shrink is expecting.

[len0x]

Weird, PGC 1 is one second too long to be the sum of the 4 eps. Of course I don't know how accurate DVDD is here or what more/specific info could be derived from the ifos that DVDD just isn't depicting. Somehow it must be possible since DVDD's stream processing in ifo mode as well as DVD Shrink's re-author mode can split the eps accurately (Shrink except for the subs that is).


Internally this is done via bytes/blocks offset that is stored in ifo obviously, however without writing re-authoring tool like dvdshrink you can only operate on the timings and knowing that you have to start cutting VOBs at X bytes won't help processing this in avisynth...

[Buggle]

As for the episode DVDs, I always like to encode all eps in order to know how the complexity is distributed. In that way you can encode at same quality instead of same bitrate. Usually I choose for instance DVD size for a certain amount of eps. In that way you have optimized quality for all episodes.

So I would personally prefer to actually encode it as one file, only making sure that during encoding the necessary keyframes are inserted, so at the end the program can then use the information to cut the resulting file into episodes.

You could even add a filenaming mask, so that everything is named in a specified way.

[Chetwood]

In that way you can encode at same quality instead of same bitrate.
So the eps do not differ? I'm simply setting the same target size for all eps.

so at the end the program can then use the information to cut the resulting file into episodes
Which won't work on external subtitles.

[Buggle]

So the eps do not differ? I'm simply setting the same target size for all eps.

Sure, they might differ in size and bitrate, because one might be more complex than others.


Which won't work on external subtitles.

Sure it will, you can rip the subs separately, ep by ep. If the process of cutting the eps has been done correctly, they will still be in synch.

Or am I not understanding what you mean by external eps?

[Chetwood]

It appears you don't understand why I'm using AutoGK: I want the program to do the job for me which means not to have to cut the external subs manually.

[Buggle]

It appears you don't understand why I'm using AutoGK: I want the program to do the job for me which means not to have to cut the external subs manually.

Again, I do not know in what other way it would be possible, since with OCR you will still need character recognition, for which I for instance use a program that still needs my input (SubRip). If there are programs that can automate that process, where's the problem? Instead of doin it yourself, it could be automated. I do not know how, but it should be possible.

Besides that, why not use the timecodes/framecounts that were used by AutoGK to cut the final stream to also cut the subtitle stream?

[Chetwood]

Besides that, why not use the timecodes/framecounts that were used by AutoGK to cut the final stream to also cut the subtitle stream?
If I understood len0x's previous posts correctly that's not working correctly. Besides, I'm only using idx/sub which spares me to do OCR.

[Buggle]

If I understood len0x's previous posts correctly that's not working correctly. Besides, I'm only using idx/sub which spares me to do OCR.

Okay, that's a different story. Then forget my whole remark.
(But still, shouldn't it be possible to modify those streams somehow?)

I for one never use idx/sub because they take up multiple MB that could be used for encoding, plus I do not like the way the subs look. But of course that's a matter of taste and personal preferences.

[Chetwood]

It's a matter of taste, alright. Consider me surprised about you prefering rendered subs over the originals, after all most standalones pretty much suck displaying them but, do you really think ~4 MB on a 400 MB xvid (40 min ep, 2 languages) not spent on subs would make a noticeable difference when used for encoding?

[FishTank]

i read through a few pages and couldn't find any mentioning of
multi-angled dvds.
its not really a problem, since one can re-author the dvd in shrink, but
its still a bug in AGK and i figured you might wanna know (if in fact you dont).

so, if you encode a dvd that has angles, you get a mess lol. repeating
frames for different angles, randomly. an example dvd would be
"the kid (http://www.imdb.com/title/tt0219854/)" RC1 or "george of the jungle (http://www.imdb.com/title/tt0119190/)" RC1.

hope it helps, otherwise ignore it :D
and THANK YOU for continuing this GREAT tool len0x :)

[manono]

Wouldn't decrypting either of those movies using the IFO Mode of DVD Decrypter and choosing the angle you want solve the problem? It's up to the user to prepare the videos properly before sending to AutoGK. That may include removing any "modern" copy protection, the angle(s) you don't want, and any other stuff, such as logos or warnings, that may be in the same VTS as your movie.

[len0x]

its still a bug in AGK and i figured you might wanna know (if in fact you dont).


its not a bug - its a feature of DGIndex where it can't process multi-angled vobs...

[FishTank]

well you can certainly argue that point. imho it should work or not
be possible. as it is, AGK will ask you want angle (PGC? cant recall)
to use, but no matter what you choose, you'll end up with
a mess out of all angles.

:)

ps: the ones i've tried were ripped with RipIt4me (movie only). wouldn't it be the same in IFO mode with dvddecrypter?

edit: wrote this while you posted @len0x.. i see :) as i said, no problem, easy workaround and thanks for
the clarification. keep it up :D

[len0x]

Nope, in IFO mode DVDD actually strips out angles... Angle/PGC selection is put in purely for subs to work properly on the material that was properly processes before. I agree it could be more obvious, but it was never intented to work in a different way due to limitation of DGIndex.

[FishTank]

gotcha!

good to know, thanks :)

[buzzqw]

Hi Len0x

i want some spoiler.. what are your plan with AutoGK ?

thanks!

BHH

[len0x]

I'm undecided :) I'm thinking to start looking at different containers first.

[buzzqw]

it's a good start

both mp4 and mkv have good muxing utility and tagger

and ... then you will be ready for the next codec ;)

BHH

[Chetwood]

IMHO a good start is always to fix any remaining bug first before starting on new features. So dont push len0x, guys ;)

[BigDid]

Hi,

I would like to come back on the subject from the main thread:
http://forum.doom9.org/showthread.php?p=1246372#post1246372
which was related to Max quality/FUWizard/Sliders

So I have tested some of the FUW profiles and manually set the xvid encoder

1/ If you use the FUW 2.90 version, the x264 is updated to a recent rev, xvid is not (still rev47)
To get the VAQ an SSE3 optimizations you need to unchek "use internal xvid" in the expert mode (options) and use the xvid installed by AGK (rev 50)

2/ There are some pros and cons with FUW. I will focus on quality. FUW doesn't use same parameters as AGK for xvid encoding; so it may influence in quality:
- In xvid encoder/quality preset/more/Quantization FUW use 1 to 31 (AGK uses 2 to 4, at least in 1pass encode)
- The Xvid/Standalone profile doesn't use B-frames
- To have b-frames you need to use the unrestricted profile

So it has an impact on size; big size should give better quality: I & P frames only, Quant up to 1 (AGK is limiting to q2)
I am sure it can be true for an ESS standalone, not so sure for MTK..

3/ Regarding the slider in FUW, the
- Fast-Lower quality
- medium - medium quality
- slow - high quality
is true for x264 (fast, slow, very slow) not really for Xvid cause there is IMO not enough choices.

The slider thingie is a good visual reference and maybe could be re-used in AGK; at least for:
- Fast speed - safe settings
- Slow speed - max quality
and adapted to ESS -MTK - Unrestricted profiles/presets if needed

I also think it can be usable for xvid as for X264 so double use !

Eventually more to come depending on feedback.

Did

Edit1 (to avoid increased number of posts) It seems there is a lot of big sizes encodes and often undersized with Xvid maxxed. FUW doesn't have this problem because it uses (by default?) Xvid Quantizer from Q1 to 31 instead of Q2 to4/5/x for AGK. Suggested:
-Cutting B-frames (as done actually) is a good way to lower compressability and gain quality.
-Extending Quantizer range up to Q1 could also help for 2 pass but also for 1 pass
-Besides that the denoiser removegrain (mode=2) gives more compression than mode=5 or =1 so the latest could be used for a very little upsizing gain (+/- 1%) and gain some details (or grain, nobody's perfect)
*For the MTK or unrestricted set, using a less compressible CQM still MTK/SAP compatible like sharktooth Eqm V3 HR or Heini MR (modded rev of the V3-HR) could upsize for +/-3% and gain more details/sharpness (some tests with VAQ 1 pass)

[len0x]

Heh, I'm sort of back after really sudden wave of problems that hit me this spring :) After lots of hardware problems, having to move home, loosing internet, vacations and busy time at work I'm going to catch up with what's going on around here ;)

[buzzqw]

welcome back len0x!

BHH

[BigDid]

Hi Len0x,

Glad to see you back.

You have all my sympathy, I also had my lot of hardware problem a while ago :(

Did

[Chetwood]

Welcome back len0x, I can imagine you really missed getting bugged about new features ;) Since you said you would reconsider it I'd like to remind you of adding an option to start a program when a job and/or queue is finished. This way I could call a batch file that would do a netsend from my encoding machine in the basement or even use my telephone system to text my cell phone. Implemented as a commandline feature like

AutoGK -jobdone "netsend.bat" -queuedone "delete.bat"

would be fine by me. Thanks.

[Mixer73]

Heh, I'm sort of back after really sudden wave of problems that hit me this spring :) After lots of hardware problems, having to move home, loosing internet, vacations and busy time at work I'm going to catch up with what's going on around here ;)

WB len0x, hopefully no more dramas for you!

[maxhavoc]

One feature I'd love to see is the ability to batch add jobs. I routinely rip TV show DVDs which require multiple independent jobs (one for each episode) so I'd love the ability to add them all in a simple fashion through the command line.

For example just use the input name as the output name, allow me to specify codec and size and let her rip.

Something like: autogk -add -c xvid -s 175 1.vob 2.vob 3.vob etc...

[Chetwood]

Plus 1!

[Barough]

Nice 2 see that ur around again lenox :)

Would really like 2 see a Option for enable/disable VAQ. A other nice addition would be to get an option for QPel.

[somebodeez]

I would like to have the ability to easily use AVIsynth filters like in GKnot.:)

[chilled]

Hi, i've got two suggestions/requests for your consideration to implement in the next version of AutoGK:

- launch 2 lame mp3 threads at the same time when the cpu is dual core AND the user has chosen to encode two audios (original+dub, original+commentary, etc). eventually the forsame for 3,4 and quad core cpus. This is standard procedure in foobar2000 encoder and, I guess, many others. it doubles the speed.

- I know this has already been issued but I'm not sure why is shareware Winrar still compulsory when you want external subtitles. You could choose a more standard format (.zip which is just a little less efficient) which even an out-of-the-box XP can decompress. My suggestion is to use a free standalone exectuable like 7za.exe or so.

thanks for your attention

[Chetwood]

I've wondered about that to, why rar the subs at all? It's only saving a few kbytes and I've yet to see a standalone/hardware media player that would support it.