Embedded MP3 Cover Art - Where?

[jhyler 3]

Please note - this has nothing whatsoever to do with the cover art plugin. I do not have the cover art plugin installed.

I have a "music" library which contains .mp3 files which aren't really music at all. The library consists of public domain spoken word albums that I've downloaded from the net. Before I upload them to my emby library, I run them through mp3tag, and among other things I remove any cover art they contain.  I then upload the files to my emby library folder, let emby scan the library, and then look at the library in the Albums view, see that there is no image for the uploaded album, and then do an "edit images" to upload the art I want to use for the album.  At least, that's how it works most of the time.

Once in a while, the emby album will display an image of the logo of the site from which I downloaded the mp3 files.  If I delete that image and reload my own, as soon as the library is rescanned the logo image reappears.  The only way to keep this from happening seems to be to lock the library entry of the album after I upload my preferred image, before the library gets rescanned.

Where could this image be coming from?  These albums won't be found on musicbrainz, etc., and in any case I've disabled all the image downloaders for the library. I've checked the uploaded data for any image files of the logo, and don't see any. And I've confirmed that mp3tag says there are no cover art images in the files.

So, can someone who knows how the code works tell me where the emby library scanner looks for images to use for mp3 files, when none of the image file downloaders are checked for the library?  This is starting to drive me nuts!

Thanks!

Edited March 24, 2021 by jhyler

[Guest]

Emby uses the tags to identify the data... SO if there is a listing for the site somewhere.. it may be finding that art.. if it is not found it reverts to the tag data when no result is achieved or uses that data first, updates from online second..

I am not for sure if mp3tag is modifying all forms and versions of tags.. I do know that TagScanner updates all versions of the tags when it edits.. so you can have three versions of the tags present and only be modifying one of them.. TagScanner will allow you to update them all.. I would check that..

What kind of thumbnail image do you get in Windows? ( Viewing as Large Icon )

[jhyler 3]

I get the player app icon (VLC in my case) for all the mp3 files. There are a few image files in an "extras" subdir for which the thumbnail is the image itself, but none of them are the logo image I'm trying to track down.

I'll have to give TagScanner a try.  Thanks for the lead!
 

[Guest]

Hope it helps  

[jhyler 3]

So I downloaded TagScanner, and as far as I can tell it agrees with mp3tag that there are no covers in any of the mp3 files. I then started thinking about other information that might be pointing back to the original site. So I did the following:

• I deleted the album image again.
• I removed everything from the album folder that wasn't an mp3 file.
• I turned on debug logging and rescanned the library.

I found this in the log:

2021-03-23 21:49:13.119 Debug App: MusicAlbumImageProvider reports change to 187064 - /mnt/user/Radio/DA
2021-03-23 21:49:13.122 Debug App: Running MusicAlbumImageProvider for /mnt/user/Radio/DA
2021-03-23 21:49:13.122 Debug ProviderManager: Saving image to /config/metadata/library/dd/dddd8ba208051869c7e5c9fee1eed5b3/folder.jpg

I checked that folder.jpg, and it is indeed the logo image I'm trying to get rid of. I deleted that file directly from the metadata, rescanned the library, and the file came back. 

Where is this thing coming from? I see only two possibilities: the image is embedded somewhere in the library files, or it is being brought in over the internet. The obvious test is to disable the network and see what happens. With the Internet disconnected, I try again. The icon image is still recreated. 

I have no idea where this file is coming from. Is there anyone with authoritative knowledge of what MusicAlbumImageProvider is doing, who can give the canonical list of where it might find images among album files?

Thanks.
 

 

[Guest]

Two things.. try to encode the file into the same or slightly different format...

Show me a detailed list of ALL tags.. 

[jhyler 3]

I generated the attached using TagScanner export 'http - extended album list'.  Interesting that all 6 images it attempted to render are broken.

Let me know if this isn't what you're looking for. I don't know of a tool that dumps out every tag, standard or not, from an mp3 file.  I wish I did.

AlbumList.htm

Edited March 24, 2021 by jhyler

[Guest]

So.. how about a detailed screenshot of just the tags.... Sometimes the images can be in another format...

What I am looking for is a string of weird text... hopefully the images are not embedded using Base64 or something else, would be interesting to find it..

The image it is looking for is cover.jpg in Downloads... on your computer.

I would encode these to another format using EZ CD Audio Converter Free without any metadata in the settings and try them to see what happens.. Basic metadata as you please.. Sometimes images can be corrupted when they are embedded but it is rare and I don't think that is the case here..

[jhyler 3]

I should have mentioned - I am on Windows using my browser to access Emby, and can access the files via SMB, but the Emby server is actually hosted in a docker on my unraid (Linux) machine. Where would it be looking for cover.jpg in that configuration? (In other circumstances I'd just do a find for it, but we're talking about 64T of data I'd have to go through in total... not all of which is Emby!)  Which, I now realize, means this is posted in the wrong forum. Sorry; moderators feel free to move it.

Getting a single screen shot of all the tags is tough, given the number of files in the folder and the number of tags on each file.  Best I could do is take a set of shots that you have to look at as a collage:

1L	1R
2L	2R
3L	3R

Six images attached - mp3tag, I'm not yet fluent in TagScanner.  Re-encoding will have to wait until tomorrow, I'm afraid.

Thanks for sticking with me!

(Edit: had to delete images and pack in a RAR file or they would insist on embedding themselves in the post).

Screenshots.rar

 

Edited March 24, 2021 by jhyler

[Guest]

The cover.jpg said it was in your Windows machine at Downloads.. but I think it must have been exported there. The thing is that if tagscanner is saying it has a cover it is embedded from what I have seen... It does not export unless it is there.. Look for the icon all the way to the left.. While on the the Edit tab.. if there is one it has one..

According to the mp3tag thing .. there doesn't see to be anything in the columns shown.. Look in TagScanner as well under the EDIT tab.. then go to the right where it says standard and advanced.. click on advanced and see what info shows there.. any link to an external URL for a cover or anything of that nature ( was another  reason to get that screenshot of the tags ) mp3tag is showing the icon for the default program in your system..

The log makes it look like it is getting the Image from a Provider.

As far as what I can see so far.. These are the only answers I have.. 

[jhyler 3]

Thanks for all your help!  It's turning midnight where I am, so it will be tomorrow before I get back to it. 

(Re mp3tag and covers - all I've ever seen in that column is an integer expressing how many covers are embedded, blank meaning zero. The actual rendering of the cover images happen in a detail window similar to that of TagScanner). 

[Luke 42083]

Let us know how you get on. Thanks.

[jhyler 3]

After much experimentation, I think I got it. It was ultimately my mistake, though identifying it was made extraordinarily difficult by certain emby behaviors.  I will summarize the essentials:

1. Along with the mp3 files, I have an "extras" folder that contains several subfolders with miscellaneous information about the recordings - transcripts, pictures of scripts, etc.). Lurking inside one of those subfolders was a "folder.jpg" file that carried the image I was trying to eliminate.  (Strictly speaking I'm not sure extras folders are a legitimate part of the music folder structure, but they work so I take advantage of them. Same for .ignore, incidentally). My fault - it was part of the download and I didn't spot it until now.
2. It's not as  easy as just deleting that folder.jpg file.  For some reason after that file is detected in a library scan (more on that later), the folder image (but not the file) keeps coming back into the folder view. Somehow that image gets locked in, and even after deleting the file, using the emby UI to delete the image from the album and then using the GUI to install a different image, that old image keeps coming back at a future library scan. That seems like a bug to me. The only way I found to permanently get rid of the image once emby found it was to rename the album folder and rescan the library. This forced emby to completely redo the metadata and got rid of the image.
3. I would also consider it a bug, or at least a poor design choice, that a folder.jpg file in a folder multiple levels of subfolders below the album folder, be taken as the album image. I would say a folder.jpg file should have to be directly in the album folder for it to take effect.
4. Another thing that made this extremely difficult to resolve - that folder.jpg file doesn't immediately get picked up and applied by emby. Initial scans of the album folder resulted in no album image at all.  It was only my manually installing an image of my choice that triggered emby to apply the folder.jpg file. I upload my own image, scan the library, my image is shown.  I rescan, only now does the folder.jpg image appear. That seems like a bug also, and more than anything else what caused me to go through so many gyrations in figuring this out.
5. The final bug, at least in my opinion, is this: if a user uses the emby GUI to manually upload a primary image, that should take priority over anything else. A manually updated primary image should always win out over a file in the media folder. Or at least the user should be told "I won't let you manually upload an image because there's another one to which I will give priority".

Luke, I'd like to hear your opinions on whether these things I call bugs seem so to you as well, and if so if they might get corrected. Hxemby001, thanks again for all your help, and especially for the pointer to TagScanner. I think that's going to be my go-to tool from now on.

Cheers!

Edited March 24, 2021 by jhyler

[Luke 42083]

Quote

1. I would also consider it a bug, or at least a poor design choice, that a folder.jpg file in a folder multiple levels of subfolders below the album folder, be taken as the album image. I would say a folder.jpg file should have to be directly in the album folder for it to take effect.

Hi, this won't happen to albums anymore in the next release on account of other changes, but it could still happen in folder view when browsing by folders. If a folder doesn't have an image directly, then it may inherit one from lower levels.

 

Quote

if a user uses the emby GUI to manually upload a primary image, that should take priority over anything else. A manually updated primary image should always win out over a file in the media folder. Or at least the user should be told "I won't let you manually upload an image because there's another one to which I will give priority".

If you enable saving images into media folders, then uploading a new image will replace that image file altogether. We don't keep track of where images come from, so for this reason, images in your media folders will end up taking priority.