Transcoding flac:wav odd sound

[Foxman50]

im using a Synology 212j to feed a naim streamer using nstream on ipad. Ive previously been using Synology's media server on the NAS to supply music. I use an old version DSM 3.2 build 1955 as this is the last version that supported transcoding of hiRes flac's to wav.

Anyway thought id try out Minimserver with Minimstreamer and have to say i like what i see and hear mostly. Very flexible, but to be honest ill never use most of its flexibility.

Sorry to my point, when i set transcoding = flac:wav i get a very dull sounding playback. Its like all the high frquencies have been stripped away and its lifeless. Changing to flac:wav24 sorts the issue out. There is definitely a slight difference between media server's playback and minimserver's playback when transcoding, even with Minimstreamer set to flac:wav24.

To be honest i wasnt expecting there to be a difference, as i thought one setting just converts flac to wav keeping bit depth and the other does the same but up samples everything to 24bit. I wondered what others have found and what the reasons maybe for the difference in sound quality im getting

[DavidHB]

(23-12-2013 12:28)Foxman50 Wrote:  Sorry to my point, when i set transcoding = flac:wav i get a very dull sounding playback. Its like all the high frquencies have been stripped away and its lifeless. Changing to flac:wav24 sorts the issue out. There is definitely a slight difference between media server's playback and minimserver's playback when transcoding, even with Minimstreamer set to flac:wav24.

To be honest i wasnt expecting there to be a difference, as i thought one setting just converts flac to wav keeping bit depth and the other does the same but up samples everything to 24bit. I wondered what others have found and what the reasons maybe for the difference in sound quality im getting.

This would be consistent with other reports, that the aural effect of particular types of transcoding will vary from system to system and from player to player. There are a number of threads on this forum that discuss different aspects of this issue. Simon's advice in the MinimStreamer User manual is:

"For best sound quality, it is recommended that you use the output sample bit depth that matches the maximum capabilty of your music player. For example, if your music player is a Linn DS, the best match is wav24. Results may vary with different types of music player."

I don't think that the cause of the variation is fully understood.

David

[Foxman50]

(23-12-2013 15:42)DavidHB Wrote:  This would be consistent with other reports, that the aural effect of particular types of transcoding will vary from system to system and from player to player. There are a number of threads on this forum that discuss different aspects of this issue. Simon's advice in the MinimStreamer User manual is:

"For best sound quality, it is recommended that you use the output sample bit depth that matches the maximum capabilty of your music player. For example, if your music player is a Linn DS, the best match is wav24. Results may vary with different types of music player."

I don't think that the cause of the variation is fully understood.

David

Thanks David for the reply. I think i was so surprised at the lack of detail coming from the flac:wav setting. Its probably my lack of knowledge on the subject, i just presumed both servers would sound identical. Think ill leave it on Minimserver for a few weeks see how it gets on.

[DavidHB]

(23-12-2013 16:26)Foxman50 Wrote:  I think i was so surprised at the lack of detail coming from the flac:wav setting ... i just presumed both servers would sound identical.

We need to be careful here, I think. In my opinion (there are users on the forum who would disagree), servers don't 'sound' at all. It is the renderers supplied by the server that do the sounding. While certain interactions between the server, the renderer and the network that connects them may have an effect on perceived sound quality (though whether and how this happens is, except in the case of obvious malfunctions, somewhat difficult to determine), I'd say that sound quality is primarily driven by the renderer, including the DAC and the analogue chain of sound reproduction.

In part I say this because I do make a distinction between serving and transcoding functions. The server is, for present purposes, the device (Hardware/OS/MinimServer) which implements the provider end of the UPnP AV protocol, which is device and format independent. So the server, which simply (!) provides data, is rather unlikely to have any sound quality of its own. Transcoding, on the other hand, is typically done for reasons of sound quality. I think that you were comparing the output of different transcoders, rather than different servers.

With that in mind, it is not surprising that you had different results from different levels of transcoding (did you by any chance compare the results of transcoding with the output when transcoding is switched off?). I assume that your Naim can render 24 bit streams; if so, you ought to get the best results from MinimStreamer at the 24 bit setting, and, from what you say, this is indeed what happens.

In case it is of interest, I tried A/B tests playing the same tracks through my DNLA Server (ReadyDNLA, which is essentially the same as miniDNLA) providing a FLAC file, and MinimServer/MinimStreamer with flac:wav24 transcoding enabled. The differences were subtle but insistent; the MinimStreamer presentation was, to my ears, clearer, better balanced and more spacious. Comparing this result with other reports on this forum, I'd attribute the difference entirely to the effects of transcoding.

If you are as happy with MinimStreamer at the wav24 setting as you were with the Synology Server, it makes sense to stick with MinimStreamer/MinimServer, because, from what you say, it has much better future proofing than the Synology. My experience also suggests that you could well come to value some of the features that are currently of little interest.

David

[Foxman50]

(23-12-2013 19:05)DavidHB Wrote:  We need to be careful here, I think. In my opinion (there are users on the forum who would disagree), servers don't 'sound' at all. It is the renderers supplied by the server that do the sounding. While certain interactions between the server, the renderer and the network that connects them may have an effect on perceived sound quality (though whether and how this happens is, except in the case of obvious malfunctions, somewhat difficult to determine), I'd say that sound quality is primarily driven by the renderer, including the DAC and the analogue chain of sound reproduction.

In part I say this because I do make a distinction between serving and transcoding functions. The server is, for present purposes, the device (Hardware/OS/MinimServer) which implements the provider end of the UPnP AV protocol, which is device and format independent. So the server, which simply (!) provides data, is rather unlikely to have any sound quality of its own. Transcoding, on the other hand, is typically done for reasons of sound quality. I think that you were comparing the output of different transcoders, rather than different servers.

With that in mind, it is not surprising that you had different results from different levels of transcoding (did you by any chance compare the results of transcoding with the output when transcoding is switched off?). I assume that your Naim can render 24 bit streams; if so, you ought to get the best results from MinimStreamer at the 24 bit setting, and, from what you say, this is indeed what happens.

In case it is of interest, I tried A/B tests playing the same tracks through my DNLA Server (ReadyDNLA, which is essentially the same as miniDNLA) providing a FLAC file, and MinimServer/MinimStreamer with flac:wav24 transcoding enabled. The differences were subtle but insistent; the MinimStreamer presentation was, to my ears, clearer, better balanced and more spacious. Comparing this result with other reports on this forum, I'd attribute the difference entirely to the effects of transcoding.

If you are as happy with MinimStreamer at the wav24 setting as you were with the Synology Server, it makes sense to stick with MinimStreamer/MinimServer, because, from what you say, it has much better future proofing than the Synology. My experience also suggests that you could well come to value some of the features that are currently of little interest.

David

Unfortunately too keep Minimserver requires me to do a lot of retagging to make things look as i like it. Mp3Tag if a fantaastic piece of software so its not too much work. But this leads me onto another point of confusion.

Im told that the control point, my nstream app i believe, decides what it receives in the way of tagging information from upnp server. But if this is the case why does the diplay on my ipad have different information on it with Minimserver than it did with media server. Oh well ill add it to the very long list of things i dont get. It grows longer by the day.

Thanks for your help

Regards Graeme

[DavidHB]

(23-12-2013 21:21)Foxman50 Wrote:  Unfortunately too keep Minimserver requires me to do a lot of retagging to make things look as i like it. Mp3Tag if a fantaastic piece of software so its not too much work.

And, if my experience is anything to go by, the effort is worthwhile; you only have to retag each track once ...

Quote:I'm told that the control point, my nstream app i believe, decides what it receives in the way of tagging information from upnp server. But if this is the case why does the diplay on my ipad have different information on it with Minimserver than it did with media server.

Your understanding is not correct. The browse tree (that is the set of music file information made available to the control point - n-Stream in your case) is determined and provided by the server. Some control points do their own thing (for example, they cache the browse tree at their end rather than accessing it directly on the server), but this is not what the standard specifies. Control points do of course determine how the browse tree is presented to the user, but do not (if they are standards compliant) determine its content.

UPnP AV does not specify which information should be used for browsing. MinimServer provides an almost unlimited range of options for users to configure the tree for their own purposes; you can choose, for instance, which tags are indexed (and so can be used for browsing), and how tags appear in your Control Point. So not only does MinimServer have (by default) a different browse tree from other servers; each implementation of MinimServer (including separate implementations on the same network) can itself be different.

I think that your Synology Media Server is a DNLA rather than a UPnP server. The underlying system is the same for both (DNLA is in part based on the UPnP protocol), but DNLA servers have (in my experience) a common, and much more restricted, browse tree, and do not provide options to change this. I assume that this restriction is part of the DNLA specification, but can't be sure as the specification is not published. DNLA is designed to be used in a wide range of consumer products, so limitations of this kind are a necessary part of the way it works. Unfortunately, for serious users of digital media and the associated metadata (for example, classical music fans who wish to browse files by composer), this approach is far too restrictive.

Interestingly, I find that DNLA control points and players/renderers can see and use the MinimServer browse tree. n-Stream is in any case a UPnP control point, so is better matched to MinimServer than to a DNLA server.

I hope that this explains things.

David

[Foxman50]

(23-12-2013 22:31)DavidHB Wrote:  Your understanding is not correct. The browse tree (that is the set of music file information made available to the control point - n-Stream in your case) is determined and provided by the server. Some control points do their own thing (for example, they cache the browse tree at their end rather than accessing it directly on the server), but this is not what the standard specifies. Control points do of course determine how the browse tree is presented to the user, but do not (if they are standards compliant) determine its content.

UPnP AV does not specify which information should be used for browsing. MinimServer provides an almost unlimited range of options for users to configure the tree for their own purposes; you can choose, for instance, which tags are indexed (and so can be used for browsing), and how tags appear in your Control Point. So not only does MinimServer have (by default) a different browse tree from other servers; each implementation of MinimServer (including separate implementations on the same network) can itself be different.

I think that your Synology Media Server is a DNLA rather than a UPnP server. The underlying system is the same for both (DNLA is in part based on the UPnP protocol), but DNLA servers have (in my experience) a common, and much more restricted, browse tree, and do not provide options to change this. I assume that this restriction is part of the DNLA specification, but can't be sure as the specification is not published. DNLA is designed to be used in a wide range of consumer products, so limitations of this kind are a necessary part of the way it works. Unfortunately, for serious users of digital media and the associated metadata (for example, classical music fans who wish to browse files by composer), this approach is far too restrictive.

Interestingly, I find that DNLA control points and players/renderers can see and use the MinimServer browse tree. n-Stream is in any case a UPnP control point, so is better matched to MinimServer than to a DNLA server.

I hope that this explains things.

David

David, thank you very much for your response. You've explained things very clearly. Ive already started retagging as the more you play with Minimserver the more you realise what it can do for you.

Regards Graeme