Hi,
Back to version 2.50 for me too. The old way was something more natural for me. I just wanted to give my opinion.
bye
[ggle trad]
I want to thank you all for chiming in. For some reason I believe somebody else pressured the developer to make this change. 
It makes absolutely NO sense to not default to the folder you already tagging the album art from.
Wow, you're still whining about this?
Yes it is a vale of tears.
The new "feature" is a torture, there is no time saving, no comfort, only confusion.
DD.20120530.2250.CEST
Yes I am.
And based on your attitude, it sounds like you were one of the ones who pushed for this change.
I use embedded artwork only rarely, but in the instances where I do, I simply have an action that imports 'cover.jpg' from the current directory. I would never have a reason to add a cover manually.
So, no, I didn't push for this change. Someone may have suggested it - I have no idea - but I imagine it fit Florine's work flow, so he thought it was a good idea, overlooking the use case that I describe above.
Well that's you. In my case, I add album art all the time to match the music I'm tagging. After all, that's a big part of the reason why I use this program to begin with.
If it was just a matter of sorting by file names then I wouldn't bother with tagging and we wouldn't be having this discussion.
Well based on your vehement objections to my comments in this thread, I find that hard to believe.
That's not surprising.
I haven't once objected to your concerns, only the childish tone that you've used to insist that this be corrected at once. I expect it will eventually be changed, or an option added. You've undoubtedly gotten the attention that you've sought, but I doubt that it's much of a priority for the author.
In my setup cover images are either already in the respective music disc folder (no subfolder for images though) or they are freshly retrieved in my Download folder. In both cases MP3Tag finds them on first click which I utterly like.
Where on your disks is the "Download folder" and how did you tell Mp3tag to use this "Download folder" in case of there is no image file in the current media folder?
DD.20120601.0827.CEST
WIndows XP and W7 (and probably also Vista) show a folder called "Download" in "My files". In many cases a browser accept/uses this folder as default folder for downloads.
ohrenkino, thank you for coming in and help me to find out.
Hm, strange, in the list of Special Folders ...
http://msdn.microsoft.com/de-de/library/sy...t.specialfolder
... there is no folder "Downloads".
On my XP there is a system folder "My Documents" ("Eigene Dateien"), where exists a folder called "Downloads", but this folder is empty and has not been used for many years, and this folder has never be used automatically on download processes at any time I can remember.
As far as I know, Mp3tag has no standard folder defined to look for image files, beside the home folder of the current media file, and therefore I asked "The Owl", how he did set up Mp3tag to use his "Download folder".
DD.20120601.0940.CEST
I could imagine the following use case:
As a habit the user saves the web downloaded picture(s) in that folder "Downloads".
He opens MP3tag to import the picture - and here comes the new way to remember the picture folder: as there is no file in the current audiofile folder MP3tag navigates to the last folder (and the user for the first time to the downloads folder). For all the following imports there is either a file in the current folder or one in the downloads folder ... in this (special?) case the behaviour is quite straight forward.
In the old days (pre 2.51) the Downloads folder was just 2 clicks away as usually there is an extra button for My files in the file selection dialogue.)
I have to be honest: I use the Downloads folder fairly often as I see it as a good collector for any kind of garbage the looks like a good idea keeping when stumbling across. But just as often, as time goes by, the fascination fades and as part of the necessary clean-up the files in that folder go straight to the bin - or the appropriate other folders if they are worth keeping. I see it as rather convenient to have just one place to look at ...
Coming back to the initial problem: as workflows seem to differ so much and looking for covers is such a regular activity, it is probably best to leave the choice to the user ... and create an extra option for the folder selection ...
well, i like the old feature, it was very very easy to use. This new one i don't like.
It shouldn't be.
Well good. Since you seem to be in the know, maybe you get him to make a comment here about what he intends to do.
Otherwise I assume you're speaking for him.
And as I said before, keeping hundreds of .jpegs in one folder (in this case the Downloads folder) is both cumbersome and unorganized. I have no intention of renaming each and every .jpg just to sort out and find the one I'm looking for.
Most of the time I have to go out to the internet to look for an album cover that's not available since I don't have a scanner, so it makes logical sense to place that album art in the same folder as the mp3s it's associated with. And I keep a subfolder called "artwork" in there to keep them separate from the mp3s, but just close enough to them for easy access.
I don't understand why he didn't do that to begin with. Make the old feature the default and add something in the preferences menu for those who want to do it the new way.
Hi Florian,
First thing, let me say "Thank You!" for creating such a great tool. I only have six months experience with creating my own music server library, but Mp3tag has been an indispensable tool that has made the tasks much more manageable.
This new feature does frustrate me -- I only updated to 2.51 this morning, but find the issue troublesome enough to register here to ask if it can be disabled in future releases.
My practice is to populate album folders with art when available, always named "cover.jpg"
Then, when using Mp3tag, I can embed from the existing file OR use the AAD tool (configured within Mp3tag) to retrieve the art if no cover exists in folder.
The problem is that when using Mp3tag this morning, after update to 2.51, I was adding several albums with same artist. Some of the folders had art (filename cover.jpg) and some did not.
For the albums that did not already have "cover.jpg" file, the previous behavior of Mp3tag would be to show me an empty folder when I perform "add cover". This is GOOD, as it prompts me to then use the tool AAD to find the art. With this scenario in 2.51, unknown to me, decides to show me the "last used" folder when I attempt "add cover". This is BAD, because as I was adding several albums from same artist, it was not readily apparent it had switched folders (I know this is my fault, but in a rush and seeing same artist name initially had me thinking the folder was for the current album I was processing, not the previous album.) If I only was paying attention to the artist name (was identical for both folders) and the art filename (also identical each case) it is sure to trip me up. I understand someone else may have a good use for the new feature, but not for me, and I will revert to previous version 2.50 to keep the ease of processing.
I WANT to see an empty folder if no art exists. In my haste, when adding multiple albums, some may have art ready and others not. I won't remember each case when tagging, so when working fast the best prompt for me to seek art (using AAD) was when I got the empty result attempting "add cover." Having the program switch me to another folder, where I see the identical filename (cover.jpg) is NOT going to help me go fast.
Using Mp3tag has always allowed me to work fast - this new feature creates more hazard (for me, and at least some other users.)
Best Regards,
John A
I just spent hours trying to figure out what has happened with this - I restored an older settings back-up, etc. before I searched and stumbled upon this thread. Firstly, without a doubt, this new implementation is not streamlined and it is not effective. I have MANY folders, with subfolders in it, and this new system simply doesn't work. Here's a simple example
Main Folder [Classical Music] -> folder [Mozart] -> folder [Concertos] -> inside this folder are the individual tracks, and also one folder called [Scans]. All album art and scans are inside this folder. Previously, after I fixed all the file information (title, etc.), I simply right-clicked on the Album reticule, left clicked on Add Cover, and it would conveniently open the "nearest" logical folder (but always, at the minimum, it would focus on the folder in which the music files were present), which, in my case is always just one click away from where the scan are (Windows makes it dead simple to move up or down the folder steps). Now, it opens the last folder I was in, which could be a complete different directory. It makes no sense. Sorry, I don't even see the real logic in changing it (and I do embrace logical changes, even if it is weird at first) - but I don't get how this facilitates the process. Either give an us an option between the streamlined way and the new way, or I guess I'm sticking with the older version. Thank you, nonetheless, for an incredible software! (no sarcasm)
As far as I remember this folder is created by Firefox and is used automatically for your downloads as long as you don't activate "Ask me where to store the downloads each time".
If you deactivate the Default-Download-Folder and activate the asking firefox offers the folder that was used for the last download.
I agree that this changing in 2.51 is not a good idea for users who first store their covers in a folder below the album folder and then want to add covers to the cover-tag.
I store all covers to the album folder itself and add only the front-cover to the cover-tag.
Therefore I am not so much disturbed with this new feature.
Only in few situatuations I add a cover to the cover-tag from another folder and then export it to the album folder. But even then it is a little confusing to be guided to the last used folder if this folder was another album-folder.
So I think it would be best to define an albumart-folder (download-folder, picture-folder) which is the folder to be guided to in case there is not cover in the album-folder and to enable the user to deselect this feature at all.
Hi Florian,
now it is two month ago ... ... ... ... ... ...
when do we can expect that it works the same way as before Mp3tag v2.51?
Regards
Detlev
DD.20120716.0924.CEST