azul3d-legacy/audio-wav

Add test to ensure decoded data is valid.

slimsag opened this issue · 2 comments

It was recently discovered that 24-bit PCM decoding didn't work because a variable wasn't assigned properly (it was zero). We should add a test that will check if the decoded audio samples are all zero, so we can at least catch this in the future if it arises again.

We should definitely update the test cases. If we add the expected audio samples for each test case this issue would have been caught. Always go for a white list rather than a black list when writing test cases; i.e. instead of checking if the audio samples are all zero, check if the audio samples are all their expected value. We could use a slice containing the expected audio samples for each test case.

To sum it up, use predefined expected values (i.e. the original decoded audio samples, verified manually to be correct) which are checked against the values we get while decoding. The Go standard library excels in this regard and can be used as a reference.

That sounds even better! We'll need to modify the testdata wav files so that we can explicitly verify them like you mention, though. I'm not too sure how we would generate them.

Perhaps once encoding is working we could generate random (math/rand) wav files of each type (PCM16, F32, etc) using the same seed, then compare it with that in the test.