INTERACT FORUM
Networks and Remotes => Media Network => Topic started by: ThierryNK on March 20, 2013, 07:34:14 am
-
Hi
Is there (or will there be) a way to setup conversion for some type of files and not for others?
My concern comes from a library containing Flac PCM files and SACD files and a non-DSD network player.
If I setup "never convert", SACD files are not playing, of course.
If I setup "always convert"
If I setup 24 bits/sampling rate = 176 KHz, it works for SACD, but all my tracks are upsampled to 24/176 and I do not want this.
Samplig rate same as source does not work either, of course, for SACD.
"Convert unsupported files" may be a solution, but when I have tried it , my Flac PCM track were also converted.
Is there a way to declare somewhere what are the supported/unsupported files?
So currently I am using Foobar serving only SACD tracks, as the basis of my JRiver Library. Foobar makes the conversion from DSD to PCM, and provide the "fake" sample rate of 2822400 which allows me to sort SACD from standard PCM tracks.
But I wish to use JRiver only, with a standard library and not based on another UPNP server.
Best and kind regards
Thierry
-
It would also be very nice to have this level of control for video conversion as well.
-
Hi ,
I had also with my Xbox problem, can't stream videos to my TV, I tried ArkMC app on Android it works well. This app helped me
Hi
Is there (or will there be) a way to setup conversion for some type of files and not for others?
My concern comes from a library containing Flac PCM files and SACD files and a non-DSD network player.
If I setup "never convert", SACD files are not playing, of course.
If I setup "always convert"
If I setup 24 bits/sampling rate = 176 KHz, it works for SACD, but all my tracks are upsampled to 24/176 and I do not want this.
Samplig rate same as source does not work either, of course, for SACD.
"Convert unsupported files" may be a solution, but when I have tried it , my Flac PCM track were also converted.
Is there a way to declare somewhere what are the supported/unsupported files?
So currently I am using Foobar serving only SACD tracks, as the basis of my JRiver Library. Foobar makes the conversion from DSD to PCM, and provide the "fake" sample rate of 2822400 which allows me to sort SACD from standard PCM tracks.
But I wish to use JRiver only, with a standard library and not based on another UPNP server.
Best and kind regards
Thierry
-
This functionality is present for conversion for portable devices, where you can enter specific file types that are supported, and then Media Center will only convert file types that are not in the supported list.
I am having a need for the requested functionality in DLNA because an MP3 conversion to Uncompressed is sounding horrible. I can't believe it, but I am switching to a DLNA server version that is just Mpeg audio for a few songs that I only have on MP3 because when it gets to the Roku Soundbridge as a .wav playback the vocals sound scratchy.
-
In "theory" the idea of DLNA is that the DLNA Players specifies what formats it accepts as a part of the handshake. Ideally, MC should only have to convert stuff that is not supported...(eg "Convert unsupported") but also gives you two other options (Always and Never) to help cater for when devices are not so accurate in what is supported or not.
More info - http://www.dlna.org/dlna-for-industry/digital-living/how-it-works/technical-overview
-
This reminds me a little story.
A man is in a balloon and is lost in the fog. So he gets down at some meters above ground and sees someone:
- Hello there!
- Yes
- Coud you please tell me where I am?
- you are in a balloon, 5 meters above ground
- oh, you may be an engineer!
- yes, how do you know
- you give a perfect but totally useless answer to a simple question
- oh you may be a manager
- yes, how do you know?
- you do not no know where you are and where you go, and in 5 seconds it will be my fault.
-
The idea of some kind of table of what to convert is not new (this was looked at during the initial testing for DLNA and Video). Unless Bob has come up with a new idea of how to handle the complexity of how it identify per DLNA renderer what very large possible combinations of Container and Codec (both Audio and Video) are supported and if not supported to converted to what Container/Codec I don't see it happening. This lead me to realise that DLNA is a bit like a Swiss Army knife, great and lots of things but certainly not the best tool for any one task.
I have also given up on relying on using a single generic DLNA profile as each device has its own quirks. Even with different DLNA profiles, I find that "Convert Unsupported" will still yield some combinations of Container/Codec that fail to play when streamed as unconverted. I've now (typically) moved to individual profiles that I then use "convert always" to a format that the DLNA renderer "likes" the best and MC server can transcode on the fly. Once some additional improvements are made, I also play to generate a separate generic "Streaming" library so that the conversion can be done off line (for me HDD space is cheap).
From your OP, it would seem to me you will get the most mileage from using the "Convert Unsupported" and either live with the upsampling (Can you really tell the difference anyway) or create a version of the FLAC/PCM tracks in your library to a format that does not require a conversion during the DLNA process.
-
When I opened this thread, it was about DSD files.
Transcoding them as wave files with sampling "same as source" does not work, of course.
Transcode them always to 24/176 does not fit my needs, as upsampling makes big differences on 44/48/96 files, at least on High End Audio Systems.
I have difficulties to understand why a list of formats Flac/ALAC/DFF/DSF etc with the wanted transcoding sampling is such a big deal. This function exists in a lot of other audio softwares.
I can understand that it requires some work to be done. I can understand that it is not a development priority.
I have difficulties to understand why I start feeling to be a bad dumb customer to suggest this function.
Best regards
-
Hi - we are just users like you sharing what we know (or don't know) on the background of the subject. Bob is the JR man for this one when it comes to code changes.
-
In "theory" the idea of DLNA is that the DLNA Players specifies what formats it accepts as a part of the handshake. Ideally, MC should only have to convert stuff that is not supported...(eg "Convert unsupported") but also gives you two other options (Always and Never) to help cater for when devices are not so accurate in what is supported or not.
NOTE: another "engineers discourse". The description you give is not entirly complete or correct. According to DLNA/UPnP, the renderer should publish what formats it can play, the server should publish what formats it can deliver (either natively or through transcoding), and the control point should choose the best match between the two and initiate the playback. The control point could then delegate that decision to the user..
The "hard-wiring servers to renderers" stuff that MC is doing is really against the spirit of DLNA (or, more specific, against "Universal Plug and Play"), and as we can see here, it turns out to be a little unflexible...
chris
-
Happy that there is a negotiation between the three elements but I get the feeling that the whole DLNA spec as implemented in many devices is pretty loose as according to dlna.org for "home devices" the Required Format for Audio is LPCM (2ch) and optional support includes only MP3, WMA9, AC-3, AAC, and ATRAC3plus yet some players will also eat DTS or MPEG Audio....so I have no idea how the three elements work this out (well) if it is beyond the spec.
-
rather easy, really.
Renderer says: I can eat FLAC, LPCM, MP3, WMA9
Server says: I can deliver FLAC, LPCM for a given file
Control point says to user: "available combinations are FLAC->LPCM ort LPCM->LPCM. Choose one"
user decides (or configures the control point to always choose the best combo)
-
But that is the bit I don't get.... how does MC know that a renderer supports formats that are outside the spec, eg how does MC know a renderer can eat FLAC, DTS, or MPEGAudio etc? Is there some extended / standardised format list (eg like the FOURCC list for Video) over and above the DLNA spec that MC should be looking for and taking notice of when the negotiation is done? If such a wider list exists then it should be a relatively easy task for JR to include it. From a real world perspective, this would then solve ThierryNK issue as he could leave MC's DLNA server as only converting "Unsupported" but still stream FLAC.....
-
the server should'n know of or care for renderers at all. All it has to do is attach to each resource it serves a list of formats in which that resource can be delivered.
The renderer provides a list of acceptable formats which it makes available through a standardized programming API.
The control point (i.e., the application that presents the user interface) queries the renderer for supported formats, then lets the user browse the server contents and select a resource. It then looks at the resource for the attached format descriptions and (optionally) tells the user: "heres what we can do. Make your choice".
The DLNA server configuration in MC, which prescribes one static transcoding schema per server, breaks all this. This is done because some renderer devices with built-in control points (e.g. the average "Smart" TV) cannot cope with all that flexibility. It would, however, be nice if MC provided one server configuration in which the server would behave as described above. I have discussed this elsewhere with one Bob, and got an acknowledgement, but that was it. My MediaSteersman app, for example (finally, heres the plug), would gladly act as intermediary (control point) to complete the picture.
chris
-
...but how are the three parts ever going to work out that FLAC (for example) is supported if there is no way to communicate this value in the spec? All DLNA allows for Audio streams is LPCM, MP3, WMA9, AC-3, AAC, ATRAC3plus, AMR, and G.726 (combining the Home and Mobile Device Spec). If FLAC (for example) is not part of the spec how does the Renderer says it can support it or the Server says it can deliver it unless there is some extensible part of the spec that allows custom codecs to be negotiated?
Thinking wider, I guess MC's or your Control Point could also add a "Test" function so that when it sees a new DLNA Renderer it tries to send various formats and records which ones work or fail and then creates a new DLNA profile based on the results.
-
Happy that there is a negotiation between the three elements but I get the feeling that the whole DLNA spec as implemented in many devices is pretty loose ...
That's also our impression.
-
formats are communicated as simple mime-type strings, e.g. "audio/x-flac" for FLAC. All other properties (resolution, sample rate, etc.) are also already catered for. DLNA specifies minimal requirements, but you can extend as you wish.
There is no need for a "test" function. All the means are already there, all that is required is to use them. The dbPowerAmp UPnP server already behaves as I described.
-
Well...No argument from me. If the renderer supports (say) Flac and advertises it in a std way that can interpreted then the MC server should deliver it.
-
Well...No argument from me. If the renderer supports (say) Flac and advertises it in a std way that can interpreted then the MC server should deliver it.
yeah. But in the DLNA architecture, the server never "sees" the renderer, nor talks to it. The unit that talks to the renderer - and the server - is called a control point.