MeGUI: General Questions and Troubleshooting Thread

[hello_hello]

If the source is an NTSC DVD, the TIVTC plugin can be used to output a VFR encode. This is copied from another script as an example:

Analysis pass:
LoadPlugin("C:\Program Files\MeGUI\tools\dgindex\DGDecode.dll")
DGDecode_mpeg2source("D:\VTS_02_1_sample.d2v")

TFM(Output="D:\S01E01TFM.txt")
TDecimate(Mode=4, Hybrid=2, Output="D:\S01E01TDecimate.txt")

# TFM(Input="D:\S01E01TFM.txt")
# TDecimate(Mode=5, Hybrid=2, Input="D:\S01E01TDecimate.txt", tfmIn="D:\S01E01TFM.txt", mkvout="D:\S01E01Timecodes.txt")

Encoding pass:
LoadPlugin("C:\Program Files\MeGUI\tools\dgindex\DGDecode.dll")
DGDecode_mpeg2source("D:\VTS_02_1_sample.d2v")

# TFM(Output="D:\S01E01TFM.txt")
# TDecimate(Mode=4, Hybrid=2, Output="D:\S01E01TDecimate.txt")

TFM(Input="D:\S01E01TFM.txt")
TDecimate(Mode=5, Hybrid=2, Input="D:\S01E01TDecimate.txt", tfmIn="D:\S01E01TFM.txt", mkvout="D:\S01E01Timecodes.txt")

I generally do it with a single script and comment/uncomment the appropriate lines. The metrics files are created during the analysis pass (MeGUI has an analysis pass option for adding jobs to the job queue) and the timecodes file is created when the encoding script is first run. You'd add the timecodes to the x264 command line using the custom section in the encoder configuration like this:

--tcfile-in "D:\S01E01Timecodes.txt"

It's only designed for dealing with NTSC sources that are a combination of film and video though. The film sections at 23.976fps and the video sections at 29.97fps. It's not really a bitrate saver.

My favourite sharpener is LSFMod (http://avisynth.nl/index.php/LSFmod). It's subtle. I don't like video that looks sharpened. You can also try MCDegrainSharp (https://forum.doom9.org/showthread.php?p=1855907#post1855907) for some noise removal and sharpening.

[Lord Dredd]

AFAIK, if the source is CFR and using AviSynth, like MeGUI do, it is not possible obtain a VFR encode.

Use HandBrake instead.

Yep Handbrake does have the option of VRF
Many Thanks again , will bother again ;)

If the source is an NTSC DVD, the TIVTC plugin can be used to output a VFR encode. This is copied from another script as an example:

Analysis pass:


Encoding pass:


I generally do it with a single script and comment/uncomment the appropriate lines. The metrics files are created during the analysis pass (MeGUI has an analysis pass option for adding jobs to the job queue) and the timecodes file is created when the encoding script is first run. You'd add the timecodes to the x264 command line using the custom section in the encoder configuration like this:

--tcfile-in "D:\S01E01Timecodes.txt"

It's only designed for dealing with NTSC sources that are a combination of film and video though. The film sections at 23.976fps and the video sections at 29.97fps. It's not really a bitrate saver.

My favourite sharpener is LSFMod (http://avisynth.nl/index.php/LSFmod). It's subtle. I don't like video that looks sharpened. You can also try MCDegrainSharp (https://forum.doom9.org/showthread.php?p=1855907#post1855907) for some noise removal and sharpening.

Thanks a bunch Hello_Hello
Will try and follow your insight
Off to try LSFMod


Any other tips for low bitrate encoding dear mate ???
by low I mean 1500 something for a 720p video

[hello_hello]

Sorry, I usually encode using CRF18, the slow preset and film tuning, and let the bitrate be what it needs to be.
My last 720p encode came in at 1421 kb/s, but it was easy to compress animation. :)

You could try grafun3() from DitherTools at the end of your scripts. In fact you should, maybe more-so for low bitrate encoding. It converts the video to 16 bit, does some gradient smoothing, and then dithers back to 8 bit. It can reduce existing color banding and help prevent the encoder from creating it. I think when I've compared encodes with and without it in the past, including it tends to reduce the bitrate for a give CRF value a little. Not by much, but every bit helps.

I forgot to mention, if you try the above VFR method, once you loaded an analysis script into MeGUI and run it, don't load it into MeGUI again until it's edited to make it the encoding script. If you do, MeGUI will check the script is okay when you load it into the video section and TIVTC will erase the metrics files, so you'll have to run the analysis pass again. It doesn't take long, but it's annoying. If you follow TFM & TDecimate with other filtering in the script, comment it out for the analysis pass too, so as not to slow it down.

I just realised there were a couple of TFM options in my example that were specific to the encode I was doing. I've edited my previous post to remove them

[Lord Dredd]

Sorry, I usually encode using CRF18, the slow preset and film tuning, and let the bitrate be what it needs to be.
My last 720p encode came in at 1421 kb/s, but it was easy to compress animation. :)

You could try grafun3() from DitherTools at the end of your scripts. In fact you should, maybe more-so for low bitrate encoding. It converts the video to 16 bit, does some gradient smoothing, and then dithers back to 8 bit. It can reduce existing color banding and help prevent the encoder from creating it. I think when I've compared encodes with and without it in the past, including it tends to reduce the bitrate for a give CRF value a little. Not by much, but every bit helps.

I forgot to mention, if you try the above VFR method, once you loaded an analysis script into MeGUI and run it, don't load it into MeGUI again until it's edited to make it the encoding script. If you do, MeGUI will check the script is okay when you load it into the video section and TIVTC will erase the metrics files, so you'll have to run the analysis pass again. It doesn't take long, but it's annoying. If you follow TFM & TDecimate with other filtering in the script, comment it out for the analysis pass too, so as not to slow it down.

I just realised there were a couple of TFM options in my example that were specific to the encode I was doing. I've edited my previous post to remove them

You are always so helpful dear mate :)
Many Thanks
I went through Dither tools but seems like I spoke too soon regarding filters :p, my technical prowess is 0.1% of you folks
Couldn't make head and tail of it
was actually thinking of some avisynth filter or some change in x264/x265 profile parameters or add some extra in the command line box ,so that details can be retained, margins remain sharp enough in my low bitrate encoding.
The source doesnt have any grain or doesn't need any denoiser as such,
But you know how this is when you try to hammer a source with such low bitrate , blocks, artifacts tend to appear in the final encode.
Just wish that the video looks decent enough for a HD TV viewing from a distance of 4 to 7 feet

[hello_hello]

If you install Avisynth+ (in addition to MeGUI's portable version) it'll have it's own subfolder called plugins. Any dlls or avsi scripts inside will automatically load when Avisynth runs. MeGUI's Avisynth will check it too.
So you'd put the two dlls in the Win32 folder from the zip file (assuming 32 bit Avisynth), along with the two Avsi scripts.

Dithertools also needs these three, so you'd download them and put the dlls in the same place.
https://github.com/pinterf/masktools/releases
http://avisynth.nl/index.php/RgTools
http://avisynth.nl/index.php/AddGrainC

Then with fingers crossed, you add gradfun3() to a script you're creating with MeGUI's script creator and refresh the preview. You probably won't see a difference, but the alternative is an Avisynth error message.

Avisynth+ has more plugin loading options than classic Avisynth. You can read about them here (http://avisynth.nl/index.php/AviSynth%2B#Plugin_Autoloader), but I use the auto-loading method myself.

I don't use x265, but x264 has it's own denoising. Enabling it and using enough to remove some light noise will probably help. Even if the source doesn't look noisy, give it a try. If it only removes very fine noise you're not seeing then it can't be a bad thing. You can adjust it under the Analysis tab in MeGUI's x264 encoder configuration.
http://www.chaneru.com/Roku/HLS/X264_Settings.htm#nr

Unfortunately I don't think there's really any free lunch, but I'm not an expert when it comes to tweaking x264, because I don't need to use a low bitrate like do you. And personally, I prefer to keep the encoding quality decent even if it means reducing the resolution and sacrificing a bit of detail to do it. It's better than looking at encoding artefacts, in my opinion.

[Lord Dredd]

If you install Avisynth+ (in addition to MeGUI's portable version) it'll have it's own subfolder called plugins. Any dlls or avsi scripts inside will automatically load when Avisynth runs. MeGUI's Avisynth will check it too.
So you'd put the two dlls in the Win32 folder from the zip file (assuming 32 bit Avisynth), along with the two Avsi scripts.

Dithertools also needs these three, so you'd download them and put the dlls in the same place.
https://github.com/pinterf/masktools/releases
http://avisynth.nl/index.php/RgTools
http://avisynth.nl/index.php/AddGrainC

Then with fingers crossed, you add gradfun3() to a script you're creating with MeGUI's script creator and refresh the preview. You probably won't see a difference, but the alternative is an Avisynth error message.

Avisynth+ has more plugin loading options than classic Avisynth. You can read about them here (http://avisynth.nl/index.php/AviSynth%2B#Plugin_Autoloader), but I use the auto-loading method myself.

I don't use x265, but x264 has it's own denoising. Enabling it and using enough to remove some light noise will probably help. Even if the source doesn't look noisy, give it a try. If it only removes very fine noise you're not seeing then it can't be a bad thing. You can adjust it under the Analysis tab in MeGUI's x264 encoder configuration.
http://www.chaneru.com/Roku/HLS/X264_Settings.htm#nr

Unfortunately I don't think there's really any free lunch, but I'm not an expert when it comes to tweaking x264, because I don't need to use a low bitrate like do you. And personally, I prefer to keep the encoding quality decent even if it means reducing the resolution and sacrificing a bit of detail to do it. It's better than looking at encoding artefacts, in my opinion.

That seems pretty lucid :)
by lower what values or nr would you suggest to have a decent effect , thinking of 200 , what say ?
I know I ll have to try various values on diff sources to have a general idea , but do you think 200 is a good starting point "?

[Thunderbolt8]

Im trying to use filters with megui but I have trouble determining the source, from where they are taken.

first of all, are there any important filters which will work with 32-bit version of megui only?

in general, Id like to try to use 64-bit megui and corresponding filters as much as possible. can I really use only 64-bit filters with 64-bit version of megui without any exception?

the problem I have is that there seem to be various directories, theres tools\avs, tools\avs\plugins, tool\avisynth_plugin and also the directories of ones separate avisynth+ installation (plugins+ & plugins64+). so which is the directory megui uses for all its filters? I remember it could be specified in options but apparently not any more.

mostly I try to get ffms2, lsmashsource and TIVTC to run in 64-bit mode but its all a big mess and sometimes I get an error and get told that I cannot use some various 32-bit filter with 64-bit megui etc.

another thing is there are sometimes newer versions of some filters compared to the version which comes even with the developmental update server. is there any way I can simply replace such filters without breaking anything? can I simply replace megui internal avisynth.dll (and other files) with clang version of avisynth+?

[hello_hello]

The tools\avisynth_plugin folder is the one used for plugins by MeGUI. You should be able to simply replace the plugins with newer versions.

To change AVisynth itself, you need to replace the files in the MeGUI\tools\avs and MeGUI\tools\avs\plugins folders with the newer versions (replacement Avisynth files) while MeGUI is closed. When it runs it copies those files to the appropriate directories if it's using it's own portable Avisynth.

Anything in the "installed" Avisynth plugins folder is autoloaded when Avisynth runs, including MeGUI's portable version.

I don't know what the difference is between the "installed" Avisynth+ plugins+ & plugins64+ folders. For 32 bit Avisynth+ there's two folders. One is only checked by classic Avisynth while both are checked by Avisynth+. It's probably something similar. Someone else will probably know for sure.
http://avisynth.nl/index.php/AviSynth%2B#Plugin_Autoloader

[Thunderbolt8]

are avisynth and x264 which comes along with megui 64-bit also automatically 64-bit versions? or 32-bit but they still run on 64-bit megui? so everything Id manually replace in megui 64 has to be 64-bit as well?

[hello_hello]

Even if you're using 32 bit MeGUI, I'm fairly sure on a 64 bit OS it still uses a 64 bit version of x264. I think that's what avs4x26x.exe (or something similar) is for, but I could be wrong. I assume the 64 bit MeGUI comes with a 64 bit Avisynth, but have you tried Version() in a script?

[tebasuna51]

Of course MeGUI 64 have all soft 64 bits.

MeGUI 32 have Avs+ 32 but in OS 64 uses also x264/x265 64 bits, now with ffmpeg like interface with Avs+ 32, before it was avs4x26x.exe like hello_hello say (ffmpeg is 1% fast in my test).

A plugin without 64 bit version is AudioLimiter.dll used to downmix audio 7.1 to 5.1 in MeGUI 32 bits.

[Lord Dredd]

@ Hello_Hello & tebasuna51 :
How can I encode a video in MEGUI using x264 or x265 using VBR ?? I am game for all methods that is 2pass , ABR, and CRF
Actually I was usin the wrong short form previously when i asked the same question . I said VFR back then , But what I wanted to ask where is the option to do a VBR 2 pass encding.

I just saw these encoding settings somewhere, what got me interested ws how on earth there is a max bitrate heding there and how on earth its showing 8k plus :O
Video

Format : AVC
Format/Info : Advanced Video Codec
Duration : 1 h 56 min
Bit rate : 865 kb/s
Maximum bit rate : 8 921 kb/s



@ Hello_Hello : using nr 100 does, help it decreases the size in a variety of videos ( tested 3 actually ) saw it do around 10% to 12% decrease .. Thats a lot but the clips were like 15min each
Will add more info after encoding some more videos with longer duration.


Thank you


EDIT :
Okay so after trying a lot i found how this is done but this refers to ffmpeg , but still want your specialist opinion if this same thing can be used in megui while doing 2pass by adding these two options in misc tab in x264 profile settings.

You can use -crf or -b:v with a maximum bit rate by specifying both -maxrate and -bufsize:

ffmpeg -i input -c:v libx264 -crf 23 -maxrate 1M -bufsize 2M output.mp4

[tebasuna51]

@ Hello_Hello & tebasuna51 :
How can I encode a video in MEGUI using x264 or x265 using VBR ?? I am game for all methods that is 2pass , ABR, and CRF
Actually I was usin the wrong short form previously when i asked the same question . I said VFR back then , But what I wanted to ask where is the option to do a VBR 2 pass encding.

OK now. You can obtain VariableBitRate with 2pass or Constant Rate Factor (CRF).

Also ABR is not exactly ConstantBitRate, is AverageBitRate.
There are I, P and B-frames you can't use the same bitrate for all frames, let's the encoder do the job.

[Lord Dredd]

OK now. You can obtain VariableBitRate with 2pass or Constant Rate Factor (CRF).



Also ABR is not exactly ConstantBitRate, is AverageBitRate.

There are I, P and B-frames you can't use the same bitrate for all frames, let's the encoder do the job.No I was asking if that can be used but unfortunately those commands are fir ffmpeg only.

Can you tell me how can one encode using VBR

[tebasuna51]

...how on earth there is a max bitrate heding there and how on earth its showing 8k plus...

Some parts can need this bitrate.
A bitrate 8k can be a standard average bitrate for a 1080p movie.

What do you think about this encode:
Codec ID : V_MPEG4/ISO/AVC
Bit rate : 11,1 Mb/s
Width : 720 píxeles
Height : 572 píxeles
Frame rate : 50,000 FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Writing library : x264 core 159 r2991 1771b55
Encoding settings : ... crf=18.0 ...

Is a deinterlace (QTGMC for that 50 fps) of a dificult miniDV tape from my holidays (longtime ago): 11,1 Mb/s for a 720x572

Some parts need high bitrates.

EDIT: x264/x265 always encode VBR

[Lord Dredd]

Some parts can need this bitrate.
A bitrate 8k can be a standard average bitrate for a 1080p movie.

What do you think about this encode:
Codec ID : V_MPEG4/ISO/AVC
Bit rate : 11,1 Mb/s
Width : 720 píxeles
Height : 572 píxeles
Frame rate : 50,000 FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Writing library : x264 core 159 r2991 1771b55
Encoding settings : ... crf=18.0 ...

Is a deinterlace (QTGMC for that 50 fps) of a dificult miniDV tape from my holidays (longtime ago): 11,1 Mb/s for a 720x572

Some parts need high bitrates.

EDIT: x264/x265 always encode VBRThat should look great.
If all my MEGUI encoders done using x264 or x265 have VBR on by default
Then Why doesnt my mediinfo shows maximum bitrate like that example showed???

Sent via x266 [emoji12]

[tebasuna51]

Then Why doesnt my mediinfo shows maximum bitrate like that example showed???

MediaInfo can't examine the full video stream to search the max bitrate, it only show data stored in the tracks header.

Then the encoder or muxer of that video have store the maximum bitrate used. It is not standard.

If you use MkvToolNix to mux and you don't --disable-track-statistics-tags you grab some metadata about video:
Video: BPS-eng = 11066469
DURATION-eng = 00:07:33.600000000
NUMBER_OF_FRAMES-eng = 22680
NUMBER_OF_BYTES-eng = 627468799
_STATISTICS_WRITING_APP-eng = mkvmerge v45.0.0 ('Heaven in Pennies') 64-bit
_STATISTICS_WRITING_DATE_UTC-eng = 2020-05-25 17:07:43
_STATISTICS_TAGS-eng = BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES

with this data you have the average bitrate (BPS or NUMBER_OF_BYTES/DURATION) but unknow the max bitrate.

[Lord Dredd]

MediaInfo can't examine the full video stream to search the max bitrate, it only show data stored in the tracks header.

Then the encoder or muxer of that video have store the maximum bitrate used. It is not standard.

If you use MkvToolNix to mux and you don't --disable-track-statistics-tags you grab some metadata about video:
Video: BPS-eng = 11066469
DURATION-eng = 00:07:33.600000000
NUMBER_OF_FRAMES-eng = 22680
NUMBER_OF_BYTES-eng = 627468799
_STATISTICS_WRITING_APP-eng = mkvmerge v45.0.0 ('Heaven in Pennies') 64-bit
_STATISTICS_WRITING_DATE_UTC-eng = 2020-05-25 17:07:43
_STATISTICS_TAGS-eng = BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES

with this data you have the average bitrate (BPS or NUMBER_OF_BYTES/DURATION) but unknow the max bitrate.

Hi
Sorry for the late reply mate
I guess I ll have to devote more time in understaning the finer nuisances of parameters and all.
On a side note

Would you kindly enlighten me about when and how one should use

vbv_maxrate
vbv_bufsize

I guess they do the same thing as those ffmprg commands but I was wondering how to use these if suppose I am gonna use a slower or very slow profile to encode in 2 pass or crf.

But then If VBR is what both x264 and x265 encode with then may be these are not used anymore ???

[LigH]

VBV parameters are important when the player with a limited decoding buffer has to read from a medium with limited read speed, in contrast to a PC reading from a local harddisk with generous RAM and read speed.

That will mainly affect consumer players playing movies from an optical disc or a Flash memory stick/card, or any player (even a PC with large RAM) receiving the movie vie a network with a bandwidth close to the average bitrate.

Consumer devices and media (e.g. Blu-ray players) will have more or less publicly known specifications about their supported limits. Apart from that it may be a challenge to discover the decoding buffer capacity and the read speed...

[tebasuna51]

Would you kindly enlighten me about when and how one should use

vbv_maxrate
vbv_bufsize

I guess they do the same thing as those ffmprg commands but I was wondering how to use these if suppose I am gonna use a slower or very slow profile to encode in 2 pass or crf.

But then If VBR is what both x264 and x265 encode with then may be these are not used anymore ???

These parameters are to guarantee than you can play that encode without problems.

For instance if you store the movie with Maximum bit rate : 8 921 kb/s in a DVD (typical max read rate 5 Mb/s) you can have troubles in the points with high bitrate. But if you store the movie in a USB 2 (at least 20 Mb/s reading) all is ok.

Also related with the player to reproduce your encode, must guarantee the speed to support this max bitrate and the amount of buffer RAM (buffer size) to store the images to be decodified (related with resolution and num of ref-frames).

The easy way to control these parameters is use the parameter --level, you must know the level than your player accept. For instance a player certified to DivX Plus (--level 4.0 see Levels in this wiki (https://en.wikipedia.org/wiki/Advanced_Video_Coding)) accept --vbv-maxrate 20000 --vbv-bufsize 25000.

You can see in the x264 Configuration Dialog in MeGUI how change these parameters when you select the Target Playback Device.

Of course modern players certified for UHD accept --level 5.1 and the maxrate/bufsize are so high than you don't need to limit your encode with low resolution/bitrate.

And these parameters aren't related with the Preset (slow or other) or the Encoding Mode (crf or 2pass) like you can see in the Configuration Dialog, only with the Target Playback Device.

[Lord Dredd]

VBV parameters are important when the player with a limited decoding buffer has to read from a medium with limited read speed, in contrast to a PC reading from a local harddisk with generous RAM and read speed.

That will mainly affect consumer players playing movies from an optical disc or a Flash memory stick/card, or any player (even a PC with large RAM) receiving the movie vie a network with a bandwidth close to the average bitrate.

Consumer devices and media (e.g. Blu-ray players) will have more or less publicly known specifications about their supported limits. Apart from that it may be a challenge to discover the decoding buffer capacity and the read speed...

Thanks for the explanation :)

These parameters are to guarantee than you can play that encode without problems.

For instance if you store the movie with Maximum bit rate : 8 921 kb/s in a DVD (typical max read rate 5 Mb/s) you can have troubles in the points with high bitrate. But if you store the movie in a USB 2 (at least 20 Mb/s reading) all is ok.

Also related with the player to reproduce your encode, must guarantee the speed to support this max bitrate and the amount of buffer RAM (buffer size) to store the images to be decodified (related with resolution and num of ref-frames).

The easy way to control these parameters is use the parameter --level, you must know the level than your player accept. For instance a player certified to DivX Plus (--level 4.0 see Levels in this wiki (https://en.wikipedia.org/wiki/Advanced_Video_Coding)) accept --vbv-maxrate 20000 --vbv-bufsize 25000.

You can see in the x264 Configuration Dialog in MeGUI how change these parameters when you select the Target Playback Device.

Of course modern players certified for UHD accept --level 5.1 and the maxrate/bufsize are so high than you don't need to limit your encode with low resolution/bitrate.

And these parameters aren't related with the Preset (slow or other) or the Encoding Mode (crf or 2pass) like you can see in the Configuration Dialog, only with the Target Playback Device.

Once again loads of thankies for the elaborating mate.
Now I know why a animation that I had encoded sometime back didnt play on my TV , I had used tune animation along with crf and the level came out to be 5 and I realized my TV cant play anything with level 5 :)
Thanks

[imsrk48]

Hey Guys, How can i increase a 5.1 audio channel volume using megui?

[StainlessS]

@imsrk48
https://i.postimg.cc/JtbyTNw0/normalize.jpg (https://postimg.cc/JtbyTNw0)

[LigH]

I would suggest to stay a little below 100%, because lossy compression may cause decoding >100%, a.k.a. clipping.

[StainlessS]

Ligh, think mine set at 96, that sound about OK ?

[hello_hello]

96 is a fraction more than stuff-all less than 100, when translated to dB. It's -0.35dB.
An increased peak of 1dB wouldn't be too unusual for lossy encoding, and for some reason AAC seems worse than MP3 in that respect. If you want a margin for error:

0.9 = -0.91dB
0.8 = -1.9dB
0.7 = -3.09dB

I don't know how to write the equation properly, but the dB value is the log of the percentage multiplied by 20 (where 100% = 1.0)

Have I ever heard the clipping when normalising to 100? Nope.

Of course I disproved everything I just said while trying to provide examples. The peaks didn't change all that much, and all but one was lower, but I have seen an increase of close to 2dB on rare occasions. The peaks were the result of 4 times over-sampling to obtain the true peak, rather than the sample peak.

If this is any indication though, 96 should generally be fine.

https://i.postimg.cc/VLDTL3Tm/true-peaks.jpg

PS StainlessS, I bumped into your comment here (https://forum.doom9.org/showthread.php?p=1912206#post1912206) (thanks, by the way), so I thought I'd mention, if you haven't seen it, the idea inspired me to create some more MeGUI functions. In case you're interested......
https://forum.doom9.org/showthread.php?t=181500

[StainlessS]

I dont like to go too low, especially if viewing on hand held (phone) where volume of device can sometimes be quite low,
but thank you HH.

[Lord Dredd]

Hey Guys, How can i increase a 5.1 audio channel volume using megui?
I may raise certain eyebrows but I found MEGUI wanting in audio encoding, no matter wht I did I always ended up encoding a low volume aac file ..
after many months I moved to pazera (http://www.pazera-software.com/products/audio-extractor/)
It raises volume upto three times and its pretty efficient in encoding AAC , AC3 , MP3 ans a whole lot of other .. give it a go
Converting your 5.1 audio file to 5.1 ac3 9 mimimum would be 256 but 384 sounds very very good and aint big at all ]with volume slider all the way to right will surprise you.

=======================================

@ tebasuna51 and Hello_Hello
I am still not able to fine a way to display maximum bit-rate in a megui encoded video.

Also what are you guyz's thoughts about ABR encoding , 2 pass takes the most time but you know what you are doing , CRF well you cant really predict the size.. but I find CRF method to be pretty faster as its single pass..
DO you guys think its better to use ABR considering its 1 pass ( so less time ) plus you can predict the file size as well ??

What about the quality, will it be similar to 2pass for a given bitrate ??
I am again talking about bitrates in the range of 1500 to 2000 only ...

Also I know one should always keep thread count to 0/auto.. but to maximize CPU usage if there are no other bottlenecks, how many threads I can input just to make sure that maximum cpu is used while encoding..

Thank you

[tebasuna51]

I may raise certain eyebrows but I found MEGUI wanting in audio encoding, no matter wht I did I always ended up encoding a low volume aac file ..
after many months I moved to pazera
It raises volume upto three times and its pretty efficient in encoding AAC , AC3 , MP3 ans a whole lot of other .. give it a go
From Pazera web:
3rd party software
To encode the video and audio files the program uses the FFmpeg encoder (ffmpeg.org).

With MeGUI you can do the same, select the proper settings.

I am still not able to fine a way to display maximum bit-rate in a megui encoded video.
For what yo need know this?

DO you guys think its better to use ABR considering its 1 pass ( so less time ) plus you can predict the file size as well ??

Nope, use always crf.

What about the quality, will it be similar to 2pass for a given bitrate ??

Yes

Also I know one should always keep thread count to 0/auto.. but to maximize CPU usage if there are no other bottlenecks, how many threads

Let Auto

[hello_hello]

I may raise certain eyebrows but I found MEGUI wanting in audio encoding, no matter wht I did I always ended up encoding a low volume aac file ..
after many months I moved to pazera (http://www.pazera-software.com/products/audio-extractor/)
It raises volume upto three times and its pretty efficient in encoding AAC , AC3 , MP3 ans a whole lot of other .. give it a go
Converting your 5.1 audio file to 5.1 ac3 9 mimimum would be 256 but 384 sounds very very good and aint big at all ]with volume slider all the way to right will surprise you.

That bothers me a little because increasing the volume with Pazera doesn't seem to offer any clipping protection if you increase it too much. Do you use the Normalise option when converting with MeGUI?

My little comparisons were for a 5.1ch file downmixed to stereo, because without normalisation that's when you can notice a fair volume drop, because the volume should be lowered enough when downmixing so when the channels are combined they can't exceed maximum, even if the individual channels all happen to be at maximum at the same time.

Pazera simply downmixed and increased the volume with ffmpeg like this:
-c:a pcm_s16le -ac 2 -af volume=3.00
Without the volume adjustment, it's just this:
-c:a pcm_s16le -ac 2

MeGUI would be slower if you normalise, because it requires two passes. One to check the peak levels, then a second to adjust the volume and encode.

I assume ffmpeg uses a slightly different formula for downmixng than MeGUI, and I use a downmix formula using foobar2000 that's slightly different again, hence the average volumes being different in the screenshot below.
I assume ffmpeg has a method for normalising the peaks to 0dB, but Pazera doesn't seem to offer the option in the GUI.

Pazera 1x - Standard ffmpeg downmix.
MeGUI No Normalise - Standard MeGUI downmix without normalisation.
Foobar2000 Downmix Prevent Clipping - same as "MeGUI No Normalise" but using a different downmix formula.
Pazera 3x - Standard ffmpeg downmix plus Volume=3.
MeGUI Peak Normalise 95 Percent - Standard MeGUI downmix with peak normalisation set to 95%.
Foobar2000 Downmix - downmixed without reducing the volume to prevent the possibility of clipping. In this case there wasn't any.
Pazera 3x Foobar2000 Downmix - I used Pazera to re-encode the "Foobar2000 Downmix" file above while increasing the volume 3x. The average volume increased by around 10dB but the peaks were already just under maximum, so I assume they were clipped pretty hard.

If you're cranking the volume while re-encoding 5.1ch audio (without downmixing), I think you're very likely to cause the peaks to be clipped. It'd be no different to re-encoding stereo audio with peaks already at or close to 0dB, while cranking the volume.
The Track Gain column is a ReplayGain thing. You can ignore it. The Volume and Peak columns show the average and peak levels according to an EBU R128 scan, which is what I was interested in.

https://i.postimg.cc/QNfn7TBv/Volume-Comparison.jpg

https://i.postimg.cc/P5ntg9tW/Volume-3x.jpg

@ tebasuna51 and Hello_Hello
I am still not able to fine a way to display maximum bit-rate in a megui encoded video.

None of my encodes display it. Maybe it's something written by ffmpeg or a particular build of x264.

Also what are you guyz's thoughts about ABR encoding , 2 pass takes the most time but you know what you are doing , CRF well you cant really predict the size.. but I find CRF method to be pretty faster as its single pass..
DO you guys think its better to use ABR considering its 1 pass ( so less time ) plus you can predict the file size as well ??

Don't even consider contemplating the possibility of using ABR encoding. The encoder starts encoding and adjusts the quality to hit the target bitrate as it goes, because all it can do is guess. Find a shortish sample with a complex picture (and lots of movement) and encode them both at the same low bitrate using 2 pass and ABR and you should see the difference.
x264's rate control methods (https://forum.videohelp.com/threads/381668-would-it-make-more-sense-to-use-1-pass-encoding-instead-of-2-with-x265#post2470457)

Also I know one should always keep thread count to 0/auto.. but to maximize CPU usage if there are no other bottlenecks, how many threads I can input just to make sure that maximum cpu is used while encoding.

If memory serves, the default of zero means the thread count is 1.5x the number of CPU cores.

[Lord Dredd]

Thanks a bunch T :)
Take care Bud
Stay safe

EDIT :
To make the first pass faster i have set FFMS Thread count to 0 without any crashes , issues or stuff
Hope thats okay..

EDIT02 : Totally missed your post @ Hello_Hello
many thanks , But i used pazera to convert very high bitrate 5.1 ac3 audio to 2 channel aac audio.
and sometimes 5.1 high bitrate ac3 to 5.1 384kbps ac3

EDIT03 :
I read your post that you linked @Hello_Hello , TBH I would always want to encode the videos ( whenever my encoding bug starts to bite ;) ) using CRF only..
I had started with a number of my DVDs ( a few years back ;) ) and after converting a few i kept all the raw files in a HDD to experiment later , by the time Blurays got cheaper and once a tried a BR too.though my system needs a update as far as the ardware is concerned.

but the crux is I saw huge huge files when there was grain in the source video, crf gave big files and i stayed with 2 pass..
TBH even now I wonder about a simple degrain filter of avisynth coz I just cant get myself to use those complex filters lol

Same is with sharpening and denoising
I am experimenting with what you told about using the x264 inbuilt noise reducer and I am sure this will prove utterly helpful..
will be trying sharpen() filer only coz the videos that I am working on were professionally made, and then filtered, edited and made into a final copy by an office mate who is a specialist..

I am trying to hammer em a bit more just for the heck of it, you always learn new things by looking at professional material.

[Lord Dredd]

That bothers me a little because increasing the volume with Pazera doesn't seem to offer any clipping protection if you increase it too much. Do you use the Normalise option when converting with MeGUI?

My little comparisons were for a 5.1ch file downmixed to stereo, because without normalisation that's when you can notice a fair volume drop, because the volume should be lowered enough when downmixing so when the channels are combined they can't exceed maximum, even if the individual channels all happen to be at maximum at the same time.

Pazera simply downmixed and increased the volume with ffmpeg like this:
-c:a pcm_s16le -ac 2 -af volume=3.00
Without the volume adjustment, it's just this:
-c:a pcm_s16le -ac 2

MeGUI would be slower if you normalise, because it requires two passes. One to check the peak levels, then a second to adjust the volume and encode.

I assume ffmpeg uses a slightly different formula for downmixng than MeGUI, and I use a downmix formula using foobar2000 that's slightly different again, hence the average volumes being different in the screenshot below.
I assume ffmpeg has a method for normalising the peaks to 0dB, but Pazera doesn't seem to offer the option in the GUI.

Pazera 1x - Standard ffmpeg downmix.
MeGUI No Normalise - Standard MeGUI downmix without normalisation.
Foobar2000 Downmix Prevent Clipping - same as "MeGUI No Normalise" but using a different downmix formula.
Pazera 3x - Standard ffmpeg downmix plus Volume=3.
MeGUI Peak Normalise 95 Percent - Standard MeGUI downmix with peak normalisation set to 95%.
Foobar2000 Downmix - downmixed without reducing the volume to prevent the possibility of clipping. In this case there wasn't any.
Pazera 3x Foobar2000 Downmix - I used Pazera to re-encode the "Foobar2000 Downmix" file above while increasing the volume 3x. The average volume increased by around 10dB but the peaks were already just under maximum, so I assume they were clipped pretty hard.

If you're cranking the volume while re-encoding 5.1ch audio (without downmixing), I think you're very likely to cause the peaks to be clipped. It'd be no different to re-encoding stereo audio with peaks already at or close to 0dB, while cranking the volume.
The Track Gain column is a ReplayGain thing. You can ignore it. The Volume and Peak columns show the average and peak levels according to an EBU R128 scan, which is what I was interested in.

https://i.postimg.cc/QNfn7TBv/Volume-Comparison.jpg

https://i.postimg.cc/P5ntg9tW/Volume-3x.jpg



None of my encodes display it. Maybe it's something written by ffmpeg or a particular build of x264.



Don't even consider contemplating the possibility of using ABR encoding. The encoder starts encoding and adjusts the quality to hit the target bitrate as it goes, because all it can do is guess. Find a shortish sample with a complex picture (and lots of movement) and encode them both at the same low bitrate using 2 pass and ABR and you should see the difference.
x264's rate control methods (https://forum.videohelp.com/threads/381668-would-it-make-more-sense-to-use-1-pass-encoding-instead-of-2-with-x265#post2470457)



If memory serves, the default of zero means the thread count is 1.5x the number of CPU cores.



Yes I always used to use normalize option when I used to downmix 5.1 to stereo 128kbps HE or LC AAC.

You may be right about me cranking up the volume levels in pazera , BUt I ll be honest I found the audio much m,uch better on both my LG and Panasonic TVs , But yet to listen to this audio with my soundbar and home theater ( long story ;) lock down has put off a lot of repair works )

But I am game if you could guide me about which options to choose and which boxes to tick while downmixing a 5.1 DD to a 2 channel stereo & also converting a 5.1 AC3 DD or ATmos to 384kbps DD


===============

Apart from a few questions asked above I had some more queries about MEGUI
just yesterday I found a profile zip from 3 or may be 4 years back and in that qpmin was set to 10 and qpmax was set to 51
But in MEGUI x264 profiles they have been changed to 0 and 81 ( 69) actually whats your opinion : for lower , low and average bitrates x264 encodes what should be the values , are there some other settings as well in SLOWER profile apart from --nr that you guys feel should be changed to have better results.

whats your view of ref frames and bframes ( wrt slower profiles ) , some people advocate cranking them up a bit more especially bframes especially for low bitrate videos ???

This is a mediainfo detail of a 200MB video
I was surprised how a 200MB video of this much duration have bitrate that high.. This is some a friend of mine sent to me this morning, I have asked him to share the video as well but I dunno... I could make out its been encoded using Medium x265 profile with a crf of 23.5 but its totally beyond my understanding, Either this video has fabke info added to it or may be there is some secret recipe...


Format/Info : High Efficiency Video Coding
Format profile : Main@L4@Main
Codec ID : V_MPEGH/ISO/HEVC
Duration : 42 min 28 s
Bit rate : 8 007 kb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Bits/(Pixel*Frame) : 0.161
Stream size : 2.38 GiB
Writing library : x265 2.5+9-fdf39a97ecb8:[Linux][GCC 6.4.0][64 bit] 8bit+10bit+12bit
Encoding settings : cpuid=1050111 / frame-threads=3 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=1920x1080 / interlace=0 / total-frames=0 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=3 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=23 / keyint=250 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=20 / lookahead-slices=6 / scenecut=40 / no-intra-refresh / ctu=64 / min-cu-size=8 / no-rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=0 / dynamic-rd=0.00 / no-ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / strong-intra-smoothing / max-merge=2 / limit-refs=3 / no-limit-modes / me=1 / subme=2 / merange=57 / temporal-mvp / weightp / no-weightb / no-analyze-src-pics / deblock=0:0 / sao / no-sao-non-deblock / rd=3 / no-early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=0.00 / no-rd-refine / analysis-reuse-mode=0 / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=23.5 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / ipratio=1.40 / pbratio=1.30 / aq-mode=1 / aq-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / no-const-vbv / sar=1 / overscan=0 / videoformat=5 / range=0 / colorprim=2 / transfer=2 / colormatrix=2 / chromaloc=0 / display-window=0 / max-cll=0,0 / min-luma=0 / max-luma=255 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / opt-qp-pps / opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / no-aq-motion / no-hdr / no-hdr-opt / no-dhdr10-opt / analysis-reuse-level=5 / scale-factor=0 / refine-intra=0 / refine-inter=0 / refine-mv=0 / no-limit-sao / ctu-info=0
Default : Yes
Forced : No

[hello_hello]

Lord Dredd,
When it comes to being able to hear everything without the loud parts being stupidly loud, I'd recommend trying the Dynamic Audio Normalizer. I use my PC as a media player so I downmix and compress the audio as it's being played (via ffdshow and a WinAmp plugin), but for the TV in another room I generally downmix to stereo and compress with the DAN.

A relativity easy way to try it (hopefully) is to download the portable version of foobar2000 I uploaded here (https://forum.doom9.org/showthread.php?p=1908807#post1908807). You'll also need ffmpeg. There's a text file with some instructions included. Once you're done you can load an audio file into a playlist, right click, select convert, and a list of my conversion presets will pop up. One is called "Downmix and Compression - Dynamic Audio Normalizer" or something similar. Select that preset and the output will be AAC. It's not overly high bitrate as I generally use it to create a temporary copy of the audio for watching in another room, but it's easy enough to edit/create a preset with higher bitrate AAC.

If you want to hear what it does, there's a zip file attached to this post (https://forum.doom9.org/showthread.php?p=1911061#post1911061) with some samples nobody bothered listening to. I was trying to show how much better it is than the method the OP was using. The idea is to compare the level of the speech at the beginning with the level of the loud stuff at the end. Ideally the loud stuff stays at the same volume while the quiet stuff gets louder. The audio in the zip file with the DAN settings I use is called "f=150 b=1.flac". There's another DAN example included using someone else's settings for comparison, although I prefer mine.

Edit: Thinking about it, Pazera lets you add stuff to the ffmpeg command line. Use it to downmix to stereo and add the following to the custom command line section. Leave the volume at 1x.
-af dynaudnorm=f=150:b=1
I haven't tested it, but it should work. I assume if you convert to AAC, Pazera uses ffmpeg to encode. The difference between doing it that way and my foobar2000 preset, is my preset uses ffmpeg to compress with the DAN, but it pipes the audio to QAAC for the actual encoding (and I probably downmix to stereo a little differently).
It'd possibly also work if you add it to the custom command line section for the formats where MeGUI uses ffmpeg for encoding, but if you do, don't enable peak normalising, or at least try it with and without.

I can't offer much of an opinion on qpmin/qpmax as I never play with them.

In theory, a higher number of reference and B frames should increase the possibility of compressing more for a given bitrate, but as a rule I just use the slow or slower preset and the number of reference and B frames that preset uses. How effective increasing the number of ref and B frames is, probably also depends on the motion estimation algorithm being used. I'm not much of an x264 tweaker but under x264's standard error stream in the MeGUI log file, there's information on reference and B frame usage.

ref P L0: 60.3% 16.9% 15.4% 3.5% 3.4% 0.4% 0.0%
ref B L0: 93.8% 4.7% 1.1% 0.4%
ref B L1: 99.0% 1.0%

I can't remember how to interpret it properly but the above was the result of the MeGUI command line below. Someone else may be able to explain it, but the way I remember it is if the numbers at the end of each line are zero or very close to it, you're into wasting CPU cycles territory if you increase the number of ref/B frames further.

"C:\Program Files\MeGUI\tools\x264\x264.exe" --level 4.1 --preset slow --tune film --crf 18.0 --min-keyint 25 --b-adapt 2 --vbv-bufsize 50000 --vbv-maxrate 50000 --me umh --stitchable --colormatrix bt470bg --sar 1:1 --frames 36931 --output "D:\0111.mkv.mkv" "D:\0111.mkv.avs"

According to MediaInfo your example isn't 200MB. Maybe you looked at the size of the audio stream by mistake.

Stream size : 2.38 GiB

[tebasuna51]

...for lower , low and average bitrates x264 encodes what should be the values , are there some other settings as well in SLOWER profile apart from --nr that you guys feel should be changed to have better results.

Nothing, please let the defaults than developers select for each profile.
Do you think than there are somebody than know better the encoder than the developers?

Select crf, preset, Target Playback device and encode.

Modify defaults can work ok for a movie but bad for another.
Don't exist miracle settings, let defaults.

whats your view of ref frames and bframes ( wrt slower profiles ) , some people advocate cranking them up a bit more especially bframes especially for low bitrate videos ???

Select preset VeriSlow (8 bframes, 16 ref-frames) or Placebo (16 bframes, 16 ref-frames)

Some playback devices can't support many bframes/ref-frames, don't forget the --level parameter.

[tebasuna51]

ref P L0: 60.3% 16.9% 15.4% 3.5% 3.4% 0.4% 0.0%
ref B L0: 93.8% 4.7% 1.1% 0.4%
ref B L1: 99.0% 1.0%

I can't remember how to interpret it properly but the above was the result of the MeGUI command line below. Someone else may be able to explain it, but the way I remember it is if the numbers at the end of each line are zero or very close to it, you're into wasting CPU cycles territory if you increase the number of ref/B frames further.

Preset slow implies --ref 5 and --weightp 2 is the default, then:

ref P L0: 60.3% of P frames have 1 reference
16.9% of P frames have 2 references
15.4% of P frames have 3 references
3.5% of P frames have 4 references
3.4% of P frames have 5 references
0.4% of P frames have 6 references
0.0% of P frames have 7 references (weightp 2 accept 2 more than the limit of --ref 5)

ref B L0: 93.8% of B frames have 1 back reference
4.7% of B frames have 2 back references
1.1% of B frames have 3 back references
0.4% of B frames have 4 back references

ref B L1: 99.0% of B frames have 1 forward reference
1.0% of B frames have 2 forward references

The % of B frames with 4 ref is very low, if the encode is a 1080p can't have 5 ref with --level 4.1 --vbv-bufsize 50000

Like you say search for more ref is waste the time.

[hello_hello]

Awesome tebasuna51. Thanks!

Edit: Looking again I picked a SD encode to use as an example, but at least we know what it all means now.

[Lord Dredd]

Thanks a lot for the insight again @ Hello_Hello :)
Will try and do the downmixing first then. as far as that stream size goes , I think the encoder has removed real info and added source info to the video. This is actually what the video mediainfo shows.

@ tebasuna51 : Indeed the developers know best , I donno 0.00000000001% TBH , Hence I keep lurking here time and again :)
I dont think I ll ever use any other preset than SLOWER, ever
As advised gonna stick to what the devs have pointed :)


One thing thats still a mystery to me is why all x265 encoded videos via MEGUI are cooler in color, do we need to tweak something or add something to the commandline to keep the colors similar to the source ..
Thanks

[hello_hello]

The x265 thing might be a rec.601 vs rec.709 vs rec.2020 issue.
https://en.wikipedia.org/wiki/Rec._601
https://en.wikipedia.org/wiki/Rec._709
https://en.wikipedia.org/wiki/Rec._2020

YV12 has to be converted to RGB on playback for display, and SD, HD and UHD use different formulas. It's more likely the player is making an assumption based on resolution and that's why the colors look different. Or the video card's drivers are borked. What's the resolution of the source and encode?
YV12 sources should just be decompressed and re-encoded as YV12 without a conversion to RGB and back (unless you're converting to RGB in a script for a filter that requires it), so re-encoding itself shouldn't change the colors, unless you downscale or upscale. For example, a SD source would usually be converted to RGB on playback using rec.601, but if you upscale to HD the player will probably use rec.709 instead, so you either need to convert the colors or set the correct colorimetry in the encoder configuration.
The difference between rec.601 and rec.709 isn't huge, but rec.2020 is a lot different.

The x264 encoder configuration offers the ability to write the correct colorimetry info via the GUI. It appears the x265 encoder configuration doesn't yet.

Did you have a listen to the samples of audio dynamic rage compression I linked to?

[Lord Dredd]

The x265 thing might be a rec.601 vs rec.709 vs rec.2020 issue.
https://en.wikipedia.org/wiki/Rec._601
https://en.wikipedia.org/wiki/Rec._709
https://en.wikipedia.org/wiki/Rec._2020

YV12 has to be converted to RGB on playback for display, and SD, HD and UHD use different formulas. It's more likely the player is making an assumption based on resolution and that's why the colors look different. Or the video card's drivers are borked. What's the resolution of the source and encode?
YV12 sources should just be decompressed and re-encoded as YV12 without a conversion to RGB and back (unless you're converting to RGB in a script for a filter that requires it), so re-encoding itself shouldn't change the colors, unless you downscale or upscale. For example, a SD source would usually be converted to RGB on playback using rec.601, but if you upscale to HD the player will probably use rec.709 instead, so you either need to convert the colors or set the correct colorimetry in the encoder configuration.
The difference between rec.601 and rec.709 isn't huge, but rec.2020 is a lot different.

The x264 encoder configuration offers the ability to write the correct colorimetry info via the GUI. It appears the x265 encoder configuration doesn't yet.

Did you have a listen to the samples of audio dynamic rage compression I linked to?

yes and I gotta say I found f=2000 g=23 m=15 b=1 to be most vibrant , the first three sounded alright the f=150 b=1 was also great but the other one had beefed up audio volumes so to me that sounded well.

I am not an expert and and I listened to them on my desktop speaker which is okish :)


Regarding the color so I never convert to RGB ever
AS i am these days trying on alreday converted videos so by and large all scripts use fpsnum=24000, fpsden=1001, colorspace="YUV420P8 at the end of source in avisynth..

strangely similar avisynth for a x264 video works well but when used with x265 cools the color off..
any tick you might wanna suggest to keep the colors as close to trhe original as possible.

[hello_hello]

yes and I gotta say I found to be most vibrant , the first three sounded alright the was also great but the other one had beefed up audio volumes so to me that sounded well.

I am not an expert and and I listened to them on my desktop speaker which is okish

Two of the samples were just a straight downmix (no compression) and there's one with very mild compression via Avisynth. The main difference between the two DAN samples is the speed at which it reacts to volume changes. My settings (f=150 b=1) react quite quickly, whereas the other settings (f=2000 g=23 m=15 b=1) are much slower. Both have advantages and disadvantages.

The DAN uses a kind of "window" for determining and adjusting the volume. If you compare the two samples, my settings keep the speech at much the same level throughout and the loud parts shouldn't be any louder than for a normal downmix.
For the other sample, the speech is louder at the beginning, but there's a section just before the first explosion where the volume of the speech starts to fade away, then the first explosion is probably a little louder than it was originally. I'm pretty sure that's due to the larger "window" it uses to determine volume.

The disadvantage of it reacting quickly is it can cause "volume pumping" on occasion....
Imagine a section of audio that's mostly normal speech with some light traffic noise in the background. In between people talking, where there's mostly silence, the volume of the background traffic can increase noticeably, then drop back down to a quieter level while someone talks, then get louder again where there's silence. That's the type of "volume pumping" I'm referring to.
If you use a TV with it's audio set to "night mode" there's a good chance you'll hear volume pumping for days, or just as bad, it'll sound like someone turned the volume down during a loud part, and they're slowly turning it up again while it's quiet.

Anyway.... the settings I use are what I found to give good compression, without noticeable volume pumping 99% of the time, and without being able to hear the volume being slowly adjusted to prevent volume pumping.... but it's all personal preference.


strangely similar avisynth for a x264 video works well but when used with x265 cools the color off..
any tick you might wanna suggest to keep the colors as close to trhe original as possible.

I can't think why x264 and x265 should look different when all else is equal, unless it's a playback issue. Someone else may have a better idea as I never use x265.

By the way, I know MeGUI automatically adds frame rate conversion to the script for ffms2, but don't use it unless the source is variable frame rate and you want to convert to a constant frame rate, in which case MeGUI will probably pick the wrong frame rate to convert to anyway.
Even if the specified frame rate is exactly the same as the source frame rate (in which case it should do nothing) it can still, on occasion, cause frames to be dropped and duplicated when they don't need to be and make the encode look "jittery". I'm talking about this:
fpsnum=24000, fpsden=1001
Unless you're converting the frame rate, delete it from the script.

[Lord Dredd]

Two of the samples were just a straight downmix (no compression) and there's one with very mild compression via Avisynth. The main difference between the two DAN samples is the speed at which it reacts to volume changes. My settings (f=150 b=1) react quite quickly, whereas the other settings (f=2000 g=23 m=15 b=1) are much slower. Both have advantages and disadvantages.

The DAN uses a kind of "window" for determining and adjusting the volume. If you compare the two samples, my settings keep the speech at much the same level throughout and the loud parts shouldn't be any louder than for a normal downmix.
For the other sample, the speech is louder at the beginning, but there's a section just before the first explosion where the volume of the speech starts to fade away, then the first explosion is probably a little louder than it was originally. I'm pretty sure that's due to the larger "window" it uses to determine volume.

The disadvantage of it reacting quickly is it can cause "volume pumping" on occasion....
Imagine a section of audio that's mostly normal speech with some light traffic noise in the background. In between people talking, where there's mostly silence, the volume of the background traffic can increase noticeably, then drop back down to a quieter level while someone talks, then get louder again where there's silence. That's the type of "volume pumping" I'm referring to.
If you use a TV with it's audio set to "night mode" there's a good chance you'll hear volume pumping for days, or just as bad, it'll sound like someone turned the volume down during a loud part, and they're slowly turning it up again while it's quiet.

Anyway.... the settings I use are what I found to give good compression, without noticeable volume pumping 99% of the time, and without being able to hear the volume being slowly adjusted to prevent volume pumping.... but it's all personal preference.
I think i had spoken too soon , you are correct the one that had your own settings was indeed most balanced .. I listened to them on my TV separately .. could you kindly gimme steps how i can use similar settings which improves the volume but propotionaley , in megui
Ac3 to ac3 and ac3 to aac - both higher to lower conversions as far as bitrate goes and from 5.12 ac3 to 2 ch aac



I can't think why x264 and x265 should look different when all else is equal, unless it's a playback issue. Someone else may have a better idea as I never use x265.

By the way, I know MeGUI automatically adds frame rate conversion to the script for ffms2, but don't use it unless the source is variable frame rate and you want to convert to a constant frame rate, in which case MeGUI will probably pick the wrong frame rate to convert to anyway.
Even if the specified frame rate is exactly the same as the source frame rate (in which case it should do nothing) it can still, on occasion, cause frames to be dropped and duplicated when they don't need to be and make the encode look "jittery". I'm talking about this:
fpsnum=24000, fpsden=1001

right , even I used to wonder their utility I dont work on frame rates and all ever .. so many thanks for pointing this out to me :)
will make a custom avisynth profile and remove these..
Unless you're converting the frame rate, delete it from the script.
one more thang that I have started adding to all my scripts is Sharpen(0.25) very light but helps as far as low bitrate hammering goes :) hope thats okay , doesn't really affect encoding speed too much[/QUOTE]

[hello_hello]

I think i had spoken too soon , you are correct the one that had your own settings was indeed most balanced .. I listened to them on my TV separately .. could you kindly gimme steps how i can use similar settings which improves the volume but propotionaley , in megui
Ac3 to ac3 and ac3 to aac - both higher to lower conversions as far as bitrate goes and from 5.12 ac3 to 2 ch aac

I haven't tested it myself, and for MeGUI it could only work for formats where ffmpeg is doing the encoding, but try the following. For both MeGUI and Pazera you'd probably want to downmix with them as you normally would while adding the DAN stuff to their custom command line sections.


Edit: Thinking about it, Pazera lets you add stuff to the ffmpeg command line. Use it to downmix to stereo and add the following to the custom command line section. Leave the volume at 1x.
-af dynaudnorm=f=150:b=1
I haven't tested it, but it should work. I assume if you convert to AAC, Pazera uses ffmpeg to encode. The difference between doing it that way and my foobar2000 preset, is my preset uses ffmpeg to compress with the DAN, but it pipes the audio to QAAC for the actual encoding (and I probably downmix to stereo a little differently).
It'd possibly also work if you add it to the custom command line section for the formats where MeGUI uses ffmpeg for encoding, but if you do, don't enable peak normalising, or at least try it with and without.

will make a custom avisynth profile and remove these.

Adding them was my idea, because I thought it'd make it easy for people to re-encode a variable frame rate source, but then the problems were discovered. The frame rate conversion was removed for Lsmash but not ffms2.
If you index with ffms2 I don't think you can stop MeGUI adding the frame rate stuff, but you can create a custom avisynth profile to remove it. Have a look here:
https://forum.videohelp.com/threads/397225-MeGui-How-to-get-path-name-of-current-file-in-the-queue-dynamically#post2583330
Or here's a version without the unnecessary stuff added for the OP of that thread. Of course if you don't index with ffms2 it'll prevent MeGUI opening the video and probably give you errors (Damn! I just had a thought for creating a template that'd do the following but still let you index with another source. I'll try it later and see if it works). This one doesn't include any colorspace conversion but you can add that to the FFVideoSource line if you want to.

Edit: Updated version of the template in this post (https://forum.doom9.org/showthread.php?t=105920&page=454).

InputString = """<input>"""

No1 = FindStr(InputString, "FFVideoSource") + 15
No2 = FindStr(InputString, "cachefile")
No3 = FindStr(InputString, "ffindex")
File = MidStr(InputString, No1, No2-No1-3)
CFile = MidStr(InputString, No2+11, No3-No2-4)

FFVideoSource(File, cachefile=CFile)
<deinterlace>
<crop>
<denoise>
<resize>

one more thang that I have started adding to all my scripts is Sharpen(0.25) very light but helps as far as low bitrate hammering goes :) hope thats okay , doesn't really affect encoding speed too much

I can't say I've used it much as I generally use LSFMod for sharpening, but if it's fast and you like it, why not?

[hello_hello]

will make a custom avisynth profile and remove these.

A template that'd work for any indexer is so obvious... in hindsight... I feel a little "special" for not having thought of it already. :)
The number of times I've deleted the frame rate stuff from the script, changed something in the script creator, had to delete it again, changed something, deleted....

This should remove the frame rate conversion stuff for FFVideoSource while leaving any other source filter untouched.
It includes colorspace="YUV420P8", but of course that's optional (just manually add or remove it). As is the LoadPlugin line for FFVideoSource. I have ffms2.dll auto-loading <edit> but I extracted the path for it and I'm pretty sure it works.

Edit: Updated version of the template and function below in this post (https://forum.doom9.org/showthread.php?t=105920&page=454).

InputString = """<input>"""
SomeNumber = FindStr(InputString, "FFVideoSource")
(SomeNumber == 0) ? Eval(InputString) : Eval("""
No1 = SomeNumber + 15
No2 = FindStr(InputString, "cachefile")
No3 = FindStr(InputString, "ffindex")
File = MidStr(InputString, No1, No2-No1-3)
CFile = MidStr(InputString, No2+11, No3-No2-4)
Plugged = MidStr(InputString, 13, SomeNumber-17)
LoadPlugin(Plugged)
FFVideoSource(File, cachefile=CFile, colorspace="YUV420P8")
""")
<deinterlace>
<crop>
<denoise>
<resize>

And thinking about it again, it turns into a function pretty easily, to make for neater Avisynth templates.

As a function:
function MeGUISource(string InputString)
{
SomeNumber = FindStr(InputString, "FFVideoSource")
(SomeNumber == 0) ? Eval(InputString) : Eval("""
No1 = SomeNumber + 15
No2 = FindStr(InputString, "cachefile")
No3 = FindStr(InputString, "ffindex")
File = MidStr(InputString, No1, No2-No1-3)
CFile = MidStr(InputString, No2+11, No3-No2-4)
Plugged = MidStr(InputString, 13, SomeNumber-17)
LoadPlugin(Plugged)
FFVideoSource(File, cachefile=CFile, colorspace="YUV420P8")
""")
}

Template:
Import("MeGUISource.avsi") # or auto-load it
MeGUISource("""<input>""")
<deinterlace>
<crop>
<denoise>
<resize>

[Lord Dredd]

A template that'd work for any indexer is so obvious... in hindsight... I feel a little "special" for not having thought of it already. :)
The numbers of times I deleted the frame rate stuff from the script, changed something in the script creator, had to delete it again, changed something, deleted....

This should remove the frame rate conversion stuff for FFVideoSource while leaving any other source filter untouched.

InputString = """<input>"""
SomeNumber = FindStr(InputString, "FFVideoSource")
(SomeNumber == 0) ? Eval(InputString) : Eval("""
No1 = SomeNumber + 15
No2 = FindStr(InputString, "cachefile")
No3 = FindStr(InputString, "ffindex")
File = MidStr(InputString, No1, No2-No1-3)
CFile = MidStr(InputString, No2+11, No3-No2-4)
FFVideoSource(File, cachefile=CFile)
""")
<deinterlace>
<crop>
<denoise>
<resize>

Actually the thing is , because FFMSIndex scans the file faster and does it pretty quickly I used to avoid using L-Smash-Works to index the source ;)
Since you pointed out I have moved back to L-Smash-Works now and it doesnt add those fps and stuff :)

[hello_hello]

The speed increase is probably because MeGUI can tell ffms2 to only index the video. Lsmash indexes video and audio. The bigger the source file, the longer Lsmash takes relative to ffms2. At least it used to, but apparently the latest version can be told to only index the video, however I don't know if MeGUI has been updated for that yet. I haven't updated MeGUI myself for a while and the newer Lsmash won't work on XP anyway.

[Lord Dredd]

The speed increase is probably because MeGUI can tell ffms2 to only index the video. Lsmash indexes video and audio. The bigger the source file, the longer Lsmash takes relative to ffms2. At least it used to, but apparently the latest version can be told to only index the video, however I don't know if MeGUI has been updated for that yet. I haven't updated MeGUI myself for a while and the newer Lsmash won't work on XP anyway.

That would be great , TBH Lsmash takes roughly 4x the time that FFMS takes ( even now , i always use stable servers to update megui and keep checking for the updates ).

But the amount of time that Lsmash takes is painfully higher ....
and the script loading takes extra time if made via Lsmash :(

[HOB]

"Runtime Files" update - Error?

When I start the latest version of MeGUI - 2924 - it tells me there are updates available but when I click to see what the update info is I get the following regarding "Runtime Files":

Update Local Version 5 Server Version 4 Local Date 5/24/2020 Server Date 5/1/2020

Very clearly the update is an OLDER version of the Runtime Files so my question is should I update anyway or just ignore this particular update? It occurred to me the NEW Version 5 may have issues so it correctly wants to go BACK to Version 4...could this be the case?

Thanks.

[hello_hello]

....
and the script loading takes extra time if made via Lsmash :(

Yeah, that probably annoys me the most.
I haven't done much encoding since creating the function a few posts ago, but I've been using it without any issue so far, so maybe give it a try if you prefer ffms2.

[Lord Dredd]

Yeah, that probably annoys me the most.
I haven't done much encoding since creating the function a few posts ago, but I've been using it without any issue so far, so maybe give it a try if you prefer ffms2.
So all i need to do is add these in my final avisynth script ofcourse then I ll have to manually edit the script for adding the input and all

Is there no way to automate
or I can just remove those frame strings from my own script in the nd before hitting ok

[hello_hello]

So all i need to do is add these in my final avisynth script of course then I ll have to manually edit the script for adding the input and all

Is there no way to automate
or I can just remove those frame strings from my own script in the nd before hitting ok

The whole point of the function is to automate removing the frame rate stuff, but yes you can just delete it manually before saving the script instead of using the function/template.

Edit 1: I discovered today that if the index file is saved to the same folder as the source file, MeGUI doesn't add the cachefile argument to the script, which breaks the function and template I originally posted, so I've edited the post to update them to fix the problem. I didn't bother updating the screenshots though.

Edit 2: And another edit, as the Edit #1 fix broke the function/template for file names and paths containing a comma.

To use the function version, create an AVS Profile (template) using the following MeGUISource function.

function MeGUISource(string InputString) {

SomeNumber = FindStr(InputString, "FFVideoSource")

(SomeNumber == 0) ? Eval(InputString) : Eval("""

No1 = SomeNumber + 15
No2 = FindStr(InputString, "cachefile=")
No3 = FindStr(InputString, "fpsnum=")
File = (No2 > 0) ? MidStr(InputString, No1, No2-No1-3) : MidStr(InputString, No1, No3-No1-3)
CFile = (No2 > 0) ? MidStr(InputString, No2+11, No3-No2-14) : ""
Plugged = MidStr(InputString, 13, SomeNumber-17)

LoadPlugin(Plugged)
FFVideoSource(File, cachefile=CFile, threads=1, colorspace="YUV420P8") """) }

# The line above decodes the video for ffms2.
# The colorspace and thread arguments need to be removed or changed manually.
# The function doesn't automatically extract them even if MeGUI adds them to the script.

Import("MeGUISource.avsi") # or auto-load it
MeGUISource("""<input>""")
<deinterlace>
<crop>
<denoise>
<resize>

MeGUI will still add the frame rate stuff to the script when it creates one, but the MeGUISource function will remove it and output the video. You need to add the color format conversion argument to the new FFVideoSource line in the function yourself if you want to include it (but it's already added for the function I posted). You can confirm the frame rate stuff is being removed by changing it manually and refreshing the preview. The frame rate/count won't change.

If you don't want to Import the function in a template or auto-load it, use the long version below. Either way, only the FFVideoSource line is changed and the input line for other source filters is untouched.
What they do for FFVideoSource, is convert the input line into a string, extract the plugin path and file name etc, then create a new LoadPlugin line and a new FFVideoSource line without the frame rate conversion.

InputString = """<input>"""
SomeNumber = FindStr(InputString, "FFVideoSource")
(SomeNumber == 0) ? Eval(InputString) : Eval("""
No1 = SomeNumber + 15
No2 = FindStr(InputString, "cachefile=")
No3 = FindStr(InputString, "fpsnum=")
File = (No2 > 0) ? MidStr(InputString, No1, No2-No1-3) : MidStr(InputString, No1, No3-No1-3)
CFile = (No2 > 0) ? MidStr(InputString, No2+11, No3-No2-14) : ""
Plugged = MidStr(InputString, 13, SomeNumber-17)

LoadPlugin(Plugged)
FFVideoSource(File, cachefile=CFile, threads=1, colorspace="YUV420P8") """)
# The line above decodes the video for ffms2.
# The colorspace and thread arguments need to be removed or changed manually.
# The template doesn't automatically extract them even if MeGUI adds them to the script
<deinterlace>
<crop>
<denoise>
<resize>

Thumbnails
https://i.postimg.cc/WqrtLpJ6/template1.jpg (https://postimg.cc/WqrtLpJ6) https://i.postimg.cc/Pp0NRvN5/template2.jpg (https://postimg.cc/Pp0NRvN5)

By the way, after indexing with ffms2 you can see what's happening by adding something like this to the end of a script using the template (for other source filters they'll result in an error message). It'll only work for the long template, not the template using the MeGUISource function.

subtitle(Plugged) # will display the LoadPlugin path as a subtitle
or
subtitle(File) # will display the path to the source file as a subtitle
or
subtitle(CFile) # will display the path to the cache file as a subtitle (if there is one).