Auto Gordian Knot: current version 2.55

[Nikse555]

Ups! Sorry for reporting a known bug (FAQ Q6.3).

Good idea to let the installer in 1.16 check for old xvid versions... so newbies like me can encode right - thx :)

[therealjoeblow]

Originally posted by len0x
Yeah, look like you have to do a bit of math: open all of the one by one write down frames, sum them up and add frame number from the last vob when credits starts.

P.S. just to remind to everyone who is not satisfied with automation of this process that AutoGK doesn't support credits and this hack with the frame number is merely a gesture to those who can't live without that feature no matter what. The rest can still think of this feature as non-existent :)

If I read the previous messages correctly, then the frame required is from the raw source, not the final IVTC'd avi, and AutoGK multiplies the specified frame number by 80% (=23.976/29.976) if the file ends up getting IVTC'd, or uses that frame number if fps stays at 29.976, or if the source is 25.000 fps PAL.

So, there's really only 2 cases that you need to worry about - is it NTSC or PAL material. If I'm correct (len0x please either confirm or correct?), and if you're not all that anal about getting the exact friggin frame, why don't you just use the time code that the credits start at (use the slider in WinDVD, PowerDVD, or any other player of your choice to find that point), and multiply by either 29.976 or 25.000?

Eg, total movie is 1h 36m 22s (which is really irrelevant) and credits start at 1h 30m 15s, then the total seconds equals (15 + 30x60 + 1x60X60) = 5415s.

Now for PAL, credits start frame = 5415 x 25.000 = 135375

and for NTSC, credits start frame = 5415 x 29.976 = 162320

Is that not simple and close enough?

[Gazza]

Hi Len0x,

The autodetect feature for xvid in the installer might have a slight bug. I had installed xvid rc4 prior to running that latest autogk update and the installer detected this version of xvid as an older version and skipped the installation of xvid. I manually uninstalled xvid but the autogk installer still thinks I have an old version in the system.

Nice proggie.

Gazza

[Spiders]

Hi Len0x!
Do you speak Russian?
Êîðî÷å, òàêàÿ ïðîáëåìà: â ïðîãðàììå åñòü ôóíêöèÿ àâòîìàòè÷åñêîãî îòêëþ÷åíèÿ êîìïüþòåðà ïîñëå îêîí÷àíèÿ ðàáîòû. Òàê âîò êîãäà ÿ åå âêëþ÷àþ è êîãäà ðàáîòà çàêàí÷èâàåòñÿ, òî êîìïüþòåð íå âûêëþ÷àåòñÿ, à ïåðåçàãðóæàåòñÿ.  ÷åì ïðîáëåìà?

[len0x]

Originally posted by Gazza
The autodetect feature for xvid in the installer might have a slight bug. I had installed xvid rc4 prior to running that latest autogk update and the installer detected this version of xvid as an older version and skipped the installation of xvid. I manually uninstalled xvid but the autogk installer still thinks I have an old version in the system.


Because actually you do have an old version :)
If installer finds that xvid.dll is present in the system directory - then it warns you. New xvid installation only contains xvidvfw.dll and xvidcore.dll. If you absolutely sure that new xvid is working ok for you (although old one was definitely not uninstalled properly) then just delete xvid.dll.

[len0x]

Originally posted by therealjoeblow
If I read the previous messages correctly, then the frame required is from the raw source, not the final IVTC'd avi, and AutoGK multiplies the specified frame number by 80% (=23.976/29.976) if the file ends up getting IVTC'd, or uses that frame number if fps stays at 29.976, or if the source is 25.000 fps PAL.


correct

Originally posted by therealjoeblow

So, there's really only 2 cases that you need to worry about - is it NTSC or PAL material. If I'm correct (len0x please either confirm or correct?), and if you're not all that anal about getting the exact friggin frame, why don't you just use the time code that the credits start at (use the slider in WinDVD, PowerDVD, or any other player of your choice to find that point), and multiply by either 29.976 or 25.000?

Is that not simple and close enough?

Actually it is - good hint !

[yotsuya-san]

Hi all. I think there's something wrong with Xvid 1.0 RC4 and/or AutoGk and their "interaction". I've done a compressibility test of Matrix Revolution with AutoGk 1.14b (1.16 han not yet come) with this settings:

Audio Track: No Track
Custom size: 615 Mb
Advanced settings: Minimum width=512
Codec=Xvid

Installed codec is Xvid 1.0 RC4 included in AutoGK update.

The result (sorry, I don't have the log) was 512x208 resolution with a predicted comp test of 61,51. So I expected that encoding that film with a 512x208 and a target quality of 61% I would have had an avi of ABOUT 615 Mb or a little less. Well, the avi is 661 Mb, about 50 megs more.
Since I didn't have this problem with DivX (always a little -sometimes more than a little- less than the predicted size of comp test), I ask myself if it's not a problem related to Xvid.

By the way, the comp test trough AutoGK of the same movie with DivX gave me a predicted comp test, at the same resolution, of 54,41, but I haven't encoded the film yet 'cause I'm quite sure the resulting avi will be of low quality.

I have another question: it seems that AutoGK, even at at 512xXXX resolution and at high quantizers (target quality at about 50-60%) use, in target quality mode, a Lanczos Resize, while at the same resolution in 2 pass mode it uses Bicubic filter. Am I right? Is not Lanczos too much for that low resolution and that low bitrate?

Hope I haven't offended any of you saying wrong things.

Bye.

[len0x]

Originally posted by yotsuya-san

The result (sorry, I don't have the log) was 512x208 resolution with a predicted comp test of 61,51. So I expected that encoding that film with a 512x208 and a target quality of 61% I would have had an avi of ABOUT 615 Mb or a little less. Well, the avi is 661 Mb, about 50 megs more.


Predicted % doesn't mean that much in some cases. What was expected REAL percentage after first pass? Comp test for XviD is known to be up to 10% wrong in worst cases. So for 600Mb error can be upto 60Mb.
Nothing unusual here. So you really need the log for the first pass percentage value...

[len0x]

Btw, I accidently disabled CPUID code for detecting MMX-capabale CPUs in latest version (1.16). I wonder if that has any impact on HT crashes lots of ppl were having. Still crashes ?

[Spiders]

Len0x
beside me question: there is function Shutdown when done in program. So here is when I its include and when functioning ends, that computer is not switched off, but is rebooted. What problem? We Beg pardon for my english... :)

[yotsuya-san]

Originally posted by len0x
Predicted % doesn't mean that much in some cases. What was expected REAL percentage after first pass?

First pass? I did not a two-pass encoding, I stopped AutoGK after the comp test and I re-started it with 61% as quality target. Do I miss something? :scared:

Comp test for XviD is known to be up to 10% wrong in worst cases. So for 600Mb error can be upto 60Mb.
Nothing unusual here.

Sorry, I didn't know that. Thanks for the clarification.
By the way, now I'm encoding with DivX and a quality target of 54%, just for curiosity. If it will be about 615 Mb, I think the only way is to use it for my target quality - target size encodings...

What about Lanczos filter? I hope you didn't miss it ;)

Thanks a lot.

[len0x]

Originally posted by Spiders
Len0x
beside me question: there is function Shutdown when done in program. So here is when I its include and when functioning ends, that computer is not switched off, but is rebooted. What problem? We Beg pardon for my english... :)

which OS are you using ?

[therealjoeblow]

Originally posted by yotsuya-san
First pass? I did not a two-pass encoding, I stopped AutoGK after the comp test and I re-started it with 61% as quality target. Do I miss something? :scared:


You should *not* do that - AutoGK uses the comptest simply to make an intelligent decision about: (1) whether the first guess for autosize was a good one; (2) whether the sharp resize algorithm is the best to use, or whether the softer resizer should be used; and (3) whether the sharp or softer quantizer matrix should be used. The predicted quality or compressibility is *NOT* the final value that will be used to reach the desired size, it is a simple estimation of how well you can compress the small portion of what is sampled during the comptest, as I said, in an effort to optimally set the rest of the encoding parameters.

If you stop after the comptest and do a 1 pass encode with that setting, the best you can hope to achieve is come up with an encode that has 61% of quality (or whatever you specify) - target size will *NOT* be used, and the size will be whatever it comes out to.

The correct way to use AutoGK to hit a specific file size is to set that in the preference, start the encode, and let all of the passes (comptest, first pass, second pass) complete - AutoGK and XviD will adjust the encoding parameters and redistribute the compression bits throughout the 2nd pass based on the results of the complete first pass, and then your target size should match within about 1mb.

[yotsuya-san]

Originally posted by therealjoeblow
If you stop after the comptest and do a 1 pass encode with that setting, the best you can hope to achieve is come up with an encode that has 61% of quality (or whatever you specify) - target size will *NOT* be used, and the size will be whatever it comes out to.

I didn't say anywhere I did such a horrible thing :D

I know what comp test is, I've used it many many times, I know the (simple) formula behind it, and if you look at its creator's site, jonny, you will find the Enc program which also performs a size prediction based on the comp test. It is, more or less, the same thing I do through AutoGK making a comp test and using the value for a single pass quality based encoding.
The only differences I know are that I use the comp test value PREDICTED by AutoGK and that AutoGK always uses, in target quality mode, Lanczos resize filter, while using 2 pass it uses different resize filters.

The correct way to use AutoGK to hit a specific file size is to set that in the preference, start the encode, and let all of the passes (comptest, first pass, second pass) complete - AutoGK and XviD will adjust the encoding parameters and redistribute the compression bits throughout the 2nd pass based on the results of the complete first pass, and then your target size should match within about 1mb.

I know this too, but that's not what I want to do, of course! I don't like two pass mode divx results especially with low bitrates, I hate pixelization in high motion scenes, I prefer a more uniform quality that ONLY 1 pass quality based mode can give.
Yes, I also know that I'm not a newbie and AutoGK is not made for me. But I am quite curious if I or others can use it to do quality based encodings with an eye on file dimension. If I can't use that way, I'll come back to his big brother, without desturbing anyone or ranting about this or that feature, this I tell for sure! ;)

Bye.

[len0x]

Originally posted by yotsuya-san
II know this too, but that's not what I want to do, of course! I don't like two pass mode divx results especially with low bitrates, I hate pixelization in high motion scenes, I prefer a more uniform quality that ONLY 1 pass quality based mode can give.
Yes, I also know that I'm not a newbie and AutoGK is not made for me. But I am quite curious if I or others can use it to do quality based encodings with an eye on file dimension.

1 pass encoding with comp test in front was discussed at some point when AutoGK just started. Conclusion was: you can really confident predict target file size in 100% cases based on just one comp test. DivX is more easy for this purpose, XviD is more difficult as I said ealier. But in general you might be in luck with some movies, may not be with others (like you experienced yourself). And there is nothing more you can do in GK either...

Regarding resize in quality mode - it's always Lanczos. Make no mistake: the quality with sharp or soft resizer is always the same but size is not! Maximum quality is the quality of codec encode, it doesn't include avs transformations. So with sharp resize you get larger maximum size then with soft one. But I see no point in reducing maximum quality artificially with resizer. (so if you'd like smaller size you better reduce quality but not resizer - in any case that mode was intended mostly for non-resize encodes at all, i.e. with width 704)

[yotsuya-san]

Originally posted by len0x
Regarding resize in quality mode - it's always Lanczos. Make no mistake: the quality with sharp or soft resizer is always the same but size is not! Maximum quality is the quality of codec encode, it doesn't include avs transformations. So with sharp resize you get larger maximum size then with soft one. But I see no point in reducing maximum quality artificially with resizer. (so if you'd like smaller size you better reduce quality but not resizer - in any case that mode was intended mostly for non-resize encodes at all, i.e. with width 704)

Yes, I think I understood your point. Target quality has quality in mind, not filesize, so using always Lanczos is like saying: "Hey, use all the space you need". At that quality and at that resolution.

I think I should come back to GordianKnot to do what I want to do. I would introduce, through AutoGK, two more approximations to 5% comp test: one is that it does a comp test at an higher resolution, the other is that predicted comp tesp is calculated by using a different resize filter than the one which will be used (is this point right?).
GordianKnot, making a comp test at the resolution and with the filter I will use later, should avoid those.
I have to say that this "manual" procedure has ALWAYS given to me me "RIGHT" results, with quite little undersized divx avis (to be sure I always rounded % to the first lower integer number).

Thanks for clarifications, Len0x.

[Spiders]

Originally posted by len0x
which OS are you using ?

Windows 98... :)

[SonGokuDBZ]

@Lenox:
I know, some day your head must explode when you hear the word "feature request". That's why I only want to make a small suggestion: What about a ".waite"-file which causes AutoGK to wait before the first-pass starts with a message like "Press OK to continue with the first pass!". Advance user could use the time to edit the avs-skript. It's up to you to decide it and if you think this feature isn't necessary its OK.

Thanks anyway, your program is great!

SonGokuDBZ

[wertherman]

Yey!!! I think this thread is now the most replied to thread on doom9's forums (surpassing the other ever growing thread for media player classic with 1867 replies to 1763, and 489812 views to only 143661)...

Yay!

[Pyniok]

Originally posted by len0x
red/green problems should go for good (hopefully).
New icon and logo for AutoGK - sort of rebranding :)

First of all: great tool, it's good, gooood.

After switching to 1.14 I found out the sound level in final avi is much lower than it used to be. Much lower, few times lower. So I switched 1.5b26 besweet.exe with 1.5b23 one and gave it another try, with exactly same settings. It was all good again, properly loud.

Both besweet logs are the same.

Am I missing anything? Thanks.

[Toge]

I've just switched BeSweet 1.15b26 with 1.4 stable.

will it still work ok?

[DSPguru]

Originally posted by Pyniok
Both besweet logs are the same.post them both.

[len0x]

Originally posted by Spiders
Windows 98... :)

Does this happen with regular GK as well ?

[len0x]

I changed interleaving settings for AC3 which result in even less overhead, but its estimation had to be changed as well, so now files will be 100-200K per CD bigger that previous versions (hopefully not more that that).

Also ppl having problems with CTRL-F10 should not have them anymore.

Last but not least: now that XviD 1.0 is almost final I adjusted resizing values for RC 4.

[QNX]

i have nice situation here.. except HT of course :D

i'm trying to encode th LinkinPark DVD
Video info: PAL - 720x576 - 4:3 Normal - 25fps - 1:11:01.800

after 2 vdub runs and besweet starting copress. test and on 2% i'm getting error in vdubmod:

Crash reason: Access Violation

Crash context:
An out-of-bounds memory access (access violation) occurred in module 'xvidcore'...

...while compressing frame 612 from 04da0000 to 0561000c (VideoSequenceCompressor.cpp:375)...

...while running thread "Processing" (thread.cpp:105).

etc..

i've tried 1.16 and 1.17 now - same result
with xvid rc4 :D

[miljbee]

Hi Len0x,

I have 1 problems to report to you concerning AutoGK :

I have several computers on a lan. I use one of them as a file server. All computers are WinXP.
Yesterday, I have done the following :
Launching AutoGK on Computer A and B and saving the output avis on the same directory of the file server. The result was an error msg concerning a temp file of autoGK that was already in use. It's because the Temp Folder is created in the destination directory. I Think it may be better if it was created in the AutoGK Directory isn't it ?
Or if you prefer, you could use time/date in the name of the temp folder.

Once again thanks for your work !

[len0x]

Originally posted by miljbee
I Think it may be better if it was created in the AutoGK Directory isn't it ?
Or if you prefer, you could use time/date in the name of the temp folder.


Well, it an intended feature. I personally select just one output dir and temp dir gets overwritten for every consequent job (I make long queue usually and have space restrictions, that is why I don't like to keep output temp dir).

[len0x]

Originally posted by QNX

after 2 vdub runs and besweet starting copress. test and on 2% i'm getting error in vdubmod:

Crash reason: Access Violation


Does this happen on the same place everytime ?

One of three things:
- corrupted vobs (try reripping)
- overclocking
- bug in xvid (then reporting in XviD forum will probably help)

[miljbee]

I am not sure to understand what you wrote, and perhaps my problem was so badly written that you misunderstand it :
Computer A and B are writing to the same temp folder on the same computer at the same time ... so it can not work since the tmp files are used at the same time for different jobs.

[Pyniok]

Originally posted by DSPguru
post them both.

I tried again (still lower sound level with 5b26), but logs are bit different:

5b26
-----------------------
BeSweet v1.5b26 by DSPguru.
--------------------------
Using azid.dll v1.9 (b922) by Midas (midas@egon.gyaloglo.hu).
Using lame_enc.dll v1.32 (8/8/2003), Engine 3.90 <http://www.mp3dev.org/>.

Logging start : 04/13/04 , 22:33:33.

D:\PROGRA~1\VCD\AutoGK\BeSweet\BeSweet.exe -core( -input E:\stanger\gk_tmp\5B26 AC3 T01 3_2ch 448Kbps DELAY -296ms.ac3 -output E:\stanger\gk_tmp\5B26 AC3 T01 3_2ch 448Kbps DELAY -296ms.mp3 -logfile E:\stanger\gk_tmp\5B26 AC3 T01 3_2ch 448Kbps DELAY -296ms.log ) -ota( -G 1 ) -azid( -L -3db -c normal ) -lame( -h -alt-preset 128 ) -profile( AutoGK )

[00:00:00:000] +------- BeSweet -----
[00:00:00:000] | Input : E:\stanger\gk_tmp\5B26 AC3 T01 3_2ch 448Kbps DELAY -296ms.ac3
[00:00:00:000] | Output: E:\stanger\gk_tmp\5B26 AC3 T01 3_2ch 448Kbps DELAY -296ms.mp3
[00:00:00:000] | Floating-Point Process: Yes
[00:00:00:000] | PostGain normalize to : 1.00
[00:00:00:000] +-------- AZID -------
[00:00:00:000] | Input Channels Mode: 3/2, Bitrate: 448kbps
[00:00:00:000] | Output Stereo mode: Dolby surround compatible
[00:00:00:000] | Total Gain: 0.000dB, Compression: Normal
[00:00:00:000] | LFE levels: To LR -3.0dB, To LFE 0.0dB
[00:00:00:000] | Center mix level: BSI
[00:00:00:000] | Surround mix level: BSI
[00:00:00:000] | Dialog normalization: No
[00:00:00:000] | Rear channels filtering: No
[00:00:00:000] | Source Sample-Rate: 48.0KHz
[00:00:00:000] +-------- LAME -------
[00:00:00:000] | 'abr 128' preset is used
[00:00:00:000] +---------------------
[00:05:50:496] Gain of 18.0dB had been asserted to file.
[00:05:50:496] Conversion Completed !
[00:01:49:000] <-- Transcoding Duration

Logging ends : 04/13/04 , 22:35:22.

------------------------------

and 5b23:

------------------------------
BeSweet v1.5b23 by DSPguru.
--------------------------
Using azid.dll v1.9 (b922) by Midas (midas@egon.gyaloglo.hu).
Using lame_enc.dll v1.32 (8/8/2003), Engine 3.90 <http://www.mp3dev.org/>.

Logging start : 04/13/04 , 23:14:45.

D:\PROGRA~1\VCD\AutoGK\BeSweet\BeSweet.exe -core( -input E:\stanger\gk_tmp\5B23 AC3 T01 3_2ch 448Kbps DELAY -296ms.ac3 -output E:\stanger\gk_tmp\5B23 AC3 T01 3_2ch 448Kbps DELAY -296ms.mp3 -logfile E:\stanger\gk_tmp\5B23 AC3 T01 3_2ch 448Kbps DELAY -296ms.log ) -ota( -G 1 ) -azid( -L -3db -c normal ) -lame( -h -alt-preset 128 ) -profile( AutoGK )

[00:00:00:000] +------- BeSweet -----
[00:00:00:000] | Input : E:\stanger\gk_tmp\5B23 AC3 T01 3_2ch 448Kbps DELAY -296ms.ac3
[00:00:00:000] | Output: E:\stanger\gk_tmp\5B23 AC3 T01 3_2ch 448Kbps DELAY -296ms.mp3
[00:00:00:000] | Floating-Point Process: Yes
[00:00:00:000] | PostGain normalize to : 1.00
[00:00:00:000] +-------- AZID -------
[00:00:00:000] | Input Channels Mode: 3/2, Bitrate: 448kbps
[00:00:00:000] | Output Stereo mode: Dolby surround compatible
[00:00:00:000] | Total Gain: 0.000dB, Compression: Normal
[00:00:00:000] | LFE levels: To LR -3.0dB, To LFE 0.0dB
[00:00:00:000] | Center mix level: BSI
[00:00:00:000] | Surround mix level: BSI
[00:00:00:000] | Dialog normalization: No
[00:00:00:000] | Rear channels filtering: No
[00:00:00:000] | Source Sample-Rate: 48.0KHz
[00:00:00:000] +-------- LAME -------
[00:00:00:000] | 'abr 128' preset is used
[00:00:00:000] +---------------------
[00:05:50:496] Gain of 16.5dB had been asserted to file.
[00:05:50:496] Conversion Completed !
[00:05:50:496] Actual Avg. Bitrate : 129kbps
[00:01:49:000] <-- Transcoding Duration

Logging ends : 04/13/04 , 23:16:34.
--------------------

[len0x]

Originally posted by miljbee
I am not sure to understand what you wrote, and perhaps my problem was so badly written that you misunderstand it :
Computer A and B are writing to the same temp folder on the same computer at the same time ... so it can not work since the tmp files are used at the same time for different jobs.

No, I perfectly understood it, but I replied why I want to keep the current behavior. :) (because I like the same directory being deleted by every consequent job, otherwize I would end up with lots of garbage in the end...)

[len0x]

...on AutoGK website (my signature is updated finally). Little program is written by therealjoeblow (big thanks ot him) to help you creating all those hidden files for AutoGK input dir.

[Stebs]

Ah, nice little Proggie,well done therealjoeblow!

@therealjoeblow
Just 2 (very minor) things I found:

For some reason the icon of "Hidden Options.exe" is the same Text-Icon as the "Hidden Options.txt", making it harder to find quickly. (I am using WinXP Pro)

Then in the very nice Frame Calculator it would be nicer to have Hrs, Min and Sec disappear when you click into the fields instead to beeing forced to delete them. Or, if not possible with VB6, write Hrs, Min and Sec above the fields...
Yeah, ;) warned you those where very minor things :D

@len0x
Any news/clues with different sound levels related to version of BeSweet?

[DSPguru]

@Pyniok
try replacing -ota( -G 1 ) with -ota( -hybridgain )


@lenox
i would advise to use this switch as default .

[therealjoeblow]

Originally posted by Stebs
Ah, nice little Proggie,well done therealjoeblow!

@therealjoeblow
Just 2 (very minor) things I found:

For some reason the icon of "Hidden Options.exe" is the same Text-Icon as the "Hidden Options.txt", making it harder to find quickly. (I am using WinXP Pro)

Then in the very nice Frame Calculator it would be nicer to have Hrs, Min and Sec disappear when you click into the fields instead to beeing forced to delete them. Or, if not possible with VB6, write Hrs, Min and Sec above the fields...
Yeah, ;) warned you those where very minor things :D



Thanks for the input - I updated it, it's on it's way to len0x, probably a day or so before he uploads it to the main server:

v-0.5 (April 14, 2004)
----------------------
-Changed program icon by request.
-Improved handling of 'prompt-text' when entering textboxes in
calculator (now when you click in the box the prompt-text gets
auto-selected, and when you start typing, the prompt-text clears,
getting replaced by your entry.
-Added tooltips as additional entry-prompts for textboxes.
-Added some critical Error Trapping:
-You can only enter numerical input into the textboxes.
-You can only enter 1 digit in Hours, and up to 2 digits in
each of Minutes and Seconds.
-Message is displayed, requiring correction, if Credit Quality
is out of the 20-100% range.

[pixolex]

Originally posted by len0x
...on AutoGK website (my signature is updated finally). Little program is written by therealjoeblow (big thanks ot him) to help you creating all those hidden files for AutoGK input dir.

Forbidden
You don't have permission to access /HiddenOptions_v-0.4.rar on this server.

Apache/1.3.27 Server at len0x.btothec.com Port 80

:(

[len0x]

Originally posted by therealjoeblow
Thanks for the input - I updated it, it's on it's way to len0x, probably a day or so before he uploads it to the main server:


It's up there now.

2All Do not try to link or use download managers (or at least those which don't keep referrer) for downloads at AutoGK.net - it won't work :)

[len0x]

Originally posted by DSPguru

@lenox
i would advise to use this switch as default .

I used that one before, then someone suggested -G 1 and I switched. But any reasons it should work differently in b26 ?


P.S. Do you still have b25 around for downloading?

[DSPguru]

i'm really too tired to re-explain all the gain modules in BeSweet :(. this had been discussed zillions of times in the 'audio encoding' forum, and anyone who disagree with my recommendation is being asked to either :
1) read it all and write a persuading, well-argued post, explaining why i should change my recommandation.
2) use any BeSweet switches at home with his own computer.


to summarize : imho, hybridgain is the best choice (reasonable level of pregain in accordance to dynamic range compression, reasonable level of postgain, reasonable usage of dialog normalization and reasonable scale level for lame.
reasonable normalization at reasonable speed)


old b25 and a new, fixed, b26, had been uploaded.

[Taurus]

i'm really too tired to re-explain all the gain modules in BeSweet
Oops,there's someone really disappointed!
I can fully understand DSPguru's ''excitement''.
As there is so much misunderstanding on all the switches used in BeSweet I would like to make a few things clear: If you don't care for some artifacts, use normalize to 100% & dynamic compression set to ''normal'' on azid. Only then a really --loud-- output to the ''lame'' encoder is achieved.
Or use the ''HybridGain'' switch, as mentioned by DSPguru.
Or try the switches together.....
Well one thing is strange: Why have the problems arised on last beta?
I can't remember this has happened before on older releases.
But maybe I did'nt noticed it, because by using normalization in Mediaplayer Classic it was not so obviously.

Taurus

[nightrhyme]

I'm new to dvd-ripping and I want to thank you for this easy to use program.
It's really easy for a newb like me and produces excellent results :p

I have a couple of questions thoug:

1. Is there any way of making AutoGK use all my memory when encoding ? I have 1024MB and I see that AutoGK only uses about 500.
Only setting I could find was the performance tab in VdubMod which I maxed out.

2. About resolution. I tried some different resolution settings.
Which setting produces best result ? Forcing 720, 640 or auto width ?
Or does that depend on other settings. I usually make 2 cd Xvid, Audio mp3 192Kbps.

3. Any news on making AutoGK run on Hyper Threaded Cpu's. I usually disable Hyper Threading in bios before running AutoGK.

4. And last. How do I know which bitrate the movie was encoded in ?

Sorry for the Newb questions. Hope you will answer them anyway :rolleyes:

Thanx in advance

[GizmoDerMokwai]

Originally posted by nightrhyme

4. And last. How do I know which bitrate the movie was encoded in ?


Get Gspot from Doom's download section...

@len0x:
I've tested AutoGK on various shorter sequenzes, just about 2 minutes long. FOr example i've testet encoding the hidden Credits from Star Wars Episode I and II. This sequenzes feature Text in the black borders/bars. AutoGK using AutoCrop crops that bars, so text is gone. Maybe you can also add a little hidden option like .mono for .nocrop .

[miljbee]

GizmoDerMokwai wrote :
Maybe you can also add a little hidden option like .mono for .nocrop


... or a .crop one. This file could contain Left, right, Up and down values for croping the original movie ... (basically i only need left and right, but if it could meet the needs of others ...)

[manono]

Hi nightrhyme and welcome-

1. The encoding is done by VDubMod, and it takes as much as it needs. I'm surprised that you got it to use as much as you did, as it usually uses about half that on my computer.

2. If you make 2 CD encodings, then you certainly don't want to force a very high resolution. With less compressible or very long movies it's very easy to get a bad looking movie with a high resolution. Until you have more experience, I'd recommend using the Auto Setting. But there's no harm in experimenting to see what looks good to you. But pay attention to the compression test results when you experiment.

3. If the information you have is from the guide, then it's out of date. You might try it with Hyperthreading enabled. If it doesn't work, you can try it in Win98 compatibility mode, as explained in the guide. And at the same time, you might run some tests to see if the encoding is really faster with hyperthreading enabled.

4. As Gizmo said, get GSpot (http://www.doom9.org/Soft21/Editing/gspot221.exe).

[DSPguru]

Originally posted by Taurus
Well one thing is strange: Why have the problems arised on last beta?the postgain module had been disabled by mistake in that build, and so the last stage of gain assertion didn't do anything. (if you'll pay attention, you could see that the postgain asseration takes no-time in this build, instead of the reasonable time it takes usually).
anyhow, the postgain engine had been re-enabled, and you can download a fixed version from my webage, or you could wait until it being integrated in (auto)gk.

[AlmanNewfred]

Thanks for this little tool. But the frame calculator seems to be missing an option for film frame rate (23.976 fps).

[Taurus]

Thanks for acting so fast!!!

(if you'll pay attention, you could see that the postgain asseration takes no-time in this build, instead of the reasonable time it takes usually).

I was just wondering how fast BeSweet can go....
Above statement makes this clear.
Thanks again, for this jewel in audioencoding.
So now there is no need to go back to an older version of BeSweet.
The updated one should work fine now.
I will give it a try, and report what's happening.

Cheers

Taurus

[Xanatos]

Hello,

I've encoded a movie with v1.17 beta (1.16 is the same).
If the movie is encoded with CBR 160 MP3 it plays choppy in MS Media Player 6.4.09.1128 and not at all in Media Player Classic 6.481.
The same move with VBR works perfectly (all other options unchanged)
Videocodec is xvid 1.0 rc4

greetings
Xanatos

[((( atom )))]

i have a little issue to report here, that might either be autogk related or something wierd in my system:

system is:
windows 2000 sp4, p4 with ht on
the system is freshly installed, no other software on it..

happens on:
all autogk-versions, full versions and updates

symptom: after installing autogk i can run it. ONCE! - it won't start again until i rerun the installer. sometimes, though i even have to rerun the installer twice in order for gk to start.
if it refuses to start, i get: autogk has experienced a problem and needs to close (translated).

any ideas?

[Taurus]

Audio volume is back to normal on mp3 encoding!

DSPguru acted real fast: After copying his updated version of BeSweet, downloaded from his webpage, to the directory BeSweet in the AutoGk Folder, everything is back to normal.
Proved it with a small rip, done by AutoGk.
So there should be no need to downgrade to an older version of BeSweet.

Thanks a lot, I really appreciate the work of the devs and mods in this forum.

Cheers

Taurus