Am i missing something or is this just unnecessary processing?
Hmm, it seems that’s because the Opus format doesn’t support 44.1kHz sample rate (only 8, 12, 16, 24 and 48kHz), so for full bandwidth audio, it’s always going to be 48kHz. Since it’s a lossy compression, the back and forth sample rate conversion is the least you need to worry about.
1 Like
Thanks for the detail on opus I didn’t know that it doesn’t support 44.1.
Still the extra processing on the endpoint (iPhone in this case) is not welcome. Has to impact battery life during playback you’d think.
If you have the bandwidth, change the streaming quality to original and it will stream the unchanged flac
Well it’s mobile data, it’s up and down. Lossy works better than flac on that front.
I presume you mean it is more efficient? Uses less data?
Less data but more processing onthe endpoint, at least some of which seems like it could be reduced/removed.
What’s interesting is the choice of Opus (over MP3 or AAC), which doesn’t support the rate at which the vast majority of music is encoded.
2 Likes
It’s it’s supposed to audibly transparent at the higher bit rates and it also has no licensing issues which the others can have especially aac. Which is why ffmpeg is a user install as it can’t be shipped with paid product. Plex use the same for audio codec in PlexAmp. It was raised before and all discussed by Brian when it was only in early access so search you will find his post. I personally think it sounds very good indeed so have no issues but have raised the need for it to resample on the device but did forget Its limited to 48k which is a pain considering Bluetooth is 44.1 on my phone. But if you use LDAC ARF will upsample so still pegging the battery.
1 Like
I agree it sounds good. But as @Marian points out its just a shame that it doesnt support all rates.
Since ARC is most likely going to have to work with varying output devices, including Bluetooth etc, it would have made sense to choose something that could be resampled on the core to anything that that the endpoint needed. So reducing or removing the need for the endpoint to also have to resample.
You would not want it to upscale to 96/24 for LDAC though would you as no free compressed codec supports it. Would you want to pay more to use ARC as it would need an increased cost to pay for AAC license to allow compressed 96k. Phones would resample locally for BT for other apps anyway, you just dont notice it as they have no signal path.
Not sure I understand what you mean about 24/96. If the source is 16/44 (or higher) FLAC then it gets transcoded to lossy on the core when you have ‘Balanced’ etc. selected in Settings. My point is that once you have transmitted it seems wasteful to then have to up/down/re-sample again on the endpoint. Just send it in the target format.
Of course I appreciate there may be circumstances where it is impossible to avoid this, but on the face of it the screenshot in the OP doesnt seem like one of them. It could just have been sent as 16/44 in a lossy container, rather than 24/48 which then needs more resampling before playback.
Anyway I am labouring the point, since I now know that Opus (bizarrely) has no support for 44.1khz.
LDAC is a bluetooth codec. Its 96/24 currently arc will upsample on the device to give the BT headset this resolution. If you want this done on the core then it would need to receive 96/24 which requires a codec that supports it which AAC is the only one for compressed formats or your sending uncompressed 96/24 which is undesirable. The amount you loose from 44.1 to 48 to 44.1 will negligible if any given its done in 64bit floating point and its crying over split milk as its a lossy file where you gaining bit depth. If you want it as it is then you need to use Mp3 or ogg which are not as good quality so what would you gain? Nothing most likely. AAC is not free it needs to be paid for so the costs would need to be recouped which would add to Roons yearly cost. Something non ARC users would not be happy to have to fund I imagine.
OK I see. That is not the situation that I was talking about though. Clearly if you play 24/96 music then it is either sent in original format or downsampled on the core. Yours is an example of a situation where if you transcode on the core you will necessarily have to upsample on the endpoint. I have no issue with that, nor did I express one.
My point was specifically about a situation where we see these operations were happening apparently unnecesarily, as per the title of the thread. And as I pointed out I know understand the limitation of Opus which causes the issue I observed.
I haven’t read the thread, but MP3 is basically transparent at 256kbps, so I still question the choice of Opus.
Hmm not found that with mp3 myself at higher 320 its a lot better but I find AAC does sound much better. As thats off the card for this as it costs to license then I think they went for the next best solution and I find it sounds very good. BT or via DAC.
To be fair I’ve never done a proper blind A/B test myself.
But most of the changes (between MP3 and AAC) relate to low bitrates and speech.
See sections 4.1 (efficiency) and 4.2 (quality) of this paper from Karlheinz Brandenburg - who lead the development of both codecs.
Also, rather than a total ground up redevelopment AAC was more a chance to rebrand the core MP3 work and drop the use of an overly complex filter bank that the MPG has suggested they use to win their endorsement.
It’s quite a story, if you fancy a good read, one third of this book details the rise of MP3 (and AAC) and the bureaucracy and vested interests that led to the MP3 decoder being made open.
1 Like
This BBC paper always seems relevant when discussing perceived differences between high bitrate AAC and lossless encodings.
Twelve audio samples were used in the test, which included orchestral, jazz, vocal music and speech. A total of18 participants with various experience levels took part in the experiment. The results showed no perceptible difference between lossless and AAC-LC 320 kbps encoding.
I suppose this just makes more sense to me if you are choosing a lossy setting anyway;
Edit: I know it’s not quite the same as this is qobuz sourced, but the point remains
but if listening on non BT headphones the phone would upsample to 48/24 on Android and iOS. Which is the argument Brian made for choosing Opus. I don’t have any iPhone headphones but it would do the same for those as the internal rate is 48/24 on both iOS and Android. Depends on what you use you cant please everyone.
1 Like