Default info methods

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Default info methods

Petteri Hintsanen-2
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?

--
Petteri


Reply | Threaded
Open this post in threaded view
|

Re: Default info methods

Fran Burstall (Gmail)
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?

I think this is a good idea.

---Fran


On Sat, 6 Mar 2021 at 18:47, Petteri Hintsanen <[hidden email]> wrote:
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?

--
Petteri


Reply | Threaded
Open this post in threaded view
|

Re: Default info methods

Yoni Rabkin-2
In reply to this post by Petteri Hintsanen-2
Petteri Hintsanen <[hidden email]> 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"

Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> wrote:
Petteri Hintsanen <[hidden email]> 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"

Reply | Threaded
Open this post in threaded view
|

Re: Default info methods

Yoni Rabkin-2
"Fran Burstall (Gmail)" <[hidden email]> 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...

That is a good idea. I'll add that.

> On Mon, 8 Mar 2021 at 14:25, Yoni Rabkin <[hidden email]> wrote:
>
>> Petteri Hintsanen <[hidden email]> 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"

Reply | Threaded
Open this post in threaded view
|

Re: Default info methods

Petteri Hintsanen-2
In reply to this post by Yoni Rabkin-2
Yoni Rabkin <[hidden email]> writes:

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

Ok, I will do that.

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

Unfortunately it does: if someone uses (emms-all) without any custom
emms-info-functions, she will effectively get

  (setq emms-info-functions ('emms-info-native))

instead of

  (setq emms-info-functions '('emms-info-mp3info 'emms-info-ogginfo
                              'emms-info-opusinfo 'emms-info-cueinfo))

or some subset of that, depending on whatever software in installed on
her system.

However, in practice emms-info-native should provide everything except
id3v1 and cueinfo, so I think the new default is relatively safe and
does not break backward compatibility too much.  I would also expect
that most people do have customized their emms-info-functions.

This can and should be described in the manual as well, including how to
get back to the previous default in case something broke.

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

This is a good idea.

I was pondering an idea where emms-info-functions would be called one at
a time, like now, but instead of going through all functions, processing
would stop as soon as some function returns non-nil.  So
emms-info-functions would be evaluated like short-circuiting OR
expression.

But your alist is much better solution.

--
Petteri

Reply | Threaded
Open this post in threaded view
|

Re: Default info methods

Petteri Hintsanen-2
In reply to this post by Yoni Rabkin-2
Yoni Rabkin <[hidden email]> writes:

> "Fran Burstall (Gmail)" <[hidden email]> writes:
>
>> 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...
>
> That is a good idea. I'll add that.

Just please don't add it into Chapter 13 (Track Information), at least
not yet.  It has been completely overhauled.  I will push changes for
review soon.

--
Petteri

Reply | Threaded
Open this post in threaded view
|

Re: Default info methods

Yoni Rabkin-2
Petteri Hintsanen <[hidden email]> writes:

> Yoni Rabkin <[hidden email]> writes:
>
>> "Fran Burstall (Gmail)" <[hidden email]> writes:
>>
>>> 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...
>>
>> That is a good idea. I'll add that.
>
> Just please don't add it into Chapter 13 (Track Information), at least
> not yet.  It has been completely overhauled.  I will push changes for
> review soon.

got it; thank you

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

Reply | Threaded
Open this post in threaded view
|

Re: Default info methods

Petteri Hintsanen-2
I pushed the manual draft into info-native branch.  Please let me know
if you find it difficult to follow, or other flaws, typos, etc.

Thanks,
Petteri

Reply | Threaded
Open this post in threaded view
|

Re: Default info methods

Yoni Rabkin-2
Petteri Hintsanen <[hidden email]> writes:

> I pushed the manual draft into info-native branch.  Please let me know
> if you find it difficult to follow, or other flaws, typos, etc.

That looks good, please feel free to merge.

thank you

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

Reply | Threaded
Open this post in threaded view
|

Re: Default info methods

Petteri Hintsanen-2
Yoni Rabkin <[hidden email]> writes:

> Petteri Hintsanen <[hidden email]> writes:
>
>> I pushed the manual draft into info-native branch.  Please let me know
>> if you find it difficult to follow, or other flaws, typos, etc.
>
> That looks good, please feel free to merge.

Merged.  Also pushed new emms-setup.el with new default info methods.

Thanks,
Petteri

Reply | Threaded
Open this post in threaded view
|

Re: Default info methods

Yoni Rabkin-2
Petteri Hintsanen <[hidden email]> writes:

> Yoni Rabkin <[hidden email]> writes:
>
>> Petteri Hintsanen <[hidden email]> writes:
>>
>>> I pushed the manual draft into info-native branch.  Please let me know
>>> if you find it difficult to follow, or other flaws, typos, etc.
>>
>> That looks good, please feel free to merge.
>
> Merged.  Also pushed new emms-setup.el with new default info methods.

Got it, thanks.

I pushed the updated emms.info to the repo for the benefit of our future
elpa update.

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

Reply | Threaded
Open this post in threaded view
|

Re: Default info methods

Petteri Hintsanen-2
In reply to this post by Fran Burstall (Gmail)
"Fran Burstall (Gmail)" <[hidden email]> writes:

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

Would the attached patch do the job?  It adds a prefix argument to
emms-cache-sync which queues all tracks in the cache for update:

  (emms-cache-sync 1)

It won't clean any info cruft from the cache though, except removed
files.  emms-cache-reset would obviously do that.

Maybe we can later provide a function that would go through
emms-source-file-default-directory and do the right thing: add new
files, remove deleted files and update modified files in the cache.

Another thing is browser refresh.  EMMS playlists get their infos
automatically refreshed (which is nice), but the browser must be
refreshed manually by rebuilding it eg. after emms-cache-sync.

--
Petteri


From 3aaf60567ebefc5aee111e72ee869b16a4c0a713 Mon Sep 17 00:00:00 2001
From: Petteri Hintsanen <[hidden email]>
Date: Thu, 11 Mar 2021 20:53:11 +0200
Subject: [PATCH] Make it possible to force-update Emms cache

Add a prefix argument to emms-cache-sync that will unconditionally
update all tracks in Emms cache.
---
 emms-cache.el | 17 ++++++++---------
 emms-info.el  | 14 +++++++++-----
 2 files changed, 17 insertions(+), 14 deletions(-)

diff --git a/emms-cache.el b/emms-cache.el
index 9b5deb8..8c5e8b3 100644
--- a/emms-cache.el
+++ b/emms-cache.el
@@ -155,12 +155,12 @@ This is used to cache over emacs sessions.")
   (load emms-cache-file t nil t)
   (setq emms-cache-dirty nil))
 
-(defun emms-cache-sync ()
+(defun emms-cache-sync (arg)
   "Sync the cache with the data on disc.
 Remove non-existent files, and update data for files which have
-been modified."
-  (interactive)
-  (message "Syncing emms track cache...")
+been modified.  With prefix argument, update data for all files
+regardless of whether they have been modified or not."
+  (interactive "P")
   (let (removed)
     (maphash (lambda (path track)
                (when (eq (emms-track-get track 'type) 'file)
@@ -172,13 +172,12 @@ been modified."
                    (let ((file-mtime (emms-info-track-file-mtime track))
                          (info-mtime (emms-track-get track 'info-mtime)))
                      (when (or (not info-mtime)
-                               (emms-time-less-p
-                                info-mtime file-mtime))
-                       (run-hook-with-args 'emms-info-functions track))))))
+                               (emms-time-less-p info-mtime file-mtime)
+                               arg)
+                       (emms-info-initialize-track track arg))))))
              emms-cache-db)
     (when removed
-      (setq emms-cache-dirty t)))
-  (message "Syncing emms track cache...done"))
+      (setq emms-cache-dirty t))))
 
 (defun emms-cache-reset ()
   "Reset the cache."
diff --git a/emms-info.el b/emms-info.el
index 9a49a5c..308b2a2 100644
--- a/emms-info.el
+++ b/emms-info.el
@@ -79,15 +79,18 @@ Each is called with a track as argument."
 (defvar emms-info-asynchronous-tracks 0
   "Number of tracks we're waiting for to be done.")
 
-(defun emms-info-initialize-track (track)
+(defun emms-info-initialize-track (track &optional force)
   "Initialize TRACK with emms-info information.
+Update TRACK information if it is new or has been modified since
+last update, or if FORCE is non-nil.
+
 This is a suitable value for `emms-track-initialize-functions'."
   (if (not emms-info-asynchronously)
-      (emms-info-really-initialize-track track)
+      (emms-info-really-initialize-track track force)
     (setq emms-info-asynchronous-tracks (1+ emms-info-asynchronous-tracks))
-    (emms-later-do 'emms-info-really-initialize-track track)))
+    (emms-later-do 'emms-info-really-initialize-track track force)))
 
-(defun emms-info-really-initialize-track (track)
+(defun emms-info-really-initialize-track (track &optional force)
   "Really initialize TRACK.
 Return t when the track got changed."
   (let ((file-mtime (when emms-info-auto-update
@@ -97,7 +100,8 @@ Return t when the track got changed."
     ;; if the file's been modified or is new
     (when (or (not file-mtime)
               (not info-mtime)
-              (emms-time-less-p info-mtime file-mtime))
+              (emms-time-less-p info-mtime file-mtime)
+              force)
       (run-hook-with-args 'emms-info-functions track)
       ;; not set by info functions
       (when file-mtime
--
2.20.1

Reply | Threaded
Open this post in threaded view
|

Re: Default info methods

Fran Burstall (Gmail)
Would the attached patch do the job?  It adds a prefix argument to
emms-cache-sync which queues all tracks in the cache for update:
  (emms-cache-sync 1)
It won't clean any info cruft from the cache though, except removed
files.  emms-cache-reset would obviously do that.
Maybe we can later provide a function that would go through
emms-source-file-default-directory and do the right thing: add new
files, remove deleted files and update modified files in the cache.

This would certainly work for me.

---Fran



On Thu, 11 Mar 2021 at 19:10, Petteri Hintsanen <[hidden email]> wrote:
"Fran Burstall (Gmail)" <[hidden email]> writes:

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

Would the attached patch do the job?  It adds a prefix argument to
emms-cache-sync which queues all tracks in the cache for update:

  (emms-cache-sync 1)

It won't clean any info cruft from the cache though, except removed
files.  emms-cache-reset would obviously do that.

Maybe we can later provide a function that would go through
emms-source-file-default-directory and do the right thing: add new
files, remove deleted files and update modified files in the cache.

Another thing is browser refresh.  EMMS playlists get their infos
automatically refreshed (which is nice), but the browser must be
refreshed manually by rebuilding it eg. after emms-cache-sync.

--
Petteri

Reply | Threaded
Open this post in threaded view
|

Re: Default info methods

Yoni Rabkin-2
In reply to this post by Fran Burstall (Gmail)
"Fran Burstall (Gmail)" <[hidden email]> 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 <[hidden email]> wrote:
>
>> Petteri Hintsanen <[hidden email]> 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"