Print

[Saga Musix]

Hmm, that particular page was created about three weeks ago, not too long ago actually. It's heavily inspired by this page, though, so you maybe had that in mind.

[Sto]

Yes, you're right, thanks. It's hard to check the tests, but at least I definetly pass the "infinite loop" test

// Edit: Around 40% passed, and 20% partly passed, seems like I've got some work to do...

[Saga Musix]

Yes, you're right, thanks. It's hard to check the tests, but at least I definetly pass the "infinite loop" test

Which parts in particular are hard to check? I want this test suite to be as easily usable as possible, so if you have any suggestions on how to improve some tests, please do tell.

I know some of the older test cases are not very good and the descriptions are probably even worse, but if I know which ones are difficult in particular I will focus on improving these.

[Sto]

Which parts in particular are hard to check?

The problem is simply that I cannot really debug my player, I am currently comparing the results of FT2 and the generated mp3's.with my ears, though I am already thinking about how to automate this (e.g. write as WAV and see how this differs to the original one). The main problem is that I never used FT2, and that some of the XMs are quite fast or have pretty random things within it so I can't tell if the result is OK or not.

I think it would be cool if some musician would sit down and combine all the corner cases into one cool track so that it's easier to tell when something sounds wrong

// Edit: OK, most of my post is completely stupid, I haven't read the text on the page and only downloaded the mods, so ... my fault, sorry.

[Saga Musix]

I think it would be cool if some musician would sit down and combine all the corner cases into one cool track so that it's easier to tell when something sounds wrong

That has been done before and believe me, it's the worst way to determine whether something is correct or not. First off,you have to sit through the whole damn thing to check whether everything plays correctly. And secondly, you can not exploit every bug in a way so that it is extremely obvious that it is played back correctly.

I think playing back the (suppsedly) same stuff on the left and right channel is a far better way (in all cases it should be really obvious if your player does something wrong), and if the test is too fast, you can always render it to WAV and play it at half the frequency or something. And yes, the description texts are important to get an idea what the test is all about and what it should sound like.

[Sto]

I'm sorry for the not so good things I wrote, I was pretty tired, and an average room temparature of 27 degrees celcius due to the summer were the reasons for that. But back to topic: I wrote a small python script to automatically compare two WAVs, so that the testing could maybe automated (I recently added WAV export for that): http://earvillage.square7.ch/downloads/wav_compare.py - maybe you could use it for openMPT as well.

[Saga Musix]

That sounds very interesting, I'll have a look at it. I previously had the same idea to automate test case verification, the only drawback is probably that it relies on the render settings (interpolation and the like) to be exactly the same every time you run the test.

[Sto]

Well, I discovered a major issue... my player's output is 2 times louder than the ft2 output, but the tool shows only a difference of 0.4%. Additionally, it is pretty slow (nearly realtime ). I think I will write a small cpp to gain more speed and to be able to add some additional parameters like multiplying the samples from one .wav with a factor or the tuning of the comparison method (like "ignore length diff" or switch between mean difference and root mean square).

[Saga Musix]

Well, I discovered a major issue... my player's output is 2 times louder than the ft2 output

You could of course normalize both outputs.

[Sto]

You could of course normalize both outputs.

... which would definetly fail if there are some peaks in the output. The worst case would be a module where i.e. one envelope is calculated wrong so that one note gets played very loud - which is clearly wrong, but only one factor out of many, and here normalization would create a false positive as the difference between the waves would then increase. In my opinion that's a no-go, but I'm open for ideas.