lark skrev:
asbjbo skrev:
Det er sånn det gjøres på en CD. Hvert sample er 16 bit, så det skal være litt av en lesefeil for å sende en sample til feil kanal. Og husk at feilkorreksjonskretsen skal greie å ordne opp med 4000 klin gærne bits etter hverandre uten at det blir noen som helst feil i bitstrømmen til DAC'en.
At det ikke er feil i bitstrømmen til DAC'en betyr vel ikke at det det er eksakte kopier av de manglende samplene som sendes? Jeg klarer etter beste evne ikke å forstå hvordan et korreksjonskretsløp skal kunne vite den nøyaktige rekkefølgen av 16 stk. 0 og 1 i manglende samples. DAC'en er vel tilfreds bare den får sammenhengende 16 bits samples å jobbe med. Kan det forresten føre til økt jitter når korreksjonskretsløpene jobber?
Det er nettopp det det betyr, opp til et visst punkt. Se et innlegg jeg hadde litt lenger oppe, eller slå opp
Cross-Interleaved Reed-Solomon Coding. Patenten fra 1980 er
her. Formler og linker til matlab-scripts og gratis C++ kildekode finnes
her.
Stikkordet er redundans. Det er mer enn 16 bit på skiva for hver 16 bit som skal ut. En CD "frame" er 33 bytes. En byte er subcode, altså data for display og sånt. Av resten er 24 bytes lyddata, mer presist seks 16-bits samples for hver kanal. 16 bit x 2 x 6 / 8 bit pr byte = 24 byte. Og så er det 8 bytes data for feilkorreksjon, som gradvis "brukes opp" før dataene går videre til DAC. Første behandlingstrinn går fra 32 til 28 byte og bruker opp 4 byte korreksjonsdata for å rette inntil to feil i en frame. Hvis det er mer enn to feil i en frame, flagges den for korreksjon i neste trinn - i prinsippet ved å slette hele greia. Alle 28 byte, rett i søpla. Så stokkes dataene på en annen måte, slik at en slettet blokk blir til 28 blokker med én feil i hver. Det retter andre trinn galant ved å gå fra 28 til 24 byte og bruke opp de siste 4 bytene med feilkorreksjonsdata. 33 litt skrukkete byte inn, 24 nystrøkne byte ut,
eksakt like med det som ble forsøkt inngravert på CD'en. Noen hadde
tenkt da dette formatet ble definert.
Det er
bare når alt det der ikke er tilstrekkelig til å rette alle feilene at dekoderen vil forsøke å interpolere. Det bør ikke skje spesielt ofte. En måte å få det til å skje på er å sette en svart tapestrimmel, 2.5 mm bred, på datasiden av en CD. Da blir det så lange lesefeil at dekoderen ikke vil fikse det, og du kan høre hvordan din CD-spiller velger å håndtere den situasjonen.
Det er mulig at feilkorreksjonskretsene skaper litt ekstra jitter. Det er gjenstand for diskusjon. Ettersom hele denne prosessen skjer asynkront, altså før dataene blir bufret og klokket, så må det i så fall skje ved at korreksjonskretsene drar litt mer strøm når de jobber, slik at spenningen til oscillatoren faller litt, som gjør at klokkefrekvensen varierer ørlittegranne. Jeg vet ikke om dette er tilfelle. I så fall kan man hevde at dingsen er underdimensjonert eller direkte feilkonstruert, men det er ikke helt uvanlig at dingser er det.