This is VERY puzzling and VERY problematic. Load a brand-new Deutsche Gramaphone album - purchased and downloaded their pristine MP3 files. For some reason the album files don't include the Composer tag. Open album in MP3Tag, add "J.S. Bach" (no quotes) as Composer. Save. MP3Tag still indicates original play length for each track, BUT in Windows File Explorer AND in every music playback app, the play durations have CHANGED and the files don't play properly - something got screwed up badly in the timings. Please see images below: original MP3Tag, original Windows Explorer (because of upload limit for new users, in a reply I will add modified MP3Tag, modified Windows Explorer). This is a major problem. An MP3Tag bug?
Screenshots once files are modified to add Composer:
These files were very badly modified by MP3Tag and no longer play properly - what is the solution? (If it's helpful at identifiying what is going on, the naming of these files includes Icelandic diacriticals in the performer's name)
I think that MP3tag is only the messenger that the files were corrupted prior to tagging.
Here are some links for tools to check the files:
I have not seen this kind of mp3tag behaviour myself on any media file format. However there have been similar reports in the last that were confirmed and corrected when files were found to have some kind of error. See this previous thread when making a change to the cover art also changed the reported song length.
The tag information is only contained within the file header, this does not affect the actual audio details of the file itself. The length should never be affected by a metadata update.
According to MP3Diag (see below), the source files are error-free - this seems to be an MP3Tag problem:
And here's the resulting mess after opening the files in Mp3Tag, and modifying just the Composer field in the first file (see first screen capture below), and modifying NOTHING in any of the other files (see second screen capture below). ALL of them seem to have been broken badly by MP3Tag. Please help.
Could you supply one of these files so that other people could have a look?
What can also be seen is that you apparently write APE tags - MP3diags cannot really cope with APE tags.
So could you also supply a screenshot of Options>Tags>Mpeg
Here an MP3diags run of a file and its copy with and without APE tags:
The one with more findings is the one with APE.
Here are my Tag settings in MP3Tag:
Please let me know if there is a setting to change so MP3Tag doesn't ruin my files. Thanks.
Please switch off writing APE tags and save the tags again and then see if that helps.
If it does not then the request for a sample file is still valid.
OK, things are getting weirder. After reunzipping fresh copies of all the source files, and importing them into MP3Tag, the UNCHANGED files seem to have had lots of errors introduced by MP3Tag (example: track 3, first screen image below), while after I use MP3Tag to modify a file it looks and plays fine (example: track 2, second screen image below.) Is MP3Tag choking on the non-English characters in the source files' ID3 tags? What else could be causing this weird behavior?
An MP3diags check of
would probably reveal more.
Could you supply one of these fresh files?
Fresh and untouched as
a) not loaded in Mp3tag
b) not loaded in Mp3diags
just as original as you got it from your source @twsf , please.
I did post MP3Diags scan of untouched above. Here are three of the fresh files you can examine yourselves:
Thank you.
The 3 files at that address show the following in MP3diags:
Looks to me like the are not really intact.
What is peculiar:
they have ID3V2.2 tags.
They have embedded covers in the png format.
They have ISO-8859-1 character encoding.
So the assumption that MP3tag ruins the files is way off IMHO - as they have been damaged from the start.
If a player then cannot interpret the tag data properly (and the embedded picture is big enough to make up more than 20 seconds more in length) and the original tag data is interpreted as audio data, then your observations are correct in respect to the integrity of the files but wrong in respect to the root cause.
A workaround would be to cut the tags and re-write them with MP3tag.
This removes also the unknown streams
I'm afraid I don't understand. MP3Tag shouldn't instantly make a bunch of changes when importing these files, which scan accurately and play absolutely fine in FOUR different audio apps when untouched (VLC, WinAmp, Emby, Windows Media Player.) Yes, the embedded cover images are large (1MB each). Yes, the character encoding is not U.S.-centric, because the performer is Icelandic and has special characters/diacriticals in his name! Why does it matter if V2.2 tagss are used. I genuinely don't understand why merely importing these files into MP3 would cause such mayhem. Let alone how I am supposed to use the software to make the range of tag edits I would like and have the resulting files scan, time, and play correctly.
And to be clear, these files aren't pirated nor from a dodgy source - they are from one of the most reputable music sources on the planet, which distributes for Decca, Deutsche Gramophone, and even ECM. .
You see in my screenshot your unaltered files which produce nothing but errors in MP3diags.
For me this is proof that these files were damaged from the start.
If you cut the ID3V2.2 tags - which seem to cause the problems - and replace them with proper ID3V2.3 tags, then the files are OK again.
The ISO-8859-1 character encoding is actually dependent on the system code page. I would prefer one that does not rely on these system settings, e.g. UTF-16 or UTF-8.
That a player plays a file does not mean that it is OK. The player simply skips the tag part. But apparently that does not work properly if that damaged ID3V2.2 tag is interpreted as audio data once the ID3V2.3 tag is written on top of the previous tag.
Oho! It seems one simple change made all the difference: removing the 1MB embedded 1000x1000 cover image and replacing with resized 600x600 400kb png. Even after adding and modifying lots of tags, now everything scans and plays properly:
Amazing how much trouble a large embedded cover image seems to have been causing.