#1543 not sure it's a bug but ...

[Zibri]

If I enable the tape audio in settings and press play on tape, even with 0 wobbling and perfect alignment, the sound is "rough" and sort of "scratchy".

If I use this program instead, the sound is very clean.
https://github.com/Zibri/C64/blob/master/t2snd2.prg

Any idea, why?

[gpz]

you expect the tape sound to sound the same as whatever this program produces? why?

[Zibri]

because I tested that and the sound my program produces can be sampled and reconverted to tap very easily.
I even tried recording audio ouput with vice (and my program) and the converting the recorded audio WAV back to TAP and it works.
Instead the vice audio if I press play on tape sounds very weird. Like noisy (even with wobbling to zero and perfect alignment)
I was expecting them to sound the same since my program was proived to be working also on real hardware.

[gpz]

For reference, this is what it does. I'd be very surprised if this produces audio that matches what comes out when playing the tape as audio for that matter.

.C:0886  A0 1C       LDY #$1C
.C:0888  20 2F F1    JSR $F12F
.C:088b  A5 C5       LDA $C5
.C:088d  C9 3F       CMP #$3F
.C:088f  F0 5D       BEQ $08EE
.C:0891  A9 10       LDA #$10
.C:0893  24 01       BIT $01
.C:0895  D0 F4       BNE $088B
.C:0897  78          SEI
.C:0898  A2 00       LDX #$00
.C:089a  8D 00 DC    STA $DC00
.C:089d  A9 0B       LDA #$0B
.C:089f  8D 11 D0    STA $D011
.C:08a2  A5 01       LDA $01
.C:08a4  29 DF       AND #$DF
.C:08a6  85 01       STA $01
.C:08a8  AE 20 D0    LDX $D020
.C:08ab  86 63       STX $63
.C:08ad  A9 10       LDA #$10
.C:08af  E6 61       INC $61
.C:08b1  D0 04       BNE $08B7
.C:08b3  E6 62       INC $62
.C:08b5  F0 2C       BEQ $08E3
.C:08b7  2C 0D DC    BIT $DC0D
.C:08ba  F0 F3       BEQ $08AF
.C:08bc  EE 20 D0    INC $D020
.C:08bf  CE 18 D4    DEC $D418
.C:08c2  CE 18 D4    DEC $D418
.C:08c5  CE 18 D4    DEC $D418
.C:08c8  EE 18 D4    INC $D418
.C:08cb  EE 18 D4    INC $D418
.C:08ce  EE 18 D4    INC $D418
.C:08d1  2C 0D DC    BIT $DC0D
.C:08d4  D0 E9       BNE $08BF
.C:08d6  A2 00       LDX #$00
.C:08d8  86 61       STX $61
.C:08da  86 62       STX $62
.C:08dc  AC 01 DC    LDY $DC01
.C:08df  C0 7F       CPY #$7F
.C:08e1  D0 CC       BNE $08AF
.C:08e3  A6 63       LDX $63
.C:08e5  8E 20 D0    STX $D020
.C:08e8  A9 1B       LDA #$1B
.C:08ea  8D 11 D0    STA $D011
.C:08ed  58          CLI
.C:08ee  A9 00       LDA #$00
.C:08f0  85 91       STA $91
.C:08f2  A5 01       LDA $01
.C:08f4  09 20       ORA #$20
.C:08f6  85 01       STA $01
.C:08f8  4C 3B A9    JMP $A93B

[Zibri]

as usual, "dear" gpz, you never get the point. The point IS my program, as usual, WORKS.
if you run t2snd3.prg (there is a new version on github) and then use wav2tap.py you get back a fully working TAP out of the recorded audio.
Add to that that if you put a C64 tape in a tape player and you listen to it, it sounds much more like my program than the vice output.
Anyway there will soon be a t2snd4 which will produce an even cleaner audio because this version won't work on every sid chip.

[compyx]

I'm confused. Triggering the SID's pops when poking $d418 is somehow supposed to sound like playing a tape in a cassette player? And it's VICE that's incorrect, not the program abusing the SID?

[Zibri]

@compyx triggering $D418 and causing a POP is how you do digitized sounds on SID.
But I don't need full digitized "music" I just need to create a square wave in sync with the tape.
What my new t2snd4.prg does is exactly that and it's "the same" (very close) you get when converting a TAP to wav, for example using this other program I just wrote:
https://github.com/Zibri/C64/blob/master/tap2wav.py

If you are curious about D418:
http://sid.kubarth.com/articles/the_c64_digi.txt

and:
https://www.youtube.com/watch?v=UYAf_awh5XA

whish is well explained here:
http://brokenbytes.blogspot.com/2018/03/a-48khz-digital-music-player-for.html

[Fabrizio Gennari]

The samples have to be produced at every frame, meaning every 1/50th of a second at normal speed. An integer number of samples is needed at each frame.

sound_chip_t's calculate_samples gets passed both the amount of clock cycles (delta_t_for_other_chips) and the amount of sound samples (temp) passed since the last frame. Possibly due to some rounding, while delta_t_for_other_chips tends to be constant, temp can fluctuate by ±1. Because of this, the length of a wave in samples can be off by one compared with the previous, even if the two waves were identical on the tape.

I don't see an easy solution. Computing the number of samples in advance might be tempting, but the audio sample rate can be changed at any time, and changing that would mean invalidating the pre-computed samples. So I'd rather keep the "unclean" sound" for the moment.

[Zibri]

Finally someone talking right and not the usual gpz babbling.
How refreshing :D

Yep. I understood the problem. I don't know exactly how to solve it on VICE, and I totally understood your point. Hmm.. hope someone comes up with a solution because it's really strange how different the "listen to tape audio" sounds compared to listening to a real tape where a program is recorded. That's why I pointed this out.

No problem if keeping it this way is a volountary solution then it's ok... I though that maybe a small change would have improved it.

No problema dn keep up the good work.

Regards, Fabrizio.
Piergiorgio :D

[gpz]

it has nothing to do with rounding or 1 cycle missing, what happens is the following:

• the tape originally contains a non rectangle (more like sinus-ish) signal. this is what you hear when playing it in an audio deck
• when converting to a tap, only the rising (not falling) edges will be detected and the timing between them written to the tap. at this point all information about the shape of the original waveform is lost
• when playing it back with that datasette-sound feature, the signal will be played as a rectangle waveform, which is what produces this "harsher" sound

If you really want to make it sound more "real", then some kind of reconstruction filter is needed. The simpliest one i can think of would be a lowpass filter - see the attached screenshot (which also shows what the above program produces.... not quite what the original waveform was either) Note that even if such filter is applied, the Signal will never sound exactly like the original, since one half of the Signal is basically missing - and the .tap also contains no info at all about the Signal Amplitude, which tends to vary quite a bit on original tapes as well.

(another small bug is that the datasette sounds produces low frequency farting sound when the .tap has long pauses with a bit of noise in them - lowpass might fix this too)

[dqh]

btw - the audio system runs more often than that now, every 2ms or so.

[gpz]

+/- 1 cycle is less than what you get from other involved factors, it shouldnt matter at all :) it's also not what makes the difference between running the above program and playing the tape as audio - even if you change the computation into a "cycle exact" sound engine, it would sound pretty much exactly the same.

that said, unless we add a feature to use .wav files for tape (which will not happen), the sound generated from .tap files will never be matching what you'd actually get from playing the tape as audio - since .tap files only contain the rising edges of the original waveform (and the above mentioned program has the exact same issue, of course - except it will sound wrong even IF we'd have .wav as input, as the CIA pin only ever "sees" the rising edges)

[gpz]

if you run t2snd3.prg (there is a new version on github) and then use wav2tap.py you get back a fully working TAP out of the recorded audio.

that however proves nothing. the c64 ever only "sees" one edge of the signal, and thats the only thing you need for the tap - so sure, you can use one to reconstruct the other.

[Zibri]

this is a better version which generates a square wave with 50% of duty cycle
https://github.com/Zibri/C64/raw/master/t2snd4.prg

[Fabrizio Gennari]

+/- 1 cycle is less than what you get from other involved factors, it shouldnt matter at all

Unfortunately it's ±1 sample, not ±1 cycle, so more than 20x as much.

True, a real waveform on tape, a square waveform and a pulsing waveform sound different. But that's not what's at stake here. The problem here is that the lengths of the (square) waves can fluctuate by ±1 sample, and that's what makes the sound "unclean" (as opposed as just harsher due to being square instead of sine, or approximately sine),

The datasette sound emulation is made to be kept in sync with the speed of the emulator and the sound engine, so it consumes a given number of cycles, and it matches that with whatever amount of samples ReSID thinks those clock cycles are worth. A typical call to resid_calculate_samples returns 63 clock cycles (that seems pretty steady) and a number of samples that can vary from1 to 4 (even though 3 is most frequent). Ideally, the same number of clock cycles should create the same number of samples, but, if ReSID thinks differently, changing the datasette sound emulation would make it out of sync with ReSID, and that would have much worse side effects.

I'll check what happens with FastSID.

[gpz]

The problem here is that the lengths of the (square) waves can fluctuate by ±1 sample, and that's what makes the sound "unclean"

I really doubt this is the "problem" you can hear - listen to the low pass filtered output, (i used 2500Hz Lowpass, perhaps there is room for improvement) its pretty much what you'd expect from playing the original wav. The error introduced by the problem you mention just adds a small bit of phase noise at a very low frequency (~50Hz), i'd be surprised if you can even hear the difference when you fix it.

[Zibri]

A totally new version of TAPE2SID if coming out...
Forget the previous ones.