[MP3 ENCODER] TMN(b) and NMT(b) values...
Hi Everyone, I just have a couple of questions: a) where do the tone-masking-noise and noise-masking-tone values (29 and 6 dB) come from and b) why are they suddenly 18 and 6 dB for MPEG-2 AAC??? Thanks in advance, Erik-- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] filter options (and several questions)
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 >...etc May I make a case for --highpass 0.016 ? FM Radio usually goes down a bit lower than 50Hz. The lowest note on a conventional piano is 27.5Hz, the orchestral `double-bass' plays down to 32.7Hz, and a 32-foot organ pipe, playing the lowest note on the pedal board, is 16.35Hz, though not many home systems will reproduce this except to annoy the neighbours. It is true that some FM stations (in the UK at least) put filters in below 30Hz to allow in-band switching tones to be used between studios. I hope this is not too much of an imposition, but has anyone documented the various `-X n' options? I'm getting better results on choral music with -X 5 while some orchestral music sounds better with -X 4. The existing documentation is *very* helpful in other aspects, though. In psymodel.c, there are a couple of commented-out sections. One is around the bark computations... is the table you supply generally thought to work better than the calculated bark values? What is the effect of #define NEWS3 in psymodel.c, which enables certain extra computations within the spreading function routines? My choral music example (possibly) sounds better without this defined (as you have left it in the code). In your `USAGE' file, you have kindly included my old notes about filtering and sample rates. Now that these facilities are included within LAME, perhaps the notes are no longer needed? I would say, however, that at 96kbit/s and 32kHz sample rate, choral music in a large reverberant setting sounds better with --noshort enabled and (even) -m f. Thanks, John Hayward-Warburton [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] List of variables used in Lame
Hi everyone, I just wondered if there is something like a list of variables that are used in the LAME code? For me, and I guess for other newcomers too, this would make life a lot easier. If there isn't such a thing perhaps it's not a bad idea to start one. What I'm thinking of is something like e.g.: sb: [int], stands for scalefactor band, used to denote the index into certain tables chn: [int], stands for channel, gives the channel-index, compliant with ISO standard numbering etc... Let me hear what you think of it! Erik PS: If a lot of people like the idea, I'm willing to maintain such a list!-- 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 ? > 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. Perhaps a stupid question, but what is libm ? Regards, Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] bitrate_index question; prev. was Layer II VBR
> 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 ? Free bitrate isn't allowed to be mixed with any other bitrate. Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] filter options
John Hayward-Warburton wrote: > It is true that some FM stations (in the UK at least) put > filters in below > 30Hz to allow in-band switching tones to be used between studios. Not that we use a filter here but I am aware that a lot of stations in the USA and elsewhere use a highpass filter which I thought was around 50hz (but maybe its 30hz) to allow more energy in the more audible freqs and therefore produce a louder sound. "Louder the better" is usually the motto. Maybe the highpass option should be removed altogether from the FM preset. > I hope this is not too much of an imposition, but has anyone > documented the > various `-X n' options? I'm getting better results on choral > music with -X 5 > while some orchestral music sounds better with -X 4. The existing > documentation is *very* helpful in other aspects, though. What does the -X parameter do exactly? -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Using libm or not
> From: "Gabriel Bouvigne" <[EMAIL PROTECTED]> > > Perhaps a stupid question, but what is libm ? The maths library in C compilers in the style of Unix cc. It contains the functions; some compilers don't link with it by default. -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] filter options
Ross Levis wrote: > What does the -X parameter do exactly? Only from looking at the code (and not understanding more than half of it...): It's all in quantize.c (look for references to `experimentalX'). It affects the output of function quant_compare(). John [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] filter options
> 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 to make this decision: -X0 the actual is better if it has less distorted scalefactor bands, or if it's equal to the best so far and the sum of noise over the thresholds is less than the best so far -X1 the actual is better if the maximum noise over all scalefactor bands is less than the best so far -X2 the actual is better if the total sum of noise is lower than the best so far -X3 the actual is better if the total sum of noise is lower than the best so far and the maximum noise over all scalefactor bands is less than the best so far plus 2db. -X4 this is a bit complicated, I think Greg Maxwell should explain this ;) -X5 the actual is better if the sum of noise over the thresholds is less than the best so far or if they are equal and the total sum of noise is lower than the best so far -X6 the actual is better if the sum of noise over the thresholds is less than the best so far or if they are equal and if the maximum noise over all scalefactor bands is less than the best so far or if they are equal and the total sum of noise is less or equal the best so far All these are EXPERIMENTAL and may disappear sooner or later. Maybe we find the one and only criterion someday. I hope it's getting a bit clearer to you. For the details take a look at quantice.c, search for experimentalX. Robert PS: -X6 is new, I just checked it in -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] -X preferences
Thanks for the info Robert. Am I right in thinking -X0 is the default? Is there anyone testing the different -X settings on different music types. Maybe the results of tests should be published somewhere for comparison? John Hayward-Warburton has mentioned his preferences with -X4 & 5 in choral music. Maybe you could try the new -X6 option John. Ross. Robert Hegemann wrote: > > 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 to > make this decision: > > -X0 the actual is better > if it has less distorted scalefactor bands, > or if it's equal to the best so far > and the sum of noise over the thresholds is less > than the best so far > > -X1 the actual is better > if the maximum noise over all scalefactor bands is less > than the best so far > > -X2 the actual is better > if the total sum of noise is lower than the best so far > > -X3 the actual is better > if the total sum of noise is lower than the best so far > and the maximum noise over all scalefactor bands > is less than the best so far plus 2db. > > -X4 this is a bit complicated, I think Greg Maxwell should > explain this ;) > > -X5 the actual is better > if the sum of noise over the thresholds is less > than the best so far > or if they are equal > and the total sum of noise is lower than the best so far > > -X6 the actual is better > if the sum of noise over the thresholds is less > than the best so far > or if they are equal > and if the maximum noise over all scalefactor bands is less > than the best so far > or if they are equal > and the total sum of noise is less or equal > the best so far > > All these are EXPERIMENTAL and may disappear sooner or later. > Maybe we find the one and only criterion someday. > > I hope it's getting a bit clearer to you. For the details take a look > at quantice.c, search for experimentalX. > > > Robert > > PS: -X6 is new, I just checked it in > -- > MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) > -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Change -V default to 6?
(LAME v3.58) -V6 is producing very similar average bitrates to Xings normal setting -- roughly 128kb/s. -V5 is averaging around 140kb/s. The default -V4 is getting up towards 160kb/s which is producing somewhat larger files. I think the default should be 6 (or at least 5) to be more consistent with the standard 128kb/s filesizes which most of the international mp3 community are using. Just my opinion. Ross. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] filter options
On Tue, 14 Dec 1999, Robert Hegemann wrote:
> -X4 this is a bit complicated, I think Greg Maxwell should
> explain this ;)
-X4 resulted from testing, overthinking and sleep deperivation. :)
It's better if:
The worst subband is less or equal to the masking while the previous
best's worst subband is 2db greating then mask
or
The worst subband and the prior best worst beat the masking threshold
and the current worst comes within 2db the prior best worst and
the current has less total noise-masking
or
The current worst subband is equal or less then masking, while the prior
best worst is greater then masking and the current worst comes within
2db of the best worst and the current noise-masking is less
then the best noise-masking + over noise (i.e. over noise is counting
twice).
or
The current worst is less then masking and the best worst is greater
then masking -0.5 and the best worst+1 is greater then the current worst
and the current noise-masking + overnoise is less then the best
noise-masking + overnoise
or
argh. You get the point. It's too complicated.
It seemed to make a real advantage here, but it could have been more of a
result of too small a test group..
I was trying to accomplish some sort of balence between the worst noise
and the total noise. I later went completely nuts and made a completely
crazy version that all the subbands and not just worst and total. But I
never had a way to tune it, so I gave up. :)
Is it better to have less overall noise even when there is more clustered
in a single/few subbands, or have the subbands getting about equal noise,
and the expense of a bit higher overall?
No one knows.
The current code lets us only easily look at the worst and
the total. All of the other -Xes ignore the worst case subband unless the
overall noise is less (except for 6 now, which only considers it when
there is no over noise (or no difference in over noise), which I think
puts too much faith in the psyco model).
I don't think this is good, because I think that
the 'more focused' noise will be more noticable even though the overall
noise is less.
However, I dont really have any good tests to back that up, and my current
implimentation is too damn messy.
Perhaps it should be replaced with:
if (experimentalX==4) {
better = ( ((max_noise < best_max_noise)
&&(tot_noise < best_tot_noise)) ||
((max_noise+1 < best_max_noise)
&&(tot_noise < best_tot_noise+2) ||
((max_noise < best_max_noise+1) ||
&&(tot_noise+2 < best_tot_noise)) ) ;
I.e. If it's better it's better
If the max noise is >1db better then it's still better
if the total is upto 2db worse
If the max noise is upto 1db worse then it's still better if
the total is at least 2db better.
I'd do it with ratios (i.e. each db of better worst allows 1.5db of worse
total) but I'm trying to not be incomprehensiable again. :)
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
