hi
if i have multiple disc album,root folder is named - artist year album, and than disc 01, disc 02 etc, if apply my directory format value to rename, it will rename disc 01 or 02, and put all files in there, how do i rename root folder, and leave dics 01,02... intact?
tnx
THis is only possible if the root folder is not the root folder, 
You have to be on the superior level which shows all artist year album folders.
Then read all tracks from there, apply a filter to filter that album and then rename all tracks.
What I would be interested in: where do you store the album name? if it is the same for disc 01, disc 02 etc. then MP3tag will not have any clue where one disc stops and the next begins.
Or: if you have the disc 01-stuff appended to album then it looks like all different albums and MP3tag will have no clue what the collective name would be.
The onyl chance would be that the albums have names like disc 01, disc 02 (rather boring) and then you can apply the root folder name in the mask for the function "tag - filename" like
root_album_name\%album%\%track% - %title%
So you have to have close look at the data that MP3tag can read and recycle for the different functions.
If you do not transport the differentiation with the album name you will get several track 1, track 2 etc. for the same album - so what is the purpose of your excercise?
Please let us see your "directory format value".
DD.20100119.1012.CET
tnx for the inputs, first, it's: %artist% '['%year%']' %album% '['flac']'\Disc 01...
second, i hate naming album - album disc01 etc 
and i don't have discnumber tag values also 
i like to keep my tags as minimal as posible
but it looks that without differentiation with the album name (eg disc 01), theres no way to do this
Maybe i'll start to use discnumber tag
edit, yes it worked with introducing discnumber value, eg 'disc' %discnumber%
but now all extra files like m3u, jpg.. are left in the original folder, since new renamed folder is also created within..
Try to "format value" the tag field _DIRECTORY instead of _FILENAME.
This will cause a MOVE of the complete folder instead a COPY of the tracks.
DD.20100119.1434.CET
it is
_DIRECTORY
%artist% '['%year%']' %album% '['flac']''Disc' %discnumber%
in this action i don't use any _FILENAME value
:]
When you load the track files respectively the parent folder respectively the root folder into Mp3tag you should have a closer look to the fact where is the Mp3tag workfolder situated (should be read in Mp3tag window title).
In relation to this workfolder you can assemble a relative folderpath which points to the place where you want to create the new subfolder of your wish.
As an alternative way you can use an absolute path starting at the drive root, carrying the complete folderpath which points to the new folder.
DD.20100119.1818.CET
i'll try
I'm sorry if this was already covered somewhere, but I've recently upgraded from 2.45a and discovered this seemingly new "workfolder" feature, which is constantly confusing me ever since.
I'm often using mp3tag to rename files by their tags, and I've been using the following format string with 2.45a:
..\%year% - %album%$num(%track%,2) - %title%
So, when I added a full discography with album folders already present, e.g. BandName\1990 - Album1..., BandName\1992 - Album2... etc by sending the "BandName" folder to mp3tag, it worked just fine. It also worked fine when I sent a few selected albums under "BandName" to mp3tag. Well, it always worked fine, and I never had to think about changing the format string or looking at the window caption.
But then the latest versions suddenly started using the application's workfolder as the root for relative format strings, which breaks all my logic. When I send some files to mp3tag, I expect it to act exactly the same way regardless of what folder was open in Windows Explorer at the time. The only thing that matters for me is where the actual files are.
So, the question. Is there any option to disable this new functionality, get the old logic back and stop confusing myself? I mean, other than downgrading back to 2.45a (which I really don't want to do, because I had a lot of crashes with that version).