Before carrying and before some seeing zealous users bare its teeth, I have to make clear that this issue only occurs in specific conditions. The problem is confined to low-volume musical content, and is mainly audible when this content has to be listened to a higher playback volume. In other words, affected tracks must have low volume parts, and tracks with high dynamic are not really concerned (you can’t constantly push the volume on such material: your neighbors won’t appreciate it). The problem becomes really critical with low-volume tracks only. People who have to live with the consequences of the “loudness war” are certainly not used to encounter such tracks, but for classical fans, tracks that are replaygained at +10 dB, +20 dB and sometimes +30 dB are all except a rare thing (tracks with corrected gain beyond +25 dB are nevertheless very rare). The encoded material would exhibit strong artifacts with ReplayGan set with Track Mode (they won’t be audible otherwise, except maybe as a subtle form of distortion – it could explain some recent complains about musepack and classical music). With RG enabled, even untrained people will be shocked by the terrible ringing that run across this musical material. MPC, with --standard profile, and to some degree --extreme and also –insane is apparently not sensitive enough to handle low volume situation.
At this stage of my account, some people would be probably tempted to claim that such issue is normal with perceptual encoding, and that all other formats will suffer from the same issue in this specific playback condition. But a quick comparison would immediately deny all validity to this idea. I’ve compared musepack --standard to comparable MP3, AAC and Vorbis presets, and these competitors showed the ability to encode properly (no ringing, flat lowpass at high level) the same material. Even stranger, MP3 at 128 kbps, or Vorbis at 90 kbps (!), or AAC (faac!) at 100 kbps perform *much* better than musepack --standard. In other words, perceptual encoders (at least modern one) could handle this situation transparently at mid/low bitrate, even with VBR; only musepack fails, and badly. It might be interesting to note that the VBR model is apparently flawed: with --standard, the bitrate drops to unusual value (110…140 kbps), and quality to an even more abnormal threshold. An illustration (graphical – listening tests were performed upstream - click for link) could make things easier to understand:

I’ve also uploaded an additional gallery - the last one looks very weird! and sounds even worse as it looks.
The ringing, and the austere lowpass, are obvious on these screenshots. Quality is objectively worse than MP3@128; subjectively speaking, the audibility is –as usual- linked to various conditions: hardware, player settings (RG or not), listener’ sensitivity to ringing. Some users won’t notice it, some others will be frightened. The important point to note here is that other audio formats have no problems; my purpose wasn’t to make an infertile comparison between MPC and other. Based on this comparison, I’m tempted to say that MPC could rejoin them with some tuning. Anecdotal point: LAME had recently serious issue (which also concern 3.90.3 ABR at mid/low bitrate) and they were recently solved by developers. I think Gabriel worked on an adaptive ATH threshold, and it might be a lead for MPC developer or for some users which are interested to play with current encoder switches.
I’ve uploaded some samples. The gain for short samples is necessary different from the gain of complete sample; but I’ve tried to cut sample with similar gain. The WavPack samples uploaded have all the native gain and the track_peak of the full track. I’ve also duplicated the track gain to the album gain.
http://guruboolez.free.fr/MPC/quiet_tracks_replaygained.zip
Two appendix in this zip file : a piano sample for which track gain for the sample doesn’t really match to the track gain of the full track (+40 dB instead of +25 dB) ; and a very noisy track for which musepack doesn’t have any problem, despite of high gain correction.
This report is probably the last one I’ll do for MPC (a developer have claim their lack of interest for improving classical at --standard), but I nevertheless hope it will help to improve the encoder. Playing with command line (in order to change ATH or noise sensitivity) might be enough to solve or reduce this issue; therefore, every MPC user could contribute. In the meantime, users should be aware of this issue.
