Wednesday, March 14, 2012

Power supplies...

Have you ever asked yourself how the power supply within you computer works? How complicated it is? Or how did it develop? I never did. For me, it was a black box that takes 220V (or 110V, depending where you live) on input and produces 12V/5V on output. Basically, you don't notice that they exist, but now and then you have some problems caused by them, e.g. when they fail, or when they are not powerful enough.

Today I stumbled on this article about power supplies. I have to say that it is well research article about modern power supplies. It was motivated by Steve Jobs' claim that the power supply within Apple ][ was revolutionary and that the guy that designed it, Rod Holt, didn't get a credit for it. So, the blog's author did an extensive research and found out that Jobs wasn't right. Anyway, I recommend that you read that post, it's very good with a lots of references.

It's interesting how I came accross that post. Initially I stumbled upon a post on Hacker News about some guy that left Google and this Guy explains why. Now, there are different opinions about this topic and maybe I write about it in the future, in the mean time, I found this post about power supplies to be rather interesting.

One more thing. That guy that wrote post about power supplies also wrote a post about iPhone USB charger that he bought cheaply in eBay. What's interesting is that this charger almost certainly doesn't follow safety regulations which means that you can suffer electrical shock. So, don't save money on something that can endanger your life!

Tuesday, March 13, 2012

Downloading a password protected file from a Web page using wget...

Today I was downloading some stuff from Web, and the download speeds were unbelievably slow (i.e. criminally slow)! The most I got was somewhere around few kilobytes per second. So, it's no wonder then that they lasted for a very long time, and some of them were reported as being finished, while actually only a part of the file was downloaded. To make things even more strange, ping reported RTT times that were within usual range of values when download speeds were much higher! Anyway, I didn't have a slightest clue what was happening. Usually, in those, cases, I use wget (or curl) to fetch a file, as they are more easily controlled and have much more features that the download mechanism embedded within Firefox. The problem was that, to access those files, I had to login and the login process isn't implemented using regular HTTP mechanism, but it's part of the Web application. Needless to say, wget (nor curl) don't know how to handle this situation.

The first thing that occurred to me is that wget supports loading of cookies from Firefox browser. So, I looked into wget manual page, and there it is an option --load-cookies. The only problem is that this option expect cookies to be stored in the old textual format, while Firefox starting from version 3 uses SQLite database. So, quick googling reveled several pages, of which I looked at this one. In short, that guy wrote a shell script that exports SQLite database into text file with a format expected by wget command. But reading comments, I found even better solution! It is a plugin called cliget. When you install this plugin it attaches itself to download dialog where it shows a wget command line you can use to download selected file from a terminal window. I tried it and it works great! So that solved my problems.

Thursday, March 8, 2012

Using ffmpeg tool to recode audio files...

I'm using ffmpeg library in one simulation project to support VoIP traffic. What bothers me is that on certain input files in mp3 format I constantly received error message about format error and then simulator would segmentation fault. The output codec is g726. So, to determine if this is a bug in my code, or something is really wrong with mp3 file I decided to use ffmpeg command line tool.

It turned out that it is necessary to experiment quite a bit with this command to achieve what you want, and in my case to recode mp3 file into wav file in g726.

First, I tried with the following command:
ffmpeg -i test.mp3 test.g726
That command specifies that ffmpeg should use test.mp3 as the input file and the output should be stored in test.g726 file. But, it stopped with the following error:
[NULL @ 0x2014c60] Unable to find a suitable output format for 'test.g726'
The problem in this case is that ffmpeg tries to deduce which codec to use based on the extension of the output file. In my case this extension didn't mean anything, it was only indicator to me which codec is used. So, I used option acodec to force use of g726:
ffmpeg -i test.mp3 -acodec g726 test.g726
Still no luck, the following error message was reported:
[NULL @ 0x21aec60] Unable to find a suitable output format for 'test.g726'
but, that gave me the clue. The problem is that output file format isn't recognized! I wanted to place g726 output into WAV file, so either changing extension from g726 into wav, or using -f option will do:
ffmpeg -i test.mp3 -acodec g726 test.wav
Now I got another error message. It's good, it means I'm progressing. The error message is:
[g726 @ 0x1dad1e0] Bitrate - Samplerate combination is invalid
This time the problem is that mp3 input file has 44khz sampling rate which is not supported by g726. So, using ar option, I specified sampling rate supported by g726, i.e. 8khz:
ffmpeg -i test.mp3 -acodec g726 -ar 8k test.wav
Then, a new message appeared:
[g726 @ 0x1f511e0] Only mono is supported
Ok, this is easy too, MP3 file is in stereo, while g726 supports only mono. So, I have to choose only one channel (or stream) from input file. Digging a bit through the manual gave the answer, I should use ac option. In other words, default number of output channels is the same as input ones. By using ac options it can be changed to 1, i.e. to mono output:
ffmpeg -i lucky.mp3 -acodec g726 -ar 8k -ac 1 test.wav
This solved the previous error, but now I got a new one:
[g726 @ 0xb6b1e0] Unsupported number of bits 8
Well, this is a confusing error message because it's obvious that it wants to use 8 bits per sample, but the question is where. Also, when you look into diagnostic information you'll notice that everything is 16 bits! But then, I realized that it uses sample frequency and default bit rate to calculate bits per sample, which turns out to be 8 bits. So, by increasing sampling frequency the problem is solved:
ffmpeg -i test.mp3 -acodec g726 -ar 16k -ac 1 test.wav
Finally, I come from where I started, to check if there is an error in input file, and it turns there is not, or, it is suppresed by ffmpeg. So, the problem is in my code obviously.

Monday, March 5, 2012

Trip to Australia...

So, finally I got a chance to visit Australia. This means two things. First, I'll be posting a bit less this month while I'm not at home, and second, my posts will be related to Australia, more specifically, my impressions about Australia. And two additional things for this post:
  1. The trip to Australia is not a piece of cake. I was in USA several times, and when you compare that trip, with this one, then you can safely say it's nothing. :)
  2. I just logged into GMail and was presented with a security question. It turns out that Google monitors from which location you sign in and in case you sign in from different one, it presents you with a security question (actually, you can choose between three questions). Now, what I wonder is, is the decision to present you with a security question influenced in any way by geographic distance. And if it is, what is the formula?
So much for now. :)

About Me

scientist, consultant, security specialist, networking guy, system administrator, philosopher ;)