Petteri Hintsanen <pette...@iki.fi> writes: > Yoni Rabkin <y...@rabkins.net> writes: > >> What are your thoughts on this? > > I don't have anything concrete to suggest to Emacs interface at this > time. > > But it may be good to check MusicBrainz Picard if you haven't done that > already. Namely, you don't necessarily need to implement a database > browsing mechanism at all, but you could delegate that to a web browser > instead. > > Picard does this kind of delegation by opening a local http server and > supplying its port in MusicBrainz "tag lookup" query parameter. This > causes special "Tagger" links to appear in the search results. By > clicking such link the web browser relays the corresponding MusicBrainz > release identifier back to Picard via the local port. Picard will then > download the tag data for the selected release and lets the user > associate that with her files. I've been using Picard for years and can > attest that this workflow works well. > > I guess you could utilize the same query mechanism if you wish. That > way you could start immediately with the actual tag update interface. > I'm not suggesting this is the right way to do it, but just something to > consider. > > And just like you described, pinpointing the correct release can be > laborious. It usually involves matching bar codes, catalog ids, > sometimes even CD matrix codes to the search results. For popular > albums there can be dozens of releases with wildly different contents. > Usually it is enough to find something close enough.
The work on this continues, albeit slowly, on the "idapi" (ID API) branch. It is 100% plumbing and 0% porcelain at this point, but designed with multiple search APIs in mind, as well as being able to connect to porcelain well. I'll post some example code once is enough there... there. -- "Cut your own wood and it will warm you twice"
