>
> > FhG faster than Xing? It seems strange.
>
> Not only faster, but better quality, in the limited tests I've done.
> Castanets is is very noticably distorted by Xing at 128kbps, but even in
> "Fast"
> mode FhG does well. It's not transparent even at "Highest" quality, but it's
> damned close (some barely noticable pre-echo and muffling on the "clacks").
>
> > I'll try to hear it in order to see if it's a low quality encoder or a
> good
> > one.
> > Could someone with an unix box and gtk have a look at it on castanets with
> > the frame analyser in order to see if they use some short and long blocks
> or
> > only long ones like Xing.
>
> I've uploaded my castanets test files to ftp://ftp.sulaco.org/incoming
> (just so nobody else needs to waste some of their 30 free tests :) I don't
> have MP3x to perform any frame analysis, though.
>
I took a quick look: they are using short blocks so it is definatly not
Xing. Also, the _hq and _fq output and the FhG v3.1 all have slightly
different encoder delays, making a direct comparision more difficult
since all the frames are out of sync by about 50 samples. So at
least this means that the _hq mode is not identical to FhG v3.1.
To really compare frame by frame, we would have to figure out the
exact differences and pad castanets.wav with the right number of zeros.
One difference between _hq and _fq: _fq does not use subblock gains
and _hq does. (LAME tries to use subblock gains with the -Y option)
Mark
> -- Mat.
>
>
>
> --
> MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
>
>
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
