MP3 artwork extraction issue

[MikeDudley 0]

I'm a musician (and developer) and I made my own MP3 album, properly tagged with mp3tag.

• Each track have a different artwork.
• Each track have a track number like "01" "02" ... "20"

When I put my album in Emby, all tracks have the artwork of the first one!

A close look to the log show:

• ffprobe.exe is properly called on all tracks
• ffmpeg.exe is called only one time on the first one to extract the artwork

The crazy thing is:

• I remove the album with emby (so the folder is deleted)
• I create it again, but this time, I put only the last track
• ffprobe.exe is called
• ffmpeg.exe is NOT called! The track use the old artwork from the previous shot

Two bugs here:

• When Emby delete an album it does not delete all the data. Something remain in the database or somewhere else (the artwork)
• The way ffmpeg is called to extract the artwork is bogus. I suspect you fail to compute the track number so all tracks have the same number "1" or NaN , this is why you call it only one time.

Edited April 4, 2021 by MikeDudley
typo

[Abobader 3470]

Hello MikeDudley,

** This is an auto reply **

Please wait for someone from staff support or our members to reply to you.

It's recommended to provide more info, as it explain in this thread:

Thank you.

Emby Team

[Guest]

Did you try a refresh metadata with replace images? After you did the other.. It may also have been the sequence/timing.. Or removing the Library and Rebuilding/Scanning it again.. performing the different operations.

Yeah.. I have multiple albums that are done this way.. [adult swim], Gorillaz,.. are some that comes to mind and quite a few box sets that artwork changes on from track to track, disc to disc. I have never seen it respect those artworks.

I think that it would mean forcing the database and or the metadata folder to house an entry for every track. A library like mine with over 100,000 artist, 30,000+ albums, and 150,000+ files would mean the metadata for the server would exceed and increase in size ( last time I did a complete reinstall I deleted over 700,000 images equaling somewhere in the neighborhood of about 15 GB ( and the library was smaller then ). It means housing an image and separate entry for each and every file.

My database was larger than it is now.. the larger it is the bigger the memory needs to be to allocate to the cache. ( If I am not mistaken by some of the posts here about the new beta Performance Improvements )

So in order to explain maybe why some of this is done that way... I do agree it would be nice though, metadata direct through a data stream would actually be the only way for the file information and I am not for sure if Emby will be doing that. It serves it all up like a server for a website would.

[Luke 42086]

Hi, this should be improved for the next release, but generally for music libraries we don't extract separate images for every single track in album. Are you saying you have tracks with different images all in the same album?

[PaperPlayn 7]

I too have some cases where I would like separate cover art (or perhaps separate background art) per song within a single album.  However, I understand the "database size concerns" listed above; so it does not seem like default behavior should be to generate per-song images and store them.

Therefore, since it is very easy to apply per-song artwork in (for instance) MusicBrainz Picard, and very labor-intensive to do so in Emby, I would suggest looking into an option to "link song [dropdown to select Primary Image or other] to embedded MP3 artwork" or something similar.  Which would be a one-or-two-click solution and would simply reference the existing MP3 artwork without creating new image files within the database.  Coupled with some basic bulk-image editing functionality (maybe inside the metadata manager)--which I think I read elsewhere is already planned?--this could be pretty powerful and quick.