Jump to content
IGNORED

Official Roon User Impressions Thread


Recommended Posts

#2 is what you are complaining about. The feature I'm actually working on at the moment lets you reverse the priority for certain fields of #1 vs #2. For example, right now, if you get a metadata match with our servers, we hide your album title and artwork. This new option will let you keep our credits data, or classical composer/work/performance structure, but use the album title + artwork from your tags.

 

We feel this is the best of both worlds. No product, or groomer, has depth to their metadata like we do, but your tags are built the way you want them. This lets the end experience include both.

 

That would be perfect!

Analog: Koetsu Rosewood > VPI Aries 3 w/SDS > EAR 834P > EAR 834L: Audiodesk cleaner

Digital Fun: DAS > CAPS v3 w/LPS (JRMC) SOtM USB > Lynx Hilo > EAR 834L

Digital Serious: DAS > CAPS v3 w/LPS (HQPlayer) Ethernet > SMS-100 NAA > Lampi DSD L4 G5 > EAR 834L

Digital Disc: Oppo BDP 95 > EAR 834L

Output: EAR 834L > Xilica XP4080 DSP > Odessey Stratos Mono Extreme > Legacy Aeris

Phones: EAR 834L > Little Dot Mk ii > Senheiser HD 800

Link to comment
Here is my take for what it is worth. On Mac, it doesn't compare to the alternatives. JRiver direct in integer mode v. Roon, no comparison.

 

I'm trying to figure out what the community here means by "SQ".

 

If this is matter of accurate reproduction by your endpoint, then this shouldn't be a concern. The definitive test for accurate reproduction is to have Roon speak to your endpoint, and then record your SPDIF output and see if the bits match up with your source. We've done this exact experiment many times, and the results are always perfect. We've also done this with JRiver and Audirvana+, and they are also perfect. You must run in exclusive mode in Roon, or direct mode in the others to bypass the OS mixer.

 

Now, there is a second item in play here, which is DSP. If you are "tweaking knobs" in the other players, then the output will not be accurate, but it may sound better to your ears. HQ Player, JRiver, etc, all have these "knobs". Roon does not. We are working with DSP partners to provide this in the future, including Meridian and the author of HQ Player. Nothing announced or pinpointed on the roadmap yet, but we aren't going to release this until we get it right.

 

If you are finding that Roon -> JRiver WDM sounds great, then Roon -> CoreAudio/WASAPI in "exclusive" mode should be as accurate, but lacking the DSP you are doing in JRiver or HQ Player.

 

Please help me understand which "SQ" you all are talking about, because there seems to be two definitions in play. Accuracy and DSP.

 

Anyone looking for DSP in Roon right now will be sorely disappointed. We do not offer it yet. As stated above, we are working with partners on this, partners you already trust, but we won't release this until it is as awesome as the rest of Roon.

 

Anyone looking to reproduce their music files accurately, have nothing to worry about. If you require DSP at the moment, there are virtual sound card solutions via JRiver and the others that let you pull this off.

 

If there is something else I'm missing, please do explain. You guys are an invaluable treasure trove of experience that can't be learned. Please, fill me in :-)

Link to comment
I'm trying to figure out what the community here means by "SQ".

 

If this is matter of accurate reproduction by your endpoint, then this shouldn't be a concern. The definitive test for accurate reproduction is to have Roon speak to your endpoint, and then record your SPDIF output and see if the bits match up with your source. We've done this exact experiment many times, and the results are always perfect. We've also done this with JRiver and Audirvana+, and they are also perfect. You must run in exclusive mode in Roon, or direct mode in the others to bypass the OS mixer.

 

Now, there is a second item in play here, which is DSP. If you are "tweaking knobs" in the other players, then the output will not be accurate, but it may sound better to your ears. HQ Player, JRiver, etc, all have these "knobs". Roon does not. We are working with DSP partners to provide this in the future, including Meridian and the author of HQ Player. Nothing announced or pinpointed on the roadmap yet, but we aren't going to release this until we get it right.

 

If you are finding that Roon -> JRiver WDM sounds great, then Roon -> CoreAudio/WASAPI in "exclusive" mode should be as accurate, but lacking the DSP you are doing in JRiver or HQ Player.

 

Please help me understand which "SQ" you all are talking about, because there seems to be two definitions in play. Accuracy and DSP.

 

Anyone looking for DSP in Roon right now will be sorely disappointed. We do not offer it yet. As stated above, we are working with partners on this, partners you already trust, but we won't release this until it is as awesome as the rest of Roon.

 

Anyone looking to reproduce their music files accurately, have nothing to worry about. If you require DSP at the moment, there are virtual sound card solutions via JRiver and the others that let you pull this off.

 

If there is something else I'm missing, please do explain. I'm new to this community, but I have my head on straight :-)

 

In my situation, I can say running JRIVER w/o any DSP but using ASIO sounds better than Roon in exclusive mode on windows and I have found similar results using my macbook pro using integer mode on Jriver vs. Roon in exclusive mode. NO DSP.

Link to comment
In my situation, I can say running JRIVER w/o any DSP but using ASIO sounds better than Roon in exclusive mode on windows and I have found similar results using my macbook pro using integer mode on Jriver vs. Roon in exclusive mode. NO DSP.

 

What is your output endpoint? Does your endpoint have a digital output? Would it be possible for you to record the digital output? If you are hearing a difference, someone is tweaking the signal, and I want to know how.

 

I just did a test a few weeks ago with some of my Meridian gear, and the digital output from Roon is identical to the FLAC decoded from disk. Exact same bytes passed from harddrive -> roon -> core audio exclusive mode -> meridian G68 -> spdif output. No one in that chain altered the signal at all.

Link to comment
What is your output endpoint? Does your endpoint have a digital output? Would it be possible for you to record the digital output? If you are hearing a difference, someone is tweaking the signal, and I want to know how.

 

I just did a test a few weeks ago with some of my Meridian gear, and the digital output from Roon is identical to the FLAC decoded from disk. Exact same bytes passed from harddrive -> roon -> core audio exclusive mode -> meridian G68 -> spdif output. No one in that chain altered the signal at all.

 

I am selecting Chord Async USB 44.1kHz - 384 kHz in "exclusive mode" on Roon and comparing it to JRiver ASIO on my PC

 

 

On the Mac, there is integer mode in JRiver that is selected.

Link to comment
I am selecting Chord Async USB 44.1kHz - 384 kHz in "exclusive mode" on Roon and comparing it to JRiver ASIO on my PC

 

 

On the Mac, there is integer mode in JRiver that is selected.

 

Integer mode makes zero different about quality, only CPU/Memory efficiency on the Mac. With or without it, it is still bit accurate.

 

JRiver makes this clear at Integer mode playback (requires OSX 10.9 and compatible hardware):

 

Technical Considerations

Both playback methods are bit-perfect, and bit-perfect methods sound the same.

 

In fact, that link on their site about bit-perfect methods is really good. Even JRiver makes the case that bit perfect is bit perfect, and whether you are speaking ASIO, CoreAudio, WASAPI, or some how directly speaking to the sound driver. The only other thing can be DSP, which they refer to as #2 on their list.

Link to comment

oh crap!!!!!

 

@priaptor, do you know about this negotiation bug Roon has?

 

The problem is actually kind of strange, and completely our fault. It arose from not testing with enough equipment before we launched. I fear you might be running into it and therefore be experiencing your content differently than you expect with Roon.

 

Brian posted this explanation of the bug:

 

The bug that I'm fixing is really only for exclusive mode configurations. When Roon tries to send audio to a device and the device won't accept the native format of the audio, Roon has to figure out a way to adjust the stream for compatibility. Currently Roon solves compatibility issues by first reducing sample rate, then reducing bit depth. This works fine for the small mountain of DACs in our test rig, since they all take 24bit natively so the bit-depth reduction never comes into play, but you guys have discovered that there are some DACs out there where this scheme is no good.

Assume for a second that you're trying to play back 96k/24bit audio and getting 48k/16bit on the output side--at least one of the logs I analyzed looked like that. The exact problems you're experiencing might be slightly different, but they all look like 24/2x or 24/4x -> 16/1x.

It looks like some devices will accept 96k/32bit or 96k/16bit natively, but refuse to accept 96k/24bit. Because we're reducing sample rate first right now, we start by downsampling to 48k/24bit then ask the device again. When that doesn't work, we try 48k/16bit and the DAC says "ok" and we run with it.

This is bad. The right thing to do would is to reformat the 96k/24bit data as 96k/32bit so we can make the device happy without doing unnecessary DSP. I'm currently in the midst of re-arranging this so that it handles these devices well.

I should be done with this work before I sleep tonight--as soon as it's done, we'll give it a couple of days in QA to make sure that I didn't accidentally break something else while doing this stuff, then push it out to you guys.

 

This might be why your Roon + CoreAudio + Chord output is not sounding as good as JRiver w/ no DSP + ASIO + Chord. ASIO and JRiver w/ no DSP have nothing to do with it, it's just a stupid DAC negotiation bug :-(

 

If this is the case, I apologize profusely and hope you give you listening test another round when you get the update this week.

Link to comment

@dannyroonlabs If you compare A+ and HQP without any upsampling, do they sound identical to you? They do not to my ears. Yet both are bit perfect.

 

Edit: HQP in not bit perfect, right?

Roon client on iPad/MacBookPro

Roon Server & HQPlayer on Mac Mini 2.0 GHz i7 with JS-2

LPS-1 & ultraRendu → Lampizator Atlantic → Bent Audio TAP-X → Atma-sphere M60 → Zero autoformers → Harbeth Compact 7 ES-3

Link to comment

@Freann, I can do that test, but I only have DSP7200s to listen to right now, so everything is digital. What renderer are you testing with?

 

If those two players (HQ and A+) are not upsampling, not converting, and not tweaking, and negotiate with the renderer in the same way, and send the exact same data to the renderer, and the renderer can correct for jitter by reclocking, then they should not sound any different. If the data and timing going to the renderer is identical, and that renderer must follow the rules of physics: same inputs, same outputs. This is basic deterministic physics. The effects of quantum mechanics are not making HQ Player magic over A+.

 

If you hear a difference, then something is changing. I believe you that you hear something different, and your ears are surely better than mine. However, my SPDIF recording test should be able to determine exactly what is changing in the stream.

 

Now, there is one more weird thing that can happen. If you renderer has a digital output and you record it with both players, and both have the exact bits, then there is still 1 more location for variable quality, and it is internal to the renderer. Here is an example of one of those pieces of variability: Some renderers have an internal 32bit PCM D->A converter. Some renderers have an internal 1bit DSD D->A converter. If you feed both the identical PCM data, then their digital outputs will be the same, but the second one will have to internally convert PCM to DSD. I would bet that HQPlayer can do that better than some (if not most) hardware devices out there, but I've not done any tests on this.

Link to comment

Ok, different scenario. I’m not using any renderer, just straight to the dac via usb.

Roon client on iPad/MacBookPro

Roon Server & HQPlayer on Mac Mini 2.0 GHz i7 with JS-2

LPS-1 & ultraRendu → Lampizator Atlantic → Bent Audio TAP-X → Atma-sphere M60 → Zero autoformers → Harbeth Compact 7 ES-3

Link to comment
@Freann, I can do that test, but I only have DSP7200s to listen to right now, so everything is digital. What renderer are you testing with?

 

If those two players (HQ and A+) are not upsampling, not converting, and not tweaking, and negotiate with the renderer in the same way, and send the exact same data to the renderer, and the renderer can correct for jitter by reclocking, then they should not sound any different. If the data and timing going to the renderer is identical, and that renderer must follow the rules of physics: same inputs, same outputs. This is basic deterministic physics. The effects of quantum mechanics are not making HQ Player magic over A+.

 

If you hear a difference, then something is changing. I believe you that you hear something different, and your ears are surely better than mine. However, my SPDIF recording test should be able to determine exactly what is changing in the stream.

 

Now, there is one more weird thing that can happen. If you renderer has a digital output and you record it with both players, and both have the exact bits, then there is still 1 more location for variable quality, and it is internal to the renderer. Here is an example of one of those pieces of variability: Some renderers have an internal 32bit PCM D->A converter. Some renderers have an internal 1bit DSD D->A converter. If you feed both the identical PCM data, then their digital outputs will be the same, but the second one will have to internally convert PCM to DSD. I would bet that HQPlayer can do that better than some (if not most) hardware devices out there, but I've not done any tests on this.

 

Hi Danny

 

I think you will find a lot of people disagreeing with the idea of bit perfect = bit perfect and will sound the same. although logically this makes perfect sense, based on experience by many audiophiles this is just not true. I do a lot of beta testing for PS Audio with the DAC and Bridge (Ethernet to I squared S interface) We have found that different firmware versions sound significantly different even though they are all bit perfect. This variation even applies to the same firmware complied a number of different times.

As far as I can tell there is not way to test a digital stream and guarantee the two different bit perfect streams will sound the same.

 

I would suggest you do some investigation into this phenomena because it will greatly influence the success of Roon amongst the sound quality fanatics (of which there are many :))

Link to comment

I have no doubt that bit perfect can sound different, but it's where in the chain once places the blame that I take issue with.

 

This is a physics and information theory problem -- When A talks to B, and B talks to C, if B gets the same information from A every time, B can choose to send different information to C, but A can not impact that decision.

 

If Roon/JRiver/A+/etc (A) send Bit Perfect data to your DAC (B), your DAC can choose to send different things to your speakers/ears/etc.. ©, but no matter what A does, it can not change B's behavior because it sends the exact same informatino there. There just isn't something different passed along to allow that to occur.

 

I'm not saying that there aren't hidden variables, or that B is working in isolation, but only that A can't impact B in any way other than sending it information, and if that information is identical between two different As talking to the same B, then A must be taken out of the equation for determining where the difference at C is coming from.

 

So how can B make differences in what it sends to C when the input from A is the same? Things like noise, interference, quality of clocks, timing, jitter, etc are all "hidden variables". Obviously they can and do make a difference. But A1 and A2 can't impact those differences at all different if they send the same bit-perfect information to B.

 

Roon's public expertise is UX and Music data, but remember, we are not new to the world of high quality audio. The entire team has worked side by side on projects and with minds who are the top of the field. You may or may not agree that Meridian speakers and systems are "the best", but no one can argue that Bob Stuart doesn't know his shit :-)

 

We are working directly with PS Audio to add RoonSpeakers to their products. I hope you enjoy the fruits of that collaboration.

Link to comment
I have no doubt that bit perfect can sound different, but it's where in the chain once places the blame that I take issue with.

 

This is a physics and information theory problem -- When A talks to B, and B talks to C, if B gets the same information from A every time, B can choose to send different information to C, but A can not impact that decision.

 

If Roon/JRiver/A+/etc (A) send Bit Perfect data to your DAC (B), your DAC can choose to send different things to your speakers/ears/etc.. ©, but no matter what A does, it can not change B's behavior because it sends the exact same informatino there. There just isn't something different passed along to allow that to occur.

 

I'm not saying that there aren't hidden variables, or that B is working in isolation, but only that A can't impact B in any way other than sending it information, and if that information is identical between two different As talking to the same B, then A must be taken out of the equation for determining where the difference at C is coming from.

 

So how can B make differences in what it sends to C when the input from A is the same? Things like noise, interference, quality of clocks, timing, jitter, etc are all "hidden variables". Obviously they can and do make a difference. But A1 and A2 can't impact those differences at all different if they send the same bit-perfect information to B.

 

Roon's public expertise is UX and Music data, but remember, we are not new to the world of high quality audio. The entire team has worked side by side on projects and with minds who are the top of the field. You may or may not agree that Meridian speakers and systems are "the best", but no one can argue that Bob Stuart doesn't know his shit :-)

 

We are working directly with PS Audio to add RoonSpeakers to their products. I hope you enjoy the fruits of that collaboration.

 

And I am not doubting that. This is on one DAC. I am going to try my main system which includes an MSB Diamond Plus tomorrow, but I will have to install a different SSD with Win 8.1 as on that computer I am running Server 2012 R2. Right now I am also running a customized ASIO driver on the MSB as well, so we will see what that shows.

 

I am not giving up on Roon. I love it and am I know you guys will integrate and work with as many as possible to meet everyone's desires whether be real, perceived or both.

Link to comment
oh crap!!!!!

 

@priaptor, do you know about this negotiation bug Roon has?

 

The problem is actually kind of strange, and completely our fault. It arose from not testing with enough equipment before we launched. I fear you might be running into it and therefore be experiencing your content differently than you expect with Roon.

 

Brian posted this explanation of the bug:

 

 

 

This might be why your Roon + CoreAudio + Chord output is not sounding as good as JRiver w/ no DSP + ASIO + Chord. ASIO and JRiver w/ no DSP have nothing to do with it, it's just a stupid DAC negotiation bug :-(

 

If this is the case, I apologize profusely and hope you give you listening test another round when you get the update this week.

 

Danny, no apologies. I am psyched. This is round one for you guys. This is an amazing interface that has given a whole new way of interfacing with my library and I am having a ball

Link to comment
I have no doubt that bit perfect can sound different, but it's where in the chain once places the blame that I take issue with.

 

This is a physics and information theory problem -- When A talks to B, and B talks to C, if B gets the same information from A every time, B can choose to send different information to C, but A can not impact that decision.

 

If Roon/JRiver/A+/etc (A) send Bit Perfect data to your DAC (B), your DAC can choose to send different things to your speakers/ears/etc.. ©, but no matter what A does, it can not change B's behavior because it sends the exact same informatino there. There just isn't something different passed along to allow that to occur.

 

I'm not saying that there aren't hidden variables, or that B is working in isolation, but only that A can't impact B in any way other than sending it information, and if that information is identical between two different As talking to the same B, then A must be taken out of the equation for determining where the difference at C is coming from.

 

So how can B make differences in what it sends to C when the input from A is the same? Things like noise, interference, quality of clocks, timing, jitter, etc are all "hidden variables". Obviously they can and do make a difference. But A1 and A2 can't impact those differences at all different if they send the same bit-perfect information to B.

 

Roon's public expertise is UX and Music data, but remember, we are not new to the world of high quality audio. The entire team has worked side by side on projects and with minds who are the top of the field. You may or may not agree that Meridian speakers and systems are "the best", but no one can argue that Bob Stuart doesn't know his shit :-)

 

We are working directly with PS Audio to add RoonSpeakers to their products. I hope you enjoy the fruits of that collaboration.

 

Hi Danny,

 

Different Bit Perfect Software does sound different. Here is an interesting interview with John Swenson:

 

Q&A with John Swenson. Part 3: How bit-perfect software can affect sound | AudioStream

Steve Plaskin

Link to comment
Hi Danny,

 

Different Bit Perfect Software does sound different. Here is an interesting interview with John Swenson:

 

Q&A with John Swenson. Part 3: How bit-perfect software can affect sound | AudioStream

 

I have read this before, and it speaks of nothing new.. only jitter and noise. If your USB DAC has an external clean power supply, an decent buffer, and reclocks from a clean high quality crystal, all these issues are moot.

 

The jitter issue is not really an issue at all with any USB or network device worth anything, as they all should be implementing a buffer and not driving the DAC conversion based on the timing from the sender, but instead from their own much cleaner clock. SPDIF inputs are a different story, but reclocking the SPDIF input is the right way to avoid this as well.

 

Also, by focusing on compiler optimizations and memory cache misses, he's missing the elephant in the room; the Ethernet and WiFi PHY are both insanely noisy compared to anything you can impact on the CPU in software, and usually they are less shielded.

Link to comment
I'm trying to figure out what the community here means by "SQ".

 

If this is matter of accurate reproduction by your endpoint, then this shouldn't be a concern. The definitive test for accurate reproduction is to have Roon speak to your endpoint, and then record your SPDIF output and see if the bits match up with your source. We've done this exact experiment many times, and the results are always perfect. We've also done this with JRiver and Audirvana+, and they are also perfect. You must run in exclusive mode in Roon, or direct mode in the others to bypass the OS mixer....

 

Please help me understand which "SQ" you all are talking about, because there seems to be two definitions in play. Accuracy and DSP...

If there is something else I'm missing, please do explain. You guys are an invaluable treasure trove of experience that can't be learned. Please, fill me in :-)

 

First off, thank you for speaking directly with us here and being open to all the suggestions. I am in the camp of music SQ perfection being the first priority of a music playback software, but I understand that is not necessarily Roon's core use. Let me take a stab at the SQ question as some is buried in heated conversations here and there are many opinions.

 

1. Bit perfect playback is the start, a must and a given for all but the DSP packages like HQ Player (which is not bit perfect on at least a Mac) or if there are bugs involved like the one mentioned

 

2. However, the interplay between OS, OS tweaking, background process reduction, hardware (memory playback, SSD vs spinners, fanless, USB regenerators, etc.), electrical pulse impacts, data burst noise, receiving chips and design at the DAC inputs, and the music playback software impact the sound quality coming out of the DAC. Hence you will find many here have a SQ preference even between different bit-perfect playback software. Some tax the CPU more, some use memory differently, some use more threads and processes, etc. For me Amarra in playlist only/cache memory/killed finder mode is the absolute king in terms of bit-perfect sound quality as it is the least fatiguing on a Mac, and noticeably better to me than Audivarna without DSP, iTtunes and JRiver. Others on the Windows side prefer e.g. JPlay or XXHighend.

 

It comes down to a general computer being a tough/noisy thing to make a dedicated audio source out of, hence all the tweaking additional hardware options and a site like this to try to make it better. So sound quality is not just the bit-perfect song, but the impact that the interplay of software, hardware and electrical has on e.g. noise floor and timing as well.

 

Cheers

Link to comment
It comes down to a general computer being a tough/noisy thing to make a dedicated audio source out of, hence all the tweaking additional hardware options and a site like this to try to make it better.

 

Agreed 100%.

 

Not liking stop gap solutions, I want a real fix, not a band-aid. The right solution is to get the power clean, the crystal accurate, the buffer isolating, all your DAC chips and amplifiers as good as you can, and then send the ideal format to each as is required.

 

Our yet-to-be-released RoonSpeakers protocol is designed with this in mind. To get the computer as far away from the endpoint as possible, while still allowing the endpoint to be in full control of the audio reproduction. However, unlike UPnP, we don't want to put extra burden on the endpoint of decoding various file formats, so RoonSpeakers is a hybrid protocol, that works like AirPlay/SongCast, in that it pushes PCM/DSD data, but it allows the remote side to control the timing characteristics (the clock). Full negotiation, control, and feedback is built in this protocol as well. It is also extremely lightweight so the endpoint does not need a powerful noisy CPU. It also pulls codec patent licensing out of the endpoints, allowing them to be cheaper too!

 

Brian or I really need to write a blog post about this stuff :-)

Link to comment

..... AND .... to get this thread back on topic -- have you played with Roon?

 

Besides SQ and the "prefer local metadata" feature, what other feedback/impressions do you have? We want to improve this stuff and we need your feedback. I know a lot of you want hardware support too. Hardware guys move slow due to the nature of their business and product lifecycles, but it's coming.

 

If you haven't tried Roon yet, why not? Seriously, I want to know and I want you to let me do something about it :-)

Link to comment
I have read this before, and it speaks of nothing new.. only jitter and noise. If your USB DAC has an external clean power supply, an decent buffer, and reclocks from a clean high quality crystal, all these issues are moot.

 

The jitter issue is not really an issue at all with any USB or network device worth anything, as they all should be implementing a buffer and not driving the DAC conversion based on the timing from the sender, but instead from their own much cleaner clock. SPDIF inputs are a different story, but reclocking the SPDIF input is the right way to avoid this as well.

 

Also, by focusing on compiler optimizations and memory cache misses, he's missing the elephant in the room; the Ethernet and WiFi PHY are both insanely noisy compared to anything you can impact on the CPU in software, and usually they are less shielded.

 

Having listened to many high quality USB DACs with an optimized computer setup, differences exist in the sound of bit perfect software.

 

I'm looking forward to your future enhancements to Roon.

 

Thanks Danny

Steve Plaskin

Link to comment
Danny, no apologies. I am psyched. This is round one for you guys. This is an amazing interface that has given a whole new way of interfacing with my library and I am having a ball

 

I totally agree with Priaptor. I had a great time using Roon this AM and truly enjoy using it.

Steve Plaskin

Link to comment
You are correct, that is what we'd say :-) Roon is pretty to look at and fun to use, but it really shines when you have all the extended data. That said, we are working on some features that will help you do what you want.

 

Right now, there is a terrible process deep in the correction popups, that lets you revert back to your data 100% and throw away our data completely. it is our opinion that this is exactly where this belongs, because throwing away our extended data should only be done when we messed up.

 

More importantly, we NEVER throw away your groomed data. Our database is structured as 3 layers:

 

1) your directory/file structure + file tags

2) the metadata from our metadata servers

3) edits you make to the metadata

 

You see the data from #3, and if it doesn't exist, you see #2, and if that doesn't exist, you see #1. This is not done as a whole, but on a field by field basis.

 

#3 isn't really exposed right now, and we are working on a full database editor that will let you create your own works, performances, etc, and edit pretty much any piece of data you see.

 

#2 is what you are complaining about. The feature I'm actually working on at the moment lets you reverse the priority for certain fields of #1 vs #2. For example, right now, if you get a metadata match with our servers, we hide your album title and artwork. This new option will let you keep our credits data, or classical composer/work/performance structure, but use the album title + artwork from your tags.

 

We feel this is the best of both worlds. No product, or groomer, has depth to their metadata like we do, but your tags are built the way you want them. This lets the end experience include both.

 

I wish we could have launched with this stuff, as a bunch of potential Roon members want this, however, we had to cut some features from the list as we moved our launch up from August to May. Be assured, we understand what you desire, and the tools to accomplish it are coming!

 

I agre with your suggested approach - it was exactly what I had in mind :) as it will let me find my albums using a structure I'm used to, but still enable the advanced features unique to Roon.

 

Can't wait to try it this way.

John Walker - IT Executive

Headphone - SonicTransporter i9 running Roon Server > Netgear Orbi > Blue Jeans Cable Ethernet > mRendu Roon endpoint > Topping D90 > Topping A90d > Dan Clark Expanse / HiFiMan H6SE v2 / HiFiman Arya Stealth

Home Theater / Music -SonicTransporter i9 running Roon Server > Netgear Orbi > Blue Jeans Cable HDMI > Denon X3700h > Anthem Amp for front channels > Revel F208-based 5.2.4 Atmos speaker system

Link to comment
..... AND .... to get this thread back on topic -- have you played with Roon?

 

If you haven't tried Roon yet, why not? Seriously, I want to know and I want you to let me do something about it :-)

 

Real simple for me I am dying to try it but I need it to be compatible with the PS Audio Bridge and Audio Optimizer on Windows Server 2012 R2.

 

Sounds like it may be a few months before I can dive in, I have been waiting for an alternative to JRiver I find the attitude of that company very hard to stomach.

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...