Purely by accident I came across this setting which was checked.
Since I never use embedded album art, I immediately unchecked it.
However, this means that it requires a very specific naming scheme to make sure the front cover is actually the first found image... And whichever naming scheme you use, invariably you almost always have 'front', 'back', 'disc', 'inlay' or some such indicator in the name. This results that most times the back cover gets picked, since whatever scheme you use, if the mentioned strings are part of it, the back cover is the first one in an alphabetic sort.
So, it would be nice when the above setting is disabled, we could specify which string must occur in the name. (I happen to have this in front of the album/artist name, but others may have it at the end...)
It was just a suggestion, I can live without mp3tag showing artwork, especially if it means I have to adapt to a software instead of the other way around. As long as my player of choice knows which is which and allows me to specify which are front covers and which are back covers I'm fine.
Just out of curiosity:which player reacts to specific prefixes to show the correct album art?
The players mostly mentioned in ths forum can cope only with 1 picture be it embedded or external and if it is external, they prefer a fixed name as @poster has pointed out.
I guess with so many members you don't remember me having mentioned which player I use, but it's foobar2000. There exist various components that allow you to cycle between the present artwork images for any given album. Which means I have a serious dislike for embedded artwork.
And it doesn't just allow me to specify a prefix, it allows me to specify down to the last lettter of the filename what pattern to use to look for artwork, and not just the front cover but also the back cover and disc images and any other art that might be present.
So, you'll understand I have by now a pretty fixed set of rules to match the present artwork. The three major ones are
but I've got others matching different patterns depending on the source of the artwork so I don't have to rename files if they get downloaded through other means (e.g. Discogs or Music Brainz) than with Album Art Downloader, in which I can specify the same rules to create filenames as foobar2000 uses to look for them.
So I really don't see the need to start duplicating files just because some external tool I sometimes use isn't this flexible and where showing the front cover is just a convenience to me.
I understand others may feel different and put more emphasis on mp3tag being able to show covers, I just put more emphasis on the player.
Yes, foobar2000 is a very flexible player with a lot of functions. Probably more than most players have.
And as you use these pretty features it still
It means to me that you have to look for a naming scheme that enables foobar to show the correct images.
And if that naming scheme is flexible enough then you could easily adapt it so that not only foobar can cope with it but also other programs, e.g. MP3tag
you should see the front cover also as first file in MP3tag - and the WIndows Explorer.
I would also prefer my naming scheme to keep all the pictures of one album together if the files should ever get collected in one folder or be dispalyed in a search as your naming pattern would first list all those starting with back, then those with cd, and finally front - and I would never know whether I had all 3 types together for one album.
But that would be just me and my way.
It does not mean that I argue against the suggestion.
Yes, on the basis to cope with the weakest link in the chain.
While MP3tag can create more or less any filename for an exported cover, there are players around like Windows Media Player or VLC that like to see a file with the fixed name folder.jpg or cover.jpg respectively. I have not seen any success to convince the publishers of these programs to change anything in this behaviour.
Which also means that you will probably not see any of the external cover picture files with your naming scheme.
So if you wanted to see a picture you would have to adapt to that software.
If Foobar has more features in that respect then that is great. But it would still leave you with the requirement to finetune your workflow to make all the elements work together.
Yes, a good attempt is to issue a feature request as you have done here.
But what are you going to do until the feature is implemented?
Not use the existing function at all?
Or see how the existing function can be used with some (minor) changes in the current workflow?
On principle I agree with you. From a practicality standpoint however, ohrenkino is right. If you want a wide variety of software to recognise your artworks, you have to adhere to the commonly used namings (even if they are inferior). Defining patterns to recognize and display various artwork types is a advanced feature that hardly anyone uses.
I use my library with a bunch of different software (musicbee, mediamonkey, jellyfin, plex, lms, symfonium..) and found the easiest way to get almost everything to AT LEAST get the main cover right is to use one Cover.jpg file in the folder of each album and putting the other artwork into a "Artwork" subfolder that most players ignore. Except for MusicBee which is pretty flexible, like foobar. MusicBee scans the Artwork subfolders as well and displays all the artworks correctly (if you set it up that way).
Realistically I won't look at an entire booklet on my phone anyways so I'm fine with only my main desktop player displaying everything while the rest of the software only displays the main cover.
One pitfall that even my naming scheme has is that I sometimes have 2 versions of the same cover (scan vs. web source, different styles etc.) and store both as Cover.jpg and Cover1.jpg in the album folder, Cover.jpg being the one I prefer.
Plex is so inflexible and dumb that it randomly selects Cover.jpg or Cover1.jpg as the main cover and there is no way to configure that behavior (last I checked).
In a perfect world we could specify regexes for every cover type in every piece of software, however it's an imperfect world.
Ah, yeah, I can see how that can pose an issue. Not only with covers but with tagging too. The latter mainly being the reason I've, since my last post, mostly stopped using MP3Tag for tagging in general.
As for software, I have FB2K hooked up to my sound system, so even though I also use Plex, I never let it, nor any other audio software touch my audio library. FB2K just has too many features that are hard to match in anything else when it comes to DSP chaining. And I use FB2K on my mobile too.
I've got bitten once to many times by the differences in MP3Tag vs FB2K... I already used it rarely, but took it up again recently, and I noticed I was seeing an awful lot of 'Not Responding' in the caption. Discovered it could use a database and got bitten hard by that feature on the odd occasion I used MP3Tag, as it reverted all the changes I had made in FB2K since I last used MP3Tag. Apparently, it does not check if the tags in the files still match what it has stored in the DB if you hit refresh, but only when you click on a row...
There is a refresh option to deal with that. You can't have it both ways - a database to speed up access but then modify the data externally as well. You have to choose one or the other to be the master and work from there.
Which is why I dropped MP3Tag in favor of FB2K, and only use MP3Tag for those situations I cannot get MassTagger to do what I can do with Actions in MP3Tag, but, without using it's database feature...
I would have expected the refresh button to also update the DB, alas it doesn't.
I think you are mistaken. The database is updated once the tags are refreshed. But the save only occurs when closing the current session of mp3tag.
There are many options out there for rippers, players, music managers, and editors. Which flavours satisfy your needs is completely up to you to decide. But expect to have issues when you try to mix and match.
I haven't used Foobar desktop for years for the very same reason, yet iTunes, Plex, and all my iOS and Android devices are all working just fine. Rip with dBPoweramp, update tags and file structure in mp3tag.
That's a good strategy which I also use. I only touch the tags in mp3tag or one of my scripts, everything else only gets read access. My sister used to have write access as well (so she could add music too) however I had to take it away when I encountered her merrily moving flac files from the server to her phone while she attempted to sync music to it.
Different states between programs are never a good thing and can lead to quite a bit of confusion, especially when there are different internal mappings at work that counteract each other.
On my tower I use MusicBee (portable install on a network share that I can also use on the HTPC hooked up to my TV and receiver without having to scan twice). On android I use Symfonium. When casting to my raspberry pi 3b (hifiberry dac hooked up to the amp) running upmpdcli I also use Symfonium. My father is too stubborn to switch from MediaMonkey to Musicbee so he still uses that. My sister is lazy so she usually uses Plex since that has the quickest scan times to show new stuff. MusicBee takes 30ish minutes to sync, mediamonkey 45is minutes and Symfonium 50ish (via the jellyfin API). My friends also have access via Plex and thanks to dyndns, let's encrypt, jellyfin and Symfonium I can stream my music everywhere in the world (where I have internet access).
Deploying a variety of software for different purposes can be really convenient.
That's a pain. I've refrained from using the db feature so far since it would probably take days to scan (if it finishes at all).
Just to get that clear:the MP3tag library is only an internal help to load also large collections as it stores the pictures externally in the database.
As it also saves which file has been added/modified when, it also speeds up the reading of previously loaded files.
Without the activated library all files are new files.
The library does not store tags for reference.
So, I would like to see the scenario in which the library overwrites externally modified tags.
