I will be monitoring this thread closely in the coming weeks so please report any bugs you find in BlindAudio. I am already aware of a number of bugs in 0.1.0a (Mostly seek bugs), however post anything you find and i will try and address it in the next version. Thanks everyone.

Hey Sphoid/Dibrom,

Nice job with the program!

Number one problem in my view: the randomizing between A and B seems to work, but it didn't look like there was any randomizing of file order. This is needed before it can be used for a listening test.

File playback works, although the stop button is very slow to react. One future feature you may want to consider is fast switching between A and B.

I entered comments, which appeared in results.txt (written to the execution directory) after I hit the submit button. Some users might mistake the "submit" button for an "ok" button, and press it to go on to the next sample (thus writing and clearing their results). Maybe some sort of dialog box should pop up explaining what they are about to do? I can see training sessions are in order before the first organized test is conducted to explain where things go, and what the buttons do, etc.

I wrote comments like, "A has a blip," etc., when in reality the program only knows the files as "original" and "encoded." Is it worthwhile adding the "A" or "B" to the results file? It's not necessary, though.

ff123

Easy fix



Yeah this is an issue with Swing, i noticed that it sticks sometimes and i plan on looking into this.



It already does this




I thought this might be a good idea too, I just forgot to add it. Easy Fix



My plan is to eventually have it print out the commandline used for the encoded sample. That will be implemented with the client side encoding feature. I could also have it explicitly specify A and B however the order is consistent, the first is A the second is B. I will go ahead and add this.

Thanks ff123

>> One future feature you may want to consider is fast switching
>> between A and B.

> It already does this

What I meant here was that if I'm playing A, and then I hit B, B would start playing, not from the beginning, but from the point where A stopped playing, perhaps with a user specified insertion of silence. The idea is to mimic a hardware AB box with a switch that the user can flip from A to B, where both A and B are simultaneously playing and are exactly synchronized. Of course, the application must be much faster than it is right now to be capable of such a feat. Some people apparently like to use ABX that way, for instance.

Personally, I like the switching the way it is now (with the starting point being the beginning of the file or the beginning of a specified section of the file). But faster would be better, of course.

ff123

This is actually the way the program originally worked, but we changed the default functionality to restart the file from the beginning when one of the other play buttons is activated. At any rate, we will make an option to allow either method to be used.

Okay, i tested it a bit (it's nice BTW), and here's what i noticed:

When loading the samples, there's no check if a specific encoded sample is already on that list. I accidentally loaded one file two times, and it showed up twice on the list. Which brings me to the next point: There's no option to remove a file from the list, and also, no way select multiple files (CTRL-click or SHIFT-click don't work in the load window).

Then, there should be a "next" button somewhere at "Select sample set", instead of manually moving the slider to the next notch.

Sometimes there's an annoying "Ding" sound (default system sound) before or during playback, which of course sophisticates the sound of the samples. I don't know if this came from setting the playback range, but it occured quite often after i did that.

The upper playback range sometimes adds audible clicks to the end of the samples, to the point where i feared that the loud sound could influence my perception of the next sample. This isn't necessarily the program's fault and maybe just a result of the "chopping", but it would be nice if there's a way to circumvent this, maybe with a very short fade-out. (yes i know that this would mess up the sample as well )

The "results.txt" file always gets overwritten, wouldn't it be better to add a consecutive number to the filename, or maybe include date and time?

That's all i noticed so far... again, well done.

This may actually be a feature, not a bug
It's not out of the question that some test administrator may wish to include the same file more than once.

But yes, a remove file option would be nice. Actually, the nicest feature would be to read a setup file so that the user doesn't have to do all the work of loading up the test files -- the test administrator would do that by creating the setup file.



I might try a short bit of silence before and after the sample before I tried a fade-out.

ff123

*nod*





Hm no... i was talking about the playback range, not the end of the actual sample. Try setting an upper limit for the playback range, and maybe you'll hear a click at the end. I was thinking about a 0.0x second fade-out, that only sets in when one defines an upper playback range, in order to suppress that click.

I think you should be able to add silence even if a selection within the sample is played.

ff123

Okay, but that doesn't solve the click problem. Example: Generate some sine wave in an audio editor and delete a bit from the end of it. When playing it fairly loud now, there's a click at the end. Adding silence doesn't change this... a fade-out does.

I actually typed up a nice response to this post yesterday but for some reason it seems to have not gone through... so here we go again



All of this will be addressed when the control panel is added to the program. The control panel will basically be a small floating pane that lets you control sample loading, test configuration, and most of the other relevant options all from a centralized area. The setup for loading samples right now is only a place holder, and functionality such as what you speak of is certainly planned for an upcoming version.



I agree with this also. This was a feature that was originally going to be included but which slipped through the cracks before release. Should be in the next version for sure.



Yeah.. I noticed this too shortly after release. I'm not quite sure what is causing it yet, but Sphoid and I are looking into it. The playback range controls, the seeking, and the position slider, are all pretty buggy right now and are due for a major overhaul.



We'll look into this. I've read the rest of the responses below also... Sphoid and I will experiment with some different methods and see what we can do.



Yes. The results system is also only a placeholder. In the coming versions we are planning to significantly modify its capabilities along with the encryption and server side stuff. At this point, it's likely that an entirely different system will be used even for personal testing, though we haven't quite decided what yet.



Thanks