A few weekends ago, we were sitting on the porch wondering which of MANY Red Rocks shows we had queued up on the media center PC we were listening to at the moment when we started discussing ways to get the information about what we were listening to displayed conveniently.

A few hours later, after dismissing some ideas involving scrolling LED marquees over the cabin door, I got the idea that "Jeff's blackberry can run Google Talk. I can have the a script pull data from Amarok via its DCOP integration{1} and use XMPP to send 'Now Playing' messages" over Google Talk to the daemon's friends.

Once we had Song Change notices being sent, the natural extension was to have a two-way conversation. By the next morning we had transport and volume control integrated. A week later, I spent an hour or two adding *very basic* playlist construction support, and that was pretty much all you'd ever need.{2}

You'll need a Google Talk account, and the people who get control and notices need to be setup to chat with the Google Talk account ( I used the Gmail UI ).

Once the server has friends to chat with, fire up Amarok, fire up this script, and it'll connect to Google Talk and start notifying of song changes and accept volume, transport control, and playlist management commands.

Footnotes:

{1} Which in going to require an abstraction layer or something to accommodate Amarok 2.0's different yet still standards conforming desktop integration API.

{2} While testing, we ended up quickly adding 2 more features ( not shown). "X" will just stop what the server's doing, load a pre-set playlist and just start playing that -- for times when you just want music up, but don't have the time to construct a playlist. And a patch to return to $MUSIC_ROOT if you get confused where you are browsing for content. The playlist construction features need some work.

This is a work in progress but I've started downloading various podcasts so I can put them on my iPod.  I ran into two problems:

1. The mp3 files were not bookmarkable, which means that I had to fast forward to where I left off if I wanted to listen to something else for while.  For long podcasts, this can be very annoying!
2. My iPod can not play RealAudio files.

The requirements for make_m4b are:

• perl 5.8 or higher
• mplayer with win32codecs or native realaudio support
• faac 1.24 with libmp4v2
• mpg123

This is a variation of Ryan Hayward's code.

Yes, I know system() is bad and I will clean it up later. (I've been sick for a number of days).

$ ./ogger.pl "Filelist" "Genre" "Artist" "Album" "Encoding"
[download]

This script takes a directory name as the first argument, parses through it, outputting the artist, title, length, bitrate, filetype, and filename of each MP3 or OGG file in the directory as columns in an Excel spreadsheet (the filename of which is determined by the second argument). As a method of keeping track of progress, it adds a dot to "Processing" after every 100 entries.

Known issues: Files without tags do not work so well. Some OGG/MP3 data may not be entered in some cases, including certain types of VBR encoding ( this is a limitation of the modules used ).

Uses MP3::Info, Ogg::Vorbis::Header::PurePerl, and Spreadsheet::WriteExcel;. Tested with ActivePerl build 810.

Locates and downloads lyrics to (hopefully) any song. Simple object interface so you can roll your own. I threw this together because the Lyrics::Fetcher:: modules on CPAN are horrible. The regexes used to extract the lyrics are of course fragile and are likely to break upon any changes to the lyric sites :) I updated the method in which the lyrics are extracted. It is now one general regex, so it should stand the test of time slightly better. It will still break (partially) if any of the lyrics sites modify their templates. I'll try to keep this up to date as maintenance is needed.

There is no guarantee that the first match returned will be the correct song. That is why I use multiple sites, it gives you a fighting chance. Chances are you will receive some lyrics with additional info at the top (songwriter, etc) that I can't filter out easily. So you get stuck with some extras once in a while.

Given a directory, this will go thru and try to figure out artist, album, and title from the directory structure and filename. A few options allow you to tweak how it gets the information. Once it has gathered the info, it then writes an ID3v2 tag. I would support Ogg Vorbis, but I couldn't find a module on CPAN that could write tags to Oggs. Requires MP3::Tag, File::Find::Rule, File::Spec, and Cwd. (The last two are in the core.)

Nota Bene: Use at your own risk. If this messes up your pristine music collection, makes your socks smell, computer implode, or generally screws up anything, I am not liable.

This program is an MP3 player with a Tk interface. It uses a database to keep track of how recently songs have been played so that it can play songs at random selecting from the least recently played songs.

Merry Christmas!

This module presents an object-oriented interface to Ogg Vorbis files which allows users to view Vorbis info and comments and to modify or add comments. You can get the whole module here. It is also on CPAN.

Thanks to everyone who helped me with my Inline::C questions over the past few weeks. Also, if anyone finds errors in this code (esp mem or perl reference leaks) I'd like to hear about it.

Update: Note the new name (old was Ogg::Vorbis::Info). Dropped CPAN q as I've put it on now. Code is updated to reflect name.

This script with create a playlist in each directory that contains mp3s, nothing else exciting.

Short Desciption: Produces an .M3U style playlist from a specified path

More Detail: There have been a few other playlist makers posted, but I've given this one the moniker "better" because it's generates useful WinAMP-style .M3U playlists, not just a list of .mp3 files. It finds all MP3 files below a given path, and stores both the file path and the ID3 info (if availble; if not, it uses the filename) in the output M3U file.

To-do's:

• get rid of the 'shortname' hash -- it works, it was easy, but it's a tacky hack.
• check for ID3v2 tags ( didn't bother because this was written for my Mp3 collection that I ripped only with ID3v1 tags).
• Check for the OS it's running on and use proper line terminator ("\n" or "\r\n") and proper directory separator ('/', '\' or ':') accordingly.

This was written for my in-car MP3 player/computer, so when I download new music to it, one double-click will refresh/rebuilt/sort the default playlist, adding the new music just downloaded. Before I did this I had to open the direcotry in WinAMP, sort it and save it. That's a pain with a screen that's a mere 2.2 inches diagonal.

It's not too optimized, but it can still process an archive of 1,300 files in about 1 minute (Pentium 133, 32 Meg, Win2k Pro).

Requires MP3::Info to be installed.

To use, open up two xterms (or use splitvt or screen) and change into the directory you want the MP3's to go to in both. Run wscd2wav in the first, scan4wav2mp3 in the second.

Needs MPG123 and LAME. Contact me if you want to know more about Wolfox Radio.

Update

This new version includes a recovery feature and many bug fixes. I have also included some code from the suggestions. Thanks to ervey body who helped me with that. P.P.S: Yes I know the file shortening process could still be more flexible with the files it gets but I will get it done sooner or later :-)