Rooting and modding Samsung Galaxy S2

If you just have to mess with your phone all the time and try out every option and setting, you'll probably have heard about replacing stock software with custom kernels and flashing in mods. This could expand battery life, give you new features and make your phone faster.

It can also render your latest phone investment as useful as a brick. Yeah, brick. That's what they call it when either you or some software you tried to run makes your phone shut down for good and it will never boot up again. So be warned, even though I am about to tell you how to possibly avoid it.

I DO NO TAKE RESPONSIBILITY FOR YOUR ACTIONS! YOUR PHONE IS YOUR OWN AND ANY OF THIS WILL VOID YOUR WARRANTY!

And don't try to be clever, the phone will tell your technician that you installed a custom binary. This feature is called the 'ROM counter'.

• First of all, some phones are known to have a bad FLASH chip, and this includes most versions of the Samsung Galaxy S2, from what I can read. 
• Personally I have the GT-I9100 which came with GingerBread 2.3.5. 
• If you, like me, have Samsung Kies installed (if not, do that NOW) and updated the firmware, you will discover that GingerBread 2.3.5 will be updated to Ice Cream Sandwich 4.0.4.

At this point, download the following:

• Siyah kernel - Will give you a temporary rooted phone. Get the correct version, and put it on your SD card.  (you do need an SD card)
• ClockWorkRecoveryMod (aka CWM)

There is a particular problem that seems to come with the stock ICS 4.0.4 when you install the 'clockworkrecovery' mod. Therefore, first of all you need to root your phone to be able to actually check your phone. (with Siyah)

• Heimdall Suite 1.3.2
• CyanogenMod verison 9 (aka CM)

You also want the Google Apps extras

1. At this point, you have to boot up into recovery mode, and wipe the phone and the cache. 
2. Then, load this binary into the phone. 
3. When it reboots, it will show you a yellow triangle below the Galaxy logo at bootup, and if you go to Settings->About Phone you will see that the kernel has been replaced. 
4. If you forget to wipe the cache as well, the phone will not boot. (It is not bricked, just repeat the process.)

Then download an app called eMMC checker from the Play Store. Move CM and Google Apps over to the SDcard.

1. Download eMMC Brickbug Check from Play Store
2. Run check. It will probably say 'Insane chip: Yes' and then you must check the memory, for which you need to have the phone already rooted.
3. If the memory check passes, your phone's flash chip is functioning well enough to flash the ROM, but it will still kill it of you skip to the CWM step now!

Note: Just to be clear, both the memory needs to be OK and the Siyah kernel must be installed or else you will have a dead phone before this tutorial is over.

1. Boot phone into Recovery Mode. (Home + Vol Up + Power.
2. Hold until logo appears, release keys.
3. You will be presented with the recovery menu. Some phones has alternate combinations.

Lastly:

1. Wipe and factory reset
2. Wipe cache
3. Install CM from SDcard
4. Install Apps from SDcard
5. Reboot phone

Now, when you reboot, the phone will be a completely different beast. Modded or not, the S2 and S3 are  formidable devices, featuring multi-core CPU and GPU processing, as well as standardized USB connectors, an array of special-purpose sensor chips and last, but not least, a Linux-based operating system to glue it all together. With the right add-ons installed, your phone is essentially a powerful hand-held computer that can be used for a multitude of uses. While the comparison  is not fair, I would guess an S2 outperforms 5 year old laptops.

I think this was everything. Please comment if I missed something.

Anyway, here's the result:

The new OPUS codec

I was reading a thread on Reddit about a new audio codec, and I was going to post a reply to someone who was wrong on the internet. People were talking like mp3 was going to disappear and Linux would have the year of the desktop, and I was going lash out at the naiveity, but the TFA and related sites are pretty clear on the actual purpose of this codec.

From boingboing's article:

"The IETF has finished its standardization effort for Opus, a new free/open audio codec that reportedly outperforms all other codecs on all axes."

Obviously wary about a huge claim like that, I had to dig a bit. From IETF's abstract:

"This document describes the Opus codec, designed for interactive speech and audio transmission over the Internet."

Audio enthusiast site HydrogenAudio does real testing of digitally treated audio and supposedly has demonstrated that all existing formats encoded at over 128kbps yield inconclusive results in double-blind testing and so OPUS is apparently untested in that area.

OPUS focuses on low latency in the 64-96kbps@48k range, which makes this a decent option for for large-scale network streaming, exactly like the project claims. Encoding one single stream at that quality is not even noticeable on modern CPU, and this codec is not primarily for high fidelity listening even though the authors claims it can be used for music up to 512kbps@48k. It's designed to deal with network latency and packet drops.

Now, what got me thinking was that since HA does not even test files over 128kbps, yet I have often been able to recognize them when I had higher qualities available.

I was wondering what kind of demography HA did this test on. Was it musicians, producers and the like or was it a random group? It matters because if you work a lot with sound and music, you will eventually be able to identify a low bitrate song

This post by IgorC on is interesting and got me questioning the testing procedure. They are operating with sample sizes around 30 and 40, which I think is small, and considering the facts about subjects IgorC points out, maybe the grounds for a claim to beat every other codec on the planet is a bit high at this time. Even the authors does not claim that their fresh 1.0.1 release competes with the best implementations of other codecs out there

Testing

A ~50MB .wav file (Metallica,'Figth Fire With Fire') was encoded to FLAC level 8 and it took 7 seconds with flac.exe trough Traders Little Helper.

Encoding the .wav to mp3 with 128kbps@44100 took 22.2 seconds with the latest VLC. For 48000khz, about 32 seconds. That is just the default settings, no encoder options. The output mp3 was about 4.5MB.

Using winLame 2010 with LAME 3.99 and "-V2 --vbr-new" took 7 seconds, and 10 with the best compression "-b 320 --cbr". The 7-second output mp3 was 11.1MB.

Then it was time to try out the OPUS encoder, which still is a CLI only app.

OPUS with default setting produced a file of 3.4MB running at 94kbps in 6 seconds.

Using OPUS with --bitrate 256 produced a 8.5MB file with 255.6kbps bitrate in 7 seconds.


That would be about the same speed as FLAC, if you can even compare these two, since FLAC produces lossless quality at nearly 1Mbit bitrate, nearly triple as much data troughput as OPUS.

I further tried --96, and --128 and they use the same amount of time, around 6-7 seconds.
Streaming

Using rtp via VLC, streaming the first 128kbps mp3 encoded from an instance of VLC to another on the same host takes between 0 to 1 % in the encoding thread, and you can't even tell that the playback thread uses CPU time.

The 11MB maximum-encoded mp3 file was then streamed, at almost the same CPU usage as the file nearly 1/3 as big. Occasional spikes to 2%, but mostly 0% and 1%.

I am inconclusive about streaming, since VLC doesn't support OPUS yet, but it seems to me that all three formats hoovers around 1% for decoding.

Conclusion

From these simple tests, I have to conclude that OPUS is much slower to encode than recent FLAC and LAME releases at the moment. LAME and FLAC used about 30% and 37% CPU respectively while encoding, but OPUS used around 24%.

Playing back the OPUS file using the official CLI tools showed that the process doesn't even cross 1% to decode. FooBar2000 added support already, and shows a 1-2% CPU usage.

If this new codec can help huge organizations save bandwidth and CPU cycles, then good for them. It's irrelevant to end users not trapped in ISDN-land, but it may be a cost-saver if you are big inside the streaming industry.

Ofcourse, it's always nice to have more royalty-free codecs, but mp3 will be around a lot longer. And just to be clear, OPUS has already gotten attention from patent trolls, although the project claims these threats are groundless.(Qualcom and Huawei)
Further reading about audio:

XIPH.org explains why it's no point in being audiophile.

Removing and installing Widcomm drivers

Trying to cut down on my heavy headset casualty record, I needed something wireless. I got Teknikmagasinet's custom BT500 headset. My 1-2 year old Targus Bluetooth USB mini dongle would not run handsfree audio correctly under the supplied Vista drivers. Even Windows 7 pointed me to new drivers available from Broadcom, so I downloaded these drivers. This software complains about old BlueTooth software already installed, only problem is there was no uninstaller. Uninstalling drivers from device manager did not do it. After some testing, I found this to work:

On another Win7 box:

1. Disable automatic driver updates
2. Insert dongle 
3. Answer no to install WHQ drivers
4. Wait until all the USB discovering is over... could take a minute or two. (does not depend on your computer speed!)
5. Install SE software
6. Answer yes to all drivers from here on
7. I had to cancel and reinsert dongle during device verification
8. Copy Users/User/Appdate/Widcomm/Software to target machine

On target machine:

1. Repeat steps 1-4
2. Install retail drivers
3. Install software from other box

I ended up having an unknown defect device in the device manager but everything works. So it appears the old 64 bit drivers from Vista works, only the software itself needed to be upgraded. Choosing this approach was better than a system reinstall, and not even 1 hour in regedit would let me hack my way out of the Widcomm registry mess.