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

[Yoni Rabkin]

"Fran Burstall (Gmail)" <fran.burstall@gmail.com> writes:

> Orthogonal to this but "brainz"-related.  I have been using listenbrainz as
> an alternative to libre.fm for tracking what I listen to.
>
> I wrote a listenbrainz-scrobbler for emms and wonder if you want it for the
> emms package.  A possible deal-breaker is that I need to use the request
> package from the non-gnu archive because I could not get the built-in url
> package to play nice with utf-8 titles.

The source code here says it has been assigned to the FSF:
https://github.com/tkf/emacs-request/blob/master/request.el

...so I don't see that as an issue.

But if I understand correctly, the package is just a wrapper around curl
which falls back to the internal url.el if curl is not
available. Perhaps it would be better to figure out what is up with
utf-8 and url.el and even submit a bug to emacs instead of adding an
external dependency on curl.

Is emms-librefm-scrobbler.el, which uses url.el, mishandling utf-8 as
well?

>
> ---Fran
>
>
> On Sun, 3 Mar 2024 at 20:02, Yoni Rabkin <yoni@rabkins.net> wrote:
>
>> 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.
>>
>> --
>>    "Cut your own wood and it will warm you twice"
>>
>>

-- 
   "Cut your own wood and it will warm you twice"