IPB

Welcome Guest ( Log In | Register )

5 Pages V  < 1 2 3 4 > »   
Reply to this topicStart new topic
MPC VBR flaws (low volume & ringing), audible under specific conditions
Cyaneyes
post Jul 3 2005, 02:43
Post #26





Group: Members
Posts: 297
Joined: 21-September 03
Member No.: 8934



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.
Go to the top of the page
+Quote Post
Andavari
post Jul 3 2005, 03:47
Post #27





Group: Members
Posts: 935
Joined: 3-June 02
From: USA
Member No.: 2204



QUOTE (Cyaneyes @ Jul 2 2005, 07:43 PM)
Just to comment on Frank's thoughts on Track gain...
*

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.


--------------------
Complexity of incoherent design.
Go to the top of the page
+Quote Post
Lyx
post Jul 3 2005, 04:27
Post #28





Group: Members
Posts: 3353
Joined: 6-July 03
From: Sachsen (DE)
Member No.: 7609



*nevermind - i mixed up trackgain and albumgain*

This post has been edited by Lyx: Jul 3 2005, 04:30


--------------------
I am arrogant and I can afford it because I deliver.
Go to the top of the page
+Quote Post
xmixahlx
post Jul 3 2005, 11:29
Post #29





Group: Members
Posts: 1394
Joined: 20-December 01
From: seattle
Member No.: 693



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


--------------------
RareWares/Debian :: http://www.rarewares.org/debian.html
Go to the top of the page
+Quote Post
guruboolez
post Jul 5 2005, 13:33
Post #30





Group: Members (Donating)
Posts: 3474
Joined: 7-November 01
From: Strasbourg (France)
Member No.: 420



QUOTE (CiTay @ Jul 2 2005, 09:40 PM)
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"? blink.gif

This post has been edited by guruboolez: Jul 5 2005, 14:05
Go to the top of the page
+Quote Post
markanini
post Jul 5 2005, 14:45
Post #31





Group: Members
Posts: 534
Joined: 22-December 03
From: Malmö, Sweden
Member No.: 10615



QUOTE (guruboolez @ Jul 5 2005, 01:33 PM)
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"? blink.gif
*


I don't think many use track gain for classical music.
Go to the top of the page
+Quote Post
Lime
post Jul 5 2005, 15:10
Post #32





Group: Members
Posts: 9
Joined: 13-December 03
Member No.: 10410



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.
Go to the top of the page
+Quote Post
Raptus
post Jul 5 2005, 15:41
Post #33





Group: Members
Posts: 73
Joined: 22-February 04
From: Germany
Member No.: 12191



QUOTE (Gabriel @ Jun 23 2005, 11:33 AM)
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...
Go to the top of the page
+Quote Post
Shade[ST]
post Jul 5 2005, 15:47
Post #34





Group: Members
Posts: 1189
Joined: 19-May 05
From: Montreal, Canada
Member No.: 22144



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...
Go to the top of the page
+Quote Post
Gabriel
post Jul 5 2005, 16:04
Post #35


LAME developer


Group: Developer
Posts: 2950
Joined: 1-October 01
From: Nanterre, France
Member No.: 138



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.
Go to the top of the page
+Quote Post
guruboolez
post Jul 5 2005, 16:17
Post #36





Group: Members (Donating)
Posts: 3474
Joined: 7-November 01
From: Strasbourg (France)
Member No.: 420



QUOTE (markanini @ Jul 5 2005, 02:45 PM)
I don't think many use track gain for classical music.
*

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...
Go to the top of the page
+Quote Post
Dibrom
post Jul 5 2005, 16:25
Post #37


Founder


Group: Admin
Posts: 2958
Joined: 26-August 02
From: Nottingham, UK
Member No.: 1



QUOTE (guruboolez @ Jul 5 2005, 04:33 AM)
QUOTE (CiTay @ Jul 2 2005, 09:40 PM)
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...
Go to the top of the page
+Quote Post
Dibrom
post Jul 5 2005, 16:46
Post #38


Founder


Group: Admin
Posts: 2958
Joined: 26-August 02
From: Nottingham, UK
Member No.: 1



QUOTE (Gabriel @ Jul 5 2005, 07:04 AM)
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.
*


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.
Go to the top of the page
+Quote Post
guruboolez
post Jul 5 2005, 16:51
Post #39





Group: Members (Donating)
Posts: 3474
Joined: 7-November 01
From: Strasbourg (France)
Member No.: 420



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
wink.gif

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.

This post has been edited by guruboolez: Jul 5 2005, 16:52
Go to the top of the page
+Quote Post
Dibrom
post Jul 5 2005, 17:26
Post #40


Founder


Group: Admin
Posts: 2958
Joined: 26-August 02
From: Nottingham, UK
Member No.: 1



QUOTE (guruboolez @ Jul 5 2005, 07:51 AM)
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
wink.gif


Hey, I can change my mind, right? smile.gif

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.
Go to the top of the page
+Quote Post
Vertigo
post Jul 5 2005, 17:26
Post #41





Group: Members
Posts: 65
Joined: 19-May 03
From: Lakeland, FL
Member No.: 6702



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.
Go to the top of the page
+Quote Post
Dibrom
post Jul 5 2005, 17:26
Post #42


Founder


Group: Admin
Posts: 2958
Joined: 26-August 02
From: Nottingham, UK
Member No.: 1



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)

This post has been edited by Dibrom: Jul 5 2005, 17:39
Go to the top of the page
+Quote Post
Vertigo
post Jul 5 2005, 17:32
Post #43





Group: Members
Posts: 65
Joined: 19-May 03
From: Lakeland, FL
Member No.: 6702



I think we need to send Guruboolez the HA Controversy Award, he's certainly earned it over the years.
Go to the top of the page
+Quote Post
rjamorim
post Jul 5 2005, 17:51
Post #44


Rarewares admin


Group: Members
Posts: 7515
Joined: 30-September 01
From: Brazil
Member No.: 81



QUOTE (Vertigo @ Jul 5 2005, 01:32 PM)
I think we need to send Guruboolez the HA Controversy Award, he's certainly earned it over the years.
*


More than me? I'm desolated! :-B


--------------------
Get up-to-date binaries of Lame, AAC, Vorbis and much more at RareWares:
http://www.rarewares.org
Go to the top of the page
+Quote Post
Vertigo
post Jul 5 2005, 17:57
Post #45





Group: Members
Posts: 65
Joined: 19-May 03
From: Lakeland, FL
Member No.: 6702



QUOTE (rjamorim @ Jul 5 2005, 08:51 AM)
QUOTE (Vertigo @ Jul 5 2005, 01:32 PM)
I think we need to send Guruboolez the HA Controversy Award, he's certainly earned it over the years.
*


More than me? I'm desolated! :-B
*



No, your HA Shit-stirrer award is in the mail.
Go to the top of the page
+Quote Post
guruboolez
post Jul 5 2005, 18:52
Post #46





Group: Members (Donating)
Posts: 3474
Joined: 7-November 01
From: Strasbourg (France)
Member No.: 420



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 tongue.gif

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? smile.gif

re- wink.gif
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.

This post has been edited by guruboolez: Jul 5 2005, 18:58
Go to the top of the page
+Quote Post
Jebus
post Jul 5 2005, 20:22
Post #47





Group: Developer
Posts: 1289
Joined: 17-March 03
From: Calgary, AB
Member No.: 5541



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.

This post has been edited by Jebus: Jul 5 2005, 20:23
Go to the top of the page
+Quote Post
CiTay
post Jul 8 2005, 22:19
Post #48


Administrator


Group: Admin
Posts: 2376
Joined: 22-September 01
Member No.: 3



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.
Go to the top of the page
+Quote Post
Gabriel
post Jul 9 2005, 11:16
Post #49


LAME developer


Group: Developer
Posts: 2950
Joined: 1-October 01
From: Nanterre, France
Member No.: 138



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.
Go to the top of the page
+Quote Post
Gambit
post Jul 9 2005, 11:48
Post #50


Burrrn developer


Group: Developer
Posts: 917
Joined: 25-November 01
From: Bratislava, Slovakia
Member No.: 534



It seems funny to me that you would try to fix Replaygain, when the problem is clearly on Musepack's side.


--------------------
Burrrn - http://www.burrrn.net/
MPEG Audio Collection - http://mac.sourceforge.net/
Go to the top of the page
+Quote Post

5 Pages V  < 1 2 3 4 > » 
Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 18th April 2014 - 20:05