v17 replaygain doesn't seem to be working
#1
I was testing replaygain in beta5, but it doesn't seem to work. I have a flac and mp3 test file. Tried using both the "use album levels" and "use track level" settings but neither had any effect.

There's no indication in the log that the Xiph comment or ID3v2 tags aren't being used. So my best guess is the ReplayGain:TonguearseGain function isn't returning a valid gain.

I have logs and 2 test files. In my log I have the preAmp setting 90.0 for files with gain and 89.0 for files without gain and AudioDecoder is reporting:
Code:
AudioDecoder::GetReplayGain - Final Replaygain applied: 1.000000, Track/Album Gain 89.000000, Peak 0.000000

Test files:

https://www.dropbox.com/s/m8joxsa68d4pyg....flac?dl=0
https://www.dropbox.com/s/ih1je6fraajfor7/440a.mp3?dl=0

scott s.
.
Reply
#2
It would seem in CAudioDecoder::GetReplayGain() that unless you tag both peak and gain then the tag value gets ignored. I don't know if there is a good reason for this, or what the previous behaviour was. Need someone with more knowledge of the audio decoder to comment.
Reply
#3
So I asked the experts... Smile

Seems that no only is the need for both gain and peak tag values a glitch that has been around for the last 2 years, but that peak clipping was being impelmented incorrectly. Fernet has a PR up to fix both, thanks Scott for sending me off on a fruitful investiagtion.
Reply
#4
Thanks for looking into this. I know at some time, maybe around Gotham there was a problem but it got sorted. It might have been though that some tagging software was tagging in the form "-7.5 dB" and the "dB" string was causing problems. I have never added the "peak" tag though I could run files through RPG again (or better, r128gain). It's mainly an issue when using party mode, as volume differences between songs will drive you crazy.

Also from looking at the code, it looks like if album gain is selected in settings, but not tagged it will first fall back to track gain if available. Didn't know that.

scott s.
.
Reply
#5
Hi, was this issue solved on Kodi V 17.0 RC1? I'm having a problem with replaygain, so maybe the issue is the same.

Thanks
Daniele
Reply
#6
This related to tagging and how it was applied, that is fixed in RC1.

What issues are you having? If the player team need to investigate they will want much more infomation, debug logs etc.
Reply
#7
I did a further check, I've a collection of ogg, mp3 and Flac files. While ogg and mp3 sounds almost at the same level, I feel that Flac files are played louder.

I tried using Qmmp on my laptop, and all is working well.

Thanks for your help.
Reply
#8
Hi,

I'll just add my 2 cents. I've recently upgraded from 16.1 to 17RC4 and I've noticed replaygain not being applied. According to the debug log it's reading the correct replaygain information from the mp3 files, but it isn't actually applying the gain change (I can tell by listening to 80s metal vs modern metal)
Reply
#9
If you want the player team to investigate you will need to provide the debug log (a link to where it is pasted, not in the post).
Reply
#10
(2017-02-04, 09:21)nzjonnydeath Wrote: Hi,

I'll just add my 2 cents. I've recently upgraded from 16.1 to 17RC4 and I've noticed replaygain not being applied. According to the debug log it's reading the correct replaygain information from the mp3 files, but it isn't actually applying the gain change (I can tell by listening to 80s metal vs modern metal)

I'm in a similar situation to the above. I'm running Kodi on OSMC on a Raspberry Pi 2 and installed the new Kodi 17 release yesterday and I don't believe the ReplayGain settings are being implemented correctly.

I've enabled debugging and had a look in the logs and it appears to be reading the correct ReplayGain tag information but not actually applying it when playing back. Whereas before the update playing a Party Mode playlist had a consistent volume it's now varying quite a lot.

I'm using Album Levels although I can't hear much difference if any between that and Track Levels although turning it off completely makes a noticeable increase in volume. I've no hard evidence to back this up but it appears it's recognising it as a track with ReplayGain information but just applying a blanket 89dB adjustment. Changing the preamp level setting for "Files with ReplayGain information" does affect the volume as expected.

I can provide a debug log but is this just a case of enabling the debugging playing a few songs and then uploading it or is anything else required?

One other thing to mention is that I notice the setting regarding not allowing a track to clip (can't remember the exact name of the setting) is no longer there and I had that enabled on version 16 so could that be coming into play somewhere?
Reply
#11
You need the player experts to respond on this, and they are a bit busy at the moment with some bug fixing. When they get a quieter moment I will ask them to discuss it.

My very vague understanding is that how the player handles gain adjustments has changed. Hence no need for the clipping setting, but the levels should be working.

I would say debug log for playback of a song with replay gain tags would be a good starting point. If it isn't any use to them nothing has been lost by it.
Reply
#12
I did some actual testing, with a source file that contains just a 440Hz steady tone. I recorded the output from Kodi on my win 7 computer using the Realtek "Stereo Mix" recording device to Audacity 2.1. I had to use the DirectSound option, not WASAPI. In audacity I use the FFT spectrum analyzer on the recorded audio to compare the output with different replaygain settings. I found that the gain is being applied, but I don't think it is linear (in dB), meaning that replaygain values (in the file metadata) of -3.0, -6.0, and -9.0 didn't produce results that seemed consistent. But they were applied. In all cases the debug log shows the computation is correct (though I don't know the source of the function used for the final computation).

Looking back through some notes this is what I measured:

RPG -1.0 measured 0
RPG -3.0 measured 0
RPG -5.0 measured -6
RPG -7.0 measured -8

scott s.
.
Reply
#13
http://www.filedropper.com/kodi_5

There goes my log. It looks like it's getting it right, but it doesn't sound like it's getting it right. The replaygain lines from that file are (I've added the Album gain bits at the end copied from the mp3 tags):

18:53:33.646 T:50904 DEBUG: AudioDecoder::GetReplayGain - Final Replaygain applied: 0.360579, Track/Album Gain 80.139999, Peak 1.037169 Album Gain: -8.86 dB
18:54:00.502 T:50904 DEBUG: AudioDecoder::GetReplayGain - Final Replaygain applied: 0.745590, Track/Album Gain 86.449997, Peak 1.006582 Album Gain: -2.55 dB
18:54:33.802 T:50904 DEBUG: AudioDecoder::GetReplayGain - Final Replaygain applied: 0.653131, Track/Album Gain 85.300003, Peak 0.947998 Album Gain: -3.70 dB

So it definitely is getting the correct values, and calculating the gain adjustment values.
Reply
#14
Here's my log, just a couple of tracks played to show that it appears to be picking up the correct ReplayGain values:

https://paste.ubuntu.com/23950870/

The two tracks I picked are actually the same song, one from the original album and one from a singles boxset. The original album is one that has always sounded noticeably quiet with the one from the singles boxset what I would perceive to be a more "normal" volume.

For information here are the tags for the two tracks

REPLAYGAIN_ALBUM_GAIN -2.87 dB
REPLAYGAIN_ALBUM_PEAK 1.000000
REPLAYGAIN_TRACK_GAIN -2.58 dB
REPLAYGAIN_TRACK_PEAK 0.909424

REPLAYGAIN_ALBUM_GAIN -7.11 dB
REPLAYGAIN_ALBUM_PEAK 0.996613
REPLAYGAIN_TRACK_GAIN -6.94 dB
REPLAYGAIN_TRACK_PEAK 0.985748

One thing that did strike me as odd, and this could well be my lack of understanding of exactly how ReplayGain works, is that while the gain figures seem logical, the first track which is much quieter has higher gain values, I was surprised to see the album peak for the quiet album at 1.000000 with the more normal sounding album with a lower peak value

Now obviously any issue here is with the method I've used to scan the tracks and write the tags, not a Kodi issue, but with the mention of a change in the way that Kodi handles clipping, and this is a total shot in the dark, could the previous version of Kodi masked something odd in my tagging that is now becoming apparent?

I will do some reading up on ReplayGain to improve my understanding and may do some testing with rescanning my files using different software and/or removing the peak tag to see what effect it has. If I find anything that might be useful I will report back otherwise hopefully we can get to the bottom of the sudden change in the new version of Kodi.

Anything more I can provide to help with any investigation let me know.
Reply
#15
Taking this slightly off topic does anyone know of a free program for batch adding replaygain tags to tracks on a windows platform
Reply
 
Thread Rating:
  • 0 Vote(s) - 0 Average



Logout Mark Read Team Forum Stats Members Help
replaygain doesn't seem to be working00