-
-
Notifications
You must be signed in to change notification settings - Fork 799
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
Volume normalization (in web player) #233
Comments
I think this is a matter of exposing the replaygain tags to the player, and each player has to handle it individually. For Navidrome's own player, this would have to be handled by the upstream project, https://github.com/lijinke666/react-music-player. Not sure if this is actually possible to do with the browser's HTML5 mediaplayer. Will keep this open and may come back to it later, but I'd argue that more important than volume normalization is gapless playback |
Gapless playing should definitely be a feature to keep on the backlog. If the upstream player doesn't want to introduce it we should maybe search for alternatives using browser tech that does support it. You could also then make a setting which player to use (preferably not). Regarding normalization, agreed upstream issue and yes exposing the tags to the player is a start. I will request it there. Also, I would also want to keep this on the backlog. |
@deluan I opened a feature request but the author stated if this functionality is desired, we should submit a PR. |
Yeah, I saw that.... Well, I don't have too much time either ATM, but may come back to this and try to contribute back to his project. |
Do you think something like this example based on the ReplayGain algorithm could work entirely in the frontend? That way it wouldn't be reliant on replaygain tags existing. |
Not sure. When I'm ready to work on this, I'll take a look at the options and ask for feedback here |
I would love to work on this issue for this edition of GSOC! Can't wait to get to know more about the project and community! |
1 similar comment
I would love to work on this issue for this edition of GSOC! Can't wait to get to know more about the project and community! |
I have just completed my exams, so I am late |
Is this issue still open? I was reading about this issue and I think I can solve this issue, can you help me on that please. |
This issue shouldn't be closed. Even if dependency is unmaintained. As @andrewzah pointed out, possible other solutions (in frontend) for volume normalization could work. |
This issue was closed because a solution was implemented in #1988, and was already merged. Let me know if you have any other concerns. |
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Volume is usually a big problem in libraries. When volume is normalized tools like MP3Gain and I believe also replaygain add information to the ID3 tag without touching the data itself. So just analyzing the volume and adding metadata. I think we should have a setting to enable support for that at least in the webplayer. I don't know exactly what tags are used for that but I suggest that we research that and use that information.
I have some ideas on the implementation (and I have no idea if it's a common implementation like this, just came to my mind).
Lets say we have three songs with different volume levels:
Assuming the normal level should be 50, you'd expect Song A to have a metadata tag saying +25 and song C having a tag saying -25.
Now I suggest we introduce two volume levels in the Web Player. One Hidden and one Shown. The Shown one is simply for the user to control the output volume from 0-100%.
The hidden one can be used for the volume correction according to the metadata tag. So when our hidden volume is 50, we can use the tag to add or remove 25 from the baseline volume depending on the metadata tag but it won't affect the volume setting of the users 0-100% which is just an overall volume control.
Regarding streaming capabilities to other devices and when other apps are used over the Airsonic API, I have no solution to fix this yet without actually changing the data (during transcoding).
The text was updated successfully, but these errors were encountered: