[gpodder-devel] Wrong length again
- From: nikosapi at gmail.com (nikosapi)
- Date: Wed, 8 Aug 2007 19:49:09 -0400
Hey Thomas,
On August 7, 2007 14:27:32 Thomas Perl wrote:
> Hello, Nick and G?tz!
>
> On Mon, 2007-08-06 at 22:59 -0400, nikosapi wrote:
> > On August 6, 2007 15:01:17 Thomas Perl wrote:
> > > On Mon, 2007-08-06 at 20:30 +0200, G?tz Waschk wrote:
> > > detection have previously been because of enhanced AAC files. Does
> > > libmad always provide the correct length for MP3 files? If so, maybe
> > > using libmad for MP3 files and mplayer for everything else would fix
> > > your problem?
> >
> > Ok, here's the promissed patch :)
> >
> > If mplayer is available, it will use it for all media files. If the file
> > is an mp3 and pymad is installed it will get the length reported by pymad
> > and compare it to the length from mplayer and use the longer of the two
> > (this works great btw). And of course, worst case eyed3 is still
> > available if all else fails.
>
> I've revisited your patch for the latest SVN trunk head (I've done some
> restructuring of the code during the weekend, because I want to clean up
> the codebase a bit to get ready for the "gPodder API" ;).
That's pretty neat ;)
> Maybe we should try out all possible ways to detect the file length
> (including eyed3) and use the maximum reported time? Or just leave it as it
> is currently (default to mplayer, if pymad is here, try and use it if
> length is bigger, and if none of the above is available/working, try
> eyed3). What do you think?
I'd like to propose that you ignore that patch because of a few reasons...
1) I've been using the mplayer/pymad combo for 2 days now and it seems pymad
isn't all that great at detecting file lengths. On two occasions it has
reported that files are infact much longer than they really are (by hours).
2) Mplayer, IMO is the best media player out there and if it can't find the
proper file length there isn't much else that will, so there's no point
double checking each mp3 with both mplayer and pymad.
3) A far simpler solution would be to just add 5 to 10 seconds extra to the
file length just to be sure we're not cutting the file short. It doesn't hurt
the player (it stops at EOF) and on a normal podcast it wouldn't even be
noticeable that the slider is a bit longer (if it were a song, it would be a
different story).
> > Oh and btw, about Cory Doctorow's podcasts. The mp3s are borked, all the
> > media players I tried them with gave different play times. Pymad gets
> > close to the right time but is off by ~10sec. Email Cory and tell him to
> > use a better mp3 encoder (he still reads all his emails right?).
>
> I think we're way too cool to support even broken podcasts, hehe :) I'm
> glad we have motivated contributors and bug reporters that help us make
> gPodder so great in this respect (file length detection is quite
> sophisticated already, and as we saw, "valid" MP3 files are not always
> the reality in the cruel, dark podcast world :).
I fully agree, the podcaster should get his act together. I tested the file
with the mp3val tool and it did find errors, here's a bit of the output:
WARNING: (offset 0x6dbda): MPEG stream error, resynchronized successfully
WARNING: Wrong number of MPEG data bytes specified in Xing header (17958326
instead of 17958144)
That said, I have been listening to that podcast and I must say, the book he's
reading is very good :)
>
> Thomas
nick
Other related posts:
