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

[Yoni Rabkin]

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

>>
>> 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.
>
>
> After thought and experimentation, I have understood the issue with url.el
> and have worked around it (short answer: wrap _everything_ intended for
> 'url-retrieve' including headers in an (encode-coding-string ... 'uft-8)).
> I shall test the new version for a couple of weeks before offering it here.

sounds good

> Meanwhile, what is the minimum version of emacs that emms supports (I want
> to use 'time-convert' which needs 27.1)?

27.1 is some four years old now. I'm fine with supporting 28.1 and
up. However, also check your favorite distro and see what comes with it.

It should, at the very least, work on the distro you use yourself out of
the box.

> Thanks,
>
> ---Fran
>
>
>
> On Mon, 4 Mar 2024 at 07:30, Fran Burstall (Gmail) <fran.burstall@gmail.com>
> wrote:
>
>> 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?
>>
>>
>> Let me get back to you on this since it is a while since I looked into it:
>> the precise issue is multibyte chars triggering an error due to the fix to
>> emacs bug #23750.  It seems that a number of packages have been hit by this
>> over the years but apparently some have fixes since I last looked.
>>
>> ---Fran
>>
>> On Sun, 3 Mar 2024 at 21:34, Yoni Rabkin <yoni@rabkins.net> wrote:
>>
>>> "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"
>>>
>>

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