# How to prevent MP3Tag from copying channel layout

**URL:** <https://community.mp3tag.de/t/how-to-prevent-mp3tag-from-copying-channel-layout/60914>\
**Category:** Support\
**Created:** [May 7, 2023, 9:32am UTC](https://community.mp3tag.de/t/how-to-prevent-mp3tag-from-copying-channel-layout/60914 "2023-05-07T09:32:34Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![very\_annoyed](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/v/cc9497/32.png) [@very\_annoyed](https://community.mp3tag.de/u/very_annoyed)\
**Post date:** [May 7, 2023, 9:32am UTC](https://community.mp3tag.de/t/how-to-prevent-mp3tag-from-copying-channel-layout/60914/1 "2023-05-07T09:32:34Z")

</div>

When ripping an album in multiple formats, it's convenient to add metadata on one version of the album, and then copy/paste the tags to the others. This works very well as long as all the formats have the same channel layout. However, if I copy tags from a 5.1 album to a stereo album, the stereo files get marked "Channel layout: L R C LFE Lb Rb" in MediaInfo. How can I prevent this from happening?

---

<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:** [May 7, 2023, 9:45am UTC](https://community.mp3tag.de/t/how-to-prevent-mp3tag-from-copying-channel-layout/60914/2 "2023-05-07T09:45:29Z")

</div>

Is the channel layout information from the file header or a user-defined field in the tag data?

---

<div class="post-metadata">

**Author:** ![very\_annoyed](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/v/cc9497/32.png) [@very\_annoyed](https://community.mp3tag.de/u/very_annoyed)\
**Post date:** [May 7, 2023, 10:19am UTC](https://community.mp3tag.de/t/how-to-prevent-mp3tag-from-copying-channel-layout/60914/3 "2023-05-07T10:19:55Z")

</div>

I have no idea, it's automatically there when converting with a FLAC tool. Here's an example 4.0 file: [Gofile - Free Unlimited File Sharing and Storage](https://gofile.io/d/O3WIa2)

---

<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:** [May 7, 2023, 11:21am UTC](https://community.mp3tag.de/t/how-to-prevent-mp3tag-from-copying-channel-layout/60914/4 "2023-05-07T11:21:38Z")

</div>

I see a tag field  
WAVEFORMATEXTENSIBLE\_CHANNEL\_MASK  
in the extedned tags dialogue.  
 ![grafik](https://community.mp3tag.de/uploads/default/original/2X/d/dcdfdd10b0c7806119ea064224bc10582dd2de80.png)

that Foobar does not show - but it shows channels:  
 ![grafik](https://community.mp3tag.de/uploads/default/original/2X/9/9fe42592210794b53249e8cd7a55698261104b0f.png)

and after I copied the tags from the flac file to an mp3 file, the tag fields stayed the same in MP3tag:

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

But the technical description in Foobar changed:  
 ![grafik](https://community.mp3tag.de/uploads/default/original/2X/2/2067404223e0309ac27ba16b3e7809b9a9adb61c.png)  
so that Channels are now 2.  
but Foobar now also shows the extra tag field as MP3tag.  
So: I would just delete the field WAVEFORMATEXTENSIBLE\_CHANNEL\_MASK.

I don't know if this is something that should be dealt with in the program as special information as apparently some programs evaluate this special field to be technical information and not a user-defined field.

---

<div class="post-metadata">

**Author:** ![very\_annoyed](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/v/cc9497/32.png) [@very\_annoyed](https://community.mp3tag.de/u/very_annoyed)\
**Post date:** [May 10, 2023, 5:42pm UTC](https://community.mp3tag.de/t/how-to-prevent-mp3tag-from-copying-channel-layout/60914/5 "2023-05-10T17:42:32Z")

</div>

Deleting the field works when copying metadata from 5.1 to stereo, but not the other way around, as I'd like to keep the layout consistent in case it matters for playback. Ideally Mp3tag would just ignore this field entirely when copying, but at least now I know how to fix it. Thanks.

---

<div class="post-metadata">

**Author:** ![mb2007](https://community.mp3tag.de/user_avatar/community.mp3tag.de/mb2007/32/22590_2.png) [@mb2007](https://community.mp3tag.de/u/mb2007)\
**Post date:** [May 19, 2023, 12:19pm UTC](https://community.mp3tag.de/t/how-to-prevent-mp3tag-from-copying-channel-layout/60914/6 "2023-05-19T12:19:14Z")

</div>

Thanks for posting this, as it helped me resolve the problem I was having when copying tags among mono FLACs: Mp3tag was copying channel layout data I actually wanted to get rid of. However, I can see how sometimes you might want Mp3tag to preserve that data, so I don't consider the default behavior undesirable.

To better explain:

WAVEFORMATEXTENSIBLE\_CHANNEL\_MASK is typically used in lossless multichannel files to say what channels are present. I often find it in mono files, too, depending on how they were made. [The mask values are defined by Microsoft](https://learn.microsoft.com/en-us/windows/win32/api/mmreg/ns-mmreg-waveformatextensible), with  
0x1 = Left  
0x2 = Right  
0x4 = Center  
and so on; you add the values for each channel that's present, e.g. a stereo file could have 0x3.

If the value is not given for a single-channel file, players should default to center. That's what I want for my mono FLACs, so I just deleted WAVEFORMATEXTENSIBLE\_CHANNEL\_MASK entirely from the extended tag panel in Mp3tag. Alternatively, I could've set the value to 4.

---

<div class="post-metadata">

**Author:** ![system](https://community.mp3tag.de/uploads/default/original/2X/c/ce7035d426cb755a7916793326d23b465222a407.png) [@system](https://community.mp3tag.de/u/system)\
**Post date:** [June 18, 2023, 12:19pm UTC](https://community.mp3tag.de/t/how-to-prevent-mp3tag-from-copying-channel-layout/60914/7 "2023-06-18T12:19:22Z")

</div>

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
