I am planning XML like interface of LAME parameter handling.
I will mail or commit the base code. It will be completely easy and
feature extendable.
---
[EMAIL PROTECTED] // may the source be with you!
>> Both methods (thousands of functions and thousands of tags) are
>> equivalent:
>
> 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
>This is a good idea. Some comments (Frank: not all of these are serious:-)
I am serious :)
> 5. All developers should be required to take 200 hours of UML training
> before working on any more code.
6. Learn more about CVS, especially about making your own branch.
---
[EMAIL PROTECTED] // may
nd the library name
should not be lame_XXX
any ideas ?
---
Takehiro TOMINAGA // may the source be with you!
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
of encoded frames. I don't see a problem here.
client needs to know mp3 header structure, CRC calculation method, and
so on.
That's not elegant, I think.
---
Takehiro TOMINAGA // may the source be with you!
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
, VBR tag is so popular and maybe a lot of frontend want to write it.
Such a common needed function should be a part of library, I think.
---
Takehiro TOMINAGA
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
he version # of gtk or
J> something. So then in the makefile HAVEGTK is defined even
J> though I don't have it...
Ok, now it is fixed.
---
Takehiro TOMINAGA // may the source be with you!
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
I think we should use /usr/local.
M> I was thinking we should make a 'mp3x' directory, and put all
M> the mp3 frame analysis code in there (and remove the 'lame -g' option)
agree.
M> The frame analyzer is not of general interest - it is just a
M>
whole source.
Regards,
---
Takehiro TOMINAGA // may the source be with you!
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
--enable-gtkanalyzer, but I have never tested
them.
4)
HAVEVORBIS things are completely not tested yet.
5)
timestatus things are also moved to frontend.
6)
I think file i/o things(VbrTag, id3tag, etc) needs more modularization
work.
---
Takehiro TOMINAGA // may the source be with you!
--
>>>>> "G" == Gabriel Bouvigne <[EMAIL PROTECTED]> writes:
G> This is usually done via the cpuid instruction. I just checked
G> the nasm manual, and this instruction is supported by nasm.
and GOGO uses this to find out the CPU type.
---
Takehiro T
> "M" == Mark Powell <[EMAIL PROTECTED]> writes:
M> BTW The gcc 2.95.2 options are perfectly valid for FreeBSD as
M> well as Linux. Obviously :) Can they be copied into the FBSD
M> section too?
silly thing. you had better detect CPU/Compiler by configure and
output the option to
> "M" == Mark Powell <[EMAIL PROTECTED]> writes:
M> How did you get the Linux version to assemble the MMX code?
M> I've had no luck with GNU as v2.10.0 under FreeBSD. I'm
M> obviously missing something?
you are missing NASM.
---
[EMAIL PROTECTED] // may the source be with you!
-
>>>>> "G" == Gabriel Bouvigne <[EMAIL PROTECTED]> writes:
G> With VC6 I got:
G> warning C4307: '*' : integral constant overflow
Sun's CC(Workshop 4.2) on Solaris 2.6 says same warning, but the
binary runs fine.
---
Takehiro TO
_flags, even if the client will not care
R> about the new entry.
Yes, That is the most heavy problem. even worse, changing compiler
or compiler option will make it require to recompile every client.
R> The client shouldn't know about internal data structures. So,
R> d
et to get something done.
>>
M> good point! So Takehiro: consider this another vote for
M> keeping parse.c in the library.
I don't think parse.c need to be in the library. parse.c in frontend/
directory will be a good sample code to explain the "big bit-structure&
>>>>> "T" == Takehiro TOMINAGA <[EMAIL PROTECTED]> writes:
T> Sorry, that is my mistake. I commited it before complete
T> the patch. pls wait until tomorrow. I will commit better one.
OOPS!
All I was hunting for is not bug of scalefac_scale
Sorry, that is my mistake. I commited it before complete the patch.
pls wait until tomorrow. I will commit better one.
- Original Message -
From: "Robert Hegemann" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, September 23, 2000 6:54 PM
Subject: [MP3 ENCODER] scalefac_sc
M> So lets agree ahead of time as to when and what will be done.
M> Takehiro: are you volunteering?
No problem :)
R> How about releasing 3.87 beta before starting to rearrange the
R> source code base?
Oh, that sounds OK, but I want to merge some features(faster quantize,
more co
nd" directory and move lame.c and gtk*,
brhist.c and so on into it.
Any Ideas ?
Anyway, John, I want to see your patch and merge them.
could you mail it to me ?
---
Takehiro TOMINAGA // may the source be with you!
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
> "M" == Mark Taylor <[EMAIL PROTECTED]> writes:
M> That used to be needed for the ASM quantization routines. But
M> I checked today and all the ASM code was gone - I guess it has
M> been replaced by the TAKEHIRO_IEEE stuff?
Yes, but for the people who want to compile ALL FLOAT(
> "R" == Robert Hegemann <[EMAIL PROTECTED]> writes:
R> I'm using GNU Make version 3.77, does above work for other Make
R> versions?
Yes, it does not work on 3.77. so I upgraded it 3.78.1 and it works fine.
---
[EMAIL PROTECTED] // may the source be with you!
--
MP3 ENCODER mailing l
Wow! great, Florian!
M> All the various options (GTK, libsndfile, VBR historgram, mpeg
M> decoding) are available through ./configure options. see
M> INSTALL for details. By default it will try to install
M> everything, if configure can find the necessary libraries.
I think it
quot;double" format with more precision than float. it is depending not on
internal format, but external format.
---
Takehiro TOMINAGA // may the source be with you!
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Hi all!
I just made a new TAKEHIRO_IEEE754_HACK more ANSI C compliant.
I think we can make it default for Intel architecture.
does anyone has opinion ?
---
Takehiro TOMINAGA // may the source be with you!
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
INT]);
and
pi[0] -= MAGIC_INT;
but the "type based aliase detection" falls to find this alias.
so the workaround answer is to compile it with -fno-strict-alias, which
disables this "type based aliase detection".
---
Takehiro TOMINAGA // may the source be with you!
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
> "M" == Monty <[EMAIL PROTECTED]> writes:
>> are there precedents of an piece of GPL upgrading to LGPL?
M> Sure! I changed all my own stuff from GPL to LGPL last year (I
M> decided I mostly agreed with Bill Joy ;-). Send the author a
M> letter; he may be willing.
but it
> "R" == Robert Hegemann <[EMAIL PROTECTED]> writes:
R> I just wanna let you know that it does not compile out of the
R> box mainly because your provided mathinline.h interferes with
R> the one installed in my Linux system.
umm,,, just remove the *MY* mathinline.h and delete the
Hi all,
I just made my latest snapshot with a "whole new psymodel".
it uses always MAXNOISE and do not normalize the spread function.
and it always uses mixed block, subblock gain, scalefactor scale.
The VBR mode of this code passes the "vbrtest.wav", and even more,
the file size will be almost
..-0.20,
F> 0.20...0.91 => stereo) and -ms for nearly not
I am afraid most of decoders can't treat an mp3 file correctly
whose mode(stereo <-> mono) is changing during one file.
---
Takehiro TOMINAGA // may the source be with you!
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
tored old takehiro.c and now it works, but the problem is still there.
I will try again in the weekend.
---
Takehiro TOMINAGA // may the source be with you!
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Hi, all
I fixed this bug and committed to the CVS.
pls check out.
---
[EMAIL PROTECTED] // may the source be with you!
>> This matter has already been told to Takehiro, and he said
>> he will commit a new code later.
>> This is an information.
:
>> Under some conditions, you will see som
> "a" == a writes:
>> Performance improvement seems to be about 45...50% using "-V0".
a> In my K6-2 300 MHz the difference is 31.695 seconds without
a> MMX vs. 30.176 seconds with MMX enconding a little wav
a> (using -V0)
my MMX code is fully optimized for intel. on the C
>>>>> "B" == Bill Eldridge <[EMAIL PROTECTED]> writes:
B> Takehiro Tominaga wrote:
>> I hope to test and release it ASAP but I am too busy to do so..
>> even worse, the code is for my branch, not for current CVS
>> version
> "F" == Frank Klemm <[EMAIL PROTECTED]> writes:
F> How to enable MMX/3DNow/ISSE support?
F> MMX: remove the two '#' in the Makefile
F> 3D-Now: ???
F> ISSE: ???
Get the source code from my linux box and compile it :)
The code is not on the net and not tested on actual machin
think ISO's algorithm of SCFSI will never work fine, however you tune
the parameters.
so I made a completely new SCFSI algorithm. it works and makes the quality
little bit better. never dicrease the quality.
see the "scfsi_calc" routine in "takehiro.c"
---
Takehiro TOMINAGA // may the source be with you!
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
re's only little improvement with or without it.
---
Takehiro TOMINAGA // may the source be with you!
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
> "M" == Mark Taylor <[EMAIL PROTECTED]> writes:
M> As for TAKEHIRO_IEE754_HACK: On my system (athlon, gcc 2.95) it
M> causes some problems when used with optimizations above -O1.
M> So it is disabled by default. The amount of choices for the
M> quantize_xrpow and quantize_xr
l[sb] / 576);
FLOAT8 mld = 1.25*(1-cos(PI*Min(bark, 15.5)/15.5))-2.5;
gfc->mld_l[sb] = pow(10.0,mld);
}
does it fit the paper's algorithm ?
---
Takehiro TOMINAGA // may the source be with you!
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
> "J" == Josh Coalson <[EMAIL PROTECTED]> writes:
J> .saf == Secure Audio Format? This sounds like a great new
J> format, because, as we all know, security is the most important
J> attribute of an audio codec! (to sarcasm-impaired: NOT!)
I think security is important too, but i
> "M" == Meister Roger <[EMAIL PROTECTED]> writes:
>> Then why not use mp2 at 384k ? Or even some lossless format ?
M> - Because mp2 is not free !
AFAIK, tooLame is free mp2 VBR supported encoder.
---
[EMAIL PROTECTED] // may the source be with you!
--
MP3 ENCODER mailing list ( http
> "R" == Roel VdB <[EMAIL PROTECTED]> writes:
R> did the standard Takehiro VBR mode change? (you know the
R> "Y"->"-Z" one) What was wrong with the older vbr mode, the size
R> was noticable smaller and I got no real artifacts.
Changed. completely changed. search the below mail fr
or different compiler, different compile option, different library.
Z> Different versions, perhaps?
>> Why are the lame windows binaries on chat.ru, and mp3-tech.org
>> not the same file size?
---
Takehiro TOMINAGA // may the source be with you!
--
MP3 ENCODER mail
>>>>> "Z" == Zia Mazhar <[EMAIL PROTECTED]> writes:
Z> By the way, won't it be nice if the other developers of GOGO
Z> join the LAME project, like Takehiro did? :-)
don't you know GOGO team stopped thier development ?
GOGO 2.35 is the
GOGO, an MP3 encoder derivated from LAME, wins
OSP2000(Online Software Prize 2000).
http://www.nmda.or.jp/enc/fsp/sjis/osp2000.html
(japanese only)
---
[EMAIL PROTECTED] // may the source be with you!
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
te T'(i) directly from T(i) ?
I hope remove these steps and we can get more simple&fast psymodel.c
---
Takehiro TOMINAGA // may the source be with you!
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
ou should use -f win32 instead of coff. pls try it
---
Takehiro TOMINAGA // may the source be with you!
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
it seems FhG and Thomson changed their patent policy.
see http://www.mp3licensing.com/index.html
---
Takehiro TOMINAGA // may the source be with you!
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
d up by fxch pipeline hack.
Anyway, I am now replacing these asm routines into GOGO's more aggressive
code. 3DNow!/SSE will bring us a crazyly fast encoding.
---
Takehiro TOMINAGA // may the source be with you!
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
+= i386/choose_table.o
4. and make it!
Sorry, I have no windows development environment and I don't know
how to use NASM and so on.
BTW, on my architecture, about 5% speed up is archived by this MMX coding.
---
Takehiro TOMINAGA // may the source be with you!
--
MP3 ENCODER mailing list (
> Just my opinion, many may differ :)
Thanx, Roel.
I'll be this feature as default for -h or -q 2 and upper setting
and remove -Z option.
I think the next step is subblock gain. I'll merge the feature from
my snapshot to the current LAME. maybe that will be another "-Z"
opt
Full huffman search is still alpha status, and it sometimes lock up
and is usually "painfully" slow.
This feature will be available with the MMX enabled Huffman code search
routine next weekend, I hope.
But, I am not full time LAME programmer and LAME is only my hobby.
I can't garantee the this
>>>>> "M" == Mark Taylor <[EMAIL PROTECTED]> writes:
M> I just committed a crude fix for the totbit/write_timing
M> overflow problem (last 10 lines of bitstream.c in CVS) but
M> Takehiro may have a better idea.
Uum... OK, I'll make it
I wrote;
>>I added a new scalefac_scale algorithm to CVS version of LAME,
>>which enables with -Y option.
Sorry, -Y option is used for Mark's new VBR routine
so I changed "new scalefactor_scale algorithm" from -Y to -Z option.
---
Takehiro TOMINAGA // may the
n and check the result, and tell me.
---
Takehiro TOMINAGA // may the source be with you!
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
ll. I keep getting access
>> violations. I ran the debugger and it pointed back to:
>>
>> 0040F586 fld qword ptr [ecx*8+455A80h]
z> This may be a bug. In quantize-pvt.c:calc_noise1(), 'max_
z> index' is set to SBMAX_s in VBR mode but the maximum i
t first step, why don't you use the 22nd scalefactor's threshold as ATH
of the scalefactor ?
---
Takehiro TOMINAGA // may the source be with you!
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
playback done on a Shark (The DEC network
M> computer based on the StrongArm) so the answer in general is 'yes'.
Encode and Decode are quite different.
I think both of them are possible, but the encode is by far more difficult
than the decode.
---
Takehiro TOMINAGA
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
I continue playing with quantize_* routine.
on Pentium100MHz, the hack does not make any difference, speed and result.
on K6 200MHz(not K6-2), the results are same but the hack makes it about
10% faster.
---
Takehiro TOMINAGA // may the source be with you!
--
MP3 ENCODER mailing list ( http
of very poor quality. :/
BTW, is it the same result, with or without -h option ?
---
Takehiro TOMINAGA // may the source be with you!
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
>>>>> "T" == Takehiro Tominaga <[EMAIL PROTECTED]> writes:
Segher> Oh, by the way, anyone interested in better DCT's?
Naoki> I made faster mdct_long and sent it to Takehiro.
T> and it was merged to my tree. maybe tomorrow, CVS tre
Hi all,
I found USAGE file in the LAME is quite old especially VBR.
I think html documents are sufficient and we can remove the
USAGE file.
---
Takehiro TOMINAGA // may the source be with you!
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
- MAGIC_INT]);
((float *)pi)[3] = (x3 + adj43asm[pi[3] - MAGIC_INT]);
uum, there's no "<<"
The binaries runs fine, and "make test" result is OK, too.
but the speed is slower than the no hacked version *sigh*
---
Takehiro TOMINAGA // may the source be with you!
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
LAME is on the topic at slashdot.
http://slashdot.org/articles/00/05/10/1454220.shtml
I think Tord knows about the MP3 and patents very good :)
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
lt of this hack, on various plathome.
pls check and tell me the result and your plathome(CPU and compiler).
---
Takehiro TOMINAGA // may the source be with you!
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Segher> Oh, by the way, anyone interested in better DCT's?
Naoki> I made faster mdct_long and sent it to Takehiro.
and it was merged to my tree.
maybe tomorrow, CVS tree will get it.
it's very swift :)
---
Takehiro TOMINAGA // may the source be with you!
--
MP3 ENCO
and normal Pentium,
there's about 2x FPU power. K6, 686MX... has more slow FPU. K6-2,III
are also, but they have 3DNow! and it'll be fast (maybe about as twice
as the same clock Pentium) if someone write the code to use it :p
---
Takehiro TOMINAGA // may the source be with you!
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
lt;[EMAIL PROTECTED]> writes:
M> The thread safe work is mostly done - but I tried encoding two
M> things simultaneously last week and it failed miserably :-(. I
M> just found some more static, non-constant variables in
M> newmdct.c, and there are probably a few more st
ur machine has no 2nd cache or poorly setting BIOS.
Be sure machine speed is not determined by only CPU clock.
check your CPU architecture and memory performance.
Pentium/K6/686MX is very slow, cause it has only slow FPU. even at the
same clock, Pentium will be half or 3/4 speed of Pentium Pro f
Hi, all,
>>>>> "T" == Takehiro Tominaga <[EMAIL PROTECTED]> writes:
T> Hi All, I've merged Naoki's new IDCT code for filter subband
T> into my tree,
Sorry, some trouble happen and I can't have a time...(even it is hol
mdct_short and mdct_long are also
N> speeded up by introducing faster algorithm. Have you already
N> made it?
No :)
I wanna heard it, but I'm afraid it is slow too...
---
Takehiro TOMINAGA // may the source be with you!
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Hi, Naoki,
Your new code looks like very similar to my snapshot(but is not on the
net yet :p). It was mentioned in the first mail of
"the road to the next(v4.00?)" thread.
>>>>> "T" == Takehiro Tominaga <[EMAIL PROTECTED]> writes:
>> 3 new
flakey feature).
I made a "--noscfsi" option for some buggy decoder, but Mark deleted :)
maybe his policy of LAME is challenging to the ISO limitation and
he think we can neglect such buggy decoder.
---
Takehiro TOMINAGA // May the source be with you !
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
t and no way to check them.
(Any donation will be welcomed :-p)
BTW, I'm using mpg123 and AudioPCI64(ES1371) and my old SANSUI amplifier
with ONKYO speakers to check the LAME.
---
Takehiro TOMINAGA // may the source be with you !
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
>> is it worth to use -p at 192kbps?
Do you know -p option ?
-p option is "calculate CRC for error detection".
It's worth only when using none error free data transmission(like UDP),
no matter what bitrate you use.
---
Takehiro TOMINAGA // may the source be with you !
-
7;m afraid "mixed block support" (which is only plan of next release,
no code available now) will be so.
If you want MAXIMUM QUALITY of mp3, BE SURE to use the best encoder
and the best decoder.
(and of course audio equipment, especially sound card in your PC)
---
Takehiro TOMINAGA // May the source be with you !
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
S> energy in the lowest frequency bands.
We should tune the some threshold parameters, but I think this simple
method will work fine.
but before the these algorithm, we have to change the bitstream code
to allow the mixed block :)
---
Takehiro TOMINAGA // may the source be with you!
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
a to the
Scott> correct sample rate etc, I can see real uses for it there.
right, resampling is one thing we can use the MMX, but the lagest problem
of MMX command set is that there's only 16bit multiply.
---
Takehiro TOMINAGA // may the source be with you!
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
e or shell account :-) ?
and these have not written yet, but may improve the LAME
5 mixed_block support
6 call best huffman code each iteration
maybe very very slow, but quality will be up.
Any ideas ? or does someone doing part of them ?
---
Takehiro TOMINAGA // may the source be with y
>>>>> "T" == Takehiro Tominaga <[EMAIL PROTECTED]> writes:
>>>>> "R" == Robert Hegemann <[EMAIL PROTECTED]> writes:
T> I make a quick hack and do it, but it is not clever and cool:
T> 1 added the routine that reo
efault mode at lower bitrate should be "-m f" (but this is
deleted...), or "-m j" (always calculate MS/LR threshold. maybe slower...).
FYI, in my snapshot version, "loopold.c" was also deleted and the default
setting of the lower bitrate is "-m j"
---
Takehiro TOMINAGA // may the source be with you !
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
count1 region.
The new code still has little bug, but the snapshot will be on my web
page(maybe tomorrow?).
And bacause the new short block huffman coding algorithm is very
efficient, I think we should change the bit allocation for short block.
I'll check them and merge into the CVS.
---
Ta
t; you given any thought to coding up a search for a more optimal
M> short block big_values ?
Oh !
I believed we can't use the count1 region when the block type is short.
I checked ISO standard and will optimize the coding if available.
---
Takehiro TOMINAGA // may the sour
575?
R> 575+2=577 --> index overflow --> crash/assertion failure!
R> So I assume, you have to check count1 >= 575 before.
MP3 standards says count1 should be even number.
if it is odd number like 575, it will cause the problem another point,
like l3bitstream.c
---
Takehiro
Hi, Robert.
This "cod_info.count1 += 2" is necessary to reduce the code size,
but we can't reduce the code size when cod_info.count1 == 576.
this is fixed before you check in the "assert".
and I think it is OK now...
---
Takehiro TOMINAGA // may the source be with
ABORTFP, I need a newer which contains
these macros.
/* Macros for accessing the hardware control word. */
#define _FPU_GETCW(cw) __asm__ ("fnstcw %0" : "=m" (*&cw))
#define _FPU_SETCW(cw) __asm__ ("fldcw %0" : : "m" (*&cw))
---
Takehiro TOMINAGA // may the source be with you!
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
and LAME do a next calculation
en0 /= bw;
and
start = scalefac_band.l[ sfb ];
end = scalefac_band.l[ sfb+1 ];
bw = end - start;
so bw is zero, and LAME do a "divide by zero"
but I haven't find out where scalefac_band is cleared.
---
Takehiro TOMIN
M> or two until this is straightened out?
OK, I stop the commiting.
---
Takehiro TOMINAGA // may the source be with you!
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
y linux machine, gcc says "invalid left hand value" and fails to
compile this code :)
---
Takehiro TOMINAGA // may the source be with you!
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
I added CVS tree a new fft routine and table lookup method to calculate
pow(2.0, ..).
The speed is about 10% faster on my celeron linux box.
---
Takehiro TOMINAGA // may the source be with you!
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
ust guess. No test.
I don't think so, because almost all "pow" call is not in the loop and
can't be vectorize.
---
Takehiro TOMINAGA // may the source be with you!
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
chines (68k
S> & PPC), might be more or less on yours, try it out... ;)
Why don't you use table :)
all pow(2.0, global_gain*0.25) and pow(2.0, -global_gain*0.1875) could
be rewrite table lookup.
see my snapshot for the detail.
---
Takehiro TOMINAGA // may the source be with y
encode and can do faster encoding.
Maybe we can write the mp3 encoding cluster based on this.
---
Takehiro TOMINAGA // may the source be with you!
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
.
When one of scalefactors will be too large even with scalefactor_scale
is 1, it will increase the subblock_gain and re-calculate the
scalefactor.
This method would be the best subblock gain selection as far as the
psychoacoustic model is right.
---
Takehiro TOMINAGA // May the source be with you!
-
alog threshold
*-h 9: subblock gain code
---
Takehiro TOMINAGA // may the source be with you!
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
ng time because I thought this was caused by a bug of
K> distortion check.
Yes, me too...
---
Takehiro TOMINAGA // May the source be with you!
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
is released in LAME.
I think "scfsi" must need some work before release.
BTW, CVS snapshot of history.html, contains changes of 3.60 -> 3.61,
but www.sulaco.org does not. I don't know why it is.
---
Takehiro TOMINAGA // May the source be with you!
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
be added to the resrvoir.
I made a usuall validation check and I think it seems working correctly.
Any comments are welcomed.
---
Takehiro TOMINAGA // may the source be with you!
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
his new scalefac_scale method as same as you did
Uuum it is "not" bit-for-bit identical, but is only LSB order,
so it seems because of mpg123's floating point rounding problem.
please test and comment this.
---
Takehiro TOMINAGA // may the source be with you!
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Takehiro TOMINAGA(me)>
>> and dividing region0/1/2 is determined by looking up the
>> subdv_table[]. However, I am afraid this method is not the
>> best.
Segher Boessenkool <[EMAIL PROTECTED]>>>
S> It is indeed not best.
S> It&#x
1 - 100 of 159 matches
Mail list logo
