Wav (Mem) to Float array issue.

[Spogg]

Please, please tell me I’m stupid for asking such a basic question…

My current project makes heavy use of Wav (Mem) to Float Array prims and Float Array processing. I’ve noticed before that indexing wav readers sound a bit noisy at the bass end, but for this project I needed to sort this. I’ve spent days on this and think I’ve finally tracked the issue down.

In my Wavemaker 4 I created wavs with low harmonic content and all partials at zero phase shifts.
I saved the Wav and it’s perfect when examined in a sound editor like Sound Forge.
But when I load that same wav there is a step at the end of the Array, because the final sample (indexed at 255 from a 256 sample wav) the value is not zero as it should be, and as is shown in the sound editor. I checked several other sample numbers and they seem to tally ok.

I tried copying and pasting several cycles in series in the editor, and there is no visible step or discontinuity of any sort between iterations, so I have to assume the WAV itself is ok. But the step shows up in FS on a scope and is clearly audible, more so at lower bass frequencies.

Now I don’t get the noise/step if I use the wave table prims because the tables created obviously eliminate such a single sample “high frequency” step (above nyquist). But I can’t use these with my system for 2 reasons:

1) The whole point of my synth is to explore phase-scrambling (and it sounds good!) so I need to go via a wav-to-array and iFFT etc. system. But the wav-to-array produces this crap.
2) With 9 oscillators the wave table creation takes an eternity (each table has a different unique float array). I tried it and it’s totally unacceptable.

I’ve attached a test case schematic (3.06) and there is the wav file in the zip. The issue is present on all wavs but shows up well on this one.

I tested this in the latest FS4 alpha and it’s the same.

I do hope this isn’t a bug and that someone can give me a damn good thrashing for being so dumb.
If it’s a bug then my project is Boris-like: dead in a ditch.

Cheers

Spogg

[trogluddite]

Why do you expect the last sample to be zero?

If scanning the samples in a loop to make a waveform, you would then have both the first and the last sample being zero, so you'd end up with a "flat spot" with two consecutive zero samples either side of the crossover. Or conversely, joining your "wrong" sample nose-to-tail in the audio editor doesn't glitch because there will be only the expected single zero at the join. Having said that, padding with a repeat of the first sample at the end can sometimes be a handy way to optimise interpolation at a point fractionally greater than the last sample index. I'm not saying that you're wrong, just trying to work out why you need the "extra" zero, as your file is exactly what I'd expect for a single-cycle waveform - the first sample of the next cycle will be zero.

[martinvicanek]

Agree with Trog, you should not expect a zero at both ends.

If you use some sort of interpolation, linear or whatever, be sure to correctly wrap around at the end. The wave read prim, for instance, will return the last array element if you try to read the n+1st, not wrap around. This might cause the buzz sound you are getting.

[Spogg]

Thank you both!

After posting I looked at this again, and in Sound Forge it shows both the first and last sample at zero. However, in Wavosaur the graph produced agrees with the Float array. In both editors, if I concatenate two or more cycles, there is no discontinuity between the cycles’ end and the first sample of the following one.
So I must conclude that Sound Forge is lying to me with its single cycle display, but I don’t see why or how. That led to my confusion.

In Sound Forge the final sample is marked as 256 and the first as 0 so the sample numbering is zero-based, but it’s showing the final sample as a repeat of the first sample, because the final sample should be index 255 and not 256. If I ignore “sample number 256” the real final value is correct.

At around 4am I woke up with the thought that it may be an interpolation issue, that the wrap-around was causing problems, as Martin suggested.

So I have some work to do and I’ll post back if I can sort this, or maybe scream out for more help.

Cheers

Spogg

[HughBanton]

Hi Spogg,

I had a similar issue a year or so back (maybe it was 2yrs ..!), and Martin kindly pointed me in the right direction.
I too was getting a wrap-around error.

Just to run through a good interpolation method, for the benefit of all (you'll already be aware of this stuff) :

If you have a 256-point waveform, and you're playing it back at different pitch rates, your waveform counter will inevitably be counting in a fractional step size. Let's pick err .. 60.2? So it will want to play sample 0, 60.2, 120.4, 180.6, 240.8 and then 301 .. which wrapping around is sample 45, then 105.2, 165.4 and so on.

'60.2' is 0.2 of the way between sample 60 and sample 61! To get the interpolated value we use the value of sample 60, and then add 0.2 * sample 61-sample 60, aka the 'difference' or 'slope'.

Rather than calculating the 'slopes' on the fly (bad idea) it's best to calculate them in advance, and then store two tables - Values & Slopes, which can be accessed in paralel, either using 2 float-array reads or better still a stereo-Mem read, where in this instance the 2 channels are used for Value & Slope. Then you just need a multiply and an add.

NOW finally .. the wrap-around issue! Slope no. 1 is sample 2-sample 1; Slope no. 2 is sample 3-sample2 etc. etc. But the very final Slope, no. 256, is sample 1 - sample 256. Then it all works a dream

I can supply lots of diagrams and code for this stuff, but it will depend on your application so probably won't be right. Let me know if you need anything.

H

[Spogg]

Hugh that sounds fascinating but unfortunately I don’t fully get it. I can see how you would use a loop to create the two tables according to your formula of sample value difference, but I don’t understand the “add and multiply” bit, and how a fractional counter would supply the appropriate index values to the readers. If you or someone could share a working reader which took a 256 float array, and played correctly, I could study it in greater depth. That would be most appreciated, but no rush.

In the meantime I’ve confirmed that my problem is related to interpolation when the precision counter wraps around, as expected. I tried all of Exo’s interpolators but the problem wasn’t fixed because it’s the principle that causes the issue. The final-to-first sample transition causes the interpolation error, irrespective of the interpolation method.

So I found a dirty cheat, a work-around. I used a Resample prim to increase the array size to 2048, and set it for linear interpolation. This means the wrap-around step now represents 0.125 of its former value. If I make a scope huge I can still spot the step but only just, and the effect is completely inaudible on every waveform I tried. Fortunately, VERY fortunately, there is no noticeable increase to the processing time when selecting a new array.

So, for now, I’m very happy.
However, I think a more elegant solution would be nicer, just as long as I can change WAVs with no appreciable extra delay. I have to process 9 of these buggers!

Cheers

Spogg

[HughBanton]

Interpolated Wave Reader.fsm

(1.52 KiB) Downloaded 812 times

This is the link that Martin sent me Nov '17 (!)

It was during my post entitled "just one thing bothering me .. ", the topic goes on to cover quite a bit of this subject.

H

[Spogg]

Thanks Hugh

I have to confess I already had that!

Here is the FlowStone 3.08.1 version from Martin if anyone needs it:

viewtopic.php?f=2&t=9408&hilit=just+one+thing+bothering+me#p36373

I tested this and it works fine in terms of wrap-around. Now follows the big BUT…

Whilst it reduces my CPU for the synth by around 1% (from 10.9 to 9.7) which is good, it also takes much longer to process a change of array. So paging through wav files currently takes about 1 second before all 9 oscillators are updated, but with Martin’s clever module it takes about 4 seconds, which I think is unacceptable if you are searching for a particular timbre. For someone with a less powerful PC it could be a very frustrating experience.
If it was only about a delay when changing presets I think it would be acceptable, but my synth features a wav browser so you can easily try out any single cycle wav file you may have.
My opinion is that the extra delay is due to creating an additional shifted array and having to write to memory, but I’m sure Martin could explain it better.

So, at present, my decision is to stay with my inelegant version because it updates faster and now sounds good enough I reckon.

Many thanks to all

Spogg

[martinvicanek]

Hm, hadn't tought that loading times could be an issue. Actually I don't even know how to measure it, I get zero even for large files.

Anyway, I have blocked some unnecessary triggers in the 2017 module so it may load twice as fast now. I also came up with an alternative method which may load even faster. @Mr. Spogg, please try and tell us.

[HughBanton]

On your new version I'm getting errors because you have streamouts and floats both called by the same names: i & j.

I'll probably figure out what you intended if I stare at it for a while ... but you'll do it quicker!

H