Sean, PLEASE forgive my ignorance on this topic, but I'm interested because I am setting up a new dedicated server on a 3G wireless network for a new SB2 and am making format decisions. Specifically, this discussion of meta-data for the file has me interested. Is this basic track, album and articst information, or are you discussing additional information beyond this? I'm trying to decide whether to keep the server as is with Win XP and copy my files over in their current state as WMA lossless or re-rip or convert everything to FLAC. I was also considering the radical step of using a Linux Deb distro for the server in conjunction with FLAC and bagging Win XP altogether. However, this and some other research are giving me some second thoughts. From this and other discussions here, it seems that FLAC files can be difficult to create and manage. If the info you are talking about is the title/album/track/genre stuff, I find Win Media player retrieves it pretty reliably and ripping is super easy. Forgetting my inherent dislike of MS, if it's really that much more of a pain to manage ripping and tagging in FLAC, what's the advantage other than open format? Help me out here! :-) Mike -----Original Message----- From: Sean Goller [mailto:[EMAIL PROTECTED] Sent: Wed 4/6/2005 9:23 PM To: Slim Devices Discussion Cc: Subject: Re: [slim] metadata musings
michael wrote:
> Sean Goller <[EMAIL PROTECTED]> writes:
> ...
>
>>>>Right now I'm just trying to see if someone's got an existing schema
>>>>that gets me 90% of the way there so I can get things up and running
>>>>reasonably quickly. If I can do that, then I can see if I can make
>>>>slimserver deal with the archive setup. That gets me a fairly robust
>>>>music archive/jukebox like thing.
>>>
>>>For what it's worth, slimserver will read a musicbrainz xml
>>>description of the flac file out of an app block. The thing that
>>>isn't available yet is a tool to insert the xml into the flac. But
>>>I'm sure it would be easy to make it read an external version of that
>>>xml as well. And the tools to pull the data from musicbrainz would
>>>lend themselves well to inclusion in an automated system like what
you
>>>describe.
>
> ...
>
>>Err, could you expand on that a bit? Do you mean the xml description
>>of the cd represented by the flac file?
>
>
> yes.
>
>
>>I've been futzing with the
>>internal guts of libmusicbrainz all day, and I have code now that
>>generates the proper musicbrainz DiscID given an flac-generated (NOT
>>EAC) cuesheet text file. Now I'm working on turning that into code
>>that just extracts the cuesheet data from the image itself and
>>bypasses the whole textfile step.
>
>
> Would you be willing to share what you've put together? I've been
> working on the same thing, but so far my calculated DiscID doesn't
> match the one cdlookup returns.
>
Certainly. I managed to get a version working that operates directly on
the flac image. I'll warn you, it's frankensteined all to hell C code
and doesn't properly deal with byte order issues automatically. (the
code I'm putting up will work properly out of the box on x86) but it
gets the job done. It's at http://www.goller.net/imageid/imageid.tar.gz
I think the next step is to use the musicbrainz DiscID object to do the
generation instead, because I missed that on my first pass through the
library, and it's easier if musicbrainz maintains that particular part
of the code instead of me, or whomever. :)
>
>>So with respect to fetching things from musicbrainz, I'm at
>>http://musicbrainz.org/cdindex/69WPuFcKSoXA4Trt1kY4tGSg6Vo- here with
>>my test disc/image. How does that relate to what you're talking about?
>>Are you talking about the information at:
>>http://mm.musicbrainz.org/mm-2.1/album/94348021-7c03-4a58-bfcb-ee865f449200
>>?
>
>
> Essentially, but it needs to go one level of detail deeper than the
> web page does. (when you're querying their server directly, you can
> specify how deep to go.) So the result you're looking for in this case
> would look like the example I've attached.
>
Could you give me the actual url used to fetch that example? I'm being
dim I know, but it would help me out. :)
>
>>If so that means all that's left is some way of transforming a DiscID
>>into a GUID. Scanning musicbrainz' wiki, it looks like
>>MBQ_GetCDInfoFromCDIndexId will get me a list of album GUIDs that are
>>linked to that DiscId, which gets me the RDF url above.
>
>
> Sounds like you're on the right track. The only tricky bit is that to
> get both the album and the song detail, you have to query the server
> directly. (or at least I haven't found an easy way to do it through
> the web interface.)
>
> Now all you need to do it either stuff that xml into an application
> block in your flac, or modify slim server to recognise it external to
> your flac file. :)
>
> I hope that helps.
>
> -michael
That works. It seems to me that the simplest thing to do for a "new"
flac image would be to calculate the CDIndexId then fetch the metadata
from musicbrainz, caching it all in an external source (filesystem or
db) for future reference and keep the file itself pristine. This is one
way of automatically fixing the "outdated tags" problem that users of
metadata storage sites like musicbrainz have, with no ambiguity. If
SlimServer refetches the metadata once every N image references (20?
100?) then you're guaranteed to have about as up to date information as
you're going to get. (without pissing off musicbrainz for eating all
their bandwidth, that is)
So since all this discussion is in the context of SlimServer, I guess
the way forward (at least from what I'm interested in) is to use the
perl module for accessing FLAC internal cuesheets, tie that to either a
perl binding to the musicbrainz DiscId object (best choice) or a
separate implementation of CDIndexId generation (reasonable) and then
use that as a basis for obtaining metadata within the server.
-Sean.
_______________________________________________
Discuss mailing list
[email protected]
http://lists.slimdevices.com/lists/listinfo/discuss
<<winmail.dat>>
_______________________________________________ Discuss mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/discuss
