Track Levelling
Posted by: surfer on 04 February 2015
I have mostly flac files, using media monkey, any negatives to letting this do its thing on my tracks to get them to as near to 90db?
Once you are only adding tags, there is no issue but Naim streamers can't read the tags (unless you use asset).
Actually changing the level of the track is bad bad bad.........
SJB
Agreed, definitely best avoided for the best SQ.
Naim streamers can't read the tags (unless you use asset).
Sorry John, I have not clear what you mean, can you elaborate more? Thank you.
Replay Gain support is IIRC not implemented by Naim streaming music players. There are two types: track-based (not so good) and album-based (best). Embedding the tags is a good idea (for future support); applying the processing, on the other hand, changes the data so that it is no longer bit-identical to the original.
Indeed so once the tags are present and you use a player that can apply them (Squeezebox) or a dnla server such as asset that can apply them at source end. The music file is not affected so you can turn off the levelling and listen to bit perfect. However if you have a play list and turn on the levelling all tracks whether recorded in 1965 or 2005 are played at roughly the same volume. Not bit perfect apparently but I'm damned if I can really hear much difference.
If you use n-serve, twonky or minimserver you can have all the replay gain tags in the world but neither the Naim streamer or the dnla server can process them.
SJB
Thank you John, I was not aware that exist a flag to set the reproduction volume at all (independently this will be recognized or not by dlna and/or streamer).
Is the user that need to deduce the volume or the "system" averaging it to a defined value?
Sorry for the asking, is somehow interesting.
Done correctly, it's a volume change only and it shouldn't alter the data in any way. However it needs an electronic volume control.
Done correctly, it's a volume change only and it shouldn't alter the data in any way. However it needs an electronic volume control.
AFAIK the interpretation and applying the Replay Gain is always done in the digital domain, so by manipulating the data and thereby loosing bits out of the original data.
Done correctly, it's a volume change only and it shouldn't alter the data in any way. However it needs an electronic volume control.
AFAIK the interpretation and applying the Replay Gain is always done in the digital domain, so by manipulating the data and thereby loosing bits out of the original data.
Yes. But it shouldn't be. It should simply be passed to the volume control.
If your source material is 16 bit, then applying replaygain to files which have been increased to 24 bits, should give enough room for a reduction in volume without quality loss (it is only reduction which looses quality).
Ideally Replaygain is applied by the player, if not possible then the UPnP server can do this.
90% of my tracks were ripped to flac using dbpoweramp and applying replay gain. I'm using synology nas with its own media server setup. Its really the other 10% of my tracks which will be mp3 at various bitrates. So seems like the general consensus is to leave well alone?
If your source material is 16 bit, then applying replaygain to files which have been increased to 24 bits, should give enough room for a reduction in volume without quality loss (it is only reduction which looses quality).
Ideally Replaygain is applied by the player, if not possible then the UPnP server can do this.
But it has to be played out as 24-bit files to the DAC then!
Which I believe need to be set explicitly on some software players / servers.
Applying ReplayGain don't make them automatically send out 24-bit files?
Aleg,
If the files are stored as 24bit, and the DLNA renderer declares that it can receive 24 bit data; then a DLNA server that can itself handle 24 bit data streams, should, by default, send them out as 24bit data streams.
Sending 24bit files out as 16bit data streams would require transcoding (either explicitly set, or by setting some form of 'compatibility mode').
Whilst this is how it should work ... in practice ... ?
Aleg,
If the files are stored as 24bit, and the DLNA renderer declares that it can receive 24 bit data; then a DLNA server that can itself handle 24 bit data streams, should, by default, send them out as 24bit data streams.
Sending 24bit files out as 16bit data streams would require transcoding (either explicitly set, or by setting some form of 'compatibility mode').
Whilst this is how it should work ... in practice ... ?
Hugh
This is a slightly different situation than mrSpoon was talking about and my comment was based on.
That was about 16-bit files expanded into 24-bit internally and then to apply the ReplayGain, which should give you 8 bits to play with before it becomes noticeable in data-loss. That assumes however that the result after applying ReplayGain is also sent out as 24-bit data.
And my comment was that one often/sometimes needs to set that behaviour inside the server / player software.
I know that with Asset one has to set a checkbox near the ReplayGain setting to indicate that the data should be sent out as 24-bits and no longer as 16-bits as the source material was.
If one is not aware of these settings and does not set them as 24-bit output, one will get data loss when applying ReplayGain to 16-bit source material.
Cheers
aleg
Hi Aleg,
Sorry, I misunderstood. I hadn't realised you were specifically talking about using replay gain within transcoding at the server. You are absolutely correct in that case.
Mind you it does illustrate the benefit and simplicity of doing it with the files!