Audible "blip" or "skip" after editing tags

Sorry to dig up an old thread, but I have had an issue recently that I had assumed was an error in ripping files from CD, or converting them from WAV to MP3 after adjusting the audio levels. However, I have discovered that MP3Tag seems to be damaging the files slightly. I will have an MP3 file that has already been tagged and had an image attached, I edit another file in the compilation, and I decide to re-save all the files in the compilation so the dates and times are in sync (I have a little OCD ;)). Two of the files that had no changes to their tags or their cover image ended up with very slight distortions to the music that last a fraction of a second at different points, and almost sound like a 'blip' or a skip. Now I will have to listen to every song all the way through to see if any others have this issue. It's very odd; I had assumed the editing of the tags should have no audible effect on the files.

If you hear a

then it is most likely the player that interprets tag data as audio data. The reason could be invalid and/or stacked and/or unsupported tags.

I would still check these files with one or all of the common utilities like MP3val, Mp3diags and/or Foobar2000.

I'd say that this is not optional but mandatory before making any claims that

1 Like

I can hear the blips on my iPhone 7 (Apple Music), with Windows Media Player (on two different PCs - one with version 11.0.5271 and the other with version 12.0.7601), with iTunes (, with VLC Media Player (2.1.5), and with a Logitech Squeezebox Radio streaming via Logitech Media Server. I don't see how it can be the tags, since the files in question have the exact same tags (in their 'working' form as well as the 'altered' versions); the only difference, as I stated, is that the files were re-saved by MP3Tag. I will use one of the apps mentioned, though the effect is audible. I will certainly be comparing other files as well; this is concerning as I have been using MP3Tag for about three years, every time I rip a CD and almost every time I download electronic files from Bandcamp or using a download card included with an lp (luckily I retained some of the original files). I figured MP3Tag was only altering the tags. The audible effect is very slight, and I definitely have files that I haven't listened to since changing their tags, so the issue may be more widespread.

Unfortunately, you've ignored our advice to check the files with MP3val, MP3 Diags and foobar2000. I trust that you can hear the blips using the various players you've mentioned — what I'm not confident about is, that saving tags using Mp3tag is creating them.

Can you send me one of the files in their "working" form so I can reproduce myself and create the "altered" version by saving the tags in Mp3tag?

I wasn't ignoring your advice; in fact, I stated that I would "use one of the apps mentioned" (I had meant to finish that sentence with "to inspect the files", which would have made it more clear). What I am saying is that I do not believe that saving the files with the particular tags (and cover image) is what is causing the errors, as the files in question had already been saved with the very same tags and image; Saving them again seemed to cause the issue. I also don't know if I would have to re-save the file 10x to end up with a similar result, since I also re-saved the rest of the files in the compilation I was working on, and so far, only 2 out of the 16 files I have listened to all the way through seem to have this problem (all files were re-saved with the same tags, apart from the song titles). I'm not sure if perhaps there is another program running that may be causing a conflict, or if there has been an update to MP3Tag that might resolve the issue. I had hoped to receive a response explaining how something like this might occur. At any rate, I won't likely have time to examine the files until the weekend. If the 'blip' is caused by an error in the files (which is producing an audible sound), then I assume it will report the error. On the other hand, if the file was re-saved with the 'blip' (as in, the blip is now part of the audio), I don't know how would the software distinguish it from the rest of the music. I will report back my findings.

Sorry for the delay; busy weekend. I am up to 5 out of 21 files in the compilation affected (there are 37 files in the compilation, but I have only listened to the first 21 since the last update). Listening closely it seems the 'blips' present themselves slightly differently depending on what is being used for playback (for instance, audible differences between playback on my iPhone and playback on my notebook via WMPlayer). This would seem to indicate there is an error with the file itself and the audible artifacts are not encoded in the files. Running mp3val on one of the files I receive the following report:

Analyzing file "18 Blowin' Cool.mp3"...
WARNING: "C:\Users\tbundy\Downloads\mp3val\18 Blowin' Cool.mp3" (offset 0x2c3bc)
: MPEG stream error, resynchronized successfully
WARNING: "C:\Users\tbundy\Downloads\mp3val\18 Blowin' Cool.mp3" (offset 0x8e9fd0
): MPEG stream error, resynchronized successfully
WARNING: "C:\Users\tbundy\Downloads\mp3val\18 Blowin' Cool.mp3" (offset 0x8f5fa6
): MPEG stream error, resynchronized successfully
INFO: "C:\Users\tbundy\Downloads\mp3val\18 Blowin' Cool.mp3": 9092 MPEG frames (
MPEG 1 Layer III), +ID3v1+ID3v2, CBR

I would not listen to any of these files but check them all with the named utilities.
The example file shows that the audio stream is broken and looking at the path "Downloads" I get the impression that the files have been downloaded, and probably got damaged during that process or were corrupt already at the source.
If you got more files in that way, I would run them all through the utilities and see if they are ok.

The files were ripped from my own CD; for testing, I placed copies of the files into my Downloads directory. I have the pre-tag files as well, which have no audible issues. The one in question before being tagged produced the following result:

Analyzing file "18 Blowin' Cool2.mp3"...
WARNING: "C:\Users\tbundy\Downloads\mp3val\18 Blowin' Cool2.mp3" (offset 0x1000)
: MPEG stream error, resynchronized successfully
INFO: "C:\Users\tbundy\Downloads\mp3val\18 Blowin' Cool2.mp3": 9102 MPEG frames
(MPEG 1 Layer III), +ID3v1+ID3v2, CBR

I also have a copy of the file that was tagged once with the very same tags that produced the audible errors, but which sounds just fine. I just have to find where I have a copy of that file so I can test it as well.

This looks to me as though the original file is already corrupt, esp. the audio part.
So I would say that

is still valid and that following the GIGO principle (garbage in, garbage out) the files stay as damaged as before, only now with added tag data.

Looking into it further, the second file I checked had already been tagged once, only without the image I added later. It's possible the effect is cumulative. I'll see if I can find a version of the file that was only tagged when it was ripped identifiable by the ID3 version (which is older than the version used by MP3tag). It's also quite strange that I have not noticed this before. Some of the files in the compilation were ripped straight to MP3, while others were ripped to WAV, edited as a WAV, then encoded as MP3. The corruption does not seem to discriminate; At first I thought it might be the WAV editor causing an issue, or the encoding that was taking place after editing, but now I have found files that were ripped and encoded on the fly with no editing required. The only commonality is they are all by the same band. :wink:

Have you checked all the files with the utilities?
What is the result of this check?
What is left of your claim that MP3tag causes file corruption?

I have checked all of the files, and about half of the files are damaged (some that did not have audible effects). No commonalities between the files, other than having been tagged (and all being from the same band). I had thought that perhaps the wave editor was corrupting the files and somehow Mp3tag was making the corruption worse, but some of the damaged files have not been edited. I am trying to either find a corrupt file that has not been tagged with mp3tag (which would indicate the corruption is occurring earlier), or to reproduce the effect by ripping, editing, and tagging files, while checking the files with mp3val at each stage, in a hope to determine what combination is producing the results in evidence.

To sum it up:
If MP3tag would damage files by tagging, it should happen every time. Apparently, it does not.
The originally described effect with gaps in the audio part is only one incarnation of the damage, other, inaudible damages have happened so no reliable data is available that the damage only occurred after tagging.
Now that you have come to see that mp3val reveals properties of a file that cannot be seen otherwise, I would recommend to run the whole collection through MP3diags as this program discovers other problems and allows you to filter for certain abnormalities.
Also, it would be interesting to see if a file that Mp3val has identified as being without problems develops some after you tagged it.

Yes, I actually turned up another compilation I had worked on a few month ago with which I had audible issues with some of the files, but I had assumed they were caused by disc read errors during ripping, and resolved the issue by re-ripping the files. However, I discovered that the original files in this case do not have problems (I never bothered to check them since I assumed they were at fault), but the tagged versions have issues when inspected with mp3val (including some that were not audible). Very odd. I still need to reproduce the issue from start to finish to be 100% sure, and I will definitely go though the rest of my files. I am worried that some files that I can't re-rip (files downloaded from vinyl downloads, primarily) may be damaged because I tend to tag them (they are often missing dates and genres), and I don't keep the unmodified originals. Oh, well.

Can you please do a simple test?

  1. Copy the original that does not have problems to a test folder
  2. Tag the files using Mp3tag
  3. Check if the resulting file has any issues.

If the files have issues, please sent me the original, so that I can verify and analyze the issue. If not, I'm not interested in prolonging the topic any further as it already shows circular nature.