Recent Roon versions have displayed the 24 bit decoded bit depth for lossy audio files, which no longer have an inherent bit depth and can be decoded to any arbitrary bit depth. The bit depth that you point out in the file info was the input bit depth prior to lossy audio encoding.
I understand the bit depth issue but I wonder why Roon displays “256 kbps” or “320 kbps” for the majority of my AAC files. I cannot see any difference and I have no idea WHEN “1 kpbs” resp. “256” kpbs" will be presented to me…
An observation: are some of your files variable bit rate (VBR)? 256kbps and 320kbps are continuous bit rates (CBR) whereas 242kbps is not. Roon is converting the lossy file to PCM.
You are right.
All of the files with “1 kbps” presented by Roon are encoded with VBR AAC. That seems to make up the difference.
Anyway, I had expected something like “~250 kbps” in which the “~” sign would signal that Roon cannot present only one value for the bitrate tag…
…whereas “1 kbps” tells me that the file is encoded really very lossy, i.e, very bad
Could you upload one of the media files being identified as 1 kbps to a sharing service like dropbox and then PM me a link? I’m going to have the QA team take a look at this.
Hi, did this get resolved? I’ve got the same issues, i.e. anything I convert with dbpoweramp to VBR AAC is being shown with a bitrate of 1 kpbs while all other audio players I’ve checked correctly determine the bitrate at ~224 kbps
Can you please upload a sample media file of this behavior to Dropbox / Google Drive and send us a link?
here is a dropbox link from my side too:
It is a VBR AAC encoded file with ~217 kbps, shown as “1 kbps” inside Roon…
Thanks for sending these files over @KPB & @SSt, let me get them over to QA for closer inspection!
I wanted to touch base with some good news, which is that our technical team has been able to reproduce this behavior and we’ve opened up a bug report with our developers.
While I can’t say for certain when this bug will be fixed, getting things reproduced in-house is a critical first step, and I will keep this thread up to date as the team passes along feedback and work begins to get this resolved. Thanks again for the report!
thanks, much appreciated.
given that’s it’s been quite some time since your technical team could reproduce the issue, is there any ETA yet on when it’ll be fixed?
I took a look at our internal tracker today, and I can see that your ticket is still in our development queue.
This means our developers are still planning to look at this, but we don’t yet have a timeframe for when that’s going to happen.
Once the ticket has been scheduled and work begins, I’ll have a better sense of timing here. Thanks in advance for your patience!
Please could we have an update on this issue? Is it still a long way down the developers’ list? 4 years is quite a lengthy wait.
Hi @Brian_Laycock ,
Thanks for the reminder on this one. Are you seeing this issue on your end as well?
I can go ahead and add the ticket to the review queue once more, but if you have media that reproduces this issue, can you kindly send it to us here for review and let us know once uploaded? Thanks!
Yes. Unfortunately, I can see this issue as well on a number of files that I ripped using dBpoweramp a few days ago using variable bit rate. I’ve uploaded an example to the specified location as you asked. Attached are a couple of screen shots from the Roon and Apple Music apps showing the difference in reported bit rates for the same file for you too.
Thanks, @Brian_Laycock ! I’ve gone ahead and bumped the ticket with your file and new details and have placed it in the review queue!