From: <mar...@cl...> - 2006-02-14 10:42:30
|
Not atall - in fact since I've now been sucked into this I suppose I shoul= d be using the CVS Head version anyway=21=21 :-) Two things I've discovered: 1) UDS=5FEXTRA DOES work - if you add ExtraNames and ExtraTypes to the pro= tocol file, and Extra1, Extra2 (etc) to the Listing line (see the Trash pr= otocol for an example). 2) You can specify the URL differently from the displayed file name - usin= g UDS=5FURL. Now, taking a leaf from njstream, therefore, we could start refering to tr= acks internally as njb:/track/123456, use that in the tracks UDS=5FURL ato= m, use the UDS=5FNAME atom for the track name and UDS=5FEXTRA atoms for Ar= tist,Album,Year etc etc. I've already got the =22Test 1=22 and =22Test 2=22 (previously commented) = EXTRAs in njb.cpp to work, and dinked with the URL of an info html file I'= ve locally added - so POC done. I'll start the real coding if y'all agree = to the ideas at the next opportunity (probably later in the week). Martin ----Message d'origine---- >Sujet: Re: =5BKionjb-devel=5D Re: A bug, a patch, and bunch of >De: ace jones <ace.j=40hotpop.com> >A: kionjb-devel=40lists.sourceforge.net >Copie =E0: =22martin.bartlett=40club-internet.fr=22 <martin.bartlett=40cl= ub-internet.fr> >Date: Mon, 13 Feb 2006 22:22:19 -0800 > >On Mon, 2006-02-13 at 13:14, Rob Walker wrote: >> On Monday 13 February 2006 16:48, Shaun Jackman wrote: >> > On 2/13/06, martin.bartlett=40club-internet.fr >> > <martin.bartlett=40club-internet.fr> wrote: >> > > Forgot to mention the tag stuff - gnomad2 and njstream handle tags = and >> > > song-length from wma using the same routine - this could very easil= y be >> > > adapted to kio, which, again, I can handle (with three projects usi= ng it >> > > maybe it should be a library now=21=21). >> > >> > The tag and track length code in kionjb definitely needs a rewrite. >> > Gnomad2 and kionjb each use id3lib for its tags. That it's very nearl= y >> > true that id3lib needs a wrapper library to actually *use* is rather >> > quite frightening. So much of the over-generalization. The track >> > length calculating code must already exist in a library. A small MP3 >> > decoding library would have to have this facility. >> = >> The length code in 0.2.x was modified by me to handle VBR files, using = the mp3 = >> specs. It works OK for the MP3 files I have, but if there's something = more = >> robust then we should use that. >> = >> The way we use artist and track name (and sometimes the album) to iden= tify = >> tracks instead of the unique jukebox ID could also use some work. When= you = >> have live or remix albums, then it's a bit of a lottery as to which fil= e is = >> accessed (or deleted=21) in the njb:/all/ and njb:/artists/Artist/ dire= ctories. = >> Unfortunately, I don't think theres an easy way to use the unique IDs w= ithout = >> exposing them to the user. > >Yes, with Rob's change, MP3 length calculation has been flawless for me. > >Martin, would you mind making this patch against CVS HEAD? Apparently >it's changed too much for the patch to apply directly. > ></Ace> > >-- = >GPG Public Key: http://keyserver.net:11371/search?q=3D0xF540E55B >Fingerprint: 3CA8 1A24 B52F 4FCA C22D 0E2F 0AF0 4EE1 F540 E55B > |