# Request: Permit id3v2.4 frames in id3v2.3 tags
**URL:** https://community.mp3tag.de/t/request-permit-id3v2-4-frames-in-id3v2-3-tags/4333
**Category:** Support
**Created:** [January 15, 2007, 6:48am UTC](https://community.mp3tag.de/t/request-permit-id3v2-4-frames-in-id3v2-3-tags/4333 "2007-01-15T06:48:24Z")
**Posts on this page:** 9
**Page:** 1
### Author:  [@JJ\_Johnson](https://community.mp3tag.de/u/JJ_Johnson)
#### Post date: [January 15, 2007, 6:48am UTC](https://community.mp3tag.de/t/request-permit-id3v2-4-frames-in-id3v2-3-tags/4333/1 "2007-01-15T06:48:24Z")
I have an application that is perfectly happy reading so-called id3v2.4 frames if found in id3v2.3 tags. I'd like to request an option to ignore the strict enforcement of specific frames when written to id3v2.3 tags. If I want to write TSOA (Mp3tag's "ALBUMSORTORDER") and TSOP (Mp3tag's "PERFORMERSORTORDER") frames to an id3v2.3 tag then please enable a mechanism to let me do this. This is not the "corruption" of tags. I suppose there may be stupid applications or devices that will crash if they see an unrecognized frame (that really would be extraordinarily stupid) so by making this an option, you can leave it to the user.
This again gets back to the need for better user control over exactly which tags are written to a file. I'd still like to see a user-definable tag mapping system instead of having to break out the hex editor to figure out what Mp3tag did to a file.
Also, I notice that Mp3tag won't allow me to write a TCMP (MP3tag's "ITUNESCOMPILATION") frame with a value of 0 to id3v2 tags. This again is imposing some understanding of how Apple iTunes treats this tag, whereas my application doesn't treat it the same.
You have to understand that due to the completely screwed up id3v2 "spec" applications are having to extend this spec, plus they often have to deal with frames created by _other_ applications. So tags like TCMP are no longer just used by iTunes and can be used and useful in other apps. Tagging standards, even for something like the years-old id3v2.3, are continuously evolving and I'm afraid Mp3tag doesn't quite have the necessary flexibilty to deal with this evolution.
---
### Author:  [@Sebastian\_Mares](https://community.mp3tag.de/u/Sebastian_Mares)
#### Post date: [January 15, 2007, 5:19pm UTC](https://community.mp3tag.de/t/request-permit-id3v2-4-frames-in-id3v2-3-tags/4333/2 "2007-01-15T17:19:11Z")
Adding of ID3v2.4 specific frames to ID3v2.3 tags is stupid and will corrupt the tags - use ID3v2.4 instead and if your application of choice does not support them, inform the developers.
As for TCPM, that is not an ID3v2 standard frame and only iTunes uses it (or at least introduced it). Since it's not standard and since it was added for compatibility reasons with iTunes, I see no point changing the current behavior.
Maybe Florian has another opinion, though.
---
### Author:  [@JJ\_Johnson](https://community.mp3tag.de/u/JJ_Johnson)
#### Post date: [January 15, 2007, 5:37pm UTC](https://community.mp3tag.de/t/request-permit-id3v2-4-frames-in-id3v2-3-tags/4333/3 "2007-01-15T17:37:01Z")
> [@Sebastian Mares](#):
>
> Adding of ID3v2.4 specific frames to ID3v2.3 tags is stupid and will corrupt the tags - use ID3v2.4 instead and if your application of choice does not support them, inform the developers.
>
> As for TCPM, that is not an ID3v2 standard frame and only iTunes uses it (or at least introduced it). Since it's not standard and since it was added for compatibility reasons with iTunes, I see no point changing the current behavior.
Explain what you mean by "corrupt". You've used this term before, but I can't understand what you mean.
I can't use id3v2.4 tags because I use the files on a device that doesn't support them.
Just because TSOP and TSOA and TCMP aren't part of the "standard" in id3v2.3 means nothing. The layout, the headers, and general form of id3v2.x tags I consider to be the "spec". The proscribed frames and their meanings I consider to be nothing more than suggestion. These tags (and any other 'T...' named frame you can think of) can easily be written to id3v2.3 tags with no consequence. Again, if it's made a user option, then at least we'd have the flexibility to accomodate applications that have extended the id3v2 "standard".
I hate id3 with a passion. But if I'm going to use Mp3 files, I'm stuck with them.
---
### Author:  [@Sebastian\_Mares](https://community.mp3tag.de/u/Sebastian_Mares)
#### Post date: [January 15, 2007, 6:44pm UTC](https://community.mp3tag.de/t/request-permit-id3v2-4-frames-in-id3v2-3-tags/4333/4 "2007-01-15T18:44:22Z")
Corrupt means that it will break the tags. If the specifications don't state those frames to be part of the ID3v2.3 standard, and you add such frames to an ID3v2.3 tag, you are doing this against the specifications. Any frame that is not included in the set of standard frames has to be a TXXX frame. It _can_ break compatibility with other programs that don't understand that specific frame.
---
### Author:  [@JJ\_Johnson](https://community.mp3tag.de/u/JJ_Johnson)
#### Post date: [January 15, 2007, 7:25pm UTC](https://community.mp3tag.de/t/request-permit-id3v2-4-frames-in-id3v2-3-tags/4333/5 "2007-01-15T19:25:15Z")
How can it _possibly_ break any program?
I'd be willing to bet that there are --- 0 --- cases of programs for which this will cause compatiblity problems.
Looking at the so-called "spec" of id3v2.3.0 at:
[http://www.id3.org/d3v2.3.0](http://www.id3.org/d3v2.3.0)
See all the esoteric frame declarations that aren't widely used? We're talking about _many_ "declared" frames that are perfectly legal within the standard. Now what does a program do when it encounters one of these unrecognized oddball frames? It just ignores it. That's exactly what it will do with TSOA and TSOP and TCMP and TIOU and TSEX... etc, etc.
---
### Author:  [@Sebastian\_Mares](https://community.mp3tag.de/u/Sebastian_Mares)
#### Post date: [January 15, 2007, 8:21pm UTC](https://community.mp3tag.de/t/request-permit-id3v2-4-frames-in-id3v2-3-tags/4333/6 "2007-01-15T20:21:40Z")
Just had a look at the ID3v2 specs (it's been some time since I last did that) and seems that I was wrong, sorry:
> [@](#):
>
> At the start of every frame there is an identifier that explains the frames' format and content, **and a size descriptor that allows software to skip unknown frames.**
---
### Author:  [@JJ\_Johnson](https://community.mp3tag.de/u/JJ_Johnson)
#### Post date: [January 15, 2007, 11:26pm UTC](https://community.mp3tag.de/t/request-permit-id3v2-4-frames-in-id3v2-3-tags/4333/7 "2007-01-15T23:26:11Z")
> [@Sebastian Mares](#):
>
> Just had a look at the ID3v2 specs (it's been some time since I last did that) and seems that I was wrong, sorry
Thanks, Sebastian. That's very gracious of you.
I would suggest the following option, under Tags\>Mpeg\>Id3v2. A checkbox
Permit non-standard text frames in id3v2 tags
This would have two effects:
1. Mp3tag names like PERFORMERSORTORDER that currently map to T--- frames only for id3v2.4 tags, would also write the same frames to id3v2.3 tags
2. If an action uses a non-standard tag with a name of the form T---, then write it as-is to both id3v2.3 and id3v2.4 tags as a text frame instead of as a user-defined TXXX frame.
---
### Author:  [@JJ\_Johnson](https://community.mp3tag.de/u/JJ_Johnson)
#### Post date: [February 1, 2008, 2:49am UTC](https://community.mp3tag.de/t/request-permit-id3v2-4-frames-in-id3v2-3-tags/4333/8 "2008-02-01T02:49:25Z")
I just became aware that Mp3tag now writes select id3v2.4 frames to id3v2.3 tags.
[/t/5348/1](https://community.mp3tag.de/t/5348/1)
I'd like to suggest that Mp3tag write _any_ id3v2.4 native frame to id3v2.3 tags. There's just very little reason to do otherwise. It would also simplify the documented behavior as then id2v2.3 and id3v2.4 would behave the same.
---
### Author:  [@system](https://community.mp3tag.de/u/system)
#### Post date: [February 9, 2026, 12:20pm UTC](https://community.mp3tag.de/t/request-permit-id3v2-4-frames-in-id3v2-3-tags/4333/9 "2026-02-09T12:20:05Z")