HydrogenAudio

Lossy Audio Compression => MPC => Topic started by: guruboolez on 2005-06-23 10:22:44

Title: MPC VBR flaws (low volume & ringing)
Post by: guruboolez on 2005-06-23 10:22:44
I’ve read recently some complaints about musepack and distortions occurring with classical music (examples here (http://www.hydrogenaudio.org/forums/index.php?showtopic=34924&view=findpost&p=307055) and here (http://musepack.net/forum/viewtopic.php?p=906&sid=eb705dea72ece4441012cde9dbacdf13#906)). There were no ABX tests to confirm them. According to my previous listening tests at ~175 kbps (http://www.hydrogenaudio.org/forums/index.php?showtopic=23355), musepack performs not only very well with various kinds of instrumental and vocal samples, but also better than competitors. But I’ve also noticed in the past one issue with this audio format that my previous test didn’t revealed, and it’s a very big one. I’d like to bring out this problem to the community, which wasn’t as far as I know warned about this kind of flaw.

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 (http://www.musepack.net/forum/viewtopic.php?p=913&sid=801c028ada16f3b54af22182171c501f#913)) could make things easier to understand:

(http://guruboolez.free.fr/MPC/2_instrumental_voice.png)

I’ve also uploaded an additional gallery (http://guruboolez.free.fr/MPC/mpc_gain_problem.htm) - 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 (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.
Title: MPC VBR flaws (low volume & ringing)
Post by: shadowking on 2005-06-23 11:07:53
I confirm serious problems under these special listening conditions.

Thanks you for making it clearer for me. Now I understand it better!
Title: MPC VBR flaws (low volume & ringing)
Post by: Acid8000 on 2005-06-23 11:24:51
What I understand from your post guru is that at > insane, this effect isn't significant. I hope this is the case.

Edit: Whoa, this is only noticable with ReplayGain higher than +20dB or so. The lowest classical on my system is +3dB or so. Any rock/metal/rap/electronica is gained to -9dB sometimes. Looks like I shouldn't really be concerned. Phew.
Title: MPC VBR flaws (low volume & ringing)
Post by: rjamorim on 2005-06-23 15:24:01
I think you should put more creativity into your report. Maybe writing it entirely in haiku, and adding pictures of women in bikini next to the spectrograms


Hehe. Anyway, thank-you very much for this very enlightening report, Guru.
Title: MPC VBR flaws (low volume & ringing)
Post by: Gambit on 2005-06-23 15:41:41
I haven't seen this mentioned anywhere, so I thought I'll quote Case from IRC:
Quote
<cse> btw, here's something Klemm says about encoding highly dynamic movie tracks. I think this is valid for classical too:
<cse> 3. Also I suggest to use the option
<cse>        --standard --ath_gain -14
<cse>    with movie soundtracks.
<cse>    For other quality settings
<cse>      --quality x --ath_gain 16-6*x
<cse>    This lowers ATH by 14 dB relative to the standard.
<cse>    Feeding of mppenc should be done with 24 bit when possible.
<cse>    Use a 24 bit AC3decoder.
Title: MPC VBR flaws (low volume & ringing)
Post by: Gabriel on 2005-06-23 20:33:01
The obvious workaround is to check the track gain before encoding, then adjust the ath level according to the gain.

The fix for the encoder would be to adjust dynamically its ath level. For a vbr encoder it is very important as you can not rely on the target bitrate "safeguard" as in cbr.
Title: MPC VBR flaws (low volume & ringing)
Post by: Lefungus on 2005-06-23 20:33:43
Quote
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.


I'd like to know where you got that claim
To put things clear, the encoder side is unmaintained. I'm not aware of anyone actually trying to improve it, or increase its transparency even for non-classical music. (feel free to prove me wrong)
Recent releases were bugfixes or nice additions, but no changes were made to the psy-model itself. Some extremely minor patches for tag writing will come soon and that will be all.
So unless Klemm give some input, nothing will come out off this stuff. The codec is just fading away, losing its relevance little by little (and all mpc haters drop tears of joy and happiness).
Title: MPC VBR flaws (low volume & ringing)
Post by: mtm on 2005-06-23 21:43:18
guruboolez, thank you very much for your input. I think your findings are very valuable.

I downloaded your sample set and tried to test according to Gambit's (Case's ? Frank's ? ) suggestions, but it seems my hearing will need a few more days of peace after I went to The Mars Volta concert on Tuesday.
Title: MPC VBR flaws (low volume & ringing)
Post by: Dibrom on 2005-06-23 22:01:13
Quote
Quote
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.

I'm not aware of anyone actually trying to improve it, or increase its transparency even for non-classical music. (feel free to prove me wrong)
Recent releases were bugfixes or nice additions, but no changes were made to the psy-model itself.


Well, I've been working on encoder changes, including a complete rewrite, but is has kind of taken a back seat to my player for the moment.  I've made many changes to the psymodel code (many functions have been completely rewritten), although they are speed optimization oriented and the output is made to be identical.  I haven't gotten far enough to really be concerned with changing things at the quality level yet.

I think that if someone could get feedback from Frank about the best way to handle this (i.e., algorithms, etc.), I could try to implement his ideas since it seems maybe nobody else will.

Quote
The codec is just fading away, losing its relevance little by little (and all mpc haters drop tears of joy and happiness).
[a href="index.php?act=findpost&pid=308403"][{POST_SNAPBACK}][/a]


I think a lot of this has to do with a certain lack of visibility.  It also seems that many people (not all of course) involved with MPC don't get along too well with HA these days either, which sort of leads to a strained relationship as far as potential developers might be concerned.

I would personally be a bit sad to see MPC fade into irrelevancy because of lack of development since it was the first codec I used that I was really impressed with once I started paying serious attention to encoding quality.  For the most part, it's still one of the best too.

@guruboolez: Thanks for the report.
Title: MPC VBR flaws (low volume & ringing)
Post by: rjamorim on 2005-06-23 22:21:37
Quote
The codec is just fading away, losing its relevance little by little (and all mpc haters drop tears of joy and happiness).[a href="index.php?act=findpost&pid=308403"][{POST_SNAPBACK}][/a]


I honestly don't see that as a surprise (but that's maybe because I would probably fall into your definition of "mpc hater")

The codec's biggest seling points were always quality and speed. While these features really set MPC apart during its heyday (2000~2002), nowadays the distinction with other codecs isn't that obvious. In 2001 Vorbis was still at its release candidates, and was slow. We had no Nero or iTunes, so the only option for us AAC lovers was the painfully slow Psytel. Lame represented a format that was probably already at the end of its improvement potential, and was quite slow as well.

Since then, Vorbis reached 1.0 and later 1.1. Quality improved a lot, and Lancer showed us you can have very, very fast Vorbis encoding with minimal quality tradeoffs. iTunes and Nero AAC were released, bringing AAC quality to a whole new level and making encoding much faster while at it. And the Lame developers seem set on amazing us with each new release, pulling MP3's quality much beyond what everybody thought would be the limit. And, of course, speed improved a lot there as well.

Now that the other formats are managing to catch up with MPC in its selling points, its limitations are starting to become evident, as the advantages no longer make up for them. Lack of hardware support, lack of multichannel support, can't be used with movies, can't be split and merged, patenting situation is unclear, development stalled... the list is long.
Title: MPC VBR flaws (low volume & ringing)
Post by: mtm on 2005-06-23 22:23:14
Quote
I would personally be a bit sad to see MPC fade into irrelevancy because of lack of development since it was the first codec I used that I was really impressed with once I started paying serious attention to encoding quality.  For the most part, it's still one of the best too.[a href="index.php?act=findpost&pid=308430"][{POST_SNAPBACK}][/a]
I think, quite a lot of people would... It was exactly the same with me and I still use it exclusively.

Quote
I think that if someone could get feedback from Frank about the best way to handle this (i.e., algorithms, etc.), I could try to implement his ideas since it seems maybe nobody else will.[a href="index.php?act=findpost&pid=308430"][{POST_SNAPBACK}][/a]
Thank you, Dibrom.  Even *if* it doesn't work out.


[ Off topic: where's that darn "beer" emoticon ?  ]
Title: MPC VBR flaws (low volume & ringing)
Post by: CiTay on 2005-06-24 01:20:18
Thanks again for that summary, guruboolez. I already sent an email to Frank Klemm about this yesterday. I'm pretty sure he'll send me some comments about it, but as always, it may take a while.

Quote
Off topic: where's that darn "beer" emoticon ?


Ah yes... it got lost during some forum software updates. There, i added it again for you.
Title: MPC VBR flaws (low volume & ringing)
Post by: CiTay on 2005-06-24 10:33:30
Frank replied from work that he will comment as soon as he has some free time.
Title: MPC VBR flaws (low volume & ringing)
Post by: mtm on 2005-06-24 14:40:02
My sincerest thanks to everyone involved.
Title: MPC VBR flaws (low volume & ringing)
Post by: guruboolez on 2005-06-27 10:27:34
Quote
Quote
<cse> btw, here's something Klemm says about encoding highly dynamic movie tracks. I think this is valid for classical too:
<cse> 3. Also I suggest to use the option
<cse>        --standard --ath_gain -14
<cse>    with movie soundtracks.
<cse>    For other quality settings
<cse>      --quality x --ath_gain 16-6*x
<cse>    This lowers ATH by 14 dB relative to the standard.
<cse>    Feeding of mppenc should be done with 24 bit when possible.
<cse>    Use a 24 bit AC3decoder.

[a href="index.php?act=findpost&pid=308342"][{POST_SNAPBACK}][/a]

Thanks for quoting this information.
--ath_gain -14 works very well, and solves all issues (I didn't carefully tried to hear smallest difference). Good new: bitrate inflation is apparently very limited for most tracks (except low volume one of course).

Also interesting to note, applied to --radio profile this additional switch increase the quality by reducing the level of audible artifacts (classical samples). Bitrate nevertheless inflates from 15...20 kbps. But it seems that with classical music --radio --ath_gain -8 performs better than --quality 4.xx (at comparable bitrate). Apparently, musepack suffers from ATH issues at inferior profile (< --standard), and could maybe benefits from tunings in this area to improve overall quality.
Title: MPC VBR flaws (low volume & ringing)
Post by: GeSomeone on 2005-06-27 12:18:11
Quote
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.

Guruboolez, thanks for the detailed report on this issue in (still) my favorite lossy encoder. Please don't be put off too quickly by the hesitant reaction of "mpc devellopment". We know how the situation is .
The "workaround", as posted by Gambit, alone may have been worth it. Maybe this, what looks like a fixable issue, can spark interest of devellopers to have a go at it?

Quote
I've made many changes to the psymodel code, although they are speed optimization oriented and the output is made to be identical.
I'm surprised, I always thought the speed was very good.

/related rant
It was my feeling that Frank Klemm, at the time the last alpha's were released by him, was very concerned about bit rate bloat. Also the ATH's were redefined when introducing the --quality scales. Maybe this issue crept in at the same time (but maybe it was waiting to be brought to front by Guruboolez all the time  )

BTW Replaygain of +20dB is pretty extreme to me. I'm always cautious with positive RG because it can result in unwanted clipping if there are peaks in the same track/album.
I am aware that in this case it's just an indication when the reported issue occurs. And, apart from RG, someone could just play it very LOUD and maybe notice the same thing.
Title: MPC VBR flaws (low volume & ringing)
Post by: xmixahlx on 2005-06-27 20:32:00
dibrom's speed enhancements were focused on PPC/etc AFAIK


later
Title: MPC VBR flaws (low volume & ringing)
Post by: Dibrom on 2005-06-27 21:04:30
Quote
dibrom's speed enhancements were focused on PPC/etc AFAIK
[a href="index.php?act=findpost&pid=309311"][{POST_SNAPBACK}][/a]


A significant portion of them were, but the later changes I've made should improve speed on x86 also, though the gains should be smaller.

A complete rewrite with a more modular codebase could probably allow for a lot more significant optimizations with little hassle (in addition to other pluses like easier maintenance, and an easier transition to a different bitstream like SV8), which is what I was starting on right about the time I shifted to working more on my audio player.

I don't know when I'll release these changes, but input from Frank about possible quality fixes should be pretty independent of most of what I've done so assuming that it's not a huge hassle to fit into the current psymodel (and I can't see why it would), then it should be pretty simple to implement and release.
Title: MPC VBR flaws (low volume & ringing)
Post by: CiTay on 2005-06-28 20:09:49
As promised, here is the answer that i got from Frank Klemm today. I translated it from german.


Code: [Select]
The calculated masked threshold is indeed depending on the level. It changes if lower levels
are approached. This modification was made sometime between encoder version 1.06 and 1.1.

With high levels, the NMR (noise-to-mask-ratio) was raised by 0.5 dB, with low levels,
it was lowered. The masked threshold (ATH) was lowered by 6 dB in total.

The original behavior was that, up to a certain threshold, things were coded with full NMR,
and after that it would suddenly get muted. A signal around that switching threshold
produced audible artifacts, despite the fact that many bits were used for coding.

The current behavior is that the coding gradually gets worse with very low levels and there's
almost no usable signal in the end. Only when this point is reached, the coding is stopped.

When you're looking at the error signal over the signal strength, there's a slowly declining
function that approaches the ATH from above. The old behavior first caused the error signal to
fall ca. 20 dB below the ATH and only raise to ATH-level again when the coding was stopped.

Extensive listening tests with headphones were conducted (headphones because of the high
listening level). For listening material, among others, the Bolero by M. Ravel was used.
Volume was adjusted to ca. 114 dB SPL at -0 dB signal strength.

At this volume, noise in the recording and quantization artefacts are already an issue with
many 16 bit recordings. As long as this level is not (clearly) exceeded, the quality of the
coding was clearly better, despite the lower bitrate (even though the NMR was raised by 0.5 dB
and the ATH lowered by 6 dB, there are spare bits with almost every kind of music).
The fluctuation in the coding - which was caused by activation and deactivation of subbands -
disappears.

But if you turn up the volume clearly above this level (ca. from 120 dB SPL at -0 dB signal
strength on), you hear the coding errors which are then pretty different from the older versions.

Now, if you disregard the question "what good are replaygains above +10 dB?" (with classical
music, only album-based replaygain should be used anyway), the problem can be solved by
lowering the ATH. It will result in a slightly higher bitrate.

If this problem is relevant for daily use in any kind of way, i dare say "no".
For most pop titles, you can increase the ATH by 30 dB and still not notice anything.
Even with classical music, 10 dB are often possible.

A clean solution is not possible with a 1-pass-coder; you would first need a rough
volume estimation of the whole song to estimate the maximum position of the volume knob -
and even then, you could still re-adjust during the title.

Furthermore, i would recommend corrections within Replaygain. A "quick-to-hack" solution
would be that the title-based replaygain of neighboring tracks in an album must not
differentiate by more than 6 dB.

From these (calculated) values:

- 7,81 dB
- 6,41 dB
- 7,61 dB
+4,81 dB
- 8,11 dB
- 6,12 dB
+1,12 dB
- 9,12 dB

you will then get:

- 7,81 dB
- 6,41 dB
- 7,61 dB
- 2,11 dB        // raised to -8,11 + 6
- 8,11 dB
- 6,12 dB
- 3,12 dB        // raised to -9,12 + 6
- 9,12 dB


Then, short voice tracks/interludes/preludes etc. don't get boosted to +40 dB anymore.
Because this is currently the only limit: Replaygain values of more than +40 dB are
simply reduced to 0 dB (not really that clean either). This limit should also be
reduced to +12 dB (corresponds to K-26).

If this proposal is taken up, i could send some reasonably tuned example code.
Somewhere in the depths of my hard disk there should be something.
In that code, the increase of these "holes" is also depending on the Album-replaygain,
the title length and sometimes from more distant neighboring tracks.
A "1 second digital null" before the first title approximately gets the value of the
first track, a "2 second digital null" in between two tracks gets the mean value
of both tracks.



static const Profile_Setting_t  Profiles [16] = {
   { 0 },
   { 0 },
   { 0 },
   { 0 },
   { 0 },
/*    Short   MinVal  EarModel  Ltq_                min   Ltq_  Band-  tmpMask  CVD_  varLtq    MS   Comb   NS_        Trans */
/*    Thr     Choice  Flag      offset  TMN   NMT   SMR   max   Width  _used    used         channel Penal used  PNS    Det  */
   { 1.e9f,  1,      300,       30,    3.0, -1.0,    0,  106,   4820,   1,      1,    1.,      3,     24,  6,   1.09f, 200 },  // 0: pre-Telephone
   { 1.e9f,  1,      300,       24,    6.0,  0.5,    0,  100,   7570,   1,      1,    1.,      3,     20,  6,   0.77f, 180 },  // 1: pre-Telephone
   { 1.e9f,  1,      400,       18,    9.0,  2.0,    0,   94,  10300,   1,      1,    1.,      4,     18,  6,   0.55f, 160 },  // 2: Telephone
   { 50.0f,  2,      430,       12,   12.0,  3.5,    0,   88,  13090,   1,      1,    1.,      5,     15,  6,   0.39f, 140 },  // 3: Thumb
   { 15.0f,  2,      440,        6,   15.0,  5.0,    0,   82,  15800,   1,      1,    1.,      6,     10,  6,   0.27f, 120 },  // 4: Radio
   {  5.0f,  2,      550,        0,   18.0,  6.5,    1,   76,  19980,   1,      2,    1.,     11,      9,  6,   0.00f, 100 },  // 5: Standard
   {  4.0f,  2,      560,       -6,   21.0,  8.0,    2,   70,  22000,   1,      2,    1.,     12,      7,  6,   0.00f,  80 },  // 6: Xtreme
   {  3.0f,  2,      570,      -12,   24.0,  9.5,    3,   64,  24000,   1,      2,    2.,     13,      5,  6,   0.00f,  60 },  // 7: Insane
   {  2.8f,  2,      580,      -18,   27.0, 11.0,    4,   58,  26000,   1,      2,    4.,     13,      4,  6,   0.00f,  40 },  // 8: BrainDead
   {  2.6f,  2,      590,      -24,   30.0, 12.5,    5,   52,  28000,   1,      2,    8.,     13,      4,  6,   0.00f,  20 },  // 9: post-BrainDead
   {  2.4f,  2,      599,      -30,   33.0, 14.0,    6,   46,  30000,   1,      2,   16.,     15,      2,  6,   0.00f,  10 },  //10: post-BrainDead
};


The Ltq_offset entry is the alteration of the masked threshold against the standard model.
A reduction by 6 dB decreases the ATH by 6 dB in the whole frequency range.

The value left of that (EarModel) can be used for ATH fine-tuning for higher frequencies.
An increasing by 20 results in a ATH decrease by 1.5 dB at 10 KHz and 6 dB at 20 KHz.

--quality 6 against --quality 5 has the following differences in the ATH with this:

- 6,0 dB for low frequencies
- 6,5 dB for 8 kHz
- 7,0 dB for 11 kHz
- 8,0 dB for 16,3 kHz
- 9,0 dB for 20 kHz
-10,0 dB for 23 kHz

If there are further questions or if something was unintelligible, just keep asking.
I still have no time, but when i have 15 minutes silence, i can answer such things.

Motto of the day: The ingeniousness of a construction lies within its simplicity.
Everyone can build something complicated. (Sergeij P. Koroljow)
Title: MPC VBR flaws (low volume & ringing)
Post by: CiTay on 2005-07-02 21:40:14
I'm a bit surprised nobody has to say anything to say to this, especially guruboolez?

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"

- The new method avoids that fluctuation by gradually decreasing quality towards the lower threshold, leading to a gentle deterioration and no audible artifacts even with quite "silent" music under normal circumstances, which was checked in listening tests

- Ridiculously high Replaygain values however (usually in track gain) can make artifacts with the new method audible again

- Replaygain in it's current state has some shortcomings for very dynamic albums

- The new method could be tuned by lowering the ATH (absolute threshold of hearing); basically making the "simulated hearing" a bit more sensitive

- For daily use and normal listening conditions, this problem is not relevant

- Possible solutions include the tweaking of the ATH curves and modifications to Replaygain
Title: MPC VBR flaws (low volume & ringing)
Post by: rjamorim on 2005-07-02 21:56:20
Quote
I'm a bit surprised nobody has to say anything to say to this, especially guruboolez?[a href="index.php?act=findpost&pid=310528"][{POST_SNAPBACK}][/a]


Well, Guruboolez already said he's not planning to test Musepack again after the terrible behaviour displayed by the project's maintainer in face of useful and valid test results. So I suspect it makes no difference to him anymore what Klemm says.
Title: MPC VBR flaws (low volume & ringing)
Post by: CiTay on 2005-07-02 22:37:53
Quote
Well, Guruboolez already said he's not planning to test Musepack again after the terrible behaviour displayed by the project's maintainer in face of useful and valid test results. So I suspect it makes no difference to him anymore what Klemm says.
[a href="index.php?act=findpost&pid=310529"][{POST_SNAPBACK}][/a]


Why don't you let him speak for himself? Some days ago he showed that he still is interested in a fix for this issue. No need trying to verbally divide things further than they already are.
Title: MPC VBR flaws (low volume & ringing)
Post by: Vertigo on 2005-07-03 00:54:28
Hahaha, I love it when robert comes in to save the day for musepack. =D
Title: MPC VBR flaws (low volume & ringing)
Post by: rjamorim on 2005-07-03 01:01:04
Quote
Hahaha, I love it when robert comes in to save the day for musepack. =D
[a href="index.php?act=findpost&pid=310566"][{POST_SNAPBACK}][/a]


hehe. I actually have been, from the beginning, defending my good friend Guruboolez from bullshit coming form all sides.
Title: MPC VBR flaws (low volume & ringing)
Post by: Dibrom on 2005-07-03 01:32:29
Do we need to split this thread again to stay on topic?
Title: MPC VBR flaws (low volume & ringing)
Post by: Cyaneyes on 2005-07-03 02:43:37
Just to comment on Frank's thoughts on Track gain...

Doesn't his proposal defeat the purpose of Track gain?  If you want to keep the volume differences between tracks intact, you use album gain.  He appears to be proposing a kind of half trackgain, half albumgain system.

What if you're playing tracks at random and come across a track that's not raised to the same gain as the others?  In this context, having a rule that says neighboring album tracks must not vary by more than x number of db makes no sense.

If you wish to keep volume differences in tracks intact, but need to decrease dynamic range (because of a noisy listening environment, etc) this can be accomplished through DSP.
Title: MPC VBR flaws (low volume & ringing)
Post by: Andavari on 2005-07-03 03:47:58
Quote
Just to comment on Frank's thoughts on Track gain...
[a href="index.php?act=findpost&pid=310575"][{POST_SNAPBACK}][/a]

I'd think that an additional switch could be added into replaygain.exe and mppenc.exe such as "--cvl" to tell them both they're dealing with classical, low volume material, etc. I'd also think that it would be the safest way to approach the problem since it would only be used for specific material that required it, without effecting material that doesn't.
Title: MPC VBR flaws (low volume & ringing)
Post by: Lyx on 2005-07-03 04:27:33
*nevermind - i mixed up trackgain and albumgain*
Title: MPC VBR flaws (low volume & ringing)
Post by: xmixahlx on 2005-07-03 11:29:12
...if this problem only occurs in music with ridiculous replaygain values (+40 dB for example)

perhaps wavegain is the answer?

*/me dodges flying debris*


later
Title: MPC VBR flaws (low volume & ringing)
Post by: guruboolez on 2005-07-05 13:33:56
Quote
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.


Quote
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.

Quote
- 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.

Quote
- 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.


Quote
- 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"?
Title: MPC VBR flaws (low volume & ringing)
Post by: markanini on 2005-07-05 14:45:54
Quote
Quote
- 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"?
[a href="index.php?act=findpost&pid=311109"][{POST_SNAPBACK}][/a]

I don't think many use track gain for classical music.
Title: MPC VBR flaws (low volume & ringing)
Post by: Lime on 2005-07-05 15:10:11
I think a workaround is easy. Just do a replaygain at the same time as encoding, and if the RG value is over +20db for example then recompress the track with the --ltq switch. You can further tweak that using a certain --ltq value for lets say tracks with +15db to +20db, and another for tracks over +20db.

Musepack's encoding is very fast so there is room to lose some speed, and also, the RG calculation doesnt need to be perfect, just a rough estimate of the value would be enough.
Title: MPC VBR flaws (low volume & ringing)
Post by: Raptus on 2005-07-05 15:41:39
Quote
The fix for the encoder would be to adjust dynamically its ath level.

Doing so on a frame to frame basis could even save some bitrate, considering that ath could be raised for louder parts. I don't know if this would unbalance the current psy-model, though...
Title: MPC VBR flaws (low volume & ringing)
Post by: Shade[ST] on 2005-07-05 15:47:42
wouldnt this type of adjustment make the ath useless alltogether?  I'm not sure how the system works, but analysing on a frame-by-frame basis seems ridiculous to me...
Title: MPC VBR flaws (low volume & ringing)
Post by: Gabriel on 2005-07-05 16:04:08
Quote
wouldnt this type of adjustment make the ath useless alltogether? I'm not sure how the system works, but analysing on a frame-by-frame basis seems ridiculous to me...

Then consider it to be the effective threshold of hearing instead of the absolute one. The ETH is affected by the middle ear behavior.

If I remember well, Frank also thought that dynamically adjusting the ATH was quite "strange". However it appears that this scheme works in some encoders, and normal humans have a middle ear doing adaptative amplification/reduction of loudness.
Title: MPC VBR flaws (low volume & ringing)
Post by: guruboolez on 2005-07-05 16:17:15
Quote
I don't think many use track gain for classical music.
[a href="index.php?act=findpost&pid=311130"][{POST_SNAPBACK}][/a]

I'm using track gain every day on my portable player. Quiet tracks are simply inaudible outdoor. MPC have poor hardware support, but with RockBox, some jukebox will probably support it. Then the problem will start to annoy some classical fans.
BTW, problem is also sometimes audible with +10 dB; I've some discs with Track adjustment at this level, and issues (minor but real) become audible at house, with Album Gain mode. The problem remains...
Title: MPC VBR flaws (low volume & ringing)
Post by: Dibrom on 2005-07-05 16:25:27
Quote
Quote
I'm a bit surprised nobody has to say anything to say to this, especially guruboolez?

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.


I think it's probably worth noting that a single disagreement is not necessarily representative of everyone involved, or everyone capable of being involved.  It's been said before, but maybe it needs to be said again...

Quote
Quote
- Replaygain in it's current state has some shortcomings for very dynamic albums


Not exactly. ReplayGain is doing its job, and perfectly.


Well I'd agree with the "replaygain is doing it's job" part, but the issue is that the way in which it is doing its job is not necessarily ideal for a psychoacoustic encoder in certain scenarios.  That is how I understand Frank's explanation.

Quote
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.


I'm not sure you can really conclude that the MPC VBR model is flawed from this.  If the issue is simply that MPC is cutting things closer to the threshold than most other encoders, given expected listening conditions, then I don't see what the problem is (with the model I mean).

Under unexpected listening conditions, problems happen.  This, in my opinion, is similar to the situation when encoding content to be played back with surround sound processing later.  Some codecs don't perform well here, and IMO, shouldn't necessarily be expected to.  Of course some do perform well here, but then the question could be asked as to whether they are sacrificing efficiency in other cases simply to deal with an unlikely listening scenario...

In either case, the fix is usually simple.  Encode with different settings if you plan to listen under conditions which you know the encoder is not tuned for by default.  In the case of MPC, that's playing with the ath at encode time, with other encoders and surround sound processing, sometimes that's playing with the js settings.

Quote
ReplayGain is clean. There's only one way to correct the problem: working on MPC.


That's one way to correct the problem, but I don't think it's the only one given what has been said.

Quote
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.


I don't think Frank was saying Track Gain is not a normal listening condition.  But using Track Gain when listening to certain highly dynamic classical music and using the standard MPC preset tunings is "not a normal listening condition."  I think it's important to define "normal listening condition" here.  I don't think Frank means that perhaps other people are not listening this way, but that from the standpoint of the encoder and the way in which the psymodel was designed (and indeed what could be expected from average conditions under which the model must perform) -- in that case it is not a "normal listening condition."

Quote
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.


Well I'm a bit curious.. I don't follow LAME development much these days, but did the "fixes" in LAME for this end up resulting in higher bitrates across the board?

Quote
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.


I think that this was clearly a different situation.  MPC had clipping issues because of a technical design flaw from early on (as I understand it), not because of an estimation about reasonable conditions under which a signal can expected to be masked according to likely playback volume.

Quote
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.


Yes, that is true.  But I don't think Frank was discrediting.  I think he was simply explaining.  And I must say that his explanation seems to make sense to me.  I also realize that from an end user point of view it is annoying and perhaps frustrating to have to have "special conditions" when encoding this type of music with MPC versus other formats.  But from a design and coding point of view, it would also seem to me to be frustrating to have to modify the psymodel to deal with something which is unusual for the given reasons and could possibly reduce efficiency across the board (if I'm wrong about that, then nevermind).  By that, I mean that changing this in the actual psymodel would probably result in efficiency loss similar to changing the ath_gain switch.

Personally, I don't listen to much classical, but I do listen to a lot of music with high dynamic range.  I never use Track gain.  But given what has been said, I don't mind adjusting the ath when encoding this sort of material.  Of course a more automatic solution would be desirable, and maybe this could be implemented (in the frontend).  But if the required solution is to modify the ath for the presets to deal with this one particular case, I'm not sure if that's a very good fix either...

Of course, maybe there are other possibilities or maybe I'm just missing something...
Title: MPC VBR flaws (low volume & ringing)
Post by: Dibrom on 2005-07-05 16:46:50
Quote
If I remember well, Frank also thought that dynamically adjusting the ATH was quite "strange". However it appears that this scheme works in some encoders, and normal humans have a middle ear doing adaptative amplification/reduction of loudness.
[a href="index.php?act=findpost&pid=311151"][{POST_SNAPBACK}][/a]


If the adjustments are made according to a psychophysical phenomenon, that's one thing, and it seems to me to be desirable to have that included in the way the psymodel works.

But attempting to adjust ATH according to how the user might play with their volume control (e.g., Replaygain Track mode on highly dynamic classical music) is another variable entirely, and IMO not necessarily one that the psymodel should even attempt to tackle.  Of course that should be up to the encoder designer and perhaps the expected userbase, but from a technical and conceptual point of view, it seems unrelated to the psymodel itself.

If you plan to factor in all of these sorts of cases, then IMO you also need to factor in many different types of possible postprocessing simply to stay consistent.  But this is a poor design choice I think and results in a much less conceptually clean psymodel -- it is not concerned anymore simply with how the user hears things, but also about how they play them back.  Since this is a whole lot more difficult (eventually impossible?) to predict, it seems to make sense to me to push this sort of prediction work off onto the client (the user) -- i.e., have them modify encode time settings to deal with the sort of situation under which they will be listening if it happens to deviate significantly from an expected (and simple) set of baseline assumptions the encoder makes.
Title: MPC VBR flaws (low volume & ringing)
Post by: guruboolez on 2005-07-05 16:51:55
Quote
I think it's probably worth noting that a single disagreement is not necessarily representative of everyone involved, or everyone capable of being involved.  It's been said before, but maybe it needs to be said again...

Right. But understand that I won't risk to give feedback to a development team which include (one?) aggressive member, and who don't care about ABX (called "flawed" or something like that) methodology. I'm testing for nothing, and I don't request anything else as polite answers.

Quote
I'm not sure you can really conclude that the MPC VBR model is flawed from this.  If the issue is simply that MPC is cutting things closer to the threshold than most other encoders, given expected listening conditions, then I don't see what the problem is (with the model I mean).


Vorbis was affected by the same issue at low bitrate, and you exactly called it a "flaw" ("No, this doesn't represent an "argument against VBR", it simply emphasizes a flaw in the Vorbis encoder").
Source: http://www.hydrogenaudio.org/forums/index....indpost&p=71576 (http://www.hydrogenaudio.org/forums/index.php?showtopic=7197&view=findpost&p=71576)
 

Quote
Of course some do perform well here, but then the question could be asked as to whether they are sacrificing efficiency in other cases simply to deal with an unlikely listening scenario...

Possibly. But call it too fast "an unlikely scenario". For ReplayGain, MPC is probably the most advanced lossy format (adjustment are stored in metadata or header, impressive Winamp plugin, support directly in mppdec).
This scenario is very usual, at least when people are listening to classical stuff.

Quote
In either case, the fix is usually simple.  Encode with different settings if you plan to listen under conditions which you know the encoder is not tuned for by default.

I don't consider it as a valid solution. Tweaking an encoder to fit to a specific solution is very unconfortable. Last and not least, it's against 4 years of HA's recommendation (use --preset and nothing else).


Quote
I don't think Frank was saying Track Gain is not a normal listening condition.  But using Track Gain when listening to certain highly dynamic classical music and using the standard MPC preset tunings is "not a normal listening condition."


On nomad conditions, it is. But again, the problem is also audible with Track Gain Mode with some albums. And only with mpc... Minimizing the problem won't solve it.

Quote
Well I'm a bit curious.. I don't follow LAME development much these days, but did the "fixes" in LAME for this end up resulting in higher bitrates across the board?

I've noticed it with ~128 kbps (ABR and CBR). Bitrate is therefore the same. I could upload samples for which 3.90.3 has poorer performance than... Blade after ReplayGaining it. 3.97 is near perfection.

Quote
I think that this was clearly a different situation.  MPC had clipping issues because of a technical design flaw from early on (as I understand it), not because of an estimation about reasonable conditions under which a signal can expected to be masked according to likely playback volume.

I never encountered a clipping issue with my classical library (>1000 discs). For me, this problem of loudness clipping is as unusual than the situation I've described could appear to people listening to metal or something else.
In both case, we have a technical issue. Clipping was solved by development, and clipping should be solved by the same way.

People listening to different musical genres may encounter different issues. What MPC developers are trying to do is to minimize a problem which is more common as you expect. I don't want to start a idiot flame war. What I'm trying to say, is that MPC has problems, probably not audible to people listening to something else than classical. That's a pity, because I've tested one year ago MPC on classical, and it performed very well.


Quote
By that, I mean that changing this in the actual psymodel would probably result in efficiency loss similar to changing the ath_gain switch.


But why? Other format don't have this problem. And honestly, we can't say anymore that Vorbis, LAME or AAC are inefficient or are wasting bit.
Title: MPC VBR flaws (low volume & ringing)
Post by: Dibrom on 2005-07-05 17:26:21
Quote
Quote
I think it's probably worth noting that a single disagreement is not necessarily representative of everyone involved, or everyone capable of being involved.  It's been said before, but maybe it needs to be said again...

Right. But understand that I won't risk to give feedback to a development team which include (one?) aggressive member, and who don't care about ABX (called "flawed" or something like that) methodology. I'm testing for nothing, and I don't request anything else as polite answers.


Well haven't you gotten polite answers in general?  You had one argument, but other people are reading and listening, and are interested in hearing more.

I would just forget about it and move on.  Yes, easier said than done, but it'd cause less strife.  Why not we just let the issue die?  There are many people here interested in a civilized discussion, and will read your posts.  You don't have to participate anymore if you don't want to, but I wouldn't stop because of a single case.  Up to you.

Quote
Quote
I'm not sure you can really conclude that the MPC VBR model is flawed from this.  If the issue is simply that MPC is cutting things closer to the threshold than most other encoders, given expected listening conditions, then I don't see what the problem is (with the model I mean).


Vorbis was affected by the same issue at low bitrate, and you exactly called it a "flaw" ("No, this doesn't represent an "argument against VBR", it simply emphasizes a flaw in the Vorbis encoder").
Source: http://www.hydrogenaudio.org/forums/index....indpost&p=71576 (http://www.hydrogenaudio.org/forums/index.php?showtopic=7197&view=findpost&p=71576)
 


Hey, I can change my mind, right?

But seriously, I don't remember that discussion and am too busy to go reread it all.  My opinion on certain things has definitely changed though, and I suppose that post was written quite awhile ago.

I'm not so interested in one solution having to deal with all cases, at least at a given level of abstraction.  I think it would be a perfectly fine and desirable solution for this to be handled without any user intervention, but I would probably "fix" it as a two-pass encoding scheme or something else rather than modifying the psymodel.

The problem here is where to make conceptual separation between encoder design to deal with psychoacoustic phenomena and design to deal with user playback schemes.  Before I didn't care much about the separation, now I do.

Quote
Quote
In either case, the fix is usually simple.  Encode with different settings if you plan to listen under conditions which you know the encoder is not tuned for by default.

I don't consider it as a valid solution. Tweaking an encoder to fit to a specific solution is very unconfortable. Last and not least, it's against 4 years of HA's recommendation (use --preset and nothing else).


The radical emphasis on exclusive preset use in LAME originally had to do with the fact that LAME had many exposed experimental switches mixed in with regular switches.  There was never a very good conceptual separation between the two, and many were undocumented or poorly documented.

There were also many, many myths about how the encoder performed with certain switch combinations.  In my opinion at the time (and probably still now, on that specific point, since the frontend is still a mess) it was best to emphasize a single switch so as to completely do away with the rest of the mess that is the frontend.

If the frontend had been redesigned so that no harmful switches were exposed any longer, along with some sort of way to disallow clearly harmful switch combinations, then a single switch would not necessarily have been needed.

Since that never happened, the best solution was to only use one switch, otherwise people begin to be encouraged to use the preset but modify a little bit here, a little bit there, and pretty soon the whole point is lost...

MPC doesn't have this problem nearly as much, so it's not as big of a deal IMO to have some sort of extra switches used for certain cases.

Quote
Quote
I don't think Frank was saying Track Gain is not a normal listening condition.  But using Track Gain when listening to certain highly dynamic classical music and using the standard MPC preset tunings is "not a normal listening condition."


On nomad conditions, it is. But again, the problem is also audible with Track Gain Mode with some albums. And only with mpc... Minimizing the problem won't solve it.


So relative to listening to track mode replaygained classical music on nomad, the problem is common.  How common is that, absolutely?  Enough to force a design change in the psymodel?  Maybe, I'm not sure...

Replaygain track mode performance in general is another situation, but again this is like some sort of post-processing.  How can the encoder be expected to predict this without given that information beforehand?  Sure, you can make a guess about it, but this is sort of a hack (i.e., not an elegant solution from a design perspective), and only for a single case.

Quote
Quote
Well I'm a bit curious.. I don't follow LAME development much these days, but did the "fixes" in LAME for this end up resulting in higher bitrates across the board?

I've noticed it with ~128 kbps (ABR and CBR). Bitrate is therefore the same. I could upload samples for which 3.90.3 has poorer performance than... Blade after ReplayGaining it. 3.97 is near perfection.


Well that is indeed interesting.  Given a fixed bitrate, I wonder how things were reshuffled to deal with the bitrate increase for frames that were given higher quality after making the modification.  I wonder if quality decreased elsewhere?  With ABR this would seem to have to be the case, because if the bitrate increased in quieter frames, the encoder would decrease bitrate elsewhere to hit the target.  This might result in increased quality across the board, but is a compromise in the technical sense if quality is decreased elsewhere even if not noticed in most cases.  With CBR it might be slightly different depending on how the bit reservoir used.  With pure VBR though, I would definitely expect the bitrate to simply increase.
Title: MPC VBR flaws (low volume & ringing)
Post by: Vertigo on 2005-07-05 17:26:28
Quote
Quote
I think it's probably worth noting that a single disagreement is not necessarily representative of everyone involved, or everyone capable of being involved.  It's been said before, but maybe it needs to be said again...

Right. But understand that I won't risk to give feedback to a development team which include (one?) aggressive member, and who don't care about ABX (called "flawed" or something like that) methodology. I'm testing for nothing, and I don't request anything else as polite answers.

Regardless of your perspective, you are helping the development team by providing data.  Not only that, you are being a valuable member of the community by giving us insight on the nature of the codec.  You listen to music that not all people do, and thus provide essential tuning information.  You are well respected and valued.  I would suggest both you and the developer, moreso him, not be childish in the least and agree there is a problem and work on the data you've collected.

Quote
Quote
In either case, the fix is usually simple.  Encode with different settings if you plan to listen under conditions which you know the encoder is not tuned for by default.

I don't consider it as a valid solution. Tweaking an encoder to fit to a specific solution is very unconfortable. Last and not least, it's against 4 years of HA's recommendation (use --preset and nothing else).


This suggestion, I think, is outdated and unfounded.  In a perfect world, this would be ideal, but we do not live in a perfect world.  SV7 is still beta, and switches can be used to fix issues that may occur.  To blindly encode without understanding the content you are working with is foolish.  Once detection methods are perfect, then quality presets will not have switches.  But I will say, HA has a wonderful pipedream tradition.
Title: MPC VBR flaws (low volume & ringing)
Post by: Dibrom on 2005-07-05 17:26:38
Quote
Quote
By that, I mean that changing this in the actual psymodel would probably result in efficiency loss similar to changing the ath_gain switch.

But why? Other format don't have this problem.


Why?  If you make the assumption that MPC is cutting things closer to the threshold, that means that its bit allocation is going to be lower than an equivalent bit allocation in another encoder.  This is because the other encoder is already spending those extra bits that the MPC encoder is not.  If you increase the encoding quality on lower volume parts, then you end up spending those extra bits on MPC that were not spent before, meaning the bitrate increases.

Quote
And honestly, we can't say anymore that Vorbis, LAME or AAC are inefficient or are wasting bit.


Well from an average human listener perspective we can't really know this, which is why we have a psymodel judge it for us.  We would only be able to judge this indirectly through examining the workings of the psymodel, and the average human listener is unable to do this.

One way to get an indication though is to look at Vorbis performance in this situation before the changes were made and after the changes were made that "fixed" the problem.  Did the bitrate increase?  (I don't remember)
Title: MPC VBR flaws (low volume & ringing)
Post by: Vertigo on 2005-07-05 17:32:37
I think we need to send Guruboolez the HA Controversy Award, he's certainly earned it over the years.
Title: MPC VBR flaws (low volume & ringing)
Post by: rjamorim on 2005-07-05 17:51:39
Quote
I think we need to send Guruboolez the HA Controversy Award, he's certainly earned it over the years.[a href="index.php?act=findpost&pid=311179"][{POST_SNAPBACK}][/a]


More than me? I'm desolated! :-B
Title: MPC VBR flaws (low volume & ringing)
Post by: Vertigo on 2005-07-05 17:57:15
Quote
Quote
I think we need to send Guruboolez the HA Controversy Award, he's certainly earned it over the years.[a href="index.php?act=findpost&pid=311179"][{POST_SNAPBACK}][/a]


More than me? I'm desolated! :-B
[a href="index.php?act=findpost&pid=311185"][{POST_SNAPBACK}][/a]


No, your HA Shit-stirrer award is in the mail.
Title: MPC VBR flaws (low volume & ringing)
Post by: guruboolez on 2005-07-05 18:52:22
Quote
Well haven't you gotten polite answers in general?  You had one argument, but other people are reading and listening, and are interested in hearing more.



In general, yes. Fortunately 

Quote
You don't have to participate anymore if you don't want to, but I wouldn't stop because of a single case.  Up to you.

I'll think about it, but currently, I confess that I'm not really in mood to follow with MPC.

Quote
Hey, I can change my mind, right?

re- 
Quote
The radical emphasis on exclusive preset use in LAME originally had to do with the fact that LAME had many exposed experimental switches mixed in with regular switches.  There was never a very good conceptual separation between the two, and many were undocumented or poorly documented.

OK for lame. But MPC is in the same situation. How was called the adaptive behaviour introduced by Klemm in mppenc with 0.90s or so, which lead to lower the name of the profile when some switchs were add to the simple preset?idiot-proof if I remember. The use of personal switch or command line was ~always discouradged, even non-experimental one. Vorbis discouraged the choice of unusual command line by a very long command name. Etc...
Note that I don't think that people shouldn't use personnal command (far from it), but I've just recall that it was and still is not recommended here.

A better solution would be a small and intuitive command, performing like --ms 15 (stereo image) or --itp for vorbis (sharpness), for people interesting to keep details at low volume (they have to assume their choice, and possible bitrate bloat). --ath_gain could be used as it. Why not updating the current recommendation, and communicating about the pertinent use of these command line? --ms 15 for surround; --ath_gain xx for security with classical?

It's not a very convenient solution for the user, but it's a working one. After all, the recommendation are here to guide the user.

Quote
I wonder if quality decreased elsewhere?


I've tested LAME on many samples, and the current encoder perform better with most of them. There's just one specific issue with lame 3.97a10 (warbling), but I'm not sure that it's link to the gain in quality that could be noticed on quiet parts. But there are maybe problems I haven't noticed. I'll maybe make a more extensive tests between 3.90.3 and 3.97 once this last one will reach final or beta status.

Quote
One way to get an indication though is to look at Vorbis performance in this situation before the changes were made and after the changes were made that "fixed" the problem. Did the bitrate increase? (I don't remember)
Yes, and no. The bitrate increases a lot between 1.00 and 1.01 (the fixed encoder) on the affected material (at -q0, bitrate was ~30kbps and then jumped to a more conventional ~60 kbps), but didn't change with louder material. Same for MPCq5 with and without --ath_gain 14: 110...130 -> 170...180 kbps IIRC. With classical stuff (full tracks), it leads to a +10 kbps inflation (approximation). I can't say for other musical genre.
Title: MPC VBR flaws (low volume & ringing)
Post by: Jebus on 2005-07-05 20:22:39
I think there seems to just be an issue with ATH and replaygain, period. If you hard-set the value (using --scale in lame.... sorry guys i'm not familiar with MPC at all), then the codec should be able to adjust the ATH curve based on the replaygain values used. This is why i brought up the whole --scale thing in the first place.

I seriously think adjusting gain after the codec had already used an ATH based on the original levels, is always going to have the potential for problems. The best work-around would be to add a --safe-quiet switch or something so that it uses a stricter ATH. But that's going to increase bitrate, of course.
Title: MPC VBR flaws (low volume & ringing)
Post by: CiTay on 2005-07-08 22:19:46
I got a new e-Mail from Frank (he follows this thread):

Quote
Title-based Replaygain in it's current form is completely useless for classical music. I could implement a couple of small, sensible modifications.

The whole thing has nothing to do with "merging" album- and track gain. Album Gain's current concept is correct, Track Gain should actually have a whole different concept.

First of all there's the question: Are modifications of loudness by more than +12 dB (for silent material) and -12 dB (for loud material) even reasonable, and are these even intended volume differences? This is also put into question if tracks are relatively short (i.e. clearly shorter than neighboring ones) and e.g. contain only announcements. Here, an adaptive method leads to better results.

Also, there are severe problems if the tracks aren't strictly seperated or when the most silent spot doesn't lie at the title border/cut. Moreover, the results are completely different when the same material is a) available as a CD with two big tracks or b) available as a CD with many small tracks.

Here we need another (more complex) solution, especially for classical music.

For one thing, it has to be possible to (slowly) change the loudness within a track (because it's e.g. 44 minutes long), and also, it has to be possible to steadily change the loudness, in order to have gapless title gain with live concerts.

This then amounts to a dynamic range compression similar to AC3, which however means more than 16 bit in the header, because we need to have constant control data.

For Matroska, here would be a proposition:

* Determine and apply album-based Replaygain (control range between K+26 and K-6) [with current nomenclature: +12 to -20 dB]
* Title-based Replaygain is an additional control signal, which is additionally applied
* Restrict title-based Replaygain to +-12 dB
* Title-based Replaygain can be changed steadily within a track
* For that, a control signal similar to an automatic level adjustment is calculated, with the following differences:
   - slow adjustment rate with normal levels
  - level-dependent maximum adjustment rate (e.g. 6 dB/sec at <-80 dB, 1.5 dB/sec at -60 dB, 0.4 dB/sec at -40 dB, 0.1 dB/sec at -20 dB, 0.02 dB/sec at >0 dB)
           - these levels are relative to the album-based Replaygain
  - adjustment considers volume jumps in both time directions
 

Result:

* Normal pop music with digital zero between the tracks isn't handled much differently, maybe the dynamics are lowered by max. 1 dB/minute.
     - There are differences with long titles that have bigger dynamics
* The outcome doesn't depend on where the cuts/title borders are (important!)
     - in particular, there are no problems when they're at the wrong place or when it's a live concert without cuts
* With classical music, the outcome is much more closer to what you would want when you listen to Beethoven in the subway.

But this thing is something that would be more for Matroska than for the MPC format.
 
Concerning another topic in the discussion:   Encoding switches can be changed without making the file lose its "profile" info. You just must not decrease the quality with the switches.
Title: MPC VBR flaws (low volume & ringing)
Post by: Gabriel on 2005-07-09 11:16:14
Isn't the purpose of track gain to be able to use the tracks in a compilation of tracks from different albums?
In this case, why would track gain be dependant of the gain of its neighbours tracks in the original album? If someone wants to listen a full album, he would use album gain, not track gain.
Title: MPC VBR flaws (low volume & ringing)
Post by: Gambit on 2005-07-09 11:48:14
It seems funny to me that you would try to fix Replaygain, when the problem is clearly on Musepack's side.
Title: MPC VBR flaws (low volume & ringing)
Post by: Frank Klemm on 2005-07-09 14:47:19
Quote
Isn't the purpose of track gain to be able to use the tracks in a compilation of tracks from different albums?
In this case, why would track gain be dependant of the gain of its neighbours tracks in the original album? If someone wants to listen a full album, he would use album gain, not track gain.
[a href="index.php?act=findpost&pid=311964"][{POST_SNAPBACK}][/a]


This is not an article about Musepack, but about flaws in the current ReplayGain
concept and implementation. Low level artefacts are related to this problem,
but this article is about ReplayGain and problems with ReplayGain. ReplayGain
ist *not* perfect at all, there's a long list of problems. Actually I use only
album based ReplayGain, other modes have a lot of problems which may significantly
reduce enjoy music.

Okay?

--------------------------------------------------------------------------------------------------------------

We should (always) start from the user application side.
And there there are at least three scenarios.

1. You want to listen to an album in original order. You want to remove volume differences between albums. The aim is to avoid volume differences between albums with different reference level, which is typical for album mastered in different decades. The effect is like a computer's turn on the volume control between albums (and by the way can also implemented in this way when the computer has access to the volume control via RS-232, RS-422, Cable LAN, Wireless LAN, IR-RC, IR-DA, USB, IEEE-1394, CAN, ...).

2. You want to listen to an album in original order. You want to remove volume differences between titels. The aim ist to reduce loudness differences inside an album, maybe also inside longer or very dynamic tracks. These loudness adjustments must be inaudible at all. No clicks, no distortions, no incredible noise boosting, no obviously loudness changes.

3. You want to shuffle titles of different album and you want to remove loudness differences between the titles. The goal is again: No clicks, no distortions, no incredible noise boosting, no obviously loudness changes.

Okay? Always start from the user application side, never start from the SSE and 3DNow!
assembler code side! Even when you like assembly programming on Intel.
Okay?

--------------------------------------------------------------------------------------------------------------

Now from the programmers geek side.

Solution for 1 is the album based replaygain and this work really great.

Solution for 2 is the proposal above. There should be a free parameter (with a useful default value) which controls the speed of the AGC. Someone want only slight loudness correction especially on title borders, another people wants to remove nearly all dynamic.

For album with silence at the title boundaries title based replaygain often works.
When there's only little loudness difference inside the album also the album gain works (see examples 2)!
There are some conceptional flaws and some flaws in the implementation.
* From time to time there are titles with (psychological) much too much title based replaygain gain
** short titles
** silent titles which must be silent at all
* file boundaries not at the real title boundaries
* live albums / classic without gaps
* noisy albums with little, but audible noise between tracks
* albums with DC
When an album has one of these problems, title based replaygain works poorly.
(see also Examples 1).

Solutions for 3 are also not so easy to implement. First of all we have problems with
boundaries (shifted, no silence). But it is not the task of replaygain to find useful
cuts or to fade between live titles during playback.

Primary goal is to remove loudness differences. Secondary goal is to avoid boosting
of intentionally silent titles. Third goal is to avoid noise boosting.

Short and very silent titles should not be boosted as much as replaygain's function GetTitleGain() says. This is important to avoid boosting of short and intentionally
silent titles.

To avoid noise boosting, ReplayGain's title gain must be limited. ReplayGain's album gain makes less problems, I only found albums with gains between -12.3 dB and +9,4 dB.
Within the title gain I found gain from -13,7 dB to +30,9 dB.

--------------------------------------------------------------------------------------------------------------

Even for 2 AND for 3 the current ReplayGain title gain is a really good implementation.
There are some flaws affecting the usage of ReplayGain title gain for problem 2 AND for problem 3. These should be fixed. In combination with a solution of the cut problem then ReplayGain title gain is also a great solution for problem 3.

Problem 2 must be solved completely different. Even when the ReplayGain title gain problems are solved, there are enough problems remaining when you want to use it
with music with
* file boundaries not at the real title boundaries
* live albums / classic without gaps
* noisy albums with little, but audible noise between tracks
* albums with DC

Examples: see next posting(s)
Title: MPC VBR flaws (low volume & ringing)
Post by: Frank Klemm on 2005-07-09 14:58:58
Example for changing title based replaygains from title to title.
(Pause) are silent intermezzi with background noise, ends and beginning of other titles.
Some are digital null or above +36 dB (=>0 dB titlegain), some are between +31 dB and
+15 dB (=> +15...+31 dB), some has normal loudness resultig in ReplayGain of -5...-7 dB.

The title numbering on the CD and on the Cover is different!

http://www.amazon.com/exec/obidos/ASIN/B0000CNY4K/ (http://www.amazon.com/exec/obidos/ASIN/B0000CNY4K/)

Replaygain values:

Code: [Select]
        Title            |        Album            |
  Level-  |      (Peak+)|  Level-  |      (Peak+)|
Adjustment|  Peak (Adjst)|Adjustment|  Peak (Adjst)|  Filename
----------+--------------+----------+--------------+---------------------------
 -7.52 dB | 34427 (14484)| -7.14 dB | 37529 (16495)| Zwischenspiel - Alles für den Herrn (CD 1) (2002) -- [01] Wo willst du hin%3F.mpc
+30.12 dB |  599 (19205)| -7.14 dB | 37529 (16495)| Zwischenspiel - Alles für den Herrn (CD 1) (2002) -- [02] (Pause).mpc
 -6.17 dB | 37039 (18203)| -7.14 dB | 37529 (16495)| Zwischenspiel - Alles für den Herrn (CD 1) (2002) -- [03] Auf Herz und Nieren.mpc
 +0.00 dB |  187 (  187)| -7.14 dB | 37529 (16495)| Zwischenspiel - Alles für den Herrn (CD 1) (2002) -- [04] (Pause).mpc
 -5.93 dB | 34627 (17495)| -7.14 dB | 37529 (16495)| Zwischenspiel - Alles für den Herrn (CD 1) (2002) -- [05] Wir gehören zusammen.mpc
 +0.00 dB |  483 (  483)| -7.14 dB | 37529 (16495)| Zwischenspiel - Alles für den Herrn (CD 1) (2002) -- [06] (Pause).mpc
 -6.84 dB | 37529 (17075)| -7.14 dB | 37529 (16495)| Zwischenspiel - Alles für den Herrn (CD 1) (2002) -- [07] Abschied nehmen.mpc
+20.32 dB |  2571 (26674)| -7.14 dB | 37529 (16495)| Zwischenspiel - Alles für den Herrn (CD 1) (2002) -- [08] (Pause).mpc
 -9.01 dB | 36891 (13074)| -7.14 dB | 37529 (16495)| Zwischenspiel - Alles für den Herrn (CD 1) (2002) -- [09] Kein Königreich.mpc
+14.71 dB |  3633 (19759)| -7.14 dB | 37529 (16495)| Zwischenspiel - Alles für den Herrn (CD 1) (2002) -- [10] (Pause).mpc
 -7.43 dB | 37127 (15783)| -7.14 dB | 37529 (16495)| Zwischenspiel - Alles für den Herrn (CD 1) (2002) -- [11] Wir haben alles Gute vor uns.mpc
 +0.00 dB |    73 (  73)| -7.14 dB | 37529 (16495)| Zwischenspiel - Alles für den Herrn (CD 1) (2002) -- [12] (Pause).mpc
 -6.51 dB | 35447 (16752)| -7.14 dB | 37529 (16495)| Zwischenspiel - Alles für den Herrn (CD 1) (2002) -- [13] Alle Männer müssen kämpfen.mpc
+28.30 dB |  861 (22387)| -7.14 dB | 37529 (16495)| Zwischenspiel - Alles für den Herrn (CD 1) (2002) -- [14] (Pause).mpc
 -5.25 dB | 35853 (19589)| -7.14 dB | 37529 (16495)| Zwischenspiel - Alles für den Herrn (CD 1) (2002) -- [15] That's the way love is.mpc
+17.96 dB |  3587 (28361)| -7.14 dB | 37529 (16495)| Zwischenspiel - Alles für den Herrn (CD 1) (2002) -- [16] (Pause).mpc
 -9.42 dB | 34291 (11592)| -7.14 dB | 37529 (16495)| Zwischenspiel - Alles für den Herrn (CD 1) (2002) -- [17] Brief.mpc
 +0.00 dB |  309 (  309)| -7.14 dB | 37529 (16495)| Zwischenspiel - Alles für den Herrn (CD 1) (2002) -- [18] (Pause).mpc
 -7.46 dB | 34297 (14529)| -7.14 dB | 37529 (16495)| Zwischenspiel - Alles für den Herrn (CD 1) (2002) -- [19] Don't give up.mpc
+30.90 dB |  833 (29217)| -7.14 dB | 37529 (16495)| Zwischenspiel - Alles für den Herrn (CD 1) (2002) -- [20] (Pause).mpc
 -5.01 dB | 36825 (20684)| -7.14 dB | 37529 (16495)| Zwischenspiel - Alles für den Herrn (CD 1) (2002) -- [21] Gut aufgepasst.mpc
 +0.00 dB |  235 (  235)| -7.14 dB | 37529 (16495)| Zwischenspiel - Alles für den Herrn (CD 1) (2002) -- [22] (Pause).mpc
 -6.60 dB | 36525 (17084)| -7.14 dB | 37529 (16495)| Zwischenspiel - Alles für den Herrn (CD 1) (2002) -- [23] Wenn ich schon Kinder hätte (Rap-Version).mpc
+26.50 dB |  913 (19296)| -7.14 dB | 37529 (16495)| Zwischenspiel - Alles für den Herrn (CD 1) (2002) -- [24] (Pause).mpc
 -6.93 dB | 29321 (13203)| -7.14 dB | 37529 (16495)| Zwischenspiel - Alles für den Herrn (CD 1) (2002) -- [25] Kleines Lied (Kinderlied).mpc
+26.72 dB |  879 (19054)| -7.14 dB | 37529 (16495)| Zwischenspiel - Alles für den Herrn (CD 1) (2002) -- [26] (Pause).mpc
 -5.08 dB | 31571 (17590)| -7.14 dB | 37529 (16495)| Zwischenspiel - Alles für den Herrn (CD 1) (2002) -- [27] Die Dinge singen hör ich so gern.mpc
+25.92 dB |  4979 (98433)| -7.14 dB | 37529 (16495)| Zwischenspiel - Alles für den Herrn (CD 1) (2002) -- [28] (Pause).mpc
 -7.47 dB | 34227 (14483)| -7.14 dB | 37529 (16495)| Zwischenspiel - Alles für den Herrn (CD 1) (2002) -- [29] Keep your eyes on me.mpc
 +0.00 dB |    1 (    1)| -5.56 dB | 38201 (20140)| Zwischenspiel - Alles für den Herrn (CD 2) (2002) -- [01] (Pause).mpc
 -5.74 dB | 33169 (17129)| -5.56 dB | 38201 (20140)| Zwischenspiel - Alles für den Herrn (CD 2) (2002) -- [02] Himmel über Deutschland.mpc
+16.33 dB |  2297 (15054)| -5.56 dB | 38201 (20140)| Zwischenspiel - Alles für den Herrn (CD 2) (2002) -- [03] (Pause).mpc
 -5.28 dB | 35303 (19222)| -5.56 dB | 38201 (20140)| Zwischenspiel - Alles für den Herrn (CD 2) (2002) -- [04] Ich lass sie sterben.mpc
 +1.95 dB | 24485 (30647)| -5.56 dB | 38201 (20140)| Zwischenspiel - Alles für den Herrn (CD 2) (2002) -- [05] (Pause).mpc
 -6.18 dB | 34891 (17128)| -5.56 dB | 38201 (20140)| Zwischenspiel - Alles für den Herrn (CD 2) (2002) -- [06] Bevor du gehst.mpc
 -8.76 dB | 34735 (12669)| -5.56 dB | 38201 (20140)| Zwischenspiel - Alles für den Herrn (CD 2) (2002) -- [07] (Pause).mpc
 -5.53 dB | 36027 (19060)| -5.56 dB | 38201 (20140)| Zwischenspiel - Alles für den Herrn (CD 2) (2002) -- [08] I'd be waiting.mpc
 +0.00 dB |  341 (  341)| -5.56 dB | 38201 (20140)| Zwischenspiel - Alles für den Herrn (CD 2) (2002) -- [09] (Pause).mpc
 -5.09 dB | 34937 (19443)| -5.56 dB | 38201 (20140)| Zwischenspiel - Alles für den Herrn (CD 2) (2002) -- [10] Sie ist im Viereck angelegt.mpc
 -4.91 dB | 33669 (19130)| -5.56 dB | 38201 (20140)| Zwischenspiel - Alles für den Herrn (CD 2) (2002) -- [11] (Pause).mpc
 -5.30 dB | 35933 (19520)| -5.56 dB | 38201 (20140)| Zwischenspiel - Alles für den Herrn (CD 2) (2002) -- [12] Eyes R shut.mpc
 +0.00 dB |    39 (  39)| -5.56 dB | 38201 (20140)| Zwischenspiel - Alles für den Herrn (CD 2) (2002) -- [13] (Pause).mpc
 -4.22 dB | 34461 (21199)| -5.56 dB | 38201 (20140)| Zwischenspiel - Alles für den Herrn (CD 2) (2002) -- [14] Der Geist ist willig.mpc
 +3.93 dB | 16935 (26624)| -5.56 dB | 38201 (20140)| Zwischenspiel - Alles für den Herrn (CD 2) (2002) -- [15] (Pause).mpc
 -4.20 dB | 34441 (21236)| -5.56 dB | 38201 (20140)| Zwischenspiel - Alles für den Herrn (CD 2) (2002) -- [16] Mägde und Knechte.mpc
 +1.62 dB | 31413 (37853)| -5.56 dB | 38201 (20140)| Zwischenspiel - Alles für den Herrn (CD 2) (2002) -- [17] (Pause).mpc
 -6.81 dB | 35489 (16202)| -5.56 dB | 38201 (20140)| Zwischenspiel - Alles für den Herrn (CD 2) (2002) -- [18] Der Herr knickt alle Bäume.mpc
 +0.00 dB |  349 (  349)| -5.56 dB | 38201 (20140)| Zwischenspiel - Alles für den Herrn (CD 2) (2002) -- [19] (Pause).mpc
 -5.79 dB | 36597 (18790)| -5.56 dB | 38201 (20140)| Zwischenspiel - Alles für den Herrn (CD 2) (2002) -- [20] Wer weiß schon, was der Morgen bringt.mpc
 +8.13 dB |  6591 (16805)| -5.56 dB | 38201 (20140)| Zwischenspiel - Alles für den Herrn (CD 2) (2002) -- [21] (Pause).mpc
 -5.09 dB | 36205 (20149)| -5.56 dB | 38201 (20140)| Zwischenspiel - Alles für den Herrn (CD 2) (2002) -- [22] Alles für den Herrn.mpc
 +0.35 dB | 34581 (36002)| -5.56 dB | 38201 (20140)| Zwischenspiel - Alles für den Herrn (CD 2) (2002) -- [23] (Pause).mpc
 -4.74 dB | 38201 (22134)| -5.56 dB | 38201 (20140)| Zwischenspiel - Alles für den Herrn (CD 2) (2002) -- [24] Wo driften wir hin.mpc
 +0.62 dB | 24231 (26023)| -5.56 dB | 38201 (20140)| Zwischenspiel - Alles für den Herrn (CD 2) (2002) -- [25] (Pause).mpc
 -7.00 dB | 37661 (16822)| -5.56 dB | 38201 (20140)| Zwischenspiel - Alles für den Herrn (CD 2) (2002) -- [26] Klagelieder.mpc
 -6.75 dB | 34197 (15721)| -5.56 dB | 38201 (20140)| Zwischenspiel - Alles für den Herrn (CD 2) (2002) -- [27] (Pause).mpc
 -5.11 dB | 27527 (15284)| -5.56 dB | 38201 (20140)| Zwischenspiel - Alles für den Herrn (CD 2) (2002) -- [28] Lied (du, nur du).mpc
 +7.97 dB |  7453 (18656)| -5.56 dB | 38201 (20140)| Zwischenspiel - Alles für den Herrn (CD 2) (2002) -- [29] (Pause).mpc
 -4.56 dB | 33751 (19965)| -5.56 dB | 38201 (20140)| Zwischenspiel - Alles für den Herrn (CD 2) (2002) -- [30] Wenn du es willst (mir sind die Hände gebunden).mpc
          | 38201 (98433)|          | 38201 (20140)| --- maximum ---

Musepack bitrates and durations:

Code: [Select]
 PCM size File size  Ratio  kbps    Duration  Param Frequency  Name
  44.633    6.077  7.344  192    4:13.027  (2x16 44100 Hz)  Zwischenspiel - Alles für den Herrn (CD 1) (2002) -- [01] Wo willst du hin%3F.mpc
    0.938    0.079          120    0:05.320  (2x16 44100 Hz)  Zwischenspiel - Alles für den Herrn (CD 1) (2002) -- [02] (Pause).mpc
  45.605    6.469  7.049  200    4:18.533  (2x16 44100 Hz)  Zwischenspiel - Alles für den Herrn (CD 1) (2002) -- [03] Auf Herz und Nieren.mpc
    1.027    0.081          112    0:05.827  (2x16 44100 Hz)  Zwischenspiel - Alles für den Herrn (CD 1) (2002) -- [04] (Pause).mpc
  43.608    6.227  7.002  202    4:07.213  (2x16 44100 Hz)  Zwischenspiel - Alles für den Herrn (CD 1) (2002) -- [05] Wir gehören zusammen.mpc
    0.992    0.066        94.3    0:05.627  (2x16 44100 Hz)  Zwischenspiel - Alles für den Herrn (CD 1) (2002) -- [06] (Pause).mpc
  73.904    10.654  6.936  203    6:58.960  (2x16 44100 Hz)  Zwischenspiel - Alles für den Herrn (CD 1) (2002) -- [07] Abschied nehmen.mpc
    1.121    0.056        71.1    0:06.360  (2x16 44100 Hz)  Zwischenspiel - Alles für den Herrn (CD 1) (2002) -- [08] (Pause).mpc
  36.994    4.841  7.641  185    3:29.720  (2x16 44100 Hz)  Zwischenspiel - Alles für den Herrn (CD 1) (2002) -- [09] Kein Königreich.mpc
    0.959    0.127  7.510  188    0:05.440  (2x16 44100 Hz)  Zwischenspiel - Alles für den Herrn (CD 1) (2002) -- [10] (Pause).mpc
  58.002    7.115  8.151  173    5:28.813  (2x16 44100 Hz)  Zwischenspiel - Alles für den Herrn (CD 1) (2002) -- [11] Wir haben alles Gute vor uns.mpc
    0.886    0.088          141    0:05.027  (2x16 44100 Hz)  Zwischenspiel - Alles für den Herrn (CD 1) (2002) -- [12] (Pause).mpc
  57.607    8.598  6.700  211    5:26.573  (2x16 44100 Hz)  Zwischenspiel - Alles für den Herrn (CD 1) (2002) -- [13] Alle Männer müssen kämpfen.mpc
    1.032    0.070        96.3    0:05.853  (2x16 44100 Hz)  Zwischenspiel - Alles für den Herrn (CD 1) (2002) -- [14] (Pause).mpc
  48.740    7.471  6.524  216    4:36.307  (2x16 44100 Hz)  Zwischenspiel - Alles für den Herrn (CD 1) (2002) -- [15] That's the way love is.mpc
    0.896    0.049        78.1    0:05.080  (2x16 44100 Hz)  Zwischenspiel - Alles für den Herrn (CD 1) (2002) -- [16] (Pause).mpc
  54.923    7.670  7.161  197    5:11.360  (2x16 44100 Hz)  Zwischenspiel - Alles für den Herrn (CD 1) (2002) -- [17] Brief.mpc
    0.893    0.071          112    0:05.067  (2x16 44100 Hz)  Zwischenspiel - Alles für den Herrn (CD 1) (2002) -- [18] (Pause).mpc
  67.862    8.823  7.691  183    6:24.707  (2x16 44100 Hz)  Zwischenspiel - Alles für den Herrn (CD 1) (2002) -- [19] Don't give up.mpc
    0.933    0.064        97.6    0:05.293  (2x16 44100 Hz)  Zwischenspiel - Alles für den Herrn (CD 1) (2002) -- [20] (Pause).mpc
  45.358    6.029  7.522  188    4:17.133  (2x16 44100 Hz)  Zwischenspiel - Alles für den Herrn (CD 1) (2002) -- [21] Gut aufgepasst.mpc
    0.898    0.073          115    0:05.093  (2x16 44100 Hz)  Zwischenspiel - Alles für den Herrn (CD 1) (2002) -- [22] (Pause).mpc
  50.490    7.080  7.131  198    4:46.227  (2x16 44100 Hz)  Zwischenspiel - Alles für den Herrn (CD 1) (2002) -- [23] Wenn ich schon Kinder hätte (Rap-Version).mpc
    0.959    0.059        87.5    0:05.440  (2x16 44100 Hz)  Zwischenspiel - Alles für den Herrn (CD 1) (2002) -- [24] (Pause).mpc
  36.893    4.738  7.786  181    3:29.147  (2x16 44100 Hz)  Zwischenspiel - Alles für den Herrn (CD 1) (2002) -- [25] Kleines Lied (Kinderlied).mpc
    0.922    0.043        66.2    0:05.227  (2x16 44100 Hz)  Zwischenspiel - Alles für den Herrn (CD 1) (2002) -- [26] (Pause).mpc
  39.727    5.820  6.825  207    3:45.213  (2x16 44100 Hz)  Zwischenspiel - Alles für den Herrn (CD 1) (2002) -- [27] Die Dinge singen hör ich so gern.mpc
    1.070    0.087          116    0:06.067  (2x16 44100 Hz)  Zwischenspiel - Alles für den Herrn (CD 1) (2002) -- [28] (Pause).mpc
  53.317    7.313  7.291  194    5:02.253  (2x16 44100 Hz)  Zwischenspiel - Alles für den Herrn (CD 1) (2002) -- [29] Keep your eyes on me.mpc
    0.705    0.001        3.52    0:04.000  (2x16 44100 Hz)  Zwischenspiel - Alles für den Herrn (CD 2) (2002) -- [01] (Pause).mpc
  65.564    8.723  7.516  188    6:11.680  (2x16 44100 Hz)  Zwischenspiel - Alles für den Herrn (CD 2) (2002) -- [02] Himmel über Deutschland.mpc
    0.705    0.070  9.954  142    0:04.000  (2x16 44100 Hz)  Zwischenspiel - Alles für den Herrn (CD 2) (2002) -- [03] (Pause).mpc
  39.210    5.050  7.764  182    3:42.280  (2x16 44100 Hz)  Zwischenspiel - Alles für den Herrn (CD 2) (2002) -- [04] Ich lass sie sterben.mpc
    0.705    0.068          137    0:04.000  (2x16 44100 Hz)  Zwischenspiel - Alles für den Herrn (CD 2) (2002) -- [05] (Pause).mpc
  55.006    7.742  7.104  199    5:11.827  (2x16 44100 Hz)  Zwischenspiel - Alles für den Herrn (CD 2) (2002) -- [06] Bevor du gehst.mpc
    0.705    0.085  8.295  170    0:04.000  (2x16 44100 Hz)  Zwischenspiel - Alles für den Herrn (CD 2) (2002) -- [07] (Pause).mpc
  42.500    6.411  6.629  213    4:00.933  (2x16 44100 Hz)  Zwischenspiel - Alles für den Herrn (CD 2) (2002) -- [08] I'd be waiting.mpc
    0.705    0.052          105    0:04.000  (2x16 44100 Hz)  Zwischenspiel - Alles für den Herrn (CD 2) (2002) -- [09] (Pause).mpc
  41.522    6.177  6.721  210    3:55.387  (2x16 44100 Hz)  Zwischenspiel - Alles für den Herrn (CD 2) (2002) -- [10] Sie ist im Viereck angelegt.mpc
    0.705    0.075  9.368  151    0:04.000  (2x16 44100 Hz)  Zwischenspiel - Alles für den Herrn (CD 2) (2002) -- [11] (Pause).mpc
  58.602    8.488  6.904  204    5:32.213  (2x16 44100 Hz)  Zwischenspiel - Alles für den Herrn (CD 2) (2002) -- [12] Eyes R shut.mpc
    0.705    0.020        40.7    0:04.000  (2x16 44100 Hz)  Zwischenspiel - Alles für den Herrn (CD 2) (2002) -- [13] (Pause).mpc
  45.720    5.820  7.855  180    4:19.187  (2x16 44100 Hz)  Zwischenspiel - Alles für den Herrn (CD 2) (2002) -- [14] Der Geist ist willig.mpc
    0.707    0.096  7.334  192    0:04.013  (2x16 44100 Hz)  Zwischenspiel - Alles für den Herrn (CD 2) (2002) -- [15] (Pause).mpc
  48.705    5.908  8.244  171    4:36.107  (2x16 44100 Hz)  Zwischenspiel - Alles für den Herrn (CD 2) (2002) -- [16] Mägde und Knechte.mpc
    0.740    0.061          116    0:04.200  (2x16 44100 Hz)  Zwischenspiel - Alles für den Herrn (CD 2) (2002) -- [17] (Pause).mpc
  40.108    5.619  7.138  198    3:47.373  (2x16 44100 Hz)  Zwischenspiel - Alles für den Herrn (CD 2) (2002) -- [18] Der Herr knickt alle Bäume.mpc
    0.705    0.061          123    0:04.000  (2x16 44100 Hz)  Zwischenspiel - Alles für den Herrn (CD 2) (2002) -- [19] (Pause).mpc
  38.960    4.891  7.965  177    3:40.867  (2x16 44100 Hz)  Zwischenspiel - Alles für den Herrn (CD 2) (2002) -- [20] Wer weiß schon, was der Morgen bringt.mpc
    0.705    0.052          104    0:04.000  (2x16 44100 Hz)  Zwischenspiel - Alles für den Herrn (CD 2) (2002) -- [21] (Pause).mpc
  40.701    4.656  8.740  161    3:50.733  (2x16 44100 Hz)  Zwischenspiel - Alles für den Herrn (CD 2) (2002) -- [22] Alles für den Herrn.mpc
    0.705    0.069          140    0:04.000  (2x16 44100 Hz)  Zwischenspiel - Alles für den Herrn (CD 2) (2002) -- [23] (Pause).mpc
  43.481    5.630  7.723  183    4:06.493  (2x16 44100 Hz)  Zwischenspiel - Alles für den Herrn (CD 2) (2002) -- [24] Wo driften wir hin.mpc
    0.705    0.070  9.968  142    0:04.000  (2x16 44100 Hz)  Zwischenspiel - Alles für den Herrn (CD 2) (2002) -- [25] (Pause).mpc
  40.637    4.630  8.777  161    3:50.373  (2x16 44100 Hz)  Zwischenspiel - Alles für den Herrn (CD 2) (2002) -- [26] Klagelieder.mpc
    0.705    0.057          114    0:04.000  (2x16 44100 Hz)  Zwischenspiel - Alles für den Herrn (CD 2) (2002) -- [27] (Pause).mpc
  45.299    6.495  6.974  202    4:16.800  (2x16 44100 Hz)  Zwischenspiel - Alles für den Herrn (CD 2) (2002) -- [28] Lied (du, nur du).mpc
    0.705    0.064          129    0:04.000  (2x16 44100 Hz)  Zwischenspiel - Alles für den Herrn (CD 2) (2002) -- [29] (Pause).mpc
  68.523    8.974  7.636  185    6:28.453  (2x16 44100 Hz)  Zwischenspiel - Alles für den Herrn (CD 2) (2002) -- [30] Wenn du es willst (mir sind die Hände gebunden).mpc
 1496.373  202.080  7.405  191  141:22.827                  --- 59 files ---

(HA board software reformats the first table, why???)

[span style=\'font-size:8pt;line-height:100%\']moderation: changed 'code' blocks to 'codebox' for better readability[/span]
Title: MPC VBR flaws (low volume & ringing)
Post by: Frank Klemm on 2005-07-09 15:16:07
Other examples where ReplayGain makes nonsense.
Especially the last example (May be someone knows this group and this album)
is suitable to destroy the hearing. While fading from "Waiting For The Worms" to "Stop"
the loudness is switched by more than 12 dB. The result are heavy overdrives for 2 or 3 seconds and you can frightens people to death.

Code: [Select]
decoding of file 'Back To Titanic (1997) -- [11] Celine Dion -- My Heart Will Go On (with dialogue from the film).mpc'
        to device /dev/audio (Open Sound System)

        Celine Dion: Back To Titanic    (1997)
   [11] My Heart Will Go On (with dialogue from the film)

 189.4 kbps,    4:43.09, SV 7.0, Profile 'Xtreme' (Beta 1.14), Gain 0.9616

    4:43.07 (runtime: 1.15 s  speed: 246.14x)

decoding of file 'Back To Titanic (1997) -- [12] Eileen Ivers -- Nearer My God to Thee.mpc'
        to device /dev/audio (Open Sound System)

        Eileen Ivers: Back To Titanic    (1997)
   [12] Nearer My God to Thee

 203.1 kbps,    2:22.34, SV 7.0, Profile 'Xtreme' (Beta 1.14), Gain 9.5280

    2:22.33 (runtime: 0.51 s  speed: 279.08x)


Code: [Select]
decoding of file 'Hot Rail (2000) -- [05] Crystal Frontier.mpc'
        to device /dev/audio (Open Sound System)

        Calexico: Hot Rail    (2000)
   [05] Crystal Frontier

 204.1 kbps,    3:56.77, SV 7.0, Profile 'Xtreme' (Beta 1.14), Gain 0.4222

    3:56.77 (runtime: 0.95 s  speed: 249.24x)

decoding of file 'Hot Rail (2000) -- [06] Untitled III.mpc'
        to device /dev/audio (Open Sound System)

        Calexico: Hot Rail    (2000)
   [06] Untitled III

 231.7 kbps,    4:07.48, SV 7.0, Profile 'Xtreme' (Beta 1.14), Gain 2.0893

    4:07.47 (runtime: 0.83 s  speed: 298.15x)

  17 Overdrives, maximum level 36659, rerun with --scale 0.89380



Code: [Select]
decoding of file 'Osho -- Kundalini Meditation (1995) -- [01] First Stage: 15 minutes.mpc'
        to device /dev/null (Null Device)

        Osho: Kundalini Meditation    (1995)
   [01] First Stage: 15 minutes

 233.3 kbps,   14:45.84, SV 7.0, Profile 'Xtreme' (Beta 1.14), Gain 0.5916

   14:45.83 (runtime: 2.83 s  speed: 313.01x)

decoding of file 'Osho -- Kundalini Meditation (1995) -- [02] Second Stage: 15 minutes.mpc'
        to device /dev/null (Null Device)

        Osho: Kundalini Meditation    (1995)
   [02] Second Stage: 15 minutes

 212.8 kbps,   14:39.18, SV 7.0, Profile 'Xtreme' (Beta 1.14), Gain 0.7464

   14:39.17 (runtime: 2.84 s  speed: 309.57x)

decoding of file 'Osho -- Kundalini Meditation (1995) -- [03] Third Stage: 15 minutes.mpc'
        to device /dev/null (Null Device)

        Osho: Kundalini Meditation    (1995)
   [03] Third Stage: 15 minutes

 215.7 kbps,   14:53.02, SV 7.0, Profile 'Xtreme' (Beta 1.14), Gain 1.1521

   14:53.00 (runtime: 2.69 s  speed: 331.97x)

decoding of file 'Osho -- Kundalini Meditation (1995) -- [04] Fourth Stage: 15 minutes.mpc'
        to device /dev/null (Null Device)

        Osho: Kundalini Meditation    (1995)
   [04] Fourth Stage: 15 minutes

   9.7 kbps,   14:42.02, SV 7.0, Profile 'Xtreme' (Beta 1.14), Gain 22.2075

   14:42.00 (runtime: 1.58 s  speed: 558.23x)

3425 Overdrives, maximum level 241085, rerun with --scale 0.13591



Code: [Select]
decoding of file 'The Wall (CD2) (1979) -- [10] Waiting For The Worms.mpc'
        to device /dev/audio (Open Sound System)

        Pink Floyd: The Wall (CD2)    (1979)
   [10] Waiting For The Worms

 200.2 kbps,    3:56.64, SV 7.0, Profile 'Xtreme' (Beta 1.14), Gain 1.3107

    3:56.64 (runtime: 0.85 s  speed: 278.40x)

decoding of file 'The Wall (CD2) (1979) -- [11] Stop.mpc'
        to device /dev/audio (Open Sound System)

        Pink Floyd: The Wall (CD2)    (1979)
   [11] Stop

 205.0 kbps,    0:34.95, SV 7.0, Profile 'Xtreme' (Beta 1.14), Gain 5.4828

    0:34.93 (runtime: 0.09 s  speed: 388.15x)

9937 Overdrives, maximum level 125247, rerun with --scale 0.26161
Title: MPC VBR flaws (low volume & ringing)
Post by: Frank Klemm on 2005-07-09 15:22:29
A lot of albums have nearly no differences between the title based ReplayGain values.
Using album based replay gain for equalization of titles may be the better choise.

Code: [Select]
        Title            |        Album            |
 Level-  |       (Peak+)|  Level-  |       (Peak+)|
Adjustment|  Peak (Adjst)|Adjustment|  Peak (Adjst)|  Filename
----------+--------------+----------+--------------+---------------------------
-2.32 dB | 34823 (26660)| -2.98 dB | 34983 (24823)| Islands -- [01] The Wind Chimes.mpc
-3.30 dB | 31059 (21241)| -2.98 dB | 34983 (24823)| Islands -- [02] Islands.mpc
-3.10 dB | 31613 (22124)| -2.98 dB | 34983 (24823)| Islands -- [03] Flying Start.mpc
-3.09 dB | 28675 (20091)| -2.98 dB | 34983 (24823)| Islands -- [04] North Point.mpc
-3.53 dB | 34983 (23300)| -2.98 dB | 34983 (24823)| Islands -- [05] Magic Touch.mpc
-3.61 dB | 30963 (20433)| -2.98 dB | 34983 (24823)| Islands -- [06] The Time has Come.mpc
-2.75 dB | 31731 (23119)| -2.98 dB | 34983 (24823)| Islands -- [07] When the Nights on Fire.mpc
         | 34983 (26660)|          | 34983 (24823)| --- maximum ---


Code: [Select]
        Title            |        Album            |
 Level-  |       (Peak+)|  Level-  |       (Peak+)|
Adjustment|  Peak (Adjst)|Adjustment|  Peak (Adjst)|  Filename
----------+--------------+----------+--------------+---------------------------
-8.00 dB | 36787 (14645)| -8.10 dB | 37953 (14936)| Wishmaster (2000) -- [01] She Is My Sin.mpc
-8.44 dB | 37953 (14363)| -8.10 dB | 37953 (14936)| Wishmaster (2000) -- [02] The Kinslayer.mpc
-8.06 dB | 36125 (14282)| -8.10 dB | 37953 (14936)| Wishmaster (2000) -- [03] Come Cover Me.mpc
-8.27 dB | 36675 (14153)| -8.10 dB | 37953 (14936)| Wishmaster (2000) -- [04] Wanderlust.mpc
-7.38 dB | 34621 (14802)| -8.10 dB | 37953 (14936)| Wishmaster (2000) -- [05] Two For Tragedy.mpc
-8.54 dB | 36245 (13559)| -8.10 dB | 37953 (14936)| Wishmaster (2000) -- [06] Wishmaster.mpc
-7.76 dB | 35925 (14702)| -8.10 dB | 37953 (14936)| Wishmaster (2000) -- [07] Bare Grace Misery.mpc
-8.43 dB | 35949 (13620)| -8.10 dB | 37953 (14936)| Wishmaster (2000) -- [08] Crownless.mpc
-7.22 dB | 35475 (15449)| -8.10 dB | 37953 (14936)| Wishmaster (2000) -- [09] Deep Silence.mpc
-8.02 dB | 35857 (14242)| -8.10 dB | 37953 (14936)| Wishmaster (2000) -- [10] Dead Boy's Poem.mpc
-7.90 dB | 35909 (14461)| -8.10 dB | 37953 (14936)| Wishmaster (2000) -- [11] FantasMic.mpc
         | 37953 (15449)|          | 37953 (14936)| --- maximum ---
Title: MPC VBR flaws (low volume & ringing)
Post by: mtm on 2005-07-09 18:51:36
Thank you for your posts, Mr Klemm. They certainly are some food for thought.

It's good to see you here again. 


Quite a lot of thread views, but not too many replies, so I'll risk mine.

From a purely practical point of view, do you think it's possible to change Musepack's RG the way it would fix problems reported by guruboolez ? You mentioned it would be more suitable for Matroska rather than SV7, and I'm curious.

Also, I don't listen to classical music nearly as much as typical classic lovers, and hence my second question is: would the practical implementation of new RG scheme have any negative influence on the idea of volume equalising between the tracks ?
I'm thinking mainly about track gain changes reported by guruboolez (about +20 dB) and a proposal of limiting the track gain to +-12 dB.

As I said, I have no idea about classic.  I'm sorry if I'm not understanding something.


Best regards,
MTM
Title: MPC VBR flaws (low volume & ringing)
Post by: ChristianHJW on 2005-07-10 09:45:09
Quote
I got a new e-Mail from Frank (he follows this thread):
For Matroska, here would be a proposition:

* Determine and apply album-based Replaygain (control range between K+26 and K-6) [with current nomenclature: +12 to -20 dB]
* Title-based Replaygain is an additional control signal, which is additionally applied
* Restrict title-based Replaygain to +-12 dB
* Title-based Replaygain can be changed steadily within a track
* For that, a control signal similar to an automatic level adjustment is calculated, with the following differences:
   - slow adjustment rate with normal levels
  - level-dependent maximum adjustment rate (e.g. 6 dB/sec at <-80 dB, 1.5 dB/sec at -60 dB, 0.4 dB/sec at -40 dB, 0.1 dB/sec at -20 dB, 0.02 dB/sec at >0 dB)
           - these levels are relative to the album-based Replaygain
  - adjustment considers volume jumps in both time directions
 

Result:

* Normal pop music with digital zero between the tracks isn't handled much differently, maybe the dynamics are lowered by max. 1 dB/minute.
     - There are differences with long titles that have bigger dynamics
* The outcome doesn't depend on where the cuts/title borders are (important!)
     - in particular, there are no problems when they're at the wrong place or when it's a live concert without cuts
* With classical music, the outcome is much more closer to what you would want when you listen to Beethoven in the subway.

But this thing is something that would be more for Matroska than for the MPC format.


Recently there hasnt been too much interest in investing time into improvement of our audio tools, as audio devs seem to be more inclined in seeing container and compression as an entity.

In a first step, you guys have to launch SV 7.5, so that we can start muxing MPC into MKA/MKV.

Christian
matroska project admin
http://www.matroska.org (http://www.matroska.org)
Title: MPC VBR flaws (low volume & ringing)
Post by: guruboolez on 2005-07-10 23:22:40
Quote
This is not an article about Musepack, but about flaws in the current ReplayGain
concept and implementation. Low level artefacts are related to this problem,
but this article is about ReplayGain and problems with ReplayGain.


I beg you pardon, but you've apparently miss an important point: the problem occurs with ReplayGain and Musepack.
ReplayGain + Lame = no problem
ReplayGain + Vorbis = no problem.
ReplayGain + AAC = no problem (checked recently with Nero and previously faac)
ReplayGain + DualStream = no problem
ReplayGain + WavPack lossy = no problem
ReplayGain + MPC = problems

I won't say that ReplayGain is the cause of the problem. It's obviously MPC which can't be used safely in some situation at some encoding profiles.

Quote
ReplayGain ist *not* perfect at all, there's a long list of problems. Actually I use only
album based ReplayGain, other modes have a lot of problems which may significantly
reduce enjoy music.

Okay?


What should I conclude? That a problem shouldn't be considered as relevant because you have other listening habits? That's fine as long as you consider MPC as your own tool, dedicated to your own purpose and to people sharing the same behavior, and if you don't plan to improve the obvious bug occuring in other situations. But don't wonder if musepack will quickly loose its audience with such reasoning.
Title: MPC VBR flaws (low volume & ringing)
Post by: rjamorim on 2005-07-11 00:13:05
Quote
ReplayGain ist *not* perfect at all, there's a long list of problems. Actually I use only album based ReplayGain, other modes have a lot of problems which may significantly reduce enjoy music.

Okay?[a href="index.php?act=findpost&pid=311995"][{POST_SNAPBACK}][/a]


Honestly, that's the first time I see that reported here. Most other complaints I have seen were about replaygaining tools having bugs (wasn't there something about MP3gain and a memory leak? It happened so long ago...) and not about the proposal itself, as well as the existing implementations of it, having issues inherent to the analytical model or the way the gain information is obtained.

There were some complaints about RG behaving in a weird fashion on some specific albums, but I wouldn't call that "a long list of problems".
Title: MPC VBR flaws (low volume & ringing)
Post by: Dibrom on 2005-07-11 00:15:27
Quote
I won't say that ReplayGain is the cause of the problem. It's obviously MPC which can't be used safely in some situation at some encoding profiles.


I think in fact it is more correct to say that MPC can't be expected to provide good results in all situations where postprocessing of the encoded file might occur, unless the user intervenes at encode time and provides the encoder with some information that can correct for this after the fact.

This still shouldn't come as a big surprise for a lossy codec.

Yes, other codecs may not exhibit this problem, but at least in the case of some (e.g., the adaptive ATH Gabriel mentioned), it appears that they rely on tradeoff's as far as compression efficiency is concerned here.  And furthermore, without 2-pass encoding being used, such an adaptive method is going to be much more imprecise.

Quote
What should I conclude? That a problem shouldn't be considered as relevant because you have other listening habits?


The inverse can be said just as well.  Should we conclude that MPC is buggy because it doesn't perform as well as you'd like after you modified the encoded file, invalidating the assumptions the encoder made about masking, etc.?

Quote
That's fine as long as you consider MPC as your own tool, dedicated to your own purpose and to people sharing the same behavior, and if you don't plan to improve the obvious bug occuring in other situations. But don't wonder if musepack will quickly loose its audience with such reasoning.


Calling this a bug seems like a real stretch to me.  It's not a problem with the encoder itself, it's a problem that arises when using the encoded file in certain situations that the encoder doesn't know about.  Furthermore, it would seem definitely not to be a bug since the problem goes away if you in fact give the encoder the correct information at encode time (e.g., ath adjustment).

I agree with Frank -- this is not a problem with MPC but a problem with using Replaygain in this way.  And that doesn't mean that there cannot be some sort of solution found, but I don't think that implementing some sort of imprecise changes in the psymodel to compensate for this special case -- sacrificing efficiency along the way -- is the right answer.

I think the proper solution is to implement some sort of multi-pass encoding system that allows for the encoder to interact with Replaygain more intelligently, if this is the way you plan to use your encoded files.  Maybe this would be done by calculating the Replaygain values for the file before encoding, and then using the track gain as an indicator for ATH adjustment and the like.  Of course this won't be an automatic process (you would have to specify some flag like --2pass), but I don't think it should be -- for people not planning to use their files this way, it should be unnecessary for them to have to make the efficiency sacrifices resulting in larger files.

Note: Sorry I accidently hit edit on your post instead of reply
Title: MPC VBR flaws (low volume & ringing)
Post by: Gambit on 2005-07-11 00:22:53
Quote
I think in fact it is more correct to say that MPC can't be expected to provide good results in all situations where postprocessing of the encoded file might occur, unless the user intervenes at encode time and provides the encoder with some information that can correct for this after the fact.
[a href="index.php?act=findpost&pid=312380"][{POST_SNAPBACK}][/a]

Erm, we are talking about Replaygain here. In the end, it's the same as adjusting the volume knob. I would hardly call that "postprocessing".
Title: MPC VBR flaws (low volume & ringing)
Post by: Dibrom on 2005-07-11 00:25:32
Quote
Quote
I think in fact it is more correct to say that MPC can't be expected to provide good results in all situations where postprocessing of the encoded file might occur, unless the user intervenes at encode time and provides the encoder with some information that can correct for this after the fact.
[a href="index.php?act=findpost&pid=312380"][{POST_SNAPBACK}][/a]

Erm, we are talking about Replaygain here. In the end, it's the same as adjusting the volume knob. I would hardly call that "postprocessing".
[a href="index.php?act=findpost&pid=312383"][{POST_SNAPBACK}][/a]


Well call it what you like, but when you make significant changes to the playback level (e.g., what is happening here with classical music), it's just about as good as postprocessing as far as a psychoacoustic encoder is concerned.

The file is being processed (volume changed significantly) in a way the encoder does not expect, after the file has been encoded.
Title: MPC VBR flaws (low volume & ringing)
Post by: rjamorim on 2005-07-11 00:28:02
Quote
Well call it what you like, but when you make significant changes to the playback level (e.g., what is happening here with classical music), it's just about as good as postprocessing as far as a psychoacoustic encoder is concerned.

The file is being processed (volume changed significantly) in a way the encoder does not expect, after the file has been encoded.[a href="index.php?act=findpost&pid=312384"][{POST_SNAPBACK}][/a]


But if something as simple as turning volume knobs is tripping the codec, then the problem can't be in the volume knob :B
Title: MPC VBR flaws (low volume & ringing)
Post by: Dibrom on 2005-07-11 00:33:31
Quote
Quote
Well call it what you like, but when you make significant changes to the playback level (e.g., what is happening here with classical music), it's just about as good as postprocessing as far as a psychoacoustic encoder is concerned.

The file is being processed (volume changed significantly) in a way the encoder does not expect, after the file has been encoded.[a href="index.php?act=findpost&pid=312384"][{POST_SNAPBACK}][/a]


But if something as simple as turning volume knobs is tripping the codec, then the problem can't be in the volume knob :B
[a href="index.php?act=findpost&pid=312387"][{POST_SNAPBACK}][/a]


Umm.. It's not "something as simple as turning the volume knob" that is "tripping the codec."  If it were, this problem would be much more pervasive and would occur practically everywhere, instead of being limited to the rather specific conditions (i.e., significant boosting of highly dynamic music to levels that invalidate encode time assumptions about masking, etc.) that guruboolez has brought up.
Title: MPC VBR flaws (low volume & ringing)
Post by: rjamorim on 2005-07-11 00:41:49
Quote
Umm.. It's not "something as simple as turning the volume knob" that is "tripping the codec."  If it were, this problem would be much more pervasive and would occur practically everywhere, instead of being limited to the rather specific conditions (i.e., significant boosting of highly dynamic music to levels that invalidate encode time assumptions about masking, etc.) that guruboolez has brought up.[a href="index.php?act=findpost&pid=312388"][{POST_SNAPBACK}][/a]


Well, since it doesn't shows up at all in other codecs, maybe it is the encoder we're discussing here that is making wrong "encode time assumptions about masking, etc."?

After all, if other codecs' psymodels can handle this issue (without two passes!), why can't Musepack's? That is what I am failing to understand. Granted it's a rare ocurrance only reported by Guru so far, but still, there's the point that no other codec suffers from it - even little tunes ones like Faac.
Title: MPC VBR flaws (low volume & ringing)
Post by: Dibrom on 2005-07-11 00:59:11
Quote
Well, since it doesn't shows up at all in other codecs, maybe it is the encoder we're discussing here that is making wrong "encode time assumptions about masking, etc."?

After all, if other codecs' psymodels can handle this issue (without two passes!), why can't Musepack's? That is what I am failing to understand. Granted it's a rare ocurrance only reported by Guru so far, but still, there's the point that no other codec suffers from it - even little tunes ones like Faac.
[a href="index.php?act=findpost&pid=312391"][{POST_SNAPBACK}][/a]


There are two ways I see that this could be handled, and is probably what is going on in the other codecs:

1) Adaptive ATH like what Gabriel was talking about.  It should be pretty obvious why a two pass solution is going to be better than this.  The encoder has to adjust the ath according to some sort of running average, and this is something that will have to be hand tuned probably.  If you adjust too fast, you lose a lot of efficiency.  If you adjust too slow, the user will hear artifacts that you were trying to adjust to prevent.  How do you suppose you are going to decide this?  There's not going to be a perfect way because you're working with incomplete data the whole time unless you go 2-pass.

2) Simply encode with a less aggressive ath level.  This is probably what is happening more of the time.  The problem here should be pretty obvious too -- you're always less efficient than you could be.  Maybe this isn't a problem if most people are happy with the bitrate though.

Maybe something else is going on and I'm simply missing it, but from the sound of what has been said, I don't think this is the case.
Title: MPC VBR flaws (low volume & ringing)
Post by: rjamorim on 2005-07-11 01:02:59
Thanks for your clarification.

So, from that, one can infer that Musepack is being a little too conservative on choosing an encoding parameter (ATH) to favor on the bitrate efficiency side?
Title: MPC VBR flaws (low volume & ringing)
Post by: Dibrom on 2005-07-11 01:05:20
Quote
Thanks for your clarification.

So, from that, one can infer that Musepack is being a little too conservative on choosing an encoding parameter (ATH) to favor on the bitrate efficiency side?
[a href="index.php?act=findpost&pid=312395"][{POST_SNAPBACK}][/a]


This is what I suspect probably, yes.

'Conservative' here could actually mean 'more exact,' since things seem to sound fine until you push them into the situation guruboolez is describing.  Unfortunately, when that happens there's no headroom anymore and you sometimes might hear artifacts.
Title: MPC VBR flaws (low volume & ringing)
Post by: CiTay on 2005-07-11 01:26:18
Quote
'Conservative' here could actually mean 'more exact,' since things seem to sound fine until you push them into the situation guruboolez is describing.  Unfortunately, when that happens there's no headroom anymore and you sometimes might hear artifacts.
[a href="index.php?act=findpost&pid=312398"][{POST_SNAPBACK}][/a]


Yes, that was my feeling too. With that in mind, i think we should look at the possible fixes, i.e. --ath_gain -14 / Ltq_offset tweaks, and see if we can work something out from there. If it's just an increase of 3, 4 kbit (and it would only be needed for --quality 5/--standard, from what i understand), it could easily be added in a new release. After all, the bits that were shaven off in 1.06~1.1 would simply be added again for one profile.
Title: MPC VBR flaws (low volume & ringing)
Post by: mtm on 2005-07-11 01:35:26
I just want to say I agree with everything Dibrom said. Any postprocessing has the potential to trip a psychoacoustic encoder, especially when the encoder is expected to provide high efficiency. 20 dB amplification is IMO a pretty extreme case and I'm not surprised it can cause some problems. I wouldn't be surprised in case of any codec.

I don't think it's fair to say Musepack is severly flawed and hope no one will. 

I wonder if RG modifiactions can solve all that.

<edit (while still writing > If not, I think CiTay is right that lowering the ath in some new release should not be a problem for any Musepack user, considering only minor bitrate increase (on avarage).
Title: MPC VBR flaws (low volume & ringing)
Post by: guruboolez on 2005-07-11 02:18:09
Quote
The inverse can be said just as well.  Should we conclude that MPC is buggy because it doesn't perform as well as you'd like after you modified the encoded file, invalidating the assumptions the encoder made about masking, etc.?


That's fair. But as other members have said it, ReplayGain is not necessary to increase the volume playback. Even at home, I'm used to modify the volume during the playback. This behaviour might hurt some purists, but it's like making a pause, or listening again and again your favorite passage. It's simply a confort introduced and allowed by recordings (sometimes, Id like to increase the volume on classical concert - and also kill my noisy neighbour, but that's another problem ).

If a problem occurs on specific conditions, then problem lies in the encoder, and not in the listener's choice. Vorbis suffers (or maybe suffered) from perceptible pre-echo which is probably only audible with headphone. The answer to this issue is not to use loudspeakers instead, but rather to tune the encoder. Nobody would say that heaphones are buggy - the encoder is immediately accused, and rightly. If a developer would maintain that listeners should avoid headphones, users would probably switch to another encoding tool more suited to their habits.


Quote
I agree with Frank -- this is not a problem with MPC but a problem with using Replaygain in this way. 

You mean "...but a problem with using ReplayGain and MPC in this way" I suppose. Because I've no problem with current RG implementation - only some lossy encodings leads to problem. Of course, a track adjustment of 30 dB will increase the background noise, but I wouldn't compare this annoyance to the awful ringing produced by mpc --standard on such situations.

Quote
And that doesn't mean that there cannot be some sort of solution found, but I don't think that implementing some sort of imprecise changes in the psymodel to compensate for this special case -- sacrificing efficiency along the way -- is the right answer.


Possibly. But I only know that some encoders could handle this situation very well without sacrificing efficiency. Some of them have even encoding tool thats would allow to stay away from this issue at very low bitrate (vorbis as example, or SBR encoders). I can't say if MPC efficiency will be sacrified by correcting this problem; but I know that other lossy encoders could perfectly handle this situation and maintain in the same time the encoding efficiency.

In my opinion, sacrifying the quality on low volume content in order to increase the efficiency on most common material is a wrong trade off. Of course, it will please people a specific category of listeners, but other could only be disappointed by the poor performance on other material/situations.

Quote
Note: Sorry I accidently hit edit on your post instead of reply

I thought you've tried to correct all my grammatical and syntactic mistakes  Don't do it, it's probably more fastidious than tuning an encoder
Title: MPC VBR flaws (low volume & ringing)
Post by: guruboolez on 2005-07-11 02:26:30
Quote
I don't think it's fair to say Musepack is severly flawed and hope no one will.

The real problem is not the words we use to qualify the issue: it's the perception of the difference between the encoded file and the reference. Currently, MPC --standard produces severe artifacts on situations ~perfectly handled by LAME at 128 kbps. Now you'e free to describe the problem with your own words.
MPC is working very well on many situations. But here, it sucks (forgive my rudeness, but it corresponds IMO to the level of the artifact).

Quote
I wonder if RG modifiactions can solve all that.


Possibly. Another solution is to ask to composers or instrumentists to avoid quiet passages and to play everything loud enough to not mislead MPC current implementation. It should also solve the problem
Title: MPC VBR flaws (low volume & ringing)
Post by: guruboolez on 2005-07-11 11:53:58
Quote
With that in mind, i think we should look at the possible fixes, i.e. --ath_gain -14 / Ltq_offset tweaks, and see if we can work something out from there. If it's just an increase of 3, 4 kbit (and it would only be needed for --quality 5/--standard, from what i understand), it could easily be added in a new release. After all, the bits that were shaven off in 1.06~1.1 would simply be added again for one profile.
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=312401")


I fear that this kind of fix can't be proposed as default. The increase in bitrate would probably appear as excessive. Don't forget that the current 1.15 series is not on par with previous MPC encoders: bitrate is systematically higher, for an identical quality compared to 1.14 on a wide majority of samples. Some users have already complaint about it. 1.06 was the most "efficient" encoder; but when 1.1 was released, the bitrate was highered again to reach the same level than pre-1.06 encoders.

I've tried to evaluate the impact of the --ath_gain -14 on standard preset with my 150 short samples (edit: classical ones - it might differ with other music). It should give an accurate idea of the inflation:

- 1.01j --standard = 185 kbps
- 1.14 --standard = 188 kbps
- 1.15v --standard = 196 kbps
- 1.15v --standard --ath_gain -14 = 214 kbps

As you can see, 1.15v without additional switch already increase the bitrate compared to the latest beta. The inflation could reach 15 kbps per album (tried with harpsichord music) without experiencing any gain in quality. And compared to 1.01j, the difference is even higher - and also recall that [a href="http://www.hydrogenaudio.org/forums/index.php?showtopic=34911]I've tested 1.01j[/url] to sound better on a panel of 15 samples.

Now the ath_gain command would probably increase the quality, but the price to pay is a bitrate, with --standard profile and 1.15v, comparable to older encoder at --extreme profile.

The html files created with MisterQuestionMan:

- mppenc 1.01j (http://guruboolez.free.fr/MPC/MrQ101j.html)
- mppenc 1.14 (http://guruboolez.free.fr/MPC/MrQ114.html)
- mppenc 1.15v (http://guruboolez.free.fr/MPC/MrQ115v.html)
- mppenc 1.15v --ath_gain -14 (http://guruboolez.free.fr/MPC/MrQ115vATHG14.html)
Title: MPC VBR flaws (low volume & ringing)
Post by: CiTay on 2005-07-11 13:01:25
Quote
Now the ath_gain command would probably increase the quality,[a href="index.php?act=findpost&pid=312495"][{POST_SNAPBACK}][/a]


Probably?

Quote
--ath_gain -14 works very well, and solves all issues (I didn't carefully tried to hear smallest difference).



Quote
but the price to pay is a bitrate, with --standard profile and 1.15v, comparable to older encoder at --extreme profile.


That's why i said, we need to work something out, probably with --ath_gain -14 as a basis, and fine-tune from there. I will do some bitrate checking with pop music etc., of course 15 kbit increase would be too much, but i'm confident there is some middle ground.
Title: MPC VBR flaws (low volume & ringing)
Post by: Dibrom on 2005-07-11 13:11:25
I think I probably agree with guruboolez.  I'm not sure this sort of change should be made to the presets.

I really think probably some sort of 2-pass method would be better.  Why not simply calculate the track gain first and use the resulting value as some sort of offset to the defaults for the presets, and then use the already calculated track gain for the encoded file?  That way you sort of get the 2-pass 'for free' because you were going to calculate it anyway.  The downside to this is that the replaygain  value probably won't be exactly what it would have been since the encoded file should calculate just a little bit differently, but the difference should be negligible (I think?).  But doing it this way would probably catch cases where even a preset modification might not be enough, while also allowing the bitrate for most things to stay where it's already at.  The other good thing is that this is something that could be implemented 100% at the frontend side.
Title: MPC VBR flaws (low volume & ringing)
Post by: ancl on 2005-07-11 13:33:15
Quote
I think I probably agree with guruboolez.  I'm not sure this sort of change should be made to the presets.

I really think probably some sort of 2-pass method would be better.  Why not simply calculate the track gain first and use the resulting value as some sort of offset to the defaults for the presets, and then use the already calculated track gain for the encoded file?  That way you sort of get the 2-pass 'for free' because you were going to calculate it anyway.  The downside to this is that the replaygain  value probably won't be exactly what it would have been since the encoded file should calculate just a little bit differently, but the difference should be negligible (I think?).  But doing it this way would probably catch cases where even a preset modification might not be enough, while also allowing the bitrate for most things to stay where it's already at.  The other good thing is that this is something that could be implemented 100% at the frontend side.
[a href="index.php?act=findpost&pid=312506"][{POST_SNAPBACK}][/a]

The 2-pass approch seem like a good solution. Reusing the replaygain can cause problem though - you won't get correct peak information.
Title: MPC VBR flaws (low volume & ringing)
Post by: CiTay on 2005-07-11 13:40:14
Quote
I think I probably agree with guruboolez.  I'm not sure this sort of change should be made to the presets.

I really think probably some sort of 2-pass method would be better.  Why not simply calculate the track gain first and use the resulting value as some sort of offset to the defaults for the presets, and then use the already calculated track gain for the encoded file?  That way you sort of get the 2-pass 'for free' because you were going to calculate it anyway.  The downside to this is that the replaygain  value probably won't be exactly what it would have been since the encoded file should calculate just a little bit differently, but the difference should be negligible (I think?).  But doing it this way would probably catch cases where even a preset modification might not be enough, while also allowing the bitrate for most things to stay where it's already at.  The other good thing is that this is something that could be implemented 100% at the frontend side.
[a href="index.php?act=findpost&pid=312506"][{POST_SNAPBACK}][/a]


Yes, it's a good idea, but some people make mocking fun of such an idea. "How come the superior MPC codec can't handle this big issue, like the other codecs can?!" [which fail at other samples MPC doesn't fail at]. I think it's been blown out of proportion a little, the reactions have gone from zero to "biggest issue of MPC". It's not that big of an issue IMHO, still it should definitely be recognized (like it is now). Now, my slight problem with this 2-pass/RG fix is that it maybe can't be communicated to Average Joe that it is an intelligent fix for a rare issue, and that it would maybe be viewed as a "crutch" by some. A tweaked fix directly to the encoder wouldn't let those thoughts come up, and MPC would easily restore it's (top) position without changing the way the encoding is handled. So there you have it. If certain people can accept a 2-pass/RG solution, all the better. But maybe some people aren't satisfied no matter what.
Title: MPC VBR flaws (low volume & ringing)
Post by: Dibrom on 2005-07-11 13:53:24
Quote
The 2-pass approch seem like a good solution. Reusing the replaygain can cause problem though - you won't get correct peak information.
[a href="index.php?act=findpost&pid=312507"][{POST_SNAPBACK}][/a]


Yeah, I hadn't thought about that.  I would think that the encoder should be able to return the correct peak information after encoding the file though and perhaps this could be combined with the other previously calculated information without having to discard everything.  I admittedly don't know how well this would work though.

If it came down to it, you could always calculate replaygain twice, but this would probably not make guruboolez happy
Title: MPC VBR flaws (low volume & ringing)
Post by: Dibrom on 2005-07-11 13:57:13
Quote
Yes, it's a good idea, but some people make mocking fun of such an idea. "How come the superior MPC codec can't handle this big issue, like the other codecs can?!" [which fail at other samples MPC doesn't fail at]. I think it's been blown out of proportion a little, the reactions have gone from zero to "biggest issue of MPC". It's not that big of an issue IMHO, still it should definitely be recognized (like it is now). Now, my slight problem with this 2-pass/RG fix is that it maybe can't be communicated to Average Joe that it is an intelligent fix for a rare issue, and that it would maybe be viewed as a "crutch" by some. A tweaked fix directly to the encoder wouldn't let those thoughts come up, and MPC would easily restore it's (top) position without changing the way the encoding is handled. So there you have it. If certain people can accept a 2-pass/RG solution, all the better. But maybe some people aren't satisfied no matter what.
[a href="index.php?act=findpost&pid=312509"][{POST_SNAPBACK}][/a]


Well, IMO, a modification to the presets is a hack, not a fix.  A 2-pass solution would be a pretty well targeted fix.  With a preset modification you're going to fix some of the cases, but probably not all of them.  You're also going to end up being less efficient on more cases than not.

Whether it is more important to do it the proper way or to please Joe Average's misconceptions about the nature of the solution is something the MPC maintainers will have to decide I suppose.  Given the fact that MPC doesn't have a very large installed base though and probably never will, at least on the order of something like AAC or MP3, I don't think it's so important to worry about mass perception here.  Besides that, Joe Average probably doesn't even use Replaygain much, so he wouldn't even need to worry about this for the most part.
Title: MPC VBR flaws (low volume & ringing)
Post by: guruboolez on 2005-07-11 14:14:04
Quote
Quote
Now the ath_gain command would probably increase the quality,[a href="index.php?act=findpost&pid=312495"][{POST_SNAPBACK}][/a]


Probably?

Yes, probably. I'm not sure that most samples would benefit from this change. I quote Klemm's comment:
"For most pop titles, you can increase the ATH by 30 dB and still not notice anything."

And I can't say if the regression I've heard by comparing 1.01j to 1.15v could be solved by the ath_gain command. There's also this problem.
Title: MPC VBR flaws (low volume & ringing)
Post by: guruboolez on 2005-07-11 14:27:47
Quote
"How come the superior MPC codec can't handle this big issue, like the other codecs can?!" [which fail at other samples MPC doesn't fail at].


With other encoders, I don't know any artifact as obvious as the one occuring with mpc in the described situation. Could you tell me which sample sound worse with Nero or iTunes AAC and Vorbis set with ~180 kbps preset than with LAME at 128 kbps?
I repeat: it's not because you're not concerned by it that the problem doesn't exist or must have to be described as something neglecting. I would consider this issue as a big one. And I'm totally amazed by the attempt of minimizing it, or reporting the fault on other tools (ReplayGain) or factors (damn listener's habits).


Quote
and MPC would easily restore it's (top) position without changing the way the encoding is handled


Are you sure that MPC is still on top position? Have you tested all other encoders, which have improved a lot during three years, whereas MPC fully stagnate (or even regressed, at least in some conditions)?

The current problem of MPC is not to be sure that MPC is the 'champion' but to solve a problem. Worrying about the superiority of something (i.e. the relative position compared to competitors) is often a sign of zealotry. I'd rather see a HA.org administrator keeping his neutrality rather than spreading doubtful generalisations (recent one was that classical needs --extreme (http://www.hydrogenaudio.org/forums/index.php?showtopic=34924&view=findpost&p=307056); now "MPC" on top) or closing threads like you did with mine. It's really compromizing in my opinion the strictness of this precious board. Working on a real solution, like Dibrom proposal, corresponds certainly more on the idea I have of people interesting by quality of a product more by its reputation (often exessive, and sometimes intentionally). It's not an attack, but I have to confess that I'm more and more perplexed by the kind of attitude you have toward one specific audio format.


EDIT: I'm talking about CiTay, not Dibrom.
Title: MPC VBR flaws (low volume & ringing)
Post by: 2Bdecided on 2005-07-11 14:49:58
I think the concentration on ReplayGain is misleading. Frank's comments are fair enough, but maybe even less relevant to the issue at hand.

The simple point is that, when you have a very quiet track, or a large quiet part in any track, some listeners are going to increase the volume. I do it in the car all the time, and do it at home sometimes too.

Other codecs have a (relatively simple?) floating ath to compensate for this - why can't mpc? It may increase the bitrate a little, in which case there should be a switch to disable it. If it bloats the bitrate massively, then either we're talking about a rare case (several minutes of hissy analogue silence suddenly being encoded very accurately) or something is not acting as required.

Two-pass VBR encoding and/or ReplayGain as part of encoding seem like bad ideas to me. The only relevance ReplayGain has is that you might what something similar to parts of the RG algorithm to check the loudness at a given point and set the floating ath level.

btw, it's not fair to say that this problem is just with mpc - lame VBR encodes from very old versions (before the floating ath) could do similar things, depending on the switches used. My tests near the CD noise floor were trashed by a very old "HQ" VBR mode while they were encoded fine at 128kbps CBR.

If the lame floating ath works well with this issue (I haven't checked) then a similar concept shouldn't be too hard to port to mpc - as long as it didn't mess other things up.

Just my ideas - as usual, I'm not offering to code it!

Cheers,
David.
Title: MPC VBR flaws (low volume & ringing)
Post by: guruboolez on 2005-07-11 15:01:04
Quote
btw, it's not fair to say that this problem is just with mpc - lame VBR encodes from very old versions (before the floating ath) could do similar things, depending on the switches used.

I confirm that. I believe that I have precised that other modern encoders don't have this problem, at least most of them (haven't tried with iTunes AAC); that's why I talked about recent changes in LAME in ABR/CBR mode, and suggested that a similar tool could be implemented in MPC. Dibrom proposal is maybe more efficient.

P.S. Glad to see that I'm not alone to change the volume during playback
Title: MPC VBR flaws (low volume & ringing)
Post by: CiTay on 2005-07-11 15:07:56
Quote
The current problem of MPC is not to be sure that MPC is the 'champion' but to solve a problem. Worrying about the superiority of something (i.e. the relative position compared to competitors) is often a sign of zealotry.


I don't worry one bit about superiority. I didn't necessarily mean first position with top position, i meant it's on top up there, probably now with other codecs as well (why do i have to prove the opposite, we don't want to shift of the burden of proof).

Quote
I'd rather see a HA.org administrator keeping his neutrality rather than spreading doubtful generalisations (recent one was that classical needs --extreme (http://www.hydrogenaudio.org/forums/index.php?showtopic=34924&view=findpost&p=307056); now "MPC" on top) or closing threads like you did with mine.


This is an unfair comment. I clearly explained to you why i closed the thread, due to the very heated discussion at the time, and later i split the thread and notified you again about it. Futhermore, with --q6, i was giving an advice ("should consider") that was reasonable at the time (meaning i had enough reason to believe it would fix or greatly reduce the problem), i did not say that classical music generally needs --q6.
Title: MPC VBR flaws (low volume & ringing)
Post by: Dibrom on 2005-07-11 15:14:14
Quote
The simple point is that, when you have a very quiet track, or a large quiet part in any track, some listeners are going to increase the volume. I do it in the car all the time, and do it at home sometimes too.
[a href="index.php?act=findpost&pid=312522"][{POST_SNAPBACK}][/a]


Yes, but looking back the original quote from guruboolez:

Quote
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)


(emphasis added)

How many people are changing the volume by this much on the average case?  Probably not many, or maybe there's something else going because others (who presumably aren't changing the volume by this much) haven't reported much of this issue before.

A floating ath could help for some of this probably, but my main issue with implementing that in MPC is that I believe it will be very difficult to tune well enough that it can be expected to behave in a very reliable fashion.  It opens up another whole can of worms to deal with.

At any rate, if this issue is showing up mainly for users of replaygain, I don't see why a good solution wouldn't include information provided by replaygain at the encoding stage.  It would be a whole lot more predictable and much easier to tune by doing it this way.

Of course, 2-pass replaygain aware encoding wouldn't help people in a situation like what guruboolez describes who don't use replaygain.

So I think it's probably a tradeoff like this:

1. Use 2-pass encoding and probably get a lot more predictable results.  Implementation could be done much more quickly and would not require modification to the psymodel.  Downside -- doesn't help people who don't use replaygain (but they might not have this issue to begin with).  Potentially makes encoding process take longer.

2.  Use floating ath.  Works in all cases, but only as well as it is tuned.  Downside -- potentially doesn't work as well (may not catch all cases), potentially decreases efficiency.  Much more complex to implement.  Will require someone with enough knowledge of the psymodel to spend the time implementing.
Title: MPC VBR flaws (low volume & ringing)
Post by: guruboolez on 2005-07-11 15:23:19
Quote
I don't worry one bit about superiority. I didn't necessarily mean first position with top position

It's a malentendu. Sorry.

Quote
This is an unfair comment. I clearly explained to you why i closed the thread, due to the very heated discussion at the time, and later i split the thread and notified you again about it.

May I recall you that I had to remind you the existence of the "splitting thread" tool, always used in similar situation, and well suited to not penalize the author of a constructed thread? It's a bit strange that once a negative feedback that concerns a specific format and based on listening test is posted on this board it has to be closed, and then opened again on a member suggestion. Heated discussion occurs really often on this board; are they closed? Or aren't usually trolling intervention thrown into the its rightplace: the dustbin?

Quote
i did not say that classical music generally needs --q6.
It's seems that you've just imply it ("i guess that's a redundant advice for that clientele"). Just a feeling...
Title: MPC VBR flaws (low volume & ringing)
Post by: CiTay on 2005-07-11 15:30:33
Also, guruboolez, i want to apologize to you again about the bad communication here. It is hard sometimes to strike the right note on a forum, when you're not discussing face to face (e.g. "How come the superior MPC codec" -> people mocking it, "oh-so-superior", not my claim). I think i did the best i could to take the problem that you discovered seriously, and i contacted Frank about it who now posts here again. I can't speak on Seed's behalf, but i want you to know that i had acknowledged the problem even though i probably don't have one track in my entire library that would suffer from it. Your effort is much appreciated and i hope the developers also put that effort into fixing such things.
Title: MPC VBR flaws (low volume & ringing)
Post by: CiTay on 2005-07-11 15:33:57
Quote
May I recall you that I had to remind you the existence of the "splitting thread" tool, always used in similar situation, and well suited to not penalize the author of a constructed thread?
[a href="index.php?act=findpost&pid=312546"][{POST_SNAPBACK}][/a]


The thread was closed for 10 minutes max. Maybe someday you can join the HA moderation staff and we can discuss flamewar policies 
Title: MPC VBR flaws (low volume & ringing)
Post by: guruboolez on 2005-07-11 15:35:52
Quote
Yes, but looking back the original quote from guruboolez:

Quote
(you can’t constantly push the volume on such material: your neighbors won’t appreciate it).


(emphasis added)

My sentence implied specific listening conditions: appartment, and loudspeakers. The listening conditions are much less restrictive in a car or when listening on headphones.

Quote
How many people are changing the volume by this much on the average case?  Probably not many, or maybe there's something else going because others (who presumably aren't changing the volume by this much) haven't reported much of this issue before.

May I recall you that few people are reporting feedback, even at 128 kbps. What do you expect with MPC at 180 kbps?
By the way, I could have reported this issue two years ago. But what's the point, when there are no developer to correct the problem. It's like talking to a wall. It could explain why people haven't reported the problem. Same happens with WMA9Pro: why should we report problem on this board? And if problems are not reported (WMA9Pro suffers from the same issue than MPC) it doesn't mean that there are no problems.


Quote
At any rate, if this issue is showing up mainly for users of replaygain, I don't see why a good solution wouldn't include information provided by replaygain at the encoding stage.  It would be a whole lot more predictable and much easier to tune by doing it this way.

Not only for people using ReplayGain for God's sake! You just need to listen at higher volume that the one expected by the psymodel currently set with mpc --standard. It was recalled several time. ReplayGain is just a tool to automate this.
Title: MPC VBR flaws (low volume & ringing)
Post by: guruboolez on 2005-07-11 15:50:16
Quote
The thread was closed for 10 minutes max

Yes, ten minutes, because I've sent to you a private message within eight minutes.

Quote
. Maybe someday you can join the HA moderation staff and we can discuss flamewar policies 

You've contacted me on this question on June, 18. My current situation (limited internet access, no IRQ chat) is not compatible with the way that HA.org moderation work.


Quote
Also, guruboolez, i want to apologize to you again about the bad communication here. It is hard sometimes to strike the right note on a forum, when you're not discussing face to face (e.g. "How come the superior MPC codec" -> people mocking it, "oh-so-superior", not my claim). I think i did the best i could to take the problem that you discovered seriously, and i contacted Frank about it who now posts here again. I can't speak on Seed's behalf, but i want you to know that i had acknowledged the problem even though i probably don't have one track in my entire library that would suffer from it. Your effort is much appreciated and i hope the developers also put that effort into fixing such things.

You don't have to apologize, but if you insist, I'll accept them


What I'd like to see from current MPC team would be comparable reactions to those of other developers (AAC, LAME, WavPack, Vorbis). And not bashing a listening test because you're not happy with it (Seed) by inventing eccentric arguments (the Audigy aliasing which only affects MPC 1.15v was very original I must admit), not deviating the fault on other tools that are working correctly (Klemm), not minimizing the problems because it corresponds to a foreign situation, and not considering big artifacts to a sign of efficiency. I think that a more respectful attitude (for the user as well for the tester) would maybe help MPC to not rejoin the graveyard of audio innovations too quickly.

Yours 
Title: MPC VBR flaws (low volume & ringing)
Post by: CiTay on 2005-07-11 16:03:04
Quote
Quote
The thread was closed for 10 minutes max

Yes, ten minutes, because I've sent to you a private message within eight minutes.


This might be splitting hairs, but i intended to split the thread anyway, regardless of your message. 


Quote
You don't have to apologize, but if you insist, I'll accept them


Thank you.
Title: MPC VBR flaws (low volume & ringing)
Post by: Frank Klemm on 2005-07-11 18:14:53
Quote
The simple point is that, when you have a very quiet track, or a large quiet part in any track, some listeners are going to increase the volume. I do it in the car all the time, and do it at home sometimes too.

Other codecs have a (relatively simple?) floating ath to compensate for this - why can't mpc? It may increase the bitrate a little, in which case there should be a switch to disable it. If it bloats the bitrate massively, then either we're talking about a rare case (several minutes of hissy analogue silence suddenly being encoded very accurately) or something is not acting as required.


Musepack has a relatively complex implemented floating ATH.
But for very small signals the ATH has a limit. The limit is set via ath_gain.
Near the limit (ATH ... ATH+25 dB) the behave of the ATH masking changes.
The NMR is reduced, the ATH adapts slowlier and a lot of things like this.

There are several assumptions about the maximum playback level.
(0 dB FS -> ~110 dB SPL). When the volume control is louder we
have problems when the signal is silent.


Quote
Two-pass VBR encoding and/or ReplayGain as part of encoding seem like bad ideas to me. The only relevance ReplayGain has is that you might what something similar to parts of the RG algorithm to check the loudness at a given point and set the floating ath level.


Two-pass do not work, for instance for /dev/audio.
And we have still the problem, that we don't know anything about
the loudness of neighbour tracks (the whole album is silent or only one track,
in the first case it is more likely that someone turn up the volume control).

Quote
If the lame floating ath works well with this issue (I haven't checked) then a similar concept shouldn't be too hard to port to mpc - as long as it didn't mess other things up.
[a href="index.php?act=findpost&pid=312522"][{POST_SNAPBACK}][/a]


Encoders with a simple floating ATH has advantages when the real playback
level is unknown. You can mute the input by 96 dB, feed it as 32 bit PCM
and get nearly the same result as the full level encoding. A replaygain
of +96 dB do not hurt in this case. Disadvantage is that you code also
pure noise with nearly the full bitrate (transform encoder may be increase
the bitrate because the transform do not compact the information).

When there's a problem with the ATH, use ath_gain. I will do some
checks concerning bitrates for Pop and classic Music depending on the
ATH gain setting.

When the default ATH should be corrected, how much should it be corrected.
Replaygain of Musepack allows boosting and attenuations up to 327 dB (!).
Title: MPC VBR flaws (low volume & ringing)
Post by: Frank Klemm on 2005-07-11 18:23:48
Quote
Quote
ReplayGain ist *not* perfect at all, there's a long list of problems. Actually I use only album based ReplayGain, other modes have a lot of problems which may significantly reduce enjoy music.

Okay?[a href="index.php?act=findpost&pid=311995"][{POST_SNAPBACK}][/a]


Honestly, that's the first time I see that reported here.


The are audible clicks between all tracks with signal between the tracks.
There are also sudden loudness jumps between tracks with signal between the tracks.

I can live with loudness difference within albums (especially when they are intended), but not with obviously artefacts with occure from time to time. I want to relax when I listen to music.
Title: MPC VBR flaws (low volume & ringing)
Post by: krazy on 2005-07-11 19:36:16
Quote
I can live with loudness difference within albums (especially when they are intended), but not with obviously artefacts with occure from time to time. I want to relax when I listen to music.
[a href="index.php?act=findpost&pid=312594"][{POST_SNAPBACK}][/a]

I still don't really understand why album gain is not used in this situation.
Title: MPC VBR flaws (low volume & ringing)
Post by: Frank Klemm on 2005-07-11 19:51:43
Quote
Quote
I can live with loudness difference within albums (especially when they are intended), but not with obviously artefacts with occure from time to time. I want to relax when I listen to music.
[a href="index.php?act=findpost&pid=312594"][{POST_SNAPBACK}][/a]

I still don't really understand why album gain is not used in this situation.
[a href="index.php?act=findpost&pid=312610"][{POST_SNAPBACK}][/a]


Vice versa.
I always use album gain, but nearly never title gain.
Title: MPC VBR flaws (low volume & ringing)
Post by: mtm on 2005-07-12 05:07:43
Quote
The are audible clicks between all tracks with signal between the tracks.
There are also sudden loudness jumps between tracks with signal between the tracks.
[a href="index.php?act=findpost&pid=312594"][{POST_SNAPBACK}][/a]
I can confirm. Some time ago I encountered a soundtrack with horribly uneven volume among all tracks. An experiment with track gain before encoding resulted in clicks and said loudness jumps. At least the second issue would be granted, too, with normal (post-encoding) track gain.

Quote
I will do some checks concerning bitrates for Pop and classic Music depending on the ATH gain setting.
Thank you for your effort.
Title: MPC VBR flaws (low volume & ringing)
Post by: 2Bdecided on 2005-07-12 10:53:20
If you play nogap tracks out of sequence, you'll get clicking (even without ReplayGain). To avoid this, you should cross fade the tracks, or pay a DJ to do it for you!

If you play nogap tracks in sequence, you'll get clicking only when using ReplayGain in Track mode. In this case, you could also avoid clicks by using a simple cross fade as above, but that overlaps the tracks and actually loses a bit of audio.

A neater solution is to join the tracks properly (butted together as normal) while changing the ReplayGain value smoothly around the track transition. So it sounds like the volume control is being carefully adjusted from one ReplayGain value to the other. No click. The ideal time over which to make this change is a subjective judgement, and difficult to automate.

Also, where a track has a gap (like on most albums), it makes no sense to change ReplayGain smoothly between tracks, as this will cause some tracks to fade up or down annoyingly for no reason.

The decision to change abruptly or smoothly could be automated by checking if the track fades to near silence, or continues without a gap.


That looks like a nice project for someone! It's not something most people might use, but some would. It would be a real pain if it went wrong!

Cheers,
David.
Title: MPC VBR flaws (low volume & ringing)
Post by: seanyseansean on 2005-07-12 10:57:01
Quote
A neater solution is to join the tracks properly (butted together as normal) while changing the ReplayGain value smoothly around the track transition. So it sounds like the volume control is being carefully adjusted from one ReplayGain value to the other. No click. The ideal time over which to make this change is a subjective judgement, and difficult to automate.[a href="index.php?act=findpost&pid=312744"][{POST_SNAPBACK}][/a]


So this would be implemented as a 'Replaygain DSP' then? You could have an adjustable adjustment period which smoothly adjusted from 1 replaygain value to another, but with no crossfade?
Title: MPC VBR flaws (low volume & ringing)
Post by: dev0 on 2005-07-12 11:17:40
Quote
That looks like a nice project for someone! It's not something most people might use, but some would. It would be a real pain if it went wrong![a href="index.php?act=findpost&pid=312744"][{POST_SNAPBACK}][/a]

And it's certainly more elegant than the DSP/3rd RG-mode solution Klemm suggested.
Title: MPC VBR flaws (low volume & ringing)
Post by: Frank Klemm on 2005-07-12 22:39:25
Quote
Quote
The are audible clicks between all tracks with signal between the tracks.
There are also sudden loudness jumps between tracks with signal between the tracks.
[a href="index.php?act=findpost&pid=312594"][{POST_SNAPBACK}][/a]
I can confirm. Some time ago I encountered a soundtrack with horribly uneven volume among all tracks. An experiment with track gain before encoding resulted in clicks and said loudness jumps. At least the second issue would be granted, too, with normal (post-encoding) track gain.

Quote
I will do some checks concerning bitrates for Pop and classic Music depending on the ATH gain setting.
Thank you for your effort.
[a href="index.php?act=findpost&pid=312720"][{POST_SNAPBACK}][/a]


Nightwish -- Tales from the Elvenpath -- Dead Boy's Poem
Code: [Select]
 PCM size File size  Ratio  kbps    Duration  Param Frequency  Name
  72.088     5.936          116    6:48.667  (2x16 44100 Hz)  +40.mpc
  72.088     7.017          137    6:48.667  (2x16 44100 Hz)  +30.mpc
  72.088     7.797  9.246   153    6:48.667  (2x16 44100 Hz)  +20.mpc
  72.088     8.388  8.594   164    6:48.667  (2x16 44100 Hz)  +10.mpc
  72.088     8.821  8.172   173    6:48.667  (2x16 44100 Hz)  0.mpc
  72.088     9.142  7.885   179    6:48.667  (2x16 44100 Hz)  -10.mpc
  72.088     9.426  7.648   185    6:48.667  (2x16 44100 Hz)  -20.mpc
  72.088     9.660  7.462   189    6:48.667  (2x16 44100 Hz)  -30.mpc
  72.088     9.852  7.317   193    6:48.667  (2x16 44100 Hz)  -40.mpc
 648.799    76.042  8.532   165   61:18.000                   --- 9 files ---

RG -8.2 dB

80/81 (CD 1) (1981) -- Pat Metheny/Charlie Haden -- Two Folk Songs: 1st (Pat Metheny)%3B 2nd (Charlie Haden)
Code: [Select]
 PCM size File size  Ratio  kbps    Duration  Param Frequency  Name
 220.970    16.638          106   20:52.667  (2x16 44100 Hz)  +40.mpc
 220.970    20.651          132   20:52.667  (2x16 44100 Hz)  +30.mpc
 220.970    23.596  9.364   151   20:52.667  (2x16 44100 Hz)  +20.mpc
 220.970    25.983  8.504   166   20:52.667  (2x16 44100 Hz)  +10.mpc
 220.970    27.951  7.906   179   20:52.667  (2x16 44100 Hz)  0.mpc
 220.970    29.363  7.525   188   20:52.667  (2x16 44100 Hz)  -10.mpc
 220.970    30.373  7.275   194   20:52.667  (2x16 44100 Hz)  -20.mpc
 220.970    31.172  7.089   199   20:52.667  (2x16 44100 Hz)  -30.mpc
 220.970    31.835  6.941   203   20:52.667  (2x16 44100 Hz)  -40.mpc
1988.733   237.565  8.371   169  187:54.000                   --- 9 files ---

RG +2.2 dB

Debussy -- Syrincs
Code: [Select]
Damn, where is this nice CD

RG +10.3 dB
Title: MPC VBR flaws (low volume & ringing)
Post by: guruboolez on 2005-07-13 00:41:48
I made a similar comparison, using short samples divided in 2 groups: one for classical (150 samples, links if needed here (http://www.hydrogenaudio.org/forums/index.php?showtopic=35438&view=findpost&p=312300)) and a smaller one for various music.

Code: [Select]
									
+40 +30 +20 +10 default -10 -20 -30 -40
41_30sec  144 175 199 214 223 230 236 241 245
ATrain    104 146 171 187 198 206 213 219 223
BigYellow 143 163 176 185 192 197 202 206 210
Blackwater 111 134 153 171 185 194 201 207 212
bodyheat  110 133 149 161 171 180 187 192 195
chanchan  130 154 171 182 191 198 204 209 214
DaFunk    122 147 166 179 188 195 201 206 210
death2    86 108 129 155 185 204 216 224 230
EnolaGay  141 165 180 189 196 202 205 208 212
experienci 132 152 165 174 180 186 190 194 197
FloorEssen 147 168 184 196 206 213 218 222 226
getiton  101 126 146 163 176 187 196 203 208
gone      114 134 151 167 178 186 193 198 202
Illinois  127 163 188 208 218 226 233 239 244
ItCouldBeS 85 97 104 109 112 115 117 118 121
kraftwerk 80 106 156 191 209 220 228 233 238
Layla    143 166 183 197 206 213 219 224 228
Leahy    144 168 183 193 201 208 213 217 221
LifeShatte 121 137 149 158 165 172 178 181 185
Mama      115 129 139 146 152 157 161 165 167
MidnightVo 114 145 169 184 195 203 210 214 219
mybloodrus 130 155 175 191 203 212 219 225 230
NewYorkCit 140 156 166 175 181 188 192 196 200
OrdinaryWo 143 164 178 189 197 203 209 213 216
Quizas    115 141 162 177 187 195 201 207 210
rosemary  104 129 148 162 173 181 188 192 197
Scars    128 149 164 176 185 193 199 203 207
SinceAlway 133 154 168 178 187 194 199 204 208
thear1    134 150 163 172 179 187 192 196 199
TheSource 105 134 155 168 176 182 186 190 192
TomsDiner 83 110 133 150 163 171 177 182 187
trust    120 143 159 171 180 188 194 199 204
Twelve    134 156 172 183 192 200 206 211 216
velvet    134 169 195 212 223 231 237 241 244
Waiting  129 153 171 184 194 201 208 213 218

AVERAGE 121,31 145,11 163,43 177,06 187,06 194,80 200,80 205,49 209,57
+40 +30 +20 +10 default -10 -20 -30 -40

A01_etchin 107 140 167 185 198 209 218 224 230
A02_metamo 124 156 178 191 200 206 211 214 217
A03_emese 194 211 227 242 255 265 275 281 284
A04_pierre 131 156 176 189 199 206 211 215 219
A05_tribou 141 162 176 185 190 194 197 199 201
E01_MODERN 117 147 168 185 198 210 219 225 232
E02_MODERN 87 115 143 168 187 203 214 221 228
E03_MODERN 99 126 152 180 197 208 216 223 228
E04_MODERN 135 169 190 205 214 221 226 230 235
E05_MODERN 99 132 159 175 186 195 203 210 214
E06_MODERN 126 157 180 197 207 216 223 229 234
E07_MODERN 104 135 168 193 209 220 228 234 240
E08_MODERN 119 144 162 173 181 187 193 198 203
E09_MODERN 98 126 154 178 196 209 220 227 234
E10_MODERN 88 118 148 170 185 195 203 209 214
E11_MODERN 98 146 178 198 212 221 228 234 239
E12_MODERN 91 120 145 166 183 198 209 217 222
E13_MODERN 117 154 181 200 213 223 233 241 247
E14_MODERN 102 134 163 183 199 210 219 225 230
E15_MODERN 91 115 145 174 197 216 228 238 245
E16_MODERN 104 136 165 192 210 222 230 237 243
E17_MODERN 82 115 145 171 189 202 210 216 223
E18_MODERN 96 124 150 171 188 200 209 215 220
E19_MODERN 115 150 177 196 210 220 227 233 238
E20_MODERN 42 72 101 131 169 199 210 219 227
E21_MODERN 66 95 124 148 166 179 188 195 201
E22_MODERN 73 100 135 169 188 201 209 216 221
E23_MODERN 119 146 167 182 194 203 211 217 221
E24_MODERN 89 124 158 183 199 211 220 227 233
E25_MODERN 128 151 168 180 189 196 202 206 210
E26_MODERN 92 119 143 164 181 194 203 210 215
E27_MODERN 70 92 112 136 166 187 197 204 213
E28_MODERN 107 129 147 160 172 182 189 196 201
E29_MODERN 128 155 173 186 196 204 212 219 224
E30_MODERN 117 139 157 171 183 191 199 205 209
E31_PERIOD 164 188 203 213 221 227 232 237 241
E32_PERIOD 151 179 199 213 224 232 240 246 250
E33_PERIOD 128 156 180 197 209 217 223 229 235
E34_PERIOD 57 81 113 145 170 189 202 210 217
E35_PERIOD 102 152 188 211 226 237 245 252 258
E36_PERIOD 172 202 220 232 239 244 249 252 255
E37_PERIOD 118 154 182 202 216 226 233 239 244
E38_PERIOD 101 136 165 185 201 212 220 227 231
E39_PERIOD 71 105 137 165 187 203 217 226 233
E40_PERIOD 105 133 158 177 192 203 212 219 225
E41_PERIOD 115 161 196 217 230 239 247 254 258
E42_PERIOD 129 168 198 219 232 242 251 259 264
E43_PERIOD 124 159 185 203 216 226 234 241 247
E44_PERIOD 56 91 130 169 194 209 219 227 233
E45_PERIOD 152 182 201 214 223 230 236 241 246
E46_PERIOD 78 114 147 173 191 204 214 221 227
E47_PERIOD 103 137 166 187 203 215 224 231 236
E48_PERIOD 134 170 196 213 224 233 239 244 248
E49_PERIOD 91 122 149 171 187 199 208 215 220
E50_PERIOD 137 167 189 205 216 226 233 239 244
E51_PERIOD 112 143 169 187 200 209 217 223 228
E52_PERIOD 131 162 184 199 211 220 226 232 236
E53_PERIOD 101 136 167 192 208 218 225 232 238
E54_PERIOD 105 133 156 172 184 193 200 205 210
E55_PERIOD 113 146 172 190 203 212 220 226 230
E56_PERIOD 148 167 182 194 203 210 216 221 225
E57_PERIOD 137 160 176 187 196 204 211 216 220
E58_PERIOD 128 148 162 173 183 191 197 201 204
E59_PERIOD 141 174 194 208 218 226 233 237 242
E60_PERIOD 100 126 147 166 183 195 203 210 215
S01_BOW_Ce 88 123 151 170 183 191 197 202 206
S02_BOW_Ce 46 64 84 110 139 170 187 197 206
S03_BOW_Ce 54 76 105 144 178 204 219 228 236
S04_BOW_Er 101 141 175 198 212 223 231 238 244
S05_BOW_Ga 102 155 198 223 237 246 254 260 265
S06_BOW_Vi 106 141 175 200 217 228 236 243 248
S07_BOW_Vi 105 139 172 197 214 225 232 238 243
S08_BOW_Vi 122 157 184 203 216 224 231 236 240
S09_BOW_Vi 89 137 188 221 240 252 260 266 271
S10_KEYBOA 82 124 156 181 196 206 215 221 227
S11_KEYBOA 137 181 210 230 244 254 263 271 276
S12_KEYBOA 167 204 226 242 253 262 270 276 280
S13_KEYBOA 174 194 207 217 224 231 236 241 245
S14_KEYBOA 147 165 178 188 196 204 209 214 218
S15_KEYBOA 108 139 171 198 210 219 224 229 233
S16_KEYBOA 158 201 231 251 264 273 281 288 292
S17_KEYBOA 92 130 165 189 204 215 222 229 234
S18_KEYBOA 61 88 122 164 189 205 216 224 230
S19_KEYBOA 125 165 198 226 241 251 260 266 271
S20_KEYBOA 102 127 154 176 193 205 213 220 226
S21_KEYBOA 95 145 186 207 219 228 233 241 246
S22_KEYBOA 62 110 163 206 237 257 267 277 283
S23_KEYBOA 72 95 124 156 185 199 207 214 220
S24_KEYBOA 85 108 128 146 163 185 200 209 217
S25_KEYBOA 34 49 70 129 168 187 196 205 210
S26_KEYBOA 31 45 59 72 102 157 188 206 215
S27_KEYBOA 94 119 142 164 181 198 208 215 221
S28_KEYBOA 72 90 106 125 152 188 208 219 228
S29_KEYBOA 74 98 123 150 174 192 203 212 219
S30_OTHERS 121 178 233 272 300 317 328 338 345
S31_OTHERS 59 88 118 145 167 188 204 216 224
S32_OTHERS 123 168 205 231 252 266 276 283 288
S33_OTHERS 73 123 170 203 223 235 243 249 253
S34_OTHERS 80 122 168 205 230 245 254 261 267
S35_OTHERS 100 126 148 164 178 188 196 202 207
S36_OTHERS 71 100 129 158 185 206 221 231 240
S37_OTHERS 46 59 79 114 159 188 206 218 225
S38_PINCH_ 74 98 126 160 185 202 213 222 228
S39_PINCH_ 54 74 97 128 166 191 205 215 222
S40_PINCH_ 79 111 154 186 205 217 226 233 239
S41_PINCH_ 44 68 100 139 171 193 205 213 221
S42_PINCH_ 52 80 112 150 181 200 212 219 226
S43_PINCH_ 80 110 143 171 194 205 215 223 229
S44_WIND_B 131 179 219 249 269 281 293 301 306
S45_WIND_B 72 102 137 173 203 223 236 246 254
S46_WIND_C 102 138 172 201 226 240 249 256 261
S47_WIND_C 66 95 127 165 204 226 240 249 256
S48_WIND_C 78 105 137 176 210 233 246 253 260
S49_WIND_F 63 95 128 159 186 206 218 228 234
S50_WIND_F 102 145 183 207 224 234 241 246 251
S51_WIND_F 76 106 142 173 194 207 215 222 227
S52_WIND_O 66 90 119 149 176 193 203 211 218
S53_WIND_S 93 129 164 192 218 248 266 276 283
S54_WIND_T 75 103 129 156 184 216 232 241 250
S55_WIND_T 102 128 149 168 186 210 222 230 237
V01_CHORUS 99 134 159 176 189 198 206 212 217
V02_CHORUS 92 124 149 168 182 193 201 207 212
V03_CHORUS 25 42 62 82 109 168 205 224 236
V04_CHORUS 137 159 175 186 195 203 209 214 219
V05_CHORUS 100 130 155 174 188 199 207 214 219
V06_CHORUS 99 129 152 168 179 188 195 201 206
V07_CHORUS 91 117 140 160 174 185 192 200 205
V08_CHORUS 124 150 169 183 194 202 210 215 219
V09_DUET_F 89 118 145 165 181 192 202 210 216
V10_DUET_M 85 115 146 175 191 201 207 214 220
V11_DUET_S 51 76 103 131 158 174 186 193 200
V12_PLAINC 110 140 166 186 199 209 216 223 227
V13_PLAINC 105 130 151 167 178 186 193 198 201
V14_PLAINC 94 119 143 164 178 189 197 205 211
V15_PLAINC 103 138 163 181 193 205 215 224 231
V16_PLAINC 64 93 125 158 185 201 212 220 226
V17_PLAINC 56 77 106 146 182 202 217 226 234
V18_SOLOIS 79 111 144 173 192 205 214 222 229
V19_SOLOIS 47 75 118 161 182 196 203 211 216
V20_SOLOIS 119 150 174 193 206 216 224 231 236
V21_SOLOIS 87 110 131 152 167 177 185 193 200
V22_SOLOIS 83 113 143 169 188 201 210 217 222
V23_SOLOIS 94 125 157 185 204 217 226 234 240
V24_SOLOIS 123 157 181 197 209 218 225 231 237
V25_SOLOIS 73 108 148 183 201 213 221 228 233
V26_SOLOIS 85 115 140 163 182 195 206 216 223
V27_SOLOIS 100 132 155 172 184 193 201 207 212
V28_SOLOIS 75 102 137 170 193 207 218 227 234
V29_SOLOIS 96 124 146 166 178 186 194 200 205
V30_SOLOIS 82 111 140 165 184 197 207 215 221

98,23 128,77 156,37 179,68 197,52 210,98 220,34 227,47 233,09

+40 +30 +20 +10 default -10 -20 -30 -40


SUMMARY:

Code: [Select]

ath_gain +40 +30 +20 +10 default -10 -20 -30 -40


various music 121 145 163 177 187 195 201 205 210
classical music 98 129 156 180 198 211 220 227 233

The bitrate range is much wider with classical (98 -> 227) than with other samples (121 -> 210 kbps).
A simple ath_gain -10 with classical lead to the same average value than --ath_gain -40 with the second group!

Also take a look on V03 and S26.
Title: MPC VBR flaws (low volume & ringing)
Post by: mtm on 2005-07-15 11:57:17
Quote
If you play nogap tracks out of sequence, you'll get clicking (even without ReplayGain). To avoid this, you should cross fade the tracks, or pay a DJ to do it for you!

If you play nogap tracks in sequence, you'll get clicking only when using ReplayGain in Track mode. In this case, you could also avoid clicks by using a simple cross fade as above, but that overlaps the tracks and actually loses a bit of audio.[a href="index.php?act=findpost&pid=312744"][{POST_SNAPBACK}][/a]
I'm sorry for the late reply.

Thank you for the detailed description.  I do know about that - it takes a bit of hand-editing in cases such as the one I described. My post was by no means of RG-bashing kind and I'm sorry if it sounded a bit like that. I just wanted to give an example that track gain can introduce some unwanted effects, because rjamorim was surprised to hear about problems. Peace.

Quote
And it's certainly more elegant than the DSP/3rd RG-mode solution Klemm suggested.
Hmm... Frank's idea is more complicated, but would solve not only clicks and sudden loudness jumps, but also help with very dynamic music, where some parts would have to be clipped to raise the avarage loudness to normal RG level. I think Frank had a very good idea. But I agree that 2Bdecided's proposed solution would be much easier to implement and would not change the general RG behaviour.

Quote
A simple ath_gain -10 with classical lead to the same average value than --ath_gain -40 with the second group!
Indeed. The relative difference is higher with classical music, too, when the ATH is lowered.


(thinking loudly) If -14 dB with Q5 were enough and lowering the ATH for all profiles chosen as a temporary solution (using an additional switch, for instance), maybe it would be sufficient to lower the ATH in profiles > Q5 to that level only ? We know it's already being lowered with each profile. This way, the bitrate would not change as much beyond Q5.

guruboolez, do you think the bitrate increases too much, when ATH is 14 dB lower ?

Best regards,
MTM
Title: MPC VBR flaws (low volume & ringing)
Post by: 2Bdecided on 2005-07-15 13:43:17
Quote
My post was by no means of RG-bashing kind and I'm sorry if it sounded a bit like that.[a href="index.php?act=findpost&pid=313557"][{POST_SNAPBACK}][/a]


No worries, I didn't take it that way at all - it just reminded me of an idea which I decided to type out!

Cheers,
David.
Title: MPC VBR flaws (low volume & ringing)
Post by: mtm on 2005-07-15 13:49:57
Phew.
Title: MPC VBR flaws (low volume & ringing)
Post by: guruboolez on 2005-07-17 13:53:49
Quote
guruboolez, do you think the bitrate increases too much, when ATH is 14 dB lower ?

In my opinion (and it's only mine), MPC --standard was mainly intersting for the quality/bitrate ratio: near-transparency a only 175...180 kbps (i.e. less than LAME --preset standard or Vorbis -q6).


Current mppenc (1.15v) is less interesting than older release, due to the bitrate inflation (for classical, it's 7...10 kbps on average - sometimes 15...20 kbps with specific recordings). Now add 15...25 additional kbps with --ath_gain -14 command, and MPC --standard will clearly exceed 200 kbps. I let you imagine the gap between --radio and --standard. With such bitrate I would consider mpc --standard to my eyes as something less interesting than before.
Title: MPC VBR flaws (low volume & ringing)
Post by: GeSomeone on 2005-07-20 16:52:29
Quote
Frank's idea is more complicated, but would solve not only clicks and sudden loudness jumps, but also help with very dynamic music, where some parts would have to be clipped to raise the avarage loudness to normal RG level.[a href="index.php?act=findpost&pid=313557"][{POST_SNAPBACK}][/a]

That idea actualy is more that of an advanced compressor. Replaygain is the more practical idea, thus easier to support on many formats and players. 2Bdecided's idea of a volume fade, from one RG value into the next, could be a player feature. (zZzZzZz?)