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