Official Qobuz Issues Thread

[nbpf]

On 7/26/2018 at 3:46 PM, The Computer Audiophile said:

Definitely some issues with playback here. The second track on the album was skipped. Plus, no metadata appears on the Rossini display  or the dCS app.

If you are using MPD for playback, expect track skip issues on long tracks and when connecting to certain Qobuz servers, please see

 

https://opensourceprojects.eu/p/upmpdcli/tickets/11/

 

and

 

https://github.com/MusicPlayerDaemon/MPD/commit/1ca1269a59e36fc4c91fa9aca93ac6067d9274bf

 

So far Qobuz has not reacted to any of my issue reports. Thus, I am going to cancel my Qobuz Sublime subscription for the upcoming season. 

[nbpf]

2 minutes ago, The Computer Audiophile said:

No MPD use in this setup right now. 

If you are using BubbleUPnP Server or a software that attempts at throttling the stream during playback, you might be experiencing the same issue. Apparently the Qobuz app downloads tracks to large buffers instead of throttling the stream, see  

https://github.com/MusicPlayerDaemon/MPD/commit/1ca1269a59e36fc4c91fa9aca93ac6067d9274bf. I have never experienced any issues with the Qobuz app in my network.

[nbpf]

5 minutes ago, The Computer Audiophile said:

My DLNA testing was with the Qobuz desktop app for macOS and a dCS Rossini DAC.

In this case your person in charge is the Qobuz technical support. Good luck, its miserable!

[nbpf]

3 hours ago, David.. Qobuz, Hi-Res Music Evangelist said:

Hi Rick, I was actually on the launch team for Tidal and remember some of the glitches well. Of course, they were eventually fixed. I expect we'll have a few too as streaming hi-res isn't not the easiest thing to set up, but I will be available as much as possible and know that if and when glitches occur, there are a bunch of really smart dedicated people working on a solution. I'm pretty sure that's true of all of the streaming services. I've found this frustration many times with upgraded OS, but find they too work as fast as possible to remedy the various and sometimes random unintended problems.

Living in a world of immediate gratification is sometimes madding when we don't see the guys on the other end fixing difficult problems in out time frame.

Streaming errors might be difficult to reproduce and hence to fix. But there are errors that are perfectly reproducible and none cares about at Qobuz. All .tar files I have downloaded from Qobuz generate a " tar: A lone zero block at ..." at unpacking. The zero block position "..." is different for different files but constantly the same for the same .tar file. I have reported this error many times and never received any feedback. Not even a notification that they had reproduced the error. I have never seen this problem with .tar downloads from prestoclassical, hyperion, etc. or, indeed, with any other .tar file. 

[nbpf]

8 hours ago, David.. Qobuz, Hi-Res Music Evangelist said:

If you're here to play Stump the Chump, you win. Been streaming foe many years, but the .tar issue in which you speak if not on my radar.

Do you have an example?

Sure, take for instance the last album I bought from Qobuz. This is Mahler's 5th by Adam Fischer and the Düsseldorfer Symphoniker. The downloaded .tar file is  Qobuz-Adam_Fischer_Dusseldorfer_Symphoniker-Mahler_Symphony_No_5.tar. Now unpacking this file yields

 

nicola@cirrus:~/share/audio/originals/qobuz$ tar xf Qobuz-Adam_Fischer_Dusseldorfer_Symphoniker-Mahler_Symphony_No_5.tar 
tar: A lone zero block at 1345140
nicola@cirrus:~/share/audio/originals/qobuz$

 

We can try to be a little bit more verbose to see if we can get some more information:

 

nicola@cirrus:~/share/audio/originals/qobuz$ tar xfv Qobuz-Adam_Fischer_Dusseldorfer_Symphoniker-Mahler_Symphony_No_5.tar  
Adam_Fischer_Dusseldorfer_Symphoniker-Mahler_Symphony_No_5/
Adam_Fischer_Dusseldorfer_Symphoniker-Mahler_Symphony_No_5/01-01-Gustav_Mahler-Symphony_No_5_in_C-Sharp_Minor_I_Trauermarsch_In_gemessenem_S-SMR.flac
Adam_Fischer_Dusseldorfer_Symphoniker-Mahler_Symphony_No_5/01-02-Gustav_Mahler-Symphony_No_5_in_C-Sharp_Minor_II_Sturmisch_bewegt_Mit_grosst-SMR.flac
Adam_Fischer_Dusseldorfer_Symphoniker-Mahler_Symphony_No_5/01-03-Gustav_Mahler-Symphony_No_5_in_C-Sharp_Minor_III_Scherzo_Kraftig_nicht_zu_s-SMR.flac
Adam_Fischer_Dusseldorfer_Symphoniker-Mahler_Symphony_No_5/01-04-Gustav_Mahler-Symphony_No_5_in_C-Sharp_Minor_IV_Adagietto_Sehr_langsam-SMR.flac
Adam_Fischer_Dusseldorfer_Symphoniker-Mahler_Symphony_No_5/01-05-Gustav_Mahler-Symphony_No_5_in_C-Sharp_Minor_V_Rondo_Finale_Allegro-SMR.flac
tar: A lone zero block at 1345140
nicola@cirrus:~/share/audio/originals/qobuz$

 

As you can see, the error is perfectly reproducible but we do not get any clue about what's wrong with the download. As a matter of fact, the content of the .tar archive seems to be fine. At least I do not hear any artifacts at replay time. Still, is is very annoying to get these false positive every time I buy a new album. If the difference is just one or two Euros, I typically buy from prestoclassical to avoid being annoyed by the error.

 

I suspect it is a systematic error because, as reported, it shows up on all Qobuz downloads on my system. I can provide dozens of similar examples and I have never seen this error on downloads from prestoclassical or, indeed, in any other .tar file. I have reported the issue to Qobuz a number of times and detailed my tar version, OS, etc. I never received any feedback from Qobuz. 

[nbpf]

7 hours ago, David.. Qobuz, Hi-Res Music Evangelist said:

I did check on this and although you may see a weird file tag, all of the files are being seen by you dac as bit perfect. There are many redundancies in a digital stream and these "errors" as you call them are simply not seen.

This is well understood by the engineers. There is no problem and this is not an issue. As you stated, it is inaudible, because the DAC sees no error. I'd like to thank my friend Gordon Rankin for the explanation, who said he was once puzzled by this as well. 

 

Thanks for looking into this issue! "lone zero block" messages are indeed errors, just check the tar documentation. An error message that systematically occurs at every download is simply unacceptable. How can one be sure that the data are not broken? What if a download is actually corrupt? Getting a false positive at every download is not normal: all other providers manage to package data that unpack flawlessly. If your friend Gordon Rankin has an explanation for the errors, please report it.  

[nbpf]

49 minutes ago, David.. Qobuz, Hi-Res Music Evangelist said:

 

You're welcome and don't typically mind trying to help with a unique question. I don't really have the time to track down reasons for an inaudible lone zero block code that the DAC doesn't see. As I researched and reported for you, the reason this is inaudible, is by the time your DAC received the file, it's bit perfect because of packet redundancies. Nothing else to report.

 

You might have nothing else to report but I have to report that I have just terminated my Qobuz Sublime subscription. I appreciate your support and I understand that you do not have time to contribute solving technical problems. I will keep my account open at least until the end of my subscription period. Should Qobuz manage to ensure that the quality of their downloads fulfills minimal industrial standards and implement a competent and responsive technical support, I would be happy to be a Qobuz customer again. 

[nbpf]

On 8/17/2018 at 11:59 PM, Cebolla said:

 

Hi nbpf,

 

I didn't realise that Qobuz currently only provides the option to download your purchased music file tracks contained in the (Linux favoured) tar archive file format. The zip archive format that I'd downloaded before appears to be no longer available from Qobuz, so no point suggesting you use that instead!

 

Using the Linux tar command on my Raspberry Pi (under the latest DietPi distro) to extract or simply list the contents of the Qobuz downloaded tar files definitely produces the "A lone zero block" warning message, though as you say the command otherwise completes as normal. Interestingly, there's no warning message when I use the Windows Z-Zip application (recommended by Qobuz for Windows users) to extract the tar file's contents.

 

Curiosity got the better of me, so I did an online search & had a 'look at the GNU tar file format doc and realised that the block referred to by the tar command warning message was always the final block (tar files use 512 byte blocks). Also, the tar file is supposed to have two zero filled blocks at the end of the file used to indicate its end.

 

I fired up a hex editor to examine the tar files from Qobuz and sure enough they only use one zero filled block for the end of file marker, hence the warning message. A quick but careful copy and paste to add the missing zero block and bye bye Linux tar command warning message. Also, the Windows Z-Zip application still work with the corrected Qobuz tar files.

Thanks Cebolla, now I know for sure that all the work that I have done to edit the metadata of my Qobuz downloads was not in vain! I strongly suspected that the files were actually fine, now I know it for sure, thanks! At this point the most annoying issue that I have with Qobuz are the random jumps to the next track documented in https://opensourceprojects.eu/p/upmpdcli/tickets/11/. I understand that this issue is not trivial but it would have been nice if Qobuz had at least reacted to my mails on the subject. On the Naim forum some users have recently reported very helpful feedback from Qobuz, others very lousy. Perhaps the quality of the support is  country-dependent, I do not know. Anyway, my Sublime subscription is valid until the 22nd of November. Short before that date I will test download an album to see if they have managed to correct at least the issue with .tar files. Best, nbpf 

[nbpf]

12 hours ago, shadowlight said:

 

Can you provide the links to the albums that you seem to have consistent problems with and I will see if I can reproduce it.  Please correct me but I believe you are using BubbleUPnP Server (to create OpenHome endpoint), MPD with upmpdcli as DLNA/UPnP as renderer with all of the components running on uRendu.  Is that correct?  I do not have the exact setup but my setup is BubbleUPnP client on Android as control point, HQPlayer Embedded as DLNA/UPnP renderer.

 

I know your preference is to continue using MPD/umpmpdcli but have you tried another renderer for testing purpose to see if both have the same issue? 

 

Sorry, part of my IT engineering background kicking to identify the root cause on why something is not working correctly. 

 

I will try the song that @sockpitposted about in the CA thread that you linked as a starting point with BubbleUPnP and HQPe.

 

Listen to the album Tchaikovsky : Symphony No.6 by Teodor Currentzis on Qobuzhttp://open.qobuz.com/album/0886446239934 

 

Thanks shadowlight! The issue affects both Qobuz and Tidal streams and is well documented here: https://github.com/MusicPlayerDaemon/MPD/issues/241. A typical album for which I often experience track skips is Mahler's 5th by Adam Fischer and the Düsseldorfer Symphoniker: https://www.qobuz.com/de-de/album/mahler-symphony-no-5-adam-fischer-dusseldorfer-symphoniker/zd4qncl5iz11a. Best, nbpf

[nbpf]

On 8/22/2018 at 6:41 AM, shadowlight said:

@nbpf, I have a working system with Volumio, MPD, upmpdcli and upmpdcli-qobuz for 16-bit music but with 24-bit music I get white-noise.  I think I am missing some configuration under mpd/upmpdcli, if you know of anything that will help me remove the white-noise let me know what changes needs to be in place for it to make it work.  I can test similar setup as you with Linn Kazoo, mdp/upmpdcli configured as OpenHome renderer.  I only get white noise when I am using Linn Kazoo which uses the upmpdcli-qobuz plugin.  If I use BubbleDS on a Android device which I believe bypasses upmpdcli-qobuz plugin I am able to play 24-bit files just fine.

 

For now, I am going to call it a night and pick it up tomorrow night.

Sorry shadowlight, I have been offline for a few days: I do not use Volumio and my Qobuz subscription is for 16bit/44.1kHz files only. Thus, I cannot confirm or confute your observations. MinimServer + upmpdcli work fine up to 24bit/192kHz in a minimal Raspbian distribution.

[nbpf]

Has anyone experienced any issues streaming the new Pappano/Bernstein album (https://www.qobuz.com/de-de/album/bernstein-symphonies-nos-1-3-prelude-fugue-riffs-antonio-pappano/j5y25ahdwr2tc) in 16/44.1? At least two renderers (BubbleUPnP and upmpdcli) appear to have reproducible problems in tracks 4 and 5: at the end of the track, replay occasionally gets stuck. Does the problem affect downloads as well?