Re: Default info methods

[Fran Burstall (Gmail)]

Couple that with a manual which robustly explains the other info methods that people
can use if they so choose either to replace emms-info-native or go
beyond it.

The manual should also explain how to recompute info when a new info method is introduced (thus 'emms-cache-rest' followed by 'emms-add-directory-tree').  This came up recently on Emacs StackExchange...

---Fran

On Mon, 8 Mar 2021 at 14:25, Yoni Rabkin <yoni@rabkins.net> wrote:

Petteri Hintsanen <petterih@iki.fi> writes:

> Hi all,
>
> While working on Chapter 13 "Track Information" of Emms manual, I
> realized that Emms actually populates emms-info-functions on startup via
> emms-all.  I think this is the right thing to do, as it provides
> functional metadata support out of the box.
>
> But the way emms-all does this could be improved.  Now it snoops if any
> of the following programs is installed and if yes, it adds the
> corresponding info method to emms-info-functions:
>
>  - emms-info-mp3info-program
>  - emms-info-ogginfo-program-name
>  - emms-info-opusinfo-program-name
>
> Finally it unconditionally adds emms-info-cueinfo.  For completeness we
> could add exiftool, emms-print-metadata, metaflac and emms-info-native
> into emms-all too.  Tinytag is a tad bit difficult because it is a
> Python library, not a separate executable.  But I think we should try to
> detect its presence as well, and add emms-info-tinytag if it is
> available.
>
> There is a caveat in this strategy though.  If there are multiple info
> methods configured at the same time, all of them will be called, and
> metadata from latter methods will override the metadata from earlier
> ones.  This is desirable if the methods are functionally orthogonal,
> like emms-info-mp3info and emms-info-ogginfo, but problematic when the
> methods are feature-par with each other, like emms-info-tinytag and
> emms-info-exiftool.  In the latter case Emms invokes two processes to
> get almost the same information, where only one would usually suffice.
>
> I propose to the following default config scheme instead:
>
> - If emms-print-metadata, tinytag or exiftool is found, use only one of
>   them.  The assumption here is that any of these suffices to supply all
>   metadata for all tracks.
>
> - Otherwise use emms-info-native.  This can be augmented by mp3info (for
>   id3v1 tags).  Ogginfo, metaflac and opusinfo are superseded by
>   emms-info-native, so they can be ignored.
>
> What do you think?

emms-info-native should be the default on a new install. Couple that
with a manual which robustly explains the other info methods that people
can use if they so choose either to replace emms-info-native or go
beyond it.

You can go ahead and make that change now so that people will have a
month to play with it from the git repo before a release to elpa on the
first of May.

If course none of this should change anyone's existing setup, but we
should also make people with existing setups aware that emms-info-native
is now available.

Looking forward, it may be a good idea to eventually expand emms-info to
permit setups such as:

(setq emms-info-methods '((("*.flac" "*.flc") . emms-info-metaflac)
                          (t                  . emms-info-native)))

Which would first hand specific jobs to particular backends, and finally
use the "t" backend as the catch-all.

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