Wonderful!

[pierrepoulpe]

Hello Nicholas,

I started to retro-engineer a few months ago qobuz connect, after looking for existing work. At that time, found nothing. Refreshed my search today before getting back on this project, and happily found your project!
Did you get access to any documentation, ot did you retro engineer too? I would be happy to communicate privately if you wish.
I'll try to make your code work locally, and plug it to mpd qobuz plugin...

Many Thanks!!

[pierremarc]

Definitely a fantastic idea.

I do not have a lot of spare time, but I’d be willing to help on this (the web client turns my x230 into a heating system pretty fast), at minimum testing things out.
Plus, I can dig some rust here and there.

[nickblt]

This has been mostly reverse engineered and some poking around at this other project https://github.com/tobiasguyer/StreamCore32

I'm slowly working towards getting qobuz connect to work locally with my sonos speakers, so all the features I implement are geared towards that. Happy to take pull requests if others find what I've built useful and need other things implemented.

[pierremarc]

Good goals!

Here I use the web player on firefox on a spare x230 as a renderer, but the thing is heavy and fans are blowing fulltime, that's annoying.

I'll start gluing together your lib and https://github.com/pdeljanov/Symphonia/tree/master/symphonia-play with ratatui to get a feel of how the whole thing could work.

[andresmlna]

@nickblt

Hi.

Is useful for you the Qobuz Connect SDK? It's a c++ linux library (.so format).

[pierrepoulpe]

The work @nickblt is so complete that, I think, it's not anymore really useful. And a binary is the hardest way to retro engineer.
But do you know what Qobuz delivered to manufacturer? Only a binary and its .h? And/or a full documentation of the protocol?

For information, I did my retroengineering by exploring, manufacturer by manufacturer, the firmwares updates, if by chance I founded some readable language. And I found the volumio app, delivered as a full Linux os on an IMG file. I ran it in a virtual machine, been able to run network capture with wireshark running on host. Then I used it while watching what was going on on network level.

[nickblt]

In case there is interest in my implementation of this lib i pushed my work on the sonos lib here: https://github.com/nickblt/sonos-websocket and the work on the sonos<->qobuz-connect bridge (which uses both my sonos lib, and qonductor) here https://github.com/nickblt/qonos

[roderickvd]

Hi Nick,

Congratulations on your progress and the looks of your API! I've been working on a headless Qobuz Connect player in Rust myself, to run on a Raspberry Pi for example. Instead of having duplication in the Rust audio ecosystem, why not unify and orchestrate our efforts?

I've got a private repo where I had also worked out the protobufs, and was making progress to building the player around it. I'm maintaining librespot for Spotify Connect and created pleezer for the now defunct Deezer Connect. And so I was taking pleezer as basis, replacing Deezer for Qobuz.

The repo is private because I hadn't gotten it to the scope nor level of quality yet that I wanted to, but I can grant you access if you want to see. So far what I got working on top of the protobuf sending and receiving is:

• runtime extraction of the app ID and secret from the public web player
• getting the CDN URL for downloading the tracks
• next steps would be to hook those URLs up in the existing player and download manager

Today, your treatment of the protocol is more advanced than what I have. And I see that we have complementary goals: I'm looking to build a headless player, you to bridge to Sonos speakers.

Here's what I'm thinking. What if we'd propel your qonductor towards "the definitive Rust Qobuz Connect API" crate - helping out together - with you continuing to build qonos on top of it and me the headless player?

Cheers,

Roderick

P.S. Your mDNS discovery capability is interesting. Mine didn't implement that, rather just announces itself on the Qobuz Connect web socket as available device.

P.P.S. I had a brief look at StreamCore32 but stayed away from it, as its GNU license isn't what I'm looking for.

[nickblt]

Sounds good to me!

The mDNS stuff is nice because you don't need any credentials. Once you broadcast availability (Without any creds except the app id) and a qobuz client selects that advertised player the credentials are sent over http (the http callback being part of that mDNS advertisement) to initiate the websocket or http api with.

I'm also very open to breaking changes to the current qonductor exposed functions and then solidifying it with a v1 release.

[delleceste]

That's great! Let’s hope Qobuz doesn’t encrypt the handshake to allow access only to officially approved firmware... for example ! Great job

[pierrepoulpe]

That's great! Let’s hope Qobuz doesn’t encrypt the handshake to allow access only to officially approved firmware... for example ! Great job

I think it would be super difficult for them. They managed to get dozens of manufacturers supporting this protocol, on device that are not all easy to keep up to date. Changing anything in the protocol would mean breaking a functionality for many end users...