>
> 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 <[email protected]> wrote:

> "Fran Burstall (Gmail)" <[email protected]> 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 <[email protected]> wrote:
> >
> >> Daniel Semyonov <[email protected]> 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"
>

Reply via email to