Vale, me cosco del problema. Sin embargo como tengas un número excesivo de unos o ceros seguidos, el factor de compresión va a verse afectado. Vamos a ver si podemos dar con una solución interesante y rápida...

Si ves un cero te vas a una parte especial de tu programa que lee el siguiente byte y realiza tantos bucles de 256 vueltas como indique el byte. Después lee el siguiente y hace un bucle con ese valor de vueltas. Por último vuelve a la parte normal del programa. Para hacerlo de esta forma la palabra debería estar en big endian en lugar de low endian... Si el registro e lo tienes libre podías guardar ahí el contador del bucle externo que realiza bucles de 256 vueltas.

¿Se me entiende?

Incluso se puede mejorar. Supongamos que tienes una rutina llamada LOOP que hace un bucle de b vueltas y otra llamada CAMBIA que cambia el valor de uno a cero o viceversa. Lo que te propongo es crear una nueva rutina llamada BIGLOOP que hace b bucles de 256 vueltas y que se podría integrar como sigue:

PLAYER:
leo siguiente valor en b
si no es cero jp LOOP
BIGLOOP:
hago b bucles de 256 vueltas apoyándome en e
leo siguiente valor en b
si es cero jp CAMBIA
LOOP:
hago un bucle de b vueltas
CAMBIA:
cambio valor 1 <-> 0
jp PLAYER

  Como ves en ningún momento estás trabajando con valores de 16 bits... No se si será lo suficientemente rápido para tus propósitos, pero no parece demasiado lento.

Volviendo a la idea de usar 0s para indicar cambio de UNOs a CEROs, creo que sería lo más sencillo (aunque no lo óptimo, como ha demostrado Sapphire).

Dices que utilizas el 0 para indicar el fin de la secuencia. Podrías sustituir el fin de secuencia por un doble cero, con lo cual tendrías un formato consistente y sin problemas (db 0,0).

Recapitulando:

db 0,n ; indica cambio de 0 a 1 (o de 1 a 0, imagino que te da lo mismo) y N bits repetidos
db 0,0 ; indica fin-de-secuencia

No hay colisión en este caso, aunque es verdad que el byte extra de cambio de bit haría que aumentase bastante el tamaño de la tabla resultante. La otra opción es usar sencillamente words en el recuento. Con 16 bits de rango seguro que no te quedas corto.

EL caso es que esto me suena familiar, ya le pasó a Robsy algo parecido. ¿Has tenido en cuenta los tiempos reales de ejecución de las instrucciones del Z80 en el MSX?

Dioniso:

Asegúrate de tener en cuenta lo que te comenta JL respecto al ciclo de espera adicional para todas las instrucciones del Z80 puesto en el MSX. Hay 4 ciclos de reloj extra que se van a refresco de memoria por byte del opcode, sin incluir parámetros. Es decir, NOP, que debería tardar 4 t-states, en realidad tarda 4+4. De todos modos, imagino que sí lo habrás tenido en cuenta.

Si quieres que le eche un vistazo al replayer, pásame código por privado y le dedico unos minutillos.

Eso diría yo. Yo tomo NOP como 5 t-states. Supongo que habrá sido el campotraviesa.

Gracias Edu por el ofrecimiento. Lo tendré en cuenta.

Incluso un OUT (C),D tiene dos más, es decir, no tiene 12 sino 14.

Bueno, parece que me acerco bastante. He compactado aún más el replayer  De todas formas no suena todo lo fino que debería ... Edu, creo que te voy a enviar dos replayers; uno sin samples/notas compactadas (es practicamente tu replayer pero modificando sólo el 7° bit del puerto $AA) y otro muy compacto para utilizar con los programas que tú y jltursan me hicisteis. Así verás las diferencias. Supongo que esto te caerá el próximo lunes.

Los t-states están medidísimos. Hay 3 loops con una duración de 162, 163 y 164 t-states respectivamente ... la diferencia no puede ser tan grande, no me lo explico. Quizá haya un problema con la conversión de samples  Si quito un bit a cada sample suena mejor, creo. Bueno, a ver si le echas un ojo. Te lo comento para que me digas si podrás o no, y lo hago aquí por si alguien piensa en otra solución para al problema. Por que si hago el juego con el primer replayer me voy a tener que llevar un "Griel's Quest for the Sangraal Extended Edition" ...