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: replaygain and R 128 (Read 8026 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

replaygain and R 128

a. besides some reference level differences (was it 5 dB?) is there a huge practical difference between this two (when talking about file-scanners), do the results differ wildly or is there a good approximation? (on a set of samples)

b. was "gating" ever implemented in replaygain implementations (i don't think there is an option in wavegain?), i do seem to remember it was defined in the standard itself.
PANIC: CPU 1: Cache Error (unrecoverable - dcache data) Eframe = 0x90000000208cf3b8
NOTICE - cpu 0 didn't dump TLB, may be hung

replaygain and R 128

Reply #1 –
Quote from: smok3 on
a. besides some reference level differences (was it 5 dB?)

The reference level doesn't have any meaning in itself. Instead you should adjust your player's pre-amp to the maximum level where clipping is avoided. Please note that in practice such a level may be negative (if measured in dB).

This implies to prefer a scanner providing true peak determination and a player informing you about the peak at playback time (i.e. including pre-amp).

Quote from: smok3 on
is there a huge practical difference between this two (when talking about file-scanners), do the results differ wildly or is there a good approximation? (on a set of samples)

Probably it's highly subjective. In order to get an idea you shuold have two copies of your audio collection, one tagged with respect to RG and the other one tagged with respect to R128. Then you should listen (random shuffeling) for some time (hours, days, weeks)  to the RG version and then for some time to the R128 version (or the other way round). Finally you should decide yourself which of the two algorithms comes closer to what you think is equal loudness.

Quote from: smok3 on
b. was "gating" ever implemented in replaygain implementations (i don't think there is an option in wavegain?), i do seem to remember it was defined in the standard itself.

To me it seems that the two algorithms are based on completely different ideas.

replaygain and R 128

Reply #2 –
Quote from: pbelkner on
Finally you should decide yourself which of the two algorithms comes closer to what you think is equal loudness.


well, /me would have different head, position of ears, age, ect than /somebody else, i thought it was about averaging lots of people opinions?

(p.s. thats a question from a broadcasters point of view, I don't care about my personal "music collection" this days anymore...)
PANIC: CPU 1: Cache Error (unrecoverable - dcache data) Eframe = 0x90000000208cf3b8
NOTICE - cpu 0 didn't dump TLB, may be hung

replaygain and R 128

Reply #3 –
Quote from: smok3 on
well, /me would have different head, position of ears, age, ect than /somebody else,

I've made the decision myself based on the test described above. Posting the arguments would most likely violate TOS #8. This forum is definitely not the place for such a discussion.

Quote from: smok3 on
i thought it was about averaging lots of people opinions?

I'm aware of such tests at least with respect to R128, cf. e.g. http://tech.ebu.ch/loudness. I'm definitely not aware of tests comparing the two methods.

Quote from: smok3 on
(p.s. thats a question from a broadcasters point of view, I don't care about my personal "music collection" this days anymore...)

EBU R128 (http://tech.ebu.ch/loudness) is a standard for broadcasters.

replaygain and R 128

Reply #4 –
ok, thanks, i found a usefull thread meantime http://www.hydrogenaudio.org/forums/index....showtopic=86424

edit:
Quote
Posting the arguments would most likely violate TOS #8. This forum is definitely not the place for such a discussion.

cough, the question was about the numbers, i certainly don't care about /your /his /hers /mine subjective opinions (was I unclear?)
PANIC: CPU 1: Cache Error (unrecoverable - dcache data) Eframe = 0x90000000208cf3b8
NOTICE - cpu 0 didn't dump TLB, may be hung

replaygain and R 128

Reply #5 –
Quote from: smok3 on
cough, the question was about the numbers, i certainly don't care about /your /his /hers /mine subjective opinions (was I unclear?)

If you find some tests (including method description, figures etc.) comparing the two methods with respect on how people subjectively feel equal loudness is approached, please let me know.

replaygain and R 128

Reply #6 –
the record delta between the two (from that thread) seems to be more than 20dB, for me that's enough to conclude that the results from two algorithms can and will vary wildly in certain cases (unless there is a bug somewhere), but still, that might not be enough to rewrite an 8 year old script, due to subjective laziness.

from http://tech.ebu.ch/loudness
Quote
Basically EBU R128 recommends to normalize audio at -23 LUFS +/- 1 LU, measured with a relative gate at -8 LU.

shouldn't that be -10 LU? (some reading ahead...)
PANIC: CPU 1: Cache Error (unrecoverable - dcache data) Eframe = 0x90000000208cf3b8
NOTICE - cpu 0 didn't dump TLB, may be hung

replaygain and R 128

Reply #7 –
Quote from: smok3 on
Quote from: pbelkner on
Finally you should decide yourself which of the two algorithms comes closer to what you think is equal loudness.


well, /me would have different head, position of ears, age, ect than /somebody else, i thought it was about averaging lots of people opinions?

(p.s. thats a question from a broadcasters point of view, I don't care about my personal "music collection" this days anymore...)

Apart from subjective preferences, both algorythmns handle dynamically compressed material quite different. From my experience R128 tends to rate compressed music as louder than ReplayGain (I think mainly due to the use of gating, the R128 algorithm is much more sophisticated than RG). With RG I always had the impression that loud pop/rock music still was too loud compared to more dynamic material. With R128 the loudness seems to be much more even between such tracks, so it's quite an improvement to me.

Quote from: smok3 on
from http://tech.ebu.ch/loudness
Quote
Basically EBU R128 recommends to normalize audio at -23 LUFS +/- 1 LU, measured with a relative gate at -8 LU.

shouldn't that be -10 LU? (some reading ahead...)

The R128 specifications where updated recently (rev. 2) and relative gate was decreased from -8 LU to -10 LU. This is implemented in the most recent libebur128 version.

replaygain and R 128

Reply #8 –
Quote from: smok3 on
the record delta between the two (from that thread) seems to be more than 20dB, for me that's enough to conclude that the results from two algorithms can and will vary wildly in certain cases (unless there is a bug somewhere)

You've found out the most important point (at least as it appears to me). That's the key to understand why the two algorithms give completely different impressions in practice (you have to find out yourself which you prefer as described above).

Quote from: smok3 on
from http://tech.ebu.ch/loudness
Quote
Basically EBU R128 recommends to normalize audio at -23 LUFS +/- 1 LU, measured with a relative gate at -8 LU.

shouldn't that be -10 LU? (some reading ahead...)

They have to update their HTML.

replaygain and R 128

Reply #9 –
Quote from: Northpack on
With RG I always had the impression that loud pop/rock music still was too loud compared to more dynamic material. With R128 the loudness seems to be much more even between such tracks, so it's quite an improvement to me.

Even if I've learned to avoid subjective claims in this forum, I completely agree.

Quote from: Northpack on
The R128 specifications where updated recently (rev. 2) and relative gate was decreased from -8 LU to -10 LU. This is implemented in the most recent libebur128 version.

R128GAIN (http://r128gain.sourceforge.net/) too 

replaygain and R 128

Reply #10 –
Quote from: pbelkner on
Even if I've learned to avoid subjective claims in this forum, I completely agree.

I think this impression could be objectified though: Take a set of samples, containing a wide range of both compressed and dynamic material. Now randomly select two samples and scan them with both R128 and ReplayGain. Take the delta of R128 and RG values from the first sample and add it to the RG value of the second one. Now ABX between the R128 and normalized RG version of the second sample and compare its loudness to the first one, judging by a scale. If you have enough samples and participants you can tell which algorithm is better.

Quote
R128GAIN (http://r128gain.sourceforge.net/) too 

Sorry, wasn't my intention to elide R128GAIN  I think it's a fantastic tool for comparing both algorithmns. However, for scanning my library I prefer libebu128 for performance reasons.

replaygain and R 128

Reply #11 –
Quote from: Northpack on
However, for scanning my library I prefer libebu128 for performance reasons.

As far as I know libebu128 avoids true peak determination (i.e. up-sampling) in violating EBU R128.

Have you tried R128GAIN's fast mode (i.e. avoiding up-sampling and breaking EBU R128)?

replaygain and R 128

Reply #12 –
and foobar (v1.1.7 beta 4 with libeur128) is adding 5 dB on top (by default)?
p.s. some weird foobar downmixing to stereo behaviour with 5 and 6 channel wav files from ebu-loudness-test-setv01.zip (6 channels will get downmixed with "correct" loudness perception, while 5 channel will fail) btw, clues?
nevermind, this must be 5.1 dsp plugin limit.
PANIC: CPU 1: Cache Error (unrecoverable - dcache data) Eframe = 0x90000000208cf3b8
NOTICE - cpu 0 didn't dump TLB, may be hung

replaygain and R 128

Reply #14 –
ok, one more silly question: the truepeak thingy, can/should that be used as a security measure if the calculus is done before lossy coding, or do i need more headroom than that?
PANIC: CPU 1: Cache Error (unrecoverable - dcache data) Eframe = 0x90000000208cf3b8
NOTICE - cpu 0 didn't dump TLB, may be hung

replaygain and R 128

Reply #15 –
Quote from: smok3 on
ok, one more silly question: the truepeak thingy, can/should that be used as a security measure if the calculus is done before lossy coding, or do i need more headroom than that?

The idea is the following:
  • Each decent DAC (sound card) does up-sampling (at playback time) as a step in the course of re-constructing the original analouge signal. It helps smoothing the sampled/staircased digital signal.
  • Up-sampling in general re-discovers inter-sample peaks larger than digital full scale (FS). If the digital signal is not attenuated arccordingly beforehand it may clip.
  • According to EBU R128 true peak determination does the following:
    • Attenuate the signal by about four times (in order to avoid clipping due to up-sampling).
    • Up-sample by four times.
    • Determine the maximum peak.
    • Multiply the maximum peak by four.

This way true peak determination may give you values greater then 0 dBFS. I've found examples with true peak larger than 2.0 dBFS, i.e. it is wise to attenuate such sounds at playback time by at least the true peak in dBFS in order to avoid clipping.

Ordinary peak determination can't give you values larger than 0 dBFS as they may happen at playback time. You trade this information by patience (i.e. waiting for a longer time until the tool has finished its job.)

replaygain and R 128

Reply #16 –
Quote
Attenuate the signal by about four times (in order to avoid clipping due to up-sampling).


Yes, but:
Quote
The purpose of this step is to provide for headroom for the subsequent signal processing employing integer arithmetic. This
step is not necessary if the calculations are performed in floating point.
 

replaygain and R 128

Reply #17 –
Quote from: lvqcl on
Yes, but:
Quote
The purpose of this step is to provide for headroom for the subsequent signal processing employing integer arithmetic. This
step is not necessary if the calculations are performed in floating point.


I agree.

Because R128GAIN's processing is based on SoX's 32 bit integer bus it's needed there.

replaygain and R 128

Reply #18 –
Quote from: smok3 on
ok, thanks, i found a usefull thread meantime http://www.hydrogenaudio.org/forums/index....showtopic=86424

I believe there was an earlier thread where we agreed on a very simple R128<->ReplayGain conversion formula. I haven't found that yet. The thread you found is discussing exceptions to that formula.

Quote from: smok3 on
b. was "gating" ever implemented in replaygain implementations (i don't think there is an option in wavegain?), i do seem to remember it was defined in the standard itself.

ReplayGain uses statistical processing which performs a similar function as gating - ignores low level portions of the program. Details on statistical processing are available here.