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: TNS Save Bit or Not !? (Read 4008 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

TNS Save Bit or Not !?

From some previous quotes of Ivan,

TNS eliminates pre-echo in some signals - but too much TNS introduces artifacts of its own kind, and also TNS could consume many bits in a frame, and good switching mechanism is also required.

and referencing the paper "Enhancing the performance of Perceptual Audio Coders by Using Temporal Noise Shaping (TNS)".


TNS can elimiate the pre-echo somehow by performing time-domain noise re-allocation. However, where is the bit-reduction benefit remaining a question mark in my mind.

A direct idea for general, the prediction gain (a reduction of residual signal energy) can reduce the dynamic range of spectral coefficients. Subsequently, a few bits require to be assigned to those shrinking coefficients.

However, the open-loop DPCM which is the kernel of TNS  adapts its reconstructed signal in its PSD based on the assumption of bring the same SNR to the coded coefficient. That means a bit to a shrinked coefficient and a un-shrinked coefficient both represent a 6-db SNR improvement.  More specifically, no matter the amplitude of residual signal energy is, the bit-assignment to each coefficent is fixed when the SMR is generated if you wanna achieve noising shaping after decoding. (that also indicates the way how to compensate the masking curve when the TNS is applied)

If the above discussion is correct, the prediction gain won't save any bits. The way TNS saving bit is taking care of pre-echo effect without switching to short block which consumes several side-info bits.

In my concern, the existence of TNS bring much encoding strateggy when one implements his own codec. TNS  can be applied at long or short block. It can also combine with the block-switching to get a better performance mentioned by Ivan.

In my opinion, we don't have all the TNS field is filled up at the same time. i.e. If we have a good block-switch mechanism, the meaning of TNS is dealing with speech signal. TNS in short block like a eating-bit monster.
TNS in long block won't exist, because good block-switch algorithm will switch the block from long to short when transient event happened except speech. Therefore, if we wanna TNS to deal with Pre-echo effect, a better strategy is disabling the option of block-switching.

Therefore, the previous report about the quicktime deficiency at block-switch for castanets.wav maybe  the result of above strategy. However, the listening test shows a block-switching mechanism is suitable to deal pre-echo in that sequence. Although some ears might enjoy the quality of quicktime's whose wider bandwidth can deliver more fidelity by saving some side-info bits to encode higher-band coefficients.


Anyway, what i wanna present is that TNS's position in the MPEG bitstream might mislead the implementor of the real power of TNS. Maybe only me is confused at this topic  .

TNS Save Bit or Not !?

Reply #1 –
TNS is useful for both long and short blocks, it's control is matter of trade-off between consumed bits for TNS data  and  gain introduced by enabling it.

Quote
Therefore, the previous report about the quicktime deficiency at block-switch for castanets.wav maybe the result of above strategy.


Issue is related to time-domain block switching that Dolby consumer codec is using instead of PE based approach.  TNS implementation in this cocdec is exactly the same as in FhG's and Dolby's professional codecs, as described in the AES paper related to Dolby consumer codec.  Castanets.wav problem is related to miss of the few attacks by the fast block switching algo.

TNS Save Bit or Not !?

Reply #2 –
Quote
TNS implementation in this cocdec is exactly the same as in FhG's and Dolby's professional codecs, as described in the AES paper related to Dolby consumer codec.


Would you mind to describe the name of the paper you mention more specifically?
Thank you!

Quote
Castanets.wav problem is related to miss of the few attacks by the fast block switching algo.


I might not update the recent quicktime codec. The one in my hand, encoding castanets.wav at 64kbps
without switching to any short block. Not just the case of missing few attacks because of a simplified switching algo is applied.
(at 64kbps, quicktime will convert the sampling-rate down to 32000 Hz)

TNS Save Bit or Not !?

Reply #3 –
Paper name is "Increased Efficiency MPEG-2 AAC Encoding"

Preprint Number:  5490    Convention:  111 2001-12   
Authors:  Michael J. Smithers,  Matt C. Fellers

TNS Save Bit or Not !?

Reply #4 –
It really seems that QT6 (dolby consumer) does not use short blocks at 64 kb/s & 32 kHz sampling rate  - I've tested it with fatboy, castanets and velvet  samples and none of them had any short blocks.

Interesting - other encoders I've tried use both long and short blocks (and use them a lot for those samples) -  advantage of Dolby is that it has much more bits on disposal thanks to long blocks only, and it is faster,  but disadvantage is that some samples simply can't sound good enough and will sound  smeared (like velvet...)

TNS Save Bit or Not !?

Reply #5 –
When an attack occurs, in the freq domain, a temporal envelope would exists. The present psychoacoustic models that exists today could not take into consideration of this temporal envelope. As a result, when coding an attack in the freq domain, this envelope is not preserve. Anyway, to accurately preserve this temporal envelope would require too many bits. So, this is where the TNS tools and Gain-Control tools comes in.. This 2 tools would flattened the temporal envelope  and reconstruct it at the decoder
without using too much bits.

Please note that using short-block alone is not enough in eliminating pre-echo noise. Short Blocks only limit the pre-echo noise to a much shorter duration. As a result, for certain very tricky clips such as hihat.wav, it is still possible to hear some pre-echo noise, even when properly switch to short blocks.

In theory, the TNS alone should be able to replace block switching.. But this is not the case as in fatboy.wav.

As for gain control, this MP4 specs requires that the gain-control tools used in short-block. It is also much better than TNS as it doesn't smear the tone information in the freq domain.

I think it is still necessary to switch to short-blocks for certain very difficult clips.

TNS Save Bit or Not !?

Reply #6 –
Quote
As a result, when coding an attack in the freq domain, this envelope is not preserve. Anyway, to accurately preserve this temporal envelope would require too many bits.


You means that many bits are spent for the cost of turning on the short block. If you treat transient with long block, "much" bits is needed to preserve the temporal envelope.

Quote
So, this is where the TNS tools and Gain-Control tools comes in.. This 2 tools would flattened the temporal envelope  and reconstruct it at the decoder
without using too much bits.



The bit consumption will be flattened, or the temporal envelope be flatten.?

Quote
In theory, the TNS alone should be able to replace block switching.. But this is not the case as in fatboy.wav


for your experience, what is the theoretical problem of TNS when dealing with "fatboy"?

TNS Save Bit or Not !?

Reply #7 –
Try out some graf plotting simulations.. This Temporal Envelope looks something like a raised cosine function. It looks like  some kind of "spectral leakage". (Depending on how you model the attack; a tone that suddenly increases in amplitud ) It is difficult to code this envelope accurately and it will require a lot of bits to do it. 

The TNS and gain-control will flattened this temporal envelope...  Try modelling in Matlab..

For fatboy.wav, there seemed to be some problem at the low freq portion of the spectrum. As already noted in the TNS MPEG specs, it is not encouraged to filtered from too low frequency.. Somehow, there is where the problem is. I don't know how to overcome the problem. As a result, you have to switch to short block.