Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Music Media

Music Filesystems? 89

Posted by Cliff from the endtroducing-the-MFS! dept.
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?"
This discussion has been archived. No new comments can be posted.

Music Filesystems? More

Music Filesystems?

Comments Filter:

  • Metadata (Score:3, Insightful)

    by SteveX ( 5640 ) on Tuesday April 23, 2002 @02:23PM (#3396202) Homepage
    We don't need a special purpose filesystem for this; just one that supports metadata. I know NTFS does; do any of the common Linux filesystems?

    Either way you're going to need a custom tool to do searching and whatnot, the custom tool might as well just index the stuff in the ID3 tag and work with an existing filesystem.

    - Steve
    • HPFS does as well, although under OS/2 the "extended attributes" are limited to 64K bytes. I don't know if the Linux HPFS driver has the same limitation.

    • Re:Metadata (Score:4, Informative)

      by foobar104 ( 206452 ) on Tuesday April 23, 2002 @03:31PM (#3396839) Journal
      We don't need a special purpose filesystem for this; just one that supports metadata.

      There are a lot of reasons why filesystem-level metadata is harder than it sounds. (XFS supports it, incidentally, though extended attributes. There are command-line tools, and also a C API. Dead simple.)

      Filesystem-level metadata is usually stored in the inode itself. If it's not stored literally inside the inode, then it's tightly coupled to the inode. This is good; it makes it fast. Reading a big chunk of metadata (say, 128K) is about as fast as doing a stat(). So that's good.

      But most applications do something tricky with their data files. Say, Photoshop for example. When you're working on a file (foo.tiff) in Photoshop and you tell it to "save," Photoshop doesn't truncate and write to the file foo.tiff. Instead it writes to a temporary file. When the write is complete, it unlinks foo.tiff and renames the temporary file "foo.tiff." This is also good, because it makes it very unlikely for a program or system crash to destroy foo.tiff, even if saving the file takes a really long time. A crash or other interruption during the save process leaves foo.tiff just as it was; at worst, it leaves a dangling temporary file laying around.

      Here's the catch: when Photoshop saves that new temporary file it gets a new inode. That inode has no metadata in it. All the metadata associated with foo.tiff is in foo.tiff's inode. When the temp file has been written and Photoshop unlinks foo.tiff, that wonderful rich metadata disappears in a tiny puff of blue smoke.

      Sure, there are ways to work around this. We could implement a system call like clone() or something that allows an application to get a new, empty file open for writing that has all the filesystem metadata from another file automatically copied to it. Or we could do any number of other clever things. But all of them-- at least to my knowledge-- would involve changing end-user applications. That makes it tough.

      ID3 tags are different, because they're stored as part of the MP3 file itself. Copying the file's data, using any method you might choose, will also copy the ID3 tags. But inode-based filesystem-level metadata is something else entirely.
      • We should assume that by metadata, it means more sophisticated metadata than mac HFS/HFS+. Obviously a database file system, preferably in XML so that we can easily get support for MIME filetypes online if need be.

        There is no technical reason why you can't have temporary files [or their modern equivalent] in a failsafe environment that persists even when the computer crashes.
        I agree with the new metadata file approach, it's sort of like the mac HFS. But, I would also use a local metadata database to backup metadata transfers when the excrement hits the air-cooling system.
        It's possible to store these ID3 tags as part of the XML MIME info, then you can search for music at filesystem access speed rather than read the guts of the file for the ID3.

        And before you ask: yes, this is a part of the Kaos operating system I'm working on.
        • My god. I spent ten minutes writing a lengthy reply about how external metadata databases are inherently flawed due to the primary key problem. Then I realized that you're an idiot [slashdot.org]. Sorry. My mistake.
          • I know external metadata is flawed, in case you didn't notice I was being polite to someone who is still thinking about metadata in the same way as apple did in 1984.

            As for me being an idiot, a common method of implementing AI programs is to use insects as the template.
            I am merely going one step further by defining an evolutionary basis for individual agents that behave in an emotional manner.
            It is possible that you are one of the geeks who is insulted by the use of game theory, a method widely used to anticipate change.

            And if you are one of the herd of americans who views the internet as a place to insult foreigners, I don't care.
            I'm lucky enough to live 1 minute from the beach, in the capital city of a country that is home to Lord of The Rings.

            I really don't have time for petty personal disputes whenever there is a procedural expert or 'ideas person' around, I'm just trying to get things done & I have no time to waste on trivial matters raised during consultation.
            • First of all, New Zealand is beautiful. I am an American, as it happens, but my company has an office in Sydney and I have a business partner in Auckland. I spend about half my time in that general area of the world. Wish I could spend more.

              But the fact that you live in a nice place doesn't make you any less of an idiot. I don't mean that in a perjorative sense; I just mean it literally. Your posts and journal entries reveal you to be a person of less-than-average insight. Nothing personal.

              Please, by all means, prove me wrong. Share some piece of wisdom that makes us all stop and think. Say something to make me reply, "Yeah, that's a good point." Throw me a bone here. My opinion will change quickly in the face of new information.

              I really don't have time for petty personal disputes whenever there is a procedural expert or 'ideas person' around, I'm just trying to get things done & I have no time to waste on trivial matters raised during consultation.

              Well, good luck with that. Let us all know how it works out for you.
              • BFD, I suppose by your logic, those New Zealanders and Australians who work for American companies know what it's like to live in New York.
                If I was an idiot, I would give you the full picture on certain technology which is banned from development in the USA.
                Nothing personal, but the NSA aren't the best people to deal with new and interesting information.
                I would be glad to give you new information I have, but you would find out that Big Brother doesn't respect the laws or the constitution of your country at all.
                If I am successful in my current project, the technology will find it's way to freedom. If I fail, it will never be heard of again. [and nor will I]
    • You're right, a modern metadata file system [Be or newer, not as old as HFS/HFS+] should support MIME filetyping.
      By using MIME, your files will always open in an app that can handle those files regardless of which app made it.

      Of course, this is something I've been doing for a few months now as a vital part of the Kaos operating system.

  • Not a specialized one, no (Score:3, Informative)

    by melquiades ( 314628 ) on Tuesday April 23, 2002 @02:26PM (#3396243) Homepage
    I don't see why you'd want a specialized system is a good idea. Instead, we should ask what general principles might make filesystems work better with music. The obvious ones for music files include:
    • performance (obviously),
    • handling of massive storage (pushing the latest n-bit addressing limit,
    • customizable file metadata (for storing tag information, among other things), and
    • query facilities for the metadata.

    That all sounds like BeFS to me. -- which, lo and behold, was discussed on Slashdot [slashdot.org] just the other day!


    What other general features might be good for the specific application of music?

  • gosh (Score:4, Funny)

    by pb ( 1020 ) on Tuesday April 23, 2002 @02:32PM (#3396295)
    Gee, yeah, who would want file permissions on files, anyhow? Feel free to delete all my MP3's, since they're just music, after all.

    Usually this sort of presentation is up to the application, not the filesystem, and Windows is no exception here. The thing presenting the "My Music" folder with ID3 tags and whatnot is the shell (explorer.exe); it's a graphical file browser. There are many of them available for Linux as well.

    And personally, I don't really care if my file browser supports this, as long as my MP3 player can read ID3 tags...

  • Please generalize that idea (Score:3, Insightful)

    by lightspawn ( 155347 ) on Tuesday April 23, 2002 @02:34PM (#3396318) Homepage
    Music filesystems? Image filesystems? Movie filesystems? Document filesystems?

    And please, please, at least store the file's mime type, don't play the extension guessing game.

    Web server: let's guess what the file's mime type is based on the extension, and send it.
    Browser: Let's guess what this file is, given the extension AND the mime type.
    Stupid computers!
    • isn't this a place where an object oriented database would be perfect? think about it. a database is actually a higher level file system layer on top of another file system layer.
    • Whether you store the type of the file using the MIME type in a filesystem-based metadata, using a creator/type pair like the Macintosh, or encode the metadata into the filename (i.e. filename extensions), this information has one thing in common: It's extrinsic to the data. It can get lost or changed to an incorrect value.
      We have countless examples of how hard this sucks. It ranges from an annoyance for Mac users dealing with files that came through a non-Mac system all the way up to lost time and money when users spread .vbs viruses because Windows hid the filename extension and they think an e-mail attachment is a .jpg file.
      The better way is plain: use an intrinsic property of the data in a file. Put another way: Decide what data a file contains by looking at what data the file contains. That's exactly how the Unix 'file' command works. It matches bit patterns in the file against the "magic" database to determine a file type.
      Of course, there are file types not easily identified by simple bit strings. Starting with v3.0, AmigaOS had it right with the DataTypes system. Part of DataTypes was the 'descriptor' which provided the system with three ways to identify types of data: a bit string, a callback function, and a filename pattern. These three can be combined, as well. Thus, it's possible to identify a JPEG image file by looking at the first four bytes, to tell the difference between an MPEG video stream and an MP3 with the callback function, and to fall back to identifying unstructured files, such as a raw dump of PCM sound data, by filename.
      Why oh why has no other system adopted this cool system?

  • from the endtroducing-the-MFS! dept.


    I thought that it was "introducing [dictionary.com]", but what do I know? Cliff may be using a word that I've not been endtroduced to yet!
  • Another problem that stems from Microsoft assuming it always knows best: You can't change the My Music folder to act like a normal folder. Sometimes when I download music I don't pay attention to the exact filename so I like to sort my music files by date to find the ones I just downloaded. Not an option with the My Music directory. Bleh.

    Mr. Spey

    • Actually, you can sort by date, it just takes a bit of work.

      First, you have to view the My Music folder using details, as opposed to small icon view or whatever you are using. Right click on one of the column headers (such as name, artist, etc.). This will bring up a menu in which you can check date modified and/or date created. Each selection you check will then be added as a detail you can view for each file. Then just click on the date modified or date created column (whichever one you added), and the folder will sort itself accordingly.

      Voila.

    • What's even worse is the My Pictures folder. I migrated from Win98 to XP, and already have a folder for pictures, so i just delete their ready-made folder. The computer has no problem with this. It simply creates another one every time I turn on my computer. And of course I need everything my way so I re-delete that folder. Good thing Windows is so reasonable...
      • I moved my My Music folder from wherever the default is to a different drive. The next time I clicked on a My Music shortcut WinXP looked for and found the moved My Music folder. Something similiar might work for the My Pictures Directory. Dilbert: You're only hearing what you want to hear!

        PHB: Yes, I do look thinner today. It must be the situp I did yesterday.

        Mr. Spey

  • metadata (Score:3, Interesting)

    by Mad Marlin ( 96929 ) <cgore@cgore.com> on Tuesday April 23, 2002 @02:45PM (#3396422) Homepage
    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.

    • The filename is metadata. What you're proposing is merely a clunky way to exploit the minimal metadata the Unix already supports.
    • Please refer to the spec, ID3v2 [id3.org], rather than some notion about an ancient ad-hoc version.
      • Okay, so what do you use to list the year of composition? Do you use the original release year, or oh wait... no, that's defined as the original release year of the recording, not the piece itself. What about pieces which are known to be written in one year, first performed in another, first recorded in another, and remastered in another?

        ID3v2 is still a standard written by people who don't know how classical music works, and don't really seem to care. Hell, they have a place to list the people in pop music's album credits, but they don't have a way to note that a track may be a single movement of a larger composition, the closest you can come is noting the original track number on the cd, which isn't what you really care about anyway.

        • Here is a chain of events:
          1. You bitch about how id3 sucks.
          2. Someone points out you are wrong and provides a link to prove it.
          3. You dont read the link. You complain again that id3 sucks.

          So here we are. Id3v2 allows you to define your own fields, including year of composition, name of the piece that the track belongs to, and what your mother bad for breakfast. Applications can choose which fields they show, and which fields they let you define. So now I will let you complain that id3 sucks because your mp3-application doesn't allow you to specify the year of composition or your mothers breakfast habits.
    • That is as ludicrous as the original question, sir. But i like it!

      Instead of designing a new FS, writing drivers and apps, we could use your kludge.
      A short script could extract the idv3 from the mp3s in folder A, and copy them accross to partition B with a stupid filename. The stupid filename is therefore all the metadata you could ever want to contain.

      Then all you need is a few apps to do whatever you might want with this metadata...... erm, ideas people?
    • Try Ogg Vorbis... it supports extensible metadata. ID3v2 supports it too, I think.
    • Yeesh. If you can say with absolute certainty that you'll never need the command line with your MP3s, I suppose you could go with a hideous monstrosity like that. Personally, I usually don't care about anything except the title and occasionally the artist, so those are what I put as the filename. Filenames still tend to be long, but they aren't impossibly long.

      I think you are also confused about what people mean when they are saying "metadata" in this context. The more common term for it is probably "extended attributes." It provides a trivial mechanism for storing key/value pairs associated with an inode. There's no reason you couldn't have a "Composer" key, or any other kind you wanted.

      A truly intelligent file browser could be configured to display metadata selectively, sort on it, and so on. That may become a reality in Linux as a metadata-capable API emerges.

      I tend to agree that metadata-in-files is a messy approach. It is better to have a distinct source for it, and filesystem-based metadata might be the solution. I guess we'll have to wait and see if it really is.

      • maybe those MP3's are on a mac, or an iPod. Most of my 6 days of MP3's are under 32 chars long.
        Metadata is a better way of doing things, it is possible to use XML for MIME filetyping so that the browser is capable of displaying data in the way you want.

        As for reality of doing it in Linux, you'd need major support by a few major distributers or the main programmers to get the critical support that Linux needs for a projecty such as this to survive.
        I know this is not the party line, but BSD has a better chance of getting this supported as it is a decentralised group of programmers.
        Linus Torvalds is on record as saying that he needs a full time deputy to take care of non-core duties, yet a new filesystem would require the full cooperation of the kernel programmer.
        • Who needs a new filesystem? XFS and JFS both already support metadata in the form of extended attributes (EAs). I'm pretty sure e2fs (and e3fs) both have the stubs in the filesystem for similar functionality.

          Again, let me emphasize: XFS and JFS already can do this. XFS did it first, and the JFS people were primarily waiting for de facto standardization of the API (they will be using the same one as XFS uses). All we need now is for programs to start taking advantage of the existing functionality. In this case, we need programs that provide ID3-like functionality and an mp3/ogg browser that does the same.

          I will concede, however, that we need more people to use EA-capable filesystems for this really to take hold. Changing the "default" filesystem on the major distros would sure do that. But implementing the EA stubs (which may already have been done in 2.5 kernels) for e[23]fs would also do the trick, and pretty much leave Reiser as the only modern Linux FS that (last I checked) doesn't support EAs.

        • for MIME filetyping so that the browser is capable of displaying data in the way you want.

          I actually consider extensions in the filename superior to storing the MIME type, or keeping a seperate extension like in DOS. If you think about it, keeping the MIME type seperate from the filename is exactly the same as the DOS 8.3 format, just a lot longer, say 255.32. The perfect example as to why this is a bad example is file.tar.gz. Making a seperate MIME type for *.tar, *.gz, and *.tar.gz is just plain stupid. What if I want source.c.gz, should we invent a new MIME type? Can different files have the same name if they have different MIME types? If not, how can I have files like paper.LaTeX, paper.dvi, paper.ps and paper.pdf, a situation that exists often with me. If so, how would I tell it to copy one of those files somewhere and not the rest, without using some bad kludge like the name.ext in DOS (probably something like index:text/html).

          I know this is not the party line, but BSD has a better chance of getting this supported as it is a decentralised group of programmers.

          I have no trouble believing that, if this was a good idea, it would show up in BSD before Linux. On a related note, I use FreeBSD, not Linux.

  • Nautilus (Score:2, Informative)

    by xiox ( 66483 )
    Nautilus has a music view, where it shoes the id3 tags as if it was an album sleeve. I'm not sure whether this is searchable though.

  • Use a database (Score:2, Insightful)

    by janke ( 49443 )
    Setting up a specialized filesystem for music storage seems both overkill in terms of implementation and maintenance issues, and underkill in terms of features. What would be more appropriate is a database table schema that stored music and lots of metadata (Artist info, title/album/recording/remix/venue info about a track, genre information, record label, user ratings/comments) about different recordings, storing the recordings themselves as either BLOBS of mp3s/oggs or (probably better) indexes into a normal filesystem containing the mp3s. Write a quick table browser to go through the collection, and construct a bunch of SQL queries to generate playlists by artist or genre.
    • How about a database filesystem, like MySQLFS [no.spam.ee] (mentioned on slashdot [slashdot.org] along with BeOS filesystem).

      The only problem is, this project appears dead in the water. If anyone knows of an equivelant system, for this or another database, I'd like to know. It makes a neat way of being able to do queries, and still access the files directly through the FS. You can even end up with dirs containing all the files in your query, then just use that directory to input to whatever program you like - nice.

  • Building a file system just for MP3? BAD idea!

    Storing metadata about files in the file system? Could be useful...

    And of course it's already been done... [bestbits.at]

  • I suspect having a filesystem optimized for one specific data type is possibly a bad idea. Every so often I need to temporarily drop a file into my MP3 partition for some reason.

    Also you need to store .txt and .jpg files in a lot of music folders (track listing and cover art)

    Anyhow, my main point was this: Can I be the first person to point out that BeFS was/is superb at this?
  • I think that this problem would be better solved not by a new filesystem, which means implementing a new kernel module for what is essentially a file symantics problem, but by a module to Nautilus, or whatever your favorite filebrowser is, that looks for ID3 tags and displays those.

    If you do it at the FS level, you would also have to rewrite things like ls and change the way the stat ioctl works, which would break the posix compliance OS. In short, you'd have to modify a ton of stuff just to get id3 tags to display, not to mention that once you got it all working, you'd have to track the development of all the newest FS features like journaling because people are going to want all that stuff to store their mp3s too.

    It would be much easier just to have your filebrowser do it for you, and let the filesystem do its job: store files.
    • Not necessarily. You could have the file system so it can be accessed "the old fasioned way". And programs that support the new features will be able to take advantage of them as well.

      For example: The file system has all the usual info about an MP3 and when a legacy application wants to read a file from it it can generate a filename on the fly like: <artist>-<song>.mp3 or whatever. And directories could also be created on the fly for /artist/album, etc.

      Personally I don't see any advantages of a music filesystem over a regular file system, but I think the idea is an interesting one. Maybe there are other applications out there that would benifit with a unique file system, but instead are using a kludge on a regular file system. What if music was stored in a CDDA format allowing a simple copying of the data to a CD when you want to create a CD of your music? What if your regular file system was steganographed on top of your music collection? Twice the space for half the price!

      We must not let our old ideals stifle innovation. Backwards compatability can usually be achived and a new format might have added benifits that have not even been explored yet.

  • Metadata directories (Score:5, Interesting)

    by pthisis ( 27352 ) on Tuesday April 23, 2002 @04:07PM (#3397120) Homepage Journal
    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
    • The approach you describe is a workable solution for existing file systems, but hardly an ideal solution. Every key name/value pair--being a file--will take up one cluster, regardless of how much data it actually contains. This could easily be 2K or 4K just to store a boolean. Besides, you then still have to worry about doing full text indexing if you want to perform meaningful queries on all these "metadata" files. As I said, it's a workable approach for grafting extensible metadata onto an existing FS, but it's not how you would design an ideal from-scratch FS.
      • So instead of using a directory and file structure like Next, lets modify it and use a compressed archive and file structure setup just like the Next system.

      • Re:Metadata directories (Score:4)

        by pthisis ( 27352 ) on Tuesday April 23, 2002 @06:25PM (#3398045) Homepage Journal
        Every key name/value pair--being a file--will take up one cluster, regardless of how much data it actually contains

        Not if your filesystem has decent support for small files, like e.g. ReiserFS or some of the recent ext2 devel branches. This is one thing ReiserFS definitely got right (though I'm less sure about the direction they're taking for ReiserFSv4).

        As I said, it's a workable approach for grafting extensible metadata onto an existing FS, but it's not how you would design an ideal from-scratch FS.

        It's definitely how I would design an ideal from-scratch FS. Metadata in the FS is a really horrible hack that goes against all the namespace unification efforts that OS designers have been making in the last 10-15 years.

        Sumner
        • > It's definitely how I would design an ideal from-scratch FS.

          Well, the trend seems to be to make the whole FS a relational database anyway. It will be interesting to watch FS developments over the next five years. Of course, the initial efforts seem to be towards a relational DB FS on top of a legacy FS (seems that's what MS is doing with their SQL IFS), but long-term I guess you would see the FS store the DB straight to the metal.
        • Good call on the single-cluster angle, but the folks at Alesis [alesis.com] already beat you to it. Their ADAT HD24 [alesis.com] IDE harddisk recorder uses a proprietary filesystem of Alesis' own design - FST - that does pretty much what you described. From the HD24 FAQ:
          The Alesis ADAT File Streaming Technology, or ADAT/FST, records onto hard drives in a unique way designed from the ground up for multitrack audio. Many other hard disk recorders use the Microsoft-designed FAT32 or Apple's HFS+ file format. Since these were originally designed for the relatively small data files used in personal computers, not for real-time multitrack recording and playback, they break up audio into many small files scattered across the disk. Alesis ADAT/FST keeps all the tracks of a song in large associated clusters on the hard disk, so the disk doesn't have to "hunt" all over during recording and playback.
          It's a pretty dope HD multitracker, too, it has an ethernet port and is mountable as an FTP server.
          • Good call on the single-cluster angle, but the folks at Alesis [alesis.com] already beat you to it.

            It's not an issue of getting beat to it, it's a really old idea. Heck, ReiserFS was hardly the first and they've done it for over 5 years. ext2 hasn't, but there is some movement in that direction.

            Sumner
      • How about using something like zip or tar to archive each of these smaller files for storage purposes, then having the file browser peek inside the tar and display the user the correct view. Actually, I think that something like customized tar files would be a good file format for many applications, so that metadata and data could be separated but stored together for efficiency. Most proprietary file formats use a principle somewhat like this anyhow, such as the existing ID3 tags in mp3 files.
  • Whatever it may be, old fs, new fs, database... how about a feature where you can assign a code or symbol or something that would allow it to find music that has some feature or charateristic as to what your currently listening to.

    I like the idea of saying "Play Happy/Sad/Fast/Uplifting songs like <song>"

    Yeah, I'm dreaming... so what?
  • (and got the t-shirt)

    BeOS (god rest its soul) uses the Be Filesystem, or BFS. It is a 64-bit journalling and indexing filesystem. It is essentially a filesystem that works much like a database. You can attach any number of arbitrary attributes to any file. Filetyping is handled by MIME filetypes, which are also stored as attributes. The default BeOS installation includes all of the usual attributes for music files and it is very easy to add many more. The BeOS "find file" tool is not unlike a database query tool.

    In terms of speed, file searches are done almost instantaneously, even when searching through several gigs of data.
  • I'm running Win2K Pro SP2 SRP1 and I don't have any special folders for digital media...let alone displaying with ID3 tags!

    This sounds like it's a Windows XP thing, and we all know that XP is the devil.
    • umm, actually you do. You just haven't enabled it. As a previous poster noted, open explorer, browse to a given directory, then on the menu click on View->Choose Columns, you will be able to add any music, video, or other attributes listed. What I would like to know, is it possible to add new attributes by writing a dll or a reg hack or something? Anybody?

  • Nautilus (Score:2, Informative)

    by mobydobius ( 237311 )
    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

    I don't think this has anything to do with the Windows file system. Its just how explorer presents data in certain folders. Nautilus does the exact same thing, for instance. It displays bitrate, time, artist, and presents a mini-player at the bottom of the folder view. I assume it gets the artist info from ID3 tags.
  • (Write-Once-Read-Many)

    A dedicated music partition would probably have files dumped on to it in large chunks, without much deletion or other write activities being performed on it otherwise.

    So, just making sure files aren't fragmented when they're dumped on the partition, and maybe caching things like ID3 tags would be useful.

    Is there really a problem to address, though?
    • This depends on from where your mp3's come. If you download them, they most likely are obtained a little bit at a time, and probably need to be fixed (ID3 tag inaccuracies are very common) or deleted (so are incomplete or corrupted files) at some point after they are written.
  • So I have lots of mp3s too. Here's how I organize them (they're served off my main FreeBSD box, this won't work in windows):

    I organize them into subdirectories, etc. with a standard naming convention. Nothing new here; everybody does this.

    The problem I found is that my playlists would break whenever a renamed or moved a file.

    Solution:

    1. Create a directory /mp3/lists
    2. Create a subdirectory for each playlist: /mp3/lists/touchy-feely, /mp3/lists/hard core-punk, etc.
    3. Each song for a playlist is symlinked into the playlist directory. Eg, "/mp3/lists/hardcore-punk/Sex Pistols - Anarchy in the UK.mp3" points to "../../70s/Sex Pistols/Sex Pistols - Anarchy in the UK.mp3".
      NB the relative, not absolute, symlink: this allows me to serve up the lists over NFS, SMB, etc.
    4. I have another directory /mp3/lists/md5 which contains the md5 sum of every actual file and every symlink. Point being: when I rename a file, I get a stale link. I can fix the link by comparing the MD5 of the old link to every other MD5.
    5. I have a nice perl script that automates all of this, so that whenever I add, delete, rename, move an mp3, all the playlists get automatically updated once I type "cd /mp3/lists ; make". It also does other miscellaneous things like creating the "all.m3u" playlist automatically and randomizing the playlists. It's actually a bit more complex than this since I've optimized it (eg, the MD5s are sorted for quick search and are never needlessly regenerated, etc).

    Altogether a very easy, powerful and flexible system. If something goes wrong, it's just standard files and directories, so I can fix it without editing inodes or dropping into an SQL shell.

    A trick you should also know is that just taking the MD5 of an mp3 does work very well since the ID3 is also part of the mp3 and it might change. So I take the MD5 of the last megabyte of mp3 files (the ID3 tag is near the beginning of the file).

    One could easily extend the perl script to use ID3 tags to generate directories and playlists. Oh, and the reason I do it this way is because Konqueror is a very nice visual file manager and it allows creating symlinks easily (albeit absolute ones, but my script fixes that).

    Anyway, hope these ideas help. Taking the problem down to the filesystem level introduces all sorts of complexity while the problem can easily be solved by a couple hundred lines of perl (writing perl scripts is much easier than kernel work, trust me). Right tool for the right job and all that. This only took me one night to throw together (this includes organizing the actual playlists, which took the most time).

    I also have lots of pr0n, and I'm working on ways to automate pr0n management. Let me know and I can get back to you once I've solved the problem.

  • with virtual file systems being de rigeur this is exactly the sort of application plan9 [bell-labs.com] would be good at.

    But we're stuck with 23 char filenames until the eagerly awaited 9p2000 as I discovered the day I statrted to move my mp3s over, doh!
  • Why not store the music separate from the meta data, in big hunks of the disk? Like one poster mentioned, the music doesn't really change once deposited in the filesystem; only the metadata does. So we could store music in arbitrary places on the disk, and then have the metadata categorize it, give it names, etc.

    The filesystem would then transparently re-create the MP3 file when copied out to move it across the network, zip file, etc... by attaching the meta-data back onto the music stream as it is ready from disk.

    Thoughts?
  • Didn't I see something on Slashdot once about someone getting a database to mount as a filesystem?? If the MP3's (or Oog's) could be stored in that database.... wouldn't it be the start of something useful???

    Then again... what the hell do I know..
  • What Im thinking of writing is a database system which will sweep through all my mp3's cataloging anything new. I also want to add a little app that I can have running that will allow me to add to the database what I think of each song. As it is I have my xmms set up to dump the name of a song to ~/mp3 and the path/filename of the song to ~/mp3filename. All I will need is to have the app pickup the ~/mp3filename contents and take it along with my comments about the song to the database. I also think a little app, maybe connected to the previous that will generate a playlist for xmms based on the type of songs I want to hear. I typically catagorize my cds this way in my cd cases. I have Christian-ROCK Christian-underground Christian-boring Christian-i bought it at a concert and found out i didnt like it.. ROCK, POP, MIX, soundtracks, soundtracks that didnt end up in the movie itself. I also sort of know the cds i want to listen to by the type of mood they induce, Mellow(like Olive), Racy(Linkin park), Feel like singing with it(like redhot chilli peppers or creed). I want my database apps to be able to pull those files attribuited like that out for times when I feel like whatever. DRACO-
    • WHy bother with writing a new database when there is CDDB or Open CDDB online? you can submit new songs or get track names to any CD (or song submitted) for free.

      ID3 tags are in most modern MP3 players, the catagory you want is Religious.
      [which covers diet rock, evangelism, boring crap, stuff that sucks and blows at the same time & annoying tunes you hear in elevators]
      You could also put mood music in Unclassifiable, which is useful if you are currently listening to stuff you'd hate to hear when you grow up.
  • One could have a standard attribute file that can be automatically updated as files are moved.

    One idea would be to do this on a directory by directory basis (like 4dos descriptions), this would overcome the mapping problem. If each file type has its own header, then you could store current and future formats in this.

    One can have a utility to go through and look at files by type, eg like a "viewer" dll.

    Backing up such a file would allow the support of this feature on cdroms under different operating systems.

Slashdot Top Deals

He has not acquired a fortune; the fortune has acquired him. -- Bion

Close