Oh man, we're pulling the gloves off aren't we weed. OK, let's tango then.
MP3 is limited to 2 channel stereo. So is wav, so are most other audio formats. If you want to do something with multichannel awesomeness automatically like let's say...
YouTube - Freestyle Don't stop the rock, Reaper Reavocode
THIS!
You'll need to step into the realm of multiple files, or even multiple file formats.
Now sure, you can store these files in subfolders, easy enough. Even from a programming perspective, it's much easier to not have to demux some container before sending **** out to your decoders BUT..
End users want:
awesomeness automatically
Automatic awesomeness will not happen if I have to tell my end user "Hey, you have to download this file here, and this file there, then assemble the files all together in this directory" Nah, they just want to deal with one file, and it it only takes another week or two to support a container format, then from a end user usability standpoint, it shouldn't matter what my technical opinion is. Not everyone is as smart as me, and I shouldn't expect them to be either.
Now let's get back into the mp3+g zipped realm of today,
In most media players, they use a flat file database with no relational tables. Winamp is an awesome example of this. This is fine if you're just going to cue up songs. On the other hand, if you want to truly expose the winamp UI and API system for something like uhhm, putting a persons name on the Winamp Playlist next to thier song, you have to play by Winamps rules.
So in a flat file database we have..
c:\music\america.mp3 bob
c:\music\amazing.mp3 grace
c:\music\anarchy.mp3 frank
What happens if frank decides to sing america as well? In a flat file, non relational database you get screwed, thats what.
On the other hand, if you had these files in a container format, then copied the mp3 from the container to a temp directory, the flat file database stays happy because you can do things like
c:\temp\frank\09td953\america.mp3 frank
c:\temp\grace\0gfd44s\america.mp3 grace
c:\temp\bob\gy435fdv\america.mp3 bob
I'm also going to point out that of all the Winamp based hosters, we were the only ones that took into account how to work with winamp, keep the winamp skin/look/feel. Sure, we could have taken the short route of making a hosting system with a non relational db outside of the winamp media library DB, but we felt that this was cheating the end user by telling them "You have to run 2 apps, winamp and my butt ugly frontend"
End users don't want to have to run a bunch of things to host karaoke. They don't want to have to worry about multiple file pairs. It's just easier. For us, there's not really a performance hit either. It's not a huge annoying thing to code it if it makes the end users happy. If you want to keep arguing it though thats cool, i'll be home all day watching my kid tomorrow so I got plenty of time to fire posts back and forth.