How do you folks deal with mp3 collections shared on your local LAN, especially when you have multiple OSes? Right now, I have my music on a Unix server that shares it via NFS and Samba, but so may actual music players want to keep their own indexes of the music, which makes adding new music a pain.

If I record a song via EAC, then I have to go around to each of these index-based players and tell them that there's new music. (Why can't they just look for it in the background?) iTunes is the worst, as I can't even play a temporary downloaded mp3 without it indexing the thing, which I then have to clean up, but I can't find a way to tell it about the new music I've got without trying to figure out the differences since the last time I told it what was there. Aarrgh!

I'm fine with just having a directory-based structure, but the index is nice for those times when I want to shuffle. But that advantage is heavily outweighed by the work required to index all that music.

What do the rest of you do?

When I had about 20 computers with music shared, I used MusicMatch Jukebox to display all the music. A macro program ran in the background to update the list every night (it took about an hour). It may not be what you are looking for, but it worked for my purposes.

-Biscuits

What do the rest of you do?

I use Rio Music Manager -- it rebuilds its database as a background operation every time you run it .

It should have been obvious from the reference to both EAC and iTunes, along with the Unix server, but these computers do not all run the same OS.

I'm pretty sure there are also MusicMatch clients for Linux and Apple.

There are also plenty of other music programs that create and organize lists similarly. Few of them will update automatically, but you can almost always use a macro program of some kind to do it for you.

-Biscuits

I think they had some lip service to the fact that they had mmjb for Linux and Mac at some point, but I can no longer find any reference to it. Of course, that doesn't really help me on my Sparc or non-MacOS PPC machines, anyway.

However, I'd be interested in hearing more about these macro programs to build indexes. I can do that on multiple OSes.

You can set a macro program to control the mouse/keyboard for you in a preset way. This can either be a simple macro (click here, here, and here, then type 1234 <enter>) or something incredibly complex (count the number of file names, then repeat this sequence of mouse/keyboard strokes 15 times - y, or until you read X text).

I had one macro program to build a massive database of what modules we had installed in different stores at one point. It took about 30 minutes to connect and figure out everything we had in an entire store, going through 3 different peices of software (was about 2 hours manually). This came in handy, since part of my job entailed doing this for about 200 stores. Of course, since it was so complicated, it took me about 2 weeks to write...

Basically, anything tedious you do yourself, you can automate with a macro. For Windows, I'd recommend Macro Express. I don't know what is good for other operating systems.

-Biscuits

Oh.

I thought you meant that there were other programs to build the database for you.

Nevermind. I'm not about to have some automated process log in and start pressing buttons for me.

God, computers suck.

other programs to build the database for you

But then those other programs would need to know each of the database formats which you intended to use.

Nobody releases that kind of information. Reverse engineering it is tricky at best, a minefield of litigation at worst. It can even be quite amusing -- a particular music management application (not ours) used the name of one of their programmers XORed with the data to 'encrypt' it . And they keep changing the damn things.

This is a problem for me, too. I can't really speak to the indexing thing, since I just use directories on all the machines.

I've "solved" the problem procedurally. I have one "master server" that is a Linux box. It can share, but mostly I use FTP to get things to/from it. I have a single machine (a windows desktop, actually), that is the *only* machine that *uploads* to the server. It is my ripping machine and how I get new stuff on the master server. Before any mp3 can be played, it must be uploaded to the server. I keep two directories on the ripping machine "new rips" and "music". "music" has stuff that is already on the server.

All my other computers get their mp3s by downloading from the server or using a share from the server.

It doesn't solve your indexing problem, but it prevents synchronization issues on the collection and makes sure you have a single master location for all the discs.

As an aside, I love the linux mp3 server. I'm using software raid on 3x160GB disk drives. It is an old P133 that I got for free and put a 10/100 nic and 3 drives in it. It works beautifully. I can play music on it using an awesome console player called mp3blaster and it still has enough guts to handle upload/download without skipping. I'm sure I could load it down with multiple users and make it skip, but maybe not. It's a pretty good solution. I just upgraded my home PC so I'm going to be migrating the server to that board, which is a P3/866 -- way overkill. It's not been a priority because the P133 works so well. Sub-second response time on key presses accessing a 300+GB mp3 collection using a 32MB/133MHz system! Let's see windows do that!

Jim

Is that a RAID 0 configuration? If so, I hope you keep some kind of good backup!

-Biscuits

Yeah, I have two systems one for backup. It is raid 0.

You have 480GB of mp3s?!

No, I have about 310 GB of mp3s. The 160's "only" have about 145GB usable on them after formatting, etc. I ended up adding the 3rd disk when I filled up the 2x160 configuration. I figured, what the hell, add another 160GB and then I've got room for new CDs. I ripped them myself, which was a drag. It took months and months and things kept changing. For instance, the older CDs only have version 1 tags on them. The reason it takes so much space is that they are all 256 CBR files, so I average around 100mb/CD.

I organized everything into directories of Artist/Album/track_song.mp3. What I need to do is find or write a perl script to recursively retag everything with the new tags using this directory structure. I'm a total perl newbie, so I haven't managed to get this done. The filenames all have underscores instead of spaces, so perl needs to work that out for me, too.

Some of the files are a real problem, especially the classical stuff (which I have quite a bit of). The "Artist" might be the performer, and then the tracks might have a composer name in them.

It's really a problem, actually, having all that data. I really need a mySQL database. The artist vs. composer thing is just one problem. I've ranted about the limitations of a directory structure for mp3 organization before. It is a *perfect* example of why relational databases were invented. If only there were 50 hours in a day...

Any thoughts would be appreciated...

Jim

I might as well mention it again in this thread...

I'm looking for an easy way to populate a MySQL database using this Artist/Album/Track directory structure. I'm pretty sure this can be done fairly easily in perl, but like I said, I don't know how to do it yet.

Jim

Any thoughts would be appreciated...


There's no one 'correct' way to organise and tag mp3s that handles all types of music well.. (eg Classical, Mix Albums, Compilations, Soundtracks etc). I don't think that the problem stems so much from ID3, since ID3v2 is fairly extensible. It actually starts earlier in the process than that, at the CDDB stage. If CDDB had a structure more suited to handling such albums (and was accurately populated), then I think that ID3 tags would evolve fairly naturally to accommodate them. (In turn leading to software that used them).

Bad data in - Bad data out.

My other 'thought' that you might appreciate, is that it appears that you might want to consider RAID5 soon. Linux supports RAID5 both in SW and using various HW solutions. (ISTR 3com Escalade series being well supported and cost-effective). A 4th 160GB disk in RAID5 would give you 435GB storage, with fault tolerance. It's not worth discussing performance benefits/hits of RAID5 vs RAID0, unless (of course) you're illegally sharing your music with a large number of people...(in which case, probably best not discussed anyway..)

What I need to do is find or write a perl script to recursively retag everything with the new tags using this directory structure. I'm a total perl newbie, so I haven't managed to get this done.

You might start with one I wrote a while back for that purpose.

-Mike

Read performance of RAID5 vs. RAID0 should be pretty similar, and better than a single drive, unless the RAID5 implementation is quite poor. I don't really have all that much statistical info on those modes under Linux, but thye've come up with some odd stuff before, so I wouldn't put it past them. (I'm talking solely SW RAID here; HW RAID should be pretty fast, I'd imagine, for all bets, although I'm not familiar with these consumer RAID things, although relative speed might vary quite a bit between different modes.)

Writing, on the other hand, is way slow on RAID5.

Ypu, and if you want the best of all words, you need RAID 0+1, which is complete overkill for home use, I'd say....

There are also some cheapish hardware IDE RAID cards around now, never tried them out, but should be significantly better than Software RAID (which in my experience is flaky and terribly slow).

Personally, I would never have a RAID0 installation at home without some serious backup hardware (DLT minimum). Reason being you are more exposed to risk of loss of data with RAID0 than any other RAID system.

Cheers,

Paul.

I've always had qualms about referring to RAID0 as RAID, since it's hardly redundant. And RAID10 is better than RAID0+1 in all cases but the minimal case. Most of my software RAID experience comes from Solaris, and both their DiskSuite RAID implementation and Veritas's Volume Manager are quite stable and pretty fast, except RAID5, which cannot be expected to be fast.

My point was that for his needs (single user playback of mp3 files and infrequent writes), maximum performance is hardly a requirement, whereas providing fault tolerance whilst maximising disk space probably is. Backing up/ restoring 300GB of media files is hardly trivial.

The hit on RAID 5 is parity calculation during writes..If course, the bigger hit is likely to be from using multiple drives on the same IDE channel - regardless of RAID mode.

raid 10 w/ a hot spare would be the best choice for redundancy and mission critical apps... otherwise, i would recommend a raid 0(+1) and a backup to dvd for the most economical.

Maybe, but Raid10 is uneconomical - your capacity is (n/2)*drive capacity.
(Where n is number of disks - let's assume here that all drives are the same capacity and that there's no partition jiggery-pokery going on).

Raid5 gives you (n-1)*drive capacity.

If this was mission-critical (which it is not) then yes, Raid10 would be ideal.

But the reality is that the redundancy of Raid5 should easily suffice for a home media server, and at the same time, 160GB drives are $215 a pop, you're looking at $860 for 480GB of RAID5 vs $1290 for 480GB of RAID10

Thank you for all of the responses. I have been thinking about adding another disk and going to RAID5. I don't care about write performance, because the major applications (FTP and mp3blaster) are pretty much read-only. In fact, even read performance just doesn't matter. It's only 256kb/sec + overhead, which you can get off of a CDROM. You're right: I'm not sharing, so its just for a jukebox application on the home stereo and a file server for the empeg. Since I already have 3 160GB drives, the incremental to go to raid5 is only about $200 or so. I think, however, that I'll lose my filesystem when I go from raid0 to raid5, so it will be a hassle to migrate.

Jim

RAID10 and RAID0+1 (and RAID1) have the same level of economy (namely, not much). RAID0 would be the most economical, except that it's not really RAID, as it provides no redundancy. After that, it would be RAID3/4/5, all of which have the same capabilities for economy. It might even be slightly preferable to use RAID3 over RAID5 for an mp3 collection, but the benefits would be marginal, if existant at all, and it's hard to find RAID3 implementations these days, anyway. But, again, RAID5 is slow (as are RAIDs 3 and 4), but mostly for writing.