Re: Default info methods

[Yoni Rabkin]

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

>>
>> 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

I just added a paragraph about this to the manual. It will be included
in the next release.

>
> 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"
>>
>>

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