One of my favourite new products in recent months is Google Music, a new cloud-based music system which allows you to keep up to 20,000 tracks on Google’s servers. In a similar fashion to Apple’s iCloud, this music can then be accessed at any time via your Android devices or a web browser. Having used Google Music for nearly 2 months now, I absolutely love it – so much so that I’ve cancelled my Spotify subscription.

Around a year ago the media hard drive in my home server crashed, causing me to lose almost all of my digital music collection. Recently I’ve been starting to re-import my CDs so they can be uploaded to Google Music, going via my laptop. Problem is that the CD importing is happening via iTunes, and my 5-and-a-half-year-old macbook certainly isn’t as fast as it used to be – the spinning beach ball of doom regularly pops up. So why not let my home server take the strain? Pop in a CD, let the server automatically rip it and eject when it’s done, and have that new music automatically uploaded to Google. That’s entirely possible on a headless Debian server.

My starting point was a blog post which deals with ripping CDs on a headless server using ivman to listen for an audio CD being inserted and abcde for ripping. However, I later discovered that ivman has effectively been abandoned and has since been replaced by halevt.

Installation

In order to encode into MP3 format, you’ll need the LAME library which is in Debian Squeeze’s Backports library. Add the following line to /etc/apt/sources.list:

deb http://backports.debian.org/debian-backports squeeze-backports main

Once that’s done, you’ll need to update the aptitude library and install halevt, abcde and lame.

# aptitude update
# aptitude install halevt abcde lame

There will be a number of dependencies that will also need to be installed, but aptitude will handle this automatically.

Detecting with halevt

Halevt will be used to listen for when a CD will be inserted. When an audio CD is detected it will execute abcde with the parameters we’ll configure later. At the bottom of /etc/halevt/halevt.xml before the final closing tag, add this:

<halevt:Device match="hal.volume.disc.has_audio = true">
    <halevt:Insertion exec="abcde >> /home/<username>/path/to/logfile.log">
</halevt:Device>

This listens for an audio CD on any device, and when that CD is inserted calls abcde and logs the output to a log file in my home area.

One gotcha you will need to deal with at this point is permissions. The halevt daemon normally runs as its own user and group, which is fine in most circumstances. However, since halevt will be running another program which will need write access to my music directory and read access to the CD ROM drive, this will cause permission errors. To get around this I changed the user and group which halevt runs as by editing /etc/default/halevt, replacing <username> with the username of your linux account:

# Default settings for halevt initscript
 
# Set this to yes if you want the halevt init-script to start a system-wide daemon
START_DAEMON=yes
 
# Run halevt has user/group
HALEVT_USER=<username>
HALEVT_GROUP=cdrom

Once changed, restart halevt to bring the changes into effect.

# /etc/init.d/halevt restart

Ripping with abcde

The next step is to configure abcde to rip the CD and place the MP3 files in the music folder. Unfortunately I found that abcde didn’t like the -N (no prompts) flag from a script or from halevt directly, so I had to configure everything I needed from the abcde config file. These are the values I changed in /etc/abcde.conf, but take time to look through the file yourself and edit it to your own needs:

# If NOSUBMIT is set to y, then abcde will never prompt asking if you
# wish to submit your edited cddb file.
NOSUBMIT=y
 
# Keep the wav files after encoding. Set it to "y" and remove "clean" from
# the list of default actions, since we purge the temp directory as default.
KEEPWAVS=n
 
# Track padding: force abcde to pad tracks using 0, so every song uses a two
# digit entry. If set to "y", even a single song encoding outputs a file like
# 01.my_song.ext
PADTRACKS=y
 
# Define if you want abcde to be non-interactive.
# Keep in mind that there is no way to deactivate it right now in the command
# line, so setting this option makes abcde to be always non-interactive.
INTERACTIVE=n
 
# If you'd like to make a default location that overrides the current
# directory for putting mp3's, uncomment this.
OUTPUTDIR=/home/<username>/music/
 
# Or if you'd just like to put the temporary .wav files somewhere else
# you can specify that here
WAVOUTPUTDIR=/tmp
 
# OUTPUTTYPE can be either "ogg", "mp3", "flac" or "spx", or a combination
# of them separated with ",": "ogg,mp3".
OUTPUTTYPE=mp3
 
# Enables nogap encoding when using the 'lame' encoder.
NOGAP=y
 
# If you'd like to have abcde eject the cdrom after all the tracks have been
# read, uncomment the following line.
EJECTCD=y

The most important flags in this list are INTERACTIVE=n, which disables any prompts, and EJECTCD=y which automatically ejects the CD on completion. Everything else is up to you.

I tested this out with two albums last night, and I’m pleased to say this method worked perfectly and the MP3 files turned up in the expected place. If you’re having any issues or if something’s changed since I wrote this piece then please leave a comment and I’ll update the article when I can.

Syncing with Google Music

The next stage for me now is to sync with Google Music, for which I’ll be using this guide as a base. I’ll update this article with my findings once I have it up and running.

Since I’m now working full time, I have a lot less time for other projects. Likewise, after spending all day staring at a screen and coding at work I have little appetite for doing more of the same on personal projects at home. As a result, all development work on RSS Alarm has been suspended. I may release free side projects onto the Google Play store in the future, but there will be no more major updates to any existing projects.

I’d like to take this opportunity to thank everyone who has downloaded RSS Alarm to date, and hope you can understand my reasons for deciding not to develop this app any further.

Michael

The good news is that my time at University is quickly drawing to a close. The even better news is that this means I can get back to working on RSS Alarm. With that, I present version 1.2.0.

The first thing you’ll probably notice is that it looks different. I’ve given the interface a cleaner, brighter look with a larger contrast between the background and the text. Those running Android 4 will also notice a few more subtle differences, as the native Action Bar and Holo UI elements are now used. Users on Android 2.2 and 2.3 will still have the old navigation style.

There’s also a few tweaks and bug fixes. The method of queueing up alarms has also been reworked to improve reliability. Now that’s out the way with, I can finally take a look at the to-do list and start adding some more features! Watch this space.

This update is currently live for the paid version only. I’ll update the free version when time allows. As ever, you can get RSS Alarm from the Google Play Store for only 99p!

Thanks!

The Experiment

A number of test participants will be presented with a series of screenshots from various Twitter accounts. Upon seeing each screenshot, the test participant will make a single yes/no choice about whether they believe the account is a genuine representation of its owner. The participant will also be given the (optional) opportunity to explain why they think that account is genuine or fake. This information will help confirm if the factors I mentioned in my most recent blog post are relevant. Each participant will receive the same list of screenshots, though the order in which the screenshots are presented will be randomised. This is to help prevent order bias.

The reason I refer to the “genuine representation” of an account as opposed to the person who operates the account is to allow for users who delegate management of their account to another person. This is normally the case for high-ranking politicians such as Barack Obama and David Cameron, the latter of whom has previously given reasons for his lack of enthusiasm towards Twitter.

I previously mentioned the factors I believe influence a Twitter user’s decision on whether a given account is genuine. Based on these beliefs, each screenshot shown to a participant will contain the Twitter account’s:

• Avatar
• Username
• Biography/description
• “Verified” icon (if appropriate)
• Location
• Personal website information
• Three sample tweets by the account

So, a participant may be shown this image as an example:

I also intend to collect some profile information from each participant (e.g. age group, gender, level of computer experience, if they are a Twitter user) to help determine if different groups of people look for different pieces of information when authenticating a Twitter account.

Implementation

As this experiment will essentially be a series of questions answered by humans, any existing survey or questionnaire software should prove sufficient for collecting the raw data. Some survey creation services also provide automatic analysis of the data, saving time when I’m making my own analysis and conclusions.

The two main services I am looking at are SurveyMonkey and Web Survey Creator. Both websites offer free accounts for creating surveys, each with a maximum of 100 respondents per survey. However, while SurveyMonkey only allows a maximum of 10 questions per survey for a free account, Web Survey Creator allows for an unlimited amount of questions. However, neither allow for questions to be given in a random order, which is something I would require.

The “roll your own” alternative is LimeSurvey, an open-source survey tool. This software offers many of the same features as an online service, but since it will be deployed to my own web hosting there will be no limits for the number of respondents or questions per survey. The documentation does not mention anything about assigning questions in a random order, so I will need to investigate this software further before making a decision on whether to use it for this experiment.

Background

For my assignment I have decided to further explore the issue of trust and what factors are most influential in helping to decide whether to believe a given Twitter account. In my project proposal, I outlined a number of possible factors a person may look at when making this decision:

• The account’s username?
• Use of a face vs. a logo in the profile picture?
• Not having a profile picture (default “egg” picture)?
• If a user’s interests or expertise is listed in their “about me” section?
• If the account has been verified by twitter (blue tick)?
• The number of other users following the account?

The issue of trust within social media is itself a very broad, with certain aspects this field having already been examined. A paper titled “Twitter under crisis: can we trust what we RT?“ by Mendoza, Poblete & Castillo studies the behaviour of Twitter uses in a emergency disaster situation and the effects that false information and rumours can have on the situation. While not directly relating to the topic I wish to cover, it does offer an insight into how much more easily people would believe rumours in a desperate situation, as well as detailing how rumours can be detected by aggregating tweets.

Another article “Interpersonal Trust: A Comparison of Attitudinal and Situational Factors” (Scott, 1980), looks more into the issues of trust between people, and the circumstances which affects this trust. I feel this would be a good help with my research, however the article is currently restricted.

The language and structure of Tweets can also be an influence in making this decision; According to Ellis, Capra & Cowcroft (“In the mood for being influential on Twitter”, 2011) “popular and influential users linguistically structure their tweets in specific ways.” Therefore any experiment to gauge the believability of given Twitter users must also contain a number of sample tweets from those users.

The Hypothesis

It is my belief that a Twitter user would be able to determine whether another account is genuine, an imitation or spam by looking at their profile picture, description (biography) and a small sample of tweets from the account. I intend to test this hypothesis by presenting a number of people with a sample number of Twitter accounts containing the above information, and asking if they believe those Twitter accounts are genuine or imitations.

Despite being less than a month into 2012, one of the year’s biggest agendas already seems to be coming to the forefront as Governments increasingly try to legislate activity on the Internet. In the past couple of weeks alone we’ve seen the rise and fall of SOPA and PIPA as well as the ratification of ACTA, which lead to the resignation of one MEP from the European Parlament.

One of the websites which seems to fly in the face of legislation the most (outside of piracy websites) is Twitter, the micro-blogging service. On a number of occasions last year Twitter users found themselves skirting the law, most notably in the case of Ryan Giggs. In that particular case Giggs had taken out a super injunction to prevent the media from commenting on an extra-marital affair, however this did not stop over 75,000 Twitter users and a Scottish Sunday newspaper from naming him, making a complete farce of UK privacy laws in the process.

But how can we ascertain that a source on Twitter is genuine? How do we know that the information it provides is genuine, or that the user him/herself is trustworthy? While the Twitter account that outed Ryan Giggs and other famous faces, one of the tweets relating to an affair between Jeremy Clarkson and Jemima Khan was later strenuously denied. The twitter account in question was a throwaway, likely to help avoid any legal repercussions, however the overall accuracy of the information helped it to gain nearly 100,000 followers.

But could any one person simply create an account, post a couple of tweets about a topic subject and gain 100,000 followers? What qualities do people look for when trying to determine if an account and/or the information posted by it is genuine or not? And how does the ability to create a throwaway twitter account cause problems for pre-Internet laws? I will be examining this question over the coming weeks and will post my research and findings on this blog.

So what next? How do I drum up some more publicity for RSS Alarm now the initial media coverage has faded away? A very difficult question for a team of developers, let alone a one-man operation. The clue to this answer is that this is version 1.1.0 of RSS Alarm, not v1.0.5. This is a major change.

After some time pondering this question, I’ve decided to release a free “lite” version of RSS Alarm. This version will be supported by banner advertisements, however I’ve been very careful to place these adverts non-intrusively. They will not get in the way of your normal usage, but will still appear prominently at either the top or bottom of the screen. The positioning of these adverts may change in future versions, but I promise not to place them in positions that seem underhand or interfere with your usage of RSS Alarm. If you’re not a fan of adverts, upgrading to the full version for 99p will also get rid of them.

For those who have purchased the full version of this application already, I’d firstly like to thank you for buying RSS Alarm, you’ve really made me smile over this past month. As a reward, not only will you copy remain ad-free for life, you’ll also get any big new features at least one version earlier than the free release. And what better time than now to give you your first reward?

Shake To Snooze is a brand new feature for those who own the paid version. Have you set your alarm a bit too early? Too tired to open your eyes? Just reach over for your phone and give it a shake, and the alarm will be postponed for 10 minutes.

So, to summarise:

• I’m releasing a free, ad-supported version of RSS Alarm
• Major new features will be exclusive to the paid version for at least one release.
• Bug fixes will be released for both versions simultaneously.
• Shake to Snooze is new and exclusive to the paid version for release v1.1.0.

• The ability to specify the amount of time between RSS Feed updates. (Main screen > MENU button > Settings)
• Alarm will be dismissed when moving away from the alarm screen (e.g. pressing the back or home key)
• All indexed podcasts will now be displayed on the Feeds screen, below the list of RSS Feeds.
• Did I mention RSS Alarm is now on Google+ and Twitter?

The update will automatically download to your phone shortly (provided you’ve allowed automatic updating), and if you don’t have RSS Alarm yet, you can buy it here.

- Fixed bug that prevented users from importing their feeds from Google Reader
- Fix bug that prevented the Text-to-Speech engine from reading out RSS feeds.

As you can see, those were problems that warranted an immediate fix, so here you go. Updates will be arriving to your phones within the hour.