Har opplevd det samme som deg via Qobuz Connect, men ikke når jeg spiller av via Eversolo sin app, @PeriodeLytter
Qobuz streaming tjeneste
- Trådstarter TGB
- Startdato
Diskusjonstråd Se tråd i gallerivisning
-
Niks, ingen sånne problemer verken i MacOS, iOS, iPadOS eller via Roon.
Ja, det hender av og til her også. Wiim Pro Plus med Qobuz Connect.Jeg spurte vår alles gode venn ChatGPT. Her er en del av svaret (noen får si ifra om det ikke passer i tråden):
Den avgjørende forskjellen: Hvem eier tidslinjen?
Når du spiller:
A)
Ikke-Connect (telefon → streamer)
- Telefonen:
- laster hele track-metadata
- kjenner eksakt lengde
- eier playback-klokka
- sier til streameren: «spill dette PCM-/FLAC-strømmen, jeg sier ifra når vi er ferdige»
Streameren er i praksis en dum DAC/renderer
Ingen tvil om når låta slutter
B)
Connect (streamer → internett)
- Streameren:
- åpner selv HTTP-strømmen
- tolker metadata, chunking og signaler
- styrer egen avspillingsstate
- Appen:
- er bare en kontrollflate
- får status tilbake fra streameren
Streameren er 100 % ansvarlig for å vite når låta er ferdig
Her ligger kjernen i problemet.
Hvorfor tror streameren at låta er ferdig?
Dette er ikke buffer-størrelse, men state-maskin-logikk.
Connect-protokoller er hendelsesbaserte, ikke filbaserte
De er bygget rundt:
- track_start
- track_progress
- track_end
- next_track_ready
De tre vanligste reelle årsakene (på tvers av merker)
1. Uklar eller feil Content-Length / duration
I Connect får streameren ofte:
- estimert lengde
- segmentert strøm
- adaptiv chunk-størrelse
- Qobuz sender FLAC i variable segmenter
- Streameren regner samples → tid
- En liten avvik (f.eks. feil padding / encoder-delay / metadata-offset)
- Spilleren når “0 samples igjen” → TROR låta er slutt
Den hopper videre uten feil i nettverket
Dette skjer:
- oftere på høyoppløst materiale
- oftere på enkelte mastere
- tilfeldig fra spor til spor
2. Avspillings-state styres av tid, ikke EOF
Mange Connect-implementasjoner gjør:
yaml
if playback_time >= reported_track_duration:
go_to_next_track()
I stedet for:
scss
wait_for_stream_EOF()
Hvis:
- track_duration er feil (for kort)
- stream har encoder-delay / tail-padding
- DAC-klokka og stream-klokka ikke er perfekt synket
Avspillingen kuttes før EOF
Dette forklarer:
- hvorfor det skjer tidlig, ikke alltid på slutten
- hvorfor det aldri skjer i WiiM-appen
- hvorfor det aldri skjer når telefonen spiller
3. Race condition mellom prefetch og end-event
Connect er designet for:
- gapless
- rask “next track”
- neste spor lastes før nåværende er ferdig
- to state-maskiner lever parallelt
- Streameren begynner å prefetch neste spor
- Nåværende spor når et internt end-condition
- “Next track ready” vinner racet
- Spilleren bytter spor for tidlig
Dette er ren logisk feil, ikke nettverksfeil
Og ja:
- Spotify Connect har samme type bug
- Tidal Connect også
- Sonos, Bluesound, WiiM, HEOS, etc.
Hvorfor skjer dette på alle merker?
Fordi:
Qobuz / Spotify leverer:
- SDK
- sertifisering
- minimums-API
Produsentene:
- implementerer selv
- på ulike OS
- med ulike audio-pipelines
- med egne klokker og DAC-drivere
Connect-spesifikasjonen er ikke deterministisk nok til å forhindre dette.
Det er ingen absolutt “EOF-garanti” i Connect slik det er når telefonen er avspiller.
Konklusjon:
**Det er en strukturell svakhet i hvordan Connect håndterer:
- tidslinje
- spor-slutt
- prefetch
- metadata-tillit**
Og noen ganger gjetter den feil.Videre:
Så: Hva måtte endres i Connect-spesifikasjonen?
Her er det viktigste – konkret, ikke teoretisk.
1. EOF-autoritativ slutt (kritisk)
I dag:
- “track_end” kan trigges av:
- tid
- metadata
- intern buffer-state
- Track kan kunavsluttes av:
- eksplisitt EOF fra stream
- eksplisitt STOP fra tjenesten
Metadata skal aldri være avgjørende.
2. Separere prefetch fra playback state
I dag:
- next_track_prefetched == “klar til å spille”
- kan trigge for tidlig
- Prefetch = passiv
- Playback state kan ikke påvirkes før:
- EOF er bekreftet
- eller tjenesten eksplisitt sender NEXT
3. Sample-basert rapportering (ikke tid)
I dag:
- streameren rapporterer:
- “playback_time = 182.3s”
- “samples_played = N”
- “samples_total = M (valgfritt)”
- encoder-delay
- FLAC-padding
- VBR-variasjoner
4. Entydig “track authority”
I dag:
- både app
- tjeneste
- streamer
Må endres til én av to modeller:
Modell A – Roon-aktig
- tjenesten er autoritet
Modell B – UPnP-aktig
- EOF er eneste sannhet
Alt annet er en kompromiss-løsning.
Hvorfor dette sannsynligvis aldri blir fikset helt
Fordi:
- Spotify / Qobuz prioriterer:
- respons
- UX
- mobil-først
- Ikke:
- sample-perfekt hi-fi-logikk
Å gjøre Connect deterministisk ville:
- øke latency
- redusere “snappiness”
- bryte kompatibilitet
- kreve ny sertifisering
Markedet vil ikke ha det – unntatt oss.
Brutalt ærlig konklusjon
- Roon fungerer fordi endpoint er dum
- UPnP fungerer fordi EOF er sjef
- Connect feiler fordi streameren må gjette
Så lenge Connect er “prediktiv”, vil spor av og til bli avsluttet feil – uansett produsent.
Sitat fra ChatGPT slutt.Sist redigert:
Samme her, med connect på HiFi Rose.
- Ble medlem
- 26.02.2013
- Innlegg
- 5.163
- Antall liker
- 5.269
Siden CGPT kan lede tanker over på mye rart la oss se på hvordan jeg kjenner Qobuz. Men først om noen av dere kan være snill å verifisere at Qobuz Connect kan styre endpoint tilsvarende Spotify sin Connector? Hvor man starter avspilling av et album/spilleliste og Connctor ferdigstiller denne selv om telefonen blir slått av eller tatt med ut av huset? Om dette er tilfelle vil jeg tro Connectoren benytter samme tilnærming som Lyrion pluggen.
Qobuz pluggen for Lyrion benytter filbasert FLAC stream over HTTPS som cashes til en midlertidig fil. I praksis vil si den utfører egentlig avspilling helt identisk som om det er en lokal FLAC-fil. Hvor den først leser inn METADATA block #0 streaminfo* hvor totalt antall samles er definert. Dette kan brukes sammen med sample rate til å kalkulere spilletid på sporet og det det slik lokal streaming i Lyrion gjør det. Spilletid blir også levert via en egen lenke hvor alle metadata for sporet som spilles finnes. Tags utenom METADATA block #0 (STREAMINFO) og #1 (SEEKTABLE) finnes ikke i selve FLAC-strømmen.
FLAC -> PCM trankoderen (player) behøver egentlig ikke denne streaminfo for å spille FLAC da hver eneste FLAC ramme inneholder** sekvensielt rammenummer og offset fra start. Men FLAC-rammen har ikke info om lengden på sporet så da blir det EOF som gjelder. Når jeg ser at cash-filen lukkes tolker jeg det slik at det da enten er server som sender EOF, eller at TCP forbindelse blir avsluttet og cash derfor lukkes lokalt.
Her er det verd å tenke på at under normalt drift så vil hvert nytt spor i spillelisten/album åpne opp en ny stream***. Derfor hverken ser eller logger streamer dette som feil om det EOF den opplever. Dette til tross for at analyse av cash faktisk inneholder feil som:
FLAC__STREAM_DECODER_ERROR_STATUS_LOST_SYNC
ERROR, decoded number of samples is smaller than the total number of samples set in the STREAMINFO.
LOST_SYNC er de fleste endpoints trent til å ignorere for heller søke opp neste ramme uten feil og fortsette avspilling. Den siste feilen forutsetter at enpoint er trent opp til å kalkulere totalt antall samples og logge dette som feil om det ikke samsvarer med streaminfo. Spørsmålet er om man anser det som transkoderen sitt ansvar gitt EOF er ganske defnetivt noe kilden er ansvarlig for. Og noe jeg har bekreftet faktisk er hva som skjer her ved å overvåke hvordan cash oppfører seg. Kan også nevne at spor lengde er riktig visualisert siden CGPT tar fram dette som mulig problem.
Siden problemet oppstår oftere på hi-res og/eller lange spor 7+ minutter har jeg spekulert om det er flaskehalser i nett eller cash på lokale servere hos QB som tuller. Herunder mulig authetisering som jeg ikke har oversikt om hvordan egentlig foregår i en lenger streamperioder. Repeterer man samme spor mange nok ganger får man innimellom hele låten uten feil. Som da om ikke annet friskmelder QB sitt arkiv som var det jeg først mistenkte var problemet før jeg erfarte at problemet eskalerte.
*) Om man selv vil tittel litt på dette brukmetaflac --list trackname.flac
**) Typisk ser vi blocksize: 4608 samples pr ramme.
***) Om man lytter til f.eks. Radio Paradise er det lenger sammenhengende stream med flere låter. Hvor avbrudd gjerne sees når radioverten snakker. Hvor streamer da lukker stream og åpner en ny.
Har problemer med at Qobuz-appen ikke finner Eversoloen, men alt fungerer ypperlig gjennom Eversolo's egen app så jeg har foreløpig ikke investert kalorier i å finne en løsning.
Nå har jeg også opplevd dette, via Connect til Bluesound Node 2i styrt fra iOS.
Roon funker fortsatt.Sist redigert:
Ikke noe problem fra qobuz appen til eversolo a6 her.
- Ble medlem
- 02.05.2009
- Innlegg
- 6.728
- Antall liker
- 4.644
Funker fint med Qobuz connect her, funker med Wiim appen også.
- Ble medlem
- 26.02.2013
- Innlegg
- 5.163
- Antall liker
- 5.269
Fortsatt ikke hørt tilbake fra QB såkalte support.
Siste dagene har jeg spilt av PROG 2025 - List by Grumpy og snitt ser ut til bli omtrent annet hvert album nå spiller feilfritt. Men når feil oppstår er det gjerne i grupper av et par spor etter hverandre hvor jeg enkelte ganger nå ser at flac header kan mangle, noe som er et nytt fenomen. Siste sporet på Bjørn Riis sin utgivelse nektet å spille av i det hele tatt. Dog har problemet avtatt noe siden før jul, — da var det uutholdelig.
Som tidligere nevt kjører jeg ping mot 8.8.8.8 og mister ingen pakker når fenomenet oppstår så det er ikke typiske WiFi drop som er årsak. Logger viser også at når QB sin cash går tom logger Lyrion meldinger om at den ikke avslutter avspilling. Her ligger det altså en logikk hvor QB venter på at spilleren sender beskjed at avspilling er ferdigstilt. Noe den faktisk gjør når spor avsluttes for tidlig, — som underbygger hypotesen at vi har nådd EOF.
EDIT: Logger viser at fra kl 22:03 til 22:33 på dagen da enkelte bråker ille fælt med fyrverkeri var det samtidig ganske håpløst å få levert bitperfekt audio fra Qobus. Album som ble forsøkt avspilt var Lux Terminus - Cinder fra 2025 i 24/48000 oppløsning. Samme album spiller fint på årets første formiddag.Sist redigert:
Reset av Router viste seg å løse dette.
- Ble medlem
- 26.02.2013
- Innlegg
- 5.163
- Antall liker
- 5.269
Når jeg mente se konturene av en trend slo virkeligheten meg rett i flaisen igjen
Faktisk kan det se ut som 24/44100 er aller vanskeligst å få spilt av hele spor. Joe Bonamasse sin katalog virker påtagelig kranglete. Jeg mente også se at den beste tiden å spille musikk uten feil på var på formiddagen. Men i dag var det like håpløst også innenfor dette tidsvinduet.
Og fortsatt ikke hørt tilbake fra deres "support", — hva vi nå enn kan legge i det. Jeg ordla meg med hensikt slik at jeg skulle slippe svar alla godagmannøkseskaft med ditto "case closed". Qobuz abonnement er herved sagt opp. Nå skal vinlyriggen få gi meg musikkglede igjen.
Selv om Qobuz fungerte utmerket de første månende vurderer jeg likevel Deezer som neste strømmetjeneste jeg bryner meg på når abstinenser etter ny musikk melder seg.
Her kommer det FM støy i 1 sek så kutter Qobuz ut og står bare og blar igjenom katalogen
. Skjedd flere ganger siste mnd, flere som har hatt det ?.
- Ble medlem
- 26.02.2013
- Innlegg
- 5.163
- Antall liker
- 5.269
Erkstern DAC? Symtom er litt typisk om sample rate ikke støttes.Her kommer det FM støy i 1 sek så kutter Qobuz ut og står bare og blar igjenom katalogen. Skjedd flere ganger siste mnd, flere som har hatt det ?.
Nei har HiFi Rose RS 151
- Ble medlem
- 26.02.2013
- Innlegg
- 5.163
- Antall liker
- 5.269
Før kontoen avsluttes tenke jeg vi kunne se på @TrompeteN sin originale fil igjen. Vi har allerede verifisert at om man har high-res aktivert får vi en bit-eksakt 1:1 kopi av hva plateselskapet har levert til sin aggregator. Det hersker fortsatt usikkerhet om det er aggregator eller strømmetjenesten selv som står for konvertering. OpenAI virker være på bølgelengde med mine tanker rundt dette og mener forstå det slik at strømmeselskap som tilbyr lossless kun mottar en master og da selv utfører nedsampling og komprimering.
Nedenfor er hvordan DeltaWave ser det når vi sammenligner @TrompeteN sin originale 24/88200 fil avspilt som 16/44100 fra Qobuz:
ChatGPT kjenner dette programmet og vil gi svar på hva grafene representerer om man er nyskjerrig.
Faseendring avslører typisk at filen er manipulert med et filter, noe som er nødvending ved resampling. Teorien er at filteret introduserer fase- og amplitudeforvrengning i området nær Nyquist. Derfor litt intressant å se fase flater ut før 4500Hz.
De to siste grafene forsøker illustrere om vi kan høre forskjeller. Her forsøker OpenAI forklare hvordan vi skal tolke disse grafene.
Egenskap DF Metric PK Metric Måler Signalavvik per frame, ofte inkludert frekvensvektet vurdering Perseptuell forskjell, altså hørbarhet Følsomhet Veldig sensitiv, registrerer små numeriske endringer Mindre sensitiv, ignorerer uhørbare endringer Bruk QC, feilsøking, teknisk optimalisering av kodek / pipeline Kvalitetssjekk, perceptuell transparens Typisk graf Flere topper, høy dynamikk Lavere, mer jevn, topper kun der hørbare artefakter oppstår
DeltaWave v2.0.24, 2026-01-10T12:00:35.3302377+01:00
Reference: 12 - Nordhagen- Baut, for euphonium, percussion and string quartet- II..flac[?] 45180450 samples 88200Hz 24bits, stereo, MD5=00
Comparison: 12 - Nordhagen- Baut, for euphonium, percussion and string quartet- II..flac[?] 22590225 samples 44100Hz 16bits, stereo, MD5=00
Settings:
Gain:True, Remove DC:True
Non-linear Gain EQ:False Non-linear Phase EQ: False
EQ FFT Size:65536, EQ Frequency Cut: 0Hz - 0Hz, EQ Threshold: -500dB
Correct Non-linearity: False
Correct Drift:True, Precision:30, Subsample Align:True
Non-Linear drift Correction:False
Upsample:False, Window:Kaiser
Spectrum Window:Kaiser, Spectrum Size:32768
Spectrogram Window:Hann, Spectrogram Size:4096, Spectrogram Steps:2048
Filter Type:IIR, window:Kaiser, taps:262144, minimum phase=False
Dither:False bits=0
Trim Silence:True
Enable Simple Waveform Measurement: True
Correct for MP DC Filter = False, DC Filter frequency=0.5 Hz
Resampled Reference to 44100Hz
Resampled Reference to 44100Hz
Discarding Reference: Start=10s, End=10s
Discarding Comparison: Start=10s, End=10s
Initial peak values Reference: -0.1dB Comparison: -0.101dB
Initial RMS values Reference: -24.767dB Comparison: -24.767dB
Null Depth=53.487dB
X-Correlation offset: 0 samples
Trimmed 0 samples ( 0.00ms) front, 0 samples ( 0.00ms end)
Final peak values Reference: -0.1dB Comparison: -0.101dB
Final RMS values Reference: -24.693dB Comparison: -24.693dB
GS: 0 ms, 0.0003 dB (L), 0.0002 dB (R), -55.1 dBFS (L), -54.7 dBFS (R) [-56.3dBFSA (L) -56.1dBFSA (R)]
Gain= 0.0003dB (1x) DC=0 Phase offset=0ms (0 samples)
Difference (rms) = -55.1dB [-56.29dBA]
Correlated Null Depth=51.39dB [45.13dBA]
Clock drift: 0 ppm
Files are NOT a bit-perfect match (match=1.18%) at 16 bits
Files are NOT a bit-perfect match (match=0%) at 24 bits
Files are NOT a bit-perfect match (match=0%) at 24 bits
Files match @ 50.0065% when reduced to 9.58 bits
---- Phase difference (full bandwidth): 11.9505341256633°
0-10kHz: 10.69°
0-20kHz: 11.85°
0-24kHz: 11.95°
Timing error (rms jitter): 1.2μs
PK Metric (step=400ms, overlap=50%):
RMS=-102.5dBFS
Median=-106.4
Max=-88.4
99%: -92.71
75%: -102.96
50%: -106.37
25%: -107.61
1%: -109.77
gn=0.999968998464833, dc=0, dr=0, of=0
---Measurements (for a simple sine-wave only)---
Comparison DR = 101.54dB
RMS of the difference of spectra: NaNdB
DF Metric (step=400ms, overlap=0%):
Median=-31.9dB
Max=-10.7dB Min=-44.3dB
1% > -43.27dB
10% > -38.01dB
25% > -34.68dB
50% > -31.92dB
75% > -27.87dB
90% > -24.17dB
99% > -12.61dB
Linearity 22.5bits @ 0.5dB error
Comparison THD+N = -24.7dB
Comparison THD = -7.15dB
H1 (1505Hz) = -74.7dB
DONE!PK Metric (step=400ms, overlap=50%):
RMS=-102.5dBFS
Median=-106.4
Max=-88.4
- RMS -102,5 dB → ekstremt lavt (praktisk ingen hørbar forskjell)
- Max -88,4 dB → den høyeste hørbare forskjellen i et 400 ms-vindu er fortsatt veldig lav
- 99%-percentil = -92,71 dB → 99% av signalet har hørbarhetsforskjell langt under hørbar terskel
Dette viser at de fleste deler av filen er praktisk talt uendret perceptuelt.
DF Metric (step=400ms, overlap=0%):
Median=-31.92dB
Max=-10.7dB Min=-44.3dB
- Median ~ -32 dB → små tekniske forskjeller over hele filen
- Max ~ -10,7 dB → én eller noen få transienter har større numerisk forskjell
- Fordelingen (1% > -43,27, 99% > -12,61) antyder at de fleste rammer har små avvik, og bare noen få er større
Dette støtter at transienter er primært “skadelidende”, resten av signalet er stabilt.
Bit-perfekt og lineæritet
- Files are NOT a bit-perfect match … → forventet, fordi bitdybde og samplingsfrekvens endres
- Linearity 22.5 bits @ 0.5dB error → nesten full 16-bit transparens
- Ingen signifikant clock drift eller faseavvik
Comparison THD+N = -24.7dB
Comparison THD = -7.15dB
- Totale harmoniske forvrengninger er lave, ikke hørbart problematisk
- Transientrespons kan gi små spike-artefakter i DF, men PK Metric viser at det er umerkelig
Oppsummering
- Nedsampling fra 88,2 kHz → 44,1 kHz introduserer små numeriske forskjeller, spesielt i transienter og høyfrekvent materiale
- Det meste av signalet er ekstremt jevnt → median DF ≈ -32 dB, RMS PK ≈ -102 dBFS
- Hørbart påvirkes praktisk talt ingenting → PK Metric viser nesten null
- Rapporten bekrefter: én “peak” i DF-grafen er normal, og transienter er de primært berørte delene
Konklusjon fra rapporten
Ved nedsampling fra 24/88,2 til 16/44,1:
Transienter og høyfrekvente detaljer er de eneste delene med målbare forskjeller
Resten av filen er ekstremt ensartet og transparent
PK Metric bekrefter at kvaliteten er praktisk talt uhørbar for mennesker
Bare for å forstå, du velger å avslutte din konto hos Qobuz selv om konklusjonen er:
Konklusjon
Ved nedsampling fra 24/88,2 til 16/44,1:
Transienter og høyfrekvente detaljer er de eneste delene med målbare forskjeller
Resten av filen er ekstremt ensartet og transparent
PK Metric bekrefter at kvaliteten er praktisk talt uhørbar for mennesker
- Ble medlem
- 26.02.2013
- Innlegg
- 5.163
- Antall liker
- 5.269
Mest fordi tjenesten ikke fungerer på high-res som vi betaler premium for. Når jeg aktiverer høyoppløsig avslutter den spor for tidlig med en feilrate på 15-20%. Sammen med at deres support ikke tar seg bryet med å svare. Nå skal det samtidig sies at det er fint lite som egentlig er høyoppløsig på Qobuz da denne delen av biblioteket deres er kraftig utvannet med 24/44100. Dette ble tydeliggjort da jeg laget Prog 2025 spillelisten med Grumpy sine tips.Ærlig talt, det høres ut som problemet er fra din side. Qobuz avspilles som "pull", klienten henter filen fra Qobux sine servere, buffrer og spiller av. Det er ikke Qobuz som "sender" filen til deg, og avslutter transmisjon x antall sekunder før låten egentlig er ferdig.
- Ble medlem
- 26.02.2013
- Innlegg
- 5.163
- Antall liker
- 5.269
Takker for input! Ja det er slik jeg har feilsøk og konkludert at klienten mest trolig ser server side EOF da debug logger ikke viser noen feil, — selv når cash ikke er komplett. Faktisk viser debug logg helt konkrekt at spor er ferdigspilt og dette rapporteres til Qobuz. (Er visnok et krav fra enkelte strømmeselskap og skal vistnok bli benyttet ved fordeling av pengesekken) Her er noen punkter som ligger til grunn for nåværende konklusjon.
- Qobuzpluggen har kjørt feilritt i flere måneder før desember 2025. Feil kan muligens i tidssammenheng kobles til når enkelte Qobuz Connetor brukere begynte rapporte problemer.
- Når Qobuz buffer går tom logges dette. Slike drop-out skjer innimellom ved high-res, men ikke like stort problem. Det finnes ikke slike hendelser i logg når feil inntreffer. Vi kan trolig konkludere at feil ikke skyldes nettverksproblemer i vår ende. Også verifisert ved at samme maskin ikke taper ICMP pakker mot Google sin server i perioder feil inntreffer.
Kilent viser korrekt tid og sporlengde. Det er nærliggende å tenke at underliggende play kode jobber utifra samme data som visualiseres?
Vi har som regel også komplett flac header med totalt antall samples. Her kan vi tenke oss at om sample count fra header benyttes at koden har en bug som kalkulerer feil ved high-res filer. Men den burde da kanskje feile på alle spor med samme sample rate? Uansett metode benyttet burde i hvertfall feilen oppstå på samme sted når sporet startes på nytt. Noe det skjelden gjør, — i hvertfall om man spiller noen andre spor før man forsøker problemsporet på nytt. Noe som har ledet de små grå til å tenke seg at kanskje har vi med å gjøre et cash problem på serversiden? Med siden det å tenke selv raskt kan føre til idioti skal jeg være forsiktig med en slik påstand.
Pluggen burde ihvertfall ha greit stell på hvortid den skal starte prebuffering av neste spor. Dette er et punkt jeg riktignok ikke har logget og som mulig kan avsløre om vi har med et "planlagt" avslutning å gjøre da prebuffering gjerne starter 7-10 sekunder før nåværende spor avsluttes uavhening av når cash ble ferdigstilt. Men jeg aner ikke om EOF også trigger en slik prebuffering.
- Ble medlem
- 26.02.2013
- Innlegg
- 5.163
- Antall liker
- 5.269
Pluggin benytter Qobuz sitt JSON-API, altså samme som deres Web klient. Det er nok riktig at det er et mindretall på HFS som benytter webspilleren med høyoppløsig, men derifra dra ut at jeg er eneste i verden med problemet er vel å ta litt i? Det kan være riktig at jeg er eneste i verden som den siste måneden har logget alle spor som spilles og dermed ser feilen i logger selv når jeg ikke lytter. Og jeg er muligens også en av få som for tiden streamer 24/7 nettopp for å danne meg et bedre bilde av problemet enn en en vanlig lytter som kun benytter tjenesten noen timer i uken.Sakset fra nettet:
"How Qobuz Explains Its Biggest Limitations
Mackta’s explanations followed a pattern: every limitation traced back to something Qobuz couldn’t control."
Ser ut som mye ute av kontroll?
https://www.headphonesty.com/2026/0...g1OxxT_yKbEuIZm4Q0_aem_gphPI97PfySfL_1PWYNMVw
Gjør det? Hans svar vitner om god kontroll og gode prioriteringer:
Qobuz Director Explains Why the $12.99 Streaming Service Still Has Broken Search, Missing Albums, and No Dolby Atmos.
1) Broken search:
Main reason? We don’t have enough people working on it. Qobuz is a small company and we need to be adding resources to speed up much needed improvements in these areas,
2) Missing albums:
When we find out we are missing something that comes through an aggregator like this, they cannot supply it to us UNLESS their customer opts in… So the artist needs to make it happen on their end.
3) No Dolby Atmos:
We are in talks with Dolby about this… The main reason we haven’t done it so far is that there is a cost to us that may not be recouped by incremental new subscribers we might get.Sist redigert:
Hadde det blitt Atmos så hadde qobuz vært "perfekt" det savner jeg etter å ha sluttet med Tidal.
Hva er galt med søket? Har aldri tenkt over at det skulle være noe problem.
Jeg har Spotify også.
- Ble medlem
- 26.02.2013
- Innlegg
- 5.163
- Antall liker
- 5.269
Jeg opplever samme som artikelen påpeker. At album mangler under artisten. At album ikke kommer opp på direkte søk men kan dukke opp ved artistsøk.
Innen jazz sjangeren finner vi rett som det er at album ikke er tilknyttet artisten vi normalt assosierer albummet med. Trolig ikke QB sin feil men dem som har publisert utgivelsen, eller min egen missforståelse. Jeg mistenker også "medvirkende musikere" kan gjøres langt bedre.
Samt at mange album mangler enkle spor. I Lyrion får disse en stjerne for å indikere at dem mangler. Jeg har tenkt at problemet da trolig skyldes at opphavsrettighetshavere seg imellom ikke er blitt enig om hvordan evt utbetaling skal deles.
Jeg er en som ikke ville brukt Atmos så gir dem rett på den. Men vi ser kanskje hvorfor dem stresser kampanjene med 3 års forskuddsbetaling og 3 mnd fri bruk. Dem virket ha et ønske om å gjøre et skippertak for plattformen som krever mer kapital.
Aller øverst på listen foruten få high-res stabil igjen er at dem fjerner 24/44100 fra high-res søket. Eller noe som muligens passer dem bedre, innfører et nytt søkebegrep for å bedre finner reelt high-res materiale.
Feilmerking av album som high-res, - noen ganger finnes kun et eller to spor i high-res, - da typisk singel utgivelsene hvor resten av albumet er CD kvalitet. - Telefonen:
-
Laster inn…
Diskusjonstråd Se tråd i gallerivisning
-
Laster inn…