Poll: Does Mp3Tag need a Find function?

Currently Mp3Tag has no Find function. To find a file in the file list, one needs to use a filter. The problem with that is that once you've found the file and selected it, if you clear the filter you lose the selection. And often the reason for jumping to a specific file is to find your place in a large collection or subset of that collection. When you lose the selection, you use your place.

Other people may have other reasons for wanting a Find function. This is the place to state them.

So: Do you feel that Mp3Tag needs a Find function? If so, please Reply to this post.

What is this poll about?
Getting a find function or keeping the selection when changing the number of displayed entries in the files list?
Or: what has the selection to do with the find function?

Which place should I use? I do not understand.

Getting a Find function (see title).

It's not a question of "changing the number of displayed entries in the files list." It's a question of "displaying the entire files list with a specific file selected."

A Find function selects a file (or a word in a word processor, etc.) Without a Find function, you have to filter and then select the file manually. Which would be fine if the selection didn't disappear when you clear the filter.

By "your place" I mean the place in the file list you were looking for by filtering (since there is no Search/Find) for a specific file.

I think this poll is actually about 2 things:

1 - Get a find function
2 - keep the current highlight (selection) when changing the number of displayed files.

So could you please clarify the ambiguities?

Reason for edit: lengthy reasoning by me deleted.

It's not about two things. A Find function is all I need. And I suspect that a lot of other users want one. But if I can't have one I need for a file I select using a filter (for lack of a Find function) to stay selected when I clear the filter.

I don't understand why you say "changing the number of displayed files". To me it's "displaying the entire collection".

Right now I have to add some marker in a temporary tag field if I want to process later on all those different kinds of files found by different filter expressions

The olny alternative to this is making a longer filter expression; which is mess up and make an error of some kind

So maybe some kind of permanent selection is a good idea

You can create a playlist for selected files ... which would then emulate a more permanent selection. I doubt that you really need a kind of selection that outlasts the actual editing.

Not if I want to select files from different filter's searches

I can can create several playlists or export lists - and then combine data in them into one or compare them; but that's not the same

I wish you'd stop telling us what we need. I've already expressed it here clearly enough, but I'll do it again: The only way to find a specific file in Mp3Tag is to use a filter. But when you clear the filter, the file display jumps back to some other place in the collection. There should either be a real Find function OR the ability to tell the program to show the selected file after the filter is cleared.

This is a shortcoming of Mp3Tag. Looking at the results of the poll, users of the program don't really want a Find function or a workaround using the filters. (On the other hand, 50% of the responders DO want one ;O)) Unless, of course, the poll hasn't functioned as a poll becase it's too full of comments from users who don't want one and who are determined to convince others they don't need one...

One gets the impression, reading this forum, that the program's users feel that it is already fully formed and needs no additional functionalities - not "bells and whistles," but real, useful, basic functionalities, such as opening a second instance or... a Find function. Its many excellent features, as well as its shortcomings, they seem to feel, are as immutable as the laws of science or the dictates of the Creator, depending on which point of view you take. One must bend to them or simply find another tagging application. Unfortunately, there is none that even comes close.

Forgive me for being somewhat provocative, Comrade, but I'd like to get a real discussion of this failing of Mp3Tag going.

Best regards
Lestrad

-removed-

A practical solution has been offered in this thread already.

  1. Set up a new column in list view, where the content from one helper tag-field is shown.
    This helper tag-field can have the name "MYSELECTION" or such, ...
    it's content variable is %MYSELECTION%.
    The set of media files to work on should be in condition to receive and store this tag-field.

  2. Apply a filter expression of your wish.
    Within the filtered set of media files fill the helper tag-field with some text, e. g. 'x' ...
    (hint: set up an action to do this).

  3. Apply another filter expression of your wish.
    Within the filtered set of media files fill the helper tag-field with some text, e. g. 'x'.
    Do this sort of filter processing how often you need it.

  4. To display all the collected media files apply a filter expression like ...
    "%MYSELECTION%" IS "x"
    ... or ...
    MYSELECTION PRESENT

  5. You may save the entire selection set of media filenames into a playlist file for later usage.

That's all and ready.

DD.20151013.0935.CEST

I thank you most heartily for your suggestion, which I had indeed seen when you first posted it. I'm sorry to have to say that my reaction is the same as it was then: if the only way to find a file is to filter for it and then open it and write a tag to it, and then go back and filter for that tag, it's just not a workable solution. If it's the only way to find a file in the full file list, it only reinforces my contention that a real Find function is needed.

I'm sorry, but your even suggesting such a workaround also reinforces my impression that expert users of Mp3Tag like yourself are convinced that the program is perfect and needs no improvement.

Are you serious with the allegations that ...
... the poll does not work,
... the other users do not know real, useful, basic functionalities,
... expert users of Mp3Tag are convinced that the program is perfect and needs no improvement?
I hope you are not serious.

You did not make clear where the performance difference might be, between a "finder" and a "filter".
I think the Mp3tag "filter" offers even more creative flexibility than a simple "finder".

What could be formulated as a proposal for a new feature, that is:
if once a selection of tracks has been made within the filter view, ...
and then the filter view has been closed, ...
then the formerly selected tracks should be furthermore shown as selected tracks ...
now in the main list view.
This could be implemented as an option.

This proposed feature prevents the detour of writing some helper tag-field into the media file.

DD.20151013.1154.CEST

  • ... the poll does not work,:
  • Well, it hasn't gotten very many responses, and most responses it has gotten have been people trying to tell me why no one should want the feaure and explaining that it isn't needed. That's not what a poll is supposed to be, and it may have prevented people from realizing that all that was wanted was a simple Yes or No.

-... the other users do not know real, useful, basic functionalities,

  • Of course not. I find it hard to imagine that none of the other users has ever used a program that has a Find function.

  • ... expert users of Mp3Tag are convinced that the program is perfect and needs no improvement?

  • Yes. Or at least that's the impression I have - or had, since just today Detlev proposed a new feature that would keep files selectedn thus demonstrating that he is open to improvements. (Thanks, Detlev!)

"You did not make clear where the performance difference might be, between a "finder" and a "filter".
I think the Mp3tag "filter" offers even more creative flexibility than a simple "finder"."

Why does it have to be one or the other? Why can't there be both? Both have their uses.

Your proposal is great. The only thing that would be better would be a Find function. Is there a procedure for formally suggesting the addition of a new function?

I just realized that I'd written "use" instead of "lose". I apologize. I've edited my original post to make it easier to read.

To reiterate: I use Mp3Tag to view my entire collection and edit tags. For example, I filter to find all files of music by JS Bach - all possible names for him, e.g. JS Bach, J.S. Bach, J. S. Bach, Bach, JS, Bach, Johann Sebastian, etc etc. - and set the Composer tag to "Bach, JS" for all of them.

But sometimes I want to go to a specific "place" in my collection, and the only way to go there is to use a filter. So I find the "place" I'm looking for - say, Tchaikovsky's Swan Lake, and then I want to go back to the full file view and see what's immediately before and after Swan Lake. The problem is that when I clear the filter, my "place" - in this case, Swan Lake - is lost because the selection is not persistent.

Not all changes are improvements.
Are you open for changes and work with the filters until the "find" function is there?

I am still wondering about the underlying workflow - tell me: what is it?
Is it "Scrolling through a lengthy list, stumbling over a file that needs editing, select it, edit it"?
But as the filter has been mentioned and the toggle between "filtered" and "not filtered" seems to be important:
Is it "Scrolling through a lengthy list, stumbling over a suspicious file that needs editing, filtering for other files that match the suspicious data, select the files (!) that need editing, edit them, remove filter"?
As these files may be one block in the unfiltered list or may not be, it is not clear to me, which file(s) should be selected now and what happens to the selection if I use a cursor key?

What is still unresolved: what happens to the "selection without filter" if the filtered files do not include the selected file - e.g. the tag panel shows the data of the selected file. In this case the tag panel would show data of an invisible file.
What happens if you apply several filters in succession? Which selection should be kept if any at all?
These where some of my questions about the "keep selection" part.

Coming back to the find-function:
How should a hit be selected: Always just the whole entry in the files list or the particular search word/term in a field?
Should one file allow several hits (e.g. let the selection jump from filename to title, artist, comment, unsyncedlyrics)?
What happens to the selection if matching data is stored in currently hidden fields?
And there are probably more scenarios that need a specification.

Just to get this right: this is intended to criticize the basic idea, it is to get a well-founded design which is then much easier to implement (if the programmers are inclined to do so).

Not all changes are improvements.
  • Not asking for a change. Just an addition.
Are you open for changes and work with the filters until the "find" function is there? - Yes, if I can keep a file selected after I clear the filter(s). I am still wondering about the underlying workflow - tell me: what is it?

Is it "Scrolling through a lengthy list, stumbling over a file that needs editing, select it, edit it"?

  • Just being able to go to a specific place in the file list. Say, Swan Lake: "Let's see if ‘Tchaikovsky’ is spelled a bunch of different ways in different versions of Swan Lake." If so, we filter for each spelling of Tchaikovsky's name and change it to whatever we decide the "right" spelling is.
But as the filter has been mentioned and the toggle between "filtered" and "not filtered" seems to be important:
  • Wait. The only reason the filter has been mentioned is that I've been told the only way to find a file is to use a filter.
Is it "Scrolling through a lengthy list, stumbling over a suspicious file that needs editing, filtering for other files that match the suspicious data, select the files (!) that need editing, edit them, remove filter"?
  • No, under that scenario I can just keep the filter in place.
As these files may be one block in the unfiltered list or may not be, it is not clear to me, which file(s) should be selected now and what happens to the selection if I use a cursor key?
  • What you describe there is filtering, not finding. A Find function finds one file at a time. The idea is to go to a certain "place" in the collection. A point, let's say. A point is by definition single.
What is still unresolved: what happens to the "selection without filter" if the filtered files do not include the selected file - e.g. the tag panel shows the data of the selected file. In this case the tag panel would show data of an invisible file.
  • Again, the "persistent selection" is a problem that only arises because there is no Find function and the only way to find a file is to use a filter. Once the file is selected we go back to an unfiltered list. So there's no possibility of that happening

What happens if you apply several filters in succession? Which selection should be kept if any at all?

  • It doesn't matter whether several filters were applied in succession. It's a question of finding a file - or better, a "place" -, whether via multiple filters or not, and then returning to the unfiltered view.
These were some of my questions about the "keep selection" part.

Coming back to the find-function:
How should a hit be selected: Always just the whole entry in the files list or the particular search word/term in a field?

  • Either.

Should one file allow several hits (e.g. let the selection jump from filename to title, artist, comment, unsyncedlyrics)?

  • That's not how a Find function works. It shows the first hit, and then by pressing F3 (or some other key, since F3 is hard-coded for Filters in Mp3Tag) you move from one hit to another.
What happens to the selection if matching data is stored in currently hidden fields?
  • That cannot happen, since we are moving to the unfiltered state, which by definition means that nothing is hidden.

I just realized, that your "find" function is in fact a "locate" function, ...
which enables the user to step along the result list of files from the last filter session, ...
or which keeps all the files from the last filter result list in selection state, ...
while working in the main view.

Such a feature has been proposed some more times in the past, ...
and it could change the traditional work with Mp3tag, ...
we want to wait.

DD.20151013.1515.CEST