Hi,
I found a bug in the long block pre-echo control code.
if (gfc-blocktype_old[chn] == SHORT_TYPE )
thr[b] = ecb; /* Min(ecb, rpelev*gfc-nb_1[chn][b]); */
else
thr[b] = Min(ecb, Min(rpelev*gfc-nb_1[chn][b],rpelev2*gfc-nb_2[chn][b])
);
In the loop of chn, chn goes up to 3, but the
Hi !
I'v came across problem in toolame. It segfaults on me on some files. One
example is at ftp://mail.slon.net/pub/final.wav.bz2 but it is 8Mb bzip2
file.
I looked at the code and it hapens in:
psycho_I.c
void subsampling
in the first loop.
While loop checks for i!=LAST, bu it happens that
On Wed, 4 Oct 2000, Stefan Bellon wrote:
Am I wrong or has the file quantize-pvt.c changed to quantize_pvt.c
(and the header file as well)? Why was this done?
As on RISC OS there's no GNU make available yet (but a port will be
release hopefully soon!), I can't use the generic Makefile but
On Wed, 4 Oct 2000, Naoki Shibata wrote:
I found a bug in the long block pre-echo control code.
This code should be fixed like this.
if (gfc-blocktype_old[gfp-mode == MPG_MD_JOINT_STEREO ? 0 : chn] == SHORT_TYPE )
Naoki,
Did this affect quality? I just folded this change back into my
The RAW's are different sizes, too:
- original
14,276,640t4.raw
- encoded then decoded back (cbr and vbr)
14,275,772t4_b256_ms_h.raw
14,275,772t4_V1_b128_mj_q1_t.raw
The original .wav is reported to be 0:00.005 longer (1:20.933 vs. 1:20.928).
I don't really mind the 1/200
::
:: 3. Creating a dozen or so odd types, all synonymous with 'int'
:: is a great idea. But I saw a few 'int's left. I think
:: we need to replace these with more new types.
::
When you were a physicist, you were a cgs advocate and a SI enemy, right?
--
Mit freundlichen Grüßen
Frank
::
:: ISO spec says the maximum should be 8191. But as part of huffman
:: decoding, you sometimes add 15 to the result, yielding values as large
:: as 8206. Right now, LAME (and the ISO dist10 code) will make use of
:: the full range: values up to 8206.
::
:: The question is, should
Just thought I'd say my thoughts on the different parameter setting function
proposals we've had so far...
Individual functions for each parameter:
Pros:
- None. ;)
Cons:
- Litters the API with "thousands" of functions.
- If the parameter's type changes, the API has to change.
- If a
2. I dont think declaring the sample rate as 'long double' is enough. We
need to add a portable, object oriented arbritrary precision floating
point library to LAME. The sample rate should be a default of
128 digits, but the user can increase this with suitable
options.
Mathematican:
fft routines are wrongly prototyped:
void fft_long ( lame_internal_flags* gfc, FLOAT x_real [BLKSIZE ], int, sample_t
** );
void fft_short ( lame_internal_flags* gfc, FLOAT x_real [3] [BLKSIZE_s], int, sample_t
** );
void init_fft ( lame_internal_flags* gfc );
Right is:
void
Some remarks about the ATHformula.
The result are differing really a lot from my experiments.
The difference is 10 dB and more at =12 kHz.
For very young people the difference may be larger.
Examples:
Frequency Formula Experiment Difference
[kHz] [dB] [dB][dB]
1
Mark Powell schrieb am Mit, 04 Okt 2000:
On Wed, 4 Oct 2000, Naoki Shibata wrote:
I found a bug in the long block pre-echo control code.
This code should be fixed like this.
if (gfc-blocktype_old[gfp-mode == MPG_MD_JOINT_STEREO ? 0 : chn] == SHORT_TYPE )
Naoki,
Did this
Sigbjørn Skjæret schrieb am Mit, 04 Okt 2000:
Just thought I'd say my thoughts on the different parameter setting function
proposals we've had so far...
Individual functions for each parameter:
Pros:
- None. ;)
:-) compiler provides type check
:-) direct check for
Mark Powell schrieb am Mon, 02 Okt 2000:
On Fri, 29 Sep 2000, Robert Hegemann wrote:
does someone know any sample where a VBR encoded MP3 with -q1
gives a better sounding MP3 compared to a same sized VBR with -q2 ?
From your recent postings I'm detecting that you think -q1 can only
On Wed, Oct 04, 2000 at 09:42:51PM +0100, Sigbjørn Skjæret wrote:
Just thought I'd say my thoughts on the different parameter setting function
proposals we've had so far...
Individual functions for each parameter:
Pros:
- None. ;)
Cons:
- Litters the API with "thousands" of
Hello,
new alpha winamp plugin was released
http://www.landoleet.org/~deadbeef/in_mp3_260_alpha13.zip
http://www.chat.ru/~dkutsanov/in_mp3_260_alpha13.zip
Changes:
* [a13] 8191 bugfix.
8)))
Best regards,
Dmitry mail to: [EMAIL PROTECTED]
--
MP3 ENCODER
Am I wrong or has the file quantize-pvt.c changed to quantize_pvt.c
(and the header file as well)? Why was this done?
As Mark said, that is because Borland C could not treat the "-" in
filename.
Wait 'til you see v3.88. You've got a big surprise coming to you :)
I agree it probably wrong to
I have looked at the Ogg Vorbis encoder (B2) and I have a couple of points to make
:
1] I think it is appalling that there is such little interest in this - it is a
viable alternative to MP3 - and
doesn't have the patent restrictions that our friends at Franhoffer put on it.
Sure, LAME is
Hello... I've been lurking on this list for awhile now and I've really started to
become interested in some of the more advanced aspects of lame such as the
experimental modes and stuff. Basically what I am trying to get out of lame is the
highest possible sound quality short of using 320kbps
Note:
Both methods (thousands of functions and thousands of tags) are equivalent:
* use one function ( lame_ioctl() ) and thousands of constants
to tell this function what functionality is actually requested
* use thousands of functions (lame_x () ) to execute a
Hello... I've been lurking on this list for awhile now and I've
really started to become interested in some of the more advanced
aspects of lame such as the experimental modes and stuff. Basically
what I am trying to get out of lame is the highest possible sound
quality short of using
21 matches
Mail list logo
