Remove all tags except album art and...


Hello, I began using Mp3tag today and I would like to use it to clean up my music collection. what I would like to do is remove every tag there could possibly be on a batch of mp3s EXCEPT the album art. furthermore all of my file names are in the
Artist - Title format and I would like to use the file name to tag the mp3s as follows

Artist = Artist
Title = Artist - Title (filename)
Keeping Album art what ever it already is
And everything else should be gone including lyrics and track volume ect.

can someone help me find a way to do this as a batch process? whats the most efficient way I could get the desired result? thanks.

Converting tags - APEv2 to ID3v2.3 - Missing artwork

You want no track numbers or album name?

Create a new action group. It will contain three actions to accomplish what you want.

Action type: Remove fields except
Fields to leave: PICTURE

Action type: Guess values
Source format: %_filename%
Guessing pattern: %artist% - %title%

Action type: Format value
Field: TITLE
Format string: %artist% - %title% (%_filename%)

Did you actually want the file name in parenthesis like that, or was that just a comment? It wouldn't really make sense, as you just end up with the same information duplicated twice. Exclude the (%_filename%) part, if not.


Also, as with any widespread use of Mp3tag to tag a large number of files simultaneously: TEST the action group on a number of individual files and folders before unleashing it on your entire library.

The action group defined above isn't too dangerous, since you'll be wiping out everything except the embedded cover, and then pull fields from the file name. But you could also mess things up badly if you were do something like misspell 'PICTURE', or accidentally use a 'Remove fields' action instead of a 'Remove fields except' action. Either error would end up deleting all of your artwork. Always test first.


The parentheses was indeed just a comment.

When I get home I will test this on a small batch of duplicated files and then report back. Thank you in advanced.


it mostly worked but it looks like the track volume is still there and the lyrics are there.
I can see both in media monkey.
any ideas on how I can get rid of those?


No, not offhand. What is 'track volume'? Do you see these fields in Mp3tag using the extended tags dialog?


i dont think it is in there i believe it is replaygain_track_gain

im not sure why the lyrics seem to have remained.\

EDIT: i removed the files from media monkey and re loaded them into it and the lyrics are gone so that is good, just need to get rid of the replaygain_track_gain


A replaygain_track_gain field should definitely have been removed by a 'Remove fields except' action. I'm betting that it's not visible in the extended tags dialog of Mp3tag. Sounds like it may be another Media Monkey thing.


maybe it could be covered in an mp3tag update..

for now i will just delete them all manually in media monkey.

thanks for the help saved me from doing a lot of other manual tagging.


If these are Mp3 files encoded by LAME, then the track gain values could be in the LAME tags (headers), rather than in the ID3v2 tags. That may be what Media Monkey is reading.


seems like i can select the field and delete the values in media monkey but i dont know if its actually removing it. i wonder if there is a way to do this as a batch.

EDIT: reloading the files shows that it is still there. eh guess its there to stay.


If Media Monkey is reading them from the LAME header then it's the first application that I've heard of that can even read this value.

There's a small program called lametag that lets you examine LAME headers. It can't modify them, but it would you tell for certain if that's what you're looking at, and whether or not Media Monkey is removing the RG value.


hm yes it seems to be in the header its being read by lametag as:

"RG track gain: -8.7dB (determined automatically)"

  • Save all the embedded cover images from within the music file to disk file, use a filename per image, which makes sure to give the relation to the source file for later re-import.
  • Remove all existing Tag Types from the file using Mp3tag [Strg+R], prior make sure to have the correct settings for removing the complete tag types ID3v1, ID3v2, APE.
  • Import the previously exported cover image files back into the file, prior make sure to have the correct settings for writing and reading a Tag Type, for example ID3v2.3 UTF-16.

Proove this radical concept on a test file first.



that method also does not seem to remove the replaygain_track_gain im assuming because mp3tag is not designed to modify the headers.

i suppose this method works for removing everything but the art although overall the first method posted by JJ Johnson seems to be the most efficient and easiest.

thanks for the help everyone i guess ill have to live with the replaygain_track_gain being there for now.


Did you really try it out to remove all the Tag Types ID3v1, ID3v2, APE from the music file?
If so, then you will be left alone with the music data only.
You will not see any tag-field data in Mp3tag's dialog "Extended Tags...".

Because replaygain data are never stored in the mp3 header area (I never heard anything about this ...), there will be no extra data anymore in the music file after removing all the entire Tag Types!

Sometimes, when bad things have been going on before to the file, and different Tag Types have been stacked multiple on to each other, then the process of removing the Tag Types has to be applied repeatedly. At end Mp3tag displays an empty field in the list view column "TagRead (TagTypes)".

JJ Johnson's proposal from above does not remove the Tag Types, but only the tag-fields.
This might leave a possible bad structured Tag-Type stack as is - and the music file will stay corrupted as is.


It is not correct, that I never heard about technical data in the mp3 header, read there ...
show LAME Encoder settings


By default LAME (since, I think, version 3.94) always computes track ReplayGain and stores it in the LAME tag that it writes to files. The following LAME switches affect ReplayGain analysis:

--replaygain-fast compute RG fast but slightly inaccurately (default)
--replaygain-accurate compute RG more accurately and find the peak sample
--noreplaygain disable ReplayGain analysis

Mp3tag doesn't read, write, or remove the LAME tag from Mp3 files.

This is the output of lametag.exe on one of my Mp3 files, showing the RG values:

F:\Mp3\Santana\Milagro>lametag 01 Milagro.mp3
LameTag - Reads the LAME tag from an mp3 file
Copyright (c) 2005 phwip
Release 0.4.1, compiled 2005-09-09

F:\Mp3\Santana\Milagro\01 Milagro.mp3
Tag revision:       0
Encoder string:     LAME
Version string:     3.98r
Quality:            80 (V2 and q0)
Encoding method:    vbr new / vbr mtrh
Lowpass:            18,500Hz
RG track peak:      1.011433
RG track gain:      -3.4dB (determined automatically)
RG album gain:      <not stored>
nspsytune:          yes
nssafejoint:        yes
nogap continued:    no
nogap continuation: no
ATH type:           4
Bitrate:            minimal (-b) bitrate 32
Encoder delay:      576 samples
Padded at end:      840 samples
Noise shaping:      1
Stereo mode:        joint
Unwise settings:    no
Source sample freq: 44.1kHz
MP3Gain change:     <none>
Preset:             V2: preset standard (fast mode)
Surround info:      none
Music length:       11,728,958 bytes
Music CRC:          E881
Actual Music CRC:   E881
Info tag CRC:       7A1D
Actual InfoTag CRC: 7A1D


Hmm, yes, JJ Johnson, you are showing me the content of a LAME tag using the latest lametag.exe.
Oh yes, I was rather blind for a moment, and have simply forgotten the history of the LAME versions in my music collection.
Obviously lametag.exe does not work with "LAME 32bits version 3.98.4".
Lametag simply says: LAME tag not found.

I suspect, that the LAME tag can only be removed by re-compiling the mp3 file with the " --id3v2-only" option.

Although using the option " --id3v2-only" the LAME Tag is written too, as reported in my log files:

LAME 3.98.4 32bits (
Using polyphase lowpass filter, transition band: 19383 Hz - 19916 Hz
Encoding O:\IMPORT\Juliane Werding\Jenseits Der Nacht\06=Jenseits der Nacht=Juliane Werding=Jenseits Der Nacht=1987=Schlager=920A3B0A.wav
      to O:\IMPORT\Juliane Werding\Jenseits Der Nacht\MP3\06=Jenseits der Nacht=Juliane Werding=Jenseits Der Nacht=1987=Schlager=920A3B0A.mp3
Encoding as 44.1 kHz j-stereo MPEG-1 Layer III VBR(q=0)
Writing LAME Tag...done
ReplayGain: -3.5dB
The waveform does not clip and is less than 0.1dB away from full scale.
Scale: 1.39636836

LAME 3.98.4 32bits (
Using polyphase lowpass filter, transition band: 19383 Hz - 19916 Hz
Encoding O:\IMPORT\Bro'Sis\Never Forget (Where You Come From)\14=Let Me Know=Bro'Sis=Never Forget (Where You Come From)=2002=Pop=E50C7C0F.wav
      to O:\IMPORT\Bro'Sis\Never Forget (Where You Come From)\MP3\14=Let Me Know=Bro'Sis=Never Forget (Where You Come From)=2002=Pop=E50C7C0F.mp3
Encoding as 44.1 kHz j-stereo MPEG-1 Layer III VBR(q=0)
Writing LAME Tag...done
ReplayGain: -8.5dB
The waveform does not clip and is at least 0.1dB away from full scale.
Scale: 0.84262666

I must have closer look into my last compile session, I have just detected, that there are files with and without lametag.exe info. For now I suspect, that foobar's "Repair VBR header" changes the header, so that lametag.exe cannot see the LAME tag anymore. ???



That's the version of LAME that I'm currently using, and was used to encode the file shown above. I think the only files that LAME doesn't write a LAME tag to by default are <64kbps CBR encoded files.

No, these LAME options are used to control it:

-t disable writing LAME Tag
-T enable and force writing LAME Tag

I wouldn't disable it, though. If you don't want RG information computed and stored, use the --noreplaygain option shown in a previous post.


That sounds feasible. I believe the LAME tag is an evolution of the Xing VBR header.