ReplayGain data and copying tags

Thanks for a great program. I use Mp3tag often.

I'm trying to work out if it's possible to copy and paste tags from one file to another without including any ReplayGain info. Everything else. No ReplayGain. In my opinion it should never be copied because unless the files to which the tags are being pasted are the same volume as the files from which the tags were copied, it'll be wrong.

For a long time this hasn't been an issue. For MP3s the usual tag data was saved to an ID3 tag and MP3Gain saves the ReplayGain info to Ape tags, so I could use Mp3tag to copy and paste the ID3 tags and no ReplayGain info would be included. Perfect.

These days though, I tend to work with multiple file types, sometimes where only one type of tag can be used, and most programs write everything to a single type of tag anyway. I'm so used to the ReplayGain info not being included when copying and pasting, I keep forgetting to update or remove it.

Thanks again!

Edit: I was thinking too.... maybe it'd be good if the same principle could be applied when pasting tags. If the files to which tags are being pasted already have tags containing ReplayGain info, it'd be nice to have an option for everything in the existing tags to be replaced except the ReplayGain info. I think it'd be better if it was excluded, although removing it would be the next best option. It's probably better to have no ReplayGain info in tags than to have the wrong ReplayGain info.

Can't you just create a saved action to delete the ReplayGain fields?

Yes., and I've done so, but it's a "need to check if the source tags contain ReplayGain info" or a "need to remember to do it" action.

It was easy when I generally only worked with MP3s and the ReplayGain info was in an Ape tag. I could copy and paste ID3 tags all day long and never have to worry about ReplayGain data being included.

Is there a reason why ReplayGain info should be included when copying and pasting tags, given the ReplayGain info is generally specific to a particular file?

Foobar2000's converter can copy data from the source file tags to the output file tags and by default that doesn't include ReplayGain info (although there's an option to include it too). That seems logical to me.

Make it an "always do it" action.

When I'm working with certain types of files, I have sets of action groups that I always run. They reformat, create and delete many fields, whether or not the actions actually need to be done or the fields exist. I just have to make sure that any actions I create can be run multiple times without duplicating or otherwise harming the data.

I mostly do the same, but the couple of times recently when I didn't, is what prompted this thread.
I had a CDs worth of files ripped to flac, and also converted to m4a with ReplayGain applied. Later, I noticed a spelling mistake in the album name. Easy to fix. Save the change to the m4a files, highlight them, copy the tags, paste them into the flac versions. Days later, I wondered why the volume of the flac files seemed so different to everything else while playing them on my PC.

I could have not copied and pasted. I could have re-run the ReplayGain scan. I could have edited them individually.... I could have remembered to do something...... but the question I'm asking, is there a likely scenario where copying and pasting tags should include the ReplayGain info, or would it be better if it wasn't?

Anyway.... I guess there's no hidden Mp3tag option I can toggle to exclude ReplayGain, so the normal copy and paste options would need to be modified. Personally though, I don't see why that'd be a bad idea. Even two more right click options would do it. Something like:

Tag Copy
Tag Copy without ReplayGain
Tag Paste
Tag paste without ReplayGain

Today, after tagging a bunch of files which involved some copying and pasting of tags, I discovered another annoyance similar to the one being discussed here in respect to ReplayGain, and that's the copying and deleting of the iTunes ITUNSMPB field, which is where (I'm pretty sure) the gapless playback info for M4As is stored. So....

Convert a FLAC file to AAC using QAAC and the M4A it writes will contain the ITUNSMPB field in the tag with the appropriate gapless info. Open the flac file in Mp3Tag, copy it's tag, open the M4A file, paste the tag, and the M4A's gapless playback info is gone forever. Likewise if I was to copy an M4A tag and paste it into a FLAC file, the flac tag would now contain a ITUNSMPB which at best is useless, and probably detrimental if a player is silly enough to pay attention to it.

I still think when copying and pasting tags, any ReplayGain fields in the source file should be ignored when copying, and any ReplayGain fields in the destination file should be left untouched when pasting, because ReplayGain info is file specific.
The ITUNSMPB field is both file specific and file type specific, so I think the same theory should apply, only more-so :wink:.

I checked, and when converting (for example) an M4A to FLAC, foobar2000 is clever enough not to copy the ITUNSMPB field when writing the FLAC tag, just as by default it doesn't copy any existing ReplayGain info when writing an output file. I can't think of a logical reason why it wouldn't be clever for Mp3Tag to behave the same way when copying and pasting tags, but the gapless info seems like it could potentially be more of an issue, as unlike ReplayGain, you can't scan the file again to get the gapless info back.

Thanks. :slight_smile:

Is there a way to tell Mp3Tag not to apply an action to a specific field?

For example, it's easy enough to create an action that changes text to upper case for all fields, and I can create the same action for a specific field, but is there a way to create an action for all fields except the specified one(s)?

I'd like to create an action that changes text to upper-case (as an example) so "song title" is changed to "SONG TITLE" etc. How do I do that though, without Mp3Tag changing the track gain info from "-7.89 dB" to "-7.89 DB"?

Not that I've noticed it causing a problem yet, but I have noticed I've unintentionally formatted ReplayGain fields quite a bit, and I do worry about what I might one day do to the data in fields such as ITUNSMPB.

I still think it'd be a good idea if certain fields could be "protected" so no matter what actions are run or what info is copied and pasted etc, Mp3Tag doesn't change or write to those protected fields until the user specifically tells it to. I'm not sure how that'd best be implemented, but I do think being able to "lock" fields globally would be a good idea.

As I said in an earlier post, life was quite simple when I only worked with MP3s and used MP3Gain to save the ReplayGain info to APE tags. I could simply configure Mp3Tag to never touch the APE tags so there was no danger of me accidentally making a mess of them. Working with multiple formats and different tags containing file-specific info though, telling Mp3Tag to leave a specific type of tag alone is no longer sufficient. I'd like to be able to tell it it to leave specific fields alone instead.

Am I really the only one having issues with copying/pasting/changing data such as ReplayGain unintentionally?


AFAIK, the "Remove fields except" is the only action that can do that.

But, usually, when you want to apply actions such as "convert to all caps" you have specific fields on which you want them to work. If you need to apply that action to multiple fields, it isn't a lot of work to simply duplicate and edit the action multiple times within an action group.

For instance, I have an action group that cleans up data within the most common fields. One thing it does is makes sure there are no leading or trailing spaces or multiple spaces within the string. This is done with actions like this:

Action type: Format value
Field: TITLE
Format string: $regexp($trim(%title%),\s+, ,1)

I created one action, then duplicated and edited it for the ARTIST, ALBUM, YEAR, GENRE and COMMENT fields. It's one of those things you do once and probably never need to look at again. I have several dozen action groups defined in Mp3tag, and I don't have a single one that is configured to work across all fields.

Thanks for the info. I guess I need to create some field specific actions. I'm pretty sure Mp3Tag comes with a "Case Conversion" action out of the box which applies to all fields, and I've used it for years without having to consider possible unwanted field changes until now.


Of course there's also nothing wrong, if you have only a handful of fields in which you want the data a certain way, to apply that case conversion to all of them, and then undo the changes in certain fields. So apply your $upper() function to all fields if that's what you really want, then change 'DB' to 'dB' in each of the ReplayGain fields.


I strongly second this opinion: ReplayGain is file specific and should not be touched in any Copy / Paste Tags action!

The unwanted behavior of mp3tag to also copy the values of the ReplayGain tag to other files bothers me for many years already and wasted me a lot of time:
If one forgets to re-calculate the RPG after pasting tags right away, it becomes very difficult to identify the wrongly tagged files later.

Even setting RPG to zero would be much better than pasting the other file's RPG-value as it is easier to identify.

I know this an old thread, but wondering if there was any action to follow up on this? I am ripping my CD library in ALAC now, originally I had used an older format of mp3 In mixed rates between 128 and 256k. The ripper has already included the Replaygain information, but I would like to use the original tags for everything else.

If you copy the tags (and that is all of them) with the functions to copy tags and paste tags then you get the replaygain fields also in the new files.
But as you can identify the new files, it should be easy to delete the now superfluous fields.
There is no automatism.

Even if I delete the older mp3 file replaygain tags, when I copy/paste the rest of those tags into the new lossless rip, it still overwrites and blanks out the replaygain tag that was calculated and added during the rip (I use dBpoweramp if that matters). For many of my files, I have used tags that I prefer versus what is commonly found through online sources, so my preference is to keep the tags from what I already have. Perhaps a tool with selective tags for copy/paste would be useful for others with similar reasons to keep some tags intact but replace the contents of others?

You could still export the tag fields in question and re-import them after you have copy/pasted the other tags.
I think that there are functions around that would recalculate the gain values even after tagging.

1 Like

My partial workaround at the moment, when copying/pasting tags, is to make copies of the "source" files and remove any ReplayGain and/or ITUNSMPB info from the copies, before copying and pasting the tags. Or remove it after pasting. I've created custom tag panel fields to make it easier. And to remind me when files contain tags with data in those fields.


Unfortunately it's still only a very partial workaround. You can't paste tags into an m4a without losing the existing ITUNSMPB information, or into any file without losing the existing ReplayGain data, although I use foobar2000, so in my case it's not hard to rescan the files I've pasted tags into to at least get the ReplayGain data back.

I'm surprised there's any argument about changing the way copying and pasting works, because to me it's obviously a problem.

Anyway, I still use Mp3tag a lot, even if these days I found myself copying and pasting data one field at a time, instead of being able to copy and paste data from multiple fields and files in one go.


1 Like

So here is what I have found since getting this started. I am using CD Ripper from dbPoweramp. I’ve tested with several discs and found that the replaygain information is exactly the same whether it is evaluated during the rip, or if it is processed afterwards.

So to save some time, I am simply ripping without the replaygain calculation. Copying the complete tag details in mp3tag from the original rips, is pretty straightforward, regardless of the replaygain information. Afterwards, I then run the Music Converter feature in dbPoweramp to recalculate the correct replaygain information. This can be done in batches, so it only needs to be run once, even if I binge rip a large bunch of discs.

Thanks @ohrenkino and @yetanotherID for the suggestions!

Due to the annoyances under discussion I paid a bit of attention to a foobar2000 forum thread today and discovered fb2k can bulk copy and paste tags as mp3tag does, but it does so without including any ReplayGain or ITUNSMPB data, as that'd be a bit silly, and it leaves the ReplayGain and ITUNSMPB fields alone when pasting too, cause it'd be a bit mental not to.

At least that's how it worked for my minute of testing (so far). The process requires a few more clicks than mp3tag to copy and paste tags.

Load files into a playlist, highlight them, right click, select Properties, highlight all the fields, right click and copy.

To paste it's the same procedure for the destination files, except in the Properties window there's a right click option for pasting, and also a "paste tags" option under the Tools button. So far the only difference between the two I've noticed is the "paste tags" option works without having to highlight the fields first, which thinking about it, mightn't exist yet.

As a side note... I discovered Mp3tag is oblivious to ReplayGain fields fb2k saves to mp4/m4a files. If you tell Mp3tag to delete the tags from those files it deletes everything else, notifies you of it's tag removal success, yet the ReplayGain fields remain. It does remove the ITUNSMPB data when removing tags from mp4/m4a files though, even though that's the sort of thing you almost always want to keep.
fb2k leaves the ITUNSMPB stuff alone even when you tell it to remove mp4/m4a tags. The same doesn't apply to ReplayGain info when deleting tags, which is okay by me. You can re-run a ReplayGain scan any time, but the ITUNSMPB data... not so much.

A screenshot showing how batch copying tags looks with my fb2k setup.