I’ve noticed this for a wile but it’s more severe since I’ve disabled the preamp due to clipping. To put it simply, volume normalisation doesn’t always work. I only stream Tidal, so I can’t comment regards local libraries.
I notice this with both the latest desktop appimage and the headless version on different devices. I’ve not used Windows recently, so can’t comment about that.
One thing I notice (beside the house suddenly shaking if I have things turned up) is that the loudness graph is not displayed for offending tracks & that if I reduce caching to a single track, skipping songs and returning often resolves the issue for the previously offending track (so I assume that the data is there, or can be computed).
The thing is, the volume can only be normalized after at least one Plex user has listened to that album. Simply because it is not practical to analyze the full catalog of Tidal.
Does Tidal not stream each track with replay data? Regardless, this should never be an issue when simply letting things play through with caching enabled. Other apps manage it.
Don’t dismiss the issue without looking at the logs either. There are clear concerns, such as “gain nan”, “gain null” and “gain 0.0 dB”. A dev should look at this.
I think the Plex loudness analysis is slightly different from replay gain.
Also, it has been explained somewhere on these forums previously (I did a quick search but couldn’t immediately locate the post) how Plex ‘obtains’ it’s loudness analysis for tidal tracks. Basically it’s a cloud thing where once one user as played an album the loudness analysis is computed and uploaded to a cloud server from which subsequent users obtain the loudness data when they play tracks from that album. Or some variation of that sort of thing. Plex is not computing loudness on tidal tracks in real time when you play/cache.
So I guess in the case of your screenshot, that album has not previously been played by a user so as to compute the loudness analysis.
This is going on the assumption that you are only ever going to play a Tidal hosted track/album once.
Here’s why >>>
While I assume that Tidal is a way for many Plex users to discover new music that is not in their collections, if you are playing tracks from Tidal that have never been played by any other user, those tracks will not be leveled etc. for that one time. However, they will be analyzed when you play them, so those tracks should then be good to go on subsequent plays.
So the fact that a track has to be played once by a single user in order to be analyzed for the benefit of all users is hardly a reason to disable the feature
I realise that my previous comment was a bit flippant. I do however listen to a lot of mixes, often playing in a different room as background while I work and this gets very annoying, especially with no decent remote volume control. With loudness levelling enabled, it can easily jump from -10dB to -0dB which is huge! It really is safer to be at the mercy of the individual records in this instance.
I also get the opinion that most here probably don’t use Tidal & I feel like a beta tester as a result. It’s just not what I expect from subscription software. If it were free and open source then it’d be a different matter. At this point, I’m honesty finding Bubble UPnP → upmpdcli → mpd to provide a more seamless headless + remote solution. Note that I didn’t say ‘better’ as I do consider Plexamp to show promise and that’s why I get frustrated.
Anyhow, I get it, things are done in a certain way & should improve with more listeners. However, I’d like to propose a suggestion if things are indeed functioning as intended. I get that we’re following Tidal’s practice of using ‘album loudness normalisation’ and that has consequences if you don’t have the full album data. I assumed that would have been in Tidal’s metadata, but obviously not. So, when a song is being cached that doesn’t have album loudness data, why not just use it’s track loudness in the interim? At the risk of further assumptions, I gather that this is computed and sent back to Plex, so why not use ‘something’ other than ‘null’ until the data is complete?
I have to assume that the analysis of Tidal tracks happens and is then stored on Plex servers. Maybe it would be wise to suggest that Plex get to work on analyzing the entirety of the Tidal library. As it is Plex is basically relying on the user’s individual plays to facilitate the process. If a number of willing participants (likely a pretty large number to be effective) were to have a way to analyze portions of the Tidal library during maintenance hours, the same way analyzation is done on our personal libraries, then the majority of the Tidal library could be covered until it became simply a matter of maintenance to analyze newly added tracks. Just a thought. There are probably enough users who would be interested if this could be facilitated
At this point, we’re all making assumptions because of the closed source nature of the project. The issue can’t be insurmountable and all I want to hear is that a dev will at least look into it (because we can’t) and give it some consideration.
I didn’t really mean that the analysis was done ON our servers, but that it is reliant on us playing the tracks for analysis to occur. So I’ve edited my post.
If the analysis happens when tracks are played by users, then why can’t it be set to continuously “play” multiple tracks for analyzation, or in a “crowd sourced” manner where Tidal tracks are temporarily added to individual users (those who are willing to participate) libraries for analyzation (in the cloud, of course) ?
I’ll propose another suggestion if both local and remote processing are undesirable: fork and maintain at least a partial Tidal API which returns the required data & call it whenever a cached track does not have the required loudness data. From a quick search, there are a few open source NodeJS projects that have already reverse engineered the Tidal API:
Back to our assumptions - I assume that there’s already some work that’s had to occur here in order to stream the tracks in the first place. So I wouldn’t be surprised if much of the leg work has already been done here. Nevertheless, three possible solutions have now been proposed in this thread…
