Hi everyone,

I have a couple of questions for the group regarding a large mp3 collection (approx 2500 CDs) on a Linux machine. This is not exactly empeg related, though I use (and love) my empeg for mobile use. The entire mp3 collection about 260GB, so using the empeg for the whole thing is not an option. I'm struggling with the best way to manage the large collection.

Since I ripped and encoded these myself, nearly all of them are properly tagged, but some didn't get tagged. Since I started this a while back, many are tagged with v1 tags only.

The mp3s are arranged in files in an Artist/Album/##_Track.mp3 structure.

Here's what I want to do:

1. Create a list of all files on the server that don't have tags
2. Create a list of all files with v1 tags only

and then:

3. Tag the untagged files using the artist/album/track structure
4. Load all of the tag information (since everything is now tagged) into a mySQL database.

and maybe:

5. *Consider* re-tagging the v1 only files with v2 tags. I would definitely do this if I could do it automagically using the artist/album/etc. structure.

I know mp3tag studio does things like this, but it is a bitch with huge recursive directories, and I'd like a nice little unix program and shell script to do it, if possible.

Which brings me to my next questions:

I'm using mp3blaster for "home" playing which is a nice little text based mp3 player for the UNIX console. With this many files, the limits of filesystem management are becoming serious.

I want to be able to use data in a relational database to compose playlists rather than select files on the filesystem. This will also facilitate sophisticated searching, etc. For example, a big problem with file system management is having a file or group of files in multiple "genres" or something like that. I suppose one could use links, but that sucks for a variety of other reasons. The empeg handles this whole thing beautifully. It also seems to use a relational database to do it...

Ideally, I'm looking for a linux console player solution that uses a database to find files rather than a "file manager" that is customary.

Alternatively, I'm looking for server-side software that will allow me to manage the collection and some kind of client (Rio Receiver???) that plays the collection.

Does anyone know of any software that does things like this for home use? With a filesystem of this size, I have no interest in using Microsoft, and I don't think it would work anyhow. Using Linux, I have the whole shebang in one filesystem and can play 256kbit/sec mp3s while uploading/downloading on a 100bT connection -- all on an old Pentium 133. I fired up Samba and tried to share the directory with Windows, and it crashed my PIII 866 with 512MB so hard (after thrashing for 15 minutes) I needed to reset.

The JReceiver Java servlet server for the Rio Receiver seems that it might do all the database magic for me. If I get this running, are there other options for playing other than the Rio Receiver? What about configuration clients and searching clients that talk to the JReceiver database?

Can the Rio Receiver even support this number of files (probably about 40-45k files)?

What is everyone else doing?

Am I nuts? Are these questions appropriate for this forum?

Are there other Linux/UNIX collections out there? Is anyone using some kind of sql database for metadata on their collection?

OK, one last thought:

Once one has the information in a database, it seems to me that the "Album" or "Source" table could contain a field for "catalog number" so that I can arrange the physical CDs by part number. The same problems happen in a physical collection, and a part number-based inventory system seems to make sense to me. Then, I could search for "Bach" and "Prelude" and get a listing of all mp3s that match *and* the catalog number in my CD collection for the cds on which those tracks originally appeared. Since the CDs would be arranged sequentailly by part number, one could instantly find the desired CD. New CDs would be ripped, encoded, uploaded to the mp3 server, loaded into the database and tagged with the next sequential part number (supplied by the database) and then put away.

Whew!

Thanks!

Jim