Frame writing discrepancy in 0.9.8

[JC-Morph]

Hi there,

I have observed some odd behaviour from MrsWatson regarding the number of frames/samples written.

I'm using: MrsWatson version 0.9.8, build 20150122 [32 bit] Windows 7 Ultimate x64 SP1

There seems to be a repeatable discrepancy in the number of frames that MrsWatson writes. The following was tested with 24 bit (signed) and 32 bit (float) audio in pcm and wav formats respectively. The mrs_passthru internal plugin was used.

Sample rate 48kHz:

duration	frames	discrepancy
1 sec	48128	+128 frames
2 sec	96256	+256 frames
3 sec	144384	+384 frames
4 sec	192512	+512 frames

This cycle repeats at least twice more if the length of audio is consistently increased by 48000 samples (1s) each time. Tested at 44.1kHz, the discrepancies looked like this:

dur.	discrepancy	-	dur.	discrepancy
1 s	+344		6 s	+104
2 s	+376		7 s	+36
3 s	+308		8 s	+480
4 s	+240		9 s	+412
5 s	+172		10 s	+344

Spectrograms show the added frames are at the end of the sample, and are predominantly noise:

or silence:

When tested with identical parameters & files, MrsWatson 0.9.7 does not display this behaviour. Similar results can however be achieved using the deprecated --tail-time parameter.

---

Potentially of note: Testing with a plugin that prompts this error:

INTERNAL ERROR: framesProcessed (3418368) != getAudioClock()->currentFrame (3418112)

(+decimate - http://www.kvraudio.com/product/and-decimate-vst-by-soundhack)

When processing wav this plugin wrote the same number of overflow frames as mrs_passthru. However, when using pcm - which bypasses the above error - Mrs.W wrote 78 LESS frames than it read.

Tested twice more on different audio samples, it wrote +118 frames and -30 frames respectively. When I tested using the incremental audio from the first example, it also followed the 4 second +=128 cycle at 48kHz, but with a range of -128 to 256 frames written.

---

I hope some of this information is useful to you. Unfortunately i'm more of a musician than a programmer at present, and so have likely gone way off the mark; I apologise if this is the case.

Thank you for your time and 9.8 is fantastic, the wav implementation is awesome. Mrs.W and other tools are facilitating changes to my creative practice in a revelatory way. Thanks again and please keep improving this unique utility!

JC

[nikreiman]

IIRC this error was fixed in master, which is as of yet unreleased. When I get around to making a 0.9.9 release we should re-examine this bug report to see if it's still valid.

[JC-Morph]

Hi Nik,

Thought I would report back on my findings after making my own build from master. I apologize in advance for any error on my part, as I am inexperienced with compiling source code.

To build MrsWatson with MSVC 14 I first had to make the changes I have outlined here: #222

The tests that I performed indicate that this bug still exists. Running mrswatsontest with --resources yielded 100% of tests passed (skipping 22 format/bitdepth audiofile tests).

I performed tests of my own using the released 0.9.8 build for comparison. I have attached a .zip which contains a folder for both builds.

JC-MrsWatson_Tests.zip

Each folder contains:

• A failed --error-report dump (running this command failed for both builds, but with different messages)
• A text file containing the output from the following command: mrswatson -i a440-16bit-stereo.wav -p mrs_passthru -o a440-test.wav --verbose

The resulting audio from both builds was identical, and 157 samples longer than the original. Here are spectrograms comparing the original (from AudioTestData) to the output:

I include this visual comparison because it seems to indicate dithering or some other process is increasing the gain of the audio. Another issue perhaps?

I hope that some of this proves useful, but please do ask if I can provide more pertinent information.

Kind regards, JC

---

sidenote: although using 64bit Windows and building the 32bit binary, both builds also report the following: D 00000000 000000 Host platform is Windows 32-bit (Windows 7) D 00000000 000000 Application is 64-bit

[nikreiman]

@JC-Morph thanks for the detailed investigation, I will try to spend some time this week and solve the issue once and for all. :)

[nikreiman]

Also regarding the bitness, it seems that these values are reversed. I've made a separate issue for that #224

[BasicPro]

Is there any news about this? I have the same issue when using some plugins, INTERNAL ERROR: framesProcessed (3418368) != getAudioClock()->currentFrame (3418112) Doesn't happen with some other plugins though.