Re: [slug-chat] Coding, strings, crack, MUSIC!

[Crossfire <xfire@xxxxxxxx>]

Jeff Waugh was once rumoured to have said:
> Morning all,
> 
> So, I have a little coding problem to play with, and I'm looking for a few
> hints. [ You'll have to remember that I'm an interface person, not an
> outragously good coder! ]
> 
> Problem: Playlist managers for music players suck. What I'd like to create
> is an efficient substring searcher for both filenames and attached metadata
> (such as ID3 tags), so a list of 8000 tracks can be cut down to two or three
> in a very short amount of time.

My solution for this at work partially was reiserfs - find runs a LOT
faster against a large reiser tree than it does against the same ext2
file tree.  Of course, that doesn't help with metadata.

[The scenario at my workplace is that we have about 24GBs of MP3s in a
 central shared repository]

> The idea of a suffix tree appeals to me, but it seems like overkill. It can
> be rationalised though, in that the application isn't just a casual music
> player, and this is its most important feature. (I envisage this as
> something you'd invoke and leave running for most of the time, or the
> innards of a music playing server or whatever.)

Does file-change notification work yet? :)

I was thinking schedulable job to run over the tree and index the
metadata along side path data into some form of searchable databse.
You then have some form of requester mechanism to run through and find
specific matches.

Of course, this has an even lower priority that id3tool2 on my list of
things to do.  *bleh* [I need to get id3tool2 done so I can index
ID3v2 metadata]

> Can anyone tip me off with a better method or data structure for this?

Look at the ID3v1 and ID3v2 structures - they should give you a good
idea of what metadata is availible when its all implemented - of
course, that is if they don't give you nightmares first. ;)

Nobody really implements ID3v2 that I've seen yet, which is a bit of a
pain.  But ID3v2 is a lesser monstrosity to process and edit since its
located at the start of the file, rather than the end.  It also
doesn't help that the main library to parse it in C does suck somewhat
from the flexibility/versitility point of view - which is also why
id3tool2 still doesn't exist.

Most of my ideas for dealing with this were tied to my concept of
building a `distributed' media playback system which could be
distributed over a `wired' house.  Of course, yet more vapour - and
too few of my ideas exist on paper - I really need to clone myself a
few times over to get all this stuff done ;)

The general concept is that you no longer worry about data
specifically - but you deal in terms of media - your digitially
distributable media is stored on Media-servers, and your localised
[non-distributable] media is tied against media-playback devices.
[I'm not talking copyright protected stuff - I'm talking the simple
difference between an mp3 file and an audio CD - we can't magically
zap that audio CD from one drive to another :)]. The grand scheme of
things was to then be able to control the media devices (be it a CD
player, MP3 player, OGG player, etc) remotely using any system on the
network.  If you want to hear a particular song, you search for it,
and the system locates either a media-player with it dirrectly
attached, or a digital media store which has it - and if its digital
media, you can then stream it to the nearest capable player so you can
listen to it in without having to move :)

Oh, and *everything* in the system has metadata of some form - since
its hard to effectively locate accurate matches in media databases
without it.  I id3v1 tag all my mp3s anyway, so I wasn't worried about
that side of things.

I thought it was a nice idea - but it would take too much time to
implement, and I don't actually have much of a use for it since I live
in a studio apartment on my own at the moment - The idea was really
more geared towards living in a geek share-house.

C.
-- 
--==============================================--
  Crossfire      | This email was brought to you
  xfire@xxxxxxxx | on 100% Recycled Electrons
--==============================================--