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).
