v17 replaygain doesn't seem to be working
#31
(2017-02-08, 14:32)tkgafs Wrote: Taking this slightly off topic does anyone know of a free program for batch adding replaygain tags to tracks on a windows platform
http://i.imgur.com/c7Gf87d.png
Reply
#32
Yeah I went back to 16.1 just to get it back
Reply
#33
Guys if all you do is say replaygain isn't working in Krypton and then retreat to using Jarvis, you will simply be stuck on Jarvis forever. It is not going to magically change in v18 either. Personally I am happy for you to be stuck on Jarvis, or not use Kodi at all for that matter. :p

My knowledge of replaygain, how it should or could work is limited, and it is not something I personally use since I listen mostly to albums and manual volume adjustment between albums is no big deal. But I am happy to act as an intermediary between users and the player dev team, however I need adequate details to be able to do that.

What has been said so far on this thread has not attracted them to jump in and either explain or change anything. So if you want something changed or fixed then you need to be more proactive than just moan (and I know some have done more than that, but I am afraid I still don't gasp the issue enough to be an effective advocate)

Anyone got a technical reference as to how replaygain is intended to work?
Reply
#34
Any replaygain issues should probably be raised on trac with clear description, sample file, and log file then assigned to Fernetmenta.
Reply
#35
(2017-03-17, 17:03)DaveBlake Wrote: Anyone got a technical reference as to how replaygain is intended to work?

http://wiki.hydrogenaud.io/index.php?tit...cification
Moanbag is in da place!
Reply
#36
I took a step away from this after my initial investigation as I don't really know what else I can add to help push towards a resolution.

While I am a user of ReplayGain I don't confess to know the ins and outs of the specification or it's implementation in Kodi.

What I do know is that if I manually set the albumpeak tag to 1 or remove it completely, to my ears, the ReplayGain adjustments are applied, anything other than 1 and the code seems to apply "SetAmplification(gain)" and again I don't know what this actually does specifically other than the volume is not balanced across albums.

As I don't play my media in anything other than Kodi I did a bulk edit to remove the albumpeak tag (backed up to a non-used tag so I don't lose the information) and now feel that I get the same experience as in Jarvis.

Anything I can do or provide to help with possibly getting a fix for this I will but will really need guiding in what and how to provide it.

For me it all ties back to the following code that was amended in version 17:

Code:
+  if (peak == 1.0)
+    si->m_stream->SetReplayGain(gain);
+  else
+    si->m_stream->SetAmplification(gain);

But I could well be over-simplifying the issue.
Reply
#37
(2017-03-17, 17:17)jjd-uk Wrote: Any replaygain issues should probably be raised on trac with clear description, sample file, and log file then assigned to Fernetmenta.
True. But it could be quicker to talk to me clearly instead.

(2017-03-17, 17:44)Gracus Wrote:
(2017-03-17, 17:03)DaveBlake Wrote: Anyone got a technical reference as to how replaygain is intended to work?

http://wiki.hydrogenaud.io/index.php?tit...cification
Thanks, as it happens I was just looking at that.

I now have some doubts about the removal of the old “avoidClipping” setting. Generally when stream amplification is applied the ActiveAE implicitly has clipping protection, but I am not sure that a peak value other than 1.0 means that the user wants the replaygain applied as stream amplification in the way that @FernetMenta implemented it.

It could be good for Kodi to always enforce some kind of clipping protection, but give the user the choice of if that is done using "audio limiting" or using "reduced gain".

In v16 the optional clipping protection was a "reduced gain" approach

if (abs(peak * replaygain) > 1.0)
replaygain = 1.0 / abs(peak);

But I have questions if that is correct either, it is not quite what as the HydrogenAudio article says.
But how is "audio limiting" to be applied?

I can see though that what v17 does, simply using replaygain as a stream amplification whenever peak is not 1, is not going to give users the volume adjustment that they want, or that works in the way other players use the replaygain and peak tag values.

The solution to this is probably simple, I just don't quite get it (yet).
Reply
#38
(2017-03-17, 19:45)DaveBlake Wrote:
(2017-03-17, 17:17)jjd-uk Wrote: Any replaygain issues should probably be raised on trac with clear description, sample file, and log file then assigned to Fernetmenta.
True. But it could be quicker to talk to me clearly instead.
Point taken, but as the necessary ReplayGain user options haven't been implemented yet, these actions aren't a requirement.

(2017-03-17, 19:45)DaveBlake Wrote: I now have some doubts about the removal of the old “avoidClipping” setting.
Agreed, this action was a reduction in user-selectable options.

(2017-03-17, 19:45)DaveBlake Wrote: It could be good for Kodi to always enforce some kind of clipping protection...
No, the user should always have control over this option.

(2017-03-17, 19:45)DaveBlake Wrote: The solution to this is probably simple, I just don't quite get it (yet).
We require ReplayGain user-selectable settings:

Loudness normalisation options
1. Off
2. On = Album
3. On = Tracks

Pre-amplification options
1. Off
2. On = +/-dB

Clipping prevention options
1. Off
2. On = Audio limiting
3. On = Reduced gain
Reply
#39
(2017-03-17, 22:32)John R Leddy Wrote:
(2017-03-17, 19:45)DaveBlake Wrote:
(2017-03-17, 17:17)jjd-uk Wrote: Any replaygain issues should probably be raised on trac with clear description, sample file, and log file then assigned to Fernetmenta.
True. But it could be quicker to talk to me clearly instead.
Point taken, but as the necessary ReplayGain user options haven't been implemented yet, these actions aren't a requirement.
Odd attitude John. I came along this morning with the intention of trying to solve this issue, now I feel quite unlike doing so.

Of course users are not "required" to raise Trac issues, and reciprocally no one on the dev team is "required" to implement or fix anything, or provide support. You go on to state what you think users require, do you think that means someone will be motivated do anything about what you want?

What Kodi needs most right now is friendly collaboration: the dev team is tiny, the user base is vast. There is no place for an attitude of entitlement, which is how your tone sounded to me.

Fernet knows most about the player, but does not watch the forum, so a clearly stated Trac issue is the best way to get his attention. JJD was giving good advise. I understand how hard it can be to express problems clearly, and how a Trac ticket that isn't clear can just linger, so I was just offering to help out.

EDIT:
I'm putting together a PR that rolls back some of the changes in PR10924, and I will get a test build up for anyone to test, then I will talk to Fernet about it. I will try to get this ready for 17.1 release, but it could be too late.
Reply
#40
(2017-03-18, 09:19)DaveBlake Wrote:
(2017-03-17, 22:32)John R Leddy Wrote:
(2017-03-17, 19:45)DaveBlake Wrote: True. But it could be quicker to talk to me clearly instead.
Point taken, but as the necessary ReplayGain user options haven't been implemented yet, these actions aren't a requirement.
Odd attitude John. I came along this morning with the intention of trying to solve this issue, now I feel quite unlike doing so.

Of course users are not "required" to raise Trac issues, and reciprocally no one on the dev team is "required" to implement or fix anything, or provide support. You go on to state what you think users require, do you think that means someone will be motivated do anything about what you want?

What Kodi needs most right now is friendly collaboration: the dev team is tiny, the user base is vast. There is no place for an attitude of entitlement, which is how your tone sounded to me.

Fernet knows most about the player, but does not watch the forum, so a clearly stated Trac issue is the best way to get his attention. JJD was giving good advise. I understand how hard it can be to express problems clearly, and how a Trac ticket that isn't clear can just linger, so I was just offering to help out.
Dave,

No attitude on my part mate. Obviously I have no control over how you choose to perceive my comments, but rest assured they're pretty straightforward and matter-of-fact to me.

Maybe it's just a clash of personalities, as that's exactly the same thing I thought about your comments concerning people moaning. I didn't get that at all myself, but as they say, Life would be boring if we were all the same. I thought maybe you were overly tired and just moved on myself.

I was being polite when I stated, "...these actions aren't a requirement." Truth is, we can't log anything of relevance for something which hasn't been coded yet.

I'm at a loss to comprehend why you chose to twist my opinions and suggestions into some sort of personal assault. Your "attitude of entitlement" statement, in my opinion, is way over the top and uncalled for. I certainly wasn't as rude as that to you. What am I saying? I wasn't rude to you at all!

My suggestions were offered in good faith. If you choose to jump to conclusions I have no control over that, but do you not think it's just a shade paranoid to see the worst in another's post? To me it's only obvious there will be communicative misunderstandings, so better to ask for clarification prior to accusing another of something which may have been unintended by the author, or simply imagined by the reader.

I have no ambition to motivate others to implement these changes as they're of no consequence to myself but, in my opinion, these options would further enhance the usability of the application.

I hope this clarifies things for you.

John.
Reply
#41
John, whatever your intentions in practice you have just communicated to me that you think I am both rude and paranoid. Oh well. You can just shrug that off as my perception, clash of personalities, not in your control etc. but I provide it as useful feedback as you say that you want to communicate clearly.

(2017-03-18, 10:48)John R Leddy Wrote: I was being polite when I stated, "...these actions aren't a requirement." Truth is, we can't log anything of relevance for something which hasn't been coded yet.
You seem confused. The things being discussed in this thread have been implemented previously and then that implementation changed in v17. It is not a discussion of new feature requirements, and it would only confuse matters to turn it into one. A Trac ticket could have been raised.

The situation is this: I am the only dev with any interest in music. If users want fixes and improvements to music in Kodi then they need to do what they can to make it as easy and enjoyable for me as possible. It is not about pandering to my sensitivity or needs, just about practicality. I am one man verses a mountain. I genuinely like to help folks, but people also need to be realistic and collaborate when they can.

So what I want to communicate, not be rude to anyone or paranoid or over the top, is that practically some users need to behave differently if they want to help Kodi to move forwards. Just moaning it is broken without details, or come to that listing requirements, when the available resources to work on it are limited is not very productive.

Meanwhile because there is a glimmer of getting something fixed for 17.1 I am trying to do so.
Reply
#42
(2017-03-17, 19:01)Hallucyn8 Wrote: I took a step away from this after my initial investigation as I don't really know what else I can add to help push towards a resolution.

I have a test build underway, would you or any one else be able to test how replaygain is working once it is on the mirrors?
Reply
#43
(2017-03-18, 12:08)DaveBlake Wrote:
(2017-03-17, 19:01)Hallucyn8 Wrote: I took a step away from this after my initial investigation as I don't really know what else I can add to help push towards a resolution.

I have a test build underway, would you or any one else be able to test how replaygain is working once it is on the mirrors?


I'm a little bit busy today but will give it a shot this evening if nobody try it before
Moanbag is in da place!
Reply
#44
Thanks. Test builds are on the mirrors http://mirrors.kodi.tv/test-builds/win32...e-HEAD.exe or for platform.

These are v18 but will prove the concept (or not). I attempted v17 patch builds too, but they failed for some unrelated reason.
Reply
#45
(2017-03-18, 18:53)DaveBlake Wrote: Thanks. Test builds are on the mirrors http://mirrors.kodi.tv/test-builds/win32...e-HEAD.exe or for platform.

These are v18 but will prove the concept (or not). I attempted v17 patch builds too, but they failed for some unrelated reason.

So I'm back after some testing

Got to test it with kodi in portable mode as my current daily kodi is the test 64bits

So here is the result: do not know what you have change but it seems to work beautifuly!

Start the first song, set the volume I want and then go from song to song without having to change volume between songs

Try with different artists just to be sure: coolio, aqua, david Guetta, daniel balavoine, AC/DC

Got absolutly no surprise with the volume!

Just 2 things:

-1 advice: wait for other report from other peoples just to be sure
-1 idea: add a dB Preamp slider for those who could moan because replay gain causes low volume (*)


(*) here is a screenshot of the same option in foobar to help you understand what I'm talking about:

Image

Thanks for your time on this!
Moanbag is in da place!
Reply
 
Thread Rating:
  • 0 Vote(s) - 0 Average



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