designspec_critical.html

This chapter deals with a number of issues which for some reason require extra attention in order to make AudioJury work correctly.

For automatic pair comparison methods, there is an option to randomize the order in which sounds are played in within the sound pair. An algorithm for doing the randomization according to the standard is described here.

The sounds in a paired judgement are called A and B. Normally sound A is played before sound B. Each judgement has a flag that is set if the normal playback order is swapped.

If pairs are randomized according to section 7.2 care must be taken before writing the selected rating to the judgement object.

First of all, it is important to note that scales of paired test are balanced integer scales. This means that the range of the scale goes from -N to N, where N is a positive integer. Some scales do not contain zero ("0"), but that does not influence the discussion.

If the swap flag of a judgement is set then the mirrored value of the rating reported from the GUI should be stored. The mirror of a value N is -N.

It may occur that a result file will be encountered twice by the administrator program during result import. This may happen if results are imported both manually and by network. If a duplicate is encountered it is discarded.

The settings of a test, such as judgement order and method, are stored in a test object. Likewise, the settings of a project are stored in a project object.

In memory, the project object contains references to all its tests. However this structure must be split when saved on disk. The test objects should be saved in the respective test directory. This is in order to make it easy to copy and move tests between projects.

Each project object contains a number of test objects. Each test object contains a number of judgements. Each judgement contains one or two sound objects. Each sound object references an audio file. This reference is made of two parts: A path and a filename. Everything together obviously is a tree structure.

· When a sound file is added to a test, the path and filename in the sound object are set to point to that file.

· Just before the project object gets serialized to disk, the tree is traversed. If a reference to a sound file is found where the path is set, the following happens:

1. Any test directories that do not exist yet in the project directory are created. See section 6.5, "Project directory".

2. The original sound file is copied to the right test directory in the project directory tree.

4. The project object gets serialized. See section section 7.5, "Location of serialized objects".

The only purpose of the path part of the reference is to show that a file has not been copied to the project directory yet. From the moment that the file has been copied, the path part is set to null indicating that the file has already been copied into the directory structure.

A project or test directory may have changed name. When the corresponding project- or test object gets loaded from disk, the program must make sure it checks the directory name and then sets the object's internal name value to that name.

It is extremely important to point out that the design does not support use of multiple administration programs in the same test environment. If the administrator program is installed and used on more than one computer, the generated project results will be more or less randomly spread out between the administrator programs depending on when result collection is performed. See section 2.3, "Result collection" for details on result collection.