ArduiTape

who got 11khz to load? who got the 9600hz wav I posted not to load? I get 9600hz loaded all day over naked door bell wire.
WHERE does the 11khz figure come from? from soundblaster stoneage decades ago! it has nothing to do with the MSX.

take an audio app and look at the curves of the 9600hz wav I posted. It is like a PPI pin timing diagram.
at 2400 baud the PPI pin wiggles 9600 times per second. The PPI signal is 9600 DAC-rate-Hz.
Because tone-hz is 1/2 dac-rate-hz, in the analog corner you may find specs of 4800hz.

Then look at the 11khz wav of caslink2.
Look at the short slopes. One of their arms is halve as long as the other, bad timing. The rule "bigger hz is always better" doesnt work!
And that pattern doesnt look like a usual resampler, but a hand crafted pattern to fit in 11khz.
again, why was something hacked into 11khz, the reason was a soundblaster bias, not the MSX.

Now, to get this loaded you probably need some strong filter. And then because of that you need an amplifier.
I think that is the story of casette cables with special circuits. First create a false timing wav and then fix it with analog vooodo.
And then the whole thing has the tendency "it only ever loaded on the authors cable / on his particular MSX model".

Long after soundblaster DOS days, a wav encoder goes this way:
shannon nyquist say that if you resample, the minimum hz must be twice as big: 9600*2 = 19200hz.
however, the 9600hz wav is NO RESAMPLING. It is a 1:1 copy.
19200 vs 9600, what to pick... well you pick 9600.

note that 9600hz is not a magic number, but "hz = 4*baud" is the relevant formula. the values I told are about 2400 baud.
to make e.g. 3000 baud, do not resample, but just write 12000Hz into the header. 3000 baud * 4 -> 12000hz.
but the wav does not get bigger. no matter what, there is always one ppi state stored in 1 wav byte.
Ironicaly that elegant smallest wav also is the simplest code, no resampler, plain copy.

And then comes the second resampling step in the audio-replay device. That is the part that is actualy different to soundblaster stoneage.
There exists no 9600hz DAC. With resampling, minimum DAC rate is 19200Hz.
In 2014 audio devices realtime-resample to high-khz DAC hands down.
The audacity displays "9600Hz", I press start and the thing works.

if some stamp mark sized consumer device does make troubles, the wav tool keeps a standard resampler code around.
the user can enter a hz number. warn him that below 19200Hz is danger zone.
so then the wavs are bigger and on that cheap device you can store less stuff,
but while the whole thing still is about a casette cable that is a plain wire and a method to work with any MSX model.
because it has no odd timing that would ask messing with analog circuits.

@giangiacomo.zaffini
practice case, fix caslink2, my recommendations are:
simple code to create 9600hz wav. more precisely the "hz = 4*baud" wav. low hz wav is best coded in plain integer to be sure.
"rework to floating point", but not on the basis of 11khz. just a standard resampler code. to be used to create wavs above 19200hz.

also caslink2 has a replay feature. maybe that works with an old soundblaster API. but soundblaster did have 22khz. or maybe 44khz. pick the highest possible DAC rate.
and then again use the said resampler code to do the replay.
and then an ages old pentium hands down realtime-resamples to that high-khz DAC. who knows, maybe a 486 can do it.

lack of resampling code in the audio-replay is what made the 11khz story. is what put the 11khz bias in there.

@Buleste,
similar, "14400 loads better than 9600", to me it smells like a bug in the experiment.
for example the wav generator made hiccups on 9600hz. a resampler generated 1.001 wav samples per ppi state. While exactly 1 is needed.
the same resampler code may have worked perfect all day in a 44khz app, because there that kind of inaccuracy plays no role.

what is the rate of the replay DAC?
to cover high speed apps like e.g. 3000baud, that is 12000hz wav, that needs at least 24000hz DAC rate in the player.
a replayer should use 44khz if possible.
if the little cpu on the board cant do that speed, a more primitive resampling is better than linear interpolation resampling that drops below the 2*hz requirement.

@ hit9918: I'll do 9600Hz WAV sampling rate and I'll share code for sure!

I just tried cas2wav of a castools-1.3 folder.
It makes nice sinuses at 43200hz.
At 9600hz exists no sinus. Hacking a code into a completely different world, random things can happen.
Like a crack every 1000 bits.

Again getting into some detail
The cas2wav slopes look like a 0-bit is high high low low.
I thought it should be low low high high. That sheme I copied from openmsx casette emu, this way I sneaked past a dozen places where the polarization question pops up

I wonder why it still loads.
Only thing I can imagine is that the bios counts just flips to the other side and polarization does not count.
But just speculating.

One thing I no more like in my code is how in the end it makes smaller sample values.
They are about "prevent hanging load at the end".
I used it to see it in the curve, but full volume feels better.
For players who swallow the last bit of the file, it should maybe be a second long.

maybe you can find a way to mod it so it goes integer style.
the place where is generated a 0-bit and a 1-bit.
each bit makes 4 bytes in the wav.
I suggest looking at the curves in audio app. things repeat within exactly 4 samples.
the 0 is a long slope, the 1 is two short ones.