Using avisynth's 'amplify' function

[jagabo]

__film = last
__t0 = __film.trim(42593, 47278)
__t0

Do you realize the net effect of that in the context of your script is the same as :

trim(42593, 47278)

If you plan on concatenating multiple trims it would be much clearer to write:

__t0 = trim(...)
__t1 = trim(...)
__t2 = trim(...)

__t0++__t1++__t2

And remember, you are trimming the video after changing the frame rate (QTGMC, SRestore) so the frame numbers you use should be the frame numbers after the rate change, not the frame numbers of the source video.

[pooksahib]

Hi LigH.de. I agree your 'code block' looks nice but I'm concentrating more on getting the script to work first.

You say my script could be reduced. Every command seems necessary, in my view, but I'd be interested to learn what you'd do with it.

I've tested Amplify(0.15) on my TV and the volume is just fine.

My problem was getting the above script to work with AVS Cutter and I seem to have found the cause. The DVD has two audio sources (different languages) and, despite me choosing just one of them at the File Indexer stage, I could not find a way to get a working video clip. I tried the script on a DVD with one audio track – success. Then I used avidemux to make a 30 minute clip from the first DVD with one audio track and using AVS Cutter on it worked.

In summary, MeGUI's AVS Cutter does not like DVDs with multiple audio tracks.

I now need to make a copy of the DVD with a single audio track. I can think of a couple of ways to do this but which would you guys suggest? I have PGCDemux installed but I'm not sure of the various options e.g. which of the three Modes would I use...

Thanks for listening to me.

[pooksahib]

Hi jagabo, I didn't see your post there. The trim command was generated for me by AVS Cutter and, yes, it was done after all the filters had been accounted for. Thanks for the layout tip, though.

[LigH.de]

To reduce content of an already completely ripped DVD (e.g. as image in a virtual DVD drive, maybe also as whole VIDEO_TS folder), you could use DVD Shrink to author a new DVD and import only the wanted streams out of the main movie PGC from your rip.

Or you could use your favourite DVD ripper (e.g. DVD Decrypter) in "IFO mode", enable stream processing, and set up the video stream and one audio stream to be either both demultiplexed as raw streams, or written as continuous "PGC VOB" without the usual 1 GB segmentation. I guess PGCDemux could do something similar from a ripped whole VIDEO_TS folder.

[hello_hello]

I haven't read through the whole thread but MeGUI doesn't have problems with multiple audio streams. I think the problem might be you're not using the AVS Cutter as intended. MeGUI pretty much always creates a script to encode the video and a script or scripts to encode the audio. They're never combined into a single script, but the system still works. If you're wanting to create scripts with MeGUI and use them with other programs that might be a different story, but for MeGUI......

Open the source video with the file indexer and index it. If it's a DVD MeGUI will use DGIndex to extract the audio. It doesn't matter if there's 1 audio stream or 27. As long as you have them all selected, they'll all be extracted when indexing, and they all should be loaded into the audio section under individual tabs (if there's more than one stream), so you can treat them differently when encoding.
If you're opening a source file for which the file indexer can't extract the audio, it'll create a script for each audio stream instead and load them into the audio section.

Create your script for encoding the video. Save it and use the AVS cutter to add the cuts. Make sure you save a "cuts file". The AVS Cutter has a "do everything" button, which will add the cuts to the script, save the cuts file, and close the AVS Cutter. It doesn't matter if you're adding a single cut to a script or 45 of them. The cuts file will ensure the audio matches the video if used correctly.

The area in the audio section between where the source file is loaded and where the audio output is specified is where the cuts file needs to be loaded so the audio is re-encoded to match the video. If there's more than one audio tab because there's more than one audio stream you might have to load the cuts file for each one (I can't remember), but MeGUI will re-encode one audio stream to match the video or it'll re-encode 12 of them.

If you don't want to re-encode the audio there's an Audio Cutter under the Tools menu. Each audio stream can be loaded into it, along with the cuts file, and MeGUI will slice them up and splice them back together as required to give you an audio stream or streams that'll match the encoded video. Cutting that way is not millisecond accurate as it is when re-encoding, due to the limitations of audio cutting, so while there's a potential for a small error with each cut it's too small to cause a noticeable audio de-sync and for multiple cuts they generally average out so it's not an issue.

For the volume thing..... turning the volume down by a specific amount is kind of unusual, but MeGUI's audio encoder configuration has an option labelled "normalise peaks to". It's probably set to maximum by default (100%) but assuming the volume you wish to reduce is already at maximum, try enabling that option and setting it to 50%. It might take a little trial and error to get it right but you can adjust the volume that way. Each audio stream can be encoded with different settings or even with a different encoder, or not re-encoded at all..... whatever you want.

If you need a script to encode the audio and you're not sure how to create it, one trick is to set up an audio encoding job with MeGUI, start it running, abort it, and then pinch the script MeGUI created from the log file, modifying it if need be. I do that now and then so I don't have to think.

If you really want to balance audio volume, ReplayGain or 128Gain (similar versions of the same concept) are the way to go. They can be used to adjust different audio files so they sound the same in volume. Unfortunately it hasn't really been embraced by video encoder GUIs as yet, which is why I use foobar2000 for most of my audio encoding, but that's a whole other story.

Tip: The cuts file is just a text file. You can open it with Notepad. If you happen to add cuts to a script and want to change a start frame here or an end frame there, you can simply change the frame numbers in the cuts file as you would for Trim() in the script.
MeGUI uses the frame numbers and frame rate listed in the cuts file to calculate where to start and stop encoding the audio, so you can change the frames in a script if you change them in the cuts file to match, but don't mess with the frame rate after the cuts file has been created. That'd probably be a recipe for considerable unpleasantness.

[hello_hello]

Sorry guys, I need your help again. For this encode, I'm not doing the whole DVD in one go but as a collection of scenes. After creating the script, I launched AVS Cutter. I created a 'Cuts File' and put it in the Cuts section of the Audio Input. The resultant file is silent although both mediainfo and avidemux tell me there's mp3 audio. Very odd. I tried again without loading the cuts file and there IS now audio but it's from another part of the DVD.

I suspect I need to reword the 'film=last' section. Can anyone assist? Thanks again.

LoadPlugin("E:\MeGUI port\tools\avisynth_plugin\NicAudio.dll")
# Set DAR in encoder to 4 : 3. The following line is for automatic signalling
global MeGUI_darx = 4
global MeGUI_dary = 3
LoadPlugin("E:\MeGUI port\tools\dgindex\DGDecode.dll")
LoadPlugin("E:\MeGUI port\tools\avisynth_plugin\ColorMatrix.dll")
video = DGDecode_mpeg2source("E:\tommy.d2v", info=3)
audio = NicAC3Source("E:\tommy\VTS_01_1 T80 2_0ch 192Kbps DELAY 0ms.ac3")
AudioDub(video,audio)
Amplify(0.15)
ColorMatrix(hints=true, threads=0)
crop(6, 0, -12, 0)
ColorYUV(off_u=26, off_v=-4)
QTGMC()
SRestore()

__film = last
__t0 = __film.trim(42593, 47278)
__t0

The 'film=last' section is fine. It's just the way MeGUI adds trims to a script.

Is the script above the one you used for audio encoding too? If so and you also loaded a cuts file into MeGUI's audio section I'm not sure how you wouldn't end up with a mess.

As an example, say your script is set to encode these frames using trim:

# First part of script omitted
ColorMatrix(hints=true, threads=0)
crop(6, 0, -12, 0)
ColorYUV(off_u=26, off_v=-4)
QTGMC()
SRestore()
trim(42593, 47278)

Then you added another trim to the script:

# First part of script omitted
ColorMatrix(hints=true, threads=0)
crop(6, 0, -12, 0)
ColorYUV(off_u=26, off_v=-4)
QTGMC()
SRestore()
trim(42593, 47278)
trim(0,50)

For the video encoding, I think you'd end up with 50 frames, only they'd be frames 42953 to 43002.

Now apply that same theory to a single trim in the script, loaded into the audio section, then effectively adding the same trim again courtesy of the cuts file, and......

Why you've ended up encoding the wrong section of audio when you didn't use the cuts file..... well if you used that script it might have something to do with all the filtering the audio section wasn't really designed to deal with. In theory it possibly could work, but in practice you probably should be loading the source audio into the audio section along with an appropriate cuts file to match the video edits, or a script that just opens the entire audio stream (and changes the volume).... along with a cuts file to match the video edits.

[pooksahib]

Hello hello_hello, good to hear from you and thanks, sincerely, for all that effort you've just gone to.

I've only just now found out why my cuts had unrelated audio – in the preview window, the movie is timed at 1hr32min but the ac3 file generated is 1hr42min. What I don't know is why that's happened. I'd say that the trailers have something to do with it. Perhaps I'm missing a BUP or an IFO which has subsequently caused MeGUI to mishandle the files...

I've tried various configurations of the 'Normalize' box but audio volume was always the same. I've also done tests on a different DVD with a view to getting Amplify to work. I simply put 'Amplify(0.2)' into the basic script (no fancy filters). Volume stayed the same. I then changed the script by loading the NicAudio.ll and adding:
video = DGDecode_mpeg2source("E:\tommy.d2v", info=3)
audio = NicAC3Source("E:\tommy\VTS_01_1 T80 2_0ch 192Kbps DELAY 0ms.ac3")
AudioDub(video,audio)

Again, volume remained unchanged. It's all extremely weird because I've had a successful test before. The fact that I can't replicate it means that, unless we can spot a flaw in my actions, I'm probably going to resort to Wavepad/avidemux after I've done all the picture repairing.

As regards the Amplify function, do you believe it necessary to load NicAudio as described above? For myself (no expert, remember!) if the basic script created after the File Indexer process can cut audio, surely it can do other things with it...

[pooksahib]

hello_hello once said about a rogue file “I couldn't let it win”. That's now how I feel about the Amplify() function. I've been trying to get it to work using scripts without any other filters to get in the way. I've used the very simplest script:

LoadPlugin("E:\MeGUI port\tools\dgindex\DGDecode.dll")
DGDecode_mpeg2source("E:\mel.d2v")
Amplify(0.2)

And a script using NicAudio:

LoadPlugin("E:\MeGUI port\tools\avisynth_plugin\NicAudio.dll")
LoadPlugin("E:\MeGUI port\tools\dgindex\DGDecode.dll")
video = DGDecode_mpeg2source("E:\mel.d2v")
audio = NicAC3Source("E:\mel T80 2_0ch 384Kbps DELAY 0ms")
AudioDub(video,audio)
Amplify(0.2)

I've run each script twice – with and without the 'Normalize Peaks to 100' box ticked. As you can see, no success. Even the smallest of the new waveforms are slightly higher than the original.

I've attached the clip for anyone who has the time and inclination to have a go producing a working script. If you do, you have my thanks.

[LigH.de]

So how did you decode the "original" script? Which decoder was used in your "reference"? And why did it decrease the volume unnecessarily? And how much?

I wonder if that decoder used the very pessimistic approach to decoding AC3: It may have up to 6 channels, and each of them may have 100% volume at the same time, so let's divide the sum of all channels by 6 (1/6 ~ 0.166...). A certainly wrong calculation for a 2-channel source. And even for a 6-channel source, there are much more reasonable assumptions (e.g. assuming phase differences in surround effects, a division by √6 is almost safe).

By the way: Your "simplest" script loads no audio track, therefore it outputs silence. I don't know where your audio output comes from in this case. Possibly the auto-generated audio script which cannot be found outside MeGUI (except in its log file).

[hello_hello]

I demuxed the audio from your sample, loaded it into the audio section and set the encoder to normalize peaks to 50%. The encoded audio was quieter than the original. From the log file, this is the script MeGUI created to encode the audio (behind the scenes).

LoadPlugin("C:\Program Files\MeGUI\tools\avisynth_plugin\NicAudio.dll")
NicAc3Source("D:\mel T80 2_0ch 384Kbps DELAY 0ms.ac3")
# detected channels: 2 channels
# detected channel positions: 2/0/0
Normalize(0.5)
return last

I tried again loading this script into the audio section instead of the original file:

LoadPlugin("C:\Program Files\MeGUI\tools\avisynth_plugin\NicAudio.dll")
NicAc3Source("D:\mel T80 2_0ch 384Kbps DELAY 0ms.ac3")
Amplify(0.5)
return last

When I checked the log file, the Amplify option wasn't listed because the log file only shows the imported script, not it's contents.

Import("D:\mel T80 2_0ch 384Kbps DELAY 0ms.avs")
# detected channels: 2 channels
# detected channel positions:
AudioBits(last)>24?ConvertAudioTo24bit(last):last
return last

It did work though. The encode via the script with Amplify(0.5) was quieter than the encode using Normalise (0.5) in the encoder configuration, and they were both quieter than the original. I didn't check with a cuts file loaded, but I can't imagine why that'd make a difference.

In case you're wondering about the 24 bit output, it's probably because I test encoded with FLAC the second time. For the lossy encoders it might be 32 bit float, assuming the encoder supports it.

I've only just now found out why my cuts had unrelated audio – in the preview window, the movie is timed at 1hr32min but the ac3 file generated is 1hr42min. What I don't know is why that's happened. I'd say that the trailers have something to do with it. Perhaps I'm missing a BUP or an IFO which has subsequently caused MeGUI to mishandle the files....

I can only guess. It's usually because the DVD wasn't ripped/prepared for encoding correctly. You can't just tack unrelated vob files together or randomly rename them to make a set. You've not done anything like that? They should be sequentially numbered ie:
VTS_01_1.VOB
VTS_01_2.VOB
VTS_01_3.VOB
If you have more than one set of sequentially numbered vob files and you want to combine them, I find it's easier to encode each set separately, then append the output files together. Make sure you have "stitchable" enabled in the x264 encoder configuration.
Are you sure about the video length? You can rarely believe anything a media player says about vob files, including their duration. The length of the video shown in the preview should be accurate though. MeGUI doesn't use the DVD IFO files.

As regards the Amplify function, do you believe it necessary to load NicAudio as described above? For myself (no expert, remember!) if the basic script created after the File Indexer process can cut audio, surely it can do other things with it...

Yeah, you'd need to use a script that actually opens the audio otherwise MeGUI wouldn't know what to do. MeGUI imports the script as the source audio and creates another one for encoding.
I don't know if it's just a copy and paste typo, but your script doesn't include the audio's file extension (ac3) at the end of the audio's file name. I assume it matters.

If you want to try foobar2000 for audio encoding at some stage I can help you out. It's more fun than MeGUI in one respect.... if you load multiple audio jobs foobar2000 will encode as many simultaneously as you have CPU cores until it's done. MeGUI encodes audio one at a time. And there's all that indexing.....

Foobar2000 can't do the traditional "normalise peaks to maximum" thing itself, but there's a plugin that lets it open AVISynth scripts, so you can still peak normalise with AVIsynth if you're into that sort of thing. If you use QAAC for encoding it has a peak normalising function of it's own. Foobar2000 can dowmix multichannel audio, but I'd recommend using the third party Matrix Mixer DSP rather than the built in foobar2000 downmixing DSP, because then you have total control over how audio is downmixed.

Most importantly, foobar2000 has a ReplayGain scanner. It'll scan and save the info to the files so you can adjust the volume accordingly when you encode. There's also a way way to use the ReplayGain info to do peak normalising if you really prefer it. The volume of MP3 and AAC audio can be adjusted losslessly so for those types you can encode first, scan second.

About the only thing I haven't quite worked out is how to scan multichannel audio with ReplayGain when it'll be downmixed. Well... it's easy to do, but if you downmix the audio the volume will probably change. I don't know if there's a way around that. I don't do much downmixing these days so if I do I just downmix and encode to a FLAC or wave file, scan that with ReplayGain, save the info, then re-encode to the final format while adjusting the volume. Unless the output will be MP3 or AAC because then you can encode first, scan and adjust the volume second.

Oh.... and obviously Foobar2000 can't load the cuts file, so you need to use MeGUI for that part.

[pooksahib]

Good morning hello_hello and thank you very much for all that effort. Using your method of loading a purpose-built script into Audio Input, I managed to get a low-volume file but only with 'Normalize Peaks' unticked. With it ticked, the volume is increased dramatically.

It does seem, though, that this page is completely incorrect, the Amplify() command just doesn't work as simply as they suggest:
http://avisynth.nl/index.php/Amplify

Yes, my script omitting the ac3 suffix was an error. As for the VOBs, they're untarnished so who knows why the movie and audio timed differently with MeGUI. When I demuxed using PGCDemux the audio and video were perfectly matched.

You store your portable programs in C/Program Files??

Thanks again.

[manono]

It does seem, though, that this page is completely incorrect, the Amplify() command just doesn't work as simply as they suggest:
http://avisynth.nl/index.php/Amplify

It works exactly as it says. Just don't try and do it within MeGUI. Open a simple script in a player that plays AviSynth scripts (MPC-HC is one such) and play it using different values for amplify.

A=AVISource("Movie.avi")
B=NicAC3source("Movie.ac3")
B=B.Amplify(0.2)
AudioDub(A,B)

[pooksahib]

Good point, I didn't consider it could be merely a compatibility issue.

[hello_hello]

Good morning hello_hello and thank you very much for all that effort. Using your method of loading a purpose-built script into Audio Input, I managed to get a low-volume file but only with 'Normalize Peaks' unticked. With it ticked, the volume is increased dramatically.

It does seem, though, that this page is completely incorrect, the Amplify() command just doesn't work as simply as they suggest:
http://avisynth.nl/index.php/Amplify

Amplify should work as described, but it won't work with the Normalise option enabled in the audio encoder configuration.
Remember.... there'll be two scripts involved if you don't load the audio directly. The one you created for loading the audio into MeGUI (with Amplify included), and the one MeGUI creates behind the scenes for encoding, using your script as the audio source.
Your script might lower the volume with Amplify, but MeGUI's Normalise option will add the normalising to it's script, so effectively the volume is reduced by your script and then it's probably increased again. In your case the Normalising option would win because it's being applied after the Amplify option. You'd end up with the same volume as you'd get with just Normalising enabled and without Amplify being used at all.

Once you've "not let it win" it'd probably be easier to load the audio directly and use the peak normalisation in the encoder configuration to adjust the volume. Assuming the peaks are already at 100%, normalising the peaks to 50% should reduce the volume by 6dB. If they're not already at 100% the volume change might be less, or it could even increase, so it'd require a little trial and error, but you probably have to trial and error a little using Amplify too.

You store your portable programs in C/Program Files??

Yeah. I'm still use XP.

[pooksahib]

I'm delighted to say that I've just completed the first encode of the DVD with the overly high volume. As mentioned above, MeGUI gives different lengths to the video and the audio so I 'File Indexed' the m2v generated by PGCdemux**. I also used the ac3 provided by PGCdemux when creating the avs script for MeGUI's 'Audio Input'.

The script for the video is this:

global MeGUI_darx = 4
global MeGUI_dary = 3
LoadPlugin("E:\MeGUI\tools\dgindex\DGDecode.dll")
DGDecode_mpeg2source("E:\HFpgc.d2v", info=3)
LoadPlugin("E:\MeGUI\tools\avisynth_plugin\ColorMa trix.dll")
ColorMatrix(hints=true, threads=0)
Crop(6, 0, -12, 0)
ColorYUV(off_u=26, off_v=-4)
QTGMC()
SRestore()

and for the audio:

LoadPlugin("E:\MeGUI\tools\avisynth_plugin\NicAudi o.dll")
NicAc3Source("E:\HFpgc1.ac3")
Amplify(0.15)
DelayAudio(-96/1000.0)
return last

AVS Cutter is then used to make the scenes.

The output is excellent and I thank everyone in this thread especially jagabo who, in a previous thread, came up with the ColorYUV settings (I couldn't better them) and hello_hello for providing the 'final solution'. As you can see, hello_hello, I'm sticking with Amplify() rather than playing about with Normalize Peak. It seems the 'proper' way to do it. And for Gawd's sake man, get yourself a copy of Windows 7!

**Thinking about it, I don't need to Index at all, do I? As long as I include the 4:3 command, I could just say 'mpeg2source("E:\HFpgc.d2v", info=3)'.

All the best, guys.

[hello_hello]

I'm delighted to say that I've just completed the first encode of the DVD with the overly high volume. As mentioned above, MeGUI gives different lengths to the video and the audio so I 'File Indexed' the m2v generated by PGCdemux**. I also used the ac3 provided by PGCdemux when creating the avs script for MeGUI's 'Audio Input'.

I'm not sure what's going on there but it's not normal to have problems extracting audio from a properly prepared DVD.

As you can see, hello_hello, I'm sticking with Amplify() rather than playing about with Normalize Peak. It seems the 'proper' way to do it.

Neither method is correct or wrong as such. Amplify just increases or decreases the volume according to the amount you specify. Normalise adjusts the volume so the peaks are at the level you specify whether it needs to be increased or decreased, which is why it's traditionally been used to make the volume of different files "roughly" the same.

Both are the equivalent of throwing darts at a dartboard compared to ReplayGain/128Gain if you want the level of different tracks to sound the same. After scanning a file with ReplayGain you're provided with details like this (foobar2000's scanner in this case):



The level displayed for "track gain" tells you how far off the target volume you are. You don't even have to know what it is as it's an industry standard volume (there's actually two commonly used volumes, one for standard CD tracks and a slightly lower one for soundtrack audio). It also tells you what the peak volume is. From there, MP3 or AAC can be adjusted without re-encoding (with the right program). For other audio types you can automatically adjust the volume when converting.

If you want to have a play at some stage, maybe try this program. It might provide a more visual representation of how the system works, although it's dog slow compared to foobar2000's scanner. Even my old PC can scan an MP3 at about 150x "real time" if it's over-sampled for "true peak" level, and about 400x "real time" without over-sampling, and by default it'll scan four files at a time (4 core CPU).

And for Gawd's sake man, get yourself a copy of Windows 7!

How will I unzip portable programs to the program files folder then?

I've actually got a copy of Win7 buried under paperwork on my desk somewhere. I've been meaning to build a new PC for a couple of years and Win7 was intended as a stop-gap until I'm comfortable enough to dump Windows and switch to Linux.
Mind you I'd planned a new PC as soon as Skylake was released, but I've procrastinated so long now I think I might wait for the next round. Or the AMD CPUs due later this year sound promising.

**Thinking about it, I don't need to Index at all, do I? As long as I include the 4:3 command, I could just say 'mpeg2source("E:\HFpgc.d2v", info=3)'.

Well, MeGUI uses DGIndex for indexing mpeg2 as a rule, and the d2v file for opening the video is created by DGIndex.....

[LigH.de]

How will I unzip portable programs to the program files folder then?

Just not in "C:\Program files", but somewhere else. That's just the reason why they are portable – because they don't insist in being installed there and getting registered in the system.

[hello_hello]

How will I unzip portable programs to the program files folder then?

Just not in "C:\Program files", but somewhere else. That's just the reason why they are portable – because they don't insist in being installed there and getting registered in the system.

I thought it was because Microsoft decided to prevent programs from writing to the Program Files folder because they can't make their OS secure. It's probably less of "insisting they go in Program Files" and more "they don't work properly if you put them there". Unless you're using XP.

Some portable programs make use of the registry. MPC-HC can store settings in the registry or an ini file no matter where you run it from, and sometimes, despite being portable, programs still converse with the Application Data folder a little.

I think my other half has portable programs unzipped in her "User/Downloads" folder, or whatever it's called. Or sometimes not there, but somewhere else. So far though, I'm absolutely certain the number of times I've had to use Windows Search to find where a program is located on my PC is exactly zero. I don't know how often she's used it to find programs but she seems to give it a workout.

[LigH.de]

A system can hardly be both secure and convenient. Microsoft preferred convenience until heaps of malware forced them to reinvent a level of security other systems already had for ages; and right away, users started to complain about the inconvenience of the security provided by the UAC. Users of systems with an X are already used to the responsibility of executing commands in "sudo"; the UAC confirmation dialog is a bit more convenient than that, possibly even more convenient than over-protective AV suites, yet Windows users were just not used to this level of responsibility from earlier versions.

In addition, there are several levels of "application portability", from avoiding access to protected parts of the system up to running in sandbox environments. Not being installed in a UAC protected folder is a convenience workaround; the side effect is a lack of security. Alternatively, always running an application "as Administrator" to have write access to UAC protected folders is about the same level of convenience vs. security risk.

So to answer your question: Run your unzipper "as Administrator" to unpack into your "Program files" directory branch. And be responsible for all possible mistakes that may harm your system from that moment on: You are the Admin, you know what you are doing.

[hello_hello]

A system can hardly be both secure and convenient. Microsoft preferred convenience until heaps of malware forced them to reinvent a level of security other systems already had for ages; and right away, users started to complain about the inconvenience of the security provided by the UAC.

I think the average user had the balance pretty right. Nobody wanted a browser integrated into their OS. Nobody wanted ActiveX. In a short time we went from drive-by infections thanks to Microsoft thinking they could own the internet, to a massively annoying UAC that once again, nobody wanted.
Last time I used my other half's laptop I copied (or moved) a bunch of files from the laptop to a USB drive. Every single time I started the copying process, UAC asked me to confirm I wanted to copy files to my own drive, after I'd initiated the process with the built in Windows file management utility. Absolutely ridiculous. Apparently I could be malware using Explorer to move files but I can't be malware responding to UAC prompts, or however that works.

So to answer your question: Run your unzipper "as Administrator" to unpack into your "Program files" directory branch. And be responsible for all possible mistakes that may harm your system from that moment on: You are the Admin, you know what you are doing.

You lost be a little there. Are you referring to me, or XP, or putting portable programs into the Win7,8,10 program files folder?
I think it's the last one, but I'm not sure. If so, I assume running programs from the program files folder isn't the actual problem, it's having to be an administrator to put them there in the first place. Is that right? If so, I had it wrong as I thought it was the other way around.

I'm really going to miss XP.....

[LigH.de]

Yes, that was my point: To put something into an UAC protected directory branch (which "Program files" is), you need administrator rights. That's the security concept of "Windows since Vista". They had to find a way to keep malware from changing files in the default installation location, and they did that by access rights. You should not use an administrative account, to limit your user's rights to avoid harming the system, because processes started in your user account will have your user's rights to change system files.

If you work in an account with restricted rights, malware started from your account will have only restricted rights as well, so it cannot change system files – except you confirm the UAC dialog and manually allow it doing so.

That's quite the same concept as e.g. Linux offers – restricted by default: Most users don't have access rights to change system files or directory contents. To force changes in risky areas, you can use e.g. "sudo" if your user account is in the group of "sudoers".

If you complain against Windows trying to protect you against malware attacking your system, you did not understand the UAC. And you probably did not understand how conveniently you can circumvent it without disabling it: Just run processes from a privileged account; to do so, you have to manually confirm that you really want to. If you start your unzipping tool "as Administrator", the process will run with the access rights of the Administrator account and be allowed to unzip files into UAC protected directories. You may have to know the password of the Administrator account to do so, though.

If you want to run a command line unpacker with administrative access rights, you have to either start the console (cmd.exe) "as Administrator", or use third-party tools like "RunAsAdmin" which will elevate the rights of the called CLI application, provided you can confirm the UAC dialog it displays first.

Be glad that "Windows since Vista" is at least trying to protect you against malware if you use it as intended. Praising XP without the UAC means that you have to be a lot more careful not to accidentally execute malware, because it is a lot less protected, malware can change your system files a lot easier.

We are certainly off-topic now.

[hello_hello]

I sometimes wonder how computers get infected. Especially these days when you can open an email without worrying Outlook Express will infect you. I had a theory, which I seemed to confirm about 6 months ago, when I installed some software with OpenCandy crap included and I didn't think till a second after I clicked. The crap kept coming back, which finally got me motivated to format the drive and start playing with Linux, which I haven't done much of lately. I should get back to it.

I've cleaned junk off the niece and nephews PCs quite a few times. All for the same reason. Clicking without thinking. I've been running antivirus and software firewall free for something like five years now. Aside from that one hiccup it's been blissful. The odds of an antivirus program catching that one probably weren't great anyway. I don't know about UAC. Well.... obviously it can't if I disable it. I thought you probably could, but it wasn't my PC I was using at the time.

[LigH.de]

There are many infection vectors. Circumventing the UAC is only one of many. But some malware does not even need to access UAC protected directories. Already script languages (JavaScript, VBScript, ActionScript in Flash) are powerful enough to start an avalanche, and they can be started anywhere, possibly even in memory only...

And spyware in installers are a special kind of harm. You probably agreed to the UAC dialog to install wanted software and get planted unwanted software (PUPS) as well. Per definition they are not a "virus", therefore usual "anti-virus" software won't search for those, you need additional "anti-malware" products (Spybot S&D, MBAM, Threatfire...). The more, the less CPU time for your daily work...

UAC is only one factor. But it is the basic support provided by the OS. There is just one caveat: "Clicking without thinking" can circumvent it easily. As you already know painfully. But hey, "sudoing without thinking" is possible just as well.

[hello_hello]

And spyware in installers are a special kind of harm. You probably agreed to the UAC dialog to install wanted software and get planted unwanted software (PUPS) as well.

I was referring to my XP PC there. No UAC to agree to. It was still my fault though. For reasons I can't quite remember, I installed the software in question twice (maybe I discovered there was a newer version right after installing it). I bypassed the Open Candy crap the first time, but for some reason I just didn't think when re-installing. It's the only time in five years of running XP without any anti-something software or a software firewall I've been "infected" with anything. Normally that sort of stuff can be uninstalled, but this one was hiding away somewhere and re-installed itself periodically.
If I can keep XP free of infection, unless I do something stupid, and the Microsoft propaganda tells us how insecure XP is compared to newer Windows, I shouldn't need UAC. Anyway, when I eventually build a new PC, and now I've procrastinated again I might wait for the next round of CPUs, I'll try Win7 UAC for a while to see if I can warm to it.