> From: Mathew Hendry <[EMAIL PROTECTED]>
> > From: Mark Taylor <[EMAIL PROTECTED]>
> > one is wall clock time, from the times() system call, and the other is
> > CPU time of LAME, from the clock() system call.  All systems seem to
> > have clock(), but not everyone has times().  On systems which do not
> > have times() (HAVETIMES not defined during compilation), LAME just
> > uses clock() instead and the two values will be identical.  Or if
> > LAME is the only thing running, the wall clock and CPU time should
> > be pretty close.
> >
> > That other problem is probably some bug in the % (mod) functions
> > in timestatus().  Hopefully it will bother someone enough that they
> > will post a patch :-)
>
> I've been using the attached for a while, but it uses ANSI
time()/difftime()
> instead of the times() stuff (which I don't have). Maybe someone else can
> add the necessary tweaks to ts_real_time(). Not sure if the modulo thing
is
> fixed, but if not, the bug should at least be a bit more readable now...
;)

Forgot to mention, the #include <windows.h> stuff has to go above the other
inclusions, or the Windows FLOAT typedef will collide with the #define in
LAME.

-- Mat.


--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )

Reply via email to