Overview

With Ubuntu 6.06, the Gnome desktop, a video iPod plus a few programs, it’s pretty easy to install music on the iPod. The main things to keep in mind are these:

1. Most free linux distros do not contain support for MP3 since it is a proprietary format. As a result, much of this will need to be installed first. Ubuntu users can use the tools EasyUbuntu, or Automatix (Mepis users too). For other distros, googling up instructions for installing various codecs, gstreamer libraries and such should provide the necessary instructions. More commercial installations probably already have the necessary items installed. There’s extensive documentation about this here. which is Ubuntu specific and very detailed.
2. iPods can have two different filesystems: HFS+ is the Mac version, FAT32 the Window version. Generally, if an iPod is initialized with one operating system, the corresponding filesystem has already been set. My iPod has only ever connected with my Ubuntu setup, and that chose the FAT32 system. While Linux can handle either, generally it takes more tweaking, even kernel recompiles, to handle the Mac version; it seems easier overall to go with FAT32 (and all three O/S understand it, which is a potential bonus for some folk). There’s a tutorial here that discusses conversion of the file system if this is necessary.
3. The music files must be in a format the iPod can play. The iPod supports
   AAC, MP3, and WAV. (This unfortunately leaves out several excellent open source formats such as Ogg Vorbis and FLAC.) This means that when songs are downloaded or ripped they must be in one of these formats. I chose MP3.

4. The linux system must be able to recognize and mount the iPod. Dapper had no trouble at all with this. In fact it has the cutest little iPod icon for the mounted device. Generally speaking, the newer models with USB ports should not be problematic; if the iPod is first or second generation with firewire, there’s plenty of information via google search to deal with that.
5. All told, two programs are necessary: one is to rip the music from the CDs in the correct format for the iPod, and the other is to sync the music over to the iPod. I used Sound Juicer to rip and gtkpod to sync
6. MP3 files are tagged via ID3 so that the album, artist, and track information can be retrieved from the files. In most cases, the software that rips the music handles the basic tag info, but there are also other programs that will add additional tag information. There are different ID3 versions, and care must be taken that versions are not accidentally switched along the way (eg the ripper expects one, and the syncer the other). Sound Juicer, with the correct settings, will properly set up the basic tag info as it extracts the music.
7. On Ubuntu, to eject the iPod (and stop the “do not disconnect” message, which will show as long as the iPod is mounted), make sure all programs such as gtkpod, Amarok, any filemanager displaying directories in the iPod, etc, are stopped, and then right click on the iPod icon and eject it or umount from command line. Otherwise the eject will fail with the message that other applications are using the iPod.

I found that the key to success lay in all the prep work on the music files I did before attempting to set them up on the iPod.

The basic sequence I am using now is:
Sound Juicer to rip the CD and then gtkpod to transfer them over. This is extremely basic! There’s no album cover art, no lyrics. Just album, artist, song names, track numbers, and playlists. I’m still working out the details of lyrics, album artwork, photos, and videoclips and will cover that in following articles.

Sound Juicer

Sound Juicer is the default CD ripper in Gnome. In Dapper, it pops up when an audio CD is inserted. The original configuration for Sound Juicer does not contain a profile for MP3, so the first step is to add such a profile.

This requires gstreamer-lame, id3v2mux. EasyUbuntu and Automatix should have installed these, but if not, searching through the Synaptic Package Manager should locate them. There’s extensive documentation about this here.

Start up SoundJuicer, and click on Edit->Preferences from the menu. In the dialog box near the bottom is a selection for different profiles, with an “Edit Profiles…” button to the right of this. A new dialog box will show; click on the New button along the top. For the Profile Name, I entered “CD Quality, MPG. The new profile is now listed in the list of profiles, so I could now select it and edit it. In this box, I put in CD Quality, Lossy for the profile name and MP3 for the description (to match the format of the predefined entries; there will now be two CD Quality, Lossy entries, but the type of file extension will distinguish between the two). The all important part is adding

audio/x-raw-int,rate=44100,channels=2 ! lame name=enc preset=1001 ! id3v2mux

in the GStreamer Pipeline definition. For the file extension, I used mp3, and then I checked the Active? checkbox and saved it. Now back in the Preference dialog, I chose the new profile as the Output Format and closed the box.

At this point, SoundJuicer should rip MP3 format files without any trouble.

Some notes: I found SoundJuicer pretty straightforward to use. On the Dapper distro, it is the default application to pop up when an audio cd is inserted. It’s also available in the Applications->Sound & Media menu & installable from Synaptic Package Manager. It’s gnome based.

gtkpod

gtkpod is a small application that will build up a list of music files to be transferred over to the iPod and then sync it (actually transfer the chosen files) on demand. It can also copy files from the iPod back to the computer, and can do other management, such as delete files, etc. I got my copy through the Synaptic Package Manager, and other download versions are readily available.

The first thing to establish is the iTunesDB. This was completely non-obvious to me, but from the menu, Files->Read iTunesDB does the trick. I kept trying iTunesDB Sync and other approaches because the error message indicates that no syncing has happened, therefore, etc. and so on. Once I got that, then I was confused with how to set up a list of files to go to the iPod. I found it was necessary to click on the “iPod” part on the left first. I had been building lists on the “Local” section (which is still sitting there) and could not for the life of me figure out how to get it on the iPod. There’s two ways to add songs to the list on the right panel; files can be read in and listed individually, or all files recursively under a starting directory can be pulled in at once. Now clicking on the Sync button will transfer all the chosen files over to the iPod. Then exit the gtkpod application, make sure nothing else is peeking at the iPod, and eject it, to see the songs.

Some thoughts and cautions

Some things to keep in mind. Updates and upgrades in this area have been quite rapid. This means it’s very easy to google up outdated information. Always check the date of the article, and establish which Linux and iPod versions are under discussion (that’s why I listed mine above).

The biggest stumbling block by far will be the lack of documentation. What I describe above (SoundJuicer+gtkpod) sounds simple, and it is, but I spent no few hours trying to make sense of these programs and searching online for tips and information. If I want to check out other programs, say GNUpod, I expect it to take a few days just to figure out how to use it and what its shortcomings are. I will likely not find extensive documentation and precious little for the questions and concerns I have. So that needs to be kept in mind.

If there’s a forum or mailing list for something, check it out! In gtkpod’s case, the documentation sucks, but the gtk-questions mailing list is fabulous: lots of responsive and helpful people there. And hopefully some efforts are underway to document gtkpod, because I think it’s a very nice little program.

For KDE users/purists, I believe that Amarok can handle all of these aspects, which I will also investigate and post about.

I haven’t even gotten to photos and movies yet! *Wipes brow*

(Happy Talk Like A Pirate Day.)

Well, I played around with EasyTags for a while, but two things came up that caused me to set it aside (and I may or may not return to using it). First, I realized that SoundJuicer (and for that matter audio-convert) still needed tweaking to properly handle the ID3 tags; I was still back at the general issue of — even though I converted the FLAC files to MP3– having to hand edit all of the tags. Erk.

Read the rest of this entry »

Update: The info on SoundJuicer’s gstreamer settings is incomplete and will result in low kb/s rates and bad tags. Please see the next post for better information.

Wow.

Just…wow. I got an iPod recently and today I set out to start populating it with music using Linux. Not Mac, not Windows, but Linux.

To look at the copy, it’s pretty straight forward. For example, see here and here, which all cheerily say that, with a little bit of fiddling, it’s a breeze to set up one’s iPod with Linux.

Read the rest of this entry »

I’ve been playing around with Amarok the last couple of days as well. When I saw a friend with an ipod who had the lyrics also downloaded with the songs, I started salivating and of course went off to check what would work with an ipod off an ubuntu installation.

Dapper Drake seems to have the 1.3.9 version of Amarok installed, so after a little poking around, I added the following

deb http://kubuntu.org/packages/amarok-142 dapper main

to my /etc/apt/sources.list file. Going back to the Synaptic Package Manager, it now lists Amarok 1.4.2 for an update. So I updated that, and went back to my playlists.

But nothing plays! All it says is “No Audio Channel” …!

After a little more digging around, I find out that for some reason libxine 1.1.1 broke support of playing FLAC files. This was, of course, the format I’d chosen to copy my CD’s over into my computer. It’s been fixed in 1.1.2, but 1.1.1 is the version in Dapper Drake (I do not know what plans are for fixing this in the 6.0.6 release: this one certainly seems to mandate a backport for functionality). In any case, following instructions on this page and snagging this patch as given by the user “Ivo Man” resolved this little problem.

And now I’m happily listening to my playlists. I even hooked up a pair of speakers to my laptop!

I have been playing around with the Linux version of Picasa for the last week or so, as the need to organize my pictures in some way became more urgent.

Installation

The Linux version of Picasa is available for download on this page. There are several options — rpm, deb and bin packages, each with instructions. I had no trouble downloading and installing the deb package on my Ubuntu 6.06 setup.

Unfortunately, Google does not include instructions for using the package manager on these pages; they are to be found in the FAQ instead and if I were to do this over, this is how I would install:

Add the Google Picasa for Linux repository:

deb http://dl.google.com/linux/deb/ stable non-free

and now apt-get can be used:

sudo apt-get update
sudo apt-get install picasa


The Good

When Picasa starts up, it immediately begins to scan the hard disk drive for pictures. It will scan everything for anything remotely image-worthy. This can lead to some interesting results as it will pick up images used by various installed applications.

Under the Tools->Folder Manager menu, I found a dialogue to mark which directories to look at or ignore. I can tell it to scan particular directories once or always; or to ignore them altogether. I chose to have it continually scan only my home directory and this got rid of many of the spurious images.

The really cool part was finding photos I had completely forgotten about and which were lost in the general directory disorganization resulting from having migrated from about three or four hdd’s and two or three computers in the last seven years.

One thing I like quite a bit about Picasa is that it leaves the original images alone (except for red eye fixes) unless I tell it otherwise. (Some people will file this under “The Ugly;” it’s going to be a matter of personal opinion.) I have discovered, in going over something like seven years of pictures that having the original “raw” (not to be confused with RAW format) upload makes all the difference in recovering the original quality of the pictures.

Pictures downloaded from digital cameras are in JPG, which is a lossy compressed format. The practical consequence of this is that each edit to a JPG file (depending on the software used, sometimes even something as simple as rotation) usually results in loss of quality in the saved version. So I want to always keep the original files around as the baseline for going back to especially if I mess up a series of edits.

I organize my pictures by year, with each event or topic getting its own sub directory within that year. Last year, I started including a “raw” directory which is supposed to be where I upload all the camera images and then copy them over to the organized sub directories. So for example, the year 2005 might contain the following directories: raw, january family dinner, easter, home improvements, fourth of july, rome trip, thanksgiving, and christmas. The “raw” has all photos taken, ever, in 2005; the remainder are the best pictures for that event, sorted out, rotated, color corrected, with blurry or bad pictures omitted. Now I admit I’ve been a bit piecemeal about that approach, but after working with Picasa for a while and being able to see all of my photos over the last seven years at a go, I’m an enthusiastic convert now.

Picasa works perfectly with this approach. Let’s say my next set of pictures is from my brother in law’s birthday party next weekend. I’ll upload all the pictures into my “raw” directory, and then go over them with Picasa — correcting, rotating, etc. Then I will export the chosen pictures into “A’s B-day” directory within the 2006 folder. Voila!

Picasa arranges the photos it finds by date, within the name of the folder it’s found them in. This has some drawbacks, as it creates a flat list. Therefore several of my directories which each had “web” subdirectories (holding smaller versions for various websites) showed up as multiple “web” folders in Picasa, which is a bit confusing. But either I can rename the directories themselves, or tell Picasa to use a different name for the folder. Still it can be a bit confusing to see multiple instances of the same filename occurring. This was especially bad with one set of trip pictures I had — the main directory was named “Red River” and then under that it had a directory for each day we were there, and then under each day-directory, there were three folders, one for each photographer with a camera, since we pooled all our pictures together. So in the end, I had multiple folders each with the photographer’s name. Each “leaf” directory within a particular year should have as unique a name as possible, or else the folders can be renamed in Picasa.

Picasa supports tagging of each picture, and that builds up a list of labels above the folders. Clicking on any of the labels (tags) pulls up all the pictures so tagged, which is a great way to help keep pictures organized.

When viewing individual pictures, Picasa offers a number of “editing” options. As I’ve mentioned, changes aren’t actually made (with the exception of red-eye fixes) to the files themselves. These corrections are more like overlays maintained by Picasa and include the basics like rotation, color correction, fill lighting, saturation and so on. It’s very fast and snappy when working with files, and it does a very good job at cleaning up files. I found the “I’m feeling lucky” button to work particularly well when involving photos of statuary and paintings. If I want to save these changes to actual files, all I need to do is to export them to another directory.

The Bad

Because of issues with driver support, Linux Picasa cannot burn to CD. This isn’t a show stopper for me; I prefer to use my own software for this, but it’s a pity this isn’t integrated into Picasa since it’s usually a timesaver.

Also related to the lack of uniformity across Linux installations, Linux Picasa is a bit wobbly with handling some issues such as which browser or email program to use, or how to access directories and files. There are template files intended to provide such specific information on what to do in a particular installation. The FAQs reference these files in passing, but unfortunately not in detail. They are:

picasa/desktop/picasa-hook-filemanager.sh.template
picasa/desktop/picasa-hook-urlhandler.sh.template
picasa/desktop/picasa-hook-email.sh.template


I first had to find the template files in question. Finally by using

locate picasa | grep desktop

I was able to determine the files resided in /opt/picasa/desktop. The file is not terribly helpful though. I copied the template file into my own ~/bin directory and played with a couple of settings. I tried a couple of things, here’s my final list:

#/usr/bin/nautilus "$1":h
#/usr/bin/konqueror --profile filemanager "$1"
#nautilus `dirname "$1"`
nautilus "${1%%$(basename "$1")}"

I did google for any examples anyone else may have constructed from these files, but the best I found was this, which was interesting, but not the level of detail I was looking for.

But the real problem wasn’t the contents of the script. The problem was in getting Picasa to recognize and hence execute the script! Like a good little unix weenie, I copied the file from its opt home into my local bin directory, chmodded it to 755, made my additions, and restarted Picasa. Nada. Checked my path with printenv. The bin dir was listed. Executed the script directly with a couple of path names, everything started up fine. In desperation, tried copying the file back to the picasa/desktop directory, still no dice.

The only thing that finally worked was to drop the script into /opt/picasa/bin. However, the Google documentation on this point is at best misleading, since it implies that the file need only be somewhere in the path, but clearly it’s only looking in one of a few places such as the bin directory. Grrr.

The Ugly

For some unknown reason, the Linux version of Picasa does not come with an export button to the Picasaweb site. As a result, I’m forced to upload pictures manually using the browser. Which is rather like shovelling coal in the nuclear fusion age.

I also found out that it’s not a good idea to change permissions on directories (or to rename or move them) after one has made extensive “changes” and tags to those directories. Ahem. From Picasa’s point of view those files are gone, and so it discards the meta data it’s got on those files.

However, I can’t really think of a good way for Picasa to handle this kind of thing. If a directory is suddenly inaccessible, what else can it do but assume the files are gone? The only way around this would be for Picasa to store the metadata (tags, etc) with each picture file itself and I can’t see that being done. It’s a possible argument that Picasa should at least save the edits to the file but there are two ways around that: either export a modified folder to a physical folder or tell it to save the actual changes to those files. If the metadata is saved within each folder, all that has to happen is for someone to move the files to another directory, rather than renaming the directory.

So it seems to me to be a fairly nasty situation with no good work around. And since the real issue is the meta data, I don’t even consider this a side effect of the no-modification-to-original philosphy that people either love or hate because the meta data question remains whether or not edits are saved to the files or not.

Flickr versus Picasa Web

Ironically enough, since Linux Picasa does not have the web export button that Windows Picasa does, it’s much easier to upload pictures to Flickr. Since overall I prefer Flickr’s options and interface to Picasaweb’s, this turned out to be a plus for me. To send pictures to Flickr is quite easy, especially when I use my gmail account. In the past few days I’ve sent almost 2000 pictures to Flickr!

I first set up an email address at Flickr. The folks over there will generate a random email address for their users. I can email pictures to this address along with various options in the subject line and they will show right up in my Flickr photo stream.

Now I select the pictures I want to send. I can send up to six pictures at once if I have set the email options (Tools->Options->Email: from here, set the gmail account, size of picture and so on).

Since Picasa is a google product, it interfaces very nicely with gmail. Once I log in with my gmail password, I can select up to six medium sized pictures, choose File->Email (or the handy ^E). I can tab through gmail’s known email addresses to the Flickr-generated one, choose that, and then set the subject line to what I want as the title for those pictures. I then add after the title (still in the subject line) a tags: tag1 tag2 which lets me set the tags for those pictures. Then I clear out the message body and either leave it blank or write something appropriate to all the included pictures and send it off.

Voila!

In contrast, the only alternative way I could find to upload to my Picasaweb site was a browse/upload page provided by picasaweb itself which was so painfully slow, I don’t want to bother with it again. I’ll revisit Picasaweb once the upload button is included in the Linux version of Picasa. On quick scrutiny, though, Picasaweb has very few features at the moment and not very much storage space as compared to Flickr.

Oh, you wanted to know where my Flickr photostream is? Right here If I know you in real life, drop me a note and I’ll add you as a friend contact if you really want to see all 2K pics . Otherwise, feel free to look over my public photos and add me as a contact if you like which I will reciprocate. I always enjoy browsing pics…

Summary

Overall, I’m impressed with this program despite the fairly extensive “bad” and “ugly” sections. I do not understand why some features were left off the Linux version, and I hope that this will be fixed in the future.