New firmware update

There’s probably like like two people who want digital EQ. The same number of people who want tone controls on their preamp. It’s not popular right now. Hasn’t been popular for decades. I certainly don’t have any interest in it.

Instead of taking away development resources on new features they should focus on making higher quality software.

5 Likes

Yeah, you’re right. I’m sorry… It’s 5 comments above yours. Hard to bring into context.

1 Like

I think that’s not true.

There are some serious manufacturers out there who put more and more effort into digital EQ, good hardware tone controls or Room Compensation. They do refine their existing technologies with each new model, do introduce it as a new feature in a new device or even bring it to their latest devices via firmware update. My feelings are this gets bigger and more important year by year. Just take a look at Dan D’Agostino Momentum, all the Linn DSMs, NAD, Roon, Steinway Lyndorf, Lyngdorf, Bang & Olufsen and much more…

Not everyone is a hifi purist, wants to play with different speaker cables, power supplies, etc., has a seperate listening room or wants to tranform his living room into a HiFi shrine for the perfect individual sound signature. These people would benefit a lot, and all the others: just don’t use it if you do not want to use it. Don’t get me wrong, I like - I love - my Nova and the Naim Sound. Overall it was and it is still the perfect fit for me. But I know people who did not buy into Naim because of missing some settings to adjust the sound signature to their taste.

But who am I… Just saying…

2 Likes

Are we there yet?

3 Likes

Not quite. Currently in Beta testing.

2 Likes

I’ve requested access to the Beta programme, but pending that, I’ll summarise some of my findings here.

For about a month and half now, I own a Naim Uniti Star, firmware version 3.5.1.4972 (latest stable version at the time of writing). I’ve experienced many hangs, crashes and reboots. That I have so many may be related to the fact that I’m ripping CD’s a lot (more than 100 per week), but that’s just conjecture on my part. Anyway, on to some of my observations. All of which to me indicate software (firmware) problems; based on my experience in the field I would guess some kind of resource leak or concurrency problem.

Note: the on-screen messages I ‘quote’ involve a bit of hand-waving, as my Star is set to Dutch, and some messages disappear from the display too quickly for me to run up to it and read them properly.

The Star may spontaneously reboot for no apparent reason. I’ve yet to find a reproducible set of circumstances, though. Mostly it’ll reboot while I’m ripping, but that may be because I’m ripping a large part of the time I’m using the Star (busy ripping my entire CD collection). It may restart completely (blank screen, clicking power supplies, full reboot), or it may just reboot some subsystem. Example of the latter is that I was streaming a Tidal track while ripping a CD. It rebooted a subsystem (a click [from a power supply?]) could be heard, but the track continued playing. I got a “Welcome. Looking for paired remotes.” message, after which it spat out the CD is was ripping, followed by a “Failed to rip CD due to an unknown error. Error 518”.

The scary part after that, and other crashes I’ve experienced, was that I then could no longer switch the Star off! Neither through the remote, nor through the front-panel buttons. In some cases I was still able to connect to it through the Naim app, and switch it to stand-by through the Settings menu. And when in stand-by, I was sometimes able to long-press (a second or 3) the front-panel power button to switch it off (i.e. ‘real’ power-off, not stand-by, although still connected to the mains, and the front-panel power button is still lit, so let’s call it ‘cold’ stand-by as opposed to the ‘warm’ stand-by after a ‘soft’ power-off). After which I could switch it back on using the front-panel power button (not through the remote, obviously, because it was now in ‘cold’ stand-by), but after it booted up (yada yada yada, plenty of time to admire the Naim logo on the display), I still could not switch it off using either the remote or the front-panel power button. Yikes. The only thing that could get it back into a usable state was unplugging it. Something that can’t be good for the machine (and possibly also not for my speakers, as unplugging it while ‘live’ gives a quite audible “BOOMPrrrr” on them). And in my set-up, it’s also not easy, as the wall socket the Naim is plugged into is for all practical means and purposes unreachable (behind a cabinet), and the connector into the power input of the Star takes quite some force to pull out. [Which, to me, in itself is a good thing, as it makes for a tight connection, but it also makes me hesitant to unplug & plug back in too many times, for fear of wearing things out.]

But I’ve also had it reboot after I was playing an album through Tidal, paused the playback and put the Star on stand-by, came back after some time, switched the Star on and resumed playing. It played the first few seconds of the track, then went silent, then managed to show the cover image on the display, and only then rebooted.

Another problem I’ve experienced was while ripping a stack of CD’s, it would fail to rip a new CD that I put in, spitting it out with the message “CD contains no tracks”. After that, it would refuse to rip any CD, including ones that I had successfully ripped just minutes before. The only way to get it out of that state was to do a power-off (long press of the front-panel power button; which by the way I only found out was possible through a post somewhere on this forum; do people no longer write proper user manuals these days I wonder?). After booting up, I could successfully rip the CD it had spat out before.

Another annoying thing is that some of the ripped tracks have ‘hiccups’ (I would call them FLAC encoding errors, but the FLAC files themselves are OK). In one case the Star would (consistently, reproducibly) play until the ‘hiccup point’ in the track (which wasn’t even halfway in the track itself), then skip to the next track. Playing that same track with e.g. VLC had an audible hiccup but continued playing the rest of the track. And none of these were tracks from CD’s with ripping errors. After re-ripping these CD’s, the hiccups were gone. I realised too late I probably should have saved these FLAC files. So when this morning I had another one, I did save it. This is the audio spectrum at the ‘hiccup’ point:

As you can see, just before the 2:06 point in the track, there’s complete silence. An analysis with flac -a around that point gives me (sorry, nerd alert :nerd_face: ):

frame=0	offset=402	bits=136008496	blocksize=909	sample_rate=44100	channels=2	channel_assignment=INDEPENDENT
	subframe=0	wasted_bits=0	type=FIXED	order=1	residual_type=RICE	partition_order=0
		warmup[0]=-2303
		parameter[0]=10
	subframe=1	wasted_bits=0	type=FIXED	order=2	residual_type=RICE	partition_order=0
		warmup[0]=-3994
		warmup[1]=-3762
		parameter[0]=10
frame=1	offset=17001464	bits=28576	blocksize=1152	sample_rate=44100	channels=2	channel_assignment=INDEPENDENT
	subframe=0	wasted_bits=0	type=FIXED	order=1	residual_type=RICE	partition_order=0
		warmup[0]=2912
		parameter[0]=10
	subframe=1	wasted_bits=0	type=FIXED	order=1	residual_type=RICE	partition_order=0
		warmup[0]=-758
		parameter[0]=10
frame=2	offset=17005036	bits=5464	blocksize=1152	sample_rate=44100	channels=2	channel_assignment=INDEPENDENT
	subframe=0	wasted_bits=0	type=FIXED	order=1	residual_type=RICE	partition_order=3
		warmup[0]=-2172
		parameter[0]=9
		parameter[1]=0
		parameter[2]=0
		parameter[3]=0
		parameter[4]=0
		parameter[5]=0
		parameter[6]=0
		parameter[7]=0
	subframe=1	wasted_bits=0	type=FIXED	order=2	residual_type=RICE	partition_order=3
		warmup[0]=197
		warmup[1]=860
		parameter[0]=9
		parameter[1]=0
		parameter[2]=0
		parameter[3]=0
		parameter[4]=0
		parameter[5]=0
		parameter[6]=0
		parameter[7]=0
frame=3	offset=17005719	bits=128	blocksize=1152	sample_rate=44100	channels=2	channel_assignment=INDEPENDENT
	subframe=0	wasted_bits=0	type=CONSTANT	value=0
	subframe=1	wasted_bits=0	type=CONSTANT	value=0
frame=4	offset=17005735	bits=128	blocksize=1152	sample_rate=44100	channels=2	channel_assignment=INDEPENDENT
	subframe=0	wasted_bits=0	type=CONSTANT	value=0
	subframe=1	wasted_bits=0	type=CONSTANT	value=0
frame=5	offset=17005751	bits=128	blocksize=1152	sample_rate=44100	channels=2	channel_assignment=INDEPENDENT
	subframe=0	wasted_bits=0	type=CONSTANT	value=0
	subframe=1	wasted_bits=0	type=CONSTANT	value=0
frame=6	offset=17005767	bits=128	blocksize=1152	sample_rate=44100	channels=2	channel_assignment=INDEPENDENT
	subframe=0	wasted_bits=0	type=CONSTANT	value=0
	subframe=1	wasted_bits=0	type=CONSTANT	value=0
frame=7	offset=17005783	bits=128	blocksize=1152	sample_rate=44100	channels=2	channel_assignment=INDEPENDENT
	subframe=0	wasted_bits=0	type=CONSTANT	value=0
	subframe=1	wasted_bits=0	type=CONSTANT	value=0
frame=8	offset=17005799	bits=128	blocksize=1152	sample_rate=44100	channels=2	channel_assignment=INDEPENDENT
	subframe=0	wasted_bits=0	type=CONSTANT	value=0
	subframe=1	wasted_bits=0	type=CONSTANT	value=0
frame=9	offset=17005815	bits=128	blocksize=1152	sample_rate=44100	channels=2	channel_assignment=INDEPENDENT
	subframe=0	wasted_bits=0	type=CONSTANT	value=0
	subframe=1	wasted_bits=0	type=CONSTANT	value=0
frame=10	offset=17005831	bits=128	blocksize=1152	sample_rate=44100	channels=2	channel_assignment=INDEPENDENT
	subframe=0	wasted_bits=0	type=CONSTANT	value=0
	subframe=1	wasted_bits=0	type=CONSTANT	value=0
frame=11	offset=17005847	bits=128	blocksize=1152	sample_rate=44100	channels=2	channel_assignment=INDEPENDENT
	subframe=0	wasted_bits=0	type=CONSTANT	value=0
	subframe=1	wasted_bits=0	type=CONSTANT	value=0
frame=12	offset=17005863	bits=128	blocksize=1152	sample_rate=44100	channels=2	channel_assignment=INDEPENDENT
	subframe=0	wasted_bits=0	type=CONSTANT	value=0
	subframe=1	wasted_bits=0	type=CONSTANT	value=0
frame=13	offset=17005879	bits=128	blocksize=1152	sample_rate=44100	channels=2	channel_assignment=INDEPENDENT
	subframe=0	wasted_bits=0	type=CONSTANT	value=0
	subframe=1	wasted_bits=0	type=CONSTANT	value=0
frame=14	offset=17005895	bits=18696	blocksize=1152	sample_rate=44100	channels=2	channel_assignment=INDEPENDENT
	subframe=0	wasted_bits=0	type=FIXED	order=2	residual_type=RICE	partition_order=3
		warmup[0]=0
		warmup[1]=0
		parameter[0]=0
		parameter[1]=0
		parameter[2]=8
		parameter[3]=9
		parameter[4]=9
		parameter[5]=9
		parameter[6]=9
		parameter[7]=8
	subframe=1	wasted_bits=0	type=FIXED	order=2	residual_type=RICE	partition_order=3
		warmup[0]=0
		warmup[1]=0
		parameter[0]=0
		parameter[1]=0
		parameter[2]=7
		parameter[3]=8
		parameter[4]=8
		parameter[5]=8
		parameter[6]=8
		parameter[7]=8
frame=15	offset=17008232	bits=24744	blocksize=1152	sample_rate=44100	channels=2	channel_assignment=INDEPENDENT
	subframe=0	wasted_bits=0	type=FIXED	order=2	residual_type=RICE	partition_order=1
		warmup[0]=-1758
		warmup[1]=-1846
		parameter[0]=8
		parameter[1]=9
	subframe=1	wasted_bits=0	type=FIXED	order=2	residual_type=RICE	partition_order=3
		warmup[0]=-570
		warmup[1]=-734
		parameter[0]=8
		parameter[1]=8
		parameter[2]=8
		parameter[3]=8
		parameter[4]=8
		parameter[5]=10
		parameter[6]=9
		parameter[7]=9

As you can see, frame 1 is OK, frame 2 is the start of the encoding error, frames 3 through 13 are completely silent (type=CONSTANT value=0), frame 14 is ramping up, and from frame 15 it’s OK again.

Since the Beta forum is not open to the public (unfortunately) I have no idea whether any of these problems a. have been reported previously and b. are being addressed by the current beta firmware.

Oh, and before anyone asks, yes, I did try a factory reset. That’s no joy, as that loses not just all your settings, but also all of your favourites and radio stations (and rebuilds the media library, which takes quite long if you have a lot of music). So that’s a hoop I hope I don’t have to jump through again. :unamused:

To end on a high note, when it works, the Star sounds absolutely magnificent. My hopes are on the software team delivering a version that fixes most (if not all) of these.

1 Like

If you haven’t already done so, it would probably be a good idea to send this info to Naim tech support for them to review and advise.

Surely tech support can read my forum post? Anyway, I forwarded a link to my post to Naim support.

It doesn’t quite work like that (and would be very hard to properly manage if it did), but thank you for forwarding your post to tech support.

I have also experienced the one second gaps of silence on a few CDs I have ripped on my Star as well. I was thinking it was fixed but as my collection is ripped I only rip a new CD every now and again these days.

Well, as we speak I’m rsync’ing my entire music library to my computer for off-line analysis. Will post here when that’s done.

Shot in the dark here. When I got my Star just over a year ago it was plagued by freezes and such. I also have a reasonable amount of local files and sub to Tidal and Qobuz.

It a point a few months ago I gave Roon a try. Aside from nicely consolidating the three sources into one smart library it also seemed to increase the stability of my Star. During this time the firmware also improved so I can’t say how much was because of what exactly.

But since that time I have had a pretty much restart free experience while effortlessly navigating music from various sources. Allowing me to concentrate on the beautiful sound of the Star, as you mention.

As you are obviously very tech savvy I thought I’d mention it. Roon can be tried for free. There, I’ll just leave this here :wink:

I definitely know Roon, but don’t want another piece of dedicated hardware (the Roon core) in my set-up. Just yet, anyway. Maybe some day.

Intermediate analysis uncovers even some invalid FLAC’s (that’s bad IMHO). My wild guess is that these encoding problems are caused by buffer overruns or resource leaks, or possibly priority interrupts causing the ripping pipeline to lose some data and encode zeroes in the output.
[In retrospect I can see why Naim claims “The Uniti Star is set to rip to uncompressed WAV by default. We believe this gives the best Sound Quality.” if they are aware of these encoding problems,
but that is contradicted slightly by “The advanced data handling algorithms ensure the ripped data is always a “bit perfect” copy”…]

Most of the ripping I do is while I’m in the room, listening to music (streamed or ripped) on the Star, and possibly doing some metadata editing in the Naim app (fixing coverart or titles etc.). It should be able to handle that, but any concurrency bugs in the firmware could/would lead to situations where things can (and by my experience with the Star will) go astray.

I ripped everything to WAV and had similar errors.

That’s some comfort at least. Don’t fancy the prospect of ripping all my currently ripped CD’s again

Once the data transfer has completed, it might be a good idea to run rsync a second time with --dry-run --checksum options to make sure that no errors have been introduced when storing the trasferred data on the target.

Data transfer errors are extremely unlikely but storing errors can happen (and do happen) when backupping terabytes of data.

The checksum takes a lot of time, but it brings the probability of differences between the source and the backup copies down to almost zero.

Well, it wasn’t even a network rsync, as I’d just taken the SD card out of the Star and inserted it into my computer, so it’s a local copy from SD to SSD (but I like rsync for its incremental transfer capabilities). However, thanks for your concern!

The analysis is running now.

I would expect the ripping software of the Uniti Star to checksum rips against AccorateRip or similar databases before storing to files.

Therefore, I would think that, if your drive contains invalid FLAC files, perhaps there is something wrong with the drive itself or perhaps with the drivers of the Uniti Star.

Anyway, if you conjecture a relationships between the reboot and/or freeze events and the file errors, you could perhaps try to find out whether the number of invalid FLAC files increases when such events occur.

You could also try to rip your collection on another computer to check whether the Uniti Star operates normally if you do not rip.

I very much doubt that Naim claims that “The Uniti Star is set to rip to uncompressed WAV by default. We believe this gives the best Sound Quality.” because they are aware of encoding problems.

I guess the default is to rip to WAV for historical reasons which is a very bad idea anyway: if you rip to WAV, the metadata are encoded in a proprietary, non-exportable format. This basically means that the rips are not portable and that the metadata can only be read by Naim systems.

Expecting but not verifying such things is never a good idea :slight_smile:
(by the way, the ripper built into Roon doesn’t. It uses CD Paranoia at high settings but no AccuRip checks).

https://www.naimaudio.com/product/uniti-star > click Support section at bottom of page > Which file format should I choose to rip CD’s, WAV or FLAC?

  1. The Uniti Star is set to rip to uncompressed WAV by default. We believe this gives the best Sound Quality. However, FLAC can be chosen which results in a smaller file size and a larger amount of files can be stored on an equivalent sized drive.