Re: [Bug-gnupod] DESC field in iTunesDB

[Richard van den Berg]

On 5/7/09 1:50 PM, H. Langos wrote:
> 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 )
>
>   

My bad. I took the width value of %FILEATTRDEF in iTunesDB.pm to mean 
the width of the field in the iTunesDB. It turns out it is only used as 
display width in FindHelper.pm. The mk_mhod() / mk_mhit() functions that 
actually convert the fields to iTunesDB format do not seem to impose any 
size limit.

> 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.
>   

I've never used podcasts, but I see how that could be useful. Personally 
I haven't been able to read the "desc" field I set on my mp3s using 
gnupod_addsong.pl + mktunes.pl either on my 5G iPod or using the iTunes 
GUI. I can use it in smart playlists though. Googling shows that my iPod 
should be able to display lyrics, but I guess the lyrics_flag needs to 
be set first. Gnupod doesn't seem to do that for mp3s (which I guess is 
a bug).

> work to get that stuff in there in the first place ;-)
>   

I figured as much. I like the way it is done, I just didn't understand 
why it was there. Info for the mp3 podcasts makes sense.

> 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.

I thought about that, and mass tagging my collection is not a big deal, 
but I'll have to redo it every time I add something, or move files from 
one directory to another. Hacking gnupod is much easier, and I won't 
have to change my habits. :-) I'll see if keeping a customized version 
of gnupod is better than changing the way I tag/select my mp3 collection.

Cheers,

Richard