probedb wrote: > It isn't....and you just changed the goalposts. Let's take just one > track from my collection: > > Artist Name: 65daysofstatic > Track Title: The Distant & Mechanised Glow of Eastern European Dance > Parties > Album Title: The Destruction of Small Ideas > > ...just broke your reasonable limit and that's without anything > including track number, genre, date, total tracks or any number of other > common fields. yes you have shorter fields but 100 as a reasonable > average, come on I think not. The track title may be slightly longer > than average but the Artist Name and Album Title certainly aren't. > > My collection is very well organised thanks.
I wasn't referring to how you might organise your collection, just how a to well organise an in-memory database for efficient use of memory... Ok, some numbers from my modest and motley collection of 14000 odd tracks. It's mostly full albums, with plenty of long names like above. Also a large number of compilations (i.e. different artists per track), a lot of classical (few tracks per work/album, with long track names), and for a large proportion of the tracks there are multiple artists (composer, 'featuring' etc) per track. These numbers come from my own LMS controller app I did ages ago for Symbian, where the full track/artist/album/genre/year data is downloaded from LMS and stored in-memory in the phone. So, for 13828 tracks, 6304 artists, 1159 albums, 63 genres, 52 years, there are 424480 bytes of UTF8 strings. That's only 31 bytes per track. Added to that is all the indexing stuff to link the tracks,artists,albums,genres and years together (including track numbers) - that comes to another 400kB for what I had. Still only 60 bytes per track. For a fully functional music server database you'd want file format, duration, volume adjustments, date, etc, but that is still not a lot of data in binary form. The biggest thing, and the thing I've missed here, is the file path, which is probably well over 100 bytes. Still, even there there are simple things that can be done to reduce the storage required, like storing common directories separately and other very simple compression. The point I'm trying to make here is that if you have a cheap and very memory constrained processor, you can still handle an in-memory database of a very large number of tracks in what is a pretty small amount of memory these days if you try. Also, for a Sonos-like system where every node holds a copy of the database, the whole of a millon track database could be synced over the network in a few seconds. Including to smartphone controller apps. So going back to the start of the thread, 64 - 80k track limits are pretty feeble. So now I'm wondering what's actually in the 48MB of my LMS library.db file... ------------------------------------------------------------------------ utgg's Profile: http://forums.slimdevices.com/member.php?userid=40900 View this thread: http://forums.slimdevices.com/showthread.php?t=103488 _______________________________________________ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
