When saving on click away is enabled, and the album cover is too large for the track, Mp3tag provides only two options, try again (which won't work) and give up completely, which also doesn't save any other tags to the track, and then switches focus to the track that was clicked causing all changes to be lost.
I propose that the album cover size should be checked and notified about when applying the cover and not when trying to save, to prevent loss of changes and also to make it more clear that it's a problem. Also, it would be a good opportunity to quickly allow the user to use the built-in re-encoding feature to compress the art as a JPEG and still potentially allow it to be applied despite its initial size.
I noticed this behaviour when tagging .flac files, and the size limitation in question is 16MB which I didn't even realize was a thing (some of my mp3s have art larger than that.) Maybe it only applies to .flacs, but still, it's undesirable behaviour in my opinion.
You could modify your workflow so that you save all the other modifcations before you embed a picture.
In that way you would not loose all other changes.
AFAIK the picture has to be embedded first before it can be manipulated. But that would fail for a picture that is too large.
If the artwork is stored in a separate file it will not be restricted. The 16MB is a technical limit in FLAC specifically due to how it is written to the tag structure.
Having embedded images with a size greater than 16MB for most formats is almost as much data as the audio payload itself, other than higher spec hi-res files with sample depths at or above 24 bit or sample rates in excess of 48kHz. So while it may be possible in some cases, it is questionable in practice.
I'm not 100% sure what either of the current replies have to do with my report. I can change my workflow, and it may be questionable to have large art on my tracks, but none of this changes the fact that throwing out the user's changes, in any case, is definitely not desirable behaviour and would be considered a bug, right?
Agreed, this is not a desirable effect. Not sure it is specifically a bug though. It is more about the image sizes being outside of the current design expectation.
Both comments relate to your reported issue. @ohrenkino suggested a potential workaround to consider at least until the issue is acknowledged and perhaps potentially addressed in a future update. My comment was just about the practicality of embedding such large artwork when in most cases it goes against the principle of using compressed music to pack songs into a reasonably small package (lossless or lossy). It has been documented as well that some players break when embedded artwork exceeds the spec.
Neither suggest that that the issue should not be addressed. Manage your library any way you want but within the limits of the software. But for others that come across this thread for anything similar it is important to recognize the pitfalls.
With Mp3tag v3.30b, Mp3tag preserves the Tag Panel input and the File List selection on errors when writing tags.
This was a fairly invasive change, as it requires intercepting (and also preventing) file selection changes. I’ve modified a significant amount of code, so I’d really appreciate it if others could give it a try.
According to my tests I think the code changes mostly work as intended.
I tested it with:
manually adding via the tag panel or the extended tag view using "Add Cover"
manually using drag & drop in the tag-panel and the extended tag view.
via a web source
Not that the previous or current behavior has been or is a real problem for me, but I would still like to point out something.
Systematically, I think it would be best if such an error could be caught already during the UI-controlled manual addition, rather than during the file saving process. However, with an "Import Cover" action, this would only be possible during the file saving process.
At the moment, when adding a cover that is too large, it is displayed in the tag panel without an error message, and only when saving does the check trigger an error message. Since such automatic saving can also occur during many other menu calls (calling the converter, calling the action menu, calling web sources, calling the extended tag view etc.), you can suddenly be confronted with this save error message if you weren't even aware of the cover that was too large and hadn't been saved yet.
In any case, I think the error message should be revised, which at the moment does not give the impression that only the cover was not written, but rather all the other tag-changes.
Independent of the files-size-error, just only calling a websource already saves changes in the tags which were not saved before.
But:
If you go further on in the websource script and select an album to display and quit, the saved changes will be undone. If you have a cover which is too large and you quit the error message, the tag changes are not saved.