New firmware update

You’d think, but the Star is slightly smarter than that: if it has no Internet connection (or cannot find the metadata), it will queue it and retry later. At least, that’s my understanding.

I use deja-dup for my backups, but we’re getting off-topic now. :wink:

I didn’t say a lot, and what “a lot” is depends on the capability of the platform. It is a lot if you have to do the decompression on an 8088. I was merely pointing out that “it’s the same bits” is correct but not the whole picture. I doubt anyone can give you measurements, but it’s a common opinion by owners of the old streamers that WAV sounds better, which is why basically everyone has set the UPnP server to transcode to WAV on the fly. It is most likely also the original reason for Naim’s claim in the Star FAQ, and if they prefer (or preferred) it, you can be 100% sure that they did listening tests and came to this conclusion, whether it is measurable or not. Most people with the much more powerful new streamers seem to agree that it makes no difference there. (But then again, it costs nothing to let the NAS do it, either).

Not sure why you put “electrical noise” into quotes, electromagnetism is a pretty well established concept. And we are talking about a company that developed output transistors with non-ferrous connectors because otherwise they say the current going through them causes microvibrations in the connectors, which Naim believes deteriorates the sound.

Sorry for thread drift

You are probably right, although I’m guessing that the Star is like the older Naim rippers in that they rip to WAV. If you have chosen FLAC, the albums are then converted, one track at a time. When ripping multiple albums, a queue would build up which could take some time to process.
I believe the Core, and probably the Star, have a bit more power to complete this transcoding faster.
Quite how this might be relevant to your issue, I’m not sure, just thought I’d throw it into the mix.

Yes, it is in the FAQ quoted above,

(Would have liked to have posted this yesterday, but was prohibited because apparently one is limited to 18 posts during one’s first day on the forum…)

Don’t read too much into that; I put it in inverted commas because I was quoting you, not because I don’t believe in the reality of electrical noise (honestly, I do).

As to what sounds better (or is perceived as such), that’s a potential mine field and we may set off religious wars. So that’s probably best saved for a totally separate topic on another forum category. :innocent:

Yeah, don’t want to go there either. Just saying that the opinions are remarkably consistent also from people switching from old to new streamers, so I’m not dismissing it outright, especially as Naim says so too

Out of curiosity, I re-ripped a sample of 3 disks (out of the 106) with FLAC errors, while as a precaution making sure the Star was doing nothing else. The tracks that contained FLAC errors were now ripped correctly, all other tracks were bit-for-bit identical to the previously ripped ones. To me again indicating firmware problems. Still waiting for that access grant to the Beta programme…

So, 3 down, 103 to go. And then the remainder of my collection. :hourglass_flowing_sand:

1 Like

(edited to quote the original quote)
Well, strictly speaking, that is not what is stated there, and also not how I read it. The Star can rip to either WAV or FLAC, its default setting being WAV, but the user can change that to FLAC. My reading of it is that the Star will rip to the chosen format, which is different from always ripping to WAV and converting to FLAC if that was chosen by the user. Mind you, it is even possible to change the rip format per CD, so: set it to WAV, rip a CD, set if to FLAC, rip another CD, set it to WAV, rip a third CD, etc. (tried that actually), and the rips will be in the set format. So tracks for CD 1 are WAV, for CD 2 are FLAC and for CD 3 are WAV, etc. There’s no after-the-fact conversion/re-encoding that I can discern.

I was keeping the quote short as the original was right there. It was obviously an answer in the context of the full statement, which was “You are probably right, although I’m guessing that the Star is like the older Naim rippers in that they rip to WAV. If you have chosen FLAC, the albums are then converted, one track at a time.”

Also I quoted the Naim statement a second time in this very post, so there should be no doubt about what the Star does by default and that you can choose different.

Don’t know of after-rip conversion, but I did not read Chris’s statement in this way. But now that you mention it, I see that it can be

My point was simply this - the old rippers used to save to WAV then immediately start converting to FLAC if that’s what you chose, rather than immediately saving as FLAC. If you open the folder on a computer you can watch it happening, as the tracks change, one at a time, and finally the artwork folder vanishes as the image is incorporated into the FLAC.
I don’t have a Star to compare, so I don’t know if it does the same or not. I was just speculating that it might be this later conversion process that was eating up the Star’s resources and causing the errors.

1 Like

Not quite. Like I said: not that I can discern. Getting technical now, so we’ll probably lose >95% of the audience… :nerd_face:

The Star’s internal Samba server only exports the Music and Downloads sub-directories. From observing these mount points with a Samba client, ripping (probably) works pretty much as I’d design it if I were in charge, which is: rip to a temporary directory outside the exported locations, and when done ripping, do an atomic rename of the results into the Music library (thus avoiding incomplete or inconsistent contents of the library). So there are no intermediate results visible; when the ripped album appears, it’s FLAC files for each track, plus two JSON files (meta.naim containing all metadata and rip.naim containing the rip results), plus a coverfront.png containing the coverart (if it could find any, otherwise this file will be absent; user-supplied coverart will be in a userartwork.jpg file).

That doesn’t rule out the possibility that in the temporary directory, WAV files are being converted to FLAC, but as the complete album appears as soon as the disc stops spinning and the rip is done, I doubt there’s a separate conversion process running on WAV files.

Theoretically, I could yank the power cord when the Star was halfway through ripping, then examine the contents of the media disk off-line to verify that hypothesis, but frankly, I won’t bother. :stuck_out_tongue_closed_eyes:

1 Like

AlI know is that if I open my Unitiserve Music folder in an OSX Finder window, I can see a freshly ripped album appear as a WAV with its separate artwork folder. I can then watch one track at a time change from WAV to FLAC. It takes a couple of minutes per album, and you can soon build up a backlog when ripping several CDs in succession.
As I said, I have no idea if this contributes to your problem, I’m just speculating as to which stage of the process might be causing an upset.

So, the conclusion that strongly presents itself is: the Star works differently from the Unitiserve.

Have had 2 reboots… so updated tonight … seemed to take quite a long time…was it my imagination … but it seemed to update twice…

This would not be totally surprising given that the UnitiServe OS was a Windows Embedded whereas the OS of the new Uniti generation was said to be Linux. On the other hand, the ripping software and the UPnP of the new Unitis seems to be just a port of the old UnitiServe software to the new platform. Thus, perhaps @ChrisSU conjecture is not that far away from reality. I would expect the new platform to have significantly more RAM. Thus, it is conceivable that encoding and decoding between different formats is much faster and possibly done in memory. None knows. Anyway the bottom line is that, sadly, the new generation of Naim servers and streamers is by far not where it should be and, in the meanwhile, it is also not any longer new.

OK, then… I’ve re-ripped about half of the CD’s that had tracks with FLAC errors, and doing only that: ripping. Star wasn’t doing anything else. All these ripped without errors now. Pretty convincing support for my “resource leak or concurrency problem” hypothesis.

Still, it’s bad enough the display of :ballot_box_with_check: Cd foutloos geript. OK” (‘Cd ripped without errors’) at the end of each rip needs to be taken with a grain of salt. Double-check your results to be sure!
The room is also very quiet while I’m ripping now, which makes me feel I’ve slightly overspent on what is at such times not much more than a glorified stand-alone CD ripper.

Anxious to hear from Naim support or the people from the Beta programme, hopefully tomorrow (Monday) when they’ll be back at work? @Naim.Marketing Are you following this?

1 Like

If I have to be brutally honest, the first time I noticed this happening was about a year ago. I reported it then as well. Because my CD ripping has decreased significantly I was under the impression it was fixed. Never had feedback that it was fixed though so it is obviously a very long running bug.

I also had the feeling that it was concurrency but I had a rip error when nothing else was happening too. Still I can’t shake the feeling that if the Star was writing and reading from the store at the same time more errors seemed to crop up.

As you have a way to check automatically may I suggest trying to enjoy the sound of the Star and retrying those that fail? Get some enjoyment out of the box as well.

And being on the beta test is probably a great idea. I’m on there too just don’t rip enough for this to have cropped up again. Your level of ripping would be an asset there I think.

Yes, I am. Will talk to the team this morning…

flawlessly ripped, that’s dutch !