MinimServer Forum

Full Version: ReplayGain
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13
(12-06-2016 10:13)Dieter Stockert Wrote: [ -> ]
(12-06-2016 05:01)krutsch Wrote: [ -> ]MinimServer as is stands today is very complete, flexible [...]. If you really want to take things to the next level [...]

MinimServer is very flexible. But the next level for me would be to make it easier to adjust. Right now the user interface may be alright for those who like command lines but not for the other folks who are used to make mouse clicks on drop down menues. But that would be a lot of work for Simon (maybe 10 lines of code for the pure functionality need 100 lines of code for a really good user interface).

For me, a user interface using a configuration file would be much more useful than new mouse and menu interfaces. That could be something like an INI file with one option value per line rather than a comma-separated list of multiple option values in a single line. Then it would be possible to see all options at the same time, make changes, save and test easily, and to make configuration backups or archive the configuration in an SCM like Subversion or Mercurial to keep a history.

Actually, this is nothing Simon needs to do. Anyone can supply an extra user interface by using the Scripting and Web API.
(12-06-2016 23:45)Servatius Wrote: [ -> ]For me as a listener of classical music it is not an issue to adjust the loudness once when I start listening to a long musical work with multiple movements. The variance in album gain values is not so big either. But pop music suffered from extreme compression due to the loudness war in the last two decades so that a collector of pop music may have quieter CDs from the 80s and much louder CDs bought more recently. It must be very annoying to change loudness all the time. For them, honouring ReplayGain in the transcoding process would be an important feature.

Thank you for seeing my problem :-)

(12-06-2016 23:45)Servatius Wrote: [ -> ]Simon, in case you decide to support this, I would have a question about effects of the ReplayGain processing on the sound quality: would it be possible to do the signal processing in high resolution (24 bit), at least when choosing a hires output format? And what about a DTS stream? Could they be processed without transcoding to PCM?

I'd also expect to have the transcoding done first in case of upsampling and then apply replay gain (Like Illustrate's AgentUPnP does - but I would apply the reverse order in case of downsampling I think). But I'm not sure what transcoding does to the metadata. Replay_gain, I believe, is not a tag universaly supported across all tagging standards. So, you may transcode and then lose the Replay_gain tag. If so, the correct order would be to collect that information first, then transcode, then level output.
Thanks for this feedback and all the useful suggestions.

I have always been doubtful about implementing this as a server-side feature. If the correct gain setting depends on whether the control point is using "shuffle (album)" mode or "shuffle (track)" mode, this implies that the control point (and possibly the renderer) need to be involved in selecting the correct gain setting.

In terms of when the gain adjustment is applied, if this is done as part of MinimStreamer ffmpeg transcoding, it would need to be applied to the input stream before this is upsampled or downsampled to produce the output stream. For example, if the input stream is 16 bits and the output stream is 24 bits, the gain adjustment would be applied to the 16-bit stream.

My conclusion is that the relatively simple server-side implementation that I had been considering would not meet the needs of users who want this feature. A player such as foobar2000 can provide a full-featured implementation because it provides the complete end-to-end serving/controlling/transcoding/rendering chain and this is the best option for users who require this functionality.
I see your point and understand the decision. So I thought about alternatives.

First of all, users like Pepsican owning albums with extremely different loudness levels can still improve their situation: In the original content directory, maintain all your audio files, tag them, and set the ReplayGain info. Then use a converter (like foobar2000's convert feature) to generate loudness-leveled versions of your files into a second content directory by applying album gain. Configure the converter to transfer metadata but not ReplayGain info (which you applied). The conversion will leave your original files untouched, but will put variants with identical tags but modified audio data into the extra directory tree. Then set MinimServer's contentDir option to the loudness-leveled content directory. Then your playlists from different albums are played with album-leveled loudness. The only thing you need is some extra disc space (cheap) and a couple of hours for the conversion (let your PC do this for you over night).

Never make any manual changes in the loudness-leveled directory tree. When adding new audio files or changing tags, always do this in your original master tree. When you are finished, run the conversion on the new or modified files to get or overwrite the loudness-leveled variants in the other directory. You also have the options to set the MinimServer contentDir temporarily back to the original directory in a phase of heavy tagging, or to run a modified conversion using track gain in the night before a party.
(17-06-2016 21:42)simoncn Wrote: [ -> ]I have always been doubtful about implementing this as a server-side feature. If the correct gain setting depends on whether the control point is using "shuffle (album)" mode or "shuffle (track)" mode, this implies that the control point (and possibly the renderer) need to be involved in selecting the correct gain setting.

So MinimServer may not be able to do anything useful at the moment for an existing combination of a control point and a renderer, but I am trying to find out what would be technically needed by a control point/renderer combination from the server in order to add a good ReplayGain support.

I am currently thinking
  1. how the tasks of selecting the correct gain value (album or track) and applying it to the audio could be assigned to the control point and the renderer,
  2. how the control point and/or renderer could communicate with the server to get access to the ReplayGain info stored in the original audio file.
For question 1, I see two possibilities:
  • The control point decides according to an option or by shuffle mode between album and track gain. Then it accesses the ReplayGain info and computes the correct loudness level. Then it tells the renderer about the loudness level to use. (BubbleUPnP and UPnPlay have a feature to change the renderer's output level via UPnP, although it does not work with the Naim network player. The Naim app has two buttons for changing the output level. The information is passed via WiFi to the Naim network player which passes it on via a cable to the amplifier, causing the loudness knob to be turned. So its seems to be possible for the control point to change the renderer's output level, either via UPnP for renderers which support it or via a proprietary interface.)
  • The control point decides according to an option or by shuffle mode between album and track gain. Then it passes the information which gain value to use to the renderer. (I don't know whether this can be done via UPnP, but the renderer's manufacturer could do so in their control point using a proprietary interface). The renderer then accesses the ReplayGain info and applies the gain value chosen by the control point before playing the audio stream.
Or shortly said, the control point decides between album and track gain, the renderer applies the gain value, but the question is whether the control point or the renderer retrieves the ReplayGain values stored in the audio file.

So for point 2 above I have some questions:
  • Is it technically possible for a UPnP server to supply ReplayGain info to the control point when the latter is browsing the media tree?
  • When the renderer plays the audio file, does it get the complete audio file including the ReplayGain info (provided that transcoding is not used) or does it only get the audio data? In the latter case, would it be technically possible to supply the ReplayGain info in a different way?

It is clear that as long as control points and renderers don't do such things nothing needs to be done in MinimServer. But owners of network players could ask the manufacturers for ReplayGain support. Manufacturers have a lot of (proprietary) possibilities for the control point/renderer combination. So if it were technically possible to access the ReplayGain info via UPnP, I would ask at the manufacturer of my equipment. It would be great if they could add a feature turning the amplifier's loudness knob according to the ReplayGain information. I mean, dreaming has often be the reason for innovation. Wink
This all makes sense to me. To answer your questions:

Quote:Is it technically possible for a UPnP server to supply ReplayGain info to the control point when the latter is browsing the media tree?

I don't think there is any UPnP standard property for passing this information.

Quote:When the renderer plays the audio file, does it get the complete audio file including the ReplayGain info (provided that transcoding is not used) or does it only get the audio data? In the latter case, would it be technically possible to supply the ReplayGain info in a different way?

If transcoding is not used, the ReplayGain information is available by reading the file's tag metadata.

If transcoding is used, the metadata is removed by MinimStreamer and the ReplayGain information is not available. In theory, MinimStreamer could insert the ReplyGain information but this would be a significant amount of work and could only be justified if there is some significant probability that it might be used by the renderer.
This means it would be the task of the renderer to extract the ReplayGain info from the audio stream and to adjust the loudness accordingly. The control point could tell the renderer whether to use album or track gain (at least the control point supplied by the renderer's manufacturer could do so), or the renderer could offer an option to select which gain to use.

So lets wait for renderers and control points actually doing this.

Thanks very much, Simon, for considering these things.
(19-06-2016 14:08)Servatius Wrote: [ -> ]This means it would be the task of the renderer to extract the ReplayGain info from the audio stream and to adjust the loudness accordingly. The control point could tell the renderer whether to use album or track gain (at least the control point supplied by the renderer's manufacturer could do so), or the renderer could offer an option to select which gain to use.

So lets wait for renderers and control points actually doing this.

Thanks very much, Simon, for considering these things.

There is another possibility. The control point could read the stream from the server and extract ReplyGain information before instructing the renderer to play the file (with suitable volume adjustment).
(18-06-2016 17:22)Servatius Wrote: [ -> ]I see your point and understand the decision. So I thought about alternatives.

First of all, users like Pepsican owning albums with extremely different loudness levels can still improve their situation: In the original content directory, maintain all your audio files, tag them, and set the ReplayGain info. Then use a converter (like foobar2000's convert feature) to generate loudness-leveled versions of your files into a second content directory by applying album gain. Configure the converter to transfer metadata but not ReplayGain info (which you applied). The conversion will leave your original files untouched, but will put variants with identical tags but modified audio data into the extra directory tree. Then set MinimServer's contentDir option to the loudness-leveled content directory. Then your playlists from different albums are played with album-leveled loudness. The only thing you need is some extra disc space (cheap) and a couple of hours for the conversion (let your PC do this for you over night).

Never make any manual changes in the loudness-leveled directory tree. When adding new audio files or changing tags, always do this in your original master tree. When you are finished, run the conversion on the new or modified files to get or overwrite the loudness-leveled variants in the other directory. You also have the options to set the MinimServer contentDir temporarily back to the original directory in a phase of heavy tagging, or to run a modified conversion using track gain in the night before a party.

I get what you mean, and I do that for my car stereo, which can't do ReplayGain. But it would effectively mean doubling my disk space for music files. So, there is a price tag attached to the workaround. And for some, it may mean upgrading the NAS itself rather than just add disks. It also goes against the suggested order of events: to first upsample and then apply the gain.
(17-06-2016 21:42)simoncn Wrote: [ -> ]I have always been doubtful about implementing this as a server-side feature. If the correct gain setting depends on whether the control point is using "shuffle (album)" mode or "shuffle (track)" mode, this implies that the control point (and possibly the renderer) need to be involved in selecting the correct gain setting.

In my mind we're overcomplicating things here. Make it a property maintained through MinimWatch. No need for complex automated decision making. Leave control to the end user. In my mind this is not a setting you'd want to tweak every few minutes.

(17-06-2016 21:42)simoncn Wrote: [ -> ]In terms of when the gain adjustment is applied, if this is done as part of MinimStreamer ffmpeg transcoding, it would need to be applied to the input stream before this is upsampled or downsampled to produce the output stream. For example, if the input stream is 16 bits and the output stream is 24 bits, the gain adjustment would be applied to the 16-bit stream.

Why does the gain need to be applied before ffmpeg does its magic? You could pick up the values for ReplayGain, prior to ffmpeg processing, and when the processed signal comes out of ffmpeg, apply the replay gain. My understanding is that this is what AssetUPnP does. True, it is not as easy but it is not undoable I think.

(17-06-2016 21:42)simoncn Wrote: [ -> ]My conclusion is that the relatively simple server-side implementation that I had been considering would not meet the needs of users who want this feature. A player such as foobar2000 can provide a full-featured implementation because it provides the complete end-to-end serving/controlling/transcoding/rendering chain and this is the best option for users who require this functionality.
Foobar2000 comes with its own problems. Most notably that it needs to run on a PC as there is no tablet, NAS or phone app. My playback chain is already complicated enough without yet another component to manage.
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13
Reference URL's