Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Replay Gain specification (Read 55805 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Replay Gain specification

Reply #25 –
Quote from: twittles on
I'd like to see what difference this makes as well under various real-world situations.

In the commercial designs I've reviewed, the introduction of a digitally-controlled gain stage degrades performance to the extent that you can get about the same or better system performance by not using the top two MSBs of your DAC when you need to attenuate by the amounts we're talking about with RG. If you don't believe me, look up the specs on digital attenuator devices. It is not that the attenuators suck badly it's because today's DACs are so good.

Replay Gain specification

Reply #26 –
Back to the standard itself. There are a few questions coming to my mind regarding the scanner. Please have mercy on me asking these possibly trivial questions, but my knowledge regarding filter construction is limited at best.

Quote
Required equal loudness filter

[...]

[A] representative average of the above curves [i.e. the equal loudness curves as measured by Robinson and Dadson, 1956, and Fletcher and Munson, 1933] will is chosen as the target filter. The desired filter response is shown in Figure 2.

Will the final standard define the "representative average" more detailed then just giving a figure?

Quote
Design of the equal loudness filter

[...]

Feeding the target response into [MATLAB] yulewalk.m, and requesting a 2x10 coefficient IIR filter gives the following response: [referring to fig. 3].

[...]

One solution is to cascade the yulewalk filter with a 2nd order Butterworth high pass filter, with a high pass frequency of 150 Hz. The resulting combined response (Figure 4) is close to our target response, and is used by Replay Level.

Will the resulting coefficients of the yulewalk and the Butterworth filters (cf. http://replaygain.hydrogenaudio.org/equal_loud_coef.txt) be part of the standard?

When is an alternate scanner implementation (as e.g. wavegain using two IIR filters with different coefficients, possibly with the same or similar response as the MATLAB yulkewalk and Butterworth filters) called compliant with the standard?

Replay Gain specification

Reply #27 –
Just letting you know that I took the liberty and bumped an old algorithm-related thread on ReplayGain with some updates, as an invitation to continue the development related disussion there.

http://www.hydrogenaudio.org/forums/index....showtopic=69568

Best,

Chris
If I don't reply to your reply, it means I agree with you.

Replay Gain specification

Reply #28 –
Please consider something in the enhanced spec to deal with how HDCD processing and Replaygain should fit together.  Per the thread here http://www.hydrogenaudio.org/forums/index....showtopic=79427 , it seems that currently one must not use Replaygain processing for any tracks for which one wants to decode for HDCD.  It seems that Replaygain is currently applied first, and when this is done it somehow corrupts whatever the HDCD decoder needs to detect and decode properly. 

If it can be done, it makes sense to me to have Replaygain to either not corrupt whatever is messing up HDCD processing, or perhaps have Replaygain have an option to allow the user to detect for HDCD, and if chosen, have Replaygain combine its processing and whatever HDCD does in a coordinated fashion.  It appears that hardware solutions can decode all aspects of HDCD, but HDCD.exe that a few applications seem to use only process portions of the full HDCD spec - I have no idea what this means for the Replaygain spec, but the person who wrote HDCD.exe seems to be over in Doom9 per http://forum.doom9.org/showthread.php?t=129136

In general, whatever you can do to not force users to pick either Replaygain use or HDCD decoding would be appreciated.  At a very minimum, please make in clear in the current spec that this current tradeoff must occur, if the thread above is accurate.  Thanks for picking up Replaygain spec documentation and development!

Replay Gain specification

Reply #30 –
Quote from: greynol on
I think a post-processing implementation of RG should be handled by the player, rather than within the RG specification.



That's way it's implicitly done today, and this approach fails users who want the benefits of both.  The current Replaygain spec is silent on this issue, and since other developers are not mind readers, this issue is not dealt with.  A different result requires a different approach.

Replay Gain specification

Reply #31 –
Quote from: grindel on
That's way it's implicitly done today, and this approach fails users who want the benefits of both.  The current Replaygain spec is silent on this issue, and since other developers are not mind readers, this issue is not dealt with.  A different result requires a different approach.

Yes and the approach should be taken up with the people designing the players which actually perform the post-processing rather than simply shifting expectation of omniscience over to the specification.

Think about it: people might want RG to be post-surround sound processing or post-EQ or album gain that is applied to an arbitrary playlist.

Also, consider that HDCD decoding is not an open specification.

Replay Gain specification

Reply #32 –
Quote from: greynol on
Yes and the approach should be taken up with the people designing the players which actually perform the post-processing rather than simply shifting expectation of omniscience over to the specification.

Think about it: people might want RG to be post-surround sound processing or post-EQ or album gain that is applied to an arbitrary playlist.

Also, consider that HDCD decoding is not an open specification.



Forget HDCD, I just wish I could apply RG to .dts and .ac3 (or .dtswav/.ac3wav) bitstreams.  I can't see clearly how this would be done, though.  If transmission isn't bit-perfect, such files only yield white noise from my AVR. 


Replay Gain specification

Reply #33 –
Replay Gain is not the missing link for highly individual, particular problems. It has a well defined purpose. Its place within the playback chain is after decoding. HDCD decoding should happen before Replay Gain application, the same is true for dts and ac3 and all other codecs. Replay Gain information requires proper storage space for its records within a metadata stream. Requests regarding bitstreams which do not provide such should be ignored.

Replay Gain specification

Reply #34 –
Quote from: krabapple on
Forget HDCD, I just wish I could apply RG to .dts and .ac3 (or .dtswav/.ac3wav) bitstreams.  I can't see clearly how this would be done, though.  If transmission isn't bit-perfect, such files only yield white noise from my AVR.

How about tweaking the dialnorm tag? Most AVRs at least nowadays allow for dialnorm.

Replay Gain specification

Reply #35 –
Quote from: googlebot on
Replay Gain is not the missing link for highly individual, particular problems. It has a well defined purpose. Its place within the playback chain is after decoding. HDCD decoding should happen before Replay Gain application, the same is true for dts and ac3 and all other codecs. Replay Gain information requires proper storage space for its records within a metadata stream. Requests regarding bitstreams which do not provide such should be ignored.


Peforming Replaygain actions after decoding anything in the bitstream makes sense.  Isn't the problem a few posts above a result of performing Replaygain before decoding something in the bitstream (in the case above, HDCD)?  If not accurate, when does Foobar perform Replaygain decoding today with respect to ac3, dts, and HDCD?

However player currently process Replaygain, does it make sense for the revised Replaygain spec to address the consideration of when Replaygain is applied, either by stipulating a requirement, making an explicit assumption, or providing for implementation before or after decoding the bitstream?  I fear confusion and suboptimal use of Replaygain if these issues are not dealt with in smoe way in the spec.

Replay Gain specification

Reply #36 –
I do not agree. It's trivial to understand that Replay Gain modifies gain. And it is trivial to understand, that any codec which requires unmodified data (as HDCD) must be applied before Replay Gain modification.

It's impossible to apply Replay gain to a AC3 or DTS bitstream without decoding, so it is not necessary to specify that, either. At least DTS has its own loudness control variant, too. That should be preferred instead of hacking Replay Gain into it.

Replay Gain specification

Reply #37 –
Quote from: googlebot on
I do not agree. It's trivial to understand that Replay Gain modifies gain. And it is trivial to understand, that any codec which requires unmodified data (as HDCD) must be applied before Replay Gain modification.

It's impossible to apply Replay gain to a AC3 or DTS bitstream without decoding, so it is not necessary to specify that, either.



I think the difference between "easy to understand once explained" and "intuitive such that no mention is warranted" has led to the current confusion.  I think there is a connection between the lack of any mention of such considerations in the current spec, and implementations that have apprently led to applying Replaygain before decoding at least HDCD.  I have a great deal of respect for the developers of Foobar, and they obviously had many, many things to think about during development, so I can see how no mention of this contributed to the current situation.

Some may argue that given that Replaygain can only be used after decoding with certain codecs (for example but not limited to ac3, dts), but can be implemented even if certain other codecs have not been applied (for example but not limited to HDCD), that the situation is not intuitive or even trivial.

If there is so strong a feeling that Foobar is currently processing Replaygain incorrectly (prior to decoding everything in the bitstream), then perhaps some energy should be expended to correct that if only one way of Replaygain implementation will be tolerated.

Replay Gain specification

Reply #38 –
Quote from: audyoknut on
If there is so strong a feeling that Foobar is currently processing Replaygain incorrectly (prior to decoding everything in the bitstream), then perhaps some energy should be expended to correct that if only one way of Replaygain implementation will be tolerated.


Foobar is not doing anything "incorrectly". HDCD is to blame and the issue is exclusive to it. It doesn't fit into a clean architecture where decoding is done by decoders and DSP is done by DSP components. The HDCD component (by a 3rd party developer) is wrapped into a DSP component although it is a decoder. Blame a broken format. The Foobar devs haven't done anything wrong. If the HDCD component wants to support HDCD and Replay Gain support, nothing prevents the component developer from adding Replay Gain support to his component (users would have to disable the integrated solution).

HDCD is a feature without audible benefit and being fed with unmodified samples is its exclusive requirement. IMHO there are no other cases. AC3 and DTS is unrelated.

Replay Gain specification

Reply #39 –
Quote from: audyoknut on
If there is so strong a feeling that Foobar is currently processing Replaygain incorrectly (prior to decoding everything in the bitstream), then perhaps some energy should be expended to correct that if only one way of Replaygain implementation will be tolerated.

I'm getting the feeling that neither you, nor the prior poster understand the evolution of ReplayGain, let alone what ReplayGain is.  ReplayGain began as nothing more than an implementation of a proposed standard.  There is no official body granting or denying its usage based on some idea of compliance or anything else for that matter.  ReplayGain began before HDCD became as commonplace as it is today, which is still not very common (which is still a huge overstatement of its ubiquity).

This is not to say that it is impossible for RG to be applied post-processing, just that there is no need to start including exceptions about current and future unforeseen applications; especially considering that this won't change the way RG is calculated.

Oh, besides the other cases that I listed, I just thought of another one: de-emphasis.  Does this mean that RG needs a specific exception for this too?  Of course not.  De-emphasize -> re-encode (lossless/lossy) -> calculate RG.  It's just common sense.

Replay Gain specification

Reply #40 –
Quote from: googlebot on
HDCD is a feature without audible benefit...



That's a TOS #8 violation, unless you can provide a valid test to refute the first case evaluated here: http://www.hydrogenaudio.org/forums/index....showtopic=85019  I concluded this was a TOS violation becuase TOS #8 seems to require objective support for any statement concerning subjective sound quality, not just assertions of audible differences.  If my interpretation is in error and claims of no audible differences are allowed, then I guess this is not a TOS violation.

Replaygain exists in a world with many other pre-exisitng aspects, not in a world by itself.  I think any spec that ignores the world around it does so at the risk of limited usefulness.  Thinking about exceptions, or use cases, or implementation guidance seems fully appropriate for any spec.  I am not comforted that "blame" can be cast elsewhere.  At a minimum, as many of us learned in engineering school, stating all assumptions as explicitly as possible is just part of rigorous technical work.  If the goal is to exclude all such considerations, at least make explicit assumptions to that effect, without casting any blame.

Replay Gain specification

Reply #41 –
Yes your interpretation is incorrect; googlebot's claim is not a TOS8 violation.  Feel free to prove him wrong with level-matched and time-synched samples and an ABX log demonstrating a statistically significant result, however.  Since you took the liberty to link the discussion I started, please follow the spirit of the discussion and not waste our time comparing a sample of HDCD not decoded with one that is.

BTW, who told you to calculate RG and write tags to HDCD that has not yet been decoded???  Don't blame the spec because people haven't exercised proper common sense regarding its application!

Replay Gain specification

Reply #42 –
Quote from: googlebot on
The HDCD component is wrapped into a DSP component although it is a decoder.

This is not true (anymore) since foobar2000 1.1 and foo_hdcd 1.5
In theory, there is no difference between theory and practice. In practice there is.

Replay Gain specification

Reply #43 –
Quote from: googlebot on
It's impossible to apply Replay gain to a AC3 or DTS bitstream without decoding,

I'm not certain about this, but I can imagine that decoding is done using floating point numbers allowing values above FS, and the final step of the decoder is casting these FP numbers into 16 bit integers, possibly causing clipping.

If the final cast of the FP number into an integer is integrated with applying RG clipping could possibly avoided.

Replay Gain specification

Reply #44 –
That whole thought is so flawed, I don't even know where to start.

The easiest would be to bin this for continued off-topicness. Or we split from post 29 up to this one. I'm going to answer then.

Replay Gain specification

Reply #45 –
My biggest problem with RG always was, that in the end ALL of my albums will have the same RMS level. This is great for "old-quiet vs new-loud" correction, but a disaster in the sense that ambient and classical will sound as loud as heavy metal...
(Not to mention that a lot of ambient drone tracks will have peaks above 0, unless you tell the unit to take that in to account.)
Some music is simply intended to be quieter than others. I still have to touch the volume slider to adjust for these differences, so it almost defeats the whole purpose of RG in this sense.

Isn't there a chance that RG can store information about the style of the music, and have an option to further lower the level like e.g. of pop/rock/electro by 3-6dB and classical/jazz/ambient by 6-12dB or something similar?

Replay Gain specification

Reply #46 –
Quote from: googlebot on
That whole thought is so flawed, I don't even know where to start.

Why?

At least liba52 (http://liba52.sourceforge.net/) provides a way to supply a gain to the decoder. I've just moved applying RG to AC3 streams to the decoder, and it works great. Moreover, I think it's the best place where to do it, if possible.

Quote from: googlebot on
The easiest would be to bin this for continued off-topicness. Or we split from post 29 up to this one. I'm going to answer then.

The OT discussion was not started by me.

Replay Gain specification

Reply #47 –
Quote from: pbelkner on
At least liba52 (http://liba52.sourceforge.net/) provides a way to supply a gain to the decoder. I've just moved applying RG to AC3 streams to the decoder, and it works great. Moreover, I think it's the best place where to do it, if possible.


The point is, it wasn't claimed that RG cannot be applied by a decoder. AC3 and DTS bitstreams just don't have a RG metadata field. So you either have to use their private methods for loudness correction instead of RG or apply gain before encoding, which implies prior decoding for an already existing DTS or AC3 stream.

Replay Gain specification

Reply #48 –
Quote from: googlebot on
That whole thought is so flawed, I don't even know where to start.

The easiest would be to bin this for continued off-topicness. Or we split from post 29 up to this one. I'm going to answer then.

It would be helpful to me if off-topic contributers started their own threads every once in a while. Failing that, I will start the new ones.

Replay Gain specification

Reply #49 –
Quote from: pbelkner on
Will the final standard define the "representative average" more detailed then just giving a figure?

Will the resulting coefficients of the yulewalk and the Butterworth filters (cf. http://replaygain.hydrogenaudio.org/equal_loud_coef.txt) be part of the standard?

When is an alternate scanner implementation (as e.g. wavegain using two IIR filters with different coefficients, possibly with the same or similar response as the MATLAB yulkewalk and Butterworth filters) called compliant with the standard?

What I have posted so far is a copy of the original RG proposal. Much of the discussion and background is interesting and potentially useful but is not a normative part of the standard. The normative piece for the filter is currently found in the MATLAB files available at the bottom of this page. I still need to convert that from MATLAB to a normative description.

An alternative filter design with same response would potentially be compliant. An alternate filter design with similar response would not be compliant.

Going forward, I would like to discuss incorporation of loudness standards such as ITU-R BS.1770 into an updated version of RG. This is a loudness measurement system that gives results very similar to RG, is slightly less computationally intensive and is starting to be used extensively in broadcast applications. The recently signed CALM act mandates ITU-R BS.1770 for loudness measurement.