18 November 2009

Msi installer will bombardier your registry

MSI installer has important benefit over standard .exe setup files.
taken from http://repository.windowsdream.com/updater/why_msi.html

* You are sure to find an entry on Add/Remove programs, in the Control Panel.
* What has been installed will be uninstalled, and only this. This means that if the MSI created a C:\MyDir\ folder, copied a Myfile.exe inside, and if afterwards you added a C:\MyDir\Myconfig.ini file, at the uninstall process, everything will disappear, except the Myconfig.ini file. This is clean.
* The install/uninstall process is even more clever. It makes use of a counter. So, if a registry key is used by 4 applications, and you uninstall 3 of them, then the registry key will remain... until you uninstall the 4th application.
* There's a repair mode, which operates automatically in case one key file has been deleted.
* Shared ini files are never overwritten. Instead, they are read, and appended or modified. When uninstalling, the ini files are restored to what they were before the installation of the MSI.
* No DLL conflict to fear.
* Upgrades from a version to a newer one can be done easily.
* And many more similar features.

But if you ever track down an installation process using MSI, in most case you will know that list of files that need to be uninstalled later and other huge redundant file information are stored inside registry.

Just imagine if a package contain 1200 files and then you stored it in deep/long directory name (like C:\Program files\The Registry Killer Company\Let me fill the registry Apps\) and also if inside that folder installer put 5-level directory, I'm pretty sure it will add some megabytes to registry...
Now make it 5 installation of such, and how much megabytes wasted for that? Why don't relocate it to log files?


And you know the rest what to be happened if registry is too big.

07 November 2009

Finding files with FTP search engine

Many ftp sites, especially that have anonymous access rarely being indexed by google. It's kind of old fashioned mode of filesharing which have minimal role for commercial purpose. A true direct mode... not the waiting link (cough.. direct link..) we seen today, says rapidshit and friends

Recently I find ftp search engine that still survived: http://proisk.ru (other is gegereka.com), a slow but extensive (probably excessive) ftp search engine. This is really great deal alternative that offer direct as well as parallel and resumable download. The sites itself is not compatible with Opera or at least I found its best for Firefox.

02 November 2009

Put x264 and Vorbis in sync (VirtualDub)

Among audiophiles, vorbis is the best choice for midrange to very low bitrates format for lossy audio compression. Beside its opensource, what could be better than that. AAC which is later came with giant corporate support (noticeable Apple) have quickly embraced more widely than vorbis. Without become audio professional you will barely notice that at very low bitrates, ogg vorbis was unbeatable in fidelity.

This fame however not equally accepted by video enthusiast. Though the standart has periodically shift toward x264 (an Open Source implementation of H264) and leaving xvid/divx (H263 family) in the dust. The choice for audio was still held by trashy mp3/mp2, thanks for its MPEG video legacy. But why not x264+Vorbis?

I have an anime movies to give it a try and I use VirtualDub here instead of Mediacoder. Before telling you why not mediacoder, I want to tell the quirks of VirtualDub. One of VirtualDub main forte is it act as video capture tool at very beginning. I have use it extensively with my poor webcam to enhance the image quality by utilised VirtualDub's excellent real-time noise reduction. Lucky enough both best video and audio compression is available in VfW and ACM though vorbis version is very outdated. Now this VfW architecture is VirtualDub's quirks as a technology that has no future at least for non-real-time processing. VirtualDub could optionaly use directShow filter too... yeah remind me the era of ffdshow's chaos yikes.

Now, I could say that I don't even care what the A/V format is as long as it played on MPlayer and probably in my DVD player box.

Why not mediacoder then? because: it can't mux any video format with vorbis correctly. I tired of finding the right encoder/decoder/muxer combination. The symptom might not obvious at first but its there. The produced video may look no good even at first sight as audio will mostly delayed, so it should be fixed by put negative delay on the audio right? No. The video will ooks insync but if you keep watch carefully just about few minutes you may notice that audio is gradually loose sync then fluctuated sometime it get insync again. This is bad as crap when there is a delayed dialog and the character has already changed to other char. So this is clearly not a proportional delayed audio.

Back to VirtualDub, in Audio>Compression menu you may see vorbis (if installed) has some modes:
mode1: Original stream compatible
mode2: Have independent header
mode3: Have no codebook header
mode*+: pseudo CBR

AFAIK vorbis is known for using quality-mode at default, but there is VBR too. So what is pseudo CBR? No matter, Mode1+ is the one you should choose and you probably need to resample the audio too (just get it reinitialized in case of mp3 format). Mode2 or 3 generally will render unplayable video stream. And quality based will result fluctuated delayed audio thus mplayer was unable to seek (forward rewind) the video. If after encoding with mode1+ it still out of sync, apply delay effect on it.

As for my encoding task, a HD resolution anime movie is enough with 400kbps x264(multipass) and 64kbps (minimum) Vorbis. Although 32kbps aoTuV still sound kind of convincing for dialogs.

note: I tested on VirtualDub 1.8 and 1.9