First of all i want to say that I LOVE mp3tag and that has saved me so many hours, I've lost the count ages ago. And that is why I'm reporting this, which is the most serious bug IMHO, for this wonderful, yet free, product.
I use the latest iTunes version, which is able to handle v2.4 id3 tags properly, and to correctly convert them between the various formats.
But even the latest 2.35 mp3tag version doesn't properly recognise the tags: for example, the year is not visible even if it's written in the tag, when the tag is v2.4, and whenever I write the tag with mp3tag, the tags get written in the older 2.3 format and NOT the new 2.4, even if they previously correctly where 2.4.
Is this intended and the support for 2.4 tags is yet to be done, or is it a bug?
It's not a bug, but a limitation of the feature. Currently, only ID3v2.3 tags are supported. ID3v2.4 might be added in the future, but it's not something that has priority. Personally, I don't know any tagging application that supports ID3v2.4 tags other than iTunes and Frontah - not to mention media players or even hardware.
Edit: Oh, and by the way... MP3Tag used id3lib that doesn't have stable ID3v2.4 support, yet.
I just visited the id3lib website and browsed the mailing list, to find out that id3lib has no v2.4 support (which I want to remember, brings full UTF-8 and UTF-16 compatibility, and many other enhancements and fixes), and is quite dead (the only active developer and maintaner, has admitted it has NO TIME to devote to the lib anymore, and the lib isn't making ANY real improvement at all since 2003).
Now, since mp3tag is an alive and kicking project (v2.35 is fresh stuff ;-)), why not consider another library?
There ARE better, active, developed and full-featured id3 libs out there!
The most promising is TagLib, which gives everything id3lib has to offer, plus full 2.4 support out of the box. It's unix-centered (mainly various linux, bsd and osx flavors), but there are windows ports available.
So... why not give it a try? I mean: I know it's no easy work to recode mp3tag around a new library... but mine is only a suggestion, especially since id3lib is dead stuff nowadays (and has been in the last 2 years as well it seems) and we can't expect ANY improvement from it.
I mean: better to start recoding today, than to improve and improve mp3tag around a old-and-dead library that promise no improvements or bug fixes, and may become incompatible with the new standards as they come (in fact, it has already happened, we are just lucky 2.4 hasn't get widespread attention yet, but with iTunes which is 2.4 focused, things will change quickly I think).
This will become more and more an hindrance to this wonderful product, if not handled ASAP imho.
Speaking of TagLib vs. id3lib, this is the reason for an issue
that makes interoperability between Linux and Windows
harder.
That is because TagLib (AFAIK) ONLY writes v2.4
whereas id3lib ONLY writes v2.3.
So, if you use AmaroK (easily the best player for KDE)
which happens to use TagLib, to tag your mp3s you'll end
up with v2.4, no way around it (but please feel free
to prove me wrong).
Cheers!
Klaas
PS (and yes, you could call me an "v2.4 advocate")
Thanks for reporting that, didn't notice this when using amarok (essentially since I do not use Amarok for tagging), but it's another good point for switching over to TagLib or any other v2.4-enabled library.
Doesn't TagLib write to ID3v2.4 only? If yes, changing the library from id3lib to TagLib makes no sense since ID3v2.3 is a LOT more wide-spread than ID3v2.4. Even current audio equipment (both software and hardware) don't support the full ID3v2.3 standard (only a handfull support Unicode), not to mention ID3v2.4 compatibility. Find me a hardware MP3 player that supports ID3v2.4. Looking at the software side, I guess you won't find 5 popular players that support ID3v2.4.
Seriously, what exactly do you miss in ID3v2.3 that you find in ID3v2.4?
But since TagLib has been born to replace the buggy&old id3lib, I guess that's the case.
Moreover, the official id3 website itself, suggest to use ONLY v2.4, since it's just the new, updated and revised version, of the popular mp3 tags.
The fact that v2.3 is still dominant is not why we should use id3lib, it's the other way around: 2.4 isn't very well supported YET, just because most of the players still use the old id3lib, which hasn't been updated since 2003!
That's why TagLib was born and that's why newer, better players focus on 2.4 (amarok, iTunes).
"Why TagLib?
TagLib was written to fill a gap in the Open Source/Free Software community. Currently there is a lack in the OSS/FS for a homogenous API to the most common music types.
As TagLib will be initially injected into the KDE community, while I am not linking to any of the KDE or Qt libraries I have tried to follow the coding style of those libraries. Again, this is in sharp contrast to id3lib, which basically provides a hybrid C/C++ API and uses a dubious object model.
I get asked rather frequently why I am replacing id3lib (mostly by people that have never worked with id3lib), if you are concerned about this please email me; I can provide my lengthy standard rant.
Official UTF8 and UTF16 support among the rest. Compatibility with newer players that correctly use v2.4 as the OFFICIAL ID3 STANDARD tells to do.
Hardware players: any iPod. It's 90% of the mp3 hardware player market (yes, 9 out of 10 hardware mp3 players are iPod today).
Software players: iTunes (one of the most popular player, if not THE most, since it's the iPod player), and amarok (I think one of the best unix players, if not the best), juK, XMMS (through IMMS plugin), MusicCube and several others less famous.
Aren't amaroK, juK and XMMS Linux players? In the Linux world, ID3v2.4 might be more wide-spread because most (if not all) of those programs are based on TagLib. However, on Windows, only iTunes can deal with ID3v2.4. Winamp added some sort of ID3v2.4 support, but that doesn't help your UTF-16 problem since Winamp still doesn't support it entirely.
As for hardware support - iPod being the only player supporting ID3v2.4 is a limitation. You say it holds 90% of the market share - what about the other 10%? Should we ignore them completely? What about in-car MP3 players? Where do you know that iPod users use MP3 and not MP4 that features its own tagging format?
I personally see no point in dropping ID3v2.3 support in favor of a format that that isn't popular, yet. Unicode is not something bound to ID3v2.4. foobar2000 supports Unicode and uses ID3v2.3. The only advantage I see in ID3v2.4 is its ability to be placed at the end of the file.
"The character encodings UTF-16BE and UTF-8 has been added to the list of valid encodings [S:4]
About the linux players, not entirely true: winamp is working on 2.4 support, and KDE libs will be ported to windows, and therefore we could easily see kde apps on windows (amarok, juK, etc..) with KDE4.0 release (less than an year).
And I don't have any problem with UTF, i was just quoting some of the 2.4 highlights (there are many many more reasons to adopt 2.4, as you can check from the changes document I linked back there).
Very very true, and I don't want mp3tag to ignore them or drop support for them at all.
Since I dropped some v2.4-only mp3 files onto my iPod through Anapod Explorer, and they perfectly show up with all the info, lyrics and cover included =)
You got me wrong: I do not want mp3tag to 'drop' backward compatibility support, aka v2.3. I see no point in dropping ID3v2.3 support as well.
I want mp3tag to be standards-compliant, and be able to read any version, including 2.4, and write both 2.3 and 2.4 (and older as well maybe) at users choice, as iTunes does (by default it's 2.4, but you can 'convert them' to any format and iTunes will just read and write any format).
The best would be IMHO to switch over to TagLib, which surely READS all the formats and I GUESS is able to write as well in all them. If that's not the case, since this is the only 'active & alive' lib, it would be the case to ask the author if this is something planned or could be done in the next version, maybe since it read it and it seems to be a wonderful done lib (it was born to address id3lib shortcomings, after all), it already does it or can be coded into easily.
That's what I hope at least =)
Wouldn't it be useful, at least to have a look at it and check if this may be done and we could have a mp3tag 3.00 built around a better, newer, always improving library, with full 2.3 AND 2.4 support? That's what I wish for mp3tag =)
And this is the problem - TagLib only supports writing of ID3v2.4 tags. And one more thing: the Windows ports (notice the plural of "port" - that means that there are multiple) are not official and therefore not supported.
I think a try could be made anyway (by checking out the ports and ask the author if writing ID3v2.3 will be done or could be done with some work), and it could be worth it.
Just my 0.02$
P.s. what do other users think about this subject?
The MusicBrainz Picard Tagger, which is a Windows/Linux application (runs fine on both), is able to read any version of ID3v1/ID3v2 tags, and properly writes ID3v2.4 tags by default.
But, since v2.4 is still not very well spread because of missing id3lib support, there is a config option "Write ID3v2 version 2.3 tags (2.4 is default)" and you can also choose the text encoding to use to write tags, where UTF-8 is of course only available to 2.4 tags, since it was introduced with 2.4.
This is a windows tagging application, and this is EXACTLY what I mean and what I would love to see in mp3tag (which has a LOT of features which Picard is missing of course).
Maybe we could check which (if any) id3 library is Picard based onto, or how did they manage to achieve this result and have this feature, which I think should be on the top10 'next to do' list for mp3tag, since the attention 2.4 is getting because of iTunes and amarok mostly (and now, musicbrainz as well).
I'm currently rewriting all tagging related code to get rid of id3lib and use a own ID3v2 implementation instead. Using TagLib or a mix of TagLib and id3lib is not an option for me (don't like both of them).
At the moment it only writes ID3v2.3, but it can be changed to write ID3v2.4 too. There's is still much other work in the queue, so next final propably won't have ID3v2.4 writing.
But I see your points and also like to have Mp3tag to use the latest standards. But I must admit, that ID3v2.4 support is not top priority at the moment. Just have to get all the other stuff working again
That sounds great Florian! While at it, are you going to support "footer" ID3v2.4 tags (I mean tags that are placed at the end of the file similar to APEv2)?
Nothing, but UTF-8 is better (it uses LESS space for occidental writings, since most of the characters involved fall into the first byte [ASCII]) for 'us' (american, europeans, etc... not for japanese, chinese, etc...) =)
Support for them would be surely nice for mp3tag
to be be fully standards compliant as a partial (=broken)
v2.4 implementation would suck, but I think that this has
to be the most unsupported part of v2.4 "in the field".
Probably because ID3v2 has always been prepended, no one cares
about thinking of the fact that v2.4 might be appended.
So if appended v2.4 Tags are supported, the option should definately
have a "not recommended" in its description
The normal, default way of writing v2.4 should be prepended with UTF-8 IHMO.
(I'll second omero's description why UTF-8 is at least a little nicer )
This should by no means imply that v2.4 with UTF-16 or v2.4 with ISO
encoding should not be offered, because there is some hardware
which sadly only reads v2.4 with UTF-16 and NOT v2.4 with UTF-8 (tested this myself).
IMO the user should be able to select all three encodings.
)