Sean Goller <[EMAIL PROTECTED]> writes: ... >>>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
Thanks. I'll take a look at that and see if it reveal what I've been doing wrong in mine. > 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. :) Yeah, I tried to do it by hand myself. It seemed easy enough from the description of the process they have up. Oh well. >>>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. :) Well, as I said that's the tricky part. As far as I can tell, there's not a way to control the query depth through the web interface. Awhile ago I hacked one of their example programs (getalbum I think) to spit out the data like what was attached. The example using your disc was, well, an example. I quickly cut-n-pasted it together from four different web urls. The data's all there, just not in one concise url. :) ... > 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. I'm hoping to go one step further and stuff the data into an app block in the flac itself. I've done this by hand, and it works. Now I just need to put together a tool that takes a flac with a cuesheet, calculates the id, does the lookup from the server, and stuffs the results back into the file. (Then once that's working well, pester the musicbrainz folks into integrating it into the next version of their tagger tool.) But I can certainly see the appeal of keeping that data in a db instead/as well. > 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. Sounds like a good plan. Let me know how you progress. -michael -- Dear Dad: Hate you, eloping with Mom. Taking your cigars and sports car. -- Love, Sigmund _______________________________________________ Discuss mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/discuss
