Poll: Does Mp3Tag need a Find function?

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


Why must Find (or Locate) be described in terms of filters? It's separate from and different from a filter. There seems to be some confusion between the two in the conception of Mp3Tag. That seems to be reflected in the fact that F3 is used to turn filtering on and off, whereas traditionally it's used for Find Again. And Ctrl-F, which is traditionally used for Find, does nothing in Mp3Tag.

I've attached a screen shot of what happens when I press Ctrl-F in Tag&Rename. Notice the "Filter" field at the top left... Attachment 6307 not found.


Is this the way the filter should be applied?
I wouldn't use it like that.
I would filter with
ALBUM HAS Swan Lake
And see what the files list then shows. This should be a fairly short list.
Then I would select all the files with some kind of "kovsky" in them ...
and select the correct spelling entry from the drop-down list in the tag panel.
No need to search and find different spellings.

The great way of mp3tags functions is not to treat every file individually but to reduce the number of possible files by filtering and sorting to such an amount that the maximum files with a common criterion can be treated in one go.
Hopping through lenghty lists is the less performant way. In my opinion.
So I think that the wish for a find / locate function depends a lot on the workflow - and a little adaptation to that workflow can get similar results as the find function.

... except that once you've found the file you lose it immediately when you clear the filter.

But again: the point is not treating a file, but simply finding it. Ctrl+F - "Swan Lake" - boom. After that I might or might not want to filter, or edit tags, or add pictures or whatever. But maybe all I want to do is listen to Swan Lake while I tag. Or maybe I want to find a specific file in a long filtered list without adding another filter.

In Mp3tag this has to be done by pressing key [F3] and typing in "Swan Lake".
Mp3tag will reduce the view of the loaded filelist to all files, which have "Swan Lake" anywhere in the tag-fields, ta-taa ... all results at a glance.
Note: The shortcut [Ctrl+F] is reserved in Mp3tag to open the Default Folder.

DD.20151013.1707.CEST

This also has the advantage that the status bar tells you right away how many hits you can expect for the given (filter) expression.
Just another note: programs like iTunes or Windows Media Player also use some kind of filter to show lists of files instead of hopping from hit to hit ...

So does Tag&Rename. But it also has a Find function. And as far as I know, so do the programs you mention.

If I remember correctly, a couple of months I wrote about the same thing

Were you for it or against it?

I can't seem to able to find that topic of mine

But here is a related one: /t/16625/1

[Maybe it is that one I was thinkig about?]

Can't say I've ever had the need for a traditional Find function, but I can understand the point raised about keeping a scrolled location in a long list (though not the purpose per se).

It also would run into some problems that ohrenkino outlined if a Find All button was implemented.

From a pure UI perspective I get it, but seeing as Mp3Tag is heavily geared towards batch tagging and advanced actions I'm curious what the use cases are outside of visually returning to a place in a long list.

For example if you're looking for 'Swan Lake' the filter search can filter to that query and reduce the selection to matching files. If a Find-style search was implemented the only use it would be is not to increase productivity (it would actually reduce it to be honest if skipping one file at a time, over potentially over hundreds or thousands of files in the list view) but rather have a limited benefit of visually displaying where—in a (eg: long) list—a match is found in order to view surrounding files.

I guess the real question is the benefit of returning to a list after finding what one was looking for and seeing the surrounding files in a program like Mp3Tag. For pure serendipity that one sees an adjacent unrelated album/artist/whatever with a tagging error?

Otherwise most workflows are for targeting whole directories/albums/artists/genres where the filter view (or plainly selecting an individual directory to work on) are most effective. For most other things like playback, viewing, or general management a program like foobar2000 is better suited.

Exactly. But why does it have to be a matter or "returning" at all? Why not be able to find what one is looking for IN the list?

As a matter of fact what I end up doing is using Foobar2000 to move around in my collection and call mp3t when I want to do some serious tagging. However, since Foobar2000 is also very good at tagging, I often simply stay and do it there. BUT if mp3t had a simple Find function, it could serve as my basic music management app - without all the bells and whistles of other apps that shall remain nameless - instead of just a tagging app. I've now figured out a way to call my music player, Logitech Media Server, from mp3t.

By the way a Find function is neither a bell nor a whistle. And I still can't figure out the purism all you expert users seem to insist on. A Find function, for Christ's sake.

I agree that Mp3tag should probably keep any selected files after you've cleared a filter, and it should keep the scroll location (to the first of the selected files, I suppose, because you can't scroll to all of them if they're not all in view within the window). That would seem (to me) to be a relatively small enhancement.

But I'm not sure I understand how a Find function might work.

Which fields would be searched? All of them?

And what would happen in the user interface? Would all of the files that are "found" be selected? Or would it take you to and select only the first one?

Personally, I'd have little use for such functionality, but I know that other people use Mp3tag differently. I've always said that there are very few instances where the typical user needs to be working within their entire music collection all at once.

My vote +1.

DD.20151119.1621.CET

Well, let's say I'm looking for Swan Lake. I hit Ctrl+F (or whatever key would be appropriate for whatever "Find" is in German) and type "Swan Lake" in the dialog box that appears. I don't really care if "Swan Lake" is found in the Title field, the Album field, the Composer field, the Artist field, the Year field, or the Bitrate field, etc. All mp3tag needs to do is highlight the first line it finds "Swan Lake" in, and I'll know what to do. So I'd say if I'm displaying all fields it should search in all fields.

The only time I work within my entire music collection all at once is when I'm looking for a file.

Me too (but I guess I'm not qualified to vote since I started the poll...)

Hmm, to make sure, I voted for the proposal from user 'JJ Johnson'.
Poll: Does Mp3Tag need a Find function?

DD.20151119.1625.CET

Default search could look in every field

But in the search box there could also be a check box for [user] defined fields

+10

Hmm, to make sure, I voted for the proposal from user 'JJ Johnson'.
http://forums.mp3tag.de/index.php?showtopi...ost&p=86895

DD.20151128.1855.CET

The story continues:
/t/18122/1