"Fran Burstall (Gmail)" <[email protected]> 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 <[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" >> >> -- "Cut your own wood and it will warm you twice"
