Upsampling to 176.4/192 and transcoding

[Alekz]

How difficult possible is it to implement 2x/4x upsampling feature?

For example:

from 44.1 to 88.2 and 176.4
from 88.2 to 176.4
from 48 to 96 and 192
from 96 to 192

The improvement (along with 16->24bit conversion) is subtle, but still noticeable.

The simplest solution would be to spawn an external program - sox, which is available for every OS. Or even add a new config file for transcoding/conversions with SOX/mac/flac command lines (less programming). So, whether this feature is needed or not, MinimServer will stay as compact as possible, yet will support more formats (e.g. APE, WV, etc.)

[simoncn]

(28-12-2012 01:50)Alekz Wrote:  How difficult possible is it to implement 2x/4x upsampling feature?

For example:

from 44.1 to 88.2 and 176.4
from 88.2 to 176.4
from 48 to 96 and 192
from 96 to 192

The improvement (along with 16->24bit conversion) is subtle, but still noticeable.

The simplest solution would be to spawn an external program - sox, which is available for every OS. Or even add a new config file for transcoding/conversions with SOX/mac/flac command lines (less programming). So, whether this feature is needed or not, MinimServer will stay as compact as possible, yet will support more formats (e.g. APE, WV, etc.)

Minimserver currently supports transcoding from FLAC to WAV, with optional 16->24 bit padding of audio samples.

The next step is to extend this to other transcoding combinations, such as FLAC to L16 and ALAC to WAV. I've had user requests for both of these.

I've been doing some prototyping of using an external converter to add more transcoding combinations (including the above), and I've got an early prototype working with ffmpeg or libav as the converter. It shouldn't be very difficult to add sox as another converter option.

I haven't done any work on upsampling yet. I'm using an upsampling player (Linn DS), so I suspect this wouldn't provide any benefit in my system. It might be useful for other users, though.

It isn't possible to use an external converter to add support to MinimServer for filetypes that MinimServer doesn't understand. This is because MinimServer needs to read the audio information and tag data for all files in the user's library.

For playback with transcoding (or upsampling), the need to support file seeking means that MinimServer needs to understand both the original format and the transcoded/upsampled format.

I'm still experimenting with some aspects of this, so it's hard to say at this stage when it will be released. I hope I'll have something ready to release in the fairly near future.

[Alekz]

When your player upsamples or does any conversions/transcodings it uses the internal CPU and the internal power supply, what eventually will affect the sound (via EMI or power contamination). So it might be better to offload all calculations to an external device. I tried upsampling in SqueezeServer via sox and got some slight but consistent improvements in clarity/noise floor/glare.

Interesting thing is that the servers "sound" differently. We compared PS Audio eLyrics server, foobar2000 and Minim servers with transcoding and got different (sonically) results. I prefer Minim (a bit brighter, but in my system it sounds a tad more dynamic and involving). My wife said that eLyrics is more dull but may sound more coherent but also you can easily ignore the music. Foobar2000 is somewhere in between. The sonic differences also confirmed by PS-Audio forum members.

I know that eLyrics uses ffmpeg to transcode to WAV. And I'm not sure if it's possible to transcode FLAC into different WAVs, since FLAC is lossless and bit-perfect.

[simoncn]

(28-12-2012 15:11)Alekz Wrote:  When your player upsamples or does any conversions/transcodings it uses the internal CPU and the internal power supply, what eventually will affect the sound (via EMI or power contamination). So it might be better to offload all calculations to an external device. I tried upsampling in SqueezeServer via sox and got some slight but consistent improvements in clarity/noise floor/glare.

Interesting thing is that the servers "sound" differently. We compared PS Audio eLyrics server, foobar2000 and Minim servers with transcoding and got different (sonically) results. I prefer Minim (a bit brighter, but in my system it sounds a tad more dynamic and involving). My wife said that eLyrics is more dull but may sound more coherent but also you can easily ignore the music. Foobar2000 is somewhere in between. The sonic differences also confirmed by PS-Audio forum members.

I know that eLyrics uses ffmpeg to transcode to WAV. And I'm not sure if it's possible to transcode FLAC into different WAVs, since FLAC is lossless and bit-perfect.

MinimServer provides the option to transcode FLAC to either 16-bit WAV or 24-bit WAV. In your listening tests, did you try MinimServer with 16-bit WAV or 24-bit WAV?

MinimServer is using the JFLAC library to do the transcoding. I've checked that the audio signature of the transcoded WAV file matches the audio signature of the original FLAC file.

I'm not convinced that EMI or power issues would affect the sound of the transcoded data. I think any differences are more likely to be caused by transcoding algorithms or by differences in how network packets are transmitted.

[Alekz]

I used WAV24 and 24/96 files in the comparison tests.

[Alekz]

(28-12-2012 16:27)simoncn Wrote:  I'm not convinced that EMI or power issues would affect the sound of the transcoded data. I think any differences are more likely to be caused by transcoding algorithms or by differences in how network packets are transmitted.

Interesting, I would say quite the opposite ;-) The transcoding algorithms should produce absolutely identical result (WAV -> FLAC -> WAV) and TCP makes sure that all packets arrive undamaged and in the correct order.

But EMI and power supply "sags" are unavoidable and measurable if the CPU is highly loaded. E.g. "top" shows 20-40% CPU load difference between WAV and FLAC decoding.

[simoncn]

(28-12-2012 17:22)Alekz Wrote:  Interesting, I would say quite the opposite ;-) The transcoding algorithms should produce absolutely identical result (WAV -> FLAC -> WAV) and TCP makes sure that all packets arrive undamaged and in the correct order.

But EMI and power supply "sags" are unavoidable and measurable if the CPU is highly loaded. E.g. "top" shows 20-40% CPU load difference between WAV and FLAC decoding.

A difference in CPU load on the NAS doesn't seem likely to make a difference to the music quality produced by the renderer. If this does make a difference, the reason must be that the extra CPU load on the NAS is making a difference to how the NAS transmits packets across the network to the renderer (e.g., packet sizes, retransmissions, window flow control, etc.).

My comment about different algorithms was intended as a reference to things like zero padding of 16-bit FLAC data to produce 24-bit WAV data.

[Alekz]

Not the CPU on the NAS, but the CPU on the player. E.g. Logitech Transporter, PS Audio PerfectWave DAC or Linn DS.

[Alekz]

I do not think that window/packet size will be affected in a local 100/1000Mbit network. The most vulnerable is 24/192, of course, but still well within switchable Ethernet LAN limits. The bottleneck here is the disk (and the disk interface) and the CPU of the server. For example, a USB connected disk, or a server running on a busy Windows box. Then WiFi.

[simoncn]

(28-12-2012 20:54)Alekz Wrote:  Not the CPU on the NAS, but the CPU on the player. E.g. Logitech Transporter, PS Audio PerfectWave DAC or Linn DS.

I think I misunderstood your earlier comment. MinimServer already transcodes on the NAS, which removes CPU load from the player. I thought you were suggesting that this transcoding should be moved to another device to remove CPU load from the NAS. My apologies for the misunderstanding.