INTERACT FORUM

More => Old Versions => Media Center 16 (Development Ended) => Topic started by: bspisak on March 24, 2011, 11:51:18 pm

Title: ID3v2.4 UTF-16 Tags Appear Munged
Post by: bspisak on March 24, 2011, 11:51:18 pm

I have an MP3 that uses ID3v2.4 and UTF-16 w/ BOM (0x01FEFF00) but the tags are displayed as garbage in MC16.0.49.

The tags are fine in other apps that support ID3v2.4, i.e., iTunes, MP3Diags, Mp3Tag, TagScanner.

Title: Re: ID3v2.4 UTF-16 Tags Appear Munged
Post by: bspisak on March 30, 2011, 01:53:05 am

Here's what the tags look like in MC:

(http://i831.photobucket.com/albums/zz239/bspisak/Media%20Center/v24munge1.jpg)

Here's what iTunes decodes them as:

(http://i831.photobucket.com/albums/zz239/bspisak/Media%20Center/v24munge3.jpg)

And here's the hex dump:

(http://i831.photobucket.com/albums/zz239/bspisak/Media%20Center/v24munge2.jpg)
 
And here's what ID3V2.4 (http://www.id3.org/id3v2.4.0-structure) says about it:

   Frames that allow different types of text encoding contains a text
   encoding description byte. Possible encodings:

     $00   ISO-8859-1 [ISO-8859-1]. Terminated with $00.
     $01   UTF-16 [UTF-16] encoded Unicode [UNICODE] with BOM. All
           strings in the same frame SHALL have the same byteorder.
           Terminated with $00 00.
     $02   UTF-16BE [UTF-16] encoded Unicode [UNICODE] without BOM.
           Terminated with $00 00.
     $03   UTF-8 [UTF-8] encoded Unicode [UNICODE]. Terminated with $00.

   Strings dependent on encoding are represented in frame descriptions
   as <text string according to encoding>, or <full text string
   according to encoding> if newlines are allowed. Any empty strings of
   type $01 which are NULL-terminated may have the Unicode BOM followed
   by a Unicode NULL ($FF FE 00 00 or $FE FF 00 00).

ID3V2.3 (http://www.id3.org/id3v2.3.0) also says:

  All Unicode strings use 16-bit unicode 2.0 (ISO/IEC 10646-1:1993, UCS-2).
  Unicode strings must begin with the Unicode BOM ($FF FE or $FE FF) to
  identify the byte order.

Title: Re: ID3v2.4 UTF-16 Tags Appear Munged
Post by: Alex B on March 30, 2011, 11:00:12 am

In my experience MC would display ID3v2.4 UTF-8 tags correctly. Since the combination of ID3v2.4 and UTF-16 is not very common it may not be supported. (To JRiver: does the BOM thing affect this?)

Quote

I have an MP3 that uses ID3v2.4 and UTF-16 w/ BOM (0x01FEFF00)

If you have only one or a few such files and you don't specifically need to have the tags in the current format, a workaround would be to save them in some other format. Mp3tag (http://www.mp3tag.de/en) can do this. It provides three different ID3v2 tagging options:

- ID3v2.3 ISO-8859-1
- ID3v2.3 UTF-16  (it doesn't say anything about BOM)
- ID3v2.4 UTF-8

These are also the commonly used formats and in my experience MC supports them.

Title: Re: ID3v2.4 UTF-16 Tags Appear Munged
Post by: bspisak on March 30, 2011, 11:32:10 am

Quote from: Alex B on March 30, 2011, 11:00:12 am

Since the combination of ID3v2.4 and UTF-16 is not very common it may not be supported.

I would agree that this isn't too common and probably not much of an issue, but since this forum seems to be the only way to file a bug report, I wanted to post it.

This particular tag was written by Mp3splt (http://mp3splt.sourceforge.net/mp3splt_page/home.php). The original tag was ID3V2.3/ISO and I've already asked the author of Mp3splt why he changes the version and format since it's not widely adopted. But, ID3V2.4/UTF-16 does seem to be supported by other major apps like iTunes, so I just wanted to make sure JRiver got the bug report (even if it is low priority.)

Thanks.

Title: Re: ID3v2.4 UTF-16 Tags Appear Munged
Post by: Matt on March 30, 2011, 02:02:07 pm

Please email a sample file that won't parse to matt at jriver dot com.

Thanks.

Title: Re: ID3v2.4 UTF-16 Tags Appear Munged
Post by: Matt on March 30, 2011, 04:42:04 pm

In a coming build:
Fixed: ID3v2 tags with big-endian UTF-16 values were not being read correctly.

Thanks.