RE: Web interface prototype

www.ibamba.net/slimp3 

Regarding the cover art: I don't know anything about the ID3
specification, but I'm guessing that it provides for album art to be
embedded with the track. MusicMatch allows me to tag tracks with album
art, and it's apparently embedded in the mp3 file (there are no separate
files generated, and if I move an individual mp3 file to another
computer, the art goes with it).

Pulling the album art from the web would be cool too - I've had to spend
a lot of time in MMJB tagging tracks with the album art, and it would be
great if it found them automatically instead. Perhaps the server could
look for album art in the file, and if it's not there then get it
online.

Regarding performance issues when retrieving thousands of tracks: I
would assume that users would change the "view by" settings
infrequently, and it would be OK if there was a 3-4 second delay. I
don't know what sort of data architecture the server uses, but in my
experience sorting & grouping even 20,000 records, formatting them, and
pushing the HTML out on a LAN should be a trivial task & shouldn't take
longer than a couple of seconds. Fat-client players (MMJB, iTunes, etc.)
don't make you page--your whole collection is there for you to scroll
through from top to bottom--and there's no reason why a thin-client
player running on a LAN should.

One approach that would lighten the demand on the server's processor
would be to generate a static text file for each possible view
(Genre:Album, Artist:Album, Album, etc.) of the music library and store
it in the server's file system. These would be regenerated only when the
music library was recatalogued (which should be very infrequent). The
server could then just send the appropriate file to the browser on
request. XML & XSLT would be ideal for this. Again, I'm totally ignorant
of how the server currently works with data, so this may or may not make
sense.

My experience with DHTML is exclusively as a client-side technology; if
there's a way to have it pull new data from the server without
refreshing the page, I'm not aware of it. I still think your best bet
would be to send the browser track info for every single track in the
library, and show/hide tracks on the client according to the + and -
buttons the user presses. 

As for the progress bar, I think there's probably a way to do it with
client-side JavaScript & no refreshes. I can work on that.
 
I'm unclear on what the difficulty would be with the volume display -
each bar is simply a 1-pixel gif sized appropriately, and each would
have its own <a> tag so that clicking on the 3rd bar sets the volume to
3, the 11th bar sets it to 11, etc. 

One other note - you'll notice that the Player drop-down (upper right
hand corner) has an option for "All (Sync)" - I'd like to be able to
choose that from the web interface in order to synchronize all players.
Right now, if I'm using the web interface and I want to play the same
thing on both clients, I have to set up my playlist for one client, then
go to the other one and tell it to synchronize, which restarts the track
if it's already started playing - it's clumsy.  

Cheers
Herb





------------------------ Yahoo! Groups Sponsor ---------------------~-->
Get 128 Bit SSL Encryption!
http://us.click.yahoo.com/FpY02D/vN2EAA/xGHJAA/rIp0lB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
[email protected]

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/