Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[lasker98]

I'm wondering what J River's position is on the new EBU R128 Gain standard as an alternative to replay gain? Are there any plans to implement this as an option? With J River positioned as the premier media player, it would seem a nobrainer for them to be on the leading edge of implementing this.

There was a topic started in MC 17 forum on this but there were no responses: http://yabb.jriver.com/interact/index.php?topic=69618.0

Based on my own limited reading on this, it appears the general consensus is that EBU R128 Gain is superior to replay gain. The latest version of dBpoweramp has the option to calculate gain based on this standard but I'm not clear on using these values. My understanding is that EBU R128 gain calculations would result in a lower overall volume than current replay gain and based on this it's not recommended to mix files with the two different gain calculations. It is possible to adjust the target volume used by R128 Gain in dBpoweramp, which could possibly be used as a way to achieve a closer level match between files with existing replay gain tags and those with R128 gain, but this kind of defeats the purpose of having a "standard".

I look forward to hearing comments or opinions on this.

Bill

[6233638]

As a word of caution, dBpoweramp's implementation of this - at least the last time I checked - works by changing the audio files, and not by tagging them as ReplayGain does.

I haven't done a comparison between the two, but I definitely still find the need to turn some albums up or down a couple of notches when using ReplayGain inside MC18 (all files analyzed inside MC18) so there is definitely room for improvement.

[lasker98]

I only found out about this because I just today upgraded to latest version of dBpoweramp and noticed this new option in replaygain. My understanding is that now these values are written as tags, in place of replaygain. So you have either R128 Gain or replay gain calculated values in the replay gain tags, depending what option you select in dBpoweramp. If the values are added as tags, then no permanent changes are made to the original file. I think the original implementation of R128 Gain in dBpoweramp made permanent changes to the files.

I understand Foobar has the option now as well to use R128 Gain, so it appears J River is already falling behind other products in implementing this.

Bill

[6233638]

You're right, I've just tried dBpoweramp again, and it seems that there's now an option under the ReplayGain DSP for this, and the EBU R128 DSP still writes the changes to the files.

I agree that it would be good to have the option to use EBU R128 inside MC18, and I would also like to have the option of writing the result to the iTunNorm tag as well. (Apple devices don't read ReplayGain tags)

[magnust]

Is dbpoweramp writing the value to the two normal RG tags (track and album gain) or is it writing it to a brand new tag?

[lasker98]

From what I see, after converting the same cd first to replay gain, then to R128, dbpoweramp writes R128 values into the track and album gain tags. As a comparison between the calculated levels here's the values for the first track from the cd (replay gain first, R128 last):

Album Gain: +0.79/-6.6
Track Gain: +4.05/-0.83

[hulkss]

Are you sure those numbers are correct? You're showing a much bigger difference in methods than I would expect to see.
In any case, R128 should be implemented in MC as it is the current standard.

[lasker98]

I reconverted the files again to double check, and yes, those values are correct. That's using -23 for LUFS Target Value, which is the standard as far as I know.

[Mikkel]

Please correct me if I am wrong but doesn't EBU R128 and ReplayGain serve the same function but only with slightly different Measurement techniques and output level?

Not to quarrel but I Wonder if any other than broadcast-members of EBU adhere to the standard. Furthermore, do record producers adhere to the standard? If not the only function of these devices is to ensure equal loudness of output across different media - which replaygain does already?

Anyway, JRiver should use whatever is the standard. And if that is EBU R128 I agree with the rest 


Best regards,
Mikkel

[6233638]

EBU R128 is the result of a lot of research specifically about loudness normalization, and should do a better job of keeping perceived loudness at the same level than ReplayGain does. While ReplayGain helps, I definitely find myself still reaching for the volume control when it is in use, because a track is too loud or too quiet.

[lasker98]

Last weekend I used dBpoweramp batch converter to convert almost 50k .wav files from replaygain to EBU R128 gain. I used the default -23 setting. I did it in 5 batches and it took close to 48 hours.

Playing back in J River is no issue using the newly calculated tags, which makes sense, since the old replay gain tag value is simply replaced with the new value calculated using R128 gain. A lot of my listening is random playlists using volume control/replay gain. I was never satisfied with the results of using replay gain since there was still a fair bit of adjusting volume between individual tracks. After a few days using volume control with newly calculated R128 values, I don't think I've had to adjust volume once for volume differences between tracks. I don't want to imply that every track volume/loudness is identical, but it's sure close enough now that I either don't notice or it's not worth adjusting. I was concerned that there would be a loss of "headroom", if that's the right word, because of the fairly large difference in original replay gain values and the new R128 gain values. I'm not sure if it's a result of J River normalize volume working, or something else I don't understand, but this hasn't been an issue at all. My current volume setting on my pre amp is pretty much identical to where it was using previous replay gain values. All in all, for me, it was well worth doing the conversion.

[Vocalpoint]

(Apple devices don't read ReplayGain tags)

Hmm...I have created every single MP3 for my iPod via MC and every single ReplayGain tag written is perfectly picked up (with Soundcheck enabled) on my 6th gen iPod.

This is the key reason I started using RG. If the iPod didn't pick up the RG tags - I wouldn't even bother using it.

VP

[6233638]

Hmm...I have created every single MP3 for my iPod via MC and every single ReplayGain tag written is perfectly picked up (with Soundcheck enabled) on my 6th gen iPod.

This is the key reason I started using RG. If the iPod didn't pick up the RG tags - I wouldn't even bother using it.

Sound Check is Apple's own volume normalization technique, it is not the same as ReplayGain, and I don't find it to be nearly as effective. You see this when you import files, whether they have ReplayGain tags or not:



dBpoweramp has the option to write ReplayGain data into Sound Check tags though, but there only seems to be an album value, and not a track value. (which might explain the poor results when a device is on shuffle)

R128 seems to be an improvement over standard ReplayGain (or MC's implementation at -20dB) and I would love it if MC also had the option to write it as iTunes Normalization data. On my iOS devices I want per-track gain, not per-album gain. (well I would actually prefer both - track when shuffling, album when playing in order, but I don't think that is an option)

[Vocalpoint]

Sound Check is Apple's own volume normalization technique, it is not the same as ReplayGain, and I don't find it to be nearly as effective.

It's totally effective for me and here's why:

1. iTunes is non-existent here and has been for years.
2. None of my tracks have ever "analyzed" by iTunes (as indicated by your graphic).
3. Every track on my iPod was created by and analyzed by JRiver with complete track based RG written to each
4. If I turn off Soundcheck on my device - the track blasts away at full volume (RG tags ignored)
5. If I turn Soundcheck on (on the device) - the RG data is correctly read and the track plays at a nice comfortable volume - as it should.

Now I can see why - if you are using iTunes - that it would be easy to associate it's lame "analysis" to the "Soundcheck" that appears on the device but I can confirm that Soundcheck on my iPod reads ALL of my JRiver RG data from MP3 files perfectly. This results in playlists with perfect balance and no jarring volume swings whatsoever.

VP

[6233638]

2. None of my tracks have ever "analyzed" by iTunes (as indicated by your graphic).

I've just checked, and it seems that it only does this scan if you have Sound Check enabled in iTunes itself.

4. If I turn off Soundcheck on my device - the track blasts away at full volume (RG tags ignored)

If you turn Sound Check on, it is using Sound Check normalization, not ReplayGain.

5. If I turn Soundcheck on (on the device) - the RG data is correctly read and the track plays at a nice comfortable volume - as it should.

I've just tested this out by setting a track to -90dB ReplayGain, and disabling Sound Check in iTunes. (so it wouldn't scan the file) If I play the track in MC, it plays back at -54dB (I guess that is the lower limit inside MC) and if I enable Sound Check on my iPad it plays at full volume.

It might have analyzed the tracks at some other stage (perhaps even on the device) but it's definitely not reading ReplayGain tags.

[Vocalpoint]

If you turn Sound Check on, it is using Sound Check normalization, not ReplayGain.

This is what I am trying to explain. There is NO possibility of any "Soundcheck Normalization" ever appearing on any of my files - since iTunes does not exist here, has never existed here and none of my tracks have ever been loaded to or touched by it.

Answer found - as per Matt (JR) from 5/31/2009 -

"If MC is used for syncing it includes the Sound Check values automatically if the replay gain values are present in MC's library."

So there's the answer - MC is automatically placing Soundcheck values (Derived from the RG values) to the device during sync. Works for me.

VP

[6233638]

There is NO possibility of any "Soundcheck Normalization" ever appearing on any of my files…

…MC is automatically placing Soundcheck values…

It is using Sound Check then, it's just that MC is converting ReplayGain tags to Sound Check data.

The problem is that I don't use an iPod Classic, and need to sync Apps, Contacts, Documents/Books, Videos etc. to my devices, so I need to use iTunes. It seems that while MC has the ability to write iTunNorm values to the files, it only does this when syncing with an iPod. I need the option to write these tags to the files along with the ReplayGain data when it is created.

And this doesn't change the fact that ReplayGain is now outdated, and superseded by R128. ReplayGain does a decent job of normalization - far better than iTunes calculated Sound Check values - but R128 does a much better job of it.

[Vocalpoint]

And this doesn't change the fact that ReplayGain is now outdated, and superseded by R128. ReplayGain does a decent job of normalization - far better than iTunes calculated Sound Check values - but R128 does a much better job of it.

+1. But until JRiver and the rest of the world decides to acknowledge R128 as "better"...it's all we got

VP

[lasker98]

"But until JRiver and the rest of the world decides to acknowledge R128 as "better"...it's all we got "

It's not "all we got". At this point in time, both foobar and dBpoweramp will calculate and tag files with R128 Gain values. There may well be others, but these are the only two I know of. Any audio playback program that uses replay gain tags can then play back these files using R128 Gain values. It doesn't really matter to me, and shouldn't matter to most users, whether the rest of the world acknowledges R128 as better. As it stands now, for my purpose, and based on my personal experience, it is better. I, and anyone else that wants to, has the capability to use it now. Even if J River can't calculate these values, dBpoweramp offers a fully functional 21 day free trial, which would allow anyone that wishes, to convert their library. This is only one possible option (using foobar would be another).

The intention of my original post was to find out whether J River had any plans on implementing support for R128 Gain. At that stage, I didn't realize that the R128 Gain values calculated by dBpoweramp and other programs were simply written into the existing replay gain tags, which means than in effect J River does "support" R128 Gain playback. It would be nice if they could also provide the ability to calculate R128 Gain within J River, but as I do all my ripping with dBpoweramp anyways, it's a non-issue for me personally.

[Vocalpoint]

It's not "all we got". At this point in time, both foobar and dBpoweramp will calculate and tag files with R128 Gain values. There may well be others, but these are the only two I know of. Any audio playback program that uses replay gain tags can then play back these files using R128 Gain values.

Are you saying the JRiver will "pick up" a R128 tag as if it was a ReplayGain tag? If so - where's the advantage? If dbPowerAmp is just placing some different value in the RG tag - and JRiver is treating it just like a ReplayGain number - then it's just a RG number...so we essentially back to "it's all we got".

It would be nice if they could also provide the ability to calculate R128 Gain within J River, but as I do all my ripping with dBpoweramp anyways, it's a non-issue for me personally.

Well - while I have dbPowerAmp and use it for a lot of things - I let MC handle all the RG stuff. And yes - I would like to see MC be fully EBU R128 compliant - including full analysis and tag support. However - I do not  believe there is actual defined "tag" support within the R128 spec that can be written to an audio file - I find that simply jamming the existing RG tag with R128 calculations is bit of a copout.

Would also be great to see full, across the board support for R128 regulated playback (and loudness level metering) using the LUFS scales and so forth. Basically - offering "loudness corrected" playback without having to rely on any tags at all.

VP

[lasker98]

Are you saying the JRiver will "pick up" a R128 tag as if it was a ReplayGain tag? If so - where's the advantage? If dbPowerAmp is just placing some different value in the RG tag - and JRiver is treating it just like a ReplayGain number - then it's just a RG number...so we essentially back to "it's all we got".

Based on my experience, as posted above, after converting almost 50k files to R128 Gain, yes, "JRiver will "pick up" a R128 tag as if it was a ReplayGain tag. That quote may be slightly misleading, since there is no actual R128 tag. What happens in the case of dBpoweramp, which is all I've used, is that at the time of ripping or converting, in the options for ReplayGain DSP, you have the choice of selecting either replay gain or R128 Gain. Depending on what's been selected, the values from that calulation are written in the standard replay gain tags. Once those values are written to replay gain tags, then any program that can playback audio files using data in standard replay gain tags, will playback the files based on the data in those tags. Just as we can currently go in and manually edit any existing replay gain tag data and have the file played back based on the new data we entered, whatever data entered as a result of the R128 Gain calculation is also used.

As far as advantage, the advantage in my opinion is that instead of your audio files being volume leveled/normalized with the "inferior" replay gain based method, they're now being volume leveled/normalized using the "superior" R128 Gain method. If you're happy with the current implementation of replay gain, then there would be no advantage, and you can continue using replay gain as before.

I find that simply jamming the existing RG tag with R128 calculations is bit of a copout

I don't think of it as a cop out. "Jamming" the existing replay gain tag with R128 calculations seems much more preferable then writing a new tag for R128 Gain. Think of the logistics of getting that implemented in all the different audio playback programs? At least this way, any program with the capability of reading standard replay gain tags now has the ability to playback files based on R128 Gain.

[Vocalpoint]

As far as advantage, the advantage in my opinion is that instead of your audio files being volume leveled/normalized with the "inferior" replay gain based method, they're now being volume leveled/normalized using the "superior" R128 Gain method. If you're happy with the current implementation of replay gain, then there would be no advantage, and you can continue using replay gain as before.

Well - based on my understanding of R128 - there is a whole lot more to this than just writing some "new" tag in the file. And if existing RG tech in JRiver or Foobar or whatever is simply taking this new so-called "R128" value and simply treating it as a RG value - that has no real bearing on anything.

Since the end result is still just some number (whether the RG calculated value or whatever it is that dbPowerAmp thinks it's calculating) at the end of the day - it's a number and all the players (MC) are still using their same old internal ReplayGain code to read it. Without being able to quantify what that new R128 value actually means within the R128 spec and have real R128 related software to correctly interpret that value - what's the point? I could type my own number in there and call it good...

I don't think of it as a cop out. "Jamming" the existing replay gain tag with R128 calculations seems much more preferable then writing a new tag for R128 Gain. Think of the logistics of getting that implemented in all the different audio playback programs? At least this way, any program with the capability of reading standard replay gain tags now has the ability to playback files based on R128 Gain.

R128 is already well established in other parts of the world and actual professional use of it for preparation for broadcast audio (like in the upcoming Wavelab 8 for example) involves software that performs an actual destructive edit (re-render) of the audio file itself to have it conform it to a specific LUFS threshold prior to delivery to an outlet - NOT writing some numerical tag into an untouched file and then having some unknown software read that tag when the piece is broadcast on TV...

So - unless some new meaningful R128 tagging standards (and software) are adopted by the "players" at large (and by the EBU themselves) - I do not think anyone will want to destructively edit their actual source material to conform to R128

VP

[lasker98]

At this point, I'd say your nickname is very appropriate. No offense meant at all, just making a joke.

I'm not sure how much I can add to what I've said in my other posts (but that won't stop me from trying).

And if existing RG tech in JRiver or Foobar or whatever is simply taking this new so-called "R128" value and simply treating it as a RG value - that has no real bearing on anything.

The way I see it, the audio playback software is adjusting (non-destructively) the playback level based on whatever values it reads from the replay gain tags. It has nothing to do with the method used to obtain those values. This is where dBpoweramp (or any other software with the capability) comes in. Based on selection made in user options, the values written to the replay gain tags are based on either replay gain methodology or R128 Gain methodology. I can only assume that if dBpoweramp has implemented an option called EBU R128 Gain, then it's been implemented to calculate correctly. To say "whatever it is that dbPowerAmp thinks it's calculating" seems unfair to the developers of dBpoweramp in my opinion.

As far as "it's a number and all the players (MC) are still using their same old internal ReplayGain code to read it", how is this a bad thing? All these players have the current ability to read and playback based on whatever values are found in the replay gain tags. Again, that's all they do. For playback purposes, they have nothing to do with the method behind calculating those values in the tags. If R128 Gain is a "better" method of calculating those values, then that's great. From my personal experience and reading, R128 Gain is a better method for volume leveling/normalizing the audio files in my library.

How does what the "players at large" do have any bearing on what I use in my own library for volume leveling? I don't for a minute think the "players at large" are all using replay gain, yet it's used pretty much universally. If my grandmother came up with a better way to calculate values for my files that can be read and used by my current playback software to normalize volume non-destructively, then I would use it. I don't see how it matters to me who else is using it. If I was distributing these files for world wide use, with the intention that everyone listening to them would be required to listen at the exact same volume level, then it may be relevant. Currently, based on my personal experience with replay gain and R128 gain, R128 gain is far more effective then replay gain as a method of achieving consistent playback volume when listening to a random playlist in J River.

If you have the most recent version of dBpoweramp, you have the ability to try R128 Gain. Until I actually tried it myself, I wasn't sure how, or if, it would work. After trying it, I found it worked very well.

[Vocalpoint]

It's been implemented to calculate correctly. To say "whatever it is that dbPowerAmp thinks it's calculating" seems unfair to the developers of dBpoweramp in my opinion.

Well - until I see that the makers of dbPowerAmp have been totally vetted by the EBU as being fully compliant with the R128 spec - I am not going to assume anything. And without any documentation on what it does (From the dbPowerAmp guys) - all this seems like on the surface is them now calling their "replaygain" function "E128" using another set of math to create a tag.

As far as "it's a number and all the players (MC) are still using their same old internal ReplayGain code to read it", how is this a bad thing? All these players have the current ability to read and playback based on whatever values are found in the replay gain tags.

I am not saying it's a "bad thing" necessarily but that it's just a "thing". If a RG tag has a 7.5 in it from dbPoweramp and a 7.75 in it as done by JRiver - again - who cares? It's not like this value is going to suddenly have a world altering effect on the sound of the file.

I do have dbPowerAmp and will give it a whirl just to see what shakes down - but right now I cannot see any reason to change from JRiver's method of calculating replaygain. Works perfectly me for now.

Cheers,

VP

[kstuart]

"...involves software that performs an actual destructive edit (re-render) of the audio file itself to have it conform it to a specific LUFS threshold prior to delivery to an outlet..."

Might be worthwhile for TV broadcast, but I don't want any software doing that to music files.

[Vocalpoint]

"...involves software that performs an actual destructive edit (re-render) of the audio file itself to have it conform it to a specific LUFS threshold prior to delivery to an outlet..."

Might be worthwhile for TV broadcast, but I don't want any software doing that to music files.

Exactly. Me either

VP

[6233638]

"But until JRiver and the rest of the world decides to acknowledge R128 as "better"...it's all we got "

"The rest of the world" has acknowledged that R128 is better, as it's set to be a broadcast standard around the world, used in both radio and television. One of the goals is to stop that huge audio spike whenever a commercial comes on.

The intention of my original post was to find out whether J River had any plans on implementing support for R128 Gain. At that stage, I didn't realize that the R128 Gain values calculated by dBpoweramp and other programs were simply written into the existing replay gain tags, which means than in effect J River does "support" R128 Gain playback. It would be nice if they could also provide the ability to calculate R128 Gain within J River, but as I do all my ripping with dBpoweramp anyways, it's a non-issue for me personally.

The issue for me is that you cannot simply scan files to add R128 gain with dBpoweramp, you need to be ripping or doing a conversion to add them. And dBpoweramp doesn't calculate the BPM and Intensity tags that MC does when scanning files - to get those, you have to overwrite the current tags.

And R128 is not just designed for music playback - it's designed to be implemented with video as well, and even treats surround channels differently from stereo ones.

R128 is already well established in other parts of the world and actual professional use of it for preparation for broadcast audio (like in the upcoming Wavelab 8 for example) involves software that performs an actual destructive edit (re-render) of the audio file itself to have it conform it to a specific LUFS threshold prior to delivery to an outlet - NOT writing some numerical tag into an untouched file and then having some unknown software read that tag when the piece is broadcast on TV...

The EBU have recommended that R128 gain is performed by editing the audio rather than using metadata - but they have not required it. The reason for this is that if you're working in broadcast, if some device in the chain does not support the metadata, you lose the normalization - similar to playing music that has ReplayGain tags in a player that doesn't support it.

I have no problem if MC simply replaces ReplayGain tags with R128 data - it's the scanning process that is different, once you have the R128 calculated level, normalization is performed the same way. I would prefer not editing the audio, and if you use the standard ReplayGain tags, you then see the results of R128 in any player that supports ReplayGain. (and iTunes if we get the option to write Sound Check tags to the file)

However, I think it might actually best if MC were to add a new tag to the files for the -23dB R128, and then implement the standard -14dB ReplayGain tags so that files are compatible across all players. (rather than the -20dB ReplayGain tags we have now)

Well - until I see that the makers of dbPowerAmp have been totally vetted by the EBU as being fully compliant with the R128 spec - I am not going to assume anything. And without any documentation on what it does (From the dbPowerAmp guys) - all this seems like on the surface is them now calling their "replaygain" function "E128" using another set of math to create a tag.

I am not saying it's a "bad thing" necessarily but that it's just a "thing". If a RG tag has a 7.5 in it from dbPoweramp and a 7.75 in it as done by JRiver - again - who cares? It's not like this value is going to suddenly have a world altering effect on the sound of the file.

But that's all R128 is - another way of calculating what the gain should be. The difference is that a lot of research went into how the final normalization value is arrived at, to try and keep audio at the same loudness level. And dBpoweramp can either write R128 as a tag via the ReplayGain DSP, or edit the audio with the EBUR128 Normalize DSP.

For example:

ReplayGain/R128
Album Gain: +0.79/-6.6
Track Gain: +4.05/-0.83

Now unfortunately, lasker98 didn't specify what tool he used to scan the ReplayGain tags. The ReplayGain standard targets -14dB, MC18 targets -20dB, and R128 targets -23LU (which is equal to -23dB)
So the difference may not be as large as it appears. If those values were both calculated with dBpoweramp, in MC the difference would be:

Album Gain: -5.21/-6.6
Track Gain: -1.95/-0.83

[lasker98]

"...involves software that performs an actual destructive edit (re-render) of the audio file itself to have it conform it to a specific LUFS threshold prior to delivery to an outlet..."

Might be worthwhile for TV broadcast, but I don't want any software doing that to music files.

I'm not sure where this idea of destructive editing is coming from. Is replay gain destructive? R128 Gain data is written to replay gain TAGS. The volume leveling data is written into tags and the tag data is read by the playback software and this is used to adjust the level of the audio. Nothing is done to the file itself. No destructive edit.

[lasker98]

Now unfortunately, lasker98 didn't specify what tool he used to scan the ReplayGain tags.

I'm sorry for the confusion. I thought the post in question (see quote below) made it clear I was using dBpoweramp.

From what I see, after converting the same cd first to replay gain, then to R128, dbpoweramp writes R128 values into the track and album gain tags. As a comparison between the calculated levels here's the values for the first track from the cd (replay gain first, R128 last):

[Mikkel]

I'm not sure where this idea of destructive editing is coming from. Is replay gain destructive? R128 Gain data is written to replay gain TAGS. The volume leveling data is written into tags and the tag data is read by the playback software and this is used to adjust the level of the audio. Nothing is done to the file itself. No destructive edit.

Destructive in the sense that the audiofiles are resampled (I think) to 192khz, re-levels the lufs-level and then reconvert back to its previous sample rate. At least that is how I understood (part of) the proces by reading the EBU R128 forum thread at hydrogenaudio (the thread by the developer of the EBU R128 software used by dbpoweramp and foobar).


Best regards,
Mikkel

[6233638]

I'm sorry for the confusion. I thought the post in question (see quote below) made it clear I was using dBpoweramp.

I assumed that was the case, but wasn't certain.

So if they had been scanned with MC18 for the ReplayGain calculation, the difference would be:

ReplayGain (MC18)/R128
Album Gain: -5.21/-6.6
Track Gain: -1.95/-0.83

Because MC18 calculates ReplayGain to -20dB rather than the standard -14dB. And if you set MC to -23dB (I use ReplayGain with a -3dB fixed correction) it would be:

ReplayGain (-23dB)/R128
Album Gain: -8.21/-6.6
Track Gain: -4.95/-0.83

Destructive in the sense that the audiofiles are resampled (I think) to 192khz, re-levels the lufs-level and then reconvert back to its previous sample rate. At least that is how I understood (part of) the proces by reading the EBU R128 forum thread at hydrogenaudio (the thread by the developer of the EBU R128 software used by dbpoweramp and foobar).

They only need to be upsampled to determine the R128 gain value - you can do that to a temporary file and discard it, writing the values to the track metadata rather than editing the file.

[Vocalpoint]

I'm not sure where this idea of destructive editing is coming from. Is replay gain destructive? R128 Gain data is written to replay gain TAGS. The volume leveling data is written into tags and the tag data is read by the playback software and this is used to adjust the level of the audio. Nothing is done to the file itself. No destructive edit.

All professional level R128 software I have seen (or have had access to) requires one to completely "normalize" (resample) the actual file and recreate it using the newly calculated data including true peak calculations and so on.

This is not the same thing (as I understand it) as having a software player "drop" the level by reading some tag that sits in the ReplayGain tag slot.

That is all I was trying to say....true R128 processing (EBU Spec) vs sticking a new value in the ReplayGain tag are not the same thing and will not be played back in the same way.

There must be some reason that some of this software (that does pro level EBU processing) is worth 500-3000 dollars...if all this software does is recreate a file that plays back in an identical way to one that contains a simple ReplayGain tag  - then why would companies like NuGen (LM Correct), Grimm Audio (Level One) Minnetonka (AudioTools Loudness Control) etc even bother? Moreover - why would anyone buy this stuff?

VP

[6233638]

All professional level R128 software I have seen (or have had access to) requires one to completely "normalize" (resample) the actual file and recreate it using the newly calculated data including true peak calculations and so on.

This is not the same thing (as I understand it) as having a software player "drop" the level by reading some tag that sits in the ReplayGain tag slot.

This is optional in the R128 Spec. In professional environments it makes sense to normalize the file, because it eliminates the possibility of the audio being played at its original level.

Inside Media Center, I would much rather use metadata (tags) than change all of my audio files. This could be done by replacing current ReplayGain tags with R128 values, or by introducing new tags for R128.
If you use ReplayGain tags containing R128 data, then you get R128 normalization in any application that can use ReplayGain.

[Vocalpoint]

Inside Media Center, I would much rather use metadata (tags) than change all of my audio files.

Hey - so would I I am not saying that MC should start resampling everything.

This could be done by replacing current ReplayGain tags with R128 values, or by introducing new tags for R128. If you use ReplayGain tags containing R128 data, then you get R128 normalization in any application that can use ReplayGain.

Well - here's where I remain skeptical. Unless MC is totally outfitted to perform analysis AND playback using the actual true R128 algorithms - I do not believe that simply placing a different "number" in the RG tag and then let the existing tired old ReplayGain code read that number makes this any different (or better) than it is right now.

How can a change in a text field of a tag value suddenly represent a "sea change" in overall "betterness" of the presentation? Whether this value is 5 or 7 or 9.245 - the file will simply playback louder or softer. I fail to see how that suddenly represents R128 "normalization" in any way.

Pro level R128 software that "normalizes" an audio file to a specific level spec changes it's structure - a lot - not just the basic level of the file.

But if we really are now saying that true R128 compliance boils down to a file tag - makes way more sense for every broadcast outlet in the world to spend 20 bucks on dbPowerAmp and use it to create new ReplayGain tags for everything rather than wasting thousands on expensive R128 compliant processing software.

VP

[6233638]

How can a change in a text field of a tag value suddenly represent a "sea change" in overall "betterness" of the presentation? Whether this value is 5 or 7 or 9.245 - the file will simply playback louder or softer. I fail to see how that suddenly represents R128 "normalization" in any way.

R128 defines how the audio is analyzed to create a "loudness" value for the audio, rather than traditional normalization that performed a much more simplistic analysis.

The end result is the same though - the track is either raised or lowered in volume so that its average loudness is -23 LU.

The difference between R128 and ReplayGain is in the analysis and the target level, not how the normalization is actually applied.

Pro level R128 software that "normalizes" an audio file to a specific level spec changes it's structure - a lot - not just the basic level of the file.

It shouldn't be.

But if we really believe the true R128 compliant boils down to a file tag - makes way more sense for every broadcast outlet in the world to spend 20 bucks on dbPowerAmp and use it to create new ReplayGain tags for everything rather than wasting thousands on expensive R128 compliant processing software.

Well dBpoweramp doesn't scan video files, and that assumes the entire audio chain supports ReplayGain tags. And even if it did, dBpoweramp's license probably doesn't allow for it to be used in professional environments like that.

The broadcast industry is like that though - you need "pro grade" tools that cost an order of magnitude more than consumer-grade equipment, even if it performs the same task.

[Vocalpoint]

The end result is the same though - the track is either raised or lowered in volume so that its average loudness is -23 LU.

Well - I disagree (or I simply do not understand R128 at all

If I use the "RMS Normalization" tool (very similar to what I thought was an R128 normalization using these expensive tools) on a wav file in Wavelab - and I dial it into to be -14.5 RMS - the resulting waveform changes dramatically - and does not represent a simple volume shift. Radical bulges and shifting in the physical makeup of the file are applied to meet a specific RMS value that I have dialed in. Rarely does the actual overall "gain" of the file increase in size....this is what I was getting at.

But you are now stating that this entire R128 spec is all about simply raising or lowering the volume? With a simple file tag? Wow - we may as well just stick with Replay Gain

VP

[6233638]

If I use the "RMS Normalization" tool (very similar to what I thought was an R128 normalization using these expensive tools) on a wav file in Wavelab - and I dial it into to be -14.5 RMS - the resulting waveform changes dramatically - and does not represent a simple volume shift. Radical bulges and shifting in the physical makeup of the file are applied to meet a specific RMS value that I have dialed in. Rarely does the actual overall "gain" of the file increase in size....this is what I was getting at.

If you are changing the waveform, you are changing the dynamic range of the audio. I am not familiar with Wavelab, but that sounds like it is applying dynamic range compression to hit a certain target level.

R128's goal is to normalize to a specific loudness target without affecting dynamic range.

With the "current" broadcast standard of using peak normalization, if you severely compress the dynamic range of the audio, when playback is normalized, the compressed tracks sound much louder than those with a lot of dynamic range.

By normalizing the audio to -23LU, tracks with a lot of dynamic range and tracks that are highly compressed will play back at the same loudness. (or as close as you can get)
However, now the tracks are at the same loudness, the lack of dynamics with the compressed track really stands out - so now it discourages the use of dynamic range compression, and should hopefully end the "loudness war".

This is the same thing that ReplayGain tries to accomplish, but the difference is that the analysis of the audio using R128 should be much better at producing a consistent volume across tracks. And because it's a broadcast standard, it should actually influence how files are mastered, unlike ReplayGain.

While ReplayGain helps to normalize volume, I still have to raise or lower it a lot of the time. Using R128 analysis should reduce or eliminate the need to touch the volume control - especially if it's also being applied to video files inside Media Center. (as R128 was designed for use with more than just two channel music)

[mark_h]

I've been using an offline tool http://r128gain.sourceforge.net/ for a while to get R128 numbers for my files.  I then import the results into my MC collection using different tags.  It allows me to do various analysis of files but nothing else yet.

I would like to see MC include R128 scanning as part of the "analyse audio" function as well as TT-Dynamic Range (I find both numbers useful)

[6233638]

I would like to see MC include R128 scanning as part of the "analyse audio" function as well as TT-Dynamic Range (I find both numbers useful)

R128 includes measuring dynamic range with the LRA value.

[mark_h]

The TT-Dynamic Range is often quite different from the LU Range.  Clearly as a result of the different processing, sometimes TT-DR is low while LU Range is high, and sometimes the opposite.  Both have stories to tell...

I've been working on my own Dynamic Quality metric for a while that I use to compare the same tracks/albums - eg remastered albums or duplicates on compilations etc.  Both TT-DR and LU Range bring useful information.