[mythtv] Perl expertise wanted

[Joseph A. Caputo]

> -----Original Message-----
> From: mythtv-dev-bounces at snowman.net
> [mailto:mythtv-dev-bounces at snowman.net]On Behalf Of Chris Petersen
> Sent: Wednesday, July 09, 2003 11:54 AM
> To: Development of mythtv
> Cc: William Preston
> Subject: Re: [mythtv] Perl expertise wanted
>
>
> > I believe supporting both of these formats will cover all VBR files.
> > We could always fall back to the check-the-first-few-frames method if
> > neither header exists, although it would be much quicker to just
> > assume it's CBR if these headers are not present.
>
> I know from some experience that many LAME-encoded vbr files don't use
> the Xing frame, and show up as 32kbps in non-smart players.  Does
> mythmusic use id3lib/libid3?  Shouldn't this library already handle all
> this sort of stuff?

What exactly is the current status of length determination for VBR MP3
files?  I recently moved my music collection to a different drive, and
changed the mount point, which forced me to re-scan my music database.  When
the files were re-scanned, all of their times were 0:00 (I have all VBR MP3,
encoded with CDex on Windows).  I know there have been changes, but I didn't
think it was completely broken.  This leads me to 2 suggestions:

(1) For accurate VBR MP3 length determination, what if the initial time was
written into the database as NULL or 0:00, then when the file is first
played, it is scanned completely for an accurate time determination and the
correct time written to the database.

(2) There really was no reason for my collection to need re-scanning, as
only the mount point changed.  Since the top-level music directory is stored
in the database, why is it necessary to store the full path to each music
file?  Wouldn't it make more sense to store the path relative to the music
storage directory?

I don't have a development box ATM, or I'd submit a patch for at least (2),
and possibly (1).

-JAC