[Bug-gnupod] FileMagic.pm Bug

[chub]

Hello.

    Firstly, I'd like to thank all those who work on GNUpod.  Although I
have
all the requirements to use my new iPod (got it yesterday =) according to
Apple (iBook with iTunes installed), I don't like the DRM source that would
restrict the syncing of my own iPod.

    However, I did add my whole library to the iPod yesterday, and it worked
very well, but that made me realize what MESS my library is in.  (I'll have
to go about pruning my collection of awkwardly normalized files, and putting
in ID3 tags).  Today, after I reset my iPod and made it a Windows iPod, I
tried using GNUpod to create my library, but unfortunately, upon calling
mktunes.pl, I got the following error:

---
$ gnupod_unmount -x GNUtunesDB_orig
mktunes.pl Version 0.93 (C) 2002-2003 Adrian Ulrich
> Parsing XML and creating FileDB

not well-formed (invalid token) at line 19, column 98, byte 5774 at
/usr/lib/perl5/XML/Parser.pm line 187
---

(I symlinked everything to gnupod_<action>, so I don't have to remember
anything. The trailing .pl isn't required anyway; you have the #! in the
first line. here, alias gnupod_unmount=mktunes.pl)

    It turned out to be a malformed comment field with a ^A character (as
indicated in emacs), but Winamp and iTunes report that no comments are in
the ID3v1 nor ID3v2 fields.  Manually deleting the character would allow
mktunes.pl to successfully complete.

    The problem lies in FileMagic.pm, line 151, when the comment is
extracted from the MP3::Info module, which is:      $rh{comment} =
getutf8($hs->{COMM} || $h->{COMMENT} || "");
    It looks okay, but there should be no reason that $rh{comment} should
have any data if both comment fields are empty.  Reading the documentation
does not explain why this occurs.  If I remove the ID3v2 variable from the
logical chain ($hs->{COMM}), then the script works correctly (but no ID3v2
comments are caught).

    However, MP3::Info says that if the second argument to get_mp3tag() is
not supplied, or false, "the ID3v1 tag is read if present, and then, if
present, the ID3v2 tag information will override any existing ID3v1 tag
info." (ref:
http://search.cpan.org/~cnandor/MP3-Info-1.02/Info.pm#get_mp3tag).  So I
tried to get rid of your double get_mp3tag call and logical ORs that give
preference to the ID3v2 data.  There's probably a good reason why it's done
manually, but just in case there isn't, here is my very
incomplete hack to make MP3::Info do the work (patch):

---
--- FileMagic.pm2       2003-12-26 12:25:27.000000000 -0500
+++ FileMagic.pm2_edit  2003-12-26 12:49:48.000000000 -0500
@@ -130,8 +130,8 @@
  $rh{srate}    = int($h->{FREQUENCY}*1000);
  $rh{time}     = int($h->{SECS}*1000);
  $rh{fdesc}    = "MPEG ${$h}{VERSION} layer ${$h}{LAYER} file";
- my $h = MP3::Info::get_mp3tag($file,1);  #Get the IDv1 tag
- my $hs = MP3::Info::get_mp3tag($file, 2,1); #Get the IDv2 tag
+ my $h = MP3::Info::get_mp3tag($file,0);  #Get the tags, and prefer IDv2
+ my $hs = ();


 #IDv2 is stronger than IDv1..
---

    I realize there's a problem here, because now get_mp3tag() might not
read the extra fields that are present in ID3v2 tags (like the composer), or
how the module handles the different keys in the hashes (COMM or COM or
COMMENT, depending on the tag type and version).

    I hope this email hasn't been too convoluted.  If anything needs
clarification, please feel free to reply.  Please CC me the reply, since I
am not on the mailing list.
If you receive an "error on delivery" message, please re-send, since my mail
server's
internet connection is very flakey and might be unable to receive mail at
all times (this will hopefully be cleared up when all the ISP's techs wake
up from vacation).

    Thanks again!

    (Attached is a GNUtunesDB with the problematic records.)

Brian Chu
PS: In the GNUpod Manual, gnupod.html, it says that bugs should be reported
to address@hidden, while the mail page says to nongnu.org.  gnu.org
replied to me with a "550 unknown user".

GNUtunesDB_orig
Description: Binary data