Will this approach work with roon too? I mean regarding that unbelievable long list of features requests / fixes / improvements that some of us are still dreaming for…
I think your answer is posed in your question “that unbelievable long list of features requests / fixes / improvements” it’s unbelievable that they could all be addressed.
1 Like
Perhaps the list is ‘unbelievable’ in itself? 
1 Like
of course!
We monitor the feature requests posted here all the time.
Well, then I try again:
Please SACD ISO support.
I started asking for this feature in June 2015.
You even closed down the thread where we started to ask.
1 Like
Well, monitoring it’s one thing, getting things done it’s another one…
Which only proves that the monitoring it’s working indeed! 
We aren’t working on it, but we’re not putting it down as a “no”. There is a way to convert to something usable without loss. The fact that there is a good workaround, it is not a priority for Roon. The number of people that need it is diminishing, not growing. Many have converted already.
Hope so, but
I would be more pleased if a validated issue promissed to get fixed “later this year (Brian)” would really happen within “this” year, since you might monitor feature requests, in return I do monitor promissed fixdates.
But there’s 3 months left … so I’m patient assuming it’ll happen as being told.
In all fairness to Roon, or any other developer, how is it possible to give accurate “fix it by” dates?? Never have I ever seen that done by a developer, as it’s virtually impossible, as they have no idea of the complete scope of fixing it until it’s fixed. There are already millions of broken deadlines. Do we really need Roon adding to that??
Software developing wise looks like you live in a very different world.
You mustn’t think about development being a reinvention of a wheel each time.
If you got a workflow where you accidently added an unrequired step doing nothing but eating up time and recources while the result this step fullfills does nothing differt against if you have simply commented out this task, then it’s easy to mention a wider range about when it’ll be done.
Since its more a matter of spare time, willing to do so, and bundling it into an upcoming release.
When reading your lines about development I get some warm feelings since it was like this in the early 90th where I was given a task without being asked about when it might be done. I can’t tell the exact year when this did chance, but by now I sometimes wonder if it would take 2 years or less until I will be first given a due date having fullfilled a development task and then fterwards given the details about the task itself. 
Which topic? I’ll get that fixed. We shouldn’t have that ETA out there.
Hi Danny
Issue in short … see last line … if you want to read the whole story here we go
Assume I have 100000 tracks in the roon library and you have to modify 30% since Brian informed me about if you add a tag:
LIVE given the value 1 would result in roon treating this track being a live performance.
He also gave me some more hints about metadata roon is aware of (more than mentioned in the documentation roon offers.)
So I retagged them (which I do quite often since times are a changing and software does as do the needs of me, wife kids and the devices they do use. Means metadata is under permanent modification.
I pointed out to Brian that it doesn’t make much sense to re-analyse the audio which eats resources without need (cpu and time).
He agreed that he wasn’t aware that a simple metadata change would result not only in the required rescan but also into a reanalysis and promissed it to get fixed.
Then there was the update which only brought the half cut frequency play bar (most of your customers asked to revert this fault which you then did with another update).
Was a bit disappointed that time and re-asked Brian about what happened in terms of getting the issue fixed. And he gave the answer “later this year”.
I surely accept nothing happened earlier this yeas, since besides fiddeling with the frontend (too much spare time I assumed) I can imagine that the core programmers were dead busy in getting quboz integration done at that time which surely is a much higher priority.
But now I had to step in and this topic was ideal … since before all your hardcode programmers step over being busing with integration of Amazon Music HD I must point with the finger that something’s still left undone from the ToDo list.
Hopefully it is on that list … since recently the annual license fee was performed which I didn’t mind since still believing the issue gets fixed (perhaps before my life ends due to having reached the end of the common lifespan for my species).
Sorry rather longish reply … but I wanted to share the whole information against saying:
roon mustn’t re-analyse previously anaysed audio (analysis stage) if only metadata was modified while the audio part of the physical file remained untouched. The rescan stage would definatly get all modifications the file could offer.
regards
Stefan
Honestly can’t say I’ve seen Roon reanalyze for metadata updates and I enhance often.
Depends upon your setup I’d say.
Either an i9 NUC for the server or perhaps using a tagger which prevents file modification datestamps being updated? I’m aware of such taggers but I got some other software which has to rely upon modifications being visible by the files modification date which was invented especially for such purpuses. In the field continous data protection / realtime backup. Means I can’t fool 1 software title since it’ll break the other from being full functional.
I do have timestamp modding turned off in my tagger and it has a hotkey that adds two seconds to the timestamp. When I’m done updating tags I use this hotkey to ensure Roon detects the changes and rescans the file. Never seen it re-analyze though.
I also often move an artist’s entire discog to a hidden folder (any folder prepended with a “.”) which Roon then ignores. I then update metadata for the albums and move them back without making any changes to date/time stamp. I’ve not noticed them being re-analyzed then either, but I’ll look out for it next time I do this.
Might be filesize is taken into account? if you add an audiofingerprint (1024 bytes for example) this surely exceeds the remaining free bytes from the so called padding area in a flac vorbis tag, resulting in expanding the metadatablock followed by getting a differnt filesize in the end.
Have to check for that. Not to mention there’s taggers around which try to save HDD space by shrinking the padding area next to 0. (surely invented with mobile devices in mind, since I won’t bother about HDD space)
When I’m done with the first tagging of a file I run
flac -f -8 --preserve-modtime --verify --no-padding
with the consequence that retagging results in a rewrite of the file. Why would you add an “audiofingerprint” - FLAC has an internal md5sum which is exactly that. It’s how FLAC is able to verify the integrity of the audio stream.