MP3Tag adds noise & 30+ seconds' silence to end of MP3s

I've recently noticed that after editing tags with MP3Tag, there will be a long period of silence added to the end of the MP3 files, often with a loud noise near the beginning of it as well. VLC Media Player seems to skip the long silence after a couple of seconds, so I only recently noticed it was happening. Opening the MP3 file in an editor and deleting the noise/silence doesn't effect the tags at all, so apparently the two aren't connected.

So far, the problem seems to be limited to MP3 files. It's never happened when using WAV files and I don't think it happens with FLAC, either. Has anyone else noticed this?


If you find another of these files:
could you check them with the linked tools and see whether they are OK before you use MP3tag?
It could be that you have invalid V1 or APE tags at the end of a file.

That's possible, certainly. I mostly work with LibriVox audiobook files made by people who obviously don't know what they're doing. You get what you pay for. :slight_smile:

Would converting an MP3 to WAV and back to MP3 eliminate the errors? I often do this before doing editing/cleanup on a noisy file so as not to lose quality from multiple MP3 recompressions.

Thanks for the links. I'll check out the tools.


Converting lossy formats to lossy formats usually looses quality.
And: if players/converters already interpret original but malformed tag data as audio data then this data will also be converted and would have to be removed with an audio editor.
But which way to go and which leads to success in the end depends an awful lot on the suspected damage.
I would run the tools first and see what they say.

I used the validator on a hundred or so MP3 files, none of which had any detected problems, so I don't think the problem is with corrupted MP3s. With some trial and error, I discovered that the additional 40 seconds or so of silence appended to the end of the MP3 happens only when I add a cover picture to the file. Removing the cover removes the excess time. Removing the excess time with an audio editor doesn't affect the cover picture, so I don't know what that extra time is doing there. Perhaps this will help in diagnosing the problem?

If the editor, MP3tag and the tools think that the files are OK then this means that your player cannot cope with this tag format. Perhaps it needs ID3V1 tags ... those don't have covers anyway.

As an addition (which was already mentioned before, but not investigated yet): the files also might have APEv2 tags which might be not supported by the decoding program.

Checking the files for that would probably shed some light into this — it's usually visible via the "Tag" column in Mp3tag's file list.

The problem has nothing to do with my player (VLC Media Player). It plays the files just fine. It also displays the covers. The problem is that when MP3tag is used to add a cover to an MP3 file, it adds about 40 seconds of silence to the end of the MP3 file.

I always take the precaution of deleting ALL tags, including extended tags, by using the X button on MP3Tag. Does it remove APEv2 tags as well? Many of the MP3 file I work with have no tags at all when I get them. Where would APE tags come from?

I bet that there are thousands of users out there who use VLC as player to play mp3 files.
If this were a common problem then the forum would overflow with descriptions of similar problems.
In respect to APE tags: see Tools>Options>Tags>Mpeg and see the settings which tags you read, write and delete.
Also, check, as @Florian suggested the "tags" column and see if there is something like APE in that column.
And finally, if all that does not help: please supply a sample file so that others can see what may be the cause.

Okay, I figured out what was happening now that you've put me on the right track.

I'm sure millions use VLC, but they wouldn't notice the silence because VLC skips over the silence and goes to the next file. I wouldn't have noticed the silence either if I hadn't been using an audio editor to separate eight-hour-long audiobooks into individual chapters.

I turned on the "tags" column and checked the tags/MPEG options for what tags would read, written and removed. After some experimentation, I discovered that the end silence appears when APE tags are written, but only if a cover is added. If there is no cover added, APE will not add the end silence. If I remove the silence with an audio file editor, the cover remains because it's stored in the ID3 tags, but the APE designation disappears from the "tags" column.

So, apparently APE stores covers at the end of the MP3 file where it looks like several seconds of silence on an audio file editor. VLC (and other players) probably knows what that silence is there for and that's why it skips over it. I've set my options to read and remove APE along with ID3, but to write only ID3 (both versions). Now I should have no further problems with end silences.

Thanks for the help and for a great tag utility!

Please note that V1 tags are also stored at the end of a file. So it is a problem of the player that it cannot cope with APE tags.
Your idea to avoid APE tags is a good one though, as they cause irritation in other contexts as well.