I was reading slashdot, and I noticed an article stating that the BladeEnc website has
been forced to take its
binaries offline. (Their download site is http://bladeenc.mp3.no/skeleton/DL.html)
I know that binaries vs source code of free mp3 encoders has been discussed here
before, so I was
w
> From: "Ampex" <[EMAIL PROTECTED]>
>
> anyone running mp3enc 3.1 under windows, does the -l3wav parameter crash
it
> every time?
Just tried it here (Win2k, Celeron 400), no problems.
-- Mat.
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
anyone running mp3enc 3.1 under windows, does the -l3wav parameter crash it
every time?
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
In the big (too big?) l3psycho_anal function, in the "determin final block
type" section, is there a way to know if the frame is m/s or stereo? I mean,
is there something like blocktype[chn] to know it?
Regards,
--
Gabriel Bouvigne - France
[EMAIL PROTECTED]
icq: 12138873
MP3' Tech: www.mp3-t
I tried to figure out a problem I had when encoding a T.O.P. track
("What is hip", a funk song recorded 1973 - so just analog effects on
the track).
When using ear phones I found some subtile flanging effects (there are
very sharp attacks from the brass section and there is much bass and
drums [h
Where can I get this MMX enabled LAME code?
Tilman
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
> > Perhaps the makefile was modified when I decompressed it or somewhen
else.
> > But Make tells me this "separator" error which disappears when I insert
> > tabs. And I am definately sure I use the cygWin "Make" because the djgpp
> > make tells me a completely other bunch of error messages.
>
>
I am in the process of the same. I read some interesting web pages where
guys did all this experimentation...some of it quite scientific...and some
of it very subjective. This is what I came down to in my own decision (as
of now):
1 - 128bit CBR is *NOT* good enough. You'll get about 1MB/min
this is just a little defect: in live recording cd,
where there is no silence between tracks, mp3enc3.1
adds a little silence at the end of each .mp3:
the pauses are noticeable even with winamp using
the continuous output plugin!
Is there an easy way to prevent this?
EAC "compression offset" feat
> Perhaps the makefile was modified when I decompressed it or somewhen else.
> But Make tells me this "separator" error which disappears when I insert
> tabs. And I am definately sure I use the cygWin "Make" because the djgpp
> make tells me a completely other bunch of error messages.
Now I got d
In the last episode (Jun 01), Tilman Sauerbeck said:
> > The Makefile should be correct as-is; you shouldn't have to fiddle with
> > tabs. Try editing your path to only include the cygwin binary
> > directory and run make again.
>
> Perhaps the makefile was modified when I decompressed it or som
> The Makefile should be correct as-is; you shouldn't have to fiddle with
> tabs. Try editing your path to only include the cygwin binary
> directory and run make again.
Perhaps the makefile was modified when I decompressed it or somewhen else.
But Make tells me this "separator" error which disa
> > Extraneous text after "ifeq" directive (this message appears for every
> > "ifeq" in Makefile)
> > and
> > Missing separator (line 237)
> I don't know what to say; I downloaded 3.70 myself and compiled it
> without errors. Be sure that the "make" you're running is cygnus'
> make, and not djg
Takehiro,
coff is the object format for DJGPP
these are the valid outputs for the nasm version I am using (0.98):
valid output formats for -f are (`*' denotes default):
* bin flat-form binary files (e.g. DOS .COM, .SYS)
aout Linux a.out object files
aoutb NetBSD/FreeBSD
> "J" == Joshua Bahnsen <[EMAIL PROTECTED]> writes:
J> I just realized that MMX_choose_table was never defined when I
J> compiled with DJGPP. Now this is what I get:
> nasm -f coff -i i386/ i386/choose_table.nas -o i386/choose_table.o
sorry, I don't have windows environment, but I h
Ross Levis wrote:
> and any ideas when -Y will become default. Does it still need some > testing or
>tuning?
I tried -Y with lame 3.83, and on some sounds, it does
make audible artifacts, so probably -Y still needs
testing.
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Mark wrote:
>There are now 3 VBR modes:
>1. the current version (default)
>2. -Y enables the true noise shaping VBR mode. It should give
(...)
>I'm hoping #2 will replace #1 soon. But I still dont trust either
>of these algorithms. Does anyone have examples of a 128kbs(average) VBR
>sounding
> There are now 3 VBR modes:
>
> 1. the current version (default)
>
> 2. -Y enables the true noise shaping VBR mode. It should give
>similar results to #1, but be much faster. Faster because it
>does not use the outer_loop() iterations scheme, but computes
>each scalefactor directly
Mark Taylor wrote:
> -Y enables the true noise shaping VBR mode. It should give
>similar results to #1, but be much faster.
Not similar results at all. -Y is producing much larger files with less spread across
the
bitrates. A graph of the -Y results doesn't look natural in my opinion wit
> What version of cygwin, what version of Lame, and what errors do you
> get? I just compiled the CVS version with cygwin 1.1 with no errors at
> all.
okay, thanks. I'll check my installation of CygWin (I'm new to this, perhaps
I didn't setup CygWin correctly).
Tilman
--
MP3 ENCODER mailing li
20 matches
Mail list logo
