Re: integration with beets

"Fran Burstall (Gmail)" <[email protected]> writes:

>>
>> > * takes care of album art for various values of "takes care"
>>
>> What do you mean by that?
>>
>> There are plugins that:
> * fetch missing album art
> * embed the art in the track file
> * extract the art from the track file (to save as cover.jpg etc)
> * resize the art

Understood; thank you

> emms-tag - Use the beet command line interface to beets from Emms
>> to correct and update track metadata. One interesting issue which would
>> come up here is that the underlying services, such as
>> acoustid/chromaprint, are licensed only for non-commercial use. So while
>> the software is free software, the services are not. People will have to
>> go through the process of having beets working with fpalc (the FFT
>> component of chromaprint).
>
>
> Two remarks:
>

> 1. The default tagger uses musicbrainz and not the
> acoustid/chromaprint mechanism (which, as you indicate, is not so
> straightforward to set up).

That makes sense.

A emms-tag feature would start by checking if there is any metadata at
all. If there is none, then it should go the fpcalc/chromaprint/acoustid
route. If there is some metadata, it can check against musicbrainz.

I guess that a emms-tag feature would be built on top of something like
emms-musicbrainz to handle those api calls.

> 2. The command line interface to beets is interactive if the match to
> musicbrainz metadata is not 100%: the user is offered choices to
> accept/reject.  So a putative emms-tag would need some UI to handle
> that (unlike metadata extractors like tinytag or exiftool).
> ---Fran

Another option is that since the user would have to go through the
trouble of installing chromaprint, a decoder, pyacoustid, then we might
as well control those directly instead of going through beets. That
would be more work for us, but remove a level of indirection.

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