Could you elaborate a little more:
How should the lists be maintained? I mean: how do you add items or remove them?
Should there be some kind of automatism like for the Convert functions and their format strings or the filter expressions?
How long should the lists become?
Just to give a rough idea: there are some users on the forum who try to load more than 100,000 files from their libraries. I would assume that this could create some 10,000 entries for ARTIST, COMPOSER and ALBUM.
Scrolling through a list with 10,000 entries does not look like an enhancement to me.
The GENRE field has pre-defined entries for the genres as laid down in the ID3 standard which describes 255 different ones. The dropdown list helps you to get the correct spelling (e.g. hip-hop vs. hip hop) for the V1 genres as otherwise the mis-spelled genre would become "other" in V1.
So this list has a technical background.
All other strings in the tags are not defined by a standard - and could be anything.
Where do you thing the limits should be?
I would also like to have the ability to add custom items to the drop-down boxes! Please make this a feature in a future update. I listen to 5-6 podcasts and would love to be able to add the artist names and album names etc. to the drop-down boxes so I don't have to type them out every-time I import a new podcast to my htpc.
I suggest actions of the type "Format value" for the respective tracks and fields.
If there are just 5 or 6 of them, the actions list does not become too long.
Executing an action leads much quicker to the desired result than editing each field individually with data from a dropdown list and then save the modifications.
In Genre, I am able to add my own item via Tools | Options. Therefore, I know it is not according to Hoyle, I am able to create my own "list".
I understand your concerns for extra long lists, and it is a point well taken. I write NET code for myself and some others. I have one application in which I have 5 lists of pre-defined items. Via an editor a User may add, change or delete any item. The editor also allows the User to create their own List and later use that list in the application. I place no restrictions on the number of items in a list. The drop-down has a built-in function for "partial" entries. Therefore, if the user wanted the name François, the user would type "F" or "f", and only those entries beginning with F are displayed in the drop-down list. If the user then types "R" or "r", the drop-down list is further refined to only those items that begin with FR, or any combination of upper and lower case letters. This action is built into the drop-down box and one simply selects a box property(s). Therefore, it is immaterial how many items are in the list. If a User wants the whole list, so be it.
In MP3Tag drop-downs, it seems this drop-down function already exists in the Genre drop-down. I am proposing that the feature be extended to all drop-down boxes. The list can be maintained via Tools|Options, as is the Genre list. I have to check, but I believe a drop-down box of this type can have up to 32K list items.
I personally see no benefits in drop-down-lists. These lists would disturb my workflow.
I like very much the possibility to see all contents of the marked files in the tag-panel. With a predefined list like in genres this is not possible anymore.
Therefore I even created my own additional genre-field in the tag-panel to overcome this restriction. Genre Field - feature request
OK. what I understand is that you suggesting me to use :
right click - convert - actions - Action group A - format value - ( tag name ) - string A
Action group B - format value - ( tag name ) - string B
but that is not helpful because when I have 30 strings as a choice for a tag, that would
result in a very large Actions list.
Am I right or am I wrong?
you can structure the menu by inserting a # in the name, e.g.
and so on.
The # creates a submenu.
And yes, if you need 30 strings then you get a list of 30 items. That's the same for dropdown lists and submenus.
Just to make this clear: all explanations of the current functionality are not intended as a verdict on your feature suggestion. They are merely a hint on how to get the same result (select from pre-defined values) with the already available functions.
This is awesome! I didn't knew you can do that.
It is a rough solution to my problem but it is way more messy than what I suggest.
Anyway thank you for pointing this out and I am very sorry if I was a pain in the ass.
Suggestion: this subitem (with #) feature will be nice for Tools, for User defined genres, too (and so on...).
Tools: instead of
...will be... Google >>
Genres: instead of
Folk song, english
Folk song, hungarian
Rock and roll
...will be... Folk song >>
Folk song english
Folk song hungarian Rock >>
Rock and roll
Now I must to scroll Tools with little arrows, and genres too (fortunately, in genres works mouse scrolling).
I am a newbie to Mp3tag, In the same vein as the topic question asked, I would like to be able to select from a simple list of years for the YEAR dropdown tag and similarly for the TRACK tag rather than having to manually type in those details each time.
Is this possible anf if so please let me know how it can be done.
Not sure how it works on a mobile device but when you click on the Year combo box (drop-down box) it only shows and . So similar to the Genre dropdown tag, I would like it filled additionally with a list of each year starting from the 1930s so that the year can be selected and saved in the file rather than having to manually enter it.
In Excel for instance you add drop-down list (combo boxes) with Data Validation or HTML you can create drop-down list with the Tag.
The problem with this is that some users also include month and day info in the year, even though this doesn’t follow the standard for some formats. Besides that fact, if one was to start with 1930 or so, and include every single year to the present - this list will be pretty long. I suggest entering 4 number characters on the keyboard should be faster to do than scrolling through these limiting options.
"I suggest entering 4 number characters on the keyboard should be faster to do than scrolling through these limiting options"
That's what I do now.
However I use a separate tag to capture, month, day, year info.
With combo boxes as you will appreciate (see the Genre one as an illustration) the auto expand / auto fill / auto complete facility fills the box as you type in the info so even though the list itself might be lengthy ( I don't regard that as a limiting factor nor using the tag for its proper use - the YEAR and noting else) there is an alternative to scrolling the list.