Skip to main content
Topic: Noise-shaping curves and downstream lossy compression (Read 16550 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Noise-shaping curves and downstream lossy compression

Reply #25
No, long word-lengths are not the answer.

Quantisation distortion is readily audible and FAR worse than any dither noise. I really don't understand your fascination with encoding at long word-lengths. I have shown that, unless you can guarantee that decoding happens at a word-length the same or longer, you merely introduce truncation with all the attendant distortion artifacts.
Yes, but...

1. mp3 encoding adds artefacts. Often, they are inaudible. It depends on bitrate, encoder, and content. It's not possible to pick a bitrate and encoder that is artefact-free for all content and all listeners.

2. Quantisation distortion due to truncation from 24-bits to 16-bits is just another artefact. For most content, most of the time, it is entirely irrelevant - completely inaudible, and at a far lower level (subjectively and objectively) than the mp3 encoding artefacts.

3. There is no guarantee that your dither will survive encoding to act as effective dither at the output. Strictly speaking, the signal should be re-dithered at the output - it's just luck that most signals (dithered or not!) adequately self-dither most of the time. Your original dither isn't really "dither" at the output of the decoder - it's a noisy signal which might do the job well enough.

4. When encoding, dither costs bits. Noise shaped dither costs even more bits. This is well agreed, I think. If bits are in short supply, dither could reduce quality by taking bits away from regions that need those bits more. This is speculation - I think it's unlikely, but possible.

5. The people who care most about sound quality aren't using mp3.

6. Of the ones who are using mp3, the ones who care most about sound quality are using decoders with 24-bit or 16-bit dithered outputs.

7. Once you have added dither at the 16-bit level, you can't take it away again.

This all suggests to me that the smart thing to do is to feed the highest resolution you have into the lossy encoder.

If you must use 16-bits, then either don't noise shape at all, or use something like UV22 which adds extra noise only at such high frequencies that the mp3 encoder's low pass filter will remove it before encoding (hopefully in the floating point domain).

btw, the most annoying result of all is to have dither noise which is partially encoded, because it just "tickles" the ATH curve in the encoder. That sounds really annoying, if you turn the volume up loud enough to be able to hear it. It's a great potential reason to avoid ATH-shaped dither if you intend to mp3 encode something - but it's also a reason to avoid dither altogether. I came across it in my mp3 decoder tests, where I stumbled onto some of these issues and tried to examine them in detail...

http://mp3decoders.mp3-tech.org/lsb.html
http://mp3decoders.mp3-tech.org/24bit.html
http://mp3decoders.mp3-tech.org/24bit2.html

Hope this helps.

Cheers,
David.

Noise-shaping curves and downstream lossy compression

Reply #26
This all suggests to me that the smart thing to do is to feed the highest resolution you have into the lossy encoder.

Thank you 2B for the support.

I have to comment on one thing, though:
[...] or use something like UV22 which adds extra noise only at such high frequencies

UV22 dither has absolutely no advantage to noise shaping. The UV22 dither signal may not contain anything below 20 kHz but quantization adds white noise with a rectangular PDF. So the overall noise you get is really UV22 + white RPDF noise.

Cheers,
SG

Noise-shaping curves and downstream lossy compression

Reply #27
In-band it's supposedly a few dB lower than dither without noise shaping.

More importantly, you don't start loading sfb21 with noise, as you would with noise shaping.


Of course 24-bit is a better choice - but sometimes people want to make CDs, knowing that they can be converted to mp3. (More often I suspect the opposite is true!).

Cheers,
David.

 
SimplePortal 1.0.0 RC1 © 2008-2018