# Adding "Composer" changes file duration

**URL:** https://community.mp3tag.de/t/adding-composer-changes-file-duration/62320
**Category:** Support
**Created:** [October 7, 2023, 2:40pm UTC](https://community.mp3tag.de/t/adding-composer-changes-file-duration/62320 "2023-10-07T14:40:30Z")
**Posts on this page:** 20
**Page:** 1

<div class="post-metadata">

### Author: ![twsf](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/t/ecc23a/32.png) [@twsf](https://community.mp3tag.de/u/twsf)
#### Post date: [October 7, 2023, 2:40pm UTC](https://community.mp3tag.de/t/adding-composer-changes-file-duration/62320/1 "2023-10-07T14:40:30Z")

</div>

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?

 ![mp3tag01](https://community.mp3tag.de/uploads/default/original/2X/a/ab139aa7ca3dce1f4a74bc7c81b31e23682e56ed.png)

 ![mp3tag02](https://community.mp3tag.de/uploads/default/original/2X/5/592c96be6379212406ef34b575378465410831c1.png)

---

<div class="post-metadata">

### Author: ![twsf](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/t/ecc23a/32.png) [@twsf](https://community.mp3tag.de/u/twsf)
#### Post date: [October 7, 2023, 2:41pm UTC](https://community.mp3tag.de/t/adding-composer-changes-file-duration/62320/2 "2023-10-07T14:41:33Z")

</div>

Screenshots once files are modified to add Composer:

 ![mp3tag03](https://community.mp3tag.de/uploads/default/original/2X/6/6d0b8b9ad6c2eec42eacb40d3046a2bf999f1fbf.png)

 ![mp3tag04](https://community.mp3tag.de/uploads/default/original/2X/9/93ae253884144ae6dc8c0236877227b94c4ff5fa.png)

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)

---

<div class="post-metadata">

### Author: ![ohrenkino](https://community.mp3tag.de/user_avatar/community.mp3tag.de/ohrenkino/32/4843_2.png) [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [October 7, 2023, 3:12pm UTC](https://community.mp3tag.de/t/adding-composer-changes-file-duration/62320/3 "2023-10-07T15:12:35Z")

</div>

> [@twsf](#):
>
> These files were very badly modified by MP3Tag and no longer play properly

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:

> [@How to check files for errors?](https://community.mp3tag.de/t/how-to-check-files-for-errors/44633):
>
> It’s required and often helps to reduce support cycles to check files for errors before filing a bug report. Symptoms of erroneous files are often missing or wrong bitrate or length audible blips or skips tags seem to be sticky and cannot be removed There are some really good tools to check the files for errors, namely MP3 Diags — identifies many different issues in MP3 files Website: [http://mp3diags.sourceforge.net](http://mp3diags.sourceforge.net) Download: [MP3 Diags - Getting MP3 Diags](http://mp3diags.sourceforge.net/010_getting_the_program.html#binWindows) If the font size in MP3 Diags is …

---

<div class="post-metadata">

### Author: ![MotleyG](https://community.mp3tag.de/user_avatar/community.mp3tag.de/motleyg/32/440_2.png) [@MotleyG](https://community.mp3tag.de/u/MotleyG)
#### Post date: [October 7, 2023, 5:24pm UTC](https://community.mp3tag.de/t/adding-composer-changes-file-duration/62320/4 "2023-10-07T17:24:01Z")

</div>

> [@twsf](#):
>
> 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 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.

> [@Adding a cover may change the length](https://community.mp3tag.de/t/adding-a-cover-may-change-the-length/49722):
>
> Once I add a cover into a mp3 file, Mp3tag may extend its length probably, the bigger cover file is, the longer mp3 file I will get. I'm using Mp3tag v3.02

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.

---

<div class="post-metadata">

### Author: ![twsf](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/t/ecc23a/32.png) [@twsf](https://community.mp3tag.de/u/twsf)
#### Post date: [October 7, 2023, 8:29pm UTC](https://community.mp3tag.de/t/adding-composer-changes-file-duration/62320/5 "2023-10-07T20:29:42Z")

</div>

According to MP3Diag (see below), the source files are error-free - this seems to be an MP3Tag problem:

 ![mp3tag05](https://community.mp3tag.de/uploads/default/original/2X/9/954b5410c2f71a70bc19567570dddb1dfa2b556f.png)

---

<div class="post-metadata">

### Author: ![twsf](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/t/ecc23a/32.png) [@twsf](https://community.mp3tag.de/u/twsf)
#### Post date: [October 7, 2023, 8:35pm UTC](https://community.mp3tag.de/t/adding-composer-changes-file-duration/62320/6 "2023-10-07T20:35:23Z")

</div>

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.

 ![mp3tag06](https://community.mp3tag.de/uploads/default/original/2X/1/11d2834b8d723ed25640e8acc60353ecbafe1945.png)

 ![mp3tag07](https://community.mp3tag.de/uploads/default/original/2X/e/e62415ddf6cf6b64507803f8dd84e5ff2c3b77a1.png)

---

<div class="post-metadata">

### Author: ![ohrenkino](https://community.mp3tag.de/user_avatar/community.mp3tag.de/ohrenkino/32/4843_2.png) [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [October 7, 2023, 8:44pm UTC](https://community.mp3tag.de/t/adding-composer-changes-file-duration/62320/7 "2023-10-07T20:44:30Z")

</div>

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:

 ![grafik](https://community.mp3tag.de/uploads/default/original/2X/e/ed2d483f014a2c0a4d3050939412d2d54a15d3e6.png)

The one with more findings is the one with APE.

---

<div class="post-metadata">

### Author: ![twsf](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/t/ecc23a/32.png) [@twsf](https://community.mp3tag.de/u/twsf)
#### Post date: [October 7, 2023, 8:54pm UTC](https://community.mp3tag.de/t/adding-composer-changes-file-duration/62320/8 "2023-10-07T20:54:43Z")

</div>

Here are my Tag settings in MP3Tag:

 ![mp3tag08](https://community.mp3tag.de/uploads/default/original/2X/3/37c23f5c593343a1dd5e05907bd3ad15b1759016.png)

Please let me know if there is a setting to change so MP3Tag doesn't ruin my files. Thanks.

---

<div class="post-metadata">

### Author: ![ohrenkino](https://community.mp3tag.de/user_avatar/community.mp3tag.de/ohrenkino/32/4843_2.png) [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [October 7, 2023, 8:55pm UTC](https://community.mp3tag.de/t/adding-composer-changes-file-duration/62320/9 "2023-10-07T20:55:59Z")

</div>

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.

---

<div class="post-metadata">

### Author: ![twsf](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/t/ecc23a/32.png) [@twsf](https://community.mp3tag.de/u/twsf)
#### Post date: [October 7, 2023, 9:05pm UTC](https://community.mp3tag.de/t/adding-composer-changes-file-duration/62320/10 "2023-10-07T21:05:53Z")

</div>

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?

 ![mp3tag10](https://community.mp3tag.de/uploads/default/original/2X/1/1e9f6cb25cc39148026e0d6b197fb6c5c0d1d04a.png)

 ![mp3tag09](https://community.mp3tag.de/uploads/default/original/2X/9/91b03d00fea437c74225aecaf341bcc2a5d4dad9.png)

---

<div class="post-metadata">

### Author: ![ohrenkino](https://community.mp3tag.de/user_avatar/community.mp3tag.de/ohrenkino/32/4843_2.png) [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [October 7, 2023, 9:09pm UTC](https://community.mp3tag.de/t/adding-composer-changes-file-duration/62320/11 "2023-10-07T21:09:07Z")

</div>

An MP3diags check of

> [@twsf](#):
>
> fresh copies of all the source files

would probably reveal more.  
Could you supply one of these fresh files?

---

<div class="post-metadata">

### Author: ![LyricsLover](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/l/c6cbf5/32.png) [@LyricsLover](https://community.mp3tag.de/u/LyricsLover)
#### Post date: [October 7, 2023, 9:11pm UTC](https://community.mp3tag.de/t/adding-composer-changes-file-duration/62320/12 "2023-10-07T21:11:04Z")

</div>

> [@ohrenkino](#):
>
> 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.

---

<div class="post-metadata">

### Author: ![twsf](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/t/ecc23a/32.png) [@twsf](https://community.mp3tag.de/u/twsf)
#### Post date: [October 7, 2023, 9:16pm UTC](https://community.mp3tag.de/t/adding-composer-changes-file-duration/62320/13 "2023-10-07T21:16:12Z")

</div>

I did post MP3Diags scan of untouched above. Here are three of the fresh files you can examine yourselves:

> **[MP3Tag](https://www.dropbox.com/scl/fo/tki4oouhaqgno9kt2bpy6/h?rlkey=kbi8aezhqtckvnu9fi9cnm2nr&dl=0)**
>
> Shared with Dropbox

---

<div class="post-metadata">

### Author: ![ohrenkino](https://community.mp3tag.de/user_avatar/community.mp3tag.de/ohrenkino/32/4843_2.png) [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [October 7, 2023, 9:32pm UTC](https://community.mp3tag.de/t/adding-composer-changes-file-duration/62320/14 "2023-10-07T21:32:43Z")

</div>

Thank you.

The 3 files at that address show the following in MP3diags:

 ![grafik](https://community.mp3tag.de/uploads/default/original/2X/7/7836762193c8d04cc0ad809976823b700363d0c4.png)

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.

---

<div class="post-metadata">

### Author: ![ohrenkino](https://community.mp3tag.de/user_avatar/community.mp3tag.de/ohrenkino/32/4843_2.png) [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [October 7, 2023, 9:35pm UTC](https://community.mp3tag.de/t/adding-composer-changes-file-duration/62320/15 "2023-10-07T21:35:54Z")

</div>

A workaround would be to cut the tags and re-write them with MP3tag.  
This removes also the unknown streams

---

<div class="post-metadata">

### Author: ![twsf](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/t/ecc23a/32.png) [@twsf](https://community.mp3tag.de/u/twsf)
#### Post date: [October 7, 2023, 9:39pm UTC](https://community.mp3tag.de/t/adding-composer-changes-file-duration/62320/16 "2023-10-07T21:39:55Z")

</div>

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.

---

<div class="post-metadata">

### Author: ![twsf](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/t/ecc23a/32.png) [@twsf](https://community.mp3tag.de/u/twsf)
#### Post date: [October 7, 2023, 9:49pm UTC](https://community.mp3tag.de/t/adding-composer-changes-file-duration/62320/17 "2023-10-07T21:49:33Z")

</div>

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

> **[Classical Center Stage Store](https://classical.centerstagestore.com)**
>
> Shop exclusive music, merch, and apparel from the Classical Center Stage Store. Hoodies, CDs, Vinyl and more.

 ![mp3tag11](https://community.mp3tag.de/uploads/default/original/2X/e/e7f92fbbf411af624ad23c32ee8f8263d16b4736.png)

---

<div class="post-metadata">

### Author: ![ohrenkino](https://community.mp3tag.de/user_avatar/community.mp3tag.de/ohrenkino/32/4843_2.png) [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [October 7, 2023, 9:51pm UTC](https://community.mp3tag.de/t/adding-composer-changes-file-duration/62320/18 "2023-10-07T21:51:05Z")

</div>

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.

---

<div class="post-metadata">

### Author: ![twsf](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/t/ecc23a/32.png) [@twsf](https://community.mp3tag.de/u/twsf)
#### Post date: [October 7, 2023, 10:12pm UTC](https://community.mp3tag.de/t/adding-composer-changes-file-duration/62320/19 "2023-10-07T22:12:18Z")

</div>

So what settings are you recommending here (or elsewhere)?

 ![mp3tag12](https://community.mp3tag.de/uploads/default/original/2X/0/0cddd43070c6ce463f6f46b9159999ec70962210.png)

 ![mp3tag13](https://community.mp3tag.de/uploads/default/original/2X/6/6117c440f0b5a7a06c5027408471d430d85b279c.png)

---

<div class="post-metadata">

### Author: ![twsf](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/t/ecc23a/32.png) [@twsf](https://community.mp3tag.de/u/twsf)
#### Post date: [October 7, 2023, 10:46pm UTC](https://community.mp3tag.de/t/adding-composer-changes-file-duration/62320/20 "2023-10-07T22:46:41Z")

</div>

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:

 ![mp3tag14](https://community.mp3tag.de/uploads/default/original/2X/2/29315926c86e738512da54ef9545a3d5708745d2.png)

Amazing how much trouble a large embedded cover image seems to have been causing.

[Next page](https://community.mp3tag.de/t/adding-composer-changes-file-duration/62320.md?page=2)
