PDA

View Full Version : ID3v2 tags recognized by SlimServer



JJZolx
2006-11-11, 12:21
If SlimServer encounters an id3v2 tag that is written within an TXXX (user defined) frame, will it recognize the tag just as if it were a native frame?

What if the tag written to the TXXX frame is a "freeform" tag such as those normally encountered in Vorbis and Ape2 tags? For instance, an Mp3 file has ID3v2 tags and has a COMPILATION=1 tag located within a TXXX (user defined) frame?

Does SlimServer distinguish between id3v2.3 and id3v2.4 tags? If a tag defined only in the id3v2.4 spec (e.g. TSOP) is encountered in an id3v2.3 tag, will it be recognized?

gerph
2006-11-11, 13:39
If SlimServer encounters an id3v2 tag that is written within an TXXX (user defined) frame, will it recognize the tag just as if it were a native frame?

Only certain tags will be recognised within the TXXX tag; it's really intended for extensions, rather than as an replacement for the native frames. I believe the JRiver media jukebox tags are recognised like this.


What if the tag written to the TXXX frame is a "freeform" tag such as those normally encountered in Vorbis and Ape2 tags? For instance, an Mp3 file has ID3v2 tags and has a COMPILATION=1 tag located within a TXXX (user defined) frame?

The only compilation tag that's recognised by SlimServer is the non-standard TCMP (or TCP in ID3v2.2 parlance) tag. This can be used to indicate a compilation; however it is NOT a standard ID3v2.x frame name. You may wish to contact the ID3v2 mailing list to see whether there's any movement (or opinion) on the state of that frame.


Does SlimServer distinguish between id3v2.3 and id3v2.4 tags? If a tag defined only in the id3v2.4 spec (e.g. TSOP) is encountered in an id3v2.3 tag, will it be recognized?

If you do something which is outside of the scope of the specification you should expect undefined behaviour. In this case, the TSOP frame is - as you say - not present in ID3v2.3, and so you should expect undefined behaviour. Such a frame would have different semantics to that expected by ID3v2.3. An ID3v2.4 frame may have multiple entries delimited by nul characters, may use encodings 2 (UTF-16BE) and 3 (UTF-8), and changes the semantics of encoding 1 (UCS-2 and UTF-16 for .3 and .4 respectively - the difference really only being that of the lack of high surrogates in UCS-2, IIRC). Similarly, meaning of the flags differs between ID3v2.3 and ID3v2.4 - the most important of which is that the latter allows per-frame unsynchronisation, whereas the former must be per-tag. As such, dropping a ID3v2.4 frame verbatim on to ID3v2.3 files will not work. If, on the other hand, you were to just use TSOP within the limited realms of the ID3v2.3 specification with the correct flags, without multiple entries, and limiting yourself to encodings 1 and 2, then you may find that it works.

It wouldn't be unreasonable for it to be rejected as invalid at this or any future point in time.

JJZolx
2006-11-11, 14:17
gerph, thanks for the reply. I understand what you're saying, but I'm really looking for SlimServer's behavior.

I see what mean about the semantic differences between v2.3 and v2.4, but that would seem to be mostly a parsing issue. Like you say, there's no reason why a TSOP tag appearing within an ID3v2.3 tag couldn't be accepted, but it's up to the application. And no reason why tags, including those used by Flac, within TXXX frames couldn't be accepted similarly. So that's why I'd like to find out how SlimServer handles them. I would NOT expect non-standard acceptance of tags to change in the future unless there's a really good reason to do so.

I'm in the process of retagging a number of mp3 files that I have and need to balance the better flexibility of ID3v2.4 with applications and devices that may not read v2.4 tags. I suspect that not too many apps will choke if they encountered an unknown ID3v2.4 frame in an ID3v2.3 tag, nor should they have problems if they see something in a TXXX frame. Then I have to balance this with the capabilities and the quirks of the tagging software that I'm using.

gerph
2006-11-11, 14:50
gerph, thanks for the reply. I understand what you're saying, but I'm really looking for SlimServer's behavior.

What I mean is that the TXXX one won't work the way you expect, but the TSOP (et al) should. Your best bet if you want to check these things is to try the MP3s with the MP3::Info library directly. I have a lump of code around here somewhere that I used for that... http://usenet.gerph.org/ID3/test.txt is the very simple harness I used for testing some changes I made to the MP3 parser, and http://usenet.gerph.org/ID3/test2.txt is the later version of that same thing with a better handling of some of the frames. You'll need to fix up the paths in the 'require' and the file that you want to parse. Basically anything you get out of that is potentially parsable.

The MP3::Info file that's used in the source is lib/MP3/Info.pm and if you want to see how the tags are converted specially without Slimserver (rather than the 'generalised' version that MP3::Info provides) then look in the Slim/Formats/MP3.pm file - there are a whole load of conversion names in there $MP3::Info::v2_to_v1_names which provides the mapping between certain frame names and their internal forms. I realise you have to read some code to understand what's going on, but from what you've said you know the ID3v2 specification at least enough to ask the question (!) so you should be able to pick out some bits from there.

Earlier today I started updating http://wiki.slimdevices.com/index.cgi?SlimServerSpecification with /some/ of the details of what will be parsed by the server (which was why I'm replying in the first place - I'd been working through the sources only a few hours earlier). It's not complete but it gives you some idea of what can be parsed.


I see what mean about the semantic differences between v2.3 and v2.4, but that would seem to be mostly a parsing issue. Like you say, there's no reason why a TSOP tag appearing within an ID3v2.3 tag couldn't be accepted, but it's up to the application. And no reason why tags, including those used by Flac, within TXXX frames couldn't be accepted similarly. So that's why I'd like to find out how SlimServer handles them. I would NOT expect non-standard acceptance of tags to change in the future unless there's a really good reason to do so.

The thing is that these 'free form' tag names don't gain you much in general. Take, for example, the COMPILATION tag which you cited. It's not defined anywhere what any of the user defined tags mean, so if you were to (say) populate the COMPILATION tag with a value to indicate 'this is a compilation' then it wouldn't mean all that much. Someone else might have set the COMPILATION tag to 'no' to mean that it's not a compilation. Or someone else might have set it to 'NOW collection' to indicate which particular compilation it's part of. Without any particular semantics for the tags, you're basically going to have to take your chances. It might be non-standard but the unfortunate iTunes use of TCMP (I wonder if they even bothered to discuss it on the ID3 mail list ? Dunno, but I'd be surprised if they did) will probably be your safest bet.


I'm in the process of retagging a number of mp3 files that I have and need to balance the better flexibility of ID3v2.4 with applications and devices that may not read v2.4 tags. I suspect that not too many apps will choke if they encountered an unknown ID3v2.4 frame in an ID3v2.3 tag, nor should they have problems if they see something in a TXXX frame. Then I have to balance this with the capabilities and the quirks of the tagging software that I'm using.

<sigh> yes, I've yet to find any ID3v2 tagger that I'm happy with. They're generally dreadful, and those which are just awful don't support ID3v2.4 footers (that is, none of the taggers support footers).

You do, however, have a bonus with the T??? frames. Because the form of those frames are all explicitly defined for ID3v2.3, if you conform to that style then you /should/ find that everything works. Even if you use the nul separated lists from ID3v2.4 in the text of the ID3v2.3 frame it should still work because the standard says that everything after the first nul is ignored.

I'd take a deep breath and say 'TSOP' (and friends) should work fine at the moment if you did that.

Sorry, that's a pretty longwinded answer.