RE: [MP3 ENCODER] filter options
At 5:28 PM +0100 on 12/13/99, Robert Hegemann wrote: > CD 2 - 2 hz, stereo: > --lowpass_h 2 > --resample 44.1 > -m s -b 192 I thaught a CD could have up to 22KHz? -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] filter options
Robert, Presets: Is the -b setting removed when -v is selected? Should! If you are interested, I've just analysed some voice-only files here and found most energy is between 100hz and 12000hz. Cheers, Ross. Robert Hegemann wrote: > Thank you Ross for the info about radio frequencies. > Coding FM quality with sharp cutoff would look like: > > lame --highpass 0.05 --highpass-width 0 > --lowpass 15 --lowpass-width 0 > -m j -b 128 > > > Robert -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: Re: [MP3 ENCODER] profiling
> From: "michael cheng" <[EMAIL PROTECTED]>
>
> > -fno-inline. It's all in the info file (and unlike most stuff in info,
this
> is
> > easy to find :-).
> But I want *everything else* inlined (if possible), except this one
function.
I don't know of any neat way around this (there's no "noinline" keyword or
attribute, for example) but you can hack up something like
/* foo.h */
...
/* int func(void) */
extern int (*const volatile func)(void); /* replace original declaration */
...
/* foo.c */
...
int func_renamed(void) { /* rename original function */
return 0;
}
int (*const volatile func)(void) = func_renamed; /* indirect calls through
this pointer */
...
then call func() to get the non-inlined version. It's even portable. ;)
-- Mat.
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] filter options
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 15% > > Mark OK, I just uploaded a new lame.c, now options look like: --lowpass --lowpass-width --highpass --highpass-width I switched the meaning of freq from Hz to kHz, because of the --freq and --resample options. You have to pass (re)sample frequencies in kHz too. If you don't pass the ...-width options, they will be 15% of lowpass/highpass, just as Mark suggested. Thank you Ross for the info about radio frequencies. Coding FM quality with sharp cutoff would look like: lame --highpass 0.05 --highpass-width 0 --lowpass 15 --lowpass-width 0 -m j -b 128 Robert -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: Re: [MP3 ENCODER] profiling
> -fno-inline. It's all in the info file (and unlike most stuff in info, this is > easy to find :-). But I want *everything else* inlined (if possible), except this one function. later mike -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] profiling
> How do I make absolutely sure that a function appears in the gprof profile. > It isn't declared implicitly inline, > but the optimizer (-O9) inlines lots of things. Is there a keyword to prevent > it? -fno-inline. It's all in the info file (and unlike most stuff in info, this is easy to find :-). Monty -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] profiling
Hi all, I'm sure I've asked this before, but i've got a terrible memory (and I'm having troubles getting my mail folders out of my backups): How do I make absolutely sure that a function appears in the gprof profile. It isn't declared implicitly inline, but the optimizer (-O9) inlines lots of things. Is there a keyword to prevent it? later mike -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] filter options
Hi Robert. Hopefully someone else can help with the Win32 compile - please :) I think Marks suggestion of using a width option may be less confusing and easier to use. As far as radio is concerned, the 2 main presets would be something like this: 1. Music/commercials: FM50 - 15000 hz, stereo: --lowpass 15000 --lowpass_width 0 (sharp cut-off) -m j -b 128 Not sure whether a highpass at 50hz would be beneficial or not. 2. High quality voice (interviews etc). I'm not sure what the best settings for this would be. I haven't analysed voice frequencies so I'm guessing at the following: HQvoice 200 - 1 hz, mono: --lowpass 1 --highpass 200 -m m -b 64 Support for variable bit-rate should be added to the presets as well. If -v is specified, an equivalent -V setting should be defaulted. I presume -V4 could be used for both of these. The -b settings would have to be increased or removed. Cheers, Ross. Robert Hegemann wrote: > Hi Ross, > I have no Windows, so I can't help you with a Win32 version. > > But I want to start a collection, that could become something > like presets for Lame: > > phone 300 - 3400 hz, mono: > --highpass_l 300 > --lowpass_h 3400 > --noshort(preechoes are a minor issue) > --resample 16(8 would be better, needs MPEG2.5) > -m m -b 16 (8 is a litle bit to low :( > > CD 2 - 2 hz, stereo: > --lowpass_h 2 > --resample 44.1 > -m s -b 192> > And as you are working for a radio station, you could probably > extend the list for different radio types, studio standards, etc. > > Robert -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] lame 3.58beta
lame3.58beta is on the web site. This is also tag 'lame3_58beta' in the CVS repository, since CVS does not allow a '.' to be in the tag name. It is just a tag, not a branch. My (limited) understanding of CVS makes me think the beta releases do not warrent being a branch, but the 'official' releases should be a new branch. That way we can update the official release independently of later beta versions. I will put out a new official release this week since this beta code should fix those intermittent crashes caused by the ix overflow. Mark Here is the list of changes on the web site: This does not include changes directly checked into CVS since they are too hard for me to keep track of. If you have some changes that were checked into CVS before today, send me email and I will add them to the history file on the web page. LAME 3.58beta December 13 1999 Segher Boessenkool: More accurate quantization procedure! Enabled with -h. Mathew Hendry, Acy Stapp and Takehiro Tominaga: ASM optimizations for quantize_xrpow and quantize_xrpow_ISO. Chuck Zenkus: "encoder inside" logo on web page Mark Taylor: a couple people have asked for this. Allow LAME to overide VBR_min_bitrate if analog_silence detected. Analog_silence defined a la Robert: energy < ATH. An Van Lam: Valid bitrates were being printed for layer 2, not layer 3! Ethan Yeo: Makefile.MSVC updated Mark Stephens: updated all MSVC project files Mark Taylor: MS switching is now smoother: ms_ratio average over 4 granules Takehiro Tominaga: Scalefactor pre-emphasis fixed (and now turned back on) Takehiro Tominaga: Bug in M/S maskings: switch to turn on stereo demasking code was buggy. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Using libm or not
> Should we use libm library in linking ( -lm) or not ? On Linux with glibc and gcc>2.7, all the calls you'd be making to libm actually become ASM macros. Linking with libm is still required. Monty -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] LAME M/S thresholds
> >That's right. therefore in FAAC you will see this: > >if ((nb[0][b] <= 1.58*nb[1][b])||(nb[1][b] <= 1.58*nb[0][b])) > >and in LAME: > >if ((ratio[0][b] >= 1.58*ratio[1][b])||(ratio[1][b] >= 1.58*ratio[0][b])) > > > >Or the other way around, I don't have access to my source code where I am > now. > >Also I think that LAME is doing these calculations with the final ratios, > >while I in FAAC use the nb values (can't remember how they were called in > >LAME, sorry). > >The beta source code is available on the developers page, I hope you can find > >them, it will make this a lot clearer. > > > >Bye, Menno > > Sorry, that was not entirely the reason. Basically the values are used in a > whole different way, than in LAME. Just take a look at psy_step11andahalf(). > > Menno > Hi Menno, I took a look at psy_step11andahalf() and couldn't understand the reasoning behind it. Maybe you could explain some? I dont have the AAC ISO docs, so I'm just using the Johnson and Ferreira reference. In that paper, the MLD correction is used to compensate for stereo demasking, but only at low frequencies. The MLD seems to be constructed so that at high frequencies, the maskings in either channel will use the maximum over both channels, but at low frequencies masking in one channel will only effect the other channel up the the level of the MLD. Thus at low frequencies, a signal in the mid channel will have less masking on the side channel. Under this theory, MLD must be in increasing function of frequency. However, looking at this again and comparing with your formulas, I think there is a mistake in LAME's implementation: The comparison of mid and side maskings should be done with the true maskings, not the masking/energy ratios. I will try to fix this today. Mark the calculation should be done It looked like both the switch to use the "MLD" correction, and the correction are used in the opposite sense as they are in LAME. In LAME, -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Status of noise quantization
On Mon, 13 Dec 1999, Mark Taylor wrote: > I dont think we should make this change. Preserving the amplitude > (and thus the actual shape of the wave form) seems more important than > the energy. Also, using fabs(i^8/3 -x^2) is an unusual definition of > noise that I have never seen in any of the technical papers. > > with my poor listening test, I think we should take noise calculation > > >> fabs(i^8/3 - x^2) > > instead of > > >> ( i^4/3 -x ) ^2 He's saying that it sounds better with listening tests. I think that because of that, it should be given a more in-depth look then "I've never seen anything in the lit do that". Can someone who's implimented these changes please produce some test samples? -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Using libm or not
Hey ! Should we use libm library in linking ( -lm) or not ? There is no difference in CBR in quality (only speed). In VBR there is difference in byte by byte comparing, and libm is about 13% slower. Regards Piotr Borowski -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] filter options
> X-Authentication-Warning: cs.csoft.net: $s=geek.rcc.se doesn't match >$[EMAIL PROTECTED] > X-Authentication-Warning: geek.rcc.se: majordom set sender to >[EMAIL PROTECTED] using -f > From: Robert Hegemann <[EMAIL PROTECTED]> > Date: Sun, 12 Dec 1999 23:21:56 +0100 > Content-Type: text/plain > Sender: [EMAIL PROTECTED] > Precedence: bulk > Reply-To: [EMAIL PROTECTED] > X-MIME-Autoconverted: from quoted-printable to 8bit by cs.csoft.net id QAA29448 > X-UIDL: !e)e97c4!!'DOe9(4G!! > > I just want to notify, that I added filter commandline > options to LAME in cvs. > > lame --highpass_l 300 --highpass_h 330 > --lowpass_l 3100 --lowpass 3400 > --resample 16 > --noshort > -b 16 > -m m > filename.wav > > => would produce an output with phone quality. > > 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 15% Mark -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Status of noise quantization
I dont think we should make this change. Preserving the amplitude (and thus the actual shape of the wave form) seems more important than the energy. Also, using fabs(i^8/3 -x^2) is an unusual definition of noise that I have never seen in any of the technical papers. Mark > > >> hmm, I'm not so sure about this. The noise measure used in > >> LAME is based *not* on the error in the energy > >> > >> fabs(i^8/3 - x^2) > >> > >> but instead on the energy of the error: > >> > >> ( i^4/3 -x ) ^2 > >> > >> Since LAME picks scalefactors to try to minimize the second > >> quantity, I think we should use a quantization consistant with > >> this error measure? > > S> Ahah. I think the scalefactor picking should be consistent with > S> the first formula instead :-) > > S> But seriously, what the ear hears is energy, not amplitude; so > S> the second formula is not an accurate description of the > S> audible error. > > I think this is right, Segher. > > with my poor listening test, I think we should take noise calculation > >> fabs(i^8/3 - x^2) > instead of > >> ( i^4/3 -x ) ^2 > --- > Takehiro TOMINAGA // may the source be with you! > -- > MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) > -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Status of noise quantization
> "M" == Mathew Hendry <[EMAIL PROTECTED]> writes: >> From: Stapp, Acy [mailto:[EMAIL PROTECTED]] >> >> Has this stabilized? M> Hasn't changed for at least a few days. ;) Wait a moment ! I don't think so > "S" == Segher Boessenkool <[EMAIL PROTECTED]> writes: >> hmm, I'm not so sure about this. The noise measure used in >> LAME is based *not* on the error in the energy >> >> fabs(i^8/3 - x^2) >> >> but instead on the energy of the error: >> >> ( i^4/3 -x ) ^2 >> >> Since LAME picks scalefactors to try to minimize the second >> quantity, I think we should use a quantization consistant with >> this error measure? S> Ahah. I think the scalefactor picking should be consistent with S> the first formula instead :-) S> But seriously, what the ear hears is energy, not amplitude; so S> the second formula is not an accurate description of the S> audible error. I think this is right, Segher. with my poor listening test, I think we should take noise calculation >> fabs(i^8/3 - x^2) instead of >> ( i^4/3 -x ) ^2 --- Takehiro TOMINAGA // may the source be with you! -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] filter options
Ross wrote: > That's great! I've been waiting for these settings. Can someone please > compile a Win32 version. Maybe a new beta version should be released? > > Ross. Hi Ross, I have no Windows, so I can't help you with a Win32 version. But I want to start a collection, that could become something like presets for Lame: phone 300 - 3400 hz, mono: --highpass_l 300 --lowpass_h 3400 --noshort(preechoes are a minor issue) --resample 16(8 would be better, needs MPEG2.5) -m m -b 16 (8 is a litle bit to low :( CD 2 - 2 hz, stereo: --lowpass_h 2 --resample 44.1 -m s -b 192 And as you are working for a radio station, you could probably extend the list for different radio types, studio standards, etc. Robert -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] Status of noise quantization
> From: Stapp, Acy [mailto:[EMAIL PROTECTED]] > > Has this stabilized? Hasn't changed for at least a few days. ;) > Do I need to redo the assembly for it? Don't think so. I removed the -0.5s from the asm quantize_xrpow, you might want to check that version for "optimality". -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Status of noise quantization
Has this stabilized? Do I need to redo the assembly for it? -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Lame at low bitrates
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 needs some more tuning for sample frequencies other than 44.1 khz ? * at low bitrates we apply filters (due to high compression ratios) But how does this effect the calculation of PE and MS ratios? PE and MS ratios are based on a full frequency spectrum (at least the higher frequencies, MS ratios). * short blocks get an extra amount of 500 bits This is optimized for bitrates of 128 kbits at 44.1 khz. Is this amount too large for low bitrates, say 16 kbits? Comments are welcome. Robert -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] bitrate_index question; prev. was Layer II VBR
In another thread (new detail question below): On Fri, 10 Dec 1999, Gabriel Bouvigne wrote: > Layer II VBR is ISO compliant. However, players are not required to support > it (unlike layer III players). Sorry, I was wrong; the above is indeed true; the standard says; "In order to provide the smallest possible delay and complexity, the decoder is not required to support a continuously VBR when in Layer I or II. Layer III ... . However, in free format, fixed bitrate is required. The decoder ..." [fixed is explained earlier as always==N or N+1 slots] Ok, but this is still a bit confusing to me; does this mean that when an encoder would try ((layer II)) VBR, eg switching from 192 to 384 kbit/s and back etc., he would or would not be allowed to also switch to "free" (bitrate_index = ) ? I.e. is it allowed to do e.g. 192, 384, free, 384, 192, free, free, etc ? If not then the standard should better say something like: "free" and specified bitrate frames may not be intertwined. If allowed; then the above "However..." sentence in the standard should have been removed/rewritten? [-> if not in VBR mode: free=fixed, else(VBR): do whatever you want] Do you agree? regards, Patrick. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
