Somehow I have ended up with some MP3 files with ID3 version 2.4.0 tags.
Running id3v2 --list on these files reports "No ID3 Tag", which is
wrong.

- -- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.11-1-686
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages id3v2 depends on:
ii  libc6                       2.3.2.ds1-21 GNU C Library: Shared libraries an
ii  libgcc1                     1:3.4.3-12   GCC support library
ii  libid3-3.8.3                3.8.3-4.1    Library for manipulating ID3v1 and
ii  libstdc++5                  1:3.3.5-12   The GNU Standard C++ Library v3
ii  zlib1g                      1:1.2.2-4    compression library - runtime

- -- no debconf information
iD8DBQFCiE3VrbXc6n5AevkRAt1/AKDCgmNgv5RiiptUQEuvVNnsz9SFIgCePkla
girg/icpT8m57IIW1mpPX+o=
=nOpP
-----END PGP SIGNATURE-----

Don't hold your breath. id3v2 can't support 2.4.0 tags until id3lib supports
2.4.0 tags. AFAIK that has been in development for over a year already.

Unfortunately, this five year old bug still exists in id3v2.  As much as we had hoped the world would have completed its transition to patent free media formats by now (go WEBM!),
sadly I was confronted with an mp3 file today and id3v2 couldn't read its the version 2.4 tag.

This is something of a problem since another tagging tool called "easytag" will automatically detect outdated tag formats and upgrade them for you. (Not a good feature to have on by
default in my opinion, but oh well.)

Given the longevity of this bug, I don't think upstream is handling this, so it seems like the solution is to either change the library id3v2 uses (libid3 to libid3tag) or deprecate
it in the package description for another command-line id3 editor. Personally, I'd go with deprecating id3v2. There look to be several alternatives already packaged in Debian. I
installed one at random called eyeD3 and it had no problem with the v2.4 tag.

I actually ported parts of id3v2 to libid3tag a while back (just out
of personal curiosity) and while libid3tag can't fully replace libid3
(IIRC it won't let you figure out whether you're dealing with a v1 or
a v2 tag - some features of the id3v2 tool need that, though) I should
be able to somehow hack basic, read-only v2.4 support into id3v2...

cheers

If an example of this is needed, try
http://daniel.holba.ch/mixes/2011-04-07.mp3

$ id3v2 -l 2011-04-07.mp3
2011-04-07.mp3: No ID3 tag

Gstreamer is fine with it, though:

$ gst-launch filesrc location=2011-04-07.mp3 ! id3demux ! fakesink -t
...
FOUND TAG      : found by element "id3demux0".
     ID3v2 frame: buffer of 25 bytes, type: application/x-gst-id3v2-txxx-frame, version=(int)4
                : buffer of 15 bytes, type: application/x-gst-id3v2-tdrl-frame, version=(int)4
                : buffer of 30 bytes, type: application/x-gst-id3v2-tdtg-frame, version=(int)4
...
           title: 2011-04-07 Mix
           genre: Drum'n'Bass
...

It appears that Buster's version of taglib:

 ii  libtag1v5:amd64         1.11.1+dfsg.1-0.3 amd64        audio meta-data library

now writes ID3v2.4 tags by default (and uses the new UTF-8 text encoding
too.) This means that any program that uses this library (lots of KDE
perhaps?) will make files that are not readable by id3v2. :(

Perhaps it's time to pension off id3v2?

Mike.

retitle 449186 libid3: Silently ignores unsupported ID3v2 version
reassign 309278 src:id3lib3.8.3
severity 309278 wishlist
thanks

I reconsidered: request for ID3v2.4 support is already requested by
#309278. Hence, I'm closing #449186.

Martin