Author Topic: No warning when attempting to embed a a picture that outspecs ID3  (Read 4595 times)

campfred

  • Jr. Member
  • **
  • Posts: 30
Hi! I think I hit a case in MusicBee that was probably not tested for. 😬

Basically, I've been banging my head as to why my embedded cover arts weren't embedding in flac files and instead ending up corrupted in MusicBee.

After searching online, it looks like ID3 has a limit for the album cover tags, which is fine.
But it would be appreciated if MusicBee could warn when a picture goes outside of the limits. Better yet would be it preventing from embedding them and instead offer the other copy options (and of course telling why it's not allowing to embed them in the file).

Here's what I was dealing with on MusicBee to come accross that case :

In the screen recording, it just says that it has successfully updated the files, which isn't false indeed. But that was the only feedback I was getting outside the « A picture is corrupted[..] » error happening after the fact. So, it wasn't obvious to know what was happening.

It's maybe a bit of an edge case but with newer releases on digital stores coming with very high quality cover art files more often than before, it's probably gonna happen to others at some point. 😅

Thank you for reading me!

sveakul

  • Hero Member
  • *****
  • Posts: 1767
This should be posted in the Wishlist forum (i.e., "Warn if attempting to embed oversized artwork") as it's not a bug per se.  Just out of curiousity, how big ARE these files?  Also, you should be using Vorbis Comment tags in FLAC files, not ID3.

campfred

  • Jr. Member
  • **
  • Posts: 30
Sorry for being in the wrong forum. I thought it was not the intended behaviour to have MusicBee corrupting files. 😅

May I ask how to switch between tag formats? MusicBee can't even tell me which version I'm using and the field isn't a dropdown menu...


About the cover arts, they are regularly comming in 3k*3k format for the content I'm getting. For example, if you go on the Monstercat label's website, click on any release inside their music page (let's take their latest for example : MCS1236) and click on the cover art (you might need to do it twice), you'll get a 3k*3k picture. This is, also, the actual file they give you upon downloading the release from the site.

But that one is the least offender since they're distributed in JPEG. A lot of the releases I buy comes with the cover art in PNG format or embedded in the files (I don't know how they managed to do that) and at the same resolution or higher in the ZIP archive. Obviously, I'd love to keep these files like they are because it looks really good when show in the Now Playing view and in the artwork slideshow when playing albums in the living room.

I put both examples in a Google Drive folder if you'd like to take a look at them.
Monstercat's JPEG in example comes up at ~6 MB while STH's PNG in example comes up to ~23 MB, which for the ID3 standard is indeed too large.

sveakul

  • Hero Member
  • *****
  • Posts: 1767
MusicBee was doing what you asked it to, namely attempt to embed the chosen picture into the file.  I agree with you that it would be a nice to add a feature that warns if you choose a non-compliant image, and encourage you to add a Wishlist forum post for it.  As you described the recent availability of hi-res album art has kept this mostly in the background until now.  Thanks for uploading the examples.

The type of tag is shown by Tag Inspector--in the Edit window, hit the Tag Inspector tab:



MusicBee will use the default Vorbis tag for FLAC when it exists for editing.  As far as from-scratch tagging when no metadata exists, I do all of that and most edits in an external tagger (Kid3 or Mp3tag) so I'm not sure of the behavior there, but hopefully others can comment.

campfred

  • Jr. Member
  • **
  • Posts: 30
Good point!
And sure, I'll make a wishlist post for that as suggested.

About the type of tag, it turns out that the Home Alone compilation album I referred (the huge PNG example) is using Vorbis Comments.


So, I checked for the data lenght limit in that format and it looks like Vorbis Comments can store up to 16 EB if I understood well according to this Wiki from the Xiph.Org Foundation. Which is indeed, a lot of data.
Then, I tried again with MP3tag to no success. MP3tag said it couldn't access the file which was false, but that was until the cover art was reduced to under ~6 MB.
Although, trying with TagScanner (a program I used to use in the past) showed me that it is probably subject to the same limit even in Vorbis.
That one did write the cover art but only part of it. Like, it looks like it did write it up to  6 MB.


Of course I'm a bit confused and I'm convinced I misunderstood something with this.
But in the meantime, I'm just going to link the cover art tag to the actual file which MusicBee allows to do.

sveakul

  • Hero Member
  • *****
  • Posts: 1767
I read at the Mp3tag forum this comment from the developer on cover size limits:  "FLAC has a limitation of ~16MB because the length field of the metadata block can only hold numbers up to 24bit."

Did some testing with your 22.7mb sample PNG and the Kid3 tagger.  At original size, and at reduced size of 16.6mb, Kid3 was not able to embed the art successfully--although it "seemed" to, like MB (no error message).  At 14.2mb, Kid3 embedded the artwork successfully and it displays fully in players.  So I think Florian's statement above is indeed correct on an approx. 16mb limit.

Why Mp3tag couldn't acces the file until it was reduced to 6mb, and why Tagscanner was only able to add 6mb of data, I do not know.  Might be time to give Kid3 a whirl though  ;)  (https://kid3.kde.org/).  Available as a 64-bit Windows portable download farther down the page.

frankz

  • Hero Member
  • *****
  • Posts: 2994
Not for nothing, but why on earth would you want to embed a 14 megabyte image file in an 11.3Mb music file?   Sometimes things are out of spec for a reason (i.e. they don't make sense as a thing to do).
A smile is happiness you'll find right under your nose.

campfred

  • Jr. Member
  • **
  • Posts: 30
I read at the Mp3tag forum this comment from the developer on cover size limits:  "FLAC has a limitation of ~16MB because the length field of the metadata block can only hold numbers up to 24bit."

Did some testing with your 22.7mb sample PNG and the Kid3 tagger.  At original size, and at reduced size of 16.6mb, Kid3 was not able to embed the art successfully--although it "seemed" to, like MB (no error message).  At 14.2mb, Kid3 embedded the artwork successfully and it displays fully in players.  So I think Florian's statement above is indeed correct on an approx. 16mb limit.

Why Mp3tag couldn't acces the file until it was reduced to 6mb, and why Tagscanner was only able to add 6mb of data, I do not know.  Might be time to give Kid3 a whirl though  ;)  (https://kid3.kde.org/).  Available as a 64-bit Windows portable download farther down the page.

I'll try it today once I get back home from work. But from even your own finding, it seems like even though Vorbis allows more data per comment, it has the same limit as ID3. 🤔

campfred

  • Jr. Member
  • **
  • Posts: 30
Not for nothing, but why on earth would you want to embed a 14 megabyte image file in an 11.3Mb music file?   Sometimes things are out of spec for a reason (i.e. they don't make sense as a thing to do).

I'll point you to my previous answer you probably forgot to read :
Obviously, I'd love to keep these files like they are because it looks really good when show in the Now Playing view and in the artwork slideshow when playing albums in the living room.

But since you look familiar and confident with tag specs, can you please help us on the matter in a more productive way than criticizing actions in an unconstructive way?

frankz

  • Hero Member
  • *****
  • Posts: 2994
But since you look familiar and confident with tag specs, can you please help us on the matter in a more productive way than criticizing actions in an unconstructive way?
Yes I can and will.  

Rather than doing something that is deliberately prevented by the file spec - embedding a 14Mb image file into each music file - you can link one copy of the image for the entire album as a stand-alone file and still enjoy the way they "look really good" in Now Playing.

https://musicbee.fandom.com/wiki/Album_Art_and_Artist_Pictures
A smile is happiness you'll find right under your nose.

The Incredible Boom Boom

  • Hero Member
  • *****
  • Posts: 600
Obviously, I'd love to keep these files like they are because it looks really good when show in the Now Playing view and in the artwork slideshow when playing albums in the living room.

Embedding album artwork was necessary during the time period when portable MP3 players could only read images from the track metadata, but it's now the case most modern players can display image files from directories. Depending on the size of your music collection and whether you wish all your tracks to display album art, embedding artwork over half a megabyte or so is quite needless. I have tens of thousands of albums with high quality PNG artwork ranging from 20MB to over a hundred megabytes in artwork folders and they display beautifully.

hiccup

  • Hero Member
  • *****
  • Posts: 5268
Suggesting/wishing for some warning when this happens doesn't seem like an offence to me?

But to practical and realistic, to embed a >16 MB png in a music file makes no sense at all.
If you encode your 23 MB png file to hi-quality jpg  (level 10) it is only 7mb.
And you will not see a difference. Not even a little.

frankz

  • Hero Member
  • *****
  • Posts: 2994
It's the condescending "maybe I'm in the wrong forum" and "since you're such an expert..." and "that you probably forgot to read" responses that are offensive.
A smile is happiness you'll find right under your nose.

hiccup

  • Hero Member
  • *****
  • Posts: 5268
It's the condescending "maybe I'm in the wrong forum"
I am guessing he meant "the wrong board" there.
'Bugs' instead of 'Wish'.

Playing advocate of the devil: depending on your perspective, somebody might consider this a bug.
If it is true that MB will happily try to embed it, thereby corrupting the file, and not warning or preventing it.
Which I have not tested myself, and I won't, since I am personally not interested in adding >16 MB image files to music files.
If this goes on any 'todo' list, for me personally it's a promising candidate for the rock bottom position ;-)
Last Edit: August 04, 2021, 09:48:18 PM by hiccup

campfred

  • Jr. Member
  • **
  • Posts: 30
It's the condescending "maybe I'm in the wrong forum" and "since you're such an expert..." and "that you probably forgot to read" responses that are offensive.
I didn't say « since you're such an expert ». However, you did read like you were very knowledgeable and knew exactly the solution about the subject but just kept it at responding to me like I was stupid for not already knowing the « obvious » and known by all answer. Maybe I don't get nuances correctly and you were actually ultra friendly and only wanted to come off as very helpful and exposing how to resolve the issue. I apologize for that.
Also, please note that maybe what I'm trying to achieve looks absolutely insane to you, but that is because you already know all of this stuff and it became obvious to you. Sadly, it is not obvious to everyone and even if you'd think it's common sense, well common sense isn't always common as we say in French.
Here's how I look at the situation : I like keeping things in their original form as best as possible. Think of it like people who preserve their video games complete with box, artwork and warning leaflets. Not just the game disc or cartridge. A lot find it useless to keep everything throw everything in the bin except the actual disc/cartridge. I'm obviously putting aside digital distribution here because it doesn't apply to that situation.
And since I have the storage for it, well I try to keep it all there and not have cut it down to 96 kbps MP3's with 128*128 artworks. MusicBee enables me to save and manage that in a pretty easy way. I can even go as far as store the catalogue number (which became much more handy than expected for sharing tracks).
Of course, I am putting away the subjective enjoyment of being able to listen to my music without it becoming a blurry and aliased mess when a lot of stuff is going on in the track and also not having a pixelated and barely readable photo to look at in the living room.
A cover art is that : Art. It's also something that can be appreciated alongside the music during listening sessions and I also want to preserve it.
So, that is why on Earth I want to keep a 14+ MB picture along side a 20 MB sound. Should you dislike this, fine. I respect that. But please, be civil too even if what I'm attempting to achieve is literal non sense to you. « Answering » with a question asking me to justify why should I enjoy having HQ cover arts doesn't actually answer the issue.
Maybe you didn't aim to sound like this and I'm giving you the benefit of doubt. Next time, make sure the tone doesn't read like you're telling someone they shouldn't dare to think about something so insane and full of non sense.


I am guessing he meant "the wrong board" there.
'Bugs' instead of 'Wish'.
Yes, that is what I meant. It does show as « forum » in the app though and it's how I always knew this worked where you have multiple forums/rooms and you can make conversations in them. But that might be me mistranslating it from French back to English. It's actually the first time I see someone calling them boards and I apologize for causing confusion. I do understand though how these can be called boards and I'll work on keeping it at this term instead.

Playing advocate of the devil: depending on your perspective, somebody might consider this a bug.
If it is true that MB will happily try to embed it, thereby corrupting the file, and not warning or preventing it.
I did thought it was a bug because I wouldn't have considered a file corruption as a desired result when trying to improve it.
And since I don't have the source code (and even if I had it, depending on the language used, I probably will take too much time to get familiar with it before this get resolved), I can't actually tell if it does indeed try to embbed it.
But the end result is a change in the file checksum which tells that something has been modified and to get rid of the warning message appearing everytime, I need to delete the non existing artwork on the interface and save the file. Which brings it back to the checksum it had before the integration attempt.


Embedding album artwork was necessary during the time period when portable MP3 players could only read images from the track metadata, but it's now the case most modern players can display image files from directories. Depending on the size of your music collection and whether you wish all your tracks to display album art, embedding artwork over half a megabyte or so is quite needless. I have tens of thousands of albums with high quality PNG artwork ranging from 20MB to over a hundred megabytes in artwork folders and they display beautifully.
That, I agree with you and sadly, I guess I'm using pretty much only uncommon music players because none of the apps I'm using except MusicBee and Foobar2000 (only most of the time for FB2K) manages to pull the linked photos. Especially when there's more than one (like the SMH compilation where there's the actual album art and a supplemental one for the deluxe version).
So far, neither my DMP, Plex, Emby, AirSonic and playing through DLNA manages to pull them.
Indeed, Plex should be supporting them and I've been in touch with them to check on what could I be doing wrong but when they get asked how to get Plex to pull linked cover art files, they just send « Don't, there's no reason you want not to embbed them. » as a supposedly resolving answers. Which, of course, doesn't tell much as to what to do to resolve the issue.
So, all that got me to switch to embbedding them in the music files and, this may be a coeincidence, but my MB database finally stopped to corrupt itself every half a year or so which was very relieving to not have to revert it with a backup each time.
Don't get me wrong, I'm totally fine with having more files in my directory for using linked files instead. Even if my cloud backup will cost me (slightly) more because it's causing a bit more upload calls, I am okay with it. It's nowhere a drastic increase like going from MP3 to FLAC ripping.


Why Mp3tag couldn't acces the file until it was reduced to 6mb, and why Tagscanner was only able to add 6mb of data, I do not know.  Might be time to give Kid3 a whirl though  ;)  (https://kid3.kde.org/).  Available as a 64-bit Windows portable download farther down the page.
About Kid3, I finally got able to try it today on my way back home. The situation is more confusing than anything with it, strangely. It does the operation like if everything was fine and even can pull it back when re-reading the file...but is also the only program that can read it back with no issue.
MB warns for a corrupted photo when navigating to the cover art tab but that's the only issue it has with it, TagScanner shows only part of the artwork like the previous example and Foobar reads and plays the file just fine too but with no picture.
I did however check with a colleague who contributes a lot to KDE projects to see if he was aware of Kid3 and familiar with it and he told me that it was supposed to be throwing an error instead when doing that operationg with files that are not properly formatted to handle that. So, they'll look on correcting that. 'Looks like that has helped them find a mistake that's been done at some point.


I must end that message by saying sorry to everyone for causing so much trouble. I was not expecting HQ artwork integration to become a weird edge case with how it is possible to get music with video artworks today (haven't stumbled upon those yet on the storefronts I'm using).