Re: [MP3 ENCODER] Full Huffman Search
Roel VdB wrote: MP3Enc flattens the sound and the 16kHz region is not at all coded accurately. Good for lower bitrates, a waste for higher (eg 256S) http://users.belgacom.net/gc247244/analysis.htm#MP3ENC31 is a test I did a while back. mp3enc cutoff is 16 kHz only for low bitrates; it is 20 kHz at 256 kbps. However, both lame and mp3enc removes most of the sound above 16 kHz, even at 320 kbps. Note that some buggy decoders (including mpg123) also tend to cut out all frequencies above 16 kHz. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] noise_shaping_stop
Mark Taylor wrote: I just took a look at this code, and it looks like "noise_shaping_stop" is never used. Robert modifed outer_loop so that: with -X0: it will stop the iteration as soon as it gets a value of over= 0 (all noise allowed noise) with other -X options, it will stop with over=0 if it has done at least 7 iterations. I would like to determine if the extra computations give any benifit (and then make that the default with -h) but I haven't had the time. I would recommend the following: - for quality = 3, always stop iteration, if over == 0 - at quality == 2 (-h), stop after the 7th iteration, if over == 0 - if quality = 1, do a full search (yes, it is slower, but CBR is still realtime even on my 400 MHz CPU) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] tot_noise
Mark Taylor wrote:
Ok, I just made that change. So do you like -X2 or -X3
better than the default?
Well, I actually use -X6, which is based on over_avg_noise;
the change for summing energy instead of dB also applies to this
version. The following code shows this for the long block
case (the same chages apply to the short block noise calculation),
in lame3.85beta.tar.gz:quantize-pvt.c (calc_noise function)
xfsf[0][sfb] = sum / bw;
noise = xfsf[0][sfb] / l3_xmin-l[sfb];
if (noise 1.0) {
over++;
over_noise += (noise - 1.0);
}
tot_noise += noise;
/* max -30db noise below threshold */
noise = 10*log10(Max(.001, noise));
distort[0][sfb] = noise;
max_noise=Max(max_noise,noise);
count++;
}
}
res-tot_count = count;
res-over_count = over;
res-tot_noise = 10*log10(Max(.001, tot_noise));
res-over_noise = 10*log10(1.0 + over_noise);
res-max_noise = max_noise;
res-tot_avg_noise = 10*log10(Max(.001, (tot_noise / count)));
res-over_avg_noise = 10*log10(1.0 + (over_noise / count));
return over;
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Decoder delay
The decoder in LAME seems to calculate delays incorrectly: when encoding in CBR format and decoding back, the delay is 1 sample, and in the case of VBR streams, the decoded file has a large delay (several hundred samples). -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] tot_noise
tot_noise is currently calculated by adding noise values in dB. I think it would be better to sum the energy of noise, i.e. changing tot_noise += noise; to tot_noise += pow (10.0, noise/10.0); This makes -X2 and -X3 much more stable. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Ogg: mostly hype and a _lot_ to be done
Roel VdB wrote: pfff, read the site, critique section. I said "average". [ http://www.r3mix.net ] If it doesn't sound good at 320k CBR, it will be at least as bad in VBR mode. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Block types vs frequency/time resolution
Shawn Riley wrote: So would such poor frequency resolution be fine as long as there are no masking approximations done on what appears to be a DC signal? Well, here's a simple test: I encoded a 1.0 Hz, and a 2.5 Hz sine wave, then the mix of the above two signals, both in L2 and L3 format. LAME 3.83 was used for Layer 3 (at 192 kbps CBR), and the ISO dist10 encoder for Layer 2 (same bitrate). Both programs were able to encode these low frequency signals, without any noticeable error. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Block types vs frequency/time resolution
Shawn Riley wrote: Having noticed the poor frequency resolution, does MP3 format still have the capability of storing frequency/volume information about frequencies that are not whole multiples of the number of blocks per unit time? Or can it only store those specific frequencies? No, it can store other frequencies as well, but having higher frequency resolution allows lower quantization noise for clean tones. However, using long blocks has a disadvantage, too: it will introduce time-domain artifacts, such as pre-echo. This pre-echo effect, at high bitrates (256k) can actually outweigh the advantages of long blocks. That's why Layer 2 (which uses only 32 bands, and has a freq. resolution worse than 600 Hz) can sound better than mp3 at very high bitrates, especially when encoding noise-like signals with sharp attacks (e.g. percussion instruments). "--noshort --resample 24 --lowpass 9.6" is looking increasingly more useful for encoding Enya's music. Unfortunately 160kBit/sec is sometimes not enough for 24kHz sampling (but it's close), with or without the --noshort. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Ogg: mostly hype and a _lot_ to be done
Roel VdB wrote: too much. also, for the moment my mp3's, to be considered transparent, are about 170kbit/s average. why are you aiming at mp3 transparent at 170 kbps ? Try encoding signals like http://members.xoom.com/steve_0401/archive/samples/test1.zip Lame will not be able to transparently encode the four short noises at the beginning of the file, not even at 384 kbps. Vorbis may be better in the future, although it needs _lots_ of tuning yet. 130-150kbit? be aware that on better Q systems you hear a difference, and imho it wouldn't be bad to get better quality at higher size. Then why not use mp2 at 384k ? Or even some lossless format ? -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] What's Safe-VBR mode?
Ross Levis wrote: and any ideas when -Y will become default. Does it still need some testing or tuning? I tried -Y with lame 3.83, and on some sounds, it does make audible artifacts, so probably -Y still needs testing. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Bug with -q1 (win32)
Ross Levis wrote: I've inadvertantly encoded 5 or 6 albums with this switch. Is there likely to be any quality problems that you know about. Ross. I do not think that this has much effect on the quality, however, if you want to use the "-X" switch (also undocumented, although it should be), -q 1 is recommended for not stopping the quantization loop when over=0 (and it may be actually the same thing that sometimes causes the endless loops). -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] default high pass filtering
Segher Boessenkool wrote: On some signals, however, highpass filters can do bad things as well. For example, after processing this file http://www.geocities.com/SiliconValley/Bit/5683/test1c.zip with a 5 Hz highpass filter, the peak amplitude increased to about 52000, resulting in lots of clipped samples. True. But you should always adjust the volume to less than 100% before encoding, because the clipping happens anyway. Can be worse with a low cut filter, though. Yes, low frequency "ringing" caused by the highpass filter can do bad things on some signals (such as this test). Anyway, what filter is it? How sharp etc. I used MiXViews (a sound editor) on Linux, elliptical filter with these parameters: passband cutoff: 6 Hz stopband cutoff: 4 Hz passband ripple: 0.1 dB stopband attenuation: 90 dB (note: I converted the signal to float format before filtering). Btw. most mp3 encoders seem to have problems with the 4 short noises at the beginning of the file (pre-echo is cleanly audible). -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] default high pass filtering
Segher Boessenkool wrote: Perhaps someone could find a wav wich produces this disturbing high frequency echos while encoding with lame due to low frequency signals. This could be bassNN_N.wav from SQAM (at low bitrates). about anything from "Grotus" as well (_very_ fat bass) On some signals, however, highpass filters can do bad things as well. For example, after processing this file http://www.geocities.com/SiliconValley/Bit/5683/test1c.zip with a 5 Hz highpass filter, the peak amplitude increased to about 52000, resulting in lots of clipped samples. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
