It’s pretty simple, listen to the album you want to buy, click BUY, select your format (MP3, AAC, ALAC, FLAC etc…) enter you Paypal details and boom your downloading your stuff. No signing up, no messing about.

It was easy, simple, and overall a good way to buy music. I still prefer CD’s but as they offer ALAC and FLAC it’s fine and reduces wear on my CD drive.

Bought an album and an EP for £8, all FLAC so I can convert to any format I want, just good stuff.

The tool is set out in two phases, the first phase consists of the tones white, black, light gray, gray, and dark gray. These will let you spot the easy pixels, gray is nice as you’ll be able to see if the panel is evenly lit. The second phase is just an RGB test, cycles red, green, blue, yellow and magenta. This will show any pixels that are stuck in those main colours.

It’s pretty simple and a tiny download written in Java so you’ll need Java installed. Mac OS X users have the Java system by default, Windows users will need it, thats if you don’t have it already, most people do. There is a Read Me included in the download with full instructions.

Any problems / help, or if you have something to say let me know.

With this I mind I got the source code for the last of the standalone versions 1.62.3, it does everything, and doesn’t have a massive dependency problem like the recent versions. I made a small change to the source, compiled it and life is good again, much easier than compiling for 10.5 and all that bag of hurt of the older versions :)

The reason I have suddenly posted this is I have just re-compiled Streamripper for Snow Leopard using the new Clang and LLVM-GCC compilers. As all of Snow Leopards utils are in x86-64 I did Streamripper as x86-64, a few years back I never thought I’d be compiling Streamripper as 64-Bit just seems overkill, but why not :)

I won’t bother with all the building stuff like my last post on the subject as it’s not that hard really.

Enjoy!

XCode Colours (RGB)
Selection: 167, 201, 255
Comments: 0, 116, 0
Documentation Comments: 0, 116, 0
Documentation Comments Keywords: 2, 61, 16
Strings: 196, 26, 22
Characters: 28, 0, 207
Numbers: 28, 0, 207
Keywords: 170, 13, 145
Pre-Processor Statements: 100, 56, 32
URLs: 14, 14, 225
Attributes: 131, 108, 40
Project Class Names: 63, 110, 116
Project Functions and Method Names: 38, 71, 75
Project Constants: 38, 71, 75
Project Type Names: 63, 110, 116
Project Instance Variables and Globals: 63, 110, 116

Default font: Menlo 11

The main tools are located in /usr/bin. In this folder you will find both gcc 4.0 and 4.2 along with g++ 4.0 and 4.2. The commands gcc, g++, cc, and gcov are all symbolic links to the default 4.0 versions. To make 4.2 the default we just need to modify the symbolic links.

To do this we need to go in to the Terminal and issue the following commands:

Now you should have a complete working gcc 4.2.1 tool chain. If there is a problem you can verify the symbolic links are pointing at the correct targets by typing ls -l Hope this helps someone else.

Anyway this afternoon I noticed that Safari kept using 100% CPU and becoming un responsive. I kept force quitting it but the problem kept coming back after about 10 mins. I tried the usual repair permissions, delete preferences and caches etc to no avail. I then thought I would try the Safari 4 Developer Preview, I downloaded it and installed it. It was perfectly stable and very fast, can’t wait for the finial release of that badboy! At this point I was still stumped as to why 3.2.1 was holding the CPU hostage but Safari 4 was fine. I uninstalled Safari 4 and reinstalled 3.2.1.. On restarting everything seemed fine but yet again it took all the CPU, back where I started. Just launching Safari and then closing the window and waiting would cause the CPU to be held hostage again.

I ran a filesystem trace to see what files Safari was touching, I basically sat and waited until the high CPU condition happened then took a look to see what files were accessed. After an hour of watching and timing the problem it seemed that Safari was continuously reading from the filesystem which is what was causing the massive CPU load. It was triggered by an unusual cache file hit, I did a check to see what network connections were established and saw some odd looking google server addresses, it then dawned on me that Safari 3.2 features anti-phishing protection that uses a blacklist provided by google.

This also explained why the the Safari 4 Developer Preview worked correctly as it doesn’t yet have the anti-phishing stuff. I turned off the anti-phishing stuff in Safari 3.2.1 and sure enough everything went back to normal. Me being me I was still bothered because why would it suddenly cause problems, it’s been working fine until today. I went back and took a look at the cache files it was using for the blacklists, I thought that corruption of some kind was most likely so I deleted them. I then re-enabled the anti-phishing mode in Safari 3.2.1, now been three hours and all is well again.

Relaunch Safari and all should be well. I couldn’t find any references to this problem online so I though I would post something.

Any questions or praise let me know!

Whats New:

• Completely new Javascript.
• Links checked and fixed, some removed and new ones added.
• More Update options.
• Updated looks and Phasenoise logos.
• Smaller Download

Merry Christmas!

I needed a replacement drive and looked in to the 100 gig version of the drive only to find out that it had been discontinued. I did some looking and my only real options seemed to be drives from Hitachi and Seagate, the Seagate drives were described as being much quieter so I went for the Seagate Momentus 7200.1 drive. As the model name indicates this is a 7200 rpm drive and I have noticed the speed boost.

Overall I was quite happy with the new drive apart from a loud ticking noise, I did some digging around and found out that this noise is related to the APM (Acoustic Power Management) built in to the drive, this tick that APM causes happens roughly every 20 to 30 seconds, this doesn’t sound too bad at first until you dig a little deeper, every tick and the Hard drives Load_Cycle_Count is incremented by 1, so roughly 69 Cycles an hour. The drives life span is rated at 600,000 cycles. At my current usage rate this drive isn’t gonna live too long.

Please note that this isn’t an isolated case either, this is known to Seagate and it’s not just Seagate that seam to have the problem, Toshiba drives fitted to MacBooks like Louisa’s also have high Load_Cycle_Counts Hitachi are also suffering with these problems. The cause of the problem is that the drive makers are setting the default APM values to the most aggressive value, the Operating System of the machine will normally set these values to a more moderate setting when booted up. There are however some systems that do not change these settings Mac OS X being one of them. So from this we can see there is no person that can correctly be blamed for this mess.

All I can really say is thankgod for Timemachine :) I guess I will just have to use the drive till one day in the future when it pings once too many. If your using a PowerBook, iBook, MacBook, MacBook Pro etc… then get hold of the smartmontools from sourceforge and check out your load cycles!