Jump to content

Cebolla

  • Content Count

    2743
  • Joined

  • Last visited

  • Country

    United Kingdom

1 Follower

About Cebolla

  • Rank
    Cepa Computensis Musicalis

Recent Profile Visitors

12204 profile views
  1. I think we are at cross purposes here. Just to be clear - on a TIDAL HiFi quality connection, ie, not a TIDAL Masters quality connection: - selecting lossless CD resolution (16bit/44.1kHz) non-MQA tracks for streaming (unfortunately TIDAL are currently actively getting rid of those in favour of lossy MQA-CD ones, so not many left to select), TIDAL's online server provides those unscathed; - selecting lossy MQA-CD (ie, MQA encoded to be distributed with a resolution of 16bit/44.1kHz.) tracks for streaming, TIDAL's online server provides those unscathed; - selecting
  2. Ah - been there, done that! Unfortunately you've picked up a bit of misinformation. The 16-bit/44.1kHz resolution mentioned for proposed hi-res MQA Radio Paradise streams derived from the 24-bit/96kHz source files was an error. It was actually corrected to the expected 24-bit/48kHz in a later post on the same RP thread, after I questioned it: https://radioparadise.com/community/forum/post/3901729
  3. MQA-CD file tracks should be provided unscathed on the TIDAL HiFi quality (16bit/44.1kHz only) connection as they are already distributed at 16bit/44.1kHz,, but the hi-res MQA ones (which in your 88.2kHz case are distributed at 24bit/44.1kHz) should be corrupted as they're provided mangled to 16bit/44.1kHz.
  4. Looks like you/we are going to be happy: https://radioparadise.com/community/forum/post/3901944
  5. From memory, I believe part of JC's instability problems with the Rendu stemmed from having to manually change its output mode whenever its AirPlay support was occasionally required and then back again for Roon its support. It's a shame that Sonore don't provide seamless constant automatic support for AirPlay for their streaming devices in parallel with the other supported streaming mechanisms, so avoiding the need to manually change the output mode, l can't think of any other AirPlay supporting streamer that requires a manual override setting for whenever AirPlay is needed (that i
  6. Crikey, hope you're not suggesting that the Q should be in Union Jack colours - I'm just about to tuck into my tea here!
  7. Bill's corrected that to a 24/48 hi-res MQA stream produced from the 24/96 hi-res source, in response to the query.
  8. From the other parts of Bill's post you quoted it's also clear that RP are not sourcing the MQA stream from MQA material and are instead using an MQA encoder to produce the MQA stream from scratch: Interestingly, it appears that it's going to be an MQA-CD 16bit/44.1kHz only stream, even when produced from the planned 24bit/96kHz hi-res source.
  9. Several years back AIFF files from Qobuz were unplayable with the Pioneer streamers of the day even though other players (including rather ironically JRiver MC 19) seemed unaffected by them. It was due to the unconventional data structure Qobuz were using for their AIFF files, placing the optional chunks before the compulsory chunks: . It's possible your Qobuz AIFF files are the similarly structured and therefore the catalyst for the FLAC conversion issue in MC 27.
  10. Separate parallel streams, so with the same playlist - one sourced from MQA material; the other from non-MQA, Really? Unlikely. It'll be far easier to source both streams from the same MQA material and just run a bit depth reducing downsampling (where necessary) hi-res MQA mangler to produce the 16bit/44.1kHz 'non-MQA' stream - similar to what TIDAL already does on its HiFi quality connection (as opposed to its Masters quality connection). Don't be surprised if some MQA-CD tracks start 'appearing' on the 'non-MQA' stream.
  11. Not a very good spell checker/corrector, I'd suggest, seeing that it can't sort out 'always' being misspelt. Can forgive Qobuz being incorrect - can't make that look any worse. Perhaps it's on counterfeit goods language mode 😀 Not sure what function you are using on the Qobuz Android app to invoke Share - you should be getting other Andoid apps to share to, not devices on the network:
  12. Does the lower case 'u' mean some new (lower?) standard for UPnP (Universal Plug and Play) or perhaps you mean 'micro PnP' (whatever that may be)? 🙃 You can actually combine both apps on Android, ie, use the Qobuz app with Android's built-in share feature to share to the BubbleUPnP app the tracks you're interested in playing on the UPnP/DLNA streamer.
  13. No worries. It may also be worth checking to see if the installed LMS's UPnP/DLNA Bridge plugin can be enabled to use with Volumio's upmpdcli UPnP renderer (and therefore its native MPD player that's pre-configured with the SHD hardware). Would avoid any conflict and/or compatibility issues with the SHD hardware if a Squeezelite player was instead installed to be used in parallel to the existing MPD.
  14. @Ultrasonic, does the miniDSP SHD's Volumio allow installation of Volumio plugins containing applications that should still be able to provide Qobuz access, such as the BubbleUPnP Server or the Logitech Media Server (LMS)? Edit: Looks like at least LMS is possible to install on the SHD via the appropriate Volumio plugin, going by this thread on the miniDSP forum: https://www.minidsp.com/forum/shd-series/17077-shd-and-logitech-media-server
×
×
  • Create New...