Using Windows Explorer to Query Music Files:

Sometimes I do an indexed search from a Windows Explorer window using Advanced Query Syntax (AQS) . For example, when I want to search all of my music folders at once. That can be very slow in Mp3tag but is nearly instantaneous with an indexed search. Then all I have to do is to select the Explorer results, choose Mp3tag from the context menu, and make my edits.

This post contains practical, tested examples of AQS. To use them your music folders must be indexed by Windows. That is not automatic so you may need to use the Windows Indexing Options dialog to add your folders. Settings in that dialog and in the Search tab of the Windows Folder Options dialog are needed to get search to work as described below. Attached is a screen shot of my settings in Folder Options.

Not all music tags (or "properties" as Windows calls them) are supported for searching. Right click on music files in Explorer and choose Properties>Details to see the list for each file type. There are additional properties like kind: that are not shown but that all files possess.

In an AQS query there must be no spaces inside property names. The name must end with a colon unless the property is used without a value. If the search string has more than one word and there are subsequent expressions then surround the key words for each property with parentheses. To match a string exactly, surround the query word or words with quotes. AQS queries are case-insensitive.

The operators AND, OR, and NOT must be capitalized. While the AND operator is shown here for clarity, it can be omitted because it is assumed when a query contains multiple properties. For example, these three queries return identical results:

ext:flac AND genre:jazz AND modified:lastyear ext:flac +genre:jazz +modified:lastyear ext:flac genre:jazz modified:lastyear
A leading hyphen is equivalent to NOT, so -genre:jazz is the same as NOT genre:jazz

AQS Examples for Music Files:

artist:(name here) returns the same results as contributingartist:(name here) album:string returns albums with "string", "Stringbusters", "no strings", etc. title:"Hello, Gorgeous" returns titles containing that exact string. title:="Hello, Gorgeous" returns titles equal to that exact string . title:"Hello," returns titles containing "Hello" but ignores the trailing punctuation. title:"Hello" AND title:~"*,*" also includes a comma that may or may not directly follow "Hello". genre:blues matches "blues" anywhere in the genre, like "Country Blues". genre:="blues" matches that exact string only but is not case sensitive. genre:(String Band) matches the words in any order and is not case sensitive. genre:="String Band" matches the exact phrase and is not case sensitive. year:2000..2006 returns items from a range of seven years in the year tag. NOT year:2000..2006 rejects items from a range of years. year:>1930<1935 returns year tags from 1931 through 1934. bitrate:128kbps..356kbps returns files within a range of bit rates. The kbps suffix is required. NOT bitrate:128kbps..356kbps rejects files with bit rates within that range. size:>5MB returns file sizes greater than 5 MB. length:medium returns lengths of 5 to 30 minutes. length:(>2510000000 <2530000000) returns lengths of about 252 seconds. Thanks to LyricsLover for the length syntax example.
Quotes are needed around parentheses when searching for them:
file:~"*(*)*" returns file names containing any text inside parentheses. title:~"(*)*" returns titles that begin with parenthesized text. The ~< operator does not work here. title:~"*(*)" returns titles that end with parenthesized text. The ~> operator does not work here. title:~"*(take*)" returns titles that end with parenthesized text beginning with the word "take" which is then followed by text. title:~<"(" returns titles that begin with a left parenthesis. title:~>")" returns titles that end with a right parenthesis.
The tildes tell Windows to treat asterisks and question marks as wild card operators, whether or not they are enclosed in quotes or parentheses. The tilde is also part of certain AQS operators, including "begins with" (~<) and "ends with" (~>).
album:~*[*]* returns albums with bracketed text. artist:~*[*]* returns artists with bracketed text title:~*[*]* returns titles with bracketed text. title:~*{*}* returns titles with text inside curly brackets. file:*[*]* returns file names containing bracketed text. No tilde needed. file:*{*}* returns file names with text inside curly brackets. No tilde needed.
Some properties are used with documents and pictures as well as music, hence the need to limit results to music files when the target folders contain a mix of file types:
kind:music NOT file:~"* - *" returns music file names lacking my standard delimiter string. kind:music AND file:~"*(1)*" OR "*(2)*" OR "*(3)*" returns music file names that contain the parenthesized numbers shown. Good for finding near-duplicate files.
A file: query will also return folder names that match the criteria. To avoid that, try one of these:
file:(keywords) NOT kind:folder file:(keywords) AND kind:music file:(keywords) AND ext:(flac OR mp3 OR m4a)
A question mark as a wild card limits results by length:
title:~????? returns titles that have five letters or less, like "Sugar", "Ruby", and "San". title:~" ??? *" returns titles that contain three characters followed by a space artist:~???????? returns artists with eight letters or less. artist:~"????? *" returns artists names that contain a string of five chars followed by a space. album:~???????? returns albums with eight letters or less. kind:music +file:~"????????????" returns music file names with ten letters or less, including the extension. file:~"??? *" returns file and folder names that begin with three characters followed by a space.
However, question marks fail with non-file queries that use operators like ~< or ~>:
artist:~<"??? " Fails. Instead use artist:~"??? *" album:~<"??? " Fails. Instead use album:~"??? *" title:~<"??? " Fails. Instead use title:~"??? *"
Track and year queries fail with question mark wildcards regardless of syntax or content:
track:0? Fails. Instead use kind:music -track:=[] and sort by the track column. year:19?? Fails. Instead use kind:music -year:=[] and sort by the year column.
When searching for digits in file names, I get better results by avoiding quotation marks. Parentheses are sometimes required and question mark wildcards may not work as expected:
kind:music +file:*000* returns file names containing a string of three or more zeros. kind:music +file:192 returns file names containing that number sequence anywhere. kind:music +file:192? returns file names containing "1920", "1927", "192A", etc. kind:music +file:~193? returns file names that begin with "1930", "1931", "193B", etc. Here the tilde prefix works fine alone but the ~< operator does not work at all. kind:music +file:~("* - 1935*") returns files containing these digits preceded by a space, a hyphen, and a space. The quotes are required to allow the hyphen to be seen as a literal, not as an operator.
Queries for digits in tags are simpler but question mark wildcards don't work:
kind:music +title:193 returns music titles containing those digits. kind:music +title:~<1933 returns music titles that begin with those digits. kind:music +title:~>1933 returns music titles that end with those digits.
Sometimes it helps to add a trailing space to a keyword to get the results that you want:
artist:~<"the " returns artists that begin with "The " or "the " but not "Theodore". This also returns files where the Album Artist tag begins with "The ". Show both columns in Explorer to see this. albumartist:~<"the " returns only album artists (not artists) that begin with "the ". album:~<"The " returns albums beginning with "The " or "the".
To search for null values use the equals sign followed by empty brackets. Null value queries often require a kind: or ext: property as well because otherwise they return non-music files that simply lack the named tag/property altogether:
kind:music AND title:=[] returns music files with empty or missing title tags. kind:music NOT comments:=[] returns music files with any content in the comments tag. kind:music AND year:=[] returns files with empty or missing year tags. kind:music AND album:=[] returns files with empty or missing album tags. NOT album:=[] returns files with any content in album tags. ext:=[] -kind:folder returns files of all kinds that lack extensions.
The property name for track number is track: or simply the # symbol:
kind:music AND #:=[] returns music files with no track entries. kind:music AND track:=[] same results as above.
For special characters in file names the syntax is: propertyname:*char* . For example, file:*+* returns file names containing plus signs anywhere in the file name. With file: this syntax works for the following special characters: ! @ # $ % & _ - + ' , ; [ ] { }

For certain properties a tilde prefix is needed to find special characters: propertyname:~char

album:~*;* returns albums with semicolons but artist:~*;* fails. No idea why. artist:~*:* returns artists with colons. title:~*,* returns titles containing commas. title:~*.* returns titles with periods. title:~*;* returns titles with semicolons. title:~*:* returns titles with colons. title:~*'* returns titles with straight apostrophes. title:~*|* returns titles with the pipe symbol. title:~*^* returns titles with the caret symbol. title:~*/* returns titles with forward slash characters title:~*\* returns titles with back slash characters title:~>? returns titles that end with a question mark. title:~>! returns titles that end with an exclamation point.
This last group of characters requires both a tilde and quotes:
title:~"*~*" returns titles containing tildes. file:~"*~*" returns file names containing a tilde (Windows long file names only). file:~"* *" returns file names with two adjacent space characters anywhere in the string. If you paste this example, add back the second space that was stripped out by your browser. artist:~"* *" OR title:~"* *" OR album:~"* *" returns files with adjacent spaces in those tags. Same caveat as above: add back the missing spaces. artist:~"*&*" returns artists containing ampersands. artist:~"*& His*" returns artists containing the exact phrase "& His" anywhere in the string but artist:~"*and His*" returns artists containing either "and His" or "& His". album:~>">" returns albums that end with a right angle bracket. title:~"*=*" returns titles containing the equals sign. title:~"*<*>*" returns titles that contain text within angle brackets surrounded by text. title:(~"* - *") OR album:(~"* - *") returns titles and albums containing one or more hyphens surrounded by space characters.
Double up on quotation marks to find one of them:
album:~"*""*" returns albums containing one or more quotation marks within text. album:~<"""" returns albums beginning with one quotation mark. album:~>"""" returns albums ending with one quotation mark. title:~"*""*""*" returns titles containing one pair of quotes that contain text. title:~"""*""*""*""" returns music titles containing paired quotes separated by text, like "Stetson" from the Film "Whoopee!"
More Syntax Tips:
  • To return all files in a folder and in all of its sub folders, open Windows Explorer to the parent folder and type only an asterisk in the search pane.
  • With file: queries, punctuation within keywords is usually ignored unless the keywords are enclosed in quotes. So file:1-2-3 returns files with "1-2-3" but also files with just "123" in the name or extension. file:"1-2-3" returns only file names containing the exact string.
  • With tag queries, punctuation within or around keywords is usually ignored even when the keywords are within quotes. So album:"Vol. 1" returns the same files as album:"Vol 1"
  • When combining logic in a file: query, repeat the parentheses each time rather than putting all of the logic within one set. For example, use file:(*@*) OR (*%*) OR (*#*) rather than simply file:(*@* OR *%* OR *#*) because the latter will fail. On the other hand, a single set of parentheses should be used for tag and extension queries. For example, title:(~*;* OR ~*,*) finds either semicolons or commas in title tags and ext:(flac OR ogg) finds files with either extension.
How to Combine AQS Logic within a Query: I wanted to search my entire collection for song titles that looked like questions but that lacked question marks. Then I could add those marks by running an action in Mp3tag. I began by testing a fairly simple query:
kind:music AND title:(~<who OR ~<what OR ~? OR ~>!)
Then I added more interrogatives:
kind:music AND title:(~<"Am " OR ~<"Are " OR ~<Aren't OR ~<"Can " OR ~<Can't OR ~<Could OR ~<"Did " OR ~<"Do " OR ~<Does OR ~<Don't OR ~<"Have " OR ~<Haven't OR ~<"How " OR ~<"Is " OR ~<Isn't OR ~<"Shall " OR ~<Should OR ~<"Was " OR ~<Wasn't OR ~<Were OR ~<What OR ~<Where OR ~<Which OR ~<"Who " OR ~<Whose OR ~<Why OR ~<"Will " OR ~<Won't OR ~? OR ~>!)
Translation: if a music title begins with "who" or "what" or "how" or any of the other words listed and does not end with either a question mark or an exclamation point, then return that file name.

Note that certain words include a trailing space and are in quotes. For example, ~<"Will " excludes words like "Willow" that begin some of my titles. You will surely need to customize some keywords this way to suit your song titles. I removed "When" from the query because so few of my song titles that begin with it make sense as questions.

This query works pretty well. Once in Mp3tag I still have to review the list by eye to remove titles that are exclamations, like "What a Difference a Day Made" or "How Mountain Girls Can Love". Also, the query ignores a title like "You Wouldn't Fool Me, Would You" (a real song title from 1929) because it does not begin with one of the keywords.

Limitations of Windows Search for Music:

  • AQS queries do not support regular expressions and are not case-sensitive.
  • AQS queries do not distinguish between numbers and other characters. You can search a tag for a specified number but not for digits in general, like the Mp3tag filter %year% MATCHES \d{4}.
  • AQS can be quirky. For example, album:~*;* returns albums with semicolons but artist:~*;* returns nothing.
  • I have not found a way to use AQS to search for an asterisk within tags. However, Mp3tag can do this easily with a view filter like %title% HAS *
A few Windows music properties are not very useful with AQS:
  • rating: Windows uses its own rating scheme and ignores popularimeter ratings added by Mp3tag, Winamp, and others.
  • tags: this property is listed for M4a files in the Details tab of the Explorer properties dialog. Not clear what the property should hold or how to use it. Maybe someone here knows.
An indexed search may return the names of files that have just been deleted because the indexer has not yet caught up. This is normal, but to avoid confusion you can show the "Folder" column in Explorer, which will display "Deleted item" for such files.

While Explorer allows you to save searches the save uses the folder that was current when the query was executed. So I store my sample searches in a text document and edit them in Explorer as needed.

My AQS testing was done using Windows 7 with ID3v2.3 tags in mp3 files along with standard tags in m4a and flac files. If you are one of the brave souls using ID3v2.4 tags for your mp3s, you will need to use the latest version of Windows 10 in order for Windows to be able to index and search tags in those files.

More Information:
Microsoft once had user-friendly pages on using AQS in Windows Vista. They were taken down years ago and never replaced. More recent MS references are for developers but this one contains a full list of AQS operators, many of which have variations:

UPDATE: The next link is from 2009 and comes from the "wayback machine" at . This page was pulled by MS but it is a good introduction:

The last link has five pages that are a decent introduction to AQS but music files are not covered:

Final Thoughts:
These tips apply to music tag and file searches in English versions of Windows 7 and later. They are adapted from my notes, kept because the AQS syntax was confusing and hard to remember. I'm still learning the fine points by trial and error.

Of course, you don't have to use AQS — you can simply type a word or phrase into the search box and that may be sufficient. Although a "DOS-style" wild card search like .mp3 still works, it is slower and less reliable than an AQS query like ext:mp3. That's because .mp3 forces Windows to scan the entire file name and to look for that string within indexed document content (when available), rather than simply looking at the file extension.

AQS queries are not nearly as flexible or powerful as Mp3tag's view filters, but AQS can save a lot of time for people with large collections. Feel free to post your own AQS examples in this thread or to post questions about creating new queries.

I use the AQS this way for years because

  • my music library is far too large to be loaded into mp3tag completely
  • it would anyway take too long to load the complete library

So to use the AQS provides an effective and fast way to make a selection of files before loading the files into MP3Tag and filter them there.

But there is one big disadvantage for people using windows in another language than English.
Microsoft localized the query syntax and till today I did not find a complete documentary for the syntax in german.
While some localizations are easy to catch, ie. "Interpret" for "Artist", "Datum" for "date" the more complicated are really hard to find and learn.
I will never understand why MS localized such a special syntax and on the other side did not propagate a docimentary in the localized languages.

Poster, thank you for your response.

Even the English documentation was far from complete. I too had to figure out many things on my own and to test every single AQS query myself. If I had faced the language difference that you had, I might have given up.

As to why Microsoft removed the user documentation, I can only speculate. When Vista came out, it was heavily criticized and people said that the new Windows Search "did not work". I suspect that MS decided that AQS was "too geeky" and so they added more drop-down choices and graphic options to search in Windows 7 and later.

Perhaps they thought that people would be confused by the user AQS pages that were available during the Vista period. I see this as part of the general trend toward the "dumbing down" of both Windows and of much consumer software. I hate that trend!

Doug Mackie

Very helpful post, Doug Mackie. Thank you.

There are two major issues with AQS:

You will not find all your tracks written in lower case letters like "a-ha" only.
You will always get all syntax variants like "a-Ha", "A-HA" etc. This is especially an issue if you want to fix your tags for such songs.

I found no way to search exactly for a string with lower and/or upper case letters.

It's very hard to find the translated search keywords.
I mean, would you ever use something like länge:sehr kurzto search for songs with a length under 1 minute? They even use umlaut (mutated vowels = äöü) and spaces :w00t:

The only way to know if you have found a working german AQS keyword is the color change as soon as you typed in a correct AQS keyword followed by a colon, like
bewertung:3 sterne
bitrate:cd-nahe qualität mehr als 128 kbits <- another crazy one!

Maybe we should start a collection for german AQS audio keywords? :music:

If you use this example:

you can type all the visible (german) properties as keywords with this exceptions:
"Mitwirkende Interpreten" must by written as one word:
"Autoren-URL" could be "autoren:" but I'm not sure about the meaning.

The last 3 file properties:
"Verfügbarkeit", "Offlinestatus" and "Freigegeben für" seems not be valid search keywords. The other (like "attribute:" or "grösse:" or "änderungsdatum:") works fine!

First step is to find the correct german tag-name. I learned these by making a right-click on the head of the columns, where you select the columns you want to see or having a look in the delails of a file.

More complicated is the syntax itself as you know.
As I mentioned I mostly use the feature to preselect files for Mp3Tag and there it is often possible to avoid complicated syntax.
i.e. looking for short mp3s I simply would create the column length and sort for this column.

All I could find with the german syntax in the internet were pages like "Die besten Tipps zur Suche", where some examples were listed but I never a complete documentary.

BTW I found a nice english cheat-sheet for the syntax as a pdf:

Nice one! Thank you.

What could be the german translation for "lyrics" in the AQS?
Would be cool to search for words in lyrics if this really works.

I believe the solution for the translation problem is called "canonical property names".

For example the possible Music properties are:

The possible Audio properties are:

The possible Media properties are:

If you are looking for the "Mitwirkende Interpreten" I assume it is
For the "Länge" you can use
Example: If you are searching for a music file with 00:04:12 length, you have to multiple the total seconds (4 x 60 seonds + 12 seconds = 252 seconds) with 10 millions, because the search system seems to use nanoseconds as values. You would use
System.Media.Duration:(>2510000000 <2530000000)
If you try to search for the exact value with
System.Media.Duration:2520000000 you don't get the desired result, because you can't see the exact length of your music file in nano- or milliseconds in windows explorer. You only see a rounded value.

For the "Bitrate" you can use

Some general properties are
System.Rating: -> Bewertung
System.FileAllocationSize: or System.Size: or System.TotalFileSize: -> "Grösse"

You can use them as Doug Mackie wrote in his initial post. They should work on all languages, at least they work in my german windows 10.

1 Like

You are quite welcome, LyricsLover, and thanks for the PM about the length property. I have added your example to my original post. And thanks for the canonical properties list. I did not include those because my post was already so long!

There is no way. This was confirmed by one of the MS developers in an MS forum post many years ago. It has to do with the way their indexing works with word segments rather than individual letters.

I've moved the off-topic discussion of benefits/drawbacks of indexing to a separate topic to keep this one on the topic of AQS. Impressive topic, thanks for sharing!