Optisk Signalöverföring "Toslink"

av **woland** » 2005-10-07 23:27

Någon som har erfarenhet av dessa fiberkablar?
Vad väljer man?
No Name 50:- +.....eller.....?
Vill bara läsa seriösa/ljudmässigt relevanta inlägg

Mvh

av **matte** » 2005-10-08 02:48

Hellre nåt åt den andra sidan 100ingen iallafall...

Har för mig att de billigare använder sig av nån form av plast som ledaren,medans de riktiga använder specialslipat glasfiberoptik,förenklat utryckt...
Jag har Monstercables Lightspeed100 och e helnöjd med den.
Fast den kostade 500 spänn då.

Good Luck
Matte

av **ptr** » 2005-10-08 10:27

Själva den optiska ledaren brukar vara samma billiga i alla optiska kablar, skillanden i ligger helt klart i termineringen. Du betalar inte för plastfibern utan hur väl kontaktdonen i ändarna ansluter till källan.

Använder själv ett par Supra X-ZAC Toslink (ca. 700pix - mellan DAT och Ljudkort för att tanka in musik i datorn) och skillnaden mellan Suprakablanrna och dom för en 50lapp från Clas Ohlsson jag hade innan är markant! (/Ännu mer så mellan dom som kom med ljudkortet..) -- Jag blev faktiskt förvånad första gången jag satt och tankade och plötsligt var det någon ting som tagit ett steg fram i ljudbilden.

/ptr

av **woland** » 2005-10-08 22:20

OK, tack för svaren. Låter rimligt att terminiringen spelar roll. Det är ju den som kostar. Kollat lite men ingen uppger ju om det är glas eller plastledare som kablarna innehåller. Eftersom jag jobbar i databranchen så vet jag att fiberoptik är vida överlägset kopparledare i kapacitet samtidigt så har ju nästan hela HiFi-världen varit emot Toslinköverföring, undrar varför?

Är det samma "bullshitsnack" som spikes kontra mjuka fötter?

Som jag ser det borde optisk överföring bara ha fördelar?

Mvh

av **ptr** » 2005-10-08 22:39

woland skrev:Kollat lite men ingen uppger ju om det är glas eller plastledare som kablarna innehåller.

Tveklöst är det så att det är plast i nästan all optisk fiber som tillverkas, sedan vad det är för plast vågar jag inte säga..

Pratade med Tommy Jenving (Supra) för några år sedan om han sa att skillanden mellan olika fabrikat och kvaliteter av fiber är försvinnande liten (Dom köpte från någon Japansk tillverkare, kan ha vart Tayo Yuden, men jag minns inte)...

/ptr

av **n-puh** » 2005-10-09 01:08

Det borde gå att direkt se om det rör sig om plastfiber genom att titta på kontaktänden. Plastfibern som används för toslink har en diameter på 1 mm och så tjocka kvartsfiber lär knappast nyttjas i nåt sammanhang med signalöverföring.

Hur väl kontakterna ansluter till källan och mottagare har säkert störst inverkan på förlusterna i överföringen men här rör sig ju ändå om digitala signaler som har betydande störmarginaler.

CD-systemets implementering av PCM, MPEG, AC-3 eller vad som nu överförs över toslink innehåller väl var och en dessutom sin egen felkorrektion och information om bitrate vid sidan av att mottagare kan få ut klockfrekvensen ur den biphase kodade signalen.

Så jag tror knappast att man märker skillnad på olika toslink-kablar så länge som F05-kontakterna är korrekt utförda. Inte heller tror jag man hör skillnader av typen "saker och ting tar ett steg fram i ljudbilden". Sådant kan säkert avfärdas som ren inbillning. Influenser från fel där CD-systemets felkorrektion inte räcker till och man får tillfälliga bidrag från interpolation eller muting framträder alls inte på det viset.

Men toslink för överföring digitala audiosignaler har faktiskt både betydande begränsningar i kablagelängd och bandbredd som måste övervägas beroende på användningen.

Själv har jag använt Supra Zac kablar och aldrig märkt av några fel i överföringen.

av **woland** » 2005-10-09 01:20

Jag tackar för dessa inlägg, men undra över

"Men toslink för överföring digitala audiosignaler har faktiskt både betydande begränsningar i kablagelängd och bandbredd som måste övervägas beroende på användningen. "

Vad skiljer då denna överföring från vanlig dataöverföring?

Mvh

av **n-puh** » 2005-10-09 01:45

Toslink kan användas för dataöverföring i olika sammanhang men togs fram som en billig lösning för enklare ändamål.

(Fast om man ser till vad alla monster, supra, proel, mfl kablar kostar kan man knappt tro det)

Telekomvärlden tex jobbar ju med helt andra våglängder, fibertyper, kontakttyper, singalkodning osv. I stort regererar väl ändå koppar fortfarande när vi talar om telekom och datakommunikation. Det finns betydande mängder nergrävd koppar redan och arbetet med att gräva ner kabelstammar är ju det som kostar. Inte undra på att intresset för radio har varit stort. Nåja, det är väl ekonomin som styr egentligen. Vilken transmissionslänk ger mest bang for the buck i dagsläget. Frontlinjerna flyttas ständigt fram med ny teknik som kämpar om att bli defacto standard.

av **Michael** » 2005-10-09 11:00

n-puh skrev:CD-systemets implementering av PCM, MPEG, AC-3 eller vad som nu överförs över toslink innehåller väl var och en dessutom sin egen felkorrektion och information om bitrate vid sidan av att mottagare kan få ut klockfrekvensen ur den biphase kodade signalen.

Överföring av PCM ljud (CD standard) via S/PDIF (koax eller toslink) anslutning innehåller ingen checksumma eller felkorrektionsbitar. Blir det bitfel så lär det höras. Om MPEG eller AC-3 (DD) innehåller detta vet jag inte.
Jag har bl.a. gjort en liten test och kollat bitfel från en billig Sony CD och en Pioneer DVD. Då använde jag billig toslink kabel. Resultat; inga bitfel. Då återstår jitter; om olika toslink kablar kan ge olika jitter har jag inte någon aning om.
//Michael

av **Style** » 2005-10-09 11:24

Mich skrev:Överföring av PCM ljud (CD standard) via S/PDIF (koax eller toslink) anslutning innehåller ingen checksumma eller felkorrektionsbitar. Blir det bitfel så lär det höras. //Michael

det är reed salomon kodat så där har du fel

av **Michael** » 2005-10-09 11:36

Style skrev:det är reed salomon kodat så där har du fel

Då stämmer alltså inte informationen i t.ex. detta dokument?
http://www.cirrus.com/en/pubs/appNote/an22.pdf
//Michael

av **Jax** » 2005-10-09 11:38

Style skrev:
Mich skrev:Överföring av PCM ljud (CD standard) via S/PDIF (koax eller toslink) anslutning innehåller ingen checksumma eller felkorrektionsbitar. Blir det bitfel så lär det höras. //Michael

det är reed salomon kodat så där har du fel

På skivan ja. I spdif finns ingen kodning alls. Inte ens paritetsbit.

Bitfel är sällsynt dock, jitter kan vara ett större problem.

av **Style** » 2005-10-09 11:58

jo det förstås men att att det ska uppstå bitfel i själva överföringen är väldigt osannolikt. Det är bra mycket troligare att du får läsfel på skivan och det fixar RS-kodningen.

av **silvervarg** » 2005-10-09 12:54

Nackdelen med toslink över koax är väl att man börjar med en elektrisk signal och vill ha en elektrisk på mottagarsidan. I fallet toslink behöver man omvandla signalen till ljus och sedan tillbaks igen.
Störningar/fel som uppkommer i den enkla omvandligen är inte försummbara om man antar överföring på korta avstånd (max 5 meter).
Dvs omvandligen och kontakterna blir det viktiga.

När det gäller data och telekom så pratar vi oftast helt andra avstånd, ofta flera kilometer, och då är förståss kabeln i sig och eventuella störningar i kabeln av stor vikt.
Ofta väljs då kabel som är känslig för tvära böjar. En sådan kabel skulle vara riktigt knepig att använda i en vanlig stereoanläggning och mycket lätt att förstöra kabeln.

av i » 2005-10-09 15:50

Jax skrev:
Style skrev:
Mich skrev:Överföring av PCM ljud (CD standard) via S/PDIF (koax eller toslink) anslutning innehåller ingen checksumma eller felkorrektionsbitar. Blir det bitfel så lär det höras. //Michael

det är reed salomon kodat så där har du fel

På skivan ja. I spdif finns ingen kodning alls. Inte ens paritetsbit.

Bitfel är sällsynt dock, jitter kan vara ett större problem.

Fast.. det spelar väl ingen roll egentligen om checksumman finns "bara på skivan" och inte i själva överföringsformatet ?
Jag menar: korrektionskretsarna (i mottagande apparat) arbetar väl lika bra/dåligt oavsett om felet uppstod i avläsningen av skivan eller i överföringen ?

av **Style** » 2005-10-09 15:55

i skrev:
Jax skrev:
Style skrev:
Mich skrev:Överföring av PCM ljud (CD standard) via S/PDIF (koax eller toslink) anslutning innehåller ingen checksumma eller felkorrektionsbitar. Blir det bitfel så lär det höras. //Michael

det är reed salomon kodat så där har du fel

På skivan ja. I spdif finns ingen kodning alls. Inte ens paritetsbit.

Bitfel är sällsynt dock, jitter kan vara ett större problem.

Fast.. det spelar väl ingen roll egentligen om checksumman finns "bara på skivan" och inte i själva överföringsformatet ?
Jag menar: korrektionskretsarna (i mottagande apparat) arbetar väl lika bra/dåligt oavsett om felet uppstod i avläsningen av skivan eller i överföringen ?

ja så måste det naturligtvis vara

av **Michael** » 2005-10-09 17:34

i skrev:Fast.. det spelar väl ingen roll egentligen om checksumman finns "bara på skivan" och inte i själva överföringsformatet ?
Jag menar: korrektionskretsarna (i mottagande apparat) arbetar väl lika bra/dåligt oavsett om felet uppstod i avläsningen av skivan eller i överföringen ?

Korrektionskretsarna sitter i den apparat som läser skivan (transport) och inte i apparaten efter toslink kabeln (DAC). Med andra ord korrektionskretsarna kan inte korrigera för fel i toslink (S/PDIF) överföringen. Digitalt (S/PDIF) så transporteras ljudet sample för sample utan några felkorrektionsbitar. Blir det bitfel i ljudbitarna så blir det bitfel, går inte att fixa till.
//Michael

av **Style** » 2005-10-09 23:14

Mich skrev:
i skrev:Fast.. det spelar väl ingen roll egentligen om checksumman finns "bara på skivan" och inte i själva överföringsformatet ?
Jag menar: korrektionskretsarna (i mottagande apparat) arbetar väl lika bra/dåligt oavsett om felet uppstod i avläsningen av skivan eller i överföringen ?

Korrektionskretsarna sitter i den apparat som läser skivan (transport) och inte i apparaten efter toslink kabeln (DAC). Med andra ord korrektionskretsarna kan inte korrigera för fel i toslink (S/PDIF) överföringen. Digitalt (S/PDIF) så transporteras ljudet sample för sample utan några felkorrektionsbitar. Blir det bitfel i ljudbitarna så blir det bitfel, går inte att fixa till.
//Michael

är du säker på att det är så, verkar ju tokdumt

av **Jax** » 2005-10-09 23:33

Style skrev:är du säker på att det är så, verkar ju tokdumt

Det är så.

av i » 2005-10-10 12:04

Mich skrev:
i skrev:Fast.. det spelar väl ingen roll egentligen om checksumman finns "bara på skivan" och inte i själva överföringsformatet ?
Jag menar: korrektionskretsarna (i mottagande apparat) arbetar väl lika bra/dåligt oavsett om felet uppstod i avläsningen av skivan eller i överföringen ?

Korrektionskretsarna sitter i den apparat som läser skivan (transport) och inte i apparaten efter toslink kabeln (DAC). Med andra ord korrektionskretsarna kan inte korrigera för fel i toslink (S/PDIF) överföringen. Digitalt (S/PDIF) så transporteras ljudet sample för sample utan några felkorrektionsbitar. Blir det bitfel i ljudbitarna så blir det bitfel, går inte att fixa till.
//Michael

Det var ju synd !

av **Qaz** » 2005-10-24 19:23

Toslink ger ju dessutom galvanisk avskilljning.

En dator är ju till exempel kanske inte vad man vill ha med i analogdelen av anläggningen.

Jag har alldelles för mig att det finns med en paritetsbit i spdif, men kan inte hitta dokumentet, det är alltså inte så?

Har det inte någon kontroll alls borde det höras tydligt om det blir bitfel. Sanorlikheten är ju lika stor* att det blir fel nära mest signifikanta biten. Och fel i den änden borde verkligen höras tydligt (som ryck/pop).

* Toslink/spdif är ju pulsbredsmodulerat, varvid mottagaren borde synka om sig för varje bit, varvid chansen för fel inte ökar ju längre i ett överfört ord man kommer, som tex med uart.

Att betala nära eller över 1000:- för en optisk kabel på 1.5m verkar ju helt skadat. För 100:- eller lite drygt måste de fan kunna kontaktera de nog bra.

av **Jax** » 2005-10-24 19:49

Qaz skrev:* Toslink/spdif är ju pulsbredsmodulerat, varvid mottagaren borde synka om sig för varje bit, varvid chansen för fel inte ökar ju längre i ett överfört ord man kommer, som tex med uart.

Bifasmodulerat, inte pulsbredd (som man normalt förknippar med analoga system) fast du kanske skrev fel i hastigheten?

Bifas gör det lätt för en faslåst loop att gräva ut klockan ur strömmen.

av **Qaz** » 2005-10-24 20:57

Jax skrev:
Qaz skrev:* Toslink/spdif är ju pulsbredsmodulerat, varvid mottagaren borde synka om sig för varje bit, varvid chansen för fel inte ökar ju längre i ett överfört ord man kommer, som tex med uart.

Bifasmodulerat, inte pulsbredd (som man normalt förknippar med analoga system) fast du kanske skrev fel i hastigheten?

Bifas gör det lätt för en faslåst loop att gräva ut klockan ur strömmen.

Det stämmer. Skrev förvisso inte fel, tänkte fel :p.
Men det gör ju ingen skillnad på att fel borde vara lika vanliga i börja som i slutet av varje ord.

Enligt http://www.epanorama.net/documents/audio/spdif.html
Finns en paritetsbit dock med varje sample. Skulle vara intressant att veta vad dacen gör om pariteten inte stämmer?

av **Jax** » 2005-10-24 21:07

Jax skrev:I spdif finns ingen kodning alls. Inte ens paritetsbit.

Jag korrigerar mig själv, det finns en paritetsbit. :oops:

Den talar i och för sig bara om att någon bit blivit fel i samplet så någon felkorrektion kan inte göras.

Vad en DAC skulle göra vet jag inte, troligen samma som om validitetsbiten är fel, tyst sample.

av **Qaz** » 2005-10-24 21:26

Jax skrev:
Jax skrev:I spdif finns ingen kodning alls. Inte ens paritetsbit.

Jag korrigerar mig själv, det finns en paritetsbit.

Den talar i och för sig bara om att någon bit blivit fel i samplet så någon felkorrektion kan inte göras.

Vad en DAC skulle göra vet jag inte, troligen samma som om validitetsbiten är fel, tyst sample.

Rimligt vore ju att ta samma värde som den innan, eller hellst en linjärinterpolering mellan föregående och nästa.

av **CJNE** » 2005-10-24 21:47

Men är det inte så att det är jitter och inte eventuella bitfel som är det
största problemet?
Vad är vanligast (i HiFi sammanhang), att använda klockan från
signalen eller att använda en intern klocka ihop med buffert i mottagaren?

Det senare borde väl eliminera jitterproblem.

av **Qaz** » 2005-10-24 22:41

Jag är inte riktigt säker på vad som menas med "jitter".

Är det att samplingar kommer med ojämna mellanrum?

En buffer är väl vad man hör som lösning på problemet vanligen i alla fall.

av **CJNE** » 2005-10-24 23:02

Ja det är vanligen variationer i klocksignalen som avses när man
pratar om jitter om jag inte är helt felunderrättad.

Och en buffer borde ju ta hand om sådana problem, men det vore
intressant att höra om nån har koll på om det är den brukligt i
HiFi-sammanhang (S/PDIF) att göra så.

av **wayfarer** » 2005-10-26 23:50

Först så kan man läsa själva spectexten i EBU utgåvan. Vet inte exakt hur den relaterar till IEC versionen.

Vad jag förstår av den så svarar den på en del av era frågor.

1. Att ramformatet har en paritetsbit per upp till 24 bitars ord har ni ju redan nämt.

2. Det finns ingen definerad klock hastighet utan mottagaren kan gör clock detektering och återskapande tack vare modulationen.

Tyvärr så svarar denna spec inte på hur man packar data för multi-kanal fallen. Dock vet jag att AC-3 (Dobly Digital) har egen ram CRC. Detta kan man läsa i AC-3 standarden kapitel 5.4.5 som säger att det är två CRC, en för först 5/8 av ramen och en andra på 16 bitar över hela ramen.

AC-3 ger också insikt i det här med jitterfrågan. I detta fall så måste spelaren ha en clocka som styr utspelandet av de återskapade PCM från AC-3 avkodaren.

Som det verkar med 2-kanals PCM överföring för SPDif så är det ju helt klart att man kan bygga någonting som inte skulle påverkas något av timing jitter hos den återskapade signalen. Men frågan kvarstår, hur ser det ut i de flesta enheter. Driver de D/A med den återskapade clockan eller använder de en egen klocka som de bara ser till går i samma hastighet som inkommande data?

Är det någon som vet var man kan läsa om hur de packar in DD och DTS i SPDIF?

Magnus

av **foxman** » 2005-10-27 21:05

Den här kanske?
http://marcuscables.com/audio_optisk.htm