Applying Artwork in iTunes Corrupts Some MP3 Files

Over the past few months—I want to say since Mojave's release last year—I have gotten a few reports from users of my artwork scripts regarding a bizarre corruption issue when applying artwork to some types of MP3s.

Essentially, when artwork is applied to the MP3, its file "echoes" the last few seconds of audio data which increases the size of the file. Here is a screenshot sent to me by Correspondent Brandon Pfeiffer, showing the phenomenon in an audio editor (I think it's Fission; no matter, really):

Each "echo" represents a single attempt to add artwork. The new size is reflected in the Size and Time for the file in iTunes as well.

I have not been able to replicate this myself so it has been very difficult to figure out what's going on. However, Brandon did some experimenting and discovered some details. First, it's probably not an issue with the AppleScripts, since Brandon was also able to see this issue when he "manually" applied artwork via a track's Info panel.

Some other observations:

• The source of the MP3s did not seem to make a difference (home rips, Amazon downloads, etcetera)
• The image file being applied may be a factor, its size, type, and so on. However, Brandon could not find a consistent factor in this regard.
• Changing the ID3 version in iTunes had no effect.
• Re-converting a corrupted MP3 to MP3 in iTunes restored the file to its un-corrupted length. (Subsequently adding artwork to such a file, however, eventually corrupted it again.)
• The new file encoded by iTunes did not appear to have the issue at first (the song duration did not change); however, closer inspection using an audio editor (or even just playing via QuickLook in Finder) revealed that the duration had in fact changed, but was yet to be reflected in iTunes.
• Re-encoding the corrupted file using FFmpeg produced several of the following errors: “Header missing - Error while decoding stream #0:0: Invalid data found when processing input”
• Re-encoding the original downloaded source MP3 using FFmpeg did not produce any errors.

Sure beats me. I'll have more follow-up as it develops.

[Update: Several Correspondents have emailed to confirm that they have seen this behavior after manually editing artwork; AppleScript was not a factor.]