Splitting a library

I have a music library from which I would like to copy all tracks of all albums containing one or more tracks having a certain tag value to one root folder and all other tracks to another.

Track pathnames are e.g. S:\TLIB\00008637207120\1\1.WMA where 00008637207120 is unique to the album.

EDIT: To clarify, I want the album folderisation to be preserved e.g. S:\TLIB\00008637207120\1\1.WMA -> S:\TLIBmatched\00008637207120\1\1.WMA or S:\TLIBnotmatched\00008637207120\1\1.WMA

Any ideas?

Filter your files as you want and then do it with an action
Type: Format value
Field: _FILENAME
Format String: Your destination folder path with the filename

So _FILENAME in fact takes a filepath?? Coo. Thanks.

Yes.
A format string like:
S:\Music\%artist% - %title%
or
S:\Music\%_filename%
will move the files to another directory.

You can also use the Convert-Menue -> Tag-Filename
and enter the Format String there.
This is good for testing because you can have a look at the preview and see the result of your string.

Aha. I see the only clue in in the Help that this takes a file path is the last example: https://archive.is/oPxg2#selection-941.0-945.29

Florian, I suggest the Help explicitly state that this accepts a file path.

OK, so move not copy. I'll make a copy using another program before then moving using Mp3tag. Thanks.

Though _FILENAME may take a path, %_FILENAME% doesn't deliver one, so the above fails to preserve the path.

I don't understand what you intend to say.
%_filename% has nothing to do with a path, it is simple the placeholder for the name of the file.

Sorry. I corrected the typo in my post.

I still don't understand.
My examples you refer to show how to move files to another directory-structure.
As I show in the example you have to specify the new path.
The use of %_filename% in the example has nothing to do with an old or new path.
The first example shows how to rebuild the filename with placeholders. The second example with the use of %_filename% shows that you can simply take the already existing filename without rebuilding it from tags.
Anyway you have to specify the new path which you can do by writing an absolute path or buiding one with the help of placeholders, like:
s:\Music\MP3s\%albumartist%\%album%\%_filename%

There is a copy files function in menu Edit>Copy...
Filter and select the files before you copy them.

Your examples show how to move the files to another directory. You show how to specify the patch of that directory.

Indeed, despite that _FILENAME does include the new path. I was pointing out that inconsistency.

Thanks for those examples, but none meet the requirements, because they fail to preserve the original path - specifically the album-specific folders, as shown in the example of my original question.

Thanks. Unfortunately that doesn't preserve folder structure. It strips the original folder path and places all files directly in the output folder, potentially suffering clashes like this: http://i.imgur.com/QnGfkYp.png

In case my original post wasn't clear, I've added an example to show stripping the folder path is unacceptable.

Yes, I know - you did not say anything about preservation.
Anyway: there is no function in MP3tag actions to COPY files. You can only move them (with actions).

So if you want to copy a certain set of files, you would have to save the original path somewhere in a (user-defined) field, like e.g. %origpath%
Then copy all the selected files without path preservation to a different location with the Edit>Copy... function.
Load the files from the new location.
Adapt the contents of the field %origpath% so that it shows the new path - it is best, if it is a fully qualified filename.
Use an action of the type "format tag-field" for _FILENAME
Format String: %origpath%

This should then create an equivalent of the old folder structure.

Thanks, but that fails with the clash I already mentioned http://i.imgur.com/QnGfkYp.png .

Still that does not matter if you supply path and the orginal filename for the field ORIGPATH.
You may then accept the suggestion of the OS to rename the file.
You restore the original filename with the data from the field ORIGPATH.
If everything else is correct, the filename should be unique again in the target directory.

The solution I've used is:

1 Copy the library to TLIBtemp and load the copy into Mp3tag
2 Set the filter and select all tracks
3 Execute this

4 On the resulting folder, manually remove S\TLIBtemp\ from the path.
5 Using Beyond Compare find each album folder that exists in both TLIBtemp and TLIBmatched and move it (and contents) to TLIBmatched.

Thanks. If one wanted the files unchanged, one would need to remove the temporary field, though I would not like to bet that would actually reproduce the original file exactly, esp. on WMA.

Your solution sounds likely to be acceptable to someone who didn't mind writing to all the files to hold the temporary data. Since the files here are >250GB, that's something I'd prefer to avoid.

Though your solution doesn't meet the requirement to copy all tracks of the albums found, it does allow this to be done manually in the same way as my solution:

5 Using Beyond Compare find each album folder that exists in both TLIBtemp and TLIBmatched and move it (and contents) to TLIBmatched.

I know of no scenario where the use of _FILENAME preserves a path.
_Filename does not care about the path and when a path is not touched it is naturally preserved.

Well you changed your original question today.

You do not want to perserve the path, you want to preserve a part of the path, in your case it is the parent-directory.
So move your files like this:
S:\TLIBmatched\%_parent_directory%\%_directory%\%_filename%
and
S:\TLIBnotmatched\%_parent_directory%\%_directory%\%_filename%

I would hold that bet ...
If you want to synchronize two sets of files and folders, I would recommend a synchronization tool. E.g. Synctoy by Microsoft is free. and it keeps the folder structure if there are sub-directories.

I would too. The program Beyond Compare used in the solution I chose is a synchronisation tool.

The snag here is that the file set being synchronised is spread across some but not all sub-folders. Mp3tag knows the set, but can't copy them (inc. internal paths). A sync tool could copy them, but does not know the set.