Re: [Bug-gnupod] DESC field in iTunesDB

[H. Langos]

Hi Richard,

On Wed, May 06, 2009 at 08:57:23PM +0200, Richard van den Berg wrote:
> When I first started ripping all my CDs I made the decision that the ID3  
> genre field was too limiting, so I split my collection into different  
> directories named after genres and/or source of the CDs  
> (wife/brother/daughter). I have generated several m3u playlists using  
> these directory names. Now that I switched to the iPod, this information  
> is no longer available to me. So I started to look for a field in the  
> iTunesDB that I could use for that purpose. The FDESC and DESC fields  
> fit rather nicely. FDESC has a width of 15 characters which is enough  
> for me today, but could be limiting in the future. So I patched  
> FileMagic.pm to place the full pathname of the mp3 into the DESC field.

The "fdesc" attribute is set by gnupod_add (or rather by the different
format handlers in FileMagic.pm ) to something that describes the file 
format.

> I realize that this is a patch for personal purposes, but looking at  
> what the DESC field is used for now I wonder if it has a real purpose:

It has :-)

The "desc" attribute is left alone by tunes2pod so if you go from iTunes to 
gnupod you should not lose any information.
When you add file with gnupod_add however, the desc attribute is filled with 
as much useful information as possible. 

That information is usually taken from the "comment" and "unsynchronized 
lyrics" tags. Unfortunately itunes also uses the comment tag to store its 
normalization information. Thats why this is explicitly stripped from the 
desc field. (It will however be preserved in the "comment" attribute.)

> rh{desc}       = __merge_strings({joinby => " ", wspace => "norm", case  
> => "ignore"},($hs->{USLT} || $hs->{ULT}),($nonitunescomment ||  
> $h->{COMMENT}));
>
> It joins the USLT or ULT field (which are used for lyrics) with the  
> $nonitunescomment (which is the ID3v2 COMM field with the iTun* fields  
> stripped) or ID3v1 comment. The comments are already stored in the  
> iTunesDB in the COMMENT field. Storing lyrics doesn't seem to make much  
> sense since the field is only 40 characters wide.

I wasn't aware of a limitation to 40 characters. This seems a rather
arbitrary limit imposed on the user by itunes. It doesn't even resemble the
original id3v1 comment tag limit as that was 30 characters.
( http://www.id3.org/ID3v1 )

I assure you that the desc attribute can hold a lot more information and 
that information is available to you on the ipod. I havn't tested the 
limits yet but several kb of text in the desc attribute seem to be no 
problem.

In the wild I've seen the ULT/USLT tag used a lot by podcast producers to store
show notes. DJ River (www.DJRiver.com) uses it to store the tracklist of his
remixes and on occasion (rather rarely) I have seen it used for lyrics.

Personally I see it most used for the show notes of podcasts. Transfering
the content to the "desc" attriute allows you to read those notes while 
listening to the podcast.

Here's how its done: Normally when you hit the center button while listening 
to music, you cycle through  "volume - position - rating - shuffle"
but when listening to podcasts you cycle through
"volume - position - rating - description".

The description is taken from the "desc" attribute. Try this podcast if 
you want to see for yourself:

gnupod_addsong.pl -p "The Naked Scientists Naked Science Radio Show" 
--playlist-is-podcast --podcast-artwork --podcast-files-limit=2 
"http://www.thenakedscientists.com/naked_scientists_podcast.xml";

BTW: When adding podcasts with gnupod_add, the information from the
podcast episode description (the one in the podcast's XML file) is also
merged with the information contained in the file tags.

> Maybe my patch is not so bad to be applied for everyone? (If so, the  
> nonitunescomment code can also be discarded.)

Nope. Took a lot of work to get that stuff in there in the first place ;-)

Of course you can patch your copy of gnupod any way you like, but I guess 
the current arangement is more useful to the majority.

If you need to get the information that currently is encoded in the file's
path into the file itself I would recommend using a comment tag. In id3v2
you can have as many comment tags as you wish and you can give comments a
title as well as a content. iTunes does the same as you can see in this 
sample:

          'COMM' => [
                      {
                        'iTunes_CDDB_TrackNumber' => '3^@'
                      },
                      {
                        'iTunes_CDDB_1' => 
'xxxxxxxx+xxxxxxx+xx+xxx+xxxxx+xxxxx+xxxxx+xxxxx+xxxxxx+xxxxxx+xxxxxx+xxxxxx+xxxxxx+xxxxxx+xxxxxx+xxxxxx^@'
                      },
                      {
                        'iTunNORM' => ' 00000000 00000000 00000000 00000000 
00000000 00000000 00000000 00000000 00000000 00000000^@'
                      }
                    ],

So in your case you could add a comment for your genre clasification as 
well as for the source:

          'COMM' => [
                      {
                        'iTunes_CDDB_TrackNumber' => '3^@'
                      },
                      {
                        'iTunes_CDDB_1' => 
'xxxxxxxx+xxxxxxx+xx+xxx+xxxxx+xxxxx+xxxxx+xxxxx+xxxxxx+xxxxxx+xxxxxx+xxxxxx+xxxxxx+xxxxxx+xxxxxx+xxxxxx^@'
                      },
                      {
                        'iTunNORM' => ' 00000000 00000000 00000000 00000000 
00000000 00000000 00000000 00000000 00000000 00000000^@'
                      },
                      {
                        'rvdb_genre' => 'something'
                      },
                      {
                        'rvdb_source' => 'uncle bob'
                      }
                    ],

If you like to do it with a perl tool I'd recommend MP3-Tag at
http://search.cpan.org/dist/MP3-Tag/ . It contains a tool 
named "mp3info2" that should be able to do that job. But don't 
take my word for it. Maybe it will eat your music collection 
instead :-)

Cheers
-henrik