Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[GaryM44]

Just DL'd Media Center 17 today. Wanted it primarily to play FLAC files and send to HT system via DLNA. WAV and MP3 files play fine, but FLAC's are garbled. I've tried changing various settings in MC, but they don't matter --- result sounds the same no matter what. Even when set to "Always Convert" and using "16 bit no header" the result is the same.

The DLNA device is a Sony BDP S580 blu-ray player. It is connected via HDMI to a Denon AV-1712.

What settings matter here, and which ones should I use? It seems to be an MC problem, since even FLACs (supposedly) converted to 44.1/16 remain garbled.

Appreciate any help!

[MrC]

According to :

  http://www.dlna.org/consumer-home/look-for-dlna/product-search

your device does not support FLAC.  So you'll have to convert.  You might want to verify.

Did you restart MC after making the changes to Always Convert / 16 bit no header.

[GaryM44]

According to :

your device does not support FLAC.  So you'll have to convert.  You might want to verify.

Did you restart MC after making the changes to Always Convert / 16 bit no header.

Thanks MrC.

The device (the blu-ray player) plays SACDs and DVD-As. Should it not then support 96/24 audio? It doesn't support FLAC directly, of course, but the signal it receives should already be uncompressed (by the player) to 96/24 PCM. Right?

I've tried converting to 44.1/24 and it plays those just fine.

[GaryM44]

PS: I'm not sure whether I restarted the player after changing the conversion options. I was able to convert the FLACs with foobar. I'll try MC again.

[AndrewFG]

The device (the blu-ray player) plays SACDs and DVD-As. Should it not then support 96/24 audio? It doesn't support FLAC directly, of course, but the signal it receives should already be uncompressed (by the player) to 96/24 PCM. Right?

The UPnP/DLNA standard lossless format is called LPCM, also known as L16; this is a linear pcm format based on 16-bit samples that supports a choice of bitrates and channels: 44100hz, 48000hz, 1-channel, 2-channel are the most common, but 96000hz might also in theory be allowed. But since L16 is limited to 16-bit samples that rules out higher bit depths. So 96000hz 16-bit 2-channel might work but 96000hz 24-bit 2-channel is certainly not possible.

I've tried converting to 44.1/24 and it plays those just fine.

You sure? For the reasons stated above, I doubt it. (You probably have to 44100hz 16-bit 2-channel)

[GaryM44]

The UPnP/DLNA standard lossless format is called LPCM, also known as L16; this is a linear pcm format based on 16-bit samples that supports a choice of bitrates and channels: 44100hz, 48000hz, 1-channel, 2-channel are the most common, but 96000hz might also in theory be allowed. But since L16 is limited to 16-bit samples that rules out higher bit depths. So 96000hz 16-bit 2-channel might work but 96000hz 24-bit 2-channel is certainly not possible.

You sure? For the reasons stated above, I doubt it. (You probably have to 44100hz 16-bit 2-channel)

Quite sure. I even have WMP set to transcode at 24-bit (which it recommends). When playing the 24 bit files the blu-ray player displays 2.1 Mbps; when playing 16 bit files it shows 1.4 Mbps. It will not accept more than 2 channels or > 44.1 sampling rate at any bit depth over DLNA, however. (It will play 48K files, but with distortion).

[AndrewFG]

When playing the 24 bit files the blu-ray player displays 2.1 Mbps; when playing 16 bit files it shows 1.4 Mbps. It will not accept more than 2 channels or > 44.1 sampling rate at any bit depth over DLNA, however. (It will play 48K files, but with distortion).

Ok. So your player apparently has some smarts. There is nothing in the DLNA/UPnP protocol that could inform a player it is a 24-bit track as opposed to a 16-bit one; and the track is being sent as pcm rather than wav, so there is no riff header either. This means the player is parsing clues inside the audio stream itself. Cool. But still if it is clever enough to detect 44100hz 24-bit without external clues, it is surprising that it is not clever enough to handle 48000hz 16-bit where it does have such clues.

[bob]

MC will downmix to 2 channel over DLNA when you select "Always Convert" and then under advanced you can select "stereo downmix". You can also choose to set a fixed sample rate.
There are two 24 bit conversion formats, 24 bit wave and 24 bit LPCM. The wave has the riff header which has the format information for the renderer. The LPCM gives the sample rate info in the DLNA content directory information however I've not seen any devices that support 24 bit LPCM.

[AndrewFG]

The LPCM gives the sample rate info in the DLNA content directory information however I've not seen any devices that support 24 bit LPCM.

As you say the both rate and depth can be carried in the content directory res elements. However the problem is that for the HTTP server there is no mime-type or file header that could convey this information. The defined pcm mime-type for UPnP/DLNA is "audio/L16;rate=44100;channels=2" and the bit depth is implicitly hardwired in the "L16" rather than being provided like the "rate" and "channels" are.

If the UPnP/DLNA specification writers would have been more thoughtful, they would no doubt have defined a mime-type such as "audio/lpcm;rate=44100;channels=2;depth=24" ...  (And BTW so far as I know, there is no mime-type definition for "audio/L24")

So as it stands, the only way a UPnP/DLNA renderer could play at 24 bit depth is if the file is a) WAV (info in the RIFF header), b) AIFF (info in the AIFF header), or FLAC (info in the FLAC standard) -- But as you know none of those are UPnP/DLNA "must support" formats so the renderers that do support them are few and far between.

[bob]

As you say the both rate and depth can be carried in the content directory res elements. However the problem is that for the HTTP server there is no mime-type or file header that could convey this information. The defined pcm mime-type for UPnP/DLNA is "audio/L16;rate=44100;channels=2" and the bit depth is implicitly hardwired in the "L16" rather than being provided like the "rate" and "channels" are.

If the UPnP/DLNA specification writers would have been more thoughtful, they would no doubt have defined a mime-type such as "audio/lpcm;rate=44100;channels=2;depth=24" ...  (And BTW so far as I know, there is no mime-type definition for "audio/L24")

So as it stands, the only way a UPnP/DLNA renderer could play at 24 bit depth is if the file is a) WAV (info in the RIFF header), b) AIFF (info in the AIFF header), or FLAC (info in the FLAC standard) -- But as you know none of those are UPnP/DLNA "must support" formats so the renderers that do support them are few and far between.

I did see some references to audio/L24 when googling around so I implemented it in that fashion.
https://en.wikipedia.org/wiki/Internet_media_type#Type_audio
https://tools.ietf.org/html/rfc3190
"audio/L24;rate=44100;channels=2"
It will work with multichannel stuff too if the stereo downmix isn't selected.

Also note that the same info (i.e.) "audio/L24;rate=44100;channels=2" is passed in the HEAD and GET requests in the Content-Type header.

[AndrewFG]

I did see some references to audio/L24 when googling around so I implemented it in that fashion.
"audio/L24;rate=44100;channels=2"
Also note that the same info (i.e.) "audio/L24;rate=44100;channels=2" is passed in the HEAD and GET requests in the Content-Type header.

Ah. Interesting.

In the case that the source file has 24 bit depth, do you then offer two res elements (one with L16, and one with L24)? I assume you would have to, since I suppose that 95% of renderers can't handle 24 bit anyway...

[bob]

Ah. Interesting.

In the case that the source file has 24 bit depth, do you then offer two res elements (one with L16, and one with L24)? I assume you would have to, since I suppose that 95% of renderers can't handle 24 bit anyway...

Since we've run into several renderers that don't like multiple resource elements we don't implement it in that fashion. If one has a device which does support it one would create another server specifically for that device with the transcode settings for that device (in the Media Network, DLNA server configuration). Then if one was pushing to the device, they can associate the zone for the device with a specific server by right clicking on the zone and doing "Associate with DLNA Server"

[AndrewFG]

Since we've run into several renderers that don't like multiple resource elements we don't implement it in that fashion. If one has a device which does support it one would create another server specifically for that device with the transcode settings for that device (in the Media Network, DLNA server configuration). Then if one was pushing to the device, they can associate the zone for the device with a specific server by right clicking on the zone and doing "Associate with DLNA Server"

Cool.

[zamar29]

It will work with multichannel stuff too if the stereo downmix isn't selected.

Could you elaborate on that pls:

- what encoder do you use to transcode multichannel Flac to multichannel LPCM? As per its devs, FFMpeg doesn't have multichannel LPCM encoder, only Mono or Stereo. How do you check media info of the transcoded file?

- will DLNA standard allow to pass multichannel LPCM to a DLNA-compliant BD player?  Will it play such output? Does DLNA allow multichannel LPCM audio - with what parameters? Or you use UpNP protocol instead - but how do you let the player know?

I have a similar issue of trying to play 5.1 Flac music over LAN to Samsung BD-C6900 BD player by transcoding to 5.1 LPCM, and haven't found any solution yet. Is JRiver Server the right solution?

[bob]

Could you elaborate on that pls:

- what encoder do you use to transcode multichannel Flac to multichannel LPCM? As per its devs, FFMpeg doesn't have multichannel LPCM encoder, only Mono or Stereo. How do you check media info of the transcoded file?

We do it with our own code. It's not really transcoding, it's decoding...

- will DLNA standard allow to pass multichannel LPCM to a DLNA-compliant BD player?  Will it play such output? Does DLNA allow multichannel LPCM audio - with what parameters? Or you use UpNP protocol instead - but how do you let the player know?

The standard allows that but it would need to be implemented on the renderer. Whenever you supply LPCM via DLNA you need to provide the bit rate, number of channels, etc since there is no header on the LPCM.

I have a similar issue of trying to play 5.1 Flac music over LAN to Samsung BD-C6900 BD player by transcoding to 5.1 LPCM, and haven't found any solution yet. Is JRiver Server the right solution?

You might try converting to wave instead of LPCM, since it's got the header it's more likely to be supported by some devices. For example, I can send the WDTV a 24 bit wave but not 24 bit LPCM since it doesn't recognize the DLNA flags for anything other than 16 bit LPCM.

[AndrewFG]

For example, I can send the WDTV a 24 bit wave but not 24 bit LPCM since it doesn't recognize the DLNA flags for anything other than 16 bit LPCM.

Just out of interest, I would love to know what happens when you tell the player to do a Seek() ?

[bob]

Just out of interest, I would love to know what happens when you tell the player to do a Seek() ?

I'll give it a try and let you know!

[streamer95]

I have just installed J River MC17 and stream to an Oppo BDP 95 without any problems with FLAC & WAV files. No problems, that is, with 16 bit/44.1 and up to, and including  24 bit/96 kHz. However, when I play 24/176 or 24/192 files, it stutters at the start of each track for about 4 - 5 seconds then it plays normally. Occasionally, about once per album, it will also falter mid-track for a few seconds.
I am not sure if the problem is with the Oppo unable to buffer such large files or the MC17 software.  I am using WASAPI - Event style, "Never Convert", "Uncompressed", sample rate "Same as Source"  and 24 bit depth in DSP Studio. I have tried every "Hardware buffer size" buffering setting from 10 to 500 ms but it made little difference when it came to the file over 24/96.
I am disappointed that I am so close, but still having problems. I could always give up and use a USB cable between my laptop and the Oppo input, but I would rather DLNA stream as it is more convenient.
But to answer your problem, I have had no problems streaming FLAC up to 24/96 using MC 17 with the Oppo BDP 95.

[JimH]

The stuttering may just be a bandwidth issue.

[streamer95]

Hi Jim,
thanks for the reply.
Do you think the bandwidth issue is with my wireless router? I have a Billion 7400N router and I usually get download speeds of 12-14 Gb/s (from the Internet). I would have thought that a DLNA system which can wirelessly transfer 1080i video would have no problems with large audio files.
By the way, I like your "horse" - you must be saving a fortune on feed bills and vet costs ! 





 

[bob]

I have just installed J River MC17 and stream to an Oppo BDP 95 without any problems with FLAC & WAV files. No problems, that is, with 16 bit/44.1 and up to, and including  24 bit/96 kHz. However, when I play 24/176 or 24/192 files, it stutters at the start of each track for about 4 - 5 seconds then it plays normally. Occasionally, about once per album, it will also falter mid-track for a few seconds.
I am not sure if the problem is with the Oppo unable to buffer such large files or the MC17 software.  I am using WASAPI - Event style, "Never Convert", "Uncompressed", sample rate "Same as Source"  and 24 bit depth in DSP Studio. I have tried every "Hardware buffer size" buffering setting from 10 to 500 ms but it made little difference when it came to the file over 24/96.
I am disappointed that I am so close, but still having problems. I could always give up and use a USB cable between my laptop and the Oppo input, but I would rather DLNA stream as it is more convenient.
But to answer your problem, I have had no problems streaming FLAC up to 24/96 using MC 17 with the Oppo BDP 95.

The only settings that concern the DLNA streaming are in the DLNA server settings.
What are your audio conversion settings under the DLNA server settings? The default is to convert to mp3 for unsupported formats (via the DLNA spec, not the renderer device). This means that only L16 and MP3 will be sent unconverted by default.

[bob]

Just out of interest, I would love to know what happens when you tell the player to do a Seek() ?

It works (though it's somewhat slow to respond, takes 3 or 4 seconds). It's a bit surprising since the WD can't take the bitrate field.

[AndrewFG]

It works (though it's somewhat slow to respond, takes 3 or 4 seconds). It's a bit surprising since the WD can't take the bitrate field.

Interesting.

I was thinking that with PCM, a Seek can always work straight off, since the player is given the rate, channels, and bit depth along with the mime type in the Content-Type header, each time the player does an HTTP GET on the stream, also when the GET has a Range request with an offset from the stream beginning.

Whereas with WAV the Content-Type does not provide the rate, channels, and bit depth, and if the player sends a GET with a Range request offset from the stream beginning, this data is also not available within the stream itself, because it is only in the RIFF header at the start of the file. So I suppose that when your player responds to a Seek command it must first do a plain GET on the start of the stream (to get the RIFF header data), and then follow it by another GET with a Range header to get the music bits. (That probably explains why the Seek takes a few seconds...)

[bob]

Interesting.

I was thinking that with PCM, a Seek can always work straight off, since the player is given the rate, channels, and bit depth along with the mime type in the Content-Type header, each time the player does an HTTP GET on the stream, also when the GET has a Range request with an offset from the stream beginning.

Whereas with WAV the Content-Type does not provide the rate, channels, and bit depth, and if the player sends a GET with a Range request offset from the stream beginning, this data is also not available within the stream itself, because it is only in the RIFF header at the start of the file. So I suppose that when your player responds to a Seek command it must first do a plain GET on the start of the stream (to get the RIFF header data), and then follow it by another GET with a Range header to get the music bits. (That probably explains why the Seek takes a few seconds...)

I suspect you are correct, I don't know how it could do the seek otherwise. I've noticed at the "firmware" level that some of these linux based players are using either mplayer or vlc for playback and sometimes both depending on the content type...