Music Filesystems?

Cutriss asks: "I suspect the odds are fairly good that a high percentage of Slashdot readers have a folder, disk partition, network share, or even a hard drive dedicated to storing Oggs or MP3s. Given that this is the case, wouldn't it be beneficial to develop a filesystem optimized for such a use? For instance, in Windows, Microsoft has special folder layouts for folders declared to have digital music or images in them. The digital music folders don't bother with file permissions or any unnecessary data, but instead display your songs with the appropriate ID3 tag information instead. If a filesystem were developed that intrinsically indexed its files by ID3 tags (or similar mechanisms), wouldn't this be an ideal structure for storing and searching through your album collection? And, more to the point, are there any such efforts under way to develop such a beast?"

Comments

metadata

[Mad Marlin]

The problem with metadata information is that it is too inflexible. The ID3 tag is an excellent example. It contains title, artist, album, comment, year, track number, and genre. What about classical music, where you would want a composer field? Items not from a CD don't need album or track number.

A better solution is to take advantage of the flexibility of a modern Unix filesystem, where any charater (excepting '/') can bu used in a file name, including the newline. There is no reason why you couldnt name a file:

Title: Symphony 2
Composer: Bach, Johann Sebastian
Composition Date: a long time ago
Performing Artists: St. Louis Symphony Orchestra
Performance Date: not very long ago
Genre: Classical
.
.
.
Format: .mp3

The Unix filesystem is adequate for the job, metadata is a curse disguised as a blessing.

Metadata directories

[pthisis]

Bear in mind that one of the core driving philosophies that has allowed Unix to survive and evolve is "everything's a file", where a file is a stream of bytes. Attaching metadata directly to a file gets to be a nightmare when you start copying files over the network, dealing with editors that create new files rather than modify in place, backing things up, etc.

NeXT had a great solution to this: instead of just having a file "mysong.mp3", have a directory "mysong" that includes files like data.mp3, title.txt, etc. The file browser presented this to the user in a simple UI (e.g. the directory would have the "mp3" icon in the file browser, double-clicking it would play the song in the mp3 player, displaying the title.txt, etc). But traditional file transfer and backup tools worked just fine, and you could use standard tools (your regular editor, copy program, etc) instead of crufty special purpose ones (regedit, or binhex, or whatever) to work with the metadata.

Think of it this way: you don't want to just have 2-3 defined metadata fields, you would like to be able to add arbitrary new ones in a flexible way. And you want the contents of each to be flexible, without size limits or such. So you want a way of associating names with values--wait, we have that, it's called a filesystem. And you want a way of grouping a bunch of name-value pairs together--wait, we have that, it's called a directory. You'll either end up reimplementing a filesystem, badly, as your metadata, but need special tools to view/edit the metadata or move it around (a la resource forks or the registry), or you'll end up going with a NeXT-like solution and use the filesystem itself (which deals quite nicely with things like this).

Sumner