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
