feature request: select from predetermined tag set for custom fields

Hello - thank you for the incredible software that is Mp3tag. I am thankful that you develop and provide this world-class tool for free.

I am trying to achieve a particular goal and am having trouble finding a way to do it efficiently.

I want to: [a] Create a custom tag field and [b] populate it for each audio file by selecting tags from a predetermined set of tag values.

For example, I want to have a custom tag field named "Mood" and then give Mp3tag a predetermined set of values such as "Dark", "Excited", "Melancholy", etc. Then, when I am editing audio file tags, I want to be able to select and apply one or more of the values from this predetermined list. So if a song is both dark and melancholy, I could select those and the end result would be "Dark; Melancholy". Does this make sense?

I know it's possible to already do this in Mp3tag manually, but there are a few problems:

(1) I want to keep data well-formed - which selecting from predetermined values would facilitate - but currently it looks like I would have to manually type the values in myself. With typos, this could create a mess. A selection list keeps things clean.
(2) I want to be able to refer to a list of values I've previously decided on and edit the list as needed. Currently, I would just have to remember (or keep an external list of) the values, which is tedious.
(3) Autocomplete features only work to make one selection; they don't take into account that a user might want to populate a field with multiple values.

Why do I want to do this?
I have a need to quickly group audio files according to various custom fields. I know that I could achieve this with playlists, but (a) playlists largely depend on host player software, which I don't want to rely on for this purpose; and [b] file locations can frequently change in my intended use cases and I don't want to have to keep tweaking the playlist. Instead, I simply want to embed the playlist-driving values into the files themselves, so I can always do a search and quickly get the group of files I need.

I think there is a gaping hole in the market for a feature like this. Would you consider introducing this capability, and/or do you have any recommended workarounds for my intended result in the mean time?

You can define action groups that would do it for you.
Not quite the function of a dropdown list, but still a predefined list.
Name the actions with a common prefix, separated by #
E.g.
Mood#Dark
Mood#Excited
Mood#Melancholy

This would create a menu entry "Mood" in the actions menu with the submenus Dark, Excited and Melancholy.

You can then equip the actions in the way you want, by keeping the already existing values or overwriting them.
You many even consider a sorting action to have the keywords in a defined order...

Following up on this quite awhile later...

Thank you for the thorough and thoughtful response.

I'd like to request, though, an actual implementation: I want the tag values to be dynamic. As I enter tags, I want to be able to choose from a list which is dynamically populated in an internal mp3tag database, without having to stop down and manually create actions every time I enter a new tag value.

If I have to manually go in and create a submenu each time, it's very tedious as opposed to just typing a tag value and having it show up in a list automatically. Not to mention that having to use the actions process (instead of just working with tags directly in various interface tools) to utilize such a list is a laborious workaround.

To put a finer point on it: What would be mp3tag's strategy as we continue to move forward in an era where people are using tons of custom tags in their player and editor programs? People generally want to be able to see their defined custom tag options and pick and choose from those options. (That's how many tag-editing media players work now.) Once a user goes down the road of configuring a bunch of custom tags in their favorite media player, suddenly trying to work with those custom tags in mp3tag feels very limited. So if a user prefers mp3tag for its features, but needs the ease of use of choosing from a predetermined set of tags for custom fields - a feature several media players already offer - what is the user to do?

1 Like

see also: /t/18317/1
or here: /t/19359/1
and a thread with the response by the developer: /t/8263/1

I would not like to have a list of values to choose from, if it means to loose the feature of MP3Tag that shows me every value of a tag that is inside the highlighted files.
As long as there is no way to have both possiblities without interferring I prefer to have this feature much more.
At the moment the genre tag ist the only tag-field in the tag-panel with a predefined (and individually expandable list). Even there I am missing the general behaviour of MP3Tag to show all tag-values that are actually in the highlighted files. Therefore I had to create my own additional genre-field to get this feature with some loss of comfort as a workaround.
Suggestion for Genres

Hi poster -

I generally agree with you, and I really like the dynamically populated values from selected files as well.

The problem is, what I really want is the ability to also have a preconfigured list of values to apply to the fields as I need. These values are too many to just remember all the time (to manually type in) and so I want them available anytime I edit the field.

For example, I have a "Theme" custom field. It has approximately 30 values which vary over time (depending on what I'm working on) but are somewhat consistent as well. I don't want to have to maintain 30+ actions to deal with this; I just want a preconfigured dropdown list.

Hi, and thanks for the followup.

Yes, I think the reason for these various posts is what I was pointing out: That people are now using more custom tags and they want a flexible way to keep track of all the ways they're using those fields.

Here's the problem: mp3tag assumes the user will be fine with just seeing whatever tag values come up contextually when viewing a certain group of files. But what if I've got 30 or so values that I want to choose from, but which don't exist in the particular files I've selected? Now I have to either manually remember the values, or do workarounds (sample files, actions, etc.) But when other utilities and players dynamically provide dropdowns with all values (in a library, for example), this just seems tedious and makes mp3tag laborious to work with.

That's why a configurable dropdown list is optimal for this situation. Why not make it optional and user-configurable? Typical users wouldn't use the feature, but for users like me and the other recent posters, we could set it up and use it.

Just take a text-file with these values or (very old fashioned) print it and fix it somewhere at your workplace.
For my workflow I can say that it is not sufficient to have a list to choose from. Even seeing the list I wouild have to remember which value I took the last time I had to decide. :wink:

Could you give an example of other utilities and players that provide dropdowns with all values so that you can apply those values to new, possibly untagged files?
What is your idea of a "custom tag"? A user-defined field? Which player or utility (besides foobar) can cope with user-definded fields?
How would you like to see the implementation if a collection has some 10.000 Artists and just as many albums? How long should the dropdown list be?
How should the list be maintained in respect to editing entries, deleting them?
Where do you see the increased user-friendliness in the thread that you linked
REQUEST: predefined disc field
where you have to scroll through 64 entries in a list just to enter 3 characters?

None?

Because all player designer had the same thought: "why would anyone want to use some made-up / non-standard fields?". And then creators of tag editors had similar idea: "why would anyone want to use some made-up / non-standard fields; especially when there are no players who can handle them?"

As long as the user would want and define?

Because maybe the user is tagging some specific files / body of work, not necessarily musical, that requires only few options?

Or for example deals with a specific period of time mostly and so a list of something like 10-15 years would cover the area of interest in regards to the YEAR tag field?

So we are back at the point where the most feasible solution is to create the required number of actions.
If you have only vcery few entries, you know them by heart.
If you have some more, it is actions.
If there are a lot of varying ones, but some that you had before: use the example file solution.

Poster, again thank you for your thoughtful contributions to this discussion.

The problem is that I would like to work dynamically with the data sets in the app. I don't want to have to manually keep a separate .txt file which is not linked in realtime to the actual data set. Doing it this way would contribute to typos/errors and would double the amount of time spent texting, when mp3tag could provide support itself.

I think the reason you are strongly at odds with this request is because you're seeing use cases only from your perspective, which is one where you prefer everything to be open-ended. That use case is fine, and I respect and support it. But there are other users and use cases where the desired outcome on certain custom fields is a rigorous adherence to predefined values. This keeps the data well-formed and normalized. Certain users need this because of a requirement to categorize or label audio tracks according to a predefined set of labels. Asking those users to do workarounds will just drive them elsewhere, which is a shame because mp3tag is otherwise so flexible and excellent.

ohrenkino, thank you for asking this important question. Many applications in 2017 (not just audio) increasingly allow users to define their own tag fields and the possible value set for those fields. It's just a common way to help users set up their own file management structure. For a well-known example, look at Firefox bookmark tags. The tags generate a dynamic list which can be seen in the places Library. The user can type to auto-complete a tag at any time in a bookmark creation/edit window, and the user can also see the full list of tags at any time to ensure they are well-formed.

You ask about other utilities and players. Audio players and library managers increasingly support this functionality and workflow. In MusicBee, the user is free to add not only custom tags (with custom names) but also "virtual tags" which can be used for smart search/sort/filter. Then the user can easily display these tags as a list in the main player interface, with drag-and-drop application to audio files. Further, MusicBee has an excellent Tag Tools extension which allows for extreme flexibility for users who need it. In MediaMonkey, same basic principle: Custom tags can be applied, and can be brought dynamically into the interface with all possible values listed out as entries in the library node. Again, these values can be drag-and-dropped to audio files, and an optional extension system provides even more detailed control over tags should the user need it. Several other players that use a library concept have similar implementations or similar implementations are being worked on. In the best cases, the user can easily and immediately see all available values for a given custom tag, and choose from the list. When a tag is removed from the library, the application dynamically detects this and shortens the list; when a new tag is added, the list is lengthened. Simple and easy.

The problem in mp3tag is that, while it provides dynamic value selections and autocomplete like Firefox bookmark tags, the values are limited to whatever files are being looked at at the moment (since mp3tag doesn't have a concept of Library). Thus, if I need to remember all the possible values I want to rigorously adhere to for a given tag field, I have to manually deal with it.

Where these modern players and utilities give the user flexibility to adapt the environment to their needs, mp3tag assumes that the user doesn't need that functionality and locks the user out of control. That's why these requests are coming up repeatedly: because the user does need the control to administrate preconfigured lists of tags. It just logically makes sense for anyone who is categorizing using tags across multiple tag fields and who doesn't want to manually keep lists or create actions.

ohrenkino, respectfully, I would ask you to realize that there are other users who have different needs than you. These users need to be able to carefully (tediously even) maintain a proper multidimensional catalog of audio files using custom tags. Having to manually remember/enter everything in mp3tag is extremely laborious when other tools (as mentioned above) already allow for maintenance of possible tag values in dynamic lists.

For example, let's say I have a custom tag called "Theme." I might want to have a list of 30 values (Wedding; Honor; Dance; Aggressive; etc.) that I have pre-configured, and apply those values as I review the material. And then there might be a "Company" custom tag theme where I apply corporate names (General Motors; Yahoo!; etc.) as it relates to various corporate projects I'm working on. If I have a bunch of custom tags and yet want to keep the values well-formed, normalized and clean, I need to have something like a preconfigured dropdown menu or other selector. It's even better if the values are dynamically populated with all of the actual-set values, but at least they need to be available as selections when setting tags.

You would probably say, "Well, why don't you just go use those other tools, then?" Because many times, I want a lightweight tool like mp3tag which is outside of a player workflow. I see MusicBee or MediaMonkey as a main "Library" tool, and mp3tag as a quick and easy "Editor" tool. Plus, mp3tag has really cool features in its own right, such as listing a matrix of files and tags and allowing quick copy-paste between files, that's just fun to use. Further, if mp3tag is going to have a place in the future of audio file tagging, it needs to conform to people's desires (just see the forum increase on this topic in the past month!) to effectively use custom tags and their value sets. Otherwise, mp3tag veers toward obsolescence for all but the most basic tagging scenarios.

To answer your specific questions: What is my idea of a "custom tag"? It's the idea that's implemented across most modern audio utilities, including mp3tag itself. Yes, as you say, it's a user-defined field. These are already supported in mp3tag, it's just that mp3tag only provides autocomplete values from the set of values that are embedded in the files currently being looked at (via directory selection). Other tools, as described above, (a) scan a library to provide the user with all existing values for each custom tag, or (:sunglasses: allow the user to maintain lists of possible values they want for the custom tags.

What about the case where a collection has 10,000 Artists and just as many albums? How long should the dropdown list be? To some extent, I think you're missing the point of this feature request in two ways. (1) I think for most of us making requests on this topic, we're not asking that dropdowns (or whatever other pre-configured value lists UI/UX might look like) would, by default, include artists or album titles, which are obviously and inherently free-form in nature. Obviously, that would clutter the interface and confuse a new and/or light user. We're looking for this functionality primarily for our custom tags, which in my case have anywhere from three to seventy possible values per tag. (2) Even if a user wanted artists or album titles as a selectable list (as some have requested), the user should be able to configure whether the user wants a dropdown (or other UI/UX element) or not. The point is that the user should be able to configure the optimal experience for the user - not mp3tag making the choice for them.

Further, you seem incredulous about a 10,000-item list and assert that it's user-unfriendly. I agree, for the average user, you would never want a 10,000-item list turned on by default. But I disagree with you (or I assume you disagree with me) that a 10,000-item list should never be allowed. If the user wants a 10,000-item list, because they have a specific need for it, give the user the functionality to do so. The data is there and waiting to be useful, so let the user have the tools needed to do what the user wants.

How should the list be maintained in respect to editing entries, deleting them? There are a couple obvious possibilities, although of course it would ultimately be up to Florian. One possibility is that mp3tag could be set up to dynamically scan (and monitor) a directory as a "library" for all possible values for custom tags. So right now, the user must simply select a directory to work in. Imagine if the user could optionally select a "library" directory which contained the entire set of files to be included in a tags database. The user could then, as they do now, browse to a folder inside that library directory to look at a subset of files - but certain user-configured fields could provide a dropdown (or another UI/UX element of Florian's choosing) which would dynamically include all possible values in the database. This library would not be required for use of mp3tag or set by default; it would only be an option in mp3tag. Another possibility is that, just like Genres, a user could maintain predefined lists for certain custom tags.

And to your question: Where do you see the increased user-friendliness where you have to scroll through 64 entries in a list just to enter 3 characters? Again, for a user like me who has 64 well-formed, purposefully designed values for a custom tag, this situation would have total user-friendliness to me. Again, you think of this situation from your use-case perspective and find the idea of 64 entries to be irritating. I find it helpful and I need the ability to configure such a situation. Rather than have one person's view dictate everyone else's use of the software, why not let the user have the tools to decide? That's what modern utility software development is all about.

It's been said that the best workaround possible is to use Actions. But then this makes working with mp3tag very tedious, because now I have to constantly maintain a growing list of actions just to have well-formed tags. Actions configuration is time-consuming and it doesn't pull data from files; users have to manually enter the details in a series of pop-up windows. Imagine sitting there opening and closing those Actions windows for hundreds of tag values. Not fun. And it takes you out of the workflow of working with files and tags; to use actions, the user has to stop down and go into the abstracted Actions popups. Plus, that list itself becomes unwieldy and too long, because I'd have a bunch of tags for unrelated tag fields in big long Actions lists. I'd rather have each set of tag values provided contextually where they belong - in relation to a specific tag field.

This overall issue is one of the reasons that I have had trouble continuing to use mp3tag. Why? As explained above, modern media players and audio/music utilities increasingly support custom tagging, and they often dynamically represent all of the known values for tags in a music library as filters in the interface. Users like me go about setting up a bunch of custom tags, and in many cases, they want to use those tags as categorization mechanisms, limiting the values to a pre-configured set of possible values.

People like me need mp3tag to adapt to our workflow, since our other tools are more flexible but we still like mp3tag for various reasons. The answer has been a staunch "no!" since 2009, which has likely driven users away. I would respectfully ask Florian to reconsider. You don't have to completely change the default experience for mp3tag users. Let these be options that users can turn on or off. Users who like things the way they are can continue as-is, but users who need the preconfigured/dynamic lists can turn them on.

1 Like

Well I would for example put such things in the ARTIST tag field, to be chosen from:

 feat.
 feat.  &
 vs.
 interp.
 interp.  cond.Especially the >> interp. << would be usefull to me because for me it stands for interpreter / interpreted by, and sometimes I write this down wrongfully [as for example >>interpr.<< or >>intepr.<<]; and that creates problems further on. And where I am in Tag Panel I have the pointer somewhere on Tag Panel and it would be quicker for me to choose something from the drop down tag field  menu than from Actions. Especially that is true when I add a completely new stuff and I go from field to field, one by one [and so the pointer needs just a small movement]. And if there were drop down menus I bet I could use them with keyboard, thus utilizing something more than just the Tab button on it during such work

It is all those little adjustment that make the overall time spent in Mp3tag less tedious and save hours of your life in the very long run

So I am not the only one? So I am not imagining things; how they can be better that is?

I have 47 entries under the Action button. Few of them contain sub-menus on purpose and some of them group in a such sub-menu things that are rarely used by me but still have to be done with an action

Most of those rarely [and some of the frequently used] are added to some sub-menu because they need to be put somewhere, so that they do not create a 48th, 49th etc. entry under the Action button. Because 48 entries would fore me to scroll the list- and that takes time and is simply a drag, going all the time up and down through such list. And on top of that I have some issues with list exceeding the vertical space of one screen: /t/18377/1

Everything that I could move to tag fields from Actions [adapt sub-menu in Actions to a form of a drop down list in Tag Panel would be of help

I just do not comprehend this. Tag for GENRE can be pre-defined as an option and it is an A-OK approach / feature; but the minute someone signalizes the obvious extension of that feature to the rest of tag fields, or at least to fields like DISCNUMBER or YEAR, it is viewed by some of the experienced users as a useless overkill. How come? Because "there are just 256 pre-set values for genre as they are defined in the ID3 standard"? [Request:Pre-defined menu's]

So if somewhere in the 1990's creators of ID3 would decide, that the YEAR field should also be populated with values ranging from 1914 to 2014, because [I'm totally speculating here] they knew of the oldest recording to be from the year 1914, then today in Mp3tag this field also would have a ready to use drop down list; that could be supplemented by user with new values [1913, 2015 etc.]? And then it would be OK to have this option for YEAR, and to be able to turn such menu off [as it is now possible for GENRE tag]? And so, we would have an argument in this discussion, that those only 101 pre-defined values for YEAR and 255 values for GENRE are manageable and useful- but for other fields such option would not have a sense to implement it, even if it would be entirely up to user how strongly such lists would be populated and with what?

Well, for me those 256 genres seem like a big number and I am stunned that they did that at all. But then again when I look at them in the Tag Panel, that quarter of thousand of variables is easily [alphabetically] manageable. So I can easily imagine that I could create a list with 2000 positions, that would cover all off my primary artist [that are the main performer of at least one song / composition and thus have a folder of their own on my musical drive]. I am not saying that I would or should, but I wish I could

You can filter your files by using the Filter Box and you can "filter" them with a column with a proper values set for it. Depending on your needs and skills, you use the first method, the second or both- whatever you like / need / can. So why it is a blasphemy for some to imagine that some users would make some usage by implementing multiple simple format value "actions" [i.e. drop down menus] in the Tag Panel?

@mp3tagz

I had asked the same; a custom drop-down list. But it seems that the mp3tag team will not consider that. They have their reason. Meanwhile we have to stay happy whatever they have provided. I thank them for mp3tag software.

Instead of mood drop-down list you can have actions drop-down list about which @ohrenkino said. That works. But the problem remains if you want to put multiple values like | Rock; Pop |. The mood# action list method replaces | Rock | while inserting | Pop |. A mixture of the mood# action list method and "replace with regular expression" may produce something closer to what you want.

After expressing my gratitude to the mp3tag team I am requesting them to reconsider the option of adding custom drop-down list for the mood field like the genre field.

User mp3tagz has raised a valid point.

1 Like

This depends a lot on how you construct the actions.
E.g. create actions that only supply the main genre/mood, here e.g. Rock,
Format value for Genre
Format string: Rock

and then you have other actions that add the sub-genres to that what is already there, here e.g. Pop
Format value for Genre
Format string: %genre%; Pop
So not fiddling about with regular expressions required.

Yes, your procedure works. But if that method is used how to solve single entry of | Pop |? I mean, after clicking | Rock |, for ? | Pop | the "format string" is | %mood%; Pop |. So when you will want to insert | Pop | only there will be | ; Pop |.

Yes, quite.
But I am sure that you can think of an action group that caters also for the case where sub-genres become main genres.
I wonder how that would be handled by the dropdown list.