Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: LAME "--allshort" (Read 3364 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

LAME "--allshort"

Will LAME "--allshort" solve all pre-echo problem? I'd tried



LAME --preset 96 -m f --nssafejoint --allshort --nspsytune


It sounds like subband encoder, full of clipping
at low bitrates! When the "--allshort" switch is on, it sounds horrible unless
bitrate higher than 160 kbit/s is used.

Is LAME using subband encoding method when '--allshort" is on?

LAME "--allshort"

Reply #1
--allshort uses only short blocks, which are meant for transients. The switch is no solution, because it would be insane to use only short blocks.

Short blocks, which have shorter transform window length than longblocks, provide better time resolution (thus less pre-echo), but worse frequency resolution.

--allshort is a switch for experimental purposes, to check specific problems in blockswitching algorithm. Never use it in regular encodings.
Juha Laaksonheimo

LAME "--allshort"

Reply #2
I have also tried --allshort, and noticed that window-transition effects seem to become audible, unless very precise quantization (=> insane bitrates) is used.

Well, I guess that's an issue due to the MDCT transform failing to provide seamless block transition because of the too inaccurate transform-domain coefficients...

What do you guys think ?

LAME "--allshort"

Reply #3
Reasons why short blocks are giving such artifacts are:

1. LAME does not have tonality estimation for short blocks (and it is hard to estimate tonality for short blocks anyway)

2. Short blocks require much more side data

3. Frequency resolution of the short blocks is too small to give any precise psychoacoustics measurement

Therefore, short blocks require much more bits to code signal properly - but, they have much better time resolution, which makes them necessary for signals with sharp attacks.

Using --allshort in LAME (or,  -svc 0.0 in Psytel AACEnc - it is also interesting, since short blocks in AAC are even shorter than in MP3)    is a killing of codec performance, and completely wrong way of using transform codec.

LAME "--allshort"

Reply #4
--allshort is a testing only option. I an ideal world, end users should not even know about it.

Yes, using --allshort the result is bad. There are 2 cause:
*as Ivan mentionned, right now short blocks are lacking some features in Lame, like tonality estimation

*if using only short block was THE solution, then why would there be the possibility to use long blocks? And why would there be codecs using long blocks?

 

LAME "--allshort"

Reply #5
Right - transform based coders like MP3, Ogg and AAC can have several (usually two)  window lengths - encoder is responsible for decision whether one block is suitable for coding with long window (if several properties of the signal are met)  or  short (if the signal contains strong attacks and increase of bit usage would faciliate reducing of pre-echo)

So, it is left to the encoder -  forcing only long or only short blocks ruins the encoder performance, and therefore should never be used for purposes other than debugging.

I'm telling that because some wise-guy could read this,  try to enable only long blocks and look at his favorite spectral analysis utility - and say "hey - this is perfect frequency response, perfect tonal purity.. wow" - and he might start encoding everything with that crippled encoder