S
Syncrolux
Gjest
Det kan godt hende. Men det har ingen ting å si. En datapakke vil enten komme fram 100% korrekt, eller ikke komme fram i det hele tatt.
Test av Audioquest Vodka Ethernet kabel
- Trådstarter marsboer
- Startdato
S
Syncrolux
Gjest
CD-drivverk og streamere sender i realtime uten mulighet for retransmisjon, så ja det er en stor forskjell her.
SPDIF og AES/EBU er en-veis kommunikasjon. Mottageren har ingen mulighet for å si fra til avsender at dataene ikke kom fram korrekt.
Når det er sagt så vil CRC-korreksjon gjøre at data fra CD-drivverk og streamere i praksis rekontrueres 100%.
Ved http-streaming over Ethernet (eller wifi) er det veldig mange feilsjekker og mulighet for retransmisjon under veis.
Mitt skrekkeksempel er en norsk hifi-skribent som for flere år siden testet et norskt nettfilter, hvor han påberopte enorme forskjeller med og uten filter.
selve teknologien var gjemt i en jernkasse slik at alt skulle være "hemmelig". Det var ikke måte på hvor mye bedre et låt...
Danske High Fidelity, som gikk langt dypere i materien når de testet, tok og kuttet opp hele jernkassen for å sjekke hva som skjulte seg og hva fant de?
Strømledningen gikk rett gjennom kassen, uten så mye som en ferritklump eller annet koblet til. Med andre ord, ren humbug. Naturlig nok leser jeg ALDRI noe den fortsatt aktive hifi-journalist skriver.
selve teknologien var gjemt i en jernkasse slik at alt skulle være "hemmelig". Det var ikke måte på hvor mye bedre et låt...
Danske High Fidelity, som gikk langt dypere i materien når de testet, tok og kuttet opp hele jernkassen for å sjekke hva som skjulte seg og hva fant de?
Strømledningen gikk rett gjennom kassen, uten så mye som en ferritklump eller annet koblet til. Med andre ord, ren humbug. Naturlig nok leser jeg ALDRI noe den fortsatt aktive hifi-journalist skriver.
Nei, både på grunn av ulikt jitternivå fra avsender og tilført jitter pga båndbreddebegrensninger i overføringen. Men grunnen til at det kan bli slik er at AES/EBU og S/PDIF er en synkron overføring hvor klokkesignalet er begravd i selve datastrømmen. Mottakeren må synkronisere seg til den bitstrømmen som kommer, og ulike DAC'er er ulikt robuste mot tidsvariasjoner i den datastrømmen. Hvis DAC'en har upresise tidsangivelser for hvert datapunkt i det selve D/A-konverteringen skjer, vil den skape umusikalsk analog forvrengning på utgangen. Det kan låte som større eller mindre grad av "digital hardhet".
Men Ethernet er en asynkron pakkeswitchet overføringsprotokoll. Den sender data i bursts som mottakeren får bufre og klokke ut selv. Den har også mengder av paritetskontroller og handshaking mellom sender og mottaker som sikrer at hele pakken er kommet frem korrekt. Det gir ingen som helst mening å snakke om jitter (klokkevariasjon) i en asynkron overføring. Enten fungerer den korrekt, eller så blir det dropouts og rebufring i mottakerenden. Analoge forskjeller som mer eller mindre hardhet, varme, detaljer osv kan bare ikke oppstå i den overføringen.
Ethernet er ikke en protokoll. Spørsmålet er hvilken protokoll som brukes. TCP -> ingen datatap, UDP -> mulig datatap. HTTP kan være over begge. Uansett, det blir et spørsmål om protokoll, og ikke kabelspesifikasjon. Spotify bruker f.eks. TCP, så det vil ikke være mulig at ulike nettverkskabler påvirker lydkvaliteten, så lenge det er som Asbjørn skriver; "Enten fungerer den korrekt, eller så blir det dropouts og rebufring i mottakerenden." Hva som skjer via AES/EBU og S/PDIF er et annet spørsmål, men for at jitter/klokkeproblemer skal bli hørbare med en DAC av normalt god kvalitet, må det være noe feil et sted i kjeden. Man kan i så fall f.eks. høre det i klangen av en pianostreng. Hvis man hører forskjell på DAC-er er den ene for dårlig, dvs. at den ikke gjør det den skal, og den andre normalt god.
Det blir et definisjonsspørsmål. Noen forfattere beskriver ethernet som en nettverksprotokoll eller en link layer protocol (eksempel, eksempel), men det er kanskje litt upresist. Kanskje det er bedre å si en nettverksteknologiplattform, en familie av nettverksteknologier eller en familie av nettverksprotokoller. Da er vi muligens på høyere språklig presisjonsnivå enn vanlig for HFS. 
Hos meg er transportprotokollen stort sett TCP mellom Logitech Media Server og Transporter. Transporteren bruker visstnok UDP ved oppstart når den søker etter servere på nettverket. Da sender den pakker ut i eteren uten å ha etablert en mottaker først, så den må vel regne med at noen forsvinner. Derimot er både musikkavspillingen og kontrollsignalene på en variant av TCP med alle dertil hørende paritetskontroller.
Asynkront og pakkeswitchet er det uansett, og det er hovedpoenget i denne sammenhengen.
Hos meg er transportprotokollen stort sett TCP mellom Logitech Media Server og Transporter. Transporteren bruker visstnok UDP ved oppstart når den søker etter servere på nettverket. Da sender den pakker ut i eteren uten å ha etablert en mottaker først, så den må vel regne med at noen forsvinner. Derimot er både musikkavspillingen og kontrollsignalene på en variant av TCP med alle dertil hørende paritetskontroller.
Asynkront og pakkeswitchet er det uansett, og det er hovedpoenget i denne sammenhengen.
Sist redigert:
Skulle ønske Audioquest kunne forklart hva ethernet audio er.
Selvsagt er det kun fri fantasi fra deres side men det hadde vært artig om de hadde forsøkt.
Snart kommer Linje-Kablene(TM). Disse har passert ekvator to ganger og låter selvsagt overlegent.
Fler passeringer == ytterligere forbedringer.
- Ble medlem
- 10.09.2004
- Innlegg
- 718
- Antall liker
- 395
Kanskje på tide å lære seg hvordan slike ting fungerer?
- Ble medlem
- 10.09.2004
- Innlegg
- 718
- Antall liker
- 395
Jeg synes det mest interessante med slike saker er hvor ivrige alle er etter å finne en bortforklaring på observasjonen.
For så vidt. En protokoll er konkret og begrenset, mens ethernet blir en paraplydefinisjon for alt mulig rart. Det du sikta til var uansett mynta på bl.a. TCP, så jeg synes presiseringen var relevant.
Du redigerte fra "kommunikasjonsprotokoll", gjorde du ikke? ;-)
Jeg har selv stått i Hessdalen og studert UFOer.
Det kom et lys over fjellkammen, og entusiastene utbrøt "Se, der kommer den!"
Etter hvert hørte vi lyden av jetmotorer, og entusiastene sa "Så synd at vi hørte motorene, for ellers kunne dere også sagt at dere hadde sett Hessdalsufoen."
Man ser det man vil se, og vil bare ikke se de opplagte forklaringene når den mest usannsynlige forklaringen er mer spennende. Hessdalen ligger for eksempel nær det punktet hvor fly på vei inn til Værnes ved Trondheim slår på landingslysene.
Sist redigert:
Jepp, i et forsøk på være enda mer presis enn jeg pleier.
Sikkert, og du er sikkert behjelpelig med å påpeke hva som er feil
Siden kommunikasjon er mer enn transport, vil jeg rose deg for presisjonen ;-)
Se på dette produktet.
"QED Performance Ethernet-kabel med solid byggekvalitet og høy båndbredde. En ideel kabel for å overføre høykvalitets digital lyd mellom nettverks ethernet komponenter opp til 24 bit / 192 kHz. Med CAT 6-spesifikasjonen og 250MHz båndbredde er QED Performance Ethernet mer enn rustet til å håndtere den nyeste HD-lyden.
De fleste vanlige nettverkskabler er konstruert til CAT5E standard og er kun angitt for datahastigheter opp til 100MHz. QED Performance Ethernet-kabelen er derimot en over-spesifisert CAT6 nettverkskabel i stand til datahastigheter opp til 250MHz - noe som gir den rikelig med takhøyde når HD-lyd skal streames."
Den nyeste HD-lyden! Jeg er over meg av begeistring.
Det de skriver om Cat 5e og Cat 6 er fullstendig irrelevant for en sluttbruker som streamer en så liten datamengde som denne såkalte HD-lyden utgjør.
"overføre høykvalitets digital lyd mellom nettverks ethernet komponenter opp til 24 bit / 192 kHz" - det ligger nok ingen begrensning i kabelen, eller kanskje de skal selge en annen kabel for å overstige 24 bit og 192 kHz?
Villedende markedsføring så det holder.
Se på dette produktet.
"QED Performance Ethernet-kabel med solid byggekvalitet og høy båndbredde. En ideel kabel for å overføre høykvalitets digital lyd mellom nettverks ethernet komponenter opp til 24 bit / 192 kHz. Med CAT 6-spesifikasjonen og 250MHz båndbredde er QED Performance Ethernet mer enn rustet til å håndtere den nyeste HD-lyden.
De fleste vanlige nettverkskabler er konstruert til CAT5E standard og er kun angitt for datahastigheter opp til 100MHz. QED Performance Ethernet-kabelen er derimot en over-spesifisert CAT6 nettverkskabel i stand til datahastigheter opp til 250MHz - noe som gir den rikelig med takhøyde når HD-lyd skal streames."
Den nyeste HD-lyden! Jeg er over meg av begeistring.
Det de skriver om Cat 5e og Cat 6 er fullstendig irrelevant for en sluttbruker som streamer en så liten datamengde som denne såkalte HD-lyden utgjør.
"overføre høykvalitets digital lyd mellom nettverks ethernet komponenter opp til 24 bit / 192 kHz" - det ligger nok ingen begrensning i kabelen, eller kanskje de skal selge en annen kabel for å overstige 24 bit og 192 kHz?
Villedende markedsføring så det holder.
Jepp. 2 kanaler x 24 bits x 192 kHz = 9,2 Mbit/s. Allerede det første ethernet-interfacet fra 1981 greide å overføre 10 Mbit/s, dengang på coax i stedet for Cat noe som helst.
Sist redigert:
- Ble medlem
- 19.09.2014
- Innlegg
- 20.801
- Antall liker
- 13.295
Nå er dere slemme, gutter. Vennligst ikke forvirre med fakta.
Nei, du ser vel at den audiofile kabelbransjen har begynt å reklamere med Cat 8. Kan absolutt ikke være dårligere enn det for å unngå jitter i diskanten og tilsløring av bondepiker.
er litt moro med cat 7 med tanke på at:
cat 5e=1gigabit per sek over 100meter
cat6= 1gigabit per sek over 100meter,
cat7= 10gigabit per sek over 100meter
10gigabit er og mye kjappere en det vanlige hardisker klarer å betjene så raid 5 med ssd ?
en normal ssd klarer rundt 450mb/s=4.5gigabit (forenklet men relativt nært enda)
ergo det er tull å benytte dette på noe annet en servere eller kraftige multi cpu stasjoner med raid etc.
cat 5e=1gigabit per sek over 100meter
cat6= 1gigabit per sek over 100meter,
cat7= 10gigabit per sek over 100meter
10gigabit er og mye kjappere en det vanlige hardisker klarer å betjene så raid 5 med ssd ?
en normal ssd klarer rundt 450mb/s=4.5gigabit (forenklet men relativt nært enda)
ergo det er tull å benytte dette på noe annet en servere eller kraftige multi cpu stasjoner med raid etc.
Julenissen samler dem opp i sleden sin og gir dem tilbake som streamingabonnement på julaften.
- Ble medlem
- 10.09.2004
- Innlegg
- 718
- Antall liker
- 395
Du kan sikkert finne ut av dette selv, men jeg håper at du ikke tror du får merker og striper på bildene du skriver ut hvis du bruker en "dårlig" kabel. Er det brudd i kabelen skrives det ikke ut en dritt selvfølgelig, verken med eller uten striper, og da er det nok riktig å bytte kabelen.Sikkert, og du er sikkert behjelpelig med å påpeke hva som er feil
Nå er det ikke bare en leder i en sånn kabel og feil kan gi flere uttrykk. Poenget mitt var at du ikke får fargefeil eller kontrastendringer i et bilde om du skriver ut med en delvis ødelagt eller dårlig kabel. Du får som regel horisontale eller vertikale striper over bildet som viser at signalet har fallt ut noen ganger og dermed ikke fått med alt. Litt som synlig jitter.Du kan sikkert finne ut av dette selv, men jeg håper at du ikke tror du får merker og striper på bildene du skriver ut hvis du bruker en "dårlig" kabel. Er det brudd i kabelen skrives det ikke ut en dritt selvfølgelig, verken med eller uten striper, og da er det nok riktig å bytte kabelen.Sikkert, og du er sikkert behjelpelig med å påpeke hva som er feil
Sist redigert:
Nei, dette er nok feil DagT.Nå er det ikke bare en leder i en sånn kabel og feil kan gi flere uttrykk. Poenget mitt var at du ikke får fargefeil eller kontrastendringer i et bilde om du skriver ut med en delvis ødelagt eller dårlig kabel. Du får som regel horisontale eller vertikale striper over bildet som viser at signalet har fallt ut noen ganger og dermed ikke fått med alt. Litt som synlig jitter.Du kan sikkert finne ut av dette selv, men jeg håper at du ikke tror du får merker og striper på bildene du skriver ut hvis du bruker en "dårlig" kabel. Er det brudd i kabelen skrives det ikke ut en dritt selvfølgelig, verken med eller uten striper, og da er det nok riktig å bytte kabelen.Sikkert, og du er sikkert behjelpelig med å påpeke hva som er feil
Les "Bulk transfers" nederst på denne websiden: USB in a NutShell - Chapter 4 - Endpoint Types
Sitat: Bulk transfers provide error correction in the form of a CRC16 field on the data payload and error detection/re-transmission mechanisms ensuring data is transmitted and received without error.
Som du ser så blir ikke data med feil bli akseptert ved en USB overføring. Dette gjelder all overføring av data mellom printere, scannere, minnepenner etc.
Skulle det oppstå datafeil på grunn av dårlig kabel eller støy, så vil dette simpelthen bli oppdaget og dataene vil bli sendt på nytt. Etter et visst antall forsøk vil driveren gi opp og man får feilmelding. Ikke striper i bildet.
Se forøvrig avsnittet over. Det blir det noe annet. (Isochronous Transfers)
OK, takk for korreksjonen, jeg gikk tilbake til de tilfellene jeg har observert det og fant ut jeg den gangen brukte FireWire (trur eg - farlig lenge siden). Mulig det er noen forskjeller der. Uansett ville ikke den godeste fotokunsteren som ble trukket frem her forskjell på bildene.