> > 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. Meanwhile, what is the minimum version of emacs that emms supports (I want to use 'time-convert' which needs 27.1)? Thanks, ---Fran On Mon, 4 Mar 2024 at 07:30, Fran Burstall (Gmail) <[email protected]> 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 <[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" >> >
