Wow, the sample quality is really chrystal clear. Very impressive ! Can't wait to do some more testing.

The "crystal clear" quality can vary a lot depending on the .wav you consider.

Here follow some open iusses :

1) better lossless encoding:
Is it possible to improve the RLE using the statistically avalable cpu time ?
Look at the "best compression algorithm" forum http://www.msx.org/forumtopic5672.html

2) trade off between quality and size:
I am experimennting a solution that works fine, but what it the "optimal" implementation ?

3) samplig frequency:
Actually the PCM decoder can work up to 24kHz using 4bit per sample
(the trik is x=y and dt1=dt2=dt3=1/3 => Fs=3*8kHz); the problem is that the quality
drops drammatically (SNR below 20dB).
Is it possible to find some optimal strategy for rising the samplig frequency without
loosing SNR (Fs = 11025Hz or Fs 22059) ?


About the mod player, AFAIK the problem is that I cannot mix the samples, while the MOD
player whould ask for multiple sampes played at the same time.

Only sample by sample solutions can work, but the quality is "standard", i.e. no guarranttes
on PSG spikes during sample transitions.

This sounds very interesting, please send me a copy.

I've been playing with the encoder and player and done some tests on my MSXes and the result is really good.

I sampled my Philips vg8020 playing a little tune: http://www.bluemsx.com/vg8020psg.mp3

What do you think, not too bad huh? ARTRAG has done an excellent job doing an encoder that works this well.

off: nice version of ca plane pour moi ^_^

gargamel
something is online but in order to realease the pcmecc in C++ we need some testing

I must say it sounds really nice!
On the other hand.. Why a French song???

BTW,

Does anybody know how the samples were done in Valkyr. In my memory, these were also quite clear...

wow, just checked. really awesome! very good job man.

Quote:

On the other hand.. Why a French song???

Vive la France !

The first issue is the RLE encoder, go to
http://www.msx.org/forumtopicl5672.html

(for now)

Hi All,

We finally have a first release ready of the encoder and replayer. The release package contains an encoder application (with source) and replayers for playing 8kHz, 11.025kHz, 22.05kHz and 44.1kHz chrystal clear samples on your PSG. You can find the release package at:

http://www.bluemsx.com/psgenc/pcmenc_v001.zip

If you're too lazy to make your own samples you can take a listen to one of our 44.1kHz test samples (played on my Philips VG-8020): http://www.bluemsx.com/psgenc/royksopp.mp3

SODEJU! Sounds good!

Just a last release note about the Viterbi metric.
While using the encoder with 1 PSG transition per input
sample (i.e. typically at 44kHz) the MSE metric (i.e. L2)
could lead to some "static noise".
Viterbi optimisation, while maximizing the SNR, can admit
occasionally large sparse errors.
Those large sparse errors can be heard as annoying "static noise".
In those cases you can try L3 or L4 or higher order metrics.
Those metrics lead to a lower SNR but reduce the occurrence
of large errors, so the "static noise" problem is reduced.

When using the encoder with 3 or 2 PSG transition per input
sample the "static noise" problem is less important, as the
optimisation has more degrees of freedom in the choice of
the PSG levels, so L2 metric (that maximize the SNR) is typically
the best choice.

Note that the encoder program doesn't "just" compile on my LInux box;

st.h:25: error: 'uint32_t' does not name a type

for example. A bit strange, in st.h the types are defined only for non-GNU compilers??

If I reverse that ifdef, it compiles fine.

Using my cygwin the gcc compiler accept it without problems
In any case if you compile with the noresample #define, st.h is
skipped.
In this case you need to do by yourself the input processing
in order to have the sample frequency you need.