thraxil.org:

heavy duty mp3 managers shootout

by anders pearson Thu 06 Nov 2003 00:39:15

i've mentioned several times that i've been working on an mp3 library management program called drachen that was specifically designed to handle enormous volumes of mp3s. i am now happy to announce that the project is dead and i'm abandoning it. ha! weren't expecting that were you!

really, this is a good thing. the reason i'm killing off drachen is because i've finally found another program that does what i need, can handle a library of over 20,000 songs without bringing my computer to its knees, and (most importantly) is maintained and improved on by someone else. i'm lazy. i'd much rather spend my time contributing bug reports and/or patches to someone else's open source project than heading my own.

it wasn't easy. i had to spend an inordinate amount of time trying out every linux mp3 player under the sun. finally though, i think my quest is over.

some background:

i currently have 20,527 mp3 and ogg vorbis files in my collection (almost entirely legal too, fwiw; i ripped my large CD collection and downloaded a lot from my emusic.com subscription). i store them on a fileserver machine and mount the directory over NFS. it comes out to just about 100GB in all.

when you have a collection that large, you face two main problems. one is the interface. just keeping them in directories for each artist and album doesn't really cut it. you really need some kind of database like interface to navigate them without going insane. OS X (and now windows) users can testify that the iTunes interface is pretty much the gold standard for mp3 management. so that's pretty much what i've been searching for.

the second problem is that with that kind of database like interface, you need some kind of database like backend to store the metadata so you can search it efficiently. doing this in a way that scales up to 20,000 tracks is difficult. the vast majority of players that i looked at just couldn't scale that well performance-wise. they would bog down the whole machine for several minutes and be completely unresponsive every time they had to perform a simple search. (iTunes, apparently even has this problem, so even if apple released a linux version it wouldn't do me much good). there seems to be some point probably around 10,000 songs that breaks their backs. on my machine at work, i have about 3,000 songs and every player i tried there handled that size library very well without any noticable performance problems from any of them.

my solution was to use a fullblown, hardcore, RDBMS for the backend. this worked pretty well and scaled quite nicely, but if anyone else was ever going to use it, requiring an end-user to install and admin a whole RDBMS just to listen to their music wouldn't really fly.

here's a quick rundown of all the linux mp3 players/managers i tried out and how they fared. (for reference, this is all on my dual 1GHz P3 w/ 256MB RAM running gentoo and a 2.4.20 kernel).

Zinf 2.2.4

it has a pretty nice library manager with an iTunes-esque interface. its musicbrainz integration is very convenient for fixing mistagged files. performance was abysmal. once the library was loaded, just starting zinf would take 20 to 30 minutes. editting any id3 tags would again take over the machine for 15 minutes with 100% CPU usage.

rhythmbox 0.5.3

the GNOME music player. it has the nicest interface of all the players i've tried. very much an iTunes clone and done with the minimalist style and focus on usability that makes GNOME so nice. performance unfortunately was only a little better than zinf. just selecting a new song would lock it up for several minutes.

Juk 2.0 beta 1

the KDE entry. decent interface. it loads faster and performs a little better than rythmbox (about 30-40 seconds of hang time following any action), but still slow enough to be unusable. it also had musicbrainz integration and a nice interface for editing id3 info.

madman 0.92rc1

the madman developers took a similar approach to what i was doing with drachen. madman is just a playlist editor and library manager and expects you to use another program to actually play the mp3s. the interface is a bit weird, but has a very powerful mini query language for searching. it performed so well on my work machine's smaller collection that i had high hopes for it. alas, it also choked on the massive home collection.

yammi 0.8.2

another playlist manager that piggybacks on XMMS for the actual playing of songs. the interface isn't very polished looking and it lacks some of the slicker features of the others (like the 'rating' feature, or musicbrainz integration), but it does have 'fuzzy' search which is nice if you can't type or spell and integrates nicely with k3b for CD burning. but none of that matters next to its performance. yammi is fast. whatever they did, they did it right. it's as fast with 20,000 tracks as any of the other players are with 20. it takes about 15 seconds to first load, but after that there isn't any noticable delay anywhere. we have a winner.

(musik also looks like it could be promising, but gentoo doesn't have an ebuild for it and i'm too lazy to install it manually.)

TAGS: linux software music drachen performance mp3 scalability zinf rhythmbox juk madman yammi

comments

I have been toying with the idea of putting my vast library of music into an mp3 database, very much like you have done. I was thinking of using iTunes, being is I am a mac-head. But your research has me alittle scared now, since my classical music library alone is upwards of 250 cd. I guess I have to read over your research again to get the jist of what is out there. But in short, what is the skinny on your library/database/front-end for mp3 listening pleasure? What exactly are you using?

I have ripped 500+ CDs to iTunes with excellent performance. I use a 1.2Ghz Athlon and a 867Mhz Powerbook G4. I have to use Juk/Yammi with my Gentoo system; both are inferior to iTunes.

My problem is that I want to share my database across multiple machines. I have ripped about 400 CD's now ... downloaded a bit here or there but I care most about the CD collection.

Also I am really starting to worry about backing up those MP3s ... the amount of time it took me to rip them is not insignificant.

i recently purchased a 120GB NAS which is basically a brick sized linux machine with a big hard drive, an ethernet jack and just enough of a processor to serve up NFS and Samba shares. i just nfsmount it from all my other machines. i also keep the whole collection backed up to a spare 180GB drive in one of my machines. rsync + cron make it easy. with the low cost of storage relative to the value of a large music collection, backups are pretty much necessary.

One of the newer versions of AmaroK started having hava a database-type functionalities (ebuilds at amarok's site). So it might be worth looking at.

Given that it is a new and undeveloped feature (amarok isn't really a database/iTunes type of player, its more like WinAmp) it probably doesn't score very well. And I think the Search feature of amaroK doesn't work with it at all, but search's through the actual files.

Well, I've been looking for a similar solution. I to settled on Yammi, however, I cannot seem to get it to scan my entire collection at once or it completely locks up my computer. No, I don't mean it hangs - it locks up the whole PC and forces me to power cycle it. I've got a little over 150Gb of music in 22,000 tracks. Yammi works fine if I scan one directory (artist) at a time. It stores everything in xml files, so its pretty quick.

Now, my collection is on an external 300Gb drive accessed through a USB 2.0 port. When using Yammi on a 2.8Ghz P4 with 1Gb RAM, it takes it about 2 minutes to lock up the computer. On my P3, 384Mb laptop, its takes about 20 seconds. Is it trying to load all this data into memory before writing it? If so, I can't imagine this working for anyone with large collections unless you manually scan a directory at a time like I'm doing.

Anyone else have a similar experience?

it sounds much more like a problem with the USB/scsi stuff, possibly with the drive itself. i've had issues with firewire drives locking up machines in a similar way. without very careful tuning of the kernel, external drives seem prone to locking up under heavy use. some drives seem more reliable than others. i have two external firewire drives; one holding my music collection and one holding backups. the one with my music is pretty robust, but the one with backups gives me nothing but problems if i try to use it too heavily. it may be incompatibilities with the drive's firmware or it may be that the drive is slightly broken or i just may not have found the right magic kernel configuration yet. at any rate, yammi has no problem indexing the music on my external drive and my collection is pretty similar to yours in size and i only have 512MB of RAM.


formatting is with Markdown syntax. Comments are not displayed until they are approved by a moderator. Moderators will not approve unless the comment contributes value to the discussion.

namerequired
emailrequired
url
remember info?