Worth The Wait?

'Seek to time' - fantastic.

Multi-room sync - interesting and doubtless the marketing guys saw the need for this... I didn't though.  But if it sells more Qute2's and keeps the company in profit and if those profits continue to be channelled into R&D, it works for me !

Now... that'll be June... 2013?       

I will actually use multi-room synch

I have a Qute upstairs . . . and the NDS on the main system downstairs . . . I can envision having a house full of people and having both systems "on." I have thought about this in the past, and then realized that the functionality had not yet been pushed.  So yay!

I'll find the multi-room useful functionality and definitely a good marketing move.  I currently achieve the same with Airport Expresses plugged into other audio systems and stream from iTunes.  I'll now be on the lookout for Qutes to replace bits and pieces with. 

Good news for people looking to sell Qutes also :-)

A bit unsure what is the big advantage of seek2time?

I look through tracks while the SuperUniti is playing a different track.

What will seek2time bring?

What could possibly have made you so cynical?    I am counting on *2013 June* too.

Looks like the master broadcasts to the slave Uniti's as 320k MP3s. Hopefully this will increase to at least CD quality. Is the Linn version limited?

It depends. AFAIK, between Linn DS and DS Songcast supports any sample rate and up to 24 bit, from PC or Mac to a DS the Songcast driver is limited to 44.1 kHz (and 16 bit for PC).

Hard Disk Update

Naim radio over uPNP - good.

Otherwise I am disappointed. The things I really wanted were:

1. Meta Data Management

For non-Naim ripped music - particularly 'genre'; and

2. Volume Normalisation

Hopefully under software control, allowing it to be switched in or out.

M

TMr Underhill, both volume optimisation and meta data management are really functions of the upnp server not really Nstream or the network player / renderer.

As I say elsewhere most functions are slaved to the upnp server, hence why it's a critical component in terms of usability.

The seek function to a time point in the media file is part of the upnp standard, and here the renderer / network player has to be changed tsu understand this or it will be ignored., as is the case with control points that try to send seek to time instructions to Naim renderers currently.

DomTom, seek to time is usually implemented as fast forward fast rewind. I am however curious  to see how seamlessly it works with Naim, Asset and FLAC/WAV realtime transcoding....

Simon

OAllen, I hear you about metadata hypertext navigation. But I can't think of a way in upnp to do it without  re engineering of the upnp server database access functions ( a little personal project I have which I am not getting very far with) and  making them available to the control point (nstream) in a non standard way. You could perhaps try a very rigidly defined  navigation directory tree  structure, however this would be a negative IMO as its useful and fun to create your own (albeit linear) navigation trees based on custom metadata as I do with Asset.

Also this method of custom trees can almost replicate a basic / limited implementation of your Jump To. I do it for artists within album search and genre search but a selected album gets subsetted if a compilation etc.

I think the database access method would be the most effective, but I think interoperability with non Naim upnp servers and control points would be the casualty.

Simon

Hi Allen, I wouldn't call myself an expert, I just make a living from them amongst other things and spent most of my working life designing, configuring and breaking them

In the the world of upnp/dlna fast forward and fast rewind can typically be achieved at least in three ways (that I am aware of)

• The controller can instruct the renderer  to seek to a specific  time in media from the server. This can increment or decrement from the current play position in time. This is sometimes referred to as seek to time.
• The controller can instruct the renderer  to seek to a specific memory position in media being served. This could be useful for variable bit rate media where a time could be hard to calculate. Ie FLAC
• The controller can instruct the renderer with the server to play the media at different speeds.

Now all these features are optional, and a device needs to instruct its ability to support before you're supposed to call the API. Of course this requires close cooperation of controller/renderer/server and so Naim results will almost certainly vary with different non Naim upnp  servers.

The following is the MS overview of their view of DLNA device architecture, quite interesting

http://download.microsoft.com/...LNA_Part_2_RS08.pptx

Finally, your database caching idea, yes sounds interesting, subject to memory being available on the iPad/iphone. Nice one.

Simon