I'm thinking of buying FL after all (newer versions didn't run with XP, so that problem isn't a problem for me anymore); unfortunately, the developer isn't that "responsive": I've been longing for FL to implement a "search within the search results" for years - that functionality missing had been the reason for me never buying that tool even when it ran with XP (there's always an XP-running free version available btw, but I think that's not pertinent for the readers of this forum).

Since it's evident that a non-indexing searcher is in heavy need for a "search within the results", when each search takes long minutes if the file body to be searched is big enough (the developer brings - imo quite weak - arguments for leaving this out, but if I accept to gratuitously wait minutes for search results if the tool is free, I do not do so if I have to pay more than 60$ incl. VAT) - and you cannot delete non-pertinent search results (as described above) in FL either.

Search-within-search isn't the same as vicinity search of course, but often, you could use either one or the other to get to your means. (This isn't true when the vicinity searched-for would be a very close one.)

-ital2 (August 01, 2017, 01:46 AM)

From the FileLocator Pro Help file (version 8.2):

Sometimes it is preferable to limit subsequent searches to the result list or a subset of the result list. FileLocator Pro supports searching file subsets through two menu options:

File - Search Result List
Searches all files listed in the result list.

File - Search Current Selection
Searches all files that are currently selected in the result list.

Search within search works by creating a new search and pre-filling the Look In field with all the files to be searched.


FL Pro also now allows the creation of indexes.

If your problem is with music software, I gather you are talking about the cover art embedded in your music files as metadata, rather than booklets and backs, which you would be viewing in a file viewer.  You just need one file per album for embedding, usually named "folder.jpg" by some unfathomable convention, but if you are like me, you need many more for documentation. 

I too have thousands of ripped CDs accumulated over several decades (and thousands more yet to be ripped), along with vast amounts of album art and documentation. Whenever possible, I buy music as CDs and rip them myself, in which case I sometimes scan the cover and some of the other material myself. But much of the artwork and documentation I have comes from a variety of sources like publishers, online stores, etc.

The ripping software I use (EZ CD Audio Converter) automatically obtains metadata from various online databases and will download cover art for most CDs  I rip, but I almost never keep those images, which are usually inferior to what I can obtain on my own.

To create the cover art file to be embedded in the metadata, whether I scan it myself or convert an existing file, I use Paint.NET, a free photo editing program that is extremely easy to use but gives me all the flexibility I need.

Artwork obtained from other sources can sometimes be unreasonably large, particularly if it is meant for printing.  I'm only interested in being able to read the information, so if the files take up too much disk space, I convert them to .jpg if need be and resize them using Irfanview, which has a batch conversion and resizing tool with many advanced options.

For adding, extracting and removing cover art from music files, as well as for nearly all my metadata editing, I use mp3tag.