Hello,
Did a search and don’t see a similar topic unless my key word string was not accurate enough. I just finished processing just over 900 MP3s and confirmed the same cover art was applied to all of the files. While I was reviewing all the files before saving, I did notice the cover art was appearing on every file.
What did I do wrong and what is the best way to fix it?
Thanks.
Please check that those files have been tagged as being from different Releases.
If you can rule out them being incorrectly tagged then someone else will be along to help figure out what has happened.
It almost looks as if this same single cover art applied to all the MP3s is a bug of sorts. What it applied is the cover art from the movie Universal Soldier II: Brothers in Arms. I was going to upload the image which was embedded into the files, but don’t see a way to do that in this forum.
Yes, they are MP3s ranging from AC/DC to Whitney Houston with all varying types of music, albums, artist, genres and so on. It did it on a second smaller round of tagging with remaining songs from the previous round. Have screen captures to show what it did. As an IT Pro, it has me quite perplexed. Previous test rounds of tagging generated the correct cover art. I am new to the program and had to do a couple of test rounds to see how the program behaved, settings worked et cetera. The earlier rounds seemed to get the right cover art for the songs until the last one. I had to run a couple of rounds through Magic MP3 Tagger and Picard to get most of the tagging and metadata populated more accurately.
It has to be a setting or a bug or both. I won’t mess with it, until someone comes along help deconstruct what is happening. No hurry at the moment. No raves to DJ or parties to entertain with the music anytime soon. LOL
Thanks, mmirG.
Just a wild guess: Are the files all in a single folder and have you the local cover art source enabled? If that cover art is maybe already as a file in this folder the local files source could pick it up and use it for all files. It is designed to work for the typical case of one folder per release. If you have a flat folder I’d recommend disabling the local files source.
If this is not the reason I’m really puzzled. Maybe share a screenshot of your cover art settings.
Excellent, looks like I can now upload screen captures.
Hello Outsidecontext,
Thanks for the reply on the RegEx script on the other topic. Will reply to that later this weekend.
To answer your questions. I allowed Picard to create the directories and put the files into them as I did with previous runs on the same files. I did select the option to embed the cover art.
Also, took those same files and checked them in MP3TAG. It confirms they are there and applied to all the MP3s individually. Aggravated Windows Media Player changes the cover art. Noticed WMP changed cover art to a smaller, lower resolution images previously. So, I removed all library locations in WMP a couple of days before the run to be sure it would not interfere. So, we can rule that out as a possible cause.
I should probably review any and all settings/options for the cover art. Are there optimal settings for such a wide variety of music? A good guideline to follow for a bundle of music like this? Those will be the next screen captures, cover art settings.
I haven’t changed anything in the program yet. It is as it was when it first caused the issue and when I recreated the issue. Haven’t disturbed the crime scene yet.
Thanks.
Edited for clarification
Here is the 200x200 cover art extracted out using MP3TAG.
How do you disable the “local files source”? I see a RegEx script in a long text field on the Cover Art>Local Files option page. Don’t see a check box to enable/disable. Am I to assume that I need to clear the script out of that field to disable it?
If I remember correctly, I started with copying only the .MP3 file to a single directory so as to not introduce problems. I have to do some more searching through my processing folders, but I would say your theory has to be the most likely possible explanation for what happened.
Any suggestions for optimal cover art settings?
Thanks.
Have a look at what you have enabled in the Cover Art Provider section of the Options settings. There is a bit of an explanation in the draft documentation that I’ve been developing.
Thanks, RDSwift,
Looking through that documentation on a web page to which the Help button in that option window redirects me. I assume that is the documentation to which you are referring. Would that be correct? Based on that documentation everything appears to be set optimally. I have to read through it a few times to make sure I have it right.
Is this where you disable the use of local files for cover art? The text field on the Cover Art > Local Files option page is to only define a path to point the program when the below box is check, correct?
I think that I know what has happened. The first initial runs ran correctly. Subsequent run introduced the rogue cover art. I searched for all *.MP3 files in a finished directory and subdirectories. Then, I copied them to a single rework directory, no subdirectories. Just before reprocessing them, I intentionally or unintentionally played one of the files in WMP. Windows Media Player has a bad habit of taking the cover art from whatever file you play and puts two size images at the same single directory level were all the MP3 were ready to reprocess. Files names are always AlbumArtSmall.jpg and Folder.jpg. If MBP’s Cover Art Providers > Local Files option is checked, then that is why I have the same rogue cover art for all 924 songs. I need to find a way to stop WMP from doing that if I intend to keep it installed. That is very very annoying and tempted to uninstall it for good.
I used MP3Tag to remove all of the embedded rogue cover art. Selected them all and right clicked on the cover art display, selected Remove cover.
Have to assume that is one way to remove the wrong cover art. Also, have to assume I have no choice but to have MBP reprocess the MP3s to restore and embed the correct cover art.
Any other suggestions on fixing this, now that we know how this issue came to be?
Thanks.
Okay, I have been very busy doing clean up on all those songs. Had to do extra research on quite a number of them to ensure I had a proper match on the song. So, it took me some time before I could get back to this topic and report any useful results.
I made a few slight adjustments on the cover art options and reprocessed all of the songs. Managed to get cover art on 83% of the songs. Had 155 songs (other 17%) without cover art. It was a challenge trying to find some of the cover art, taking a hour or two for each song. Those are what kept me busy since my last post. There were a number within the 83% which needed re-work. A number of the issues were a result of songs having silence on the end of the song. Once that dead air was removed, AcousID fingerprints would more accurately identify the version of the song and the release from which it came.
When Local Files isn’t checked in Cover Art Providers, Picard will not use pre-existing image file matching the regex titled Local cover files match the following regular expression:.
Also you can re-order cover art providers (then Picard will try each enabled one from top to bottom until it can get a cover art image).
The use of Cover Art Archive is way better than anything else, CAA Release Group is a fallback, it will use the cover art from another release which has one in the same release group (so it might not be correct, but it helps when your specific release has no cover art yet).
Whitelist is mainly Amazon (for releases having associated ASIN), it is unreliable: it may fail to download an existing cover art (because we don’t use API, but an hacky mean), and Amazon itself is unreliable when it comes to cover art (especially for releases sold by third parties).
Thanks, Zas. The information and the order on the cover art providers was very helpful. I did have to move the Whitelist provider to the last position.
