Newsgroup: it.hobby.home-cinema
Titolo: ottico o coassiale... ultimo capitolo.

Are you sure about that error rate? Is it really errors-per-bit?
Yes, David.  I am sure.
Toshiba's published bit error rate (BER) specification is <= 1EE-9 bits (ie
1
bit in 10^9 bits) when transmitting at six Mb/s NRZ with a duty cycle
between
25-75%, or 3 Mb/s biphase transmission with optical power between -27 dbm to
- -14.5 dbm.  48KHz optical transmission uses a 64 bits/stereo word frame
and
amounts to 3.072 Mb/s.  The manufacturer quotes these rates at ambient
temperature 25 degrees C and voltage of 5.00 V using APF (all plastic fiber)
970/1000 micrometer cable.
This BER is typical of all major digital audio fiber optic
transmitter/receiver manufacturers.  We use the Toshiba brand over less
expensive brands because it is of higher quality.  The transmitter uses
unique differential pair circuitry to minimize power supply noise that would
be caused by on-off keying without a differential circuit.  Cheaper
transmitters don't use this.  The Toshiba receivers have automatic threshold
correction that cheaper receivers don't have.  We also use a filtered supply
to the Toshiba receiver to limit high frequency noise that can introduce
jitter and errors.  Furthermore, the Toshiba receiver uses a conductive
plastic case to shield the photo diode against EMI pickup.
============================================================================
====
In conclusione : il tasso di errore e' <= a 1E-9 quindi si puo' avere un
drop di paccheto (su 2 canali) ogni 9minuti !!!!
Occhio che il drop e' di 1 (uno) campione ed in 1 secondo ne abbiamo 44mila
circa....  non servono altri commenti, almeno credo.
bye
Gizmo

 wrote in message
Omissis.
Confesso di non aver capito se con questo messaggio vuoi dimostrare ciň che
affermavi, cioč che in presenza di stream compressi un cavo vale
l'altro...oppure, se finalmente sei uscito dal lato oscuro della forza per
dar ragione a Marco R.
Massimo

 dar ragione a Marco R.
Bisognerebbe innanzitutto sapere a quanto ammonta il BER di un coassiale!
Cmq anche secondo me non risolve il problema sugli stream compressi, con
tutti quegli errori come viene ricostruito il flusso corretto? Oppure la
compressione AC3 o DTS permette la ricostruzione delle frequenze anche da un
flusso di dati non corretto?
Qualcuno ci illumini!!!
Cia'!
Mad J

 Qualcuno ci illumini!!!
E quando sai il BER del coax?
Perchč, quel dato ti permette di determinare se lo "jitter č o no
ininfluente su stream compressi"? ( che era l'oggetto della discussione).
Non mi č chiara neanche la storia dei (quasi) 9 minuti:
se tu hai una interfaccia con un BER di 10^9 & 6Mbps, hai un errore in 2.77
minuti.
Massimo

Ciao a tutti,
credevo che il messaggio portasse un lampo di luce... invece...
Ricapitolando:
La discussione precedente era basata sulle differenze che si sentono
impiegando un cavo ottico ed uno coax, questo almeno in teoria.
La pratica e' che:
su un cavo ottivo possiamo avere in media un (1) bit errato ogni 10^9 quindi
su un flusso di 2Mbps fanno circa un errore ogni 9 minuti.
La conclusione e' che il tasso di errore e' talmente basso che non puo'
essere
assolutamente 'sentito' da nessuno al mondo, ma puo' solo essere misurato.
Questo chiude la disputa xche' per quanto + basso sia il BER del cavo  coax
le differenze possono solo essere misurate in laboratorio.
Nel caso degli stream compressi vale lo stesso discorso, un glich on 9
minuti,
adesso non ricordo se l'AC3 ha una correzione di errore inglobata nel
pacchetto
oltre al CRC.
bye
Gizmo

 ininfluente su stream compressi"? ( che era l'oggetto della discussione).
Tempo fa c'era una discussione simile e mi sono documentato sul jitter.
Se non ho capito male il jitter è un leggero errore di fase nei segnali
digitali che potrebbe "ingannare" un DAC tradizionale.
Se però il DAC è riclockato è ovvio che tutte le differenze di fase (purché
non siano tanto grandi da divenire errori di trasmissione) vengono eliminate
da questo sistema, in quanto il segnale viene completamente rigenerato prima
di essere dato in pasto ad DAC.
A maggior ragione il concetto si applica ai segnali compressi.
--
Davide Granzotto

 Non mi è chiara neanche la storia dei (quasi) 9 minuti:


 cui l'equazione DENON 5000 = OLIDATA)...
Senza dubbio. Il flusso deve arrivare senza errori al decoder, 
altrimenti la decodifica non e' possibile.
Questo e' cio' che dice lo standard AC-3 (a_52.pdf su 
www.dolby.com
); 
come si vede, non e' prevista correzione degli errori.
7.10 Error detection
There are several ways in which the AC-3 data may determine that errors 
are contained within a frame of data. The decoder may be informed of that 
fact by the transport system which has delivered the data. The data 
integrity may be checked using the embedded CRCs. Also, some simple 
consistency checks on the received data can indicate that errors are 
present. The decoder strategy when errors are detected is user definable. 
Possible responses include muting, block repeats, or frame repeats. The 
amount of error checking performed, and the behavior in the presence of 
errors are not specified in this standard, but are left to the 
application and implementation.
Nicola Salmoria

 come si vede, non e' prevista correzione degli errori.
[SNIP]
Questo mette la parola fine su tante "udibilità illusive" di cui al thread
"Ancora sui cavi ottici e coassiali" del 15/03/2000...
Quasi quasi mi vien voglia di scrivere ad AFDigitale...
Tanto per la cronaca, nell'articolo di test di un altro lettore DVD (credo
sullo stesso numero, ma devo controllare), viene affermato l'esatto
contrario, cioè che tutti i lettori sono uguali se usati come meccanica per
dati compressi (ac3, dts...). Vorrei tanto sapere chi ha scritto l'articolo
di prova del lettore LG...
Bha!
Un ringraziamento a Nicola (che ormai sospetto faccia di mestiere il
costruttore di lettori DVD!) per il link!
Cià!
Mad J

 Aspetto (speranzoso) che qualcuno ci illumini ulteriormente!
Anche io!!
-- 
Ciao
Marco (Area 5.1)
------------------------------------
Togli NOSPAM per rispondere

 application and implementation.
Benchè il mio Inglese sia già stato messo in dubbio, e le mie conoscenze
in materia siano superficiali, questo sembra avvalorare la mia teoria
che errori generati da fattori esterni, meccaica, cavi o altro, siano
possibili e che il decoder li gestisce a seconda della programmazione
ricevuta fornendo risultati che possono differire all'ascolto.
E' così oppure non ho capito un tubo?!?! :-)))


 "Ancora sui cavi ottici e coassiali" del 15/03/2000...
....
A dire il vero, bastava anche il mio primo messaggio sul BER (bit error
rate),
su questo credo che non ci piova, se la matematica non e' un' opinione.
Bye
Gizmo

 E' così oppure non ho capito un tubo?!?! :-)))
Sembrerebbe così anche a me...!!!
:))
--
Bye
Mirco
P.S.: ... nel senso che il testo riportato  dà ragione al buon Rosanova....

 P.S.: ... nel senso che il testo riportato  dà ragione al buon Rosanova....
Ciao Mirco, la tua conferma mi rincuora!! :-)))
BTW cosa ne pensi della faccenda?
 
Un caro saluto, anche a casa.


 A maggior ragione il concetto si applica ai segnali compressi.
Il fatto, è che il discorso che si faceva era a prescindere dalle
elettroniche impiegate; elettroniche che possono ridurre ( non eliminare)
più o meno sensibilmente lo jitter.
Massimo

 wrote in message
Omissis.
Attenzione a non confondere "non specificato" con "assente" e attenzione a
considerare l'Ac3 a se stante, cioè senza relazionarlo al supporto.
Massimo

 altrimenti la decodifica non e' possibile.
Se il flusso deve arrivare senza errori al decoder, altrimenti la decodifica
non e' possibile, mi spieghi il senso della presenza del correttore
 (correttore molto sofisticato, tra l'altro)  del decoder?
Massimo

 wrote in message
news:8c1uca$1ar$3...@nslave2.tin.it...

Scusa Massimo,
ha ragione Nicola, in alcuni post precedenti diceva appunto che le infos che
viaggiano
da un dispositivo all'altro (leggi DVD-->Decoder) non contengono i dati per
la correzione
degli errori (RS o altro) ma solo quelle per la rivelatione (dicesi CRC e
famiglia),
quindi il decoder non puo' correggere niente, puo' solo interpolare il dato
in modo + o meno
sofisticato a seconda del numero di campioni mancanti.
Quindi ributtiamo la  palla nella zona del 'mistero del suono'..... :-)))
Bye e buon week end.
Gizmo

 wrote in message
Omissis.
Scusa, ma trovo contradditorio quello che hai scritto:" il decoder non puo'
correggere niente, puo' solo interpolare il dato".
La rivelazione (CRCC) non è fine a se stessa, ma rappresenta il mezzo per
poter effettuare la correzione.
E l'interpolazione è di per sè una correzione.
Interpolazione non certo necessaria se il flusso dovesse arrivare privo di
errori.
Ti sembra?
buon week end anche a te
Massimo

errori.
Scusami anche tu, ma tra i vari i post il tuo mi sembra il piů
approssimativo.
1) La rivelazione (CRCC o qualsiasi altra equivalente) ha senso in
un'ottica di correzione solo in caso di comunicazione bidirezionale,
ed il flusso Spdif non lo č.
In questo caso la rivelazione d'errore permette solo di discrimare tra
una sequenza valida o meno. Non si puň richiedere che la sequenza
venga ritrasmessa.
2) Io non chiamerei affatto l'interpolazione una correzione,
tuttaltro. E' quanto di piů errato ci possa essere. Molti testi di dsp
riportano tabelle comparative che dimostrano come i migliori filtri di
interpolazione da una parte ricostruiscono un segnale molto morbido e
musicale, ma dall'altra non "onorano i dati", ossia non passano per il
valore reale dei campioni, creando spesso un errore maggiore.
3) Interpolare significa ricavare valori intermedi sfruttando la
conoscenzadi quelli estremi. E' un banale risultato matematico che puň
portare a risultati completamente differenti a seconda dell'approccio
usato.E' la creazione di un nuovo valore, non la correzione.
Soprattutto nel caso di stream digitali, segnali  che non contengono i
puri valori in sequenza, ma anche bit di codifica, indirizzamento, ...
che ovviamente non ha senso interpolare.
Ciao
Andrea
Non comprerň mai piů un DvD Cecchi Gori !
la traccia inglese/originale č assente !
il formato originale del film NON č rispettato !
il master video utilizzato č scadente !
mancano i sottotitoli !
non ci sono extra degni di questo nome !

Grazie Andrea,
e' esattamente quello che avrei risposto... mi hai anticipato di qualche
ora....... ;-)
Forse ho sbagliaro io nel post precedente, davo per scontata la conoscenza
di alcuni termini
(leggi CRC, interpolazione in tutte le sue variazioni, correzione
dell'errore....), ma purtroppo
mi sono reso conto che cosi' non era, la risposta di Massimo B. mi ha
leggermente
lasciato si sasso.
Andrea, non conosco i testi dei dsp che tu hai letto pero' la considerazione
che tu fai
puo' andare a pennello solo in casi nei quali c'e' una grandissima assenza
di campioni non e' qeusto il nostro caso.Nel sostro caso mancano pochi
campioni (1-2 max) su un dominio di campioni sempre limitato ma grande 9
minuti. (44K fps).
L'operazione dei Dsp va benissimo se devo fare un upgrade della "frequenza
di campionamento", es: 48K-->96K oppure 22K-->44K, in questo caso e' lecito
aspettarsi una variazione della "musicalita' " o della "morbidezza" del
suono.
bye
Gizmo

 sempre limitato ma grande 9 minuti. (44K fps).
Questo puo' essere vero per l'audio PCM ma non per quello compresso.
Nicola Salmoria

 approssimativo.
Beh, piů che approssimativo direi sintetico.
Mi rendo conto che ciň puň portare a degli equivoci, e cerco di evitarlo, ma
siccome č un modo di scrivere che salta fuori dal mio carattere ..a volte mi
scappa:))
( ammetto, comunque, di aver usato il termine "correzione" impropriamente).
Premesso questo, bando alle ciance e vorrei soffermarmi su un punto che
trovo particolarmente significativo, cioč quando hai scritto:"  Interpolare
significa ricavare valori intermedi sfruttando la conoscenza di quelli
estremi. E' un banale risultato matematico che puň portare a risultati
completamente differenti a seconda dell'approccio usato.E' la creazione di
un nuovo valore, non la correzione.".
Questo č vero, ma solo in presenza di forme complesse di interpolazione,
cioč riferite a N-order ( first-order, third-order, etc); ma
l'interpolazione nella sua forma piů semplice ( previus-value o zero-order)
e in assenza di valori errati continui, non crea un nuovo valore, bensě
replica il valore precedente.
Forse sbaglierň, ma mi risulta che spesso e volentieri in ciň che si trova
in commercio si ha proprio un previus-value accompagnato da un first-order.
Saluti
Massimo

 wrote in message
news:MPG.1351675e7...@news.tin.it...

Lo davo per scontato anche perche' nel caso compresso non si puo' fare
riferimento ad una freq. di campionamento fissa credo....
E poi rientriamo nel caso esposto tempo fa.... se manca un pacchetto
compresso... e' un casino. (almeno per il DSP).
bye
Gizmo