Author Topic: Any plans for ReplayGain analysis to use the recent EBU-R128 standard ? [DONE]  (Read 36778 times)

redwing

  • Guest
The difference is whether to simply add tags to the file or to rewrite the file's audio stream with leveled volume. Most people would use the first option since the algorithm can improve further like this very example.

For mp3 players, first check whether yours supports leveling volume by respecting ReplayGain tags. If not, you could tick "level volume" option when you sync files to your device with MB. Some people keep archive/portable versions for each track in their library. In that case, permanently adjusting volume for portable version can make them hassle-free.

phred

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 7880
Thanks for the clarification and suggestion, redwing.
A quick check of the web shows that my iPod Classic does not recognize the ReplayGain tag.  So I'll re-analyze the library with option one, and use the sync-only volume leveling. 
Download the latest MusicBee v3.4 patch from here.
Download the latest MusicBee v3.5 beta patch from here.
Unzip into your MusicBee directory and overwrite existing files.

----------
Check out the MusicBee Wiki.
How to post screenshots is here

redwing

  • Guest
If you're using iDevices, then consider converting ReplayGain tags to SoundCheck values:

http://getmusicbee.com/forum/index.php?topic=9600.0

A little complicated at first, but once it's set up, you could forget about it as everything is automated. That's how I use my iPhone.

DrPhatteus

  • Guest
Wow, serendipity.

I've spent the last week or so attempting to a) find the right media manager, and b) establish volume levels for my music collection. I've been struggling to find a consistent approach, and was using a combination of WinAmp and MediaMonkey to set the ReplayGain tags. I wanted to use MusicBee, but found that the tags written were not honored by other apps.

Now I understand why :) Thanks ya'll. Although it took several days to get all the RG values set across my collection, it seems I may be undoing them in favor of R128 using my top choice for media managers: MusicBee.

I am doing some testing with MusicBee 2.3 now, and my focus is on how XBMC will work in relation to ReplayGain and R128. Since XBMC is my main source for playing music, I'm hoping that it honors the R128 info.

I will report my findings back here shortly.

Thanks again, this app and you guys ROCK!

 

SimonBRT

  • Sr. Member
  • ****
  • Posts: 434
so quick question.  i currently have my library fully tagged to the old replaygain standard.  should i be re-analysing / tagging with this new standard?  is there significant benefit?  if this is going to be the future standard, is it better to adopt now?  realise answers to this can be opinion only, but i am keen to get some input from some knowledgeable folks!

DrPhatteus

  • Guest
Simon- excellent question!

In reference to my post just before yours, I did some testing and the current release of XBMC (12.3) does not support R128.

So, one of the most popular (and best, IMO) media center apps supports ReplayGain, but not  R128.
One of the best media manager apps - MusicBee - supports R128 but not ReplayGain.

Man!!!!!

To Simon's point, it sure would be nice if BOTH standards could be used. Let's face it, ReplayGain is old, but ubiquitous and effective. I am all for utilizing the best algorithms possible for volume analysis, but I wonder how hard it would be (or of there is a workaround) to support the older technology.

*** Could it be as easy as copying R128 values into ReplayGain tags? ***

redwing

  • Guest
Let's get some facts straight for forum users who are not familiar to these technical jargons.

- While ReplayGain 1.0 specification is based on the RMS method, RG 2.0 specification adopts ITU BS. 1770-2 standard. It's called A/85 in the US, EBU-R128 in Europe.
- So probably better to call the old algorithm "RG1" and the new one "RG2" to prevent any unnecessary confusions.
- MB's default algorithm is still RG1, unless you activate RG2 by downloading lib1770.dll file and the latest patch from Steven's post above.
- The end results of volume analysis with any of those algorithms are put in the same RG tags. But individual tag values may be different depending on a track or an album.
- So it doesn't matter which algorithm was used for any players or apps to normalize playback volume with RG tags. But if they are mixed, the playback volume across the entire library may not be ideally normalized.  
- For more information about RG2 specification: http://wiki.hydrogenaudio.org/index.php?title=ReplayGain_2.0_specification
Last Edit: February 17, 2014, 02:59:24 PM by redwing

DrPhatteus

  • Guest
Great info, thanks redwing!

This is for the benefit of anyone else who might be puzzled by mysterious ReplayGain behavior. I believe that MB is doing everything right, but other apps may be misbehaving.

I have done extensive testing today, reading and writing ID3v1, ID3v2 in UTF8 and UTF16,  using a variety of tag editors, trying to narrow down the cause for some strange behavior:

1) Take a virgin mp3, perform volume analysis in MB
2) Play mp3 in XBMC (and WinAmp) and compare with original - files sound the same
3) Edit title in TagScanner - files still sound the same
4) Edit title in MP3Tag, file is now playing at expected volume level!

So, what is that MP3Tag is introducing into the file? Lower case tag names.

In XBMC and Winamp, if the tag names REPLAYGAIN_TRACK_PEAK and REPLAYGAIN_TRACK_GAIN are stored in upper case, then the RG info is not respected during playback. I used a hex editor to change the tag name from upper to lower case (to "replaygain_track_peak" and "replaygain_track_gain") and the file played correctly.

A little googling reveals that this same issue has crept up over the years with foobar, VLC, Sonos, and others. The standard suggests upper case, but many implementations are case sensitive to lower case. Lame!

I did look through the various tag options in MB.... And though I don't see a setting for tag case, I am thinking there may be some double-secret setting I could tweak that would enable me to write lower case tag names in the tags. At least until I convince the XBMC guys to tweak their code :)

Would this be possible?



redwing

  • Guest
Technically it's possible, but probably won't worth the effort. You better use saving in mp3tag method unless Steven offers support for that.
Last Edit: February 18, 2014, 04:14:13 AM by redwing

Steven

  • Administrator
  • Hero Member
  • *****
  • Posts: 33114
i have to say i am staggered that XMBC is case sensitive for that field given the usual convention is for uppercase on TXXX fields and also as documented on hydrogenaudio. However as foobar is writing it in lower case so i will change it to be compatible.
Also thanks for the summary redwing - thats spot on.
For the v2.3 release i think i will include the lib1770.dll file so by default the new algorithm is used and anyone who doesnt want it can delete that .dll file so MB would revert to the old algorithm

Pat

  • Guest
so quick question.  i currently have my library fully tagged to the old replaygain standard.  should i be re-analysing / tagging with this new standard?  is there significant benefit?

Some background.
The original replaygain proposal (for the sake of clarity "RG1") was an attempt at leveling subjective audio volumes. Put simply, subjective audio volumes is called loudness. The problem was that there was no agreed method at defining loudness. So the author of RG1 proposed a method to calculate that subjective loudness. And the author also proposed to use specific tags to store the calculated loudness on track level and album level.

In the past years loudness levels has become a real issue in the broadcast industry because different channels output different volumes forcing you to adjust the volume between channels. And the music industry was caught in a 'loudness war' of CD mastering with ever increasing volume (just watch the wavebar of a track, it's almost completely filled to maximum)

That's why there was an incentive to come up with:
1) a standard to level the volumes across programmes
2) an agreed method to measure subjective loudness

To come up with an agreed method for loudness measurement the following procedure was taken:
1) there was a call for loudness measurement algorithms
2) experiments were set up in which participants had to rate the loudness of various pieces of sound
3) the different algorithms were 'plotted' against the subjective scores and the algorithm with highest goodness of fit was chosen.

The chosen algorithm is called "ITU-1770". So the benefit of this algorithm compared to the RG1 algorithm is that it is more 'evidence based' and purportedly should reflect more accurately the subjective loudness experience of a listener. The calculated loudness of track and album by this 1770 algorithm is also stored in the same replaygain TAGS because they are already implemented by most players.


Last Edit: February 17, 2014, 07:41:17 PM by Pat

DrPhatteus

  • Guest
Steven, I have posted the tag/case issue on XBMC forums and I've been asked to file a bug report, which I will. Not sure when their devs will consider it a "squeaky wheel", but hopefully sooner than later!

That's very cool of you to change MB to use lower-case, it's unfortunate to have to accommodate for bugs in other apps, but I for one am very appreciative that you'd even consider it.

Thanks!






Zak

  • Member
  • Hero Member
  • *****
  • Posts: 2179
XBMC is open source so if it bothers anyone enough it would be easy enough to find out if it's reading case sensitive tags.
Bee excellent to each other...

DrPhatteus

  • Guest
Good point Zak...

I'm not much of a (OK, I admit, not at all) C++ guy, but looking through the XBMC source code in the TagLoaderTagLib.cpp file, I see something quite interesting. For ASF and ID3v2 tags, XBMC looks for lower case tags (lines 380-384 in the ParseID3v2Tag function):

        else if (frame->description() == "replaygain_track_gain")       tag.SetReplayGainTrackGain((int)(atof(stringList.front().toCString(true)) * 100 + 0.5));
        else if (frame->description() == "replaygain_album_gain")       tag.SetReplayGainAlbumGain((int)(atof(stringList.front().toCString(true)) * 100 + 0.5));
        else if (frame->description() == "replaygain_track_peak")       tag.SetReplayGainTrackPeak((float)atof(stringList.front().toCString(true)));
        else if (frame->description() == "replaygain_album_peak")       tag.SetReplayGainAlbumPeak((float)atof(stringList.front().toCString(true)));

Yet for ogg (Xiph comments?) and APE tags, the code references upper case tag names. I'll definitely post a bug report over there!

If it was C# I guess it could be as easy as ".....frame->description().ToLower()" or something like that. :)

Anyways, I know this is a MB forum, not an XBMC forum. I'm just a little geeky and find this all quite fun.

SimonBRT

  • Sr. Member
  • ****
  • Posts: 434
Thanks to all that answered my earlier question.  Some really good info, very much appreciated.  I think when I have some time, I may look to re-write all my replay gain tags using the new standard/algorithm.   Clearly I am a bit of a music geek (I am here aren't I!) so I think it may be worth a little time in getting my whole collection tagged to the same standard.