Re: MusicBrainz integration (and by extension other music search APIs)

[Daniel Semyonov]

>>>>> Yoni Rabkin writes:

    > Yoni Rabkin <yoni@rabkins.net> writes:
    >> Daniel Semyonov <daniel@dsemy.com> writes:
    >> 
    >>>>>>>> Yoni Rabkin writes:
    >>> 
    >>> > I have a working MusicBrainz API for Emms in a local branch, in the
    >>> > sense that I can send a request and get a response which is then
    >>> > processed into SEXP form.
    >>> 
    >>> > The question now becomes: how do we start to integrate that 
information
    >>> > into Emms?
    >>> 
    >>> > Identifying a specific artist, recording, or release is
    >>> > non-trivial. Each album can have multiple releases. For example: ones
    >>> > issued for the Japanese/European/U.S. market, an extended re-release, 
a
    >>> > digitized version of the original vinyl release, a remastered release,
    >>> > the 40-year anniversary remaster, etc.
    >>> 
    >>> > With MusicBrainz specifically, the process needs to start with an API
    >>> > call to correctly identify the artist, then the recording, then the
    >>> > release-group, and finally the release.
    >>> 
    >>> > For illustration purpose, I'll present information from MusicBrainz
    >>> > about David Bowie:
    >>> 
    >>> > Searching for "David Bowie" as an artist returns over 14,000 results!
    >>> > Assuming we choose the right one (and not, for instance "Woody
    >>> > Woodmansey's Holy Holy, a David Bowie tribute band"), we will get the
    >>> > MusicBrainz artist ID for David Bowie.
    >>> 
    >>> > We can then effectively do a search for terms in the specific release 
we
    >>> > have at hand using the artist ID. We could then search for "Heathen" 
and
    >>> > get the MusicBrainz release-group of 21 releases for that recording. 
We
    >>> > can finally examine one of those releases to see the track list for 
that
    >>> > specific release and match it to the files we have to hand.
    >>> 
    >>> What prevents performing a single search for releases (or release 
groups)?
    >>> According to 
https://musicbrainz.org/doc/MusicBrainz_API/Search#Release_Group
    >>> it should be possible to use the 'artist' or 'artistname' field instead
    >>> of 'arid'.
    >> 
    >>> From my limited experimentation with it, if you put "David Bowie" in the
    >> artist/artistname field of a release-group search (as opposed to using
    >> an arid), you'll get every single artist name which includes the string
    >> "David Bowie" anywhere in it, along with all of their releases. If that
    >> includes tribute/cover bands, then the song names will be the same as
    >> well. You'd have to potentially wade through a lot of dross first.
    >> 
    >> The same would happen if the artist you are interested in has a
    >> relatively common name like "John Smith".
    >> 
    >> In comparison, identifying the arid first allows you to narrow all
    >> subsequent searches to the right artist.
    >> 
    >> However, I'm interested in actually implementing more of the API and
    >> experimenting with it in order to see if this is the problem in practice
    >> that I think it is.

    > And at the moment it is a matter of two steps forward, one step back, as
    > the results of translating the response from musicbrainz to sexp is a
    > mess via `xml-parse-region'. I might try to do it with
    > `re-search-forward' over the xml instead... sheesh.

The API seems to support returning the results as json (by setting the
"fmt" parameter to 'json'), have you tried that?  I personally find the
parsed data to be easier to manage.
Emacs supports parsing json fairly quickly with libjansson since Emacs
27, and there has actually been some discussion on emacs-devel lately
around a much faster json parser being developed specifically for Emacs
(it doesn't depend on any external json parsing library).

If you still want to use XML, look into the `dom' library (part of
Emacs, though not well advertised IMO) which helps manipulate the
structures returned by `xml-parse-region'.
Though from experience, it's still a mess.

Daniel