"Espineter" <espineter***gmail.com> escribió en el mensaje
news:1187936299.177886.134770***e9g2000prf.googlegro ups.com...




> Enhorabuena. Ya era hora que alguien lo consiguiera. He visto en
>tu página que tienes una tabla de samples/bit donde las 4 variantes
>más rápidas son 1.25, 1.5, 1.75 y 2. A bote pronto, se me ocurren
>métodos de 1 bit por símbolo y de 2 bits por símbolo. Los de 2 bits
>por símbolo son los que tienen 4 sumandos.
>
>A) 1+2+3+4 = 10/8 = 1.25

Esa es Non PLus Ultra a 1.25

>B1) 1+2 = 3/2 = 1.5

Ultra a 1.5

>B2) 1+2+4+5 = 12/8 = 1.5 Ligeramente inútil
>B2) 1+2+3+6 = 12/8 = 1.5 Inútil

Esas no están.


>C) 2+3+4+5 = 14/8 = 1.75

Shavings y NPU a 1.75


>D1) 1+3+5+7 = 16/8 = 2 Genial (los símbolos están separados 2 muestras)

NPU a 2. Sí, es buena; llega a funcionar sin mucho problema en el Spectrum+
pero en +3 no.

>D2) x+y+z+t = 16 Cualquier otra combinación hará que al menos 2 símbolos
estén
>a 1 muestra de distancia.
>D3) 1+3 = 4/2 = 2 Igual de genial que D1, pero más sencillo.

Ultra a 2. También muy buena. Con una ajuste fino de volumen funciona en
ambos modelos de Spectrum. Pero lamentablemente solo lo he conseguido a
44100 khz.

>Para la velocidad que has conseguido no se me ocurre otro método distinto
al C,
>corrígeme si me equivoco.


Hay otro. El que utiliza FiQ: 3+3+4+4 .


>Bueno el caso es que tanto C
>como A tienen la misma separación entre símbolos, y por tanto, la
>misma probabilidad de error. La única diferencia es que en A hay que
>ser muy rápido, ya que el símbolo de 1 muestra es muy crítico (80
>ciclos) y además hay que procesar 2 bits.

Aunque cerca del limite la velocidad de proceso del Spectrum no es problema,
puede muestrar como un campeón señales de 24kHz.
El problema es que aunque la separación entre simbolos es teoricamente la
misma
hay una diferencia notable entre medir pulsos y medir ciclos completos
(un pulso negativo más uno positivo) como hace shavings.
Si suponemos un tren de pulsos de una sola muestra -1+1-1+1-1+1-1+1.. o de
dos
-2+2-2+2-2+2-2+2... no hay ningún problema en decodificar la señal.
Pero para este tren de pulsos: -1+2-1+2-1+2-1+2 la señal se desequilibra y
lo que
el Spectrum ve es algo más parecido a esto -1.3+1.7-1.3+1.7-1.3+1.7...
Entonces la
separacion entre simbolos es de solo .5 muestras o menos.

La idea de las formas de onda "compensar continua" y "pulsos de igual
energia"
surgió precisamente para compensar este efecto. Se nota diferencia y mejora
pero
no es suficiente.


>Espero que llegues a 1.25, que supondrán 35280 y 38400 bps (a 44100 y
>48000 m/s).

Por lo anterior parece que va a ser imposible. En todo caso antes habría que
llegar antes a 1.5 con el metodo ultra. Y está, ya digo, muy complicado.

>Yo en su día probé lo del 1.25, pero solo me funcionaba
>bajo emuladores. Desgraciadamente no conservo el código fuente,
>aunque puedes depurarlo cargando el wav en spectaculator. Si te sirve
>te lo dejo aquí, es un manic miner que tarda 6 segundos en cargar,
>bloque basic incluído.
>http://www.antoniovillena.es/ultra/manic.zip

Parte de ese codigo lo utilizo en el programa ZinetriX. Cargar pantallas a
38400
si vale porque algun error en pocos pixel no es problema.


> En cuanto al tema de la compresión, no hace falta que busques mucho,
>el único método factible es el LZ77. Si usas Huffman o Shanon Fano
>para aumentar el ratio, ralentizarás bastante el tiempo de
>descompresión, y no te compensará en tiempo global. Yo uso una
>variante LZ77 muy buena con ratios ZIP equivalentes y tiempo de
>descompresión rapidísimo. Lo malo es que está en ensamblador: es el
>tc.asm que está en codigofuente.zip.

Más que por tiempo de carga la compresión merecería la pena para tener wavs
o
mp3 más pequeños.

------ (1) ------ (2) ------
| .sna |=> | .tap |=> | .wav |
------ ------ ------

(1) sería el compresor que genera un fichero .tap (con su pequeño cargador
y su bloque de bytes autodescomprimibles)
(2) sería k7xz

Pero se pierde el encanto de ver como se carga no instantaneamente la
pantalla
de carga. 8-)