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

Volume normalization (in web player) #233

Closed
JaneX8 opened this issue Apr 27, 2020 · 13 comments · Fixed by #1988
Closed

Volume normalization (in web player) #233

JaneX8 opened this issue Apr 27, 2020 · 13 comments · Fixed by #1988
Labels
blocked This issue is blocked by an upstream dependency enhancement help wanted

Comments

@JaneX8
Copy link
Contributor

JaneX8 commented Apr 27, 2020

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:

  • Song A: 25
  • Song B: 50
  • Song C: 75

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).

@deluan
Copy link
Member

deluan commented Apr 27, 2020

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

@JaneX8
Copy link
Contributor Author

JaneX8 commented Apr 27, 2020

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.

@andrewzah
Copy link

@deluan I opened a feature request but the author stated if this functionality is desired, we should submit a PR.

@deluan
Copy link
Member

deluan commented Jul 31, 2020

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.

@andrewzah
Copy link

andrewzah commented Jul 31, 2020

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.

@deluan
Copy link
Member

deluan commented Aug 2, 2020

Not sure. When I'm ready to work on this, I'll take a look at the options and ask for feedback here

@rochakjain361
Copy link
Contributor

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
@abhinavmaharana
Copy link

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!

@ishtiaqSamdani
Copy link

I have just completed my exams, so I am late
can I still contribute to this cause I am really interested in it
I have an idea that we can add it to the Alexa problem too
mentor I hope you will guide me on this :)

@swayamg20
Copy link

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.

@JaneX8
Copy link
Contributor Author

JaneX8 commented Jan 18, 2023

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.

@deluan
Copy link
Member

deluan commented Jan 18, 2023

This issue was closed because a solution was implemented in #1988, and was already merged. Let me know if you have any other concerns.

@github-actions
Copy link

github-actions bot commented Mar 7, 2023

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 7, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
blocked This issue is blocked by an upstream dependency enhancement help wanted
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants