Where can I upload a 10 seconds cut from "Main Theme" wave
so you can make your own picture of the problem I have with it?
Robert Hegemann
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
to add this. But if you send me a script that can do
this I would love to add it to the LAME distribution.
Mark
here is a little bash script as a start.
Robert Hegemann
begin-lame.script---
#!/usr/local/bin/bash
# adapt this for your needs
For the value of this threshold, I suggest using a table giving the minimum
of the audition threshold in the frequency range of each subband. The
following formula gives the human minimal audition threshold of a young
people with very good hearing, f beeing the frequency:
I´m not sure that a substraction of 5dB -- or any other
constant x -- from all masking thresholds is the right way to go.
We could vary this value along the Absolut Threshold of Hearing.
The advantage of this method would be a prevention of distortions
at frequencies where the ear is most
The Resource Intercharge File Format (RIFF) Wave file has
the following structure:
ID4 character code "RIFF"
Size 4 Bytes, length of data field
Data Size Bytes of Data
The Data field of a "RIFF" chunk has the following format
FormType
IDSubchunk; 4cc "fmt " for .WAV files
Size 4 Bytes, length of data field
data Stereo/Mono, kHz, etc.
I forgot to say that in this "fmt " chunk it is coded which type
the wave data is: MP3, PCM, ...
But don´t ask me how it is coded.
Robert
--
MP3
hmm, strange. I'm still on the list, but compared to the mail archive
didn't get the last few.
Robert
--
Sent through Global Message Exchange - http://www.gmx.net
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
The calculation of needed bits for the side channel with the one
needed for the mid channel is a step back. I get ringing artefacts
on even highest possible VBR settings. A while ago I played
with such things, but never got satisfactory results.
ms_ener_ratio was introduced to decide between
Greg Maxwell wrote:
Well with the fac .33 caused by the ms_ener_ratio=0.0;
this line save_bits[gr][1]=((1+fac)/(1-fac))*save_bits[gr][0]
allocates twice the bits to mid as it does side.
if you mean
number of bits for side = 2* number of bits for mid
you are right.
I think the line
Hi all,
played a bit with calcnoise2. Just tweaked the inner most loops
to check first whether ix[]=0 (which is pretty common). This then skips the
pow43 table look up and calculation.
This gives about a 25-30% speedup for this routine.
one note
Am Son, 10 Okt 1999 schrieben Sie:
# My latest snapshot is available at
# http://www.isoternet.org/~tominaga/lame-1007.tar.bz2
---
Takehiro TOMINAGA // may the source be with you!
I tried your latest snapshot, the speed is really good.
But try to encode gspi35_1.wav from the SQAM files at
Has anyone taken a close look to the three spreading functions
in Lame? For me it looks like they are buggy, but correct me
if I'm wrong.
Here is how I would patch them.
Robert
*** lame3.34/psymodel.c Tue Oct 12 23:14:57 1999
--- lame3.34.w2/psymodel.c Mon Oct 18 21:27:27 1999
I took a look at that: I think s[][] is the spreading function used
for psymodel 2, layer II. In LAME, it is never used, so I went ahead
and deleted all that code. The layer III psy model is modified - see
page 80 in the ISO docs, "adaption of psychoacoustic model II for layer
III")
As many of you may have noticed, if a track fades out
the bitrate decreases downto min_bitrate (ie. 32kbits).
But, if that track has a few more frames with digital
silence (zero energy), the bitrate switches up to
max_bitrate (ie. 224kbits). For a quick fix look at
quantice.c around line 662,
Greg Maxwell wrote:
The correct solution is not to remove the -2. :) We want that because we
know that the psy model is often too optimistic, as it really was designed
for CBR apps, and is thus more useful for choosing how to allocate bits
among subbands then for determining how good
Greg Maxwell wrote:
Currently VBR quality selection only select the number of subbands that
you permit to be over the psy model (unless I've drifted completely out of
sync from the codebase), this is a nearly useless metric.
OK, you are a bit out of sync with the codebase. VBR as it is
No, Eric, you are not the only one!
lame -v fatboy.wav
with todays cvs lame gives me a segfault too,
in quantize_xrpow line 783 of quantize-pvt.c.
The code looks like:
for (j=192;j0;j--)
{
x = istep0 * *xr++;
/* *(ix++) = (int)( x + adj43[(int)x]); */
Yes, VBR is really VBR :-)
A few more informations how you call Lame would be usefull:
- operating system
- Lame version
- complete commandline
I suppose you are calling Lame out of a DOS Box.
Well, first of all, Lames command line settings are case sensitive.
And as far as I
Thanks, it seems it works fine.
I think you can close this open BUG at
SourceForge.
Robert
Lame A Mpeg-audio Experience
Takehiro wrote:
I commited simple and "not cool" code for workaround of adj43 overrun.
please test it I have not enough time to do it
uuh... so many trouble,
ÿØÿà
What do you mean Chuck?
Robert
--
___ ___ ___ ___
/\__\ /\ \ /\__\ /\ \
/:/ //::\ \ /::| | /::\ \
/:/ //:/\:\ \ /:|:| | /:/\:\ \
/:/ //::\~\:\ \
Menno wrote:
While implementing M/S threshold calculations for FAAC, I noticed some
things that could be improved in GPSYCHO.
The formula for the BMLD protection ratios you reverse engineered should
look like this:
mld[b] = pow(10, -3*(0.5+0.5*(M_PI*(min(bval[b], 15.5)/15.5;
I took
Here are some thoughts about Lame at constant low bitrates:
* at low bitrates we have low samplerates (MPEG2)
But the ATH formula we implemented is tuned for 44.1 khz
sample frequency (due to the high frequencies, MUS420 Project).
Maybe the ATH formula
Mark wrote:
I would suggest changing to a more sox like settings, where you specify
the lowpass frequency, and then a width or rolloff parameter.
lowpass_l and lowpass_h seems a little confusing. What about:
--lowpass
--lowpass_width
And then there could be a default width of about
What does the -X parameter do exactly?
When LAME searches for a "good" quantization, it has to compare
the actual one with the best one found so far.
The function quant_compare says which one is better, the best
so far or the actual.
Now the -X parameter selects between different approaches
Mark wrote:
I'm still not sure the gspi35_1.wav problem is caused by the ATH.
I think it is actually caused by other flaws in the psy model.
My reasons are:
1. using --athonly -V5 doesn't have the problem (in this case lame is
choosing the bitrate so there is no audible distortion
Mark wrote:
and also will use the same amount of bits for both mid and side channels!
But, that's not always bad doing so.
Another quick fix: the '-m s' option :-)
yes, at the cost of twice the file size :) (at least in my example)
A+B.wav as VBR in stereo 95 kbits
Takehiro wrote:
"R" == Robert Hegemann [EMAIL PROTECTED] writes:
: snip
R As a quick fix, I would suggest turning the special treatment
R for the Side channel off.
If it is so, the problem is caused by the calculation of the MS ratio,
not by the ATH.
The calculation
David wrote:
Hello All,
Has anyone else had the problem of a small pop at the beginning
of playing an encoded file? I am just curious if it is a known problem.
BTW:
I am compiling and linking in Win98..
-David Swigger
Hi David,
first of all we need to know what you did.
Did
Greg wrote:
On Thu, 6 Jan 2000, Mark Taylor wrote:
Also, as a sanity check, if side_channel_energy mid_channel_energy,
turn of ms stereo for that frame.
I know it sounds a bit insane... But...
Whats wrong with letting side have more bits then mid for weird cases like
the inverted
Mathew wrote:
From: "Mark Taylor" [EMAIL PROTECTED]
From: "Mathew Hendry" [EMAIL PROTECTED]
Looking at the sampling rate options in FhG's MP3 plugin for Cool Edit
Pro,
some odd sampling / bitrate choices are offered.
Bitrates: 18kbps, 20kbps
Sampling rates: 11025Hz,
I am interested is VBR encoding so when I discovered LAME I started to
play
with it.
For relative low quality I used -V 7 and didn't specify a minimum bit
rate.
To increase the quality I changed to -V 5 and added -b 64 (or something
comparable). After upgrading from 3.50 to 3.58 I saw
Dmitry schrieb am Don, 20 Jan 2000:
Hello Peter,
Thursday, January 20, 2000, 10:40:33 PM, you wrote:
PO I've done some testing on Lame, Mp3Enc31 and BladeEnc, encoding a 262sec. song
(45.2Mb).
PO I used a 600Mhz pentium III with Win-98, and the EXE from the russian site.
PO CBR,
Osamu Shigematsu schrieb am Mit, 26 Jan 2000:
Hi, all.
Recently, I found that float (32bit folating point) is faster than double
(64bit) when calculating devision. More, division is extreamly slower than
multiplication.
snip
How does everyone think about unifing float size to 32bit? It
Greg Maxwell schrieb am Die, 01 Feb 2000:
On Tue, 1 Feb 2000, Jeremy Hall wrote:
but then you're in conflict with VBR.
VBR should be changed. It makes more sence for big numbers to denote
bigger bitrate in VBR.
Well, in my opinion -V reflects the following behaviour:
-V0:allow low
Is the sfBandIndex Table B.8 messed up for MPEG2's
lower frequencies?
For long blocks the entries B.2.b (22.05kHz) are the
same as for B.2.a (16kHz)! But the entries for short
blocks differ.
Robert
--
Sent through Global Message Exchange - http://www.gmx.net
--
MP3 ENCODER mailing list (
Is the sfBandIndex Table B.8 messed up for MPEG2's
lower frequencies?
For long blocks the entries B.2.b (22.05kHz) are the
same as for B.2.a (16kHz)! But the entries for short
blocks differ.
A comparison between LAME's tables and MPGLIB's (mpg123)
tables show a different value in Table
We orignally used V to set the number of bands allowed to be 'over'.
When
we changed that, we should have V.
Why? Only to confuse users?
And the idea of V hasn't changed.
btw, what about a "-h x" setting with x in R?
x = -inf : nothing but speed counts
x = 0: best quality we can do now
x
Doesn't xmms use a different engine? I don't use xmms.
I use mpg123 0.59r, too, and it repeatedly bombs on "-v -V 0" encoded
songs. A friend of mine apparently likes -V 0 and he has had the same
problems with mpg123, so it is not an isolated issue.
Felix
That sounds strange. What
Mark Taylor schrieb am Sam, 05 Feb 2000:
Hi Ingo,
It looks like your changes have already been added to CVS.
But on my system (RH5.2 linux), the line
stderr = stdout
gives an 'invalid lvalue' error.
Any suggestions? I've temporarily commented it out for now.
That wasn't Ingos
I just committed Ingo's patch. It should work now.
Robert
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Takehiro schrieb:
Maybe that is my faults (because this two days, CVS changes are mainly
done by me), but on my linux box, it is not happen... ? and "make test"
has no problem too.
Except the GTK sections I did not have problems with Takehiro's
modifications. (It seems Takehiro does not like
Ooops, the complete patch is:
*** lame/lame.c Sat Feb 5 13:28:16 2000
--- lame-2000-02-06/lame.c Mon Feb 7 20:20:39 2000
***
*** 288,293
--- 288,294
/* we do not normally allow 320bps frams with VBR, unless: */
if (gf.VBR_min_bitrate_kbps=256)
Mark Taylor schrieb am Don, 10 Feb 2000:
Ok, I'm giving up trying to track down that floating point exception bug,
and reverted CVS back to the original code, with the following fixes:
VBR_min/max bitrate index set properly (Robert)
s3_s spreading function bug fixed (Alfred Weyers)
Albert Faber schrieb am Die, 15 Feb 2000:
Robert,
Can you be more specific with which file this error occurs, and what
options/settings are you using? So I can try to reproduce this problem on my
system.
Albert
Sure Albert!
It happens in "quantize-pvt.c", function calc_xmin (around line
Segher Boessenkool schrieb am Die, 15 Feb 2000:
0x805e2cc calc_xmin+460: fldl 0xfff0(%ebp)
It loads from stack, offset -0x10; so it's a local variable.
-- for ( sfb = 0; sfb cod_info-sfb_lmax; sfb++ ){
Don't think so, no floats involved here.
Ciao,
Segher
OK,
Mathew Hendry schrieb am Die, 15 Feb 2000:
0x805e2cc calc_xmin+460: fldl 0xfff0(%ebp)
It loads a floating point value from memory into a floating point register.
The value in memory is presumably invalid, so the CPU traps when it loads
it.
So we have to figure out which
Hi, I read on the FAAC board about a freeware tool
named sMP3m Simple MP3 Maker by Lance Perkins.
It can play mp3s, rip and encode to MPEG1, MPEG2-lsf
and MPEG2-AAC. The features VBR (quality from 1-10),
fast encoding switch and Joint-Stereo together with
it's encoding speed, let me think, that
Takehiro Tominaga schrieb am Son, 30 Jan 2000:
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!
Hi Takehiro,
that sounds good to me!
But I
freeamp uses a Xing decoder, table entry is 332.
Robert
Mark Taylor schrieb am Fre, 24 Mär 2000:
It looks like this MPEG2 table bug has finally showed up as a real glitch.
There seems to be a problem with the 19'th number in Table B.2.c (24kHz):
{ /* Table B.2.c: 24 kHz */
Encoding ECLIPSE, from Dark Side Of The Moon by Pink Floyd,
with actual CVS version results in a segmentation fault
after 96% done. All other eight songs encode fine.
It happens at the following code within best_huffman_divide (takehiro.c)
/* Determines the number of bits to encode the
Mark Taylor schrieb am Mon, 27 Mär 2000:
if you dont mind, can you try again the latest CVS version?
I'm guessing these problems were caused by Takehiro's latest
changes: he put in yet more efficient lossless encoding
which is also faster! But there may be a few more bugs,
he just
GA // may the source be with you!
"R" == Robert Hegemann [EMAIL PROTECTED] writes:
R I checked the 3.67 tarball from sulaco.org and it seems to
R work. For the SEGFAULT problem with Takehiro's enhanced code I
R inserted an assert(i=576) in best_huffman_divide, and now it
Hi Takehiro.
Hi, Robert,
"R" == Robert Hegemann [EMAIL PROTECTED] writes:
R I still get assertion failures at this point.
Uum, really ?
R Sorry, but it is not OK now. If you check count1 == 576 before
R this, what happens if count1 == 575?
R 575+2=57
Takehiro Tominaga schrieb am Mon, 03 Apr 2000:
Hi Mark,
"M" == Mark Taylor [EMAIL PROTECTED] writes:
M It is a little confusion to me because short blocks have fixed
M values for the region0/region1 partition which says that
M region1 ends at 576. And thus you could assume
Takehiro Tominaga schrieb am Mon, 03 Apr 2000:
It's not mistake. maybe.
it is because Mark deleted the old "loopold.c" code from LAME.
"loopold.c" is too old and not mentainanced.
I think default mode at lower bitrate should be "-m f" (but this is
deleted...), or "-m j" (always
Mark Taylor schrieb am Mon, 03 Apr 2000:
snip
I've noticed there are some MPEG2.5 problems at 8kbs,
but are you sure this is the problem? setting the
extra bits added for short blocks (currently 500) to zero
doesn't help for me.
snip
Mark
No Mark, I'm not sure that it is the cause. The
Hi Nils!
Hi!
I just tried to setup my personal CVS mirror but fail with
authorization.
I tries
cvs -d :pserver:[EMAIL PROTECTED]:/cvsroot/lame login
with password
anonymous
right?
Try to just type the RETURN key, that works for me.
Does not work:
cvs [login aborted]:
Hi Ross,
as LAME 3.80 is the CVS version, may I ask you:
which version of LAME 3.80 did you compare with LAME 3.70?
Robert
Ross Levis schrieb am Sam, 15 Apr 2000:
If anyone is interested,VBR is now more spread over the bitrates. Here is a partial
frame analysis of a song (all encoded with
Mark Taylor schrieb am Don, 20 Apr 2000:
With the 3.80n-binary i get a lot of " informative message:
drain_pre/post: wasting bits=" especially with -V 2 and -V 1
combined with -B 320 or -V 0 alone, is this important or is it just
a message that hasent been removed ?
Peter
Mark Taylor schrieb am Sam, 06 Mai 2000:
I created them with the new "--freeformat" option in LAME :-)
freeamp and "lame --decode" both seem to play them back correctly,
but that is the only testing I've done.
The ISO spec says that free format bitstreams are limited
to 320kbs, but lame
Hi Ivo!
Woah, that's pretty big difference, isn't it??
YES
b) you use an older, slower version of LAME
Well, it was based on some older versions, I'm now testing it with the
version
I have now, which is Lame 3.69. Is there much difference in speed from
the
newer versions?
I can't
Mark Taylor schrieb am Mon, 08 Mai 2000:
From discussions here, I think it is safe to remove this restriction
but make an option to turn it back on. I liked the one suggestion
of something hard to type like: "--strictly-enforce-ISO" :-)
I tested a couple of players and they didn't have
Mark Taylor schrieb am Die, 16 Mai 2000:
I am very biased, but...
The web site says nothing about audio compression or encoding
technology. Also SCMPX seems to be the work on one guy with
limited user feedback (not open source) who also writes games
and GUIs. I just cant believe it is
Sigbjørn Skjæret schrieb am Die, 16 Mai 2000:
Just thought I'd note that MPEG 2.5 is more or less broken at lower
bitrates, and that the filters seem screwy at low frequencies...
Try the following: (preferably with a 8kHz sample)
"LAME --resample 8 -b 8 input output" (MPEG2.5)
- Notice
Robert Hegemann schrieb am Die, 16 Mai 2000:
Mark Taylor schrieb am Die, 16 Mai 2000:
I am very biased, but...
The web site says nothing about audio compression or encoding
technology. Also SCMPX seems to be the work on one guy with
limited user feedback (not open source) who also
Mark Taylor schrieb am Don, 18 Mai 2000:
I think I already asked this before, but could someone on the developing
team consider adding this function to lame?
thanxxs
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
I would like to do this, since then it would be
Osamu Shigematsu schrieb am Son, 21 Mai 2000:
Hello, all.
I'm now trying to make LAME 3.83 on Macintosh with CodeWarrior.
My compiler says, that
Error : type mismatch
'int *' and
'int'
quantize-pvt.c line 1088 if (scalefac-s[sfb]0) /* scfsi! */
So I fix
if
Roel VdB schrieb am Son, 21 Mai 2000:
RV To be clear, I don't mind, but am just curious:
RV Lame 370 gave me 1.7 speed on my Cel400@450 (dkutsanov)
RV Lame 383 gives me 1.0 speed on my Cel400@450 (dkutsanov)
RV [Lame 384 -Z gave me 1.7 speed on my Cel400@450 (dkutsanov)]
sorry should have
Hello, all.
I would like to normalize (maxmize) and trim silent part from input
audio
data. I'm going to add both routine into get_audio.c (I don't use
libsndfile).
Does anybody know how to do that or such sound libraries?
TIA
--
Osamu Shigematsu
mailto:[EMAIL PROTECTED]
I
Gabriel Bouvigne schrieb am Son, 07 Mai 2000:
The ISO spec says that free format bitstreams are limited
to 320kbs, but lame will allow you to specify any bitrate over 8kbs.
(lame prints warnings when using freeformat)
According to my ISO doc (section 2.4.2.3), for layer III, decoders are
Gabriel Bouvigne schrieb am Son, 28 Mai 2000:
Hello ,
latest usage says:
"
--freeformat
LAME will produce a fixed bitrate, free format bitstream.
User must specify the desired bitrate in kbs, which can
be any integer between 8 and 320.
Not supported by many decoders.
"
Gabriel Bouvigne schrieb am Mon, 29 Mai 2000:
Btw, what is Mad?
Robert
Mad is a young integer only decoder, quite fast. I don't remember the url,
but there is some source code on my page.
Regards,
--
Gabriel Bouvigne - France
[EMAIL PROTECTED]
icq: 12138873
MP3' Tech:
Gabriel Bouvigne schrieb am Don, 01 Jun 2000:
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 -
[EMAIL PROTECTED] schrieb am Fre, 02 Jun 2000:
Has anyone know about MPEGPlus.
According to http://come.to/mpegplus site, this new format gives a better audio
quality than all currently available formats (MP3, VQF, Liquid Audio, etc). The
new format is created by Andree Buschmann and he
Hi Charlton!
Exactly! But WAIT! There's nothing else TO use for Lame!
Guess I'll have to make one myself. Which I can say I honestly have
been
tempted to do. All it would take is a few hours to come up with
something
better than lamebatch.
there is no need to do that! You already have
I searched the archives and I don't think this has been mentioned
before.
I downloaded mp3encdemo31 [0] onto two 450Mhz pIII computers with
identical hardware, one running NT4, one running red hat linux 6.0.
The NT version seems about twice as fast, and they output different mp3s
even if
Mark Taylor schrieb am Fre, 09 Jun 2000:
This bitstreams produced by this mode are just like other
VBR streams, so there should be no compatibility problems.
To explain how this works, take a 128kbs CBR for example.
In that case, LAME allocated a base amount of
bits for each frame. This
The Safe-VBR mode is more a constant rate encoding than a variable rate
encoding. I made (not in CVS) a switch allowing to specify a target
bitrate with --abr 157 and noticed that 157 kbits would be reached more
often than not. OK that fatboy sample needed a lot more than the target
bitrate
Chris Sidi schrieb am Son, 11 Jun 2000:
In my case, the CPUs are identical (at least they should be - I should
double check the company who built them got it right), only the platforms
(and I guess the compilers used) are different. Do different platforms
get slightly different results for
Alfred Weyers schrieb am Sam, 17 Jun 2000:
Hi,
Before the former -X n experimental settings in quant_compare are dropped
entirely, I'd like to report about the experiences I made with these
evaluation heuristics.
1) experimentalX=0 uses the most stable setting (and the default method).
Leonardo Stern schrieb am Don, 22 Jun 2000:
Hello L.A.M.E. people,
1 - Why ABR is much faster than VBR ?
because ABR (aka Safe-VBR) is some kind of constant rate encoding
with an unlimited (speek as much as the largest allowed bitrate
can give) bitreservoir.
2 - Anyone tested ABR x CBR
Shawn Riley schrieb am Don, 01 Jan 1970:
I'm not quite sure actually, but I think that mp3enc3.1 lets you control more than
that ACM
I'll bet it does, I was actually referring to the command line interface with
that one... AFAIK, MP3Enc only has -no-is -dm. -no-is doesn't tell it
So ABR is VBR that tries to match the average bit-rate to the user
supplied value ?
David
ABR is more like CBR without to be constraint to fit into a fixed bitrate,
so it is allowed to use frames of variable sizes, like VBR too.
ABR is a hybrid of CBR and VBR.
And yes, ABR tries to
Hi,
The dist10-code is part of the ISO 13818 standard.
So everyone can go to a good library and copy the standard.
(Here in Germany you need papers from a university or you
have to pay money ... but basically you can get this code
without any problems - and without hacking.)
If you
Mathew Hendry schrieb am Fre, 23 Jun 2000:
The -Y mode does seem to have problems, though. A five minute test track I
just encoded at -v 4 has spurious bleeps all the way through it. Smells
more like a logic error than a problem with the psychoacoustics.
-- Mat.
Hmm strange.
I don't
Hi Roel!
Hello,
[MP3 ENCODER] Marks new VBR now the default
I know I'm not a developer myself, but I'll try to make some points.
If I understand correctly, there was beta up to 3.83, and then both
Mark Taylor and Takehiro Tominaga put forward a new VBR algo
(respectively -Y and -Z).
Hi Roel!
But anyways, I'll try my best to find some more bugs in the newer
alpha's, so that there will be clarity soon. :) (btw, is that min
bitrate bug already fixed? (-B128 doesn't work)
I think here is no bug, but lame detects silence.
If you want to force lame to use no smaller frame
Hi,
it looks like some code in quantize.c is now broken
in lame3.84 beta. There is no quality decrease, but
an unnecessary speed decrease for the old VBR.
You would have to patch lame.c and parse.c with the following
and the old VBR would be back at its normal speed.
Ciao Robert
***
Hi all.
I found a bug of MS threshold adjustment, but I don't have a paper
describing the algorithm(*). so I want to someone to check this.
(*) Johnston Ferreira 1992 ICASSP paper
snip
does it fit the paper's algorithm ?
---
Takehiro TOMINAGA // may the source be with you!
I don't
kenzeh schrieb am Mon, 03 Jul 2000:
What about LAME at 128kbs? files size should be about 2.7meg.
Vorbis by the way, is a VQ codec, and it is probably already
supported by more players than the proprietary vqf :-)
Can someone point me at a Vorbis site, i remember reading about it on
Mark Taylor schrieb am Mon, 03 Jul 2000:
Thanks Mathew, I just changed VbrTag.c to set
the CRC bit for the Xing-VBR tagging frame
like the first frame.
Now mpg123 works with protected VBR files.
Robert
This is probabaly the right thing to do, but:
Now, the Xing
Hello,
I think I might have located a bug in the 3.85 (and also 3.84, as
mentioned before) vbr engine.
You can notice it on this file:
http://users.belgacom.net/gc247244/extra/teenyweenytinybug.zip
(1.666bytes)
snip
thanks and good luck ;)
--
Best regards,
Roel
Karsten Luetkewitz schrieb am Mit, 05 Jul 2000:
:: Hi, Mathew Hendry
The Standard edition doesn't include an optimizing compiler, so you're
unlikely to get a lot of speed out of it.
Try the 30-day evaluation version of Intel's compiler at
http://developer.intel.com/vtune/ .
Hi Tonic!
It looks like your LAME version 3.85 is an alpha version and not
a released beta. In LAME we have currently two versions of VBR code:
1 the "old" VBR code
2 the "new" VBR code by Mark
No this is beta I do not DL any alfa
I DL it on the day of release of 3,85 from rusian site
Gabriel Bouvigne schrieb am Mon, 10 Jul 2000:
I've personnally got a different opinion than Mark about it. The iso specs
forbid usage of reservoir with 320k frames and up. So I personnally think
that --nores must be used when encoding with -b 320. Otherwise, it could
cause problems in
Mark Taylor schrieb am Mon, 10 Jul 2000:
-F: Not recommended. This was added to force a
minimum frame size even if the data
could fit in a smaller framesize. -F was added because
some obscure portable couldn't handle frames 64kbs.
Originally -F had no
Mark Taylor schrieb am Mon, 10 Jul 2000:
Why I attenuate 3dB (0.7 != -1.5dB) here is that there is a description
in Zwicker's book that peak of masking is 3dB below masker. Why I
increase masking by 2dB later is that I tuned this value by listening
tests.
I dont know if this is
I'm a bit worried about LAME's short block detection.
Consider the following sequence of short block
energies with a big surge between b3 and b4:
b1 b2 b3b4b5b6
100100100200020002000
If the frame boundaries are like
f1f2
[b1,b2,b3][b4,b5,b6]
then LAME will not
OK, once again, there is no -b128 bug!!
A typical stereo mp3 frame consists of two granules and 2 channels.
So you have to encode:
granule1 left-channel
granule1 right-channel
granule2 left-channel
granule2 right-channel
That makes 4 possibilities to detect
David schrieb am Die, 11 Jul 2000:
I'de like to get a version with MP3x included, can some code wiz compile
such a version ?
i tried the 3.70 GTK version with the dll's but it never worked, it just
crashed.. :(
If you would have looked at LAME's homepage you would have found the
following
1 - 100 of 230 matches
Mail list logo
