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 55707 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Replay Gain specification

Reply #50
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

Thank you very much for bringing this to my attention. I have bookmarked it and will refer to it as I move forward.

Replay Gain specification

Reply #51
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?

Many media players give you the ability to adjust level on a per-track basis. I believe this adjustment is above and beyond what loudness normalization like RG does for you. You should be able select files by genre and tweak the level manually en-mass as you've specified. I don't think we want to make RG smart enough to do this for listeners. In this department, what works for you will not necessarily work for others.

Replay Gain specification

Reply #52
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.



Bear with my ignorance a moment please and tell me if I'm right or wrong --

My ac3 and dts files are all in WAV wrappers now (i.e., dtswav, ac3wav).  That made it possible to convert them to FLAC, which I have also done.  These FLAC files are actually the ones I stream via toslink from my laptop (foobar2k with foo_spdif and WASAPI output) to my AVR, which decodes them into surround sound.  This particular combination of file format and software settings makes it possible to have F2K playlists containing both 2channel and 5.1 channel tracks, all with proper tagging and album art....a wonderful thing. 

I certainly can add replaygain meta info to my flac'ed dts and ac3 files -- thanks to the RG metadata field.  But they don't play if I do that, I'm guessing because foobar is trying to change the gain of an undecoded bitstream.  If I understand correctly, the solution would be for F2K to leave them alone, and have something in the *AVR* that recognizes the RG field of the incoming steam, and adjusts decoded output accordingly.

[EDIT: ooops, if this belongs in the new thread, I'd be grateful if the mods moved it]

Replay Gain specification

Reply #53
Seems you are trying to solve a problem without understanding why it fails.


spdif is just a stream of data. This data can be raw, or can be a codec.

Now, if the file is stored not only inside a .wav file, but in fact, a lossless codec, why would the program know that it has an encoded file?

The problem is not about Replaygain, think about it: Any DSP would fail (equalizer, reverb, stereo expander, resampler...). The only way for this to not cause a problem is for the program to know in some way that it is streaming a signal, and not playing audio.

Replay Gain specification

Reply #54
[JAZ] is right. Foobar doesn't care, what's inside a sample and will just send it to the audio output. This works so good that you can put totally different formats as AC3 and DTS into PCM samples, and they get passed along just fine. As it is the case the case for analog audio, metadata is not part of the output stream, just because you choose to output over S/PDIF. Foobar would have to modify the DTS or AC3 stream directly to encode that kind of information. Either by reencoding the content or by tapping into those formats' respective methods for loudness control, which is IMHO preferable.

Replay Gain specification

Reply #55
As it is the case the case for analog audio, metadata is not part of the output stream, just because you choose to output over S/PDIF.

This was precisely what I was getting at in my earlier discussion with twittles.

Replay Gain specification

Reply #56
As it is the case the case for analog audio, metadata is not part of the output stream, just because you choose to output over S/PDIF.

This was precisely what I was getting at in my earlier discussion with twittles.


By george I think I've got it now.  Thanks guys.

(Btw, I never thought the problem was about Replaygain.)

Replay Gain specification

Reply #57
A couple ideas, please comment if they sound worthwhile:
  • Blacknoise's comment reminds me that the RG spec should probably cover the subject explicitly in its rationale. That is, ReplayGain presumes the existence of a program level (and such a presumption is justified for the vast majority of listening situations). Furthermore, if a manual volume change is necessary for a given piece of music, ReplayGain is extremely likely to reduce the number of volume changes necessary during the course of a listening session.
  • ReplayGain ought to be compared with SoundCheck and BS.1770 (now that those standards exist)

Replay Gain specification

Reply #58
I will add a brief discussion of reference program level to the specification.

It is reported that this paper compares RG to BS.1770. BS.1770 apparently is slightly more accurate. Apple does not publish technical information about Sound Check but reports I've heard indicate that it is less accurate that RG or BS.1770.

I have done some more updates to the specification tonight. The loudness measurement filter is now specified in terms of topology and filter coefficients. I use the same presentation approach used in the BS.1770 standards document.

Replay Gain specification

Reply #59
It is reported that this paper compares RG to BS.1770.

Not to forget the Master's thesis I linked to, which comes to the same conclusion.

Quote
ReplayGain ought to be compared with SoundCheck and BS.1770 (now that those standards exist)

I'd rather compare RG to the state of the art, meaning the "integrated" EBU mode meter according to R 128, which is BS.1770 with a loudness gate. See my post in the thread Notat mentioned. My own experiments with high-dynamic-range songs like Phil Collins' "In The Air Tonight" seem to confirm the necessity of gating (otherwise the loud passage of the song ends up too loud).

Chris


Edit: fixed some typos
If I don't reply to your reply, it means I agree with you.

Replay Gain specification

Reply #60
It is reported that this paper compares RG to BS.1770.

Not to forget the Master's thesis I linked to, which comes to the same conclusion.

Just finished reading the Dolby paper. It does not actually contain a direct performance comparison of RG and BS.1770.

Next up on my reading list is the Swedish Radio thesis.

Thanks again for bringing this all to my attention.

Replay Gain specification

Reply #61
OT: "Swedish Radio Thesis" is a fine band name.

Replay Gain specification

Reply #62
Quote
ReplayGain ought to be compared with SoundCheck and BS.1770 (now that those standards exist)

I'd rather compare RG to the state of the art, meaning the "integrated" EBU mode meter according to R 128, which is BS.1770 with a loudness gate. See my post in the thread Notat mentioned. My own experiments with high-dynamic-range songs like Phil Collins' "In The Air Tonight" seem to confirm the necessity of gating (otherwise the loud passage of the song ends up too loud).

Many thanks for pointing me to that.

As far as I understand matters, BS.1770 is a loudness measuring method. A standard comparable to RG and residing on top of BS 1770 is EBU R128 (cf. http://tech.ebu.ch/loudness).

I've just started a corresponding topic.

Replay Gain specification

Reply #63
As far as I understand matters, BS.1770 is a loudness measuring method. A standard comparable to RG and residing on top of BS 1770 is EBU R128 (cf. http://tech.ebu.ch/loudness).



that link is broken for me.

but I found this direct link to the pdf of EBU R128 "Loudness normalisation and permitted maximum level of audio signals"

Replay Gain specification

Reply #64
As far as I understand matters, BS.1770 is a loudness measuring method. A standard comparable to RG and residing on top of BS 1770 is EBU R128 (cf. http://tech.ebu.ch/loudness).



that link is broken for me.

Sorry for including the right parentheses into the link. The correct link is
[blockquote]http://tech.ebu.ch/loudness[/blockquote]

Replay Gain specification

Reply #65
As far as I understand matters, BS.1770 is a loudness measuring method. A standard comparable to RG and residing on top of BS 1770 is EBU R128 (cf. http://tech.ebu.ch/loudness).



that link is broken for me.

Sorry for including the right parentheses into the link. The correct link is
[blockquote]http://tech.ebu.ch/loudness[/blockquote]



Thanks.

Replay Gain specification

Reply #66
There is a major change to make though: what's stored is the 83dB referenced result, plus an arbitrary 6dB. That's a defacto change from the original proposal.

I believe the +6 dB is correctly called out in section 3.2 (Pre-amp). The text on replaygain.hydrogenaudio.com says 6 to 12 dB. I removed the 12 dB option in my early edits because I knew 6 dB was current practice.

Notat, I don't think this is right.

The original RG spec was calibrated to -20 dB, and RG analyzers were supposed to store the corresponding level change. However, it quickly became common among RG analyzers to add an extra +6 dB before storing the level change. Effectively, these analyzers are storing the required level change for -14 dB, not -20 dB. The analyzers I have studied (mp3gain, lame, vorbisgain) all use this modified level.

This is quite different from pre-amp. Pre-amp is an optional correction which is supposed to be applied by the decoder, not the RG analyzer.

The addition of +6 dB, as implemented by RG analyzers, was accepted as the new standard by David ([a href='index.php?act=findpost&pid=154605']here[/a]). I believe that is what he refers to above. Unfortunately that change was never added to the replaygain website. Can somebody confirm that current implementations indeed use -14 dB instead of -20 dB?

The updated RG spec still talks about -20 dB, same as the original spec. This should be changed to -14 dB, according to the modified standard.

Sorry for jumping on this so late. I was just reading through the current version of Notat's updated spec when I noticed this.

Replay Gain specification

Reply #67
^^^^ this is correct.

Replay Gain specification

Reply #68
The "Replay Gain Specification" wiki should be first and foremost an implementation guide. The "fluffy bits" can go. There will still be the ReplayGain HA wiki, which is already doing a very good job explaining it.

I am working my way through the document from top to bottom. I have thus far removed "fluffy bits" from beginning through section 1.3. Section 1.4 is next and in addition to removing fluffy bits, I will update the reference level as discussed in this thread and other references.

Replay Gain specification

Reply #69
I've taken the first step towards fulfilling my threat to produce an up-to-date edition of the Replay Gain specification.

The working draft is published on the Hydrogen Audio Wiki.


I may be totally clueless, but the writeup seems to be very specific to ID3 and MP3, especially the part about bit format. I'm using FooBar2000 to RG tag my FLAC files, which I listen on a SqueezeBox. I don't have and care for MP3 files. As far as I am aware, I'm using ReplayGain, but the VorbisComment are quite different from what you list on your page.

It seems that I have 4 values (and not 3), and seems all textual :
replaygain_album_gain -1.99 dB
replaygain_album_peak 1.000000
replaygain_track_gain -2.60 dB
replaygain_track_peak 1.000000

Good luck...

Jean


Replay Gain specification

Reply #70
This is work in progress. Vorbis comment documentation is not in there yet but it is coming.

I have just finished updated description of reference level and gain calculation. I've expressed things in terms of headroom which is how professional audio engineers, R128 and BS.1770 tend to look at things. The SPL reference levels are retained and explained as well.

Replay Gain specification

Reply #71
The addition of +6 dB, as implemented by RG analyzers, was accepted as the new standard by David ([a href='index.php?act=findpost&pid=154605']here[/a]).

I used [a href='index.php?act=findpost&pid=475019']a later statement by David[/a] to justify an explanation in the RG informational article in the HA wiki that the spec calls for a reference level "of 83dB (with the expectation that players would add 6dB at playback time). However, the de facto standard has been for the reference level to simply be 89dB and for players not to add anything extra."

So if we're going to replace -20 dB SPL with -14 dB SPL in the spec, then shouldn't we also change the default pre-amp from +6 dB to zero? Or am I not understanding some nuance here?

Also, the new draft was using "ReplayGain" and "Replay Gain" inconsistently. I changed it all back to "Replay Gain" for now until we were sure it should be changed. "ReplayGain" seems to be how many people talk about the spec and the technology in general ("instead of normalizing your audio data, just add ReplayGain tags and configure your ReplayGain-aware media player according to your listening preferences"). I personally feel comfortable with using it as a compound term like that, and I think the spec should acknowledge it as a permissible spelling.

But in its prose, the spec talks of "the appropriate replay gain", "the Replay Gain adjustment", "the replay level", and so on, where "replay" is very deliberately an adjective, clarifying which gain/level/adjustment, out of several being discussed. So in that context, it seems more appropriate to keep the words separate. I'm not sure how to reconcile these two ways of talking about RG. Maybe just keep it as-is, and add a footnote to its first use saying that the technology in general is often called either ReplayGain or Replay Gain, but when referring to a specific type of gain in prose, the latter is preferable?

Replay Gain specification

Reply #72
FWIW:
http://www.hydrogenaudio.org/forums/index....st&p=736023

Of course I have already objected (and still object!) to the "because that is what David did" argument regarding "preferred" ID3 tagging, so take the link with a grain of salt.

Replay Gain specification

Reply #73
Seems simple to me. The specific technology/standard has a brand name for which David suggested "ReplayGain" has an edge. In standard prose when you're talking about replay being used as an normal adjective; then its a generic usage of the term rather than a reference to the brand name. It should neither be capitalized nor concatenated in this case as it's just normal English. If the usage is overly confusing in a particular context; then reword (e.g."the gain used during playback" intead of "the replay gain") assuming that is less awkward in a particular situation.

Of course I haven't looked through all of the situations you've reviewed; so maybe it's not so easy in practice...

-Jeff

Replay Gain specification

Reply #74
+replaygain has about twice as many Google results as +"replay gain".