Re: [MP3 ENCODER] Re: Severe bug in lame (when using -k)
Mark Taylor schrieb am Die, 25 Jul 2000: > -X: picks which of 7 algorithms will be used to determine if > one noise 'signature' sounds better than another. well, 0...7, seem to be 8 different ones ;-) > -X should now be considered a permanent option. -Y and -Z change > >from release to release and are just for testing things. > Right now, -Y does nothing, and -Z turns on Takehiro's CBR > subblock gain code. > > > Mark So, should we give -Xn a name? How about "--quant-compare n" ? Robert PS: I had to fix the noise calculation, as -X3/4 didn't work anymore lately -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Re: Severe bug in lame (when using -k)
Hi. On Tue, 25 Jul 2000, Mark Taylor wrote: >> >Thanks for finding this. This was a subtle & rare bug in CBR, >> >triggered by the -k option. >> Can you tell me when this bug was introduced? I listened to some of my recent >> encodings and found this blip in about every 20th track. >Were they all made with -k? Yes, Don't Panic :) >I would guess it was introduced in 3.85: it requires a combination of >scalefac_scale (defaulted in 3.85, before that enabled with -Y ), and >not using enough low pass filtering for the amount of compression. OK, so I know how how many I have to check (and redo). Is the blip always as loud as the one I found or are there variations? cu arne -- Arne Zellentin [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re[2]: [MP3 ENCODER] Re: Severe bug in lame (when using -k)
Hello Mark, MT> I would guess it was introduced in 3.85: it requires a combination of MT> scalefac_scale (defaulted in 3.85, before that enabled with -Y ), and MT> not using enough low pass filtering for the amount of compression. If I believe the history log and my own tests, scalefac_scale was only defaulted since 3.86a and not yet in 3.85. -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Re: Severe bug in lame (when using -k)
> > >(-k, by the way, is *always* a bad idea. It overrides LAME's > >default lowpass filters. It will cause ringing and twinking > >at 128kbs) > > Are there examples for this? When I did some listening tests I noticed the > missing frequencies but nothing else. Does the FhG encoder still do this > (cutoff), too? Would it be feasible to use a slightly higher --lowpass or > does sfb=21 interfere? What kind of curve is used by the lowpass? > The filter uses a 32 band "polyphase" filter bank. The default behavoir is to zero out the last N banks, but you can add some kind of curve to this by increasing --lowpass-width. N depends on the compression ratio: the less compression, the less filtering. The amount of filtering used is very similar to FhG at >= 128kbs. At low bitrates, the automatic filtering code still needs work. > > Where can I find information about the -X -Y and -Z options? I know that > they're experimental and undocumented, but... > -X: picks which of 7 algorithms will be used to determine if one noise 'signature' sounds better than another. -X should now be considered a permanent option. -Y and -Z change from release to release and are just for testing things. Right now, -Y does nothing, and -Z turns on Takehiro's CBR subblock gain code. Mark -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Re: Severe bug in lame (when using -k)
> > Hi Mark, > > On Mon, 24 Jul 2000, Mark Taylor wrote: > >Thanks for finding this. This was a subtle & rare bug in CBR, > >triggered by the -k option. > > Can you tell me when this bug was introduced? I listened to some of my recent > encodings and found this blip in about every 20th track. > Were they all made with -k? I would guess it was introduced in 3.85: it requires a combination of scalefac_scale (defaulted in 3.85, before that enabled with -Y ), and not using enough low pass filtering for the amount of compression. Mark -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Re: Severe bug in lame (when using -k)
Just a quick question, when cdex refers to "high quality" that "may produce pinging" they are not using the -k option are they? Also this bug only applies to VBR right? Regards, Abe Corrie --- Arne Zellentin <[EMAIL PROTECTED]> wrote: > Hi Mark, > > On Mon, 24 Jul 2000, Mark Taylor wrote: > >Thanks for finding this. This was a subtle & rare > bug in CBR, > >triggered by the -k option. > > Can you tell me when this bug was introduced? I > listened to some of my recent > encodings and found this blip in about every 20th > track. > > >(-k, by the way, is *always* a bad idea. It > overrides LAME's > >default lowpass filters. It will cause ringing and > twinking > >at 128kbs) > > Are there examples for this? When I did some > listening tests I noticed the > missing frequencies but nothing else. Does the FhG > encoder still do this > (cutoff), too? Would it be feasible to use a > slightly higher --lowpass or > does sfb=21 interfere? What kind of curve is used by > the lowpass? > > >Note to developers and -X6 fans: [...] > > Where can I find information about the -X -Y and -Z > options? I know that > they're experimental and undocumented, but... > > I'm asking too many questions, developers should not > write e-mails, they > should develop code :-) > > Thank you and > > cu arne > -- > Arne Zellentin > [EMAIL PROTECTED] > -- > MP3 ENCODER mailing list ( > http://geek.rcc.se/mp3encoder/ ) __ Do You Yahoo!? Get Yahoo! Mail Free email you can access from anywhere! http://mail.yahoo.com/ -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Re: Severe bug in lame (when using -k)
Hi Mark, On Mon, 24 Jul 2000, Mark Taylor wrote: >Thanks for finding this. This was a subtle & rare bug in CBR, >triggered by the -k option. Can you tell me when this bug was introduced? I listened to some of my recent encodings and found this blip in about every 20th track. >(-k, by the way, is *always* a bad idea. It overrides LAME's >default lowpass filters. It will cause ringing and twinking >at 128kbs) Are there examples for this? When I did some listening tests I noticed the missing frequencies but nothing else. Does the FhG encoder still do this (cutoff), too? Would it be feasible to use a slightly higher --lowpass or does sfb=21 interfere? What kind of curve is used by the lowpass? >Note to developers and -X6 fans: [...] Where can I find information about the -X -Y and -Z options? I know that they're experimental and undocumented, but... I'm asking too many questions, developers should not write e-mails, they should develop code :-) Thank you and cu arne -- Arne Zellentin [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Re: Severe bug in lame (when using -k)
Hi Arne, Thanks for finding this. This was a subtle & rare bug in CBR, triggered by the -k option. (-k, by the way, is *always* a bad idea. It overrides LAME's default lowpass filters. It will cause ringing and twinking at 128kbs) Note to developers and -X6 fans: The problem is in frame 2326, side channel. It has a lot of energy > 15khz. Trying to encode these frequencies got LAME stuck in the following loop: 1. increase scalefactor for bands with distortion by 1. 2. decrease global_gain so bits < targ_bits (decrease in global_gain exactly offsets change in scalefactor) net effect on bands with distortion: NO CHANGE! Thus over, over_noise, max_noise are all unchanged, but tot_noise is increasing. In this case, -X0 would accept the newer quantization as better. So LAME just kept increasing the scalefactor bands and decreasing global_gain until it got into a bizzare configuation. The fact that scalefac_scale is now enabled, allowed LAME to further aggravate the situation and create an audible glitch in the mp3 file. I just committed the following fix: If over == best->over, and over_noise == best->over_noise, then use tot_noise to decide on the best quantization. This makes -X0 (the default) very close to -X6, although -X0 still gives precedence to 'over'. Changing that would be too radical at this time :-) Mark > > Hi Mark, > > I accidentially discoverd a bug in lame which I really can't understand. I > have one wav audio track to which, when encoded, a short period of noise is > added. I'm not able to describe this, listen yourself: > http://www.home.unix-ag.org/arne/x/cdda.wav.mp3 (1.1MB) > the original wav-file is at > http://www.home.unix-ag.org/arne/x/cdda.wav (12MB) > The noise appears between time offset 1:00 and 1:01 and is clearly audible. > What I consider strange is that it doesn't seem to appear when > * encoding with other parameters than -h -k -b 128 > * only a part of this track is used, i.e. I tried this with a rip which > started at 0:50 in order to save bandwidth -> no noise > > I used cvs-lame, one of today, 2 hours ago and one with 2 days of age. > > I'm writing directly to you because the part of the track is too long to be > considered legal. Please don't pass it unnecessarily around. I guess it's ok > for technical examination. > > Of course I still consider lame the best MP3 encoder around, nice work... > > cu arne > -- > Arne Zellentin > [EMAIL PROTECTED] > -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
