>
> + maybe a MPEG2 vbr should get a Xing header?
> at least optional via a switch?
>
Can you get Xing to generate a MPEG2 VBR file? I tried once and
it aways produced fixed bitrate output files. The problem is the
Xing header is embedded in a 64kbs frame, but at MPEG2 samplerates,
>
> Hi all,
> find attached a small tweak to l3psycho_energy (just cut and paste into
> l3psy.c). a 30% improvement in this routine.
> all i did was re-order the checks for chn type.
Thanks, that will be in 3.31, along with the BladeDLL fix from Albert.
I will put 3.31 on the
>
> > 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
28.09.1999 at 13:54:12 you wrote to me:
GB> Btw, according to the gogo page, Lame can be twice as fast as it
GB> is using asm.
But then it will loose the portability at least among the non-ix86
systems.
---
Sergey A. Maslyakov
2:5030/1024@fidonet
--
MP3 ENCODER mailing list ( http://geek.r
From: Gabriel Bouvigne <[EMAIL PROTECTED]>
> 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" qu
FhG faster than Xing? It seems strange.
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.
Hello Gabriel,
>> Thanks for the tip. With -march=pentiumpro, the speed gap is
>> closed to about 1%. BTW, I don't notice any difference in speed
>> with the /G6 (PPro optimization) flag to MSVC compared to the
>> default "blended" optimization.
GB> According to VC++ documentation, PPro i
>i noticed between 3.29 and 3.30 the order of gpk_redraw's parameters
>were swapped, but the calls to it (in gpkplotting.c) were unchanged,
>which lead to compiler warnings & coredumps when I tried using -g
>option. Swapping them around seemed to fix it here (on OS/2 using pgcc
>2.91.66).
Oooops
Hi all,
find attached a small tweak to l3psycho_energy (just cut and paste into
l3psy.c). a 30% improvement in this routine.
all i did was re-order the checks for chn type.
A few ideas/things about this routine
- when does chn==2 or chn==3? I guess from the code that it'
On Tue, 28 Sep 1999, Sergey A. Maslyakov wrote:
> By the way, it would be a great idea to make LAME being able to run
> on all processors of SMP system
If you are encoding multiple tracks at a time, you can call multiple
instances of LAME (this is what Grip does). Trying to parallelize LAME
On 28-Sep-99 Scott Manley wrote:
> WEll... dual channel stereo modes might be trivially paralelisable
> Dunno about anything else.
> Scott Manley (aka Szyzyg) /-- _@/ Mail -\
>> By the way, it would be a great idea to make LAME being able to run
>> on al
> From: "Paul Hartman" <[EMAIL PROTECTED]>
> Date: Tue, 28 Sep 1999 02:03:57 -0500 (CDT)
>
> i noticed between 3.29 and 3.30 the order of gpk_redraw's parameters
> were swapped, but the calls to it (in gpkplotting.c) were unchanged,
> which lead to compiler warnings & coredumps when I tried usi
WEll... dual channel stereo modes might be trivially paralelisable
Dunno about anything else.
Scott Manley (aka Szyzyg) /-- _@/ Mail -\
___ _ _ __ __ _ | Armagh Observatory |
/ __| __ ___| |_| |_ | \/ |__ _ _ _ | |___ _
> "Fast" is suspiciously fast - Xing fast you might say.
Faster than xing on my box.
Encoding my standard 150 second file takes less than 60 seconds with nero (fast
mode).
Xing(linux) takes abou 110 seconds
(p166 RH6.0)
later
mike
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
hi
>the site talks about the "brandnew and ultrafast MP3-Encoder of Fraunhofer".
>but neither fraunhofer or opticom mention any updates to the encoding engine.
>Probably using the same old codec that everyone else on windows uses.
the old codec sometimes produced obvious flanging artifacts (JS
From: Jake Hamby [mailto:[EMAIL PROTECTED]]
> results. As for speed, the "fast" setting is very fast (4
> sec. for a 30
> sec. clip), "medium" is slower then LAME (23 sec. vs. <7 sec.
> for LAME), and
> "highest" is very slow (didn't time it, but about 2 minutes).
"Fast" is suspiciously fast -
16 matches
Mail list logo
