Well without a tree structure you're still going to have an issue with the names.

Personally I use Album Artist/Album/DiscTrack. Artist - Title.ext

But say we did away with folders - you'd have to put all that data in the filenames to sort properly anyway!

Naaaaaah, you'd just have metadata!

I think the last time I used the filesystem to browse my music was in 2003. And it was dreadful. I use a music library app in which I can decide which way my music is ordered. Albums from oldest to youngest? No problem. Artists alphabetically? Sure thing. Artists alphabetically and their albums in chronological order? No problem.

The music library app is especially tuned for ways to view my music that make sense for music. It makes those easily accessible. The file system is wholly inadequate for that task.

The library app takes care of the underlying folder structure – but that’s an implementation detail I absolutely do not care about. I don’t even know how it looks. (I just looked it up, it’s “Artist” – “Album”, the same structure I used before I started using a library app.)

I’m not sure that the file system is really so bad (at least I’m relatively comfortable with it) but I do think that for certain specialized tasks it’s massively preferable to have dedicated apps. Music and photos are my two prime examples.

"Albums from oldest to youngest? No problem. Artists alphabetically? Sure thing. Artists alphabetically and their albums in chronological order? No problem."

from the "to each his own" file: i have never understood why anyone would care about sorting their music in any of these ways. To me, none of these are ways to "view my music that make sense for music." On the other hand, I find a directory structure for albums and everything else chucked into a giant directory to work just fine, as it supports the sort order I do sometimes care about, mtime. Normal search tools like locate work pretty well too.

In previous comments on related articles on HN, I have pointed out that files, and to a lesser extent directories, are good because they serve as a universal protocol-of-sorts for dealing w/ blobs of data. That allows you to use the system that works for you, and me to use the system that works for me, and yet we can still share files and move between systems etc. with little headache.

I am actually sympathetic to moving to a tag-like system that supports hierarchical tags (gmail style), so that multiple organizational structures can be imposed onto a mess of files. I also find it funny that that's more or less how unix file systems work under the hood.

All of these music filing schemes fail miserably when confronted by Classical music. There you often have four 'obvious' candidates for leading tag---composer, performer, conductor, title etc. There is even an entertaining amount of discussion on the net about the best way to solve the problem. The only point of commonality accepted is that the iTunes approach simply does not work. Then every one starts to bang their personal agenda drums; all sadly out of sync. And this for a subject that every one 'knows' Move into other areas and you will find similar problems. This does not even begin to touch the problem of tagging as a speed bump---takes time, ask a librarian :)

How much music do you have? 100 songs?

I have 5,380 titles, I cannot for the life of me imagine how to deal with that inside the confines of the file system. I want to browse my music. (It probably doesn’t help that I despise search. Search is no alternative to browsing for me.)

(Besides: This is not some evil scheme. Metadata for music is completely standard. My music library app – and every popular music library app – puts music in straightforward human-readable folders. That’s a nice fallback if all else fails – but to me it is just that. A fallback.)

I have 3575 music files on my current main hard drive, organized by hand into an /Artist/Year - Album Title/File.ext structure just fine. I don't listen to classical music or by genres, though.

I have around 69,000 and I find that due to the fact that most music players choke on that amount, that often sorting by filename is one of the fastest ways to get my music into a decent order.

Also in response to other post - you can quickly rename your music with something like Musicbrainz Picard (cross platform) or foobar2000 (Windows).

for the record, I too have about 5000 tracks these days.

I use both. I've got about 10,000 tracks sorted as Artist - Album/Song.ext in the filesystem. Since I'm a bit of a geek about my music anyway I remember which song is where anyway and if not, there's still find.

In the music player (mpd + ncmpcpp as a client) everything's sorted using tags so I can do all the searches I ever want quickly.

The filesystem way of storing things is merely about redundancy and whenever I want to copy stuff onto an external device. I do not want to use an app to sync stuff onto my smartphone. That's just an extra app for a trivial task. Additionally it provides me with a tad more control. And seriously? I couldn't care less about copying over all MP3s recorded by a band Z in year X belonging to genre Y (or some other sort of query). When I copy music to the phone I'll copy albums and that's what this file structure is absolutely perfect for.

Don’t you browse your music? I’m very particular about my music collection and I definitely need to browse it. Sometimes I just do not know what I want to listen to, so search is useless. And looking at something like all albums from 2009 (because I know some good music came out then) can be very useful for me.

I do not care about the structure on the disc. I use my music library app to browse.

I said that many things are well represented by trees, not all things...

And we sort-of already have WinFS, in the form of full-text indexes on file systems.

We have nothing like WinFS in practice, we don't think or use our filesystem as if it was a database. That is the key difference, not the implementation.