Print

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

[AndrewFG]

I am starting to build up some 96kHz/24bit tracks in my library; although the majority is still 44.1kHz/16bit; and (for iTunes compatibility) the tracks are ALAC M4A encoded.

Given this format profile, I find that neither "Always Convert" L16 nor "Always Convert" L24 are really suitable all the time. Ideally, the 16 bit tracks should be served in L16 and the 24 bit in L24. However if you would have "Always Convert" to Flac, then this would serve both bit depths equally without argument.

=> May I request that you add "Always Convert" to Flac as one of the options for the DLNA server?

=> And/Or alternatively "Always Convert" to L16/L24 depending on the bit depth...

[Matt]

Why not always serve L24?

[AndrewFG]

Why not always serve L24?

To answer your question: I guess my only objection is that it would create a lot of excess network traffic.

Let me now add another (better) suggestion: Instead of "always convert" perhaps you should have a setting "Automatic". In this automatic mode, MC would retrieve the renderer's capabilities via GetProtocolInfo.SinkProtocol and serve the track in whatever format has the highest common denominator of samplerate & bitdepth between the original source file and the renderer's capabilities.

[AndrewFG]

Why not always serve L24?

And another point: Are there actually any renderers out there that can play L24? I know that there are many that support HiDef flac. So IMHO converting to flac would be a better way to go than converting to L24...

[bob]

It's referenced but I've not seen any implementations yet. It's pretty much 24 bit wave support that I see.

[AndrewFG]

It's referenced but I've not seen any implementations yet. It's pretty much 24 bit wave support that I see.

Personally I still think your conversion options should be more extensive, and they should handle lossy and lossless file format classes differently, where each format class should have several options. My proposal would be like this:

a) Lossless tracks (source file format: alac, flac, wav, aif, wmal, ogg, ...)
    [ ] Don't convert
    [ ] Always convert - L16 No Header
    [ ] Always convert - Flac (insofar as source file format is not flac)
    [ ] Always convert - L24 With Header (also known as wav)
    [ ] Automatic conversion based on the respective player's GetProtocolInfo response

b) Lossy Formats (source file format: aac, mp3, wma, ...)
    [ ] Don't convert
    [ ] Always convert - L16 No Header
    [ ] Always convert - Mp3  (insofar as source file format is not mp3)
    [ ] Automatic conversion based on the respective player's GetProtocolInfo response

WARNING: Technical Stuff Follows:

Note that the reason why I push for the Always Convert Flac (and indeed Always Convert Mp3) is that these formats allow the server to push the stream with whatever bit rate, bit depth and channel count that the source file is in.

You just offer one mime type audio/x-flac (or audio/mpeg), you don't need to mess with rate= and channels= parameters, or L16 and L24 bit depth mime types; with the one mime type you can serve any combination of rate/channels/bitdepth, and the player should be able to sort out how to play it.

Obviously since Flac (and Mp3) use compression, there are a few niggly details that your server has to master. Namely 1) how to determine the ContentLength before you have transcoded the file (so that the player can support seek via Range:bytes). And 2) how the server does actually serve a Get request with a Range:bytes header.

In my case (Whitebear) I solve 1) by transcoding to Flacs with zero compression (in which case ContentLength is determinate and calculable) and by transcoding to Mp3s with Constant Bit Rate. And I solve 2) by translating the Get Range:bytes header value into a time offset, based on the duration and the ContentLength calculated in 1) above, and then calling the respective transcoder application with a time skip or jump switch. (Or if the track has already been transcoded into cache then I just serve from cache from the respective byte offset...)

EDIT: I should add that when MC is offering a ContentDirectory (via CD:Browse or CD:Search) it should obviously offer a wider choice or resource formats including L16, Mp3, Native, and (IMHO) Flac. And obviously the server should be able to honour all of those offers if a client makes a pull request for that format. The above comments concerning Always Convert would only apply to the case when the the server is pushing a track via Play To (SetXXAvTransportUri).

[bubbleguuum]

You just offer one mime type audio/x-flac (or audio/mpeg), you don't need to mess with rate= and channels= parameters, or L16 and L24 bit depth mime types; with the one mime type you can serve any combination of rate/channels/bitdepth, and the player should be able to sort out how to play it.

L16 is still required as it is the only lossless format that some DLNA devices support (since it is required by DLNA).
L16 is also appropriate for streams with no known length (eg Internet radio). WAV is not since the header specify a data length (4Gb max). Not sure
how FLAC behave regarding unbounded streams.

As for L24, nothing supports it that I know of, and I never could find a spec on how samples are arranged.
In other terms, it is like it doesn't exist...

[AndrewFG]

L16 is still required as it is the only lossless format that some DLNA devices support (since it is required by DLNA).

Yes. That is why I explicitly mentioned L16 in my earlier post.

L16 is also appropriate for streams with no known length (eg Internet radio).

Sort of. The server obviously must take care to always send data starting at a frame boundary (4 bytes in case of 16bit/2ch, or 6 bytes in case of 24bit/2ch etc.) otherwise the render plays nice white noise.

WAV is not since the header specify a data length (4Gb max).

Indeed. And the RIFF header also carries the bit depth, sample rate and channel info, which are essential too. The same applies for AIF (slightly different header format, and opposite byte order).

Not sure how FLAC behave regarding unbounded streams.

Flac does also have a header prefix which includes a field called Estimated File Size. However if the estimated size is zero (or indeed not zero) then it can also be ignored. Most transcoder applications start by writing zero in the size estimate, and after completing the transcoding, if they are writing to a disk file, they go back and overwrite the size estimate with the actual value. However if the transcoder application is writing to a stream or to StdOut, then it obviously is clever enough to not try to do that :-)

The other important thing concerning Flac is that on Get's with a Range: bytes offset, the server should ideally also start sending data aligned to a Flac frame boundary (analog to L16 frame alignment above). However the start of a Flac frame is marked by a unique byte code, so a renderer can (indeed should) ignore any trash from the server until it encounters the first clean Flac frame. In my experience most renderers do this. By the way, basically the same logic applies for Mp3 files too. This means that Flac (and Mp3) are relatively immune to frame alignment errors, because in the worst case they may "play" just one trash frame before they get realigned. This is quite different from L16, L24, Wav or Aif, where if the renderer starts with an alignment error it will remain non aligned forever....

As for L24, nothing supports it that I know of, and I never could find a spec on how samples are arranged.
In other terms, it is like it doesn't exist...

See RFC3190 chapter 8.3 http://tools.ietf.org/html/rfc3190
Basically, (to make it simple), when you use it to transport linear PCM data, it is exactly like L16 but each sample consists of 3 bytes instead of 2 bytes.

[bob]

It's referenced but I've not seen any implementations yet. It's pretty much 24 bit wave support that I see.

I'm quoting myself

Found the first commercial device that claims L24 support. An Audio Research Reference DAC. Here is the pertinent sink info:

http-get:*:audio/L24;rate=44100;channels=1:DLNA.ORG_PN=LPCM,
http-get:*:audio/L24;rate=44100;channels=2:DLNA.ORG_PN=LPCM,
http-get:*:audio/L24;rate=48000;channels=1:DLNA.ORG_PN=LPCM,
http-get:*:audio/L24;rate=48000;channels=2:DLNA.ORG_PN=LPCM,
http-get:*:audio/L24;rate=96000;channels=1:DLNA.ORG_PN=LPCM,
http-get:*:audio/L24;rate=96000;channels=2:DLNA.ORG_PN=LPCM,
http-get:*:audio/L24;rate=88200;channels=1:DLNA.ORG_PN=LPCM,
http-get:*:audio/L24;rate=88200;channels=2:DLNA.ORG_PN=LPCM,
http-get:*:audio/L24;rate=192000;channels=1:DLNA.ORG_PN=LPCM,
http-get:*:audio/L24;rate=192000;channels=2:DLNA.ORG_PN=LPCM,

It also does SetNext and actually transitions gaplessly but there are some other issues with the firmware that need fixing.

[doulos]

EDIT: I should add that when MC is offering a ContentDirectory (via CD:Browse or CD:Search) it should obviously offer a wider choice or resource formats including L16, Mp3, Native, and (IMHO) Flac. And obviously the server should be able to honour all of those offers if a client makes a pull request for that format. The above comments concerning Always Convert would only apply to the case when the the server is pushing a track via Play To (SetXXAvTransportUri).

you mean, MC should behave like a real UPnP/DLNA server ? I have made this request elswhere before. To repeat myself: currently, MC assumes a hard-wired connection between server and renderer, i.e. you essentially have to create a server for each renderer device with the appropriate transcoding settings. This goes against the idea of UPnP, where the control point should do the matching between the renderer and the server capabilities. I therefore requested, that there at least be an option to configure a server such that it provides resources for ALL transcodeable formats, leaving it to the CP to make the choice. That request was turned down (for now)

chris

[AndrewFG]

... the control point should do the matching between the renderer and the server capabilities.

Indeed. (Seconded).

I therefore requested, that there at least be an option to configure a server such that it provides resources for ALL transcodeable formats, leaving it to the CP to make the choice.

That would be a start. However in the case of MC being both server and CP, it is not sufficient to meet your "the CP should do the matching" requirement.

Actually there are several requirements of MC for its server and CP functions:

Requirements on MC as a Server

1) Its Browse and Search responses should (as you say) contain resources for ALL formats it can serve.

2) Its GetProtocolInfo::SourceProtocolInfo response argument should contain the list of all the above formats.

Requirements on MC as a Control Point

3) Before trying to push a track to the Renderer (Play To) it should query the renderer's GetProtocolInfo::SinkProtocolInfo

4) Its SetAvTransportUri (and SetNextAvTransportUri) commands should pass the url of the resource having the highest audio or video resolution that is common to both Server::GetProtocolInfo::SourceProtocolInfo and Renderer::GetProtocolInfo::SinkProtocolInfo

[bubbleguuum]

1) Its Browse and Search responses should (as you say) contain resources for ALL formats it can serve.

At the very least it should always provide a WAV and LPCM stereo resource in either 44.1 or 48Khz.
Since at least one of these resource is almost guaranteed to be playable by any renderer, as renderers
almots always support WAV or LPCM or both.

[doulos]

2) Its GetProtocolInfo::SourceProtocolInfo response argument should contain the list of all the above formats.

Requirements on MC as a Control Point

3) Before trying to push a track to the Renderer (Play To) it should query the renderer's GetProtocolInfo::SinkProtocolInfo

4) Its SetAvTransportUri (and SetNextAvTransportUri) commands should pass the url of the resource having the highest audio or video resolution that is common to both Server::GetProtocolInfo::SourceProtocolInfo and Renderer::GetProtocolInfo::SinkProtocolInfo

well put, now we have everything as explicit as it can get. I think requirement 2) above is already met today. I personally am more interested in the server part, because I am implementing a control point myself, which works as you describe.

Bob, will this be on the agenda for MC somewhere down the road?

[AndrewFG]

At the very least it should always provide a WAV and LPCM stereo resource in either 44.1 or 48Khz.
Since at least one of these resource is almost guaranteed to be playable by any renderer, as renderers
almots always support WAV or LPCM or both.

Weell, you see the thing is that Squeeze players do not natively support either WAV or L16; but they do support FLAC natively; which means that current versions of Whitebear have to transcode incoming WAV or L16 to FLAC. So we have the dumb situation where MC transcodes (say) ALAC to L16, and then Whitebear converts L16 to FLAC, which the Squeeze player then plays natively. This is the reason why I ask if MC can have an option to serve FLAC directly. At least in my case, it would save a whole lot of bit churning on the other side...

[bob]

This is a great discussion and I've got a list of DLNA things to do about a mile long.
The thing is all of the server work has to be finished first.
Hopefully that will be done within the next week.