Bättre ljud via USB Android app ? Nu mätt

[dewpo]

Fler uppdateringar angående funktionalitet (I min telefon)
Qobuz egna program samplar om HighRes till 48 kHz
USB Audio Player PRO ger BitPerfekt ut upp till 96 kHz med min DAC, Vilket är taket på USB interfacet jag använder

ps Även 44.1 kHz blir ändrat till 48 kHz i Qobuz egen app men strömmas BitPerfekt av USB Audio Player PRO ...

Vet inte om jag missförstår....
USB Audio 1.0 och 2.0 applikationerna är inte felkorrigerande till skillnad från många andra USB-applikationer. Alltså ett "frame" kan innehålla bitfel utan att omläsning sker. Man struntar alltså i "NAC" ( = data packet Not ACcepted)
Skälet är enkelt - risken för fel i överföringen är minimal och dessutom ger ett bitfel ca 2 16-delars risk (vid 16bits bitdjup) att överhuvutaget påverka utsignalen. Egentligen kan en hel "frame" kan vara kass utan någon ljudlig påvekan.

Ville bara försiktig påpeka att USB Audio protokoll är inte bit-perfect om jag förstår det rätt utan snarare nivå "audio perfect".
Är det någon som på forumet har bättre koll än jag har?

Det kan säkert stämma att USB Audio protokollet inte innehåller någon redundans bit och inte kan garantera att bit-fel inte uppstår Men är inte det samma sant om CD skivor också?
Och inte innebär väl det att taskig omsampling till 48kHz är att föredra?

ps har råkat skiva redundans när jag menade paritet

[jansch]

Fler uppdateringar angående funktionalitet (I min telefon)
Qobuz egna program samplar om HighRes till 48 kHz
USB Audio Player PRO ger BitPerfekt ut upp till 96 kHz med min DAC, Vilket är taket på USB interfacet jag använder

ps Även 44.1 kHz blir ändrat till 48 kHz i Qobuz egen app men strömmas BitPerfekt av USB Audio Player PRO ...

Vet inte om jag missförstår....
USB Audio 1.0 och 2.0 applikationerna är inte felkorrigerande till skillnad från många andra USB-applikationer. Alltså ett "frame" kan innehålla bitfel utan att omläsning sker. Man struntar alltså i "NAC" ( = data packet Not ACcepted)
Skälet är enkelt - risken för fel i överföringen är minimal och dessutom ger ett bitfel ca 2 16-delars risk (vid 16bits bitdjup) att överhuvutaget påverka utsignalen. Egentligen kan en hel "frame" kan vara kass utan någon ljudlig påvekan.

Ville bara försiktig påpeka att USB Audio protokoll är inte bit-perfect om jag förstår det rätt utan snarare nivå "audio perfect".
Är det någon som på forumet har bättre koll än jag har?

Det kan säkert stämma att USB Audio protokollet inte innehåller någon redundans bit och inte kan garantera att bit-fel inte uppstår Men är inte det samma sant om CD skivor också?
Och inte innebär väl det att taskig omsampling till 48kHz är att föredra?

Nu börjar jag komma in på "djupt vatten"........
Det är väl så att CD (audio) har CIRC felrättning och att om jag minns rätt bygger CIRC bl.a på statistik vilket då betyder att felrättningen är en kvalificerad "gissning".
En CDskiva har normalt tusentals bitfel fick jag lära mig för över 30-år sedan. Dock slutresultatets kvalitet, när väl D/A omvandling sker, är helt försumbart ur ett analogt perspektiv.
Hallå.......finns det inte någon på forumet som har bättre "på fötterna" än jag

[Almen]

Det är väl så att CD (audio) har CIRC felrättning och att om jag minns rätt bygger CIRC bl.a på statistik vilket då betyder att felrättningen är en kvalificerad "gissning".
En CDskiva har normalt tusentals bitfel fick jag lära mig för över 30-år sedan. Dock slutresultatets kvalitet, när väl D/A omvandling sker, är helt försumbart ur ett analogt perspektiv.
Hallå.......finns det inte någon på forumet som har bättre "på fötterna" än jag

Min första tanke var att "CIRC är väl helt felrättande", men du har lite rätt.

Reed–Solomon codes are specifically useful in combating mixtures of random and burst errors. CIRC corrects error bursts up to 4000 data bits in sequence (2.5 mm in length as seen on CD surface) and compensates for error bursts up to 12,000 bits (7.5 mm) that may be caused by minor scratches.

Det där "compensates" är alltså interpolering.

[E]

Man lägger alltså polermedel mellan två kompaktskivor och gnuggar?
Detta är bra mot minor scratches, är det korrekt uppfattat?

Och om detta inte hjälper så är det bara att extrapolera?

Mvh E*

[E]

Uppar den här lite.
Kan jag med den här appen koppla en Samsung Galaxy S20 med usb-otg direkt till usb-ingången på en hörlursförstärkare?

Det låter väl rimligt, men du får nog ett säkrare svar från andra.

Mvh E*

[petersteindl]

Det är väl så att CD (audio) har CIRC felrättning och att om jag minns rätt bygger CIRC bl.a på statistik vilket då betyder att felrättningen är en kvalificerad "gissning".
En CDskiva har normalt tusentals bitfel fick jag lära mig för över 30-år sedan. Dock slutresultatets kvalitet, när väl D/A omvandling sker, är helt försumbart ur ett analogt perspektiv.
Hallå.......finns det inte någon på forumet som har bättre "på fötterna" än jag

Min första tanke var att "CIRC är väl helt felrättande", men du har lite rätt.

Reed–Solomon codes are specifically useful in combating mixtures of random and burst errors. CIRC corrects error bursts up to 4000 data bits in sequence (2.5 mm in length as seen on CD surface) and compensates for error bursts up to 12,000 bits (7.5 mm) that may be caused by minor scratches.

Det där "compensates" är alltså interpolering.

Det jag lärt mig en gång för länge sedan är att det finns 2 olika error correction. Det ena är att det finns missing bits i informationen, men inte i tillräcklig hög grad att man inte kan beräkna dessa missing bits helt korrekta värden d v s det blir bit correct. Detta eftersom det finns redundanta bitar, precis som sista siffran i personnumret. Saknas en siffra så kan man räkna ut den. Saknas 2 siffror så går inte det. Likartat är det med de redundanta bitarna. Saknas det för mycket bitar så beräknas statistiska bitar fram med viss noggrannhet och läggs till. Saknas ännu mer så stannar CDn.

[I-or]

CIRC arbetar i flera steg med interfoliering, offset och paritetsbitar och utnyttjar 33 % redundant information för att bitperfekt återställa data upp till 4000 bitar i följd (ett liknande upplägg är även skälet till att CD-ROM fungerar så bra som det gör/gjorde).

I normalfallet inga "gissningar", alltså, även om interpolering kan utnyttjas i värsta fall för CD-Audio.

[E]

En CDskiva har normalt tusentals bitfel fick jag lära mig för över 30-år sedan. Dock slutresultatets kvalitet, när väl D/A omvandling sker, är helt försumbart ur ett analogt perspektiv.

Vissa skivor har inte en enda bra bit.

De flesta är en bra bit bättre än så,
ehuru ofta med flit förstörda ändå.

Mvh E*

[dewpo]

Jag lät AI analysera USB Audio 2.0 specifikationerna och fick följande svar angående bit-perfektion Fast jag vet ej om det gjorde mig klokare

-------------------------------------------------------------

Den angivna texten säger inte uttryckligen om USB-ljud 2.0 erbjuder bit-perfekt överföring. Dokumentets huvudfokus ligger på att definiera enhetsklassen och dess funktioner, inklusive hantering av olika ljudformat, kontroller och synkronisering. Även om den beskriver hanteringen av digitala ljudströmmar och vikten av att bibehålla ljudkvalitet, garanterar den inte uttryckligen bit-perfekt överföring i alla scenarier.

Specifikationen tillhandahåller dock mekanismer som kan möjliggöra bit-perfekt överföring under vissa förutsättningar. Till exempel tillåter den användning av okomprimerade PCM-ljudformat, som i sig bevarar de ursprungliga ljuddata utan förlust. Dessutom stöder den förlustfria komprimeringsformat som WMA Lossless, vilket säkerställer att det avkodade ljudet är identiskt med originalet.

Specifikationen betonar också vikten av synkronisering och tillhandahåller mekanismer för att minimera jitter och bibehålla fasrelationer mellan ljudkanaler, vilket är avgörande för att bevara ljudkvaliteten.

Därför, även om USB-ljud 2.0 inte uttryckligen garanterar bit-perfekt överföring i alla fall, ger det de nödvändiga verktygen och funktionerna för att uppnå det när man använder lämpliga ljudformat och konfigurationer. Den faktiska implementeringen och huruvida bit-perfekt överföring uppnås kan bero på specifika enhetsimplementeringar och de valda ljudformaten och inställningarna.

[jansch]

Jag lät AI analysera USB Audio 2.0 specifikationerna och fick följande svar angående bit-perfektion Fast jag vet ej om det gjorde mig klokare

-------------------------------------------------------------

Den angivna texten säger inte uttryckligen om USB-ljud 2.0 erbjuder bit-perfekt överföring. Dokumentets huvudfokus ligger på att definiera enhetsklassen och dess funktioner, inklusive hantering av olika ljudformat, kontroller och synkronisering. Även om den beskriver hanteringen av digitala ljudströmmar och vikten av att bibehålla ljudkvalitet, garanterar den inte uttryckligen bit-perfekt överföring i alla scenarier.

Specifikationen tillhandahåller dock mekanismer som kan möjliggöra bit-perfekt överföring under vissa förutsättningar. Till exempel tillåter den användning av okomprimerade PCM-ljudformat, som i sig bevarar de ursprungliga ljuddata utan förlust. Dessutom stöder den förlustfria komprimeringsformat som WMA Lossless, vilket säkerställer att det avkodade ljudet är identiskt med originalet.

Specifikationen betonar också vikten av synkronisering och tillhandahåller mekanismer för att minimera jitter och bibehålla fasrelationer mellan ljudkanaler, vilket är avgörande för att bevara ljudkvaliteten.

Därför, även om USB-ljud 2.0 inte uttryckligen garanterar bit-perfekt överföring i alla fall, ger det de nödvändiga verktygen och funktionerna för att uppnå det när man använder lämpliga ljudformat och konfigurationer. Den faktiska implementeringen och huruvida bit-perfekt överföring uppnås kan bero på specifika enhetsimplementeringar och de valda ljudformaten och inställningarna.

Som jag skrev tidigare, USB Audio använder inte felrättning då överföringen är av typ isokron överföring.

Jitterproblemet är ofta överdrivet men också missförstått.
Det kan finnas jitter i både seriell och parallell överföring. Men man konverterar från seriell bitöverföring, i form av USB, till parallell hantering i samband/inför D/A omvandling där 16bits skall staplas upp parallellt. innan dess skall också synkbits, mm rensas bort.
Dålig liknelse:
Om man tänker sig en busshållplats där alla bussar tar 16 personer. Det är då ointressant när resenärerna (alla resenärer heter Bits!) ställer sig i busskön eller när dom stiger på bussen innan den avgår. Det viktiga är att bussen avgår i tid till hållplatsen som heter DAomvandlingtorget....... ...det blir många bussar....44100 st/sekund.
Har man separat klocka i Dac:en är alltså kopplingen mellan seriell och parallell hantering väldigt "lös"/obefintlig.

Vad som dock kan hända är t.ex följande:
Dac:en matas av en intern power supply som förser den seriella USBporten/steget, mm med ström. Samma power supply matar även klockan som taktar ut analoga signalen från själva DAomvandlingen.
"Sviktar" nu matningsspänningen p g a den seriella delens belastning kan klockan störas. Klockan består ju av en kristall som avger en sinusvåg/frekvens som exvis triggar en schmitt-trigger för att få en defierad puls/fyrkantvåg. Varerar spänningen kommer triggnivån att ändras, tex trigga lite längre upp på sinusen.
Bara ett exempel på ogenomtänkt design......

[dewpo]

Jag har kommit farm till att jansch har rätt angående att USB inte är Bit-Perfekt Efter mycket googlande och läsande av specifikationer har jag funnit att felfrekvensen för USB Audio är angiven till 10e-12,,, Vilket innebär att ett Bit-Fel om man spelar 192kHz 24bits ljud inträffar ungefär en gång i halvtimmen

[sammel]

Vilket innebär att ett Bit-Fel om man spelar 192kHz 24bits ljud inträffar ungefär en gång i halvtimmen

Det kan man ju stå ut med

[I-or]

Nä, sannolikheten för ett bitfel under 1 s är alltså 192000x24x2x10^-12 = 9,2*10^-6 i värsta fall. (10^-12 kan även skrivas 1e-12, dock ej 10e-12)

M.a.o. har vi i värsta fall ett fel per 30 timmars lyssning även när vi som i detta exempel slösar med mängder av ohörbara data. Oftast blir det betydligt färre fel.

[petersteindl]

Så USB trasar sönder ljudet.

[Tell]

Och inte innebär väl det att taskig omsampling till 48kHz är att föredra?

Men är omsamplingen taskig då? Hör ni massa fel när Android omsamplar eller har ni mätningar som visar att det är ett faktiskt problem? Eller är det så att jakten på bitperfect är överdriven och onödig?

[jansch]

Nä, sannolikheten för ett bitfel under 1 s är alltså 192000x24x2x10^-12 = 9,2*10^-6 i värsta fall. (10^-12 kan även skrivas 1e-12, dock ej 10e-12)

M.a.o. har vi i värsta fall ett fel per 30 timmars lyssning även när vi som i detta exempel slösar med mängder av ohörbara data. Oftast blir det betydligt färre fel.

Dessutom är det nog bara enstaka bitfel på de två minst signifikanta bits:en som kan ha påverkan på audiosignalen.

[nuffe]

Alltså konstaterar jag att CD och CD-rom även över USB är milsvitt bättre än en LP, häpp!

[jansch]

Och inte innebär väl det att taskig omsampling till 48kHz är att föredra?

Men är omsamplingen taskig då? Hör ni massa fel när Android omsamplar eller har ni mätningar som visar att det är ett faktiskt problem? Eller är det så att jakten på bitperfevt är överdriven och onödig?

Det största "problemet" är att vissa auiofiler tror att digitaliserat ljud kan påverkas/förvrängas på samma sätt som anlog ljudsignal kan förvrängas
Alla dessa "analoga" uttalanden såsom "snabbare bas" eller t o m "mer bas" eller "krispigare mellanregister" och liknande kan helt enkelt inte uppstå i den digitala världen.
ALLA bitfel, när mängden av dom blir så stor att det blir hörbart efter D/Aomvandling, blir knaster/skrap/etc och då utan koppling till musiksignalen.

T.ex sannolikheten att en "digital" baston skulle bli svagare/starkare under en enda sekund i en övrigt god återgivning är totalt obefintlig.
I så fall skulle över 700 000 bits få ett nytt specifikt/korrekt värde i rätt ordning, dessutom beroende på övrig musiksignal, d v s mönstret upprepar sig aldrig. För varje sekund en ny specifik kombination av 700 000 felaktiga bits.