Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

replaygain_reference_loudness additions #1928

Closed
wants to merge 7 commits into from
Closed

Conversation

bp0
Copy link
Contributor

@bp0 bp0 commented Apr 30, 2016

Get the reference-level from gstreamer replaygain scanner and store it in the replaygain_reference_loudness tag in the same way that flac does.
Also supports that tag in mp4.

Original ReplayGain used 83 dB, but ReplayGain 1.0 uses 89 dB. There are now other loudness measuring standards that specify different levels, and I think it is a good idea to store it.

bp0 and others added 5 commits April 16, 2016 01:03
Add support for mp4 ReplayGain tags in the format used by foobar2000 and deadbeef.
remove trailing whitespace; add test for replaygain tag support in mp4
* store reference-level from scanner in replaygain_reference_loudness tag like flac
* replaygain_reference_loudness support for mp4
@lazka
Copy link
Member

lazka commented May 1, 2016

Original replaygain switched to 89db in 2003. Why do you want this?

@bp0
Copy link
Contributor Author

bp0 commented May 1, 2016

I noticed that foobar2000's ReplayGain scanner gives different results to flac/QL/gstreamer etc, and I found out that it uses a different formula to calculate the values, one based on a relatively new standard for volume normalization called (ITU-R BS.1770 or EBU R128 (Europe) or A/85 (USA)), and those all specify a different reference loudness. I was wondering if they were still using the same reference loudness from ReplayGain or the new specified level, but there was no way to know from the tags themselves. I did eventually find out they were still using 89 dB, but I think just using this tag would make things easier. It is a informational tag, like "encoded by" that tells about the settings of the ReplayGain scanner when it was scanned. It is not supposed to be used by any player. The alternative is to use some kind of tag specifying the formula used to calculate loudness or something, but this tag already exists, so why not use it?

If there was ever an alternative scanner for QL based on say, libebur128, it would be nice to have this tag to tell what the reference level was.

@bp0
Copy link
Contributor Author

bp0 commented May 2, 2016

New additions:
Use a stub for a future preference to store or not store replaygain_reference_loudness, and have it set to False so current behavior is not changed. Now, only update the tag if it already exists in the file being scanned. If preferences are set not to overwrite any tags, then it will still not be written, just as before.

*add user option to store reference loudness
*complete an existing TODO for an option to never overwrite existing tags
@bp0
Copy link
Contributor Author

bp0 commented May 2, 2016

Completed the addition of a plugin preference for storing the reference level, so now it is completely optional. The preference defaults to False, so as not to change existing behavior.

@lazka
Copy link
Member

lazka commented May 2, 2016

Sorry, but I'm not convinced.

Taking into account the extra options etc this doesn't add much besides confusing users:

  • What is the reference loudness?
  • What if I delete it? Do I have to keep it? Can I change it and what will it do?
  • What happens if I select to not store reference loudness? Does that add problems for other players to apply replaygain?

And that for no real gain...

@bp0
Copy link
Contributor Author

bp0 commented May 3, 2016

What about just adding a little explanation next to the option?

Anyway in the case that it exists already, shouldn't the scanner update it and make sure it is correct?

@lazka
Copy link
Member

lazka commented May 3, 2016

Anyway in the case that it exists already, shouldn't the scanner update it and make sure it is correct?

What would be the reason that it exists already? Which application writes/adds them?

@bp0
Copy link
Contributor Author

bp0 commented May 3, 2016

As far as I know, only flac.

@lazka
Copy link
Member

lazka commented May 4, 2016

OK, passing "--replay-gain" creates "89.0 dB" which is hardcoded in the flac source.

So, there is one source of the tag which always writes the same value which happens to be the default and isn't used by anything else.

Maybe delete it in the replaygain plugin if it exists?

@bp0
Copy link
Contributor Author

bp0 commented May 4, 2016

I thought it could be useful if an alternate scanner (bs.1770/r128/a85/rg2.0) was implemented, supporting and using this existing tag rather than making something new.
Anyway, it is ok.

@bp0 bp0 closed this May 4, 2016
@lazka
Copy link
Member

lazka commented May 4, 2016

bs1770 is tracked here: #1609

@bp0
Copy link
Contributor Author

bp0 commented May 15, 2016

There is a scanner tool called bs1770gain that also writes REPLAYGAIN_REFERENCE_LOUDNESS, as well as another tag REPLAYGAIN_REFERENCE_ALGORITHM, and they are variable. So I guess it isn't just flac.

@lazka
Copy link
Member

lazka commented May 16, 2016

Thanks

Example tags for bs1770gain with --replaygain

TXXX=REPLAYGAIN_ALBUM_GAIN=-7.47 dB
TXXX=REPLAYGAIN_ALGORITHM=ITU-R BS.1770
TXXX=REPLAYGAIN_REFERENCE_LOUDNESS=-18.00
TXXX=REPLAYGAIN_TRACK_GAIN=-7.47 dB

default tags:

TXXX=REPLAYGAIN_ALBUM_GAIN=-12.47 LU
TXXX=REPLAYGAIN_ALGORITHM=ITU-R BS.1770
TXXX=REPLAYGAIN_REFERENCE_LOUDNESS=-23.00
TXXX=REPLAYGAIN_TRACK_GAIN=-12.47 LU

I guess we should delete REPLAYGAIN_REFERENCE_LOUDNESS and REPLAYGAIN_ALGORITHM in the replaygain plugin for now.

@lazka
Copy link
Member

lazka commented May 16, 2016

I've opened #1942

lazka added a commit that referenced this pull request May 30, 2016
At least for eading/writing. We don't use it for gain adjustment.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants