MPC VBR flaws (low volume & ringing)
Reply #29 – 2005-07-05 13:33:56
I'm a bit surprised nobody has to say anything to say to this, especially guruboolez? What am I supposed to add? Sorry, but I don't see what to do or to say. I made a test, and now it's to developers to work on the problem. A new encoder was released since, but the only change affects encoding speed, not quality. Only thing I can do is a bench... Anyway, Roberto at least have understand what I've said previously. If some musepack's developer consider a listening test as an attack, I won't insist. It's pretty simple. The problem I've submit in this topic is just a "farewell present" to musepack. I know this problem for a long time, and the only thing I could do is to submit it. Just hope that it will help MPC to progress. Members should also be aware of this issue.Anyway, to summarize Frank Klemm's comments in a more simple manner: - In a version between 1.06 and 1.1, the coding of low level (not low frequency!) signals was changed, to avoid artifacts that were caused when such a signal approached a certain lower threshold which made it fluctuate between "encode" and "not encode" I've posted two listening tests that conclude on it. Frank Klemm gives an explanation. What should I do more? I can't work on the encoder and tweak it.- Ridiculously high Replaygain values however (usually in track gain) can make artifacts with the new method audible again Not again . 1.01j and even 1.78c suffers from the same big issue.- Replaygain in it's current state has some shortcomings for very dynamic albums Not exactly. ReplayGain is doing its job, and perfectly. The problem is Musepack + Replaygain. Many other audio formats don't have this problem at this bitrate, an can be used with RG even with very high gain correction: vorbis, aac, mp3, DualStram and WavPack lossy. MPC VBR model is flawed, at least with the current tuning. ReplayGain is clean. There's only one way to correct the problem: working on MPC. Changing ReplayGain to work in a weird Track/Album mix have no sense at all. And saying that Track Gain is not suitable for classical or doesn't correspond to a a "normal listening condition" is just an easy way to hide the real problem, or to minimize it. A more serious alternative would be to take example on other formats: they work fine with RG in either track or album mode, with either classical or metal music. LAME, at least with CBR/ABR, had similar issues, and were solved by working on the code without changing RG behaviour. MPC SV7 had in the past serious clipping issue; they were corrected by Klemm with the introduction of --xlevel tool and not by convincing the audio engineers to stop their loudness war. Honestly, defending MPC by discrediting specific listening conditions or minimizing the problem won't make MPC sound better. ath_gain swith is a working solution (at least to this problem), but to the price of efficiency.- For daily use and normal listening conditions, this problem is not relevant Are you suggesting that ReplayGain Track mode is not refecting "daily use" or "normal listening conditions"?
Wavpack Hybrid: one encoder, one encoding for all scenarios WavPack -c4.5hx6 (44100Hz & 48000Hz) ≈ 390 kbps + correction file WavPack -c4hx6 (96000Hz) ≈ 768 kbps + correction file WavPack -h (SACD & DSD) ≈ 2400 kbps at 2.8224 MHz