annotate docs/Instructions/Instructions.tex @ 2202:61c8e13f1e2e

Merge branch 'master' of https://github.com/BrechtDeMan/WebAudioEvaluationTool
author www-data <www-data@sucuk.dcs.qmul.ac.uk>
date Fri, 08 Apr 2016 13:20:54 +0100
parents 41577a11f12e
children b332dcc65b8c
rev   line source
b@1402 1 \documentclass[11pt, oneside]{article} % use "amsart" instead of "article" for AMSLaTeX format
b@1402 2 \usepackage{geometry} % See geometry.pdf to learn the layout options. There are lots.
b@1402 3 \geometry{letterpaper} % ... or a4paper or a5paper or ...
b@1402 4 %\geometry{landscape} % Activate for rotated page geometry
b@1402 5 \usepackage[parfill]{parskip} % Activate to begin paragraphs with an empty line rather than an indent
b@1402 6 \usepackage{graphicx} % Use pdf, png, jpg, or eps§ with pdflatex; use eps in DVI mode
b@1402 7 % TeX will automatically convert eps --> pdf in pdflatex
b@1402 8
b@1402 9 \usepackage{listings} % Source code
b@1435 10 \usepackage{xcolor} % colour (source code for instance)
b@1435 11 \definecolor{grey}{rgb}{0.1,0.1,0.1}
b@1435 12 \definecolor{darkblue}{rgb}{0.0,0.0,0.6}
b@1435 13 \definecolor{cyan}{rgb}{0.0,0.6,0.6}
b@1435 14
b@1402 15 \usepackage{amssymb}
b@1402 16 \usepackage{cite}
b@1402 17 \usepackage{hyperref} % Hyperlinks
b@1402 18 \usepackage[nottoc,numbib]{tocbibind} % 'References' in TOC
b@1402 19
b@1402 20 \graphicspath{{img/}} % Relative path where the images are stored.
b@1402 21
b@1402 22 \title{Instructions for \\ Web Audio Evaluation Tool}
b@1402 23 \author{Nicholas Jillings, Brecht De Man and David Moffat}
b@1402 24 \date{7 December 2015} % Activate to display a given date or no date
b@1402 25
b@1402 26 \begin{document}
b@1402 27 \maketitle
b@1402 28
b@1435 29 These instructions are about use of the Web Audio Evaluation Tool on Windows and Mac OS X platforms.
b@1435 30
b@1435 31 We request that you acknowledge the authors and cite our work when using it \cite{waet}, see also CITING.txt.
b@1435 32
b@2201 33 The tool is available in its entirety including source code on \url{https://github.com/BrechtDeMan/WebAudioEvaluationTool}, under the GNU General Public License v3.0 (\url{http://choosealicense.com/licenses/gpl-3.0/}), see also LICENSE.txt.
b@2201 34
b@2201 35 The SoundSoftware project page, including a Mercurial repository, is \url{https://code.soundsoftware.ac.uk/projects/webaudioevaluationtool/}.
b@1435 36
b@1390 37 % TO DO: Linux (Android, iOS)
b@1402 38
b@1402 39 \tableofcontents
b@1402 40
b@1402 41 \clearpage
b@1402 42
b@1402 43 \section{Installation}
b@1435 44 Download the folder (\url{https://code.soundsoftware.ac.uk/hg/webaudioevaluationtool/archive/tip.zip}) and unzip in a location of your choice, or pull the source code from \url{https://code.soundsoftware.ac.uk/hg/webaudioevaluationtool} (Mercurial).
b@1402 45
b@1402 46 \subsection{Contents}
b@1402 47 The folder should contain the following elements: \\
b@1402 48
b@1402 49 \textbf{Main folder:}
b@1402 50 \begin{itemize}
b@1402 51 \item \texttt{analyse.html}: analysis and diagnostics of a set of result XML files
nickjillings@1363 52 \item \texttt{core.css, graphics.css, structure.css}: core style files (edit to change appearance)
b@1435 53 \item \texttt{CITING.txt, LICENSE.txt, README.txt}: text files with, respectively, the citation which we ask to include in any work where this tool or any portion thereof is used, modified or otherwise; the license under which the software is shared; and a general readme file referring to these instructions.
b@1402 54 \item \texttt{core.js}: JavaScript file with core functionality
b@1402 55 \item \texttt{index.html}: webpage where interface should appear (includes link to test configuration XML)
b@1402 56 \item \texttt{jquery-2.1.4.js}: jQuery JavaScript Library
b@1435 57 \item \texttt{loudness.js}: Allows for automatic calculation of loudness of Web Audio API Buffer objects, return gain values to correct for a target loudness or match loudness between multiple objects
b@1402 58 \item \texttt{pythonServer.py}: webserver for running tests locally
b@1402 59 \item \texttt{pythonServer-legacy.py}: webserver with limited functionality (no automatic storing of output XML files)
b@1402 60 \item \texttt{save.php}: PHP script to store result XML files to web server\\
b@1402 61 \end{itemize}
b@1402 62 \textbf{Documentation (./docs/)}
b@1402 63 \begin{itemize}
b@1435 64 \item \href{http://c4dm.eecs.qmul.ac.uk/dmrn/events/dmrnp10/#posters}{DMRN+10}: PDF and \LaTeX source of poster for 10\textsuperscript{th} Digital Music Research Network One-Day workshop (``soft launch'')
b@1402 65 \item Instructions: PDF and \LaTeX source of these instructions
b@1402 66 \item Project Specification Document (\LaTeX/PDF)
b@1402 67 \item Results Specification Document (\LaTeX/PDF)
b@1435 68 \item SMC15: PDF and \LaTeX source of 12th Sound and Music Computing Conference paper \cite{waet}
b@1435 69 \item WAC2016: PDF and \LaTeX source of 2nd Web Audio Conference paper\\
b@1402 70 \end{itemize}
b@1402 71 \textbf{Example project (./example\_eval/)}
b@1402 72 \begin{itemize}
b@1402 73 \item An example of what the set up XML should look like, with example audio files 0.wav-10.wav which are short recordings at 44.1kHz, 16bit of a woman saying the corresponding number (useful for testing randomisation and general familiarisation with the interface).\\
b@1402 74 \end{itemize}
nickjillings@1363 75 \textbf{Interface files (./interfaces/}
nickjillings@1363 76 \begin{itemize}
nickjillings@1363 77 \item Each interface class has a JavaScript file and an optional CSS style file. These are loaded as needed.
nickjillings@1363 78 \end{itemize}
nickjillings@1363 79
b@1402 80 \textbf{Output files (./saves/)}
b@1402 81 \begin{itemize}
b@1402 82 \item The output XML files of tests will be stored here by default by the \texttt{pythonServer.py} script.\\
b@1402 83 \end{itemize}
b@1402 84 \textbf{Auxiliary scripts (./scripts/)}
b@1402 85 \begin{itemize}
b@1402 86 \item Helpful Python scripts for extraction and visualisation of data.\\
b@1402 87 \end{itemize}
b@1402 88 \textbf{Test creation tool (./test\_create/)}
b@1402 89 \begin{itemize}
b@1402 90 \item Webpage for easily setting up your own test without having to delve into the XML.\\
b@1402 91 \end{itemize}
b@1402 92
b@1435 93 \subsection{Compatibility}
b@1402 94 As Microsoft Internet Explorer doesn't support the Web Audio API\footnote{\url{http://caniuse.com/\#feat=audio-api}}, you will need another browser like Google Chrome, Safari or Firefox (all three are tested and confirmed to work).
b@1435 95
b@1435 96 Firefox does not currently support other bit depths than 8 or 16 bit for PCM wave files. In the future, this will throw a warning message to tell the user that their content is being quantised automatically. %Nick? Right? To be removed if and when actually implemented
b@1402 97
b@1402 98 The tool is platform-independent and works in any browser that supports the Web Audio API. It does not require any specific, proprietary software. However, in case the tool is hosted locally (i.e. you are not hosting it on an actual webserver) you will need Python (2.7), which is a free programming language - see the next paragraph.
b@1402 99
b@1435 100 \clearpage
b@1402 101
b@1402 102
b@1402 103 \section{Test setup}
b@1402 104
b@1402 105 \subsection{Sample rate}
b@1402 106 Depending on how the experiment is set up, audio is resampled automatically (the Web Audio default) or the sample rate is enforced. In the latter case, you will need to make sure that the sample rate of the system is equal to the sample rate of these audio files. For this reason, all audio files in the experiment will have to have the same sample rate.
b@1402 107
b@1402 108 Always make sure that all other digital equipment in the playback chain (clock, audio interface, digital-to-analog converter, ...) is set to this same sample rate.
b@1402 109
b@1402 110 Note that upon changing the sampling rate, the browser will have to be restarted for the change to take effect.
b@1402 111
b@1402 112 \subsubsection{Mac OS X}
b@1402 113 To change the sample rate in Mac OS X, go to \textbf{Applications/Utilities/Audio MIDI Setup} or find this application with Spotlight (see Figure \ref{fig:audiomidisetup}). Then select the output of the audio interface you are using and change the `Format' to the appropriate number. Also make sure the bit depth and channel count are as desired.
b@1402 114 If you are using an external audio interface, you may have to go to the preference pane of that device to change the sample rate.
b@1402 115
b@1402 116 Also make sure left and right channel gains are equal, as some applications alter this without changing it back, leading to a predominantly louder left or right channel. See Figure \ref{fig:audiomidisetup} for an example where the channel gains are different.
b@1402 117
b@1402 118 \begin{figure}[tb]
b@1402 119 \centering
b@1402 120 \includegraphics[width=.65\textwidth]{img/audiomidisetup.png}
b@1402 121 \caption{The Audio MIDI Setup window in Mac OS X}
b@1402 122 \label{fig:audiomidisetup}
b@1402 123 \end{figure}
b@1402 124
b@1402 125 \subsubsection{Windows}
b@1402 126 To change the sample rate in Windows, right-click on the speaker icon in the lower-right corner of your desktop and choose `Playback devices'. Right-click the appropriate playback device and click `Properties'. Click the `Advanced' tab and verify or change the sample rate under `Default Format'. % NEEDS CONFIRMATION
b@1402 127 If you are using an external audio interface, you may have to go to the preference pane of that device to change the sample rate.
b@1402 128
b@1402 129 \subsection{Local test}
b@1402 130 If the test is hosted locally, you will need to run the local webserver provided with this tool.
b@1402 131
nickjillings@1446 132 \subsubsection{Mac OS X \& Linux}
b@1402 133
nickjillings@1446 134 On Mac OS X, Python comes preinstalled, as with most Unix/Linux distributions.
b@1402 135
b@1402 136 Open the Terminal (find it in \textbf{Applications/Terminal} or via Spotlight), and go to the folder you downloaded. To do this, type \texttt{cd [folder]}, where \texttt{[folder]} is the folder where to find the \texttt{pythonServer.py} script you downloaded. For instance, if the location is \texttt{/Users/John/Documents/test/}, then type
b@1402 137
b@1402 138 \texttt{cd /Users/John/Documents/test/}
b@1402 139
b@1402 140 Then hit enter and run the Python script by typing
b@1402 141
b@1402 142 \texttt{python pythonServer.py}
b@1402 143
b@1402 144 and hit enter again. See also Figure \ref{fig:terminal}.
b@1402 145
b@1402 146 \begin{figure}[htbp]
b@1402 147 \begin{center}
b@1402 148 \includegraphics[width=.75\textwidth]{pythonServer.png}
b@1402 149 \caption{Mac OS X: The Terminal window after going to the right folder (\texttt{cd [folder\_path]}) and running \texttt{pythonServer.py}.}
b@1402 150 \label{fig:terminal}
b@1402 151 \end{center}
b@1402 152 \end{figure}
b@1402 153
b@1402 154 Alternatively, you can simply type \texttt{python} (follwed by a space) and drag the file into the Terminal window from Finder. % DOESN'T WORK YET
b@1402 155
nickjillings@1446 156 You can leave this running throughout the different experiments (i.e. leave the Terminal open). Once running the terminal will report the current URL to type into your browser to initiate the test, usually this is http://localhost:8000/.
b@1402 157
b@1402 158 To start the test, open the browser and type
b@1402 159
b@1402 160 \texttt{localhost:8000}
b@1402 161
b@1402 162 and hit enter. The test should start (see Figure \ref{fig:test}).
b@1402 163
b@1402 164 To quit the server, either close the terminal window or press Ctrl+C on your keyboard to forcibly shut the server.
b@1402 165
b@1402 166 \subsubsection{Windows}
b@1402 167
b@1402 168 On Windows, Python 2.7 is not generally preinstalled and therefore has to be downloaded\footnote{\url{https://www.python.org/downloads/windows/}} and installed to be able to run scripts such as the local webserver, necessary if the tool is hosted locally.
b@1402 169
b@1402 170 Simply double click the Python script \texttt{pythonServer.py} in the folder you downloaded.
b@1402 171
b@1402 172 You may see a warning like the one in Figure \ref{fig:warning}. Click `Allow access'.
b@1402 173
b@1402 174 \begin{figure}[htbp]
b@1402 175 \begin{center}
b@1402 176 \includegraphics[width=.6\textwidth]{warning.png}
b@1402 177 \caption{Windows: Potential warning message when executing \texttt{pythonServer.py}.}
b@1402 178 \label{fig:warning}
b@1402 179 \end{center}
b@1402 180 \end{figure}
b@1402 181
b@1402 182 The process should now start, in the Command prompt that opens - see Figure \ref{fig:python}.
b@1402 183
b@1402 184 \begin{figure}[htbp]
b@1402 185 \begin{center}
b@1402 186 \includegraphics[width=.75\textwidth]{python.png}
b@1402 187 \caption{Windows: The Command Prompt after running \texttt{pythonServer.py} and opening the corresponding website.}
b@1402 188 \label{fig:python}
b@1402 189 \end{center}
b@1402 190 \end{figure}
b@1402 191
b@1402 192 You can leave this running throughout the different experiments (i.e. leave the Command Prompt open).
b@1402 193
b@1402 194 To start the test, open the browser and type
b@1402 195
b@1402 196 \texttt{localhost:8000}
b@1402 197
b@1402 198 and hit enter. The test should start (see Figure \ref{fig:test}).
b@1402 199
b@1402 200 \begin{figure}[htb]
b@1402 201 \begin{center}
b@1402 202 \includegraphics[width=.8\textwidth]{test.png}
b@1402 203 \caption{The start of the test in Google Chrome on Windows 7.}
b@1402 204 \label{fig:test}
b@1402 205 \end{center}
b@1402 206 \end{figure}
b@1402 207
b@1402 208 If at any point in the test the participant reports weird behaviour or an error of some kind, or the test needs to be interrupted, please notify the experimenter and/or refer to Section \ref{sec:troubleshooting}.
b@1402 209
b@1402 210 When the test is over (the subject should see a message to that effect, and click `Submit' one last time), the output XML file containing all collected data should have appeared in `saves/'. The names of these files are `test-0.xml', `test-1.xml', etc., in ascending order. The Terminal or Command prompt running the local web server will display the following file name. If such a file did not appear, please again refer to Section \ref{sec:troubleshooting}.
b@1402 211
b@1402 212 It is advised that you back up these results as often as possible, as a loss of this data means that the time and effort spent by the subject(s) has been in vain. Save the results to an external or network drive, and/or send them to the experimenter regularly.
b@1402 213
b@1402 214 To start the test again for a new participant, you do not need to close the browser or shut down the Terminal or Command Prompt. Simply refresh the page or go to \texttt{localhost:8000} again.
b@1402 215
b@1402 216
b@1402 217 \subsection{Remote test}
b@1402 218 Put all files on a web server which supports PHP. This allows the `save.php' script to store the XML result files in the `saves/' folder. If the web server is not able to store the XML file there at the end of the test, it will present the XML file locally to the user, as a `Save file' link.
b@1435 219
b@1435 220 Make sure the \texttt{projectReturn} attribute of the \texttt{setup} node is set to the \texttt{save.php} script.
b@1435 221
b@1435 222 Then, just go to the URL of the corresponding HTML file, e.g. \texttt{http://server.com/path/to/WAET/index.html?url=test/my-test.xml}. If storing on the server doesn't work at submission (e.g. if the \texttt{projectReturn} attribute isn't properly set), the result XML file will be presented to the subject on the client side, as a `Save file' link.
b@1435 223
nickjillings@1363 224 \subsection{Load a test / Multiple test documents}
nickjillings@1446 225 By default the index page will load a demo page of tests. To automatically load a test document, you need to append the location in the URL. If your URL is normally http://localhost:8000/index.html you would append the following: \texttt{?url=/path/to/your/test.xml}. Replace the fields with your actual path, the path is local to the running directory, so if you have your test in the directory \texttt{example\_eval} called \texttt{project.xml} you would append \texttt{?url=/example\_eval/project.xml}.
b@1435 226
b@1402 227 \clearpage
b@1435 228
b@1435 229 \section{Interfaces}
b@1435 230
b@1435 231 The Web Audio Evaluation Tool comes with a number of interface styles, each of which can be customised extensively, either by configuring them differently using the many optional features, or by modifying the JavaScript files.
b@1435 232
nickjillings@1363 233 To set the interface style for the whole test, set the attribute of the \texttt{setup} node to \texttt{interface="APE"}, where \texttt{"APE"} is one of the interface names below.
b@1435 234
b@1435 235 \subsection{APE}
b@1435 236 The APE interface is based on \cite{ape}, and consists of one or more axes, each corresponding with an attribute to be rated, on which markers are placed. As such, it is a multiple stimulus interface where (for each dimension or attribute) all elements are on one axis so that they can be maximally compared against each other, as opposed to rated individually or with regards to a single reference.
b@1435 237 It also contains an optional text box for each element, to allow for clarification by the subject, tagging, and so on.
b@1435 238
b@1435 239 \subsection{MUSHRA}
nickjillings@1363 240 This is a straightforward implementation of \cite{mushra}, especially common for the rating of audio quality, for instance for the evaluation of audio codecs. This can also operate any vertical slider style test and does not necessarily have to match the MUSHRA specification.
nickjillings@1363 241
nickjillings@1363 242 \subsection{AB}
nickjillings@1363 243 Performs a pairwise comparison, but supports ABX and n-way comparison (in the example we demonstrate it performing a 7-way comparison).
nickjillings@1363 244
b@2103 245 \subsection{Discrete/Likert}
nickjillings@1363 246 Each audio element is given a discrete set of values based on the number of slider options specified. For instance, Likert specifies 5 values and therefore each audio element must be one of those 5 values.
nickjillings@1363 247
nickjillings@1363 248 \subsection{ACR/CCR/DCR/horizontal}
nickjillings@1363 249 Creates the same interfaces as MUSHRA except the sliders are horizontal, not vertical.
b@1435 250
b@1402 251
b@1435 252 \clearpage
b@1435 253
nickjillings@1363 254 \section{Project XML}
nickjillings@1363 255
nickjillings@1363 256 Each test is defined by its project XML file, examples of these can be seen in the ./example\_eval/ directory.
nickjillings@1363 257
nickjillings@1363 258 In the XML there are several nodes which must be defined:
nickjillings@1363 259 \begin{itemize}
nickjillings@1363 260 \item \texttt{<waet>}: The root node.
nickjillings@1363 261 \item \texttt{<setup>}: The first child node, defines whole-test parameters
nickjillings@1363 262 \item \texttt{<page>}: Specifies a test page, attached \emph{after} the \texttt{<setup>}.
nickjillings@1363 263 \item \texttt{<audioelement>}: Specifies an audio element.
nickjillings@1363 264 \end{itemize}
nickjillings@1363 265
nickjillings@1363 266 The test uses XML validation, so the ordering of nodes is important to pass this validation. Some nodes also have specific attributes which must be set and may even have a certain format to apply them. This is done so error checking can be performed both quickly and succintly with easy to find errors before loading and running a test session.
nickjillings@1363 267
nickjillings@1363 268 Before identifying any features, this part will walk you through the available nodes, their function and their attributes.
nickjillings@1363 269
nickjillings@1363 270 \subsection{Root}
nickjillings@1363 271 The root node is \texttt{<waet>}, it must have the following attributes:
nickjillings@1363 272
nickjillings@1363 273 \texttt{xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"}
nickjillings@1363 274
nickjillings@1363 275 \texttt{xsi:noNamespaceSchemaLocation="test-schema.xsd"}.
nickjillings@1363 276
nickjillings@1363 277 This will ensure it is checked against the XML schema for validation.
nickjillings@1363 278
nickjillings@1363 279 \subsection{Set up}
nickjillings@1363 280 The first child node, \texttt{<setup>} specifies any one time and global parameters. It takes the following attributes:
nickjillings@1363 281 \begin{itemize}
nickjillings@1363 282 \item \texttt{interface}: String, mandatory, specifies the interface to load
b@2103 283 \item \texttt{projectReturn}: URL, mandatory, specifies the return point. Can be a 3rd party server or the local server. Set to null to disable automatic saving. Specifying ``save.php'' will trigger the return if either the PHP or python servers are used. On error, it will always default to presenting the save on page.
nickjillings@1363 284 \item \texttt{randomiseOrder}: Boolean, optional, if true it will randomise the order of the test pages. Default is false.
nickjillings@1363 285 \item \texttt{testPages}: non-negative integer, optional. Specifies the number of test pages to actually test with. Combined with randomiseOrder being true will give a random set of test pages per participant from the given pool of \texttt{<page>} nodes. Specifying 0 disables this option, default is 0.
nickjillings@1363 286 \item \texttt{loudness}: non-positive integer, optional. Set the default LUFS target value. See \ref{sec:loudness} for more.
nickjillings@1363 287 \item \texttt{sampleRate}: positive integer, optional. If set, the sample rate reported by the Web Audio API must match this number. See \ref{sec:samplerate}.
nickjillings@1363 288 \end{itemize}
nickjillings@1363 289
nickjillings@1363 290 The \texttt{<setup>} node takes the following child nodes, note these must appear in this order:
nickjillings@1363 291 \begin{itemize}
nickjillings@1363 292 \item \texttt{<survey>}: Min of 0, max of 2 occurences. See \ref{sec:survey}
nickjillings@1363 293 \item \texttt{<metric>}: Must appear only once.
nickjillings@1363 294 \item \texttt{<interface>}: Must appear only once.
nickjillings@1363 295 \end{itemize}
nickjillings@1363 296
nickjillings@1363 297 \subsection{Page}
nickjillings@1365 298 \label{sec:page}
nickjillings@1363 299 The only other first level child nodes, these specify the test pages. It takes the following attributes:
nickjillings@1363 300 \begin{itemize}
nickjillings@1363 301 \item \texttt{id}: ID, mandatory. A string which must be unique across the entire XML. It is used to identify the page on test completion as pages are returned in the results in the order they appeared, not specified.
b@2103 302 \item \texttt{hostURL}: URL, mandatory. Used in conjuction with the \texttt{<audioelement>} url to specify where the audio files are located. For instance if all your files are in the directory \texttt{./test/} you can set this attribute to ``/test/'' and the \texttt{<audioelement>} url attribute only needs to file name. Set to ``'' if no hostURL prefix desired.
nickjillings@1363 303 \item \texttt{randomiseOrder}: Boolean, optional. If true the audio fragments are presented randomly rather than the order specified. See \ref{sec:randomisation}. Default is false.
nickjillings@1363 304 \item \texttt{repeatCount}: non-negative integer, optional. Specify the number of times to repeat the test page (re-present). Each presentation will appear as an individual page in the results. Default is 0.
nickjillings@1363 305 \item \texttt{loop}: Boolean, optional. If true, the audio elements will loop synchronously with each other. See \ref{sec:looping}. Default is false.
nickjillings@1363 306 \item \texttt{showElementComments}: Boolean, optional. If true then there will be a comment box on the test page for each audio element presented, see \ref{sec:commentboxes}.
nickjillings@1363 307 \item \texttt{loudness}: non-positive integer, optional. Set the LUFS target value for this page. Supersedes the \texttt{<setup>} loudness attribute for this page. See \ref{sec:loudness} for more.
nickjillings@1363 308 \end{itemize}
nickjillings@1363 309
nickjillings@1363 310 The \texttt{<page>} node takes the following child, nodes note these must appear in this order:
nickjillings@1363 311 \begin{itemize}
nickjillings@1363 312 \item \texttt{<title>}: Appear once or not at all. The text content of this node specifies the title of the test page, for instance \texttt{<title>John Doe's Test</title>}
nickjillings@1363 313 \item \texttt{<commentboxprefix}: Appear once or not at all. The text content specifies the prefix of the comment boxes, see \ref{sec:commentboxes}.
nickjillings@1363 314 \item \texttt{<interface>}: Must appear only once.
nickjillings@1363 315 \item \texttt{<audioelement>}: Minimum of one. Specifies an audio element, see \ref{sec:audioelement}.
nickjillings@1365 316 \item \texttt{<commentquestion>}: Min of 0, max unlimited occurences. See \ref{sec:commentboxes}.
nickjillings@1363 317 \item \texttt{<survey>}: Min of 0, max of 2 occurences. See \ref{sec:survey}
nickjillings@1363 318 \end{itemize}
nickjillings@1363 319
nickjillings@1363 320 \subsection{Survey}
nickjillings@1363 321 \label{sec:survey}
nickjillings@1363 322 These specify any survey items to be presented. The must be a maximum of two of these per \texttt{<setup>} and \texttt{<page>} nodes. These have one attribute, location, which must be set to one of the following: before, pre, after or post. In this case before == pre and after == post. This specifies where the survey must appear before or after the node it is associated with. When a child of \texttt{<setup>} then pre/before will be shown before the first test page and after/post shown after completing the last test page. When a child of \texttt{<page>} then pre/before is before the test commences and after/post is once the test has been submitted.
nickjillings@1363 323
nickjillings@1363 324 The survey node takes as its only set of childs the \texttt{<surveyentry>} node of which there can be any number.
nickjillings@1363 325
nickjillings@1363 326 \subsubsection{Survey Entry}
nickjillings@1363 327 These nodes have the following attributes, which vary depending on the survey type wanted:
nickjillings@1363 328 \begin{itemize}
nickjillings@1363 329 \item \texttt{id}: ID, mandatory. Must be unique across the entire XML, used to identify the response in the results.
nickjillings@1363 330 \item \texttt{type}: String, mandatory. Must be one of the following: statement, question, checkbox, radio or number. This defines the type to show.
nickjillings@1363 331 \item \texttt{mandatory}: Boolean, optional. Defines if the survey must have a response or not. Does not apply to statements. Default is false.
nickjillings@1363 332 \item \texttt{min}: Number, optional. Only applies when \texttt{type="number"}, the minimum valid response.
nickjillings@1363 333 \item \texttt{max}: Number, optional. Only applies when \texttt{type="number"}, the maximum valid response.
nickjillings@1363 334 \item \texttt{boxsize}: String, optional. Only applies when \texttt{type="question"} and must be one of the following: normal (default), small, large or huge.
nickjillings@1363 335 \end{itemize}
nickjillings@1363 336
nickjillings@1363 337 The nodes have the following children, which vary depending on the survey type wanted.
nickjillings@1363 338 \begin{itemize}
nickjillings@1363 339 \item \texttt{<statement>}: Must appear only once. Its text content specifies the text to appear as the statement or question for the user to respond to.
nickjillings@1363 340 \item \texttt{<option>}: Only valid if the parent node has the attribute \texttt{type} set to checkbox or radio. Has attribute \texttt{name} to identify the selected option in the results. The text content is the text to show next to the radio/checkbox.
nickjillings@1363 341 \end{itemize}
nickjillings@1363 342
nickjillings@1363 343 \subsection{Interface}
nickjillings@1363 344 This node specifies any interface specific options and test parameters. It has an optional \texttt{name} attribute used to set the axis name (where applicable), such as the multi-axis APE interface. Specifying multiple interface nodes in a \texttt{<page>} node will trigger multiple axis where applicable, otherwise only the \emph{first node} will be used and the rest ignored.
nickjillings@1363 345
nickjillings@1363 346 The node has the following children, note the order these must appear in is as follows:
nickjillings@1363 347 \begin{itemize}
nickjillings@1363 348 \item \texttt{title}: Min 0, max 1 occurence. The text content specifies the name of the axis as shown to the user.
nickjillings@1363 349 \item \texttt{interfaceoption}: Min 0, max unbounded. Specifies the interface options. See \ref{sec:interfaceoption}.
nickjillings@1363 350 \item \texttt{scales}: Min 0, max 1 occurence. Contains \texttt{<scalelable>} nodes which define the displayed scales. See \ref{sec:scales}.
nickjillings@1363 351 \end{itemize}
nickjillings@1363 352
nickjillings@1363 353 \subsection{Audio Element}
nickjillings@1363 354 \label{sec:audioelement}
nickjillings@1363 355 Appear as children of the \texttt{page} node. Each of these specify an individual interface fragment to display. Multiple fragments can reference the same file (allowing for repetition with different parameters or blind-doubles). The node has the following attributes:
nickjillings@1363 356 \begin{itemize}
nickjillings@1363 357 \item \texttt{id}: ID, mandatory. Must be unique across the test page. Used to identify the specific fragment in the results.
nickjillings@1363 358 \item \texttt{url}: URL, mandatory. Used with the parent \texttt{page} nodes' \texttt{hostURL} attribute to get the full url of the audio file to load.
nickjillings@1363 359 \item \texttt{gain}: Float, optional. Specify the gain in decibels to apply to the node after loudness normalisation. Default is 0.
nickjillings@1363 360 \item \texttt{type}: String, optional. Must be one of the following: normal (default when not specified), anchor, reference or outside-reference. Normal, anchor and reference are presented as normal, outside-reference presents the node as a separate interface option.
nickjillings@1363 361 \item \texttt{marker}: Integer between 0 and 100, optional. Only used when \texttt{type="anchor"|"reference"}. See \ref{sec:referencesandanchors}.
nickjillings@1363 362 \end{itemize}
nickjillings@1363 363
nickjillings@1363 364
b@1435 365 \section{Features}
b@1435 366
b@1447 367 This section covers the different features implemented in the Web Audio Evaluation Tool, how to use them, and what to know about them.
b@1435 368
b@1435 369 Unless otherwise specified, \emph{each} feature described here is optional, i.e. it can be enabled or disabled and adjusted to some extent.
b@1435 370
nickjillings@1363 371 As the example project showcases (nearly) all of these features, please refer to its configuration XML document for a demonstration of how to enable and adjust them.
b@1435 372
nickjillings@1363 373 \subsection{Interface options}
nickjillings@1363 374 The interface node has children of interface options which are used to specify modifications to the test environment. These are divided into two catagories: check and show. Check are used to specify conditions which must be met before a page can be completed, these include checking all fragments have been played or checking all fragments have a comment and so on. Show is used to show an optional on page element or control, such as the playhead or master volume.
nickjillings@1363 375
b@2103 376 Check items have the attribute ``type'' set to ``check''. The following list gives the string to give the ``name'' attribute along with a description of the check.
nickjillings@1363 377 \begin{itemize}
nickjillings@1363 378 \item \texttt{fragmentPlayed}: Checks that all fragments have been at least partially played
nickjillings@1363 379 \item \texttt{fragmentFullPlayback}: Checks that all fragments have been fully played. \emph{NOTE:} This will always clear if the page is looping as it is not possible to know every sample has been played.
nickjillings@1363 380 \item \texttt{fragmentMoved}: Checks that all fragments have been moved. This is interface dependent, for instance on AB this will always clear as there is no movement.
nickjillings@1363 381 \item \texttt{fragmentComments}: Cheks that all fragments have a comment. Will clear if there are no on page comments but with a console warning.
b@2103 382 \item \texttt{scalerange}: Has two extra attributes ``min'' and ``max''. Checks that at least one element is below the min value and one element is above the max value.
nickjillings@1363 383 \end{itemize}
b@2103 384 % QUANTISATION OF THE SCALE: to be implemented?
b@1447 385
b@2103 386 Show items have the attribute ``type'' set to ``show''. The following list gives the string to give the ``name'' attribute along with a description.
nickjillings@1363 387 \begin{itemize}
nickjillings@1363 388 \item \texttt{playhead}: Shows the playhead to the end user indicating where in the file they are currently listening
nickjillings@1363 389 \item \texttt{page-count}: Shows the current test page number and the total number of test pages.
nickjillings@1363 390 \item \texttt{volume}: Shows a master volume control to the user to manipulate the output gain of the page. This is tracked.
nickjillings@1363 391 \end{itemize}
b@1447 392
b@1447 393 \subsubsection{Multiple scales}
b@1447 394 In the case of multiple rating scales, e.g. when the stimuli are to be rated in terms of attributes `timbre' and `spatial impression', multiple interface nodes will have to be added, each specifying the title and annotations.
b@1447 395
b@1447 396 This is where the \texttt{interface}'s \texttt{name} attribute is particularly important: use this to retrieve the rating values, comments and metrics associated with the specified interface.
b@1447 397 If none is given, you can still use the automatically given \texttt{interface-id}, which is the interface number starting with 0 and corresponding to the order in which the rating scales appear.
b@1447 398
b@1435 399 \subsection{Randomisation}
nickjillings@1363 400 \label{sec:randomisation}
b@1447 401 [WORK IN PROGRESS]
b@1435 402
b@1435 403 \subsubsection{Randomisation of configuration XML files}
nickjillings@1363 404 The python server has a special function to automatically cycle through a list of test pages. Instead of directly requesting an XML, simply setting the url item in the browser URL to \texttt{pseudo.xml} will cycle through a list of XMLs. These XMLs must be in the local directory called \texttt{./pseudo/}.
b@1435 405 % how to
b@1435 406 % explain how this is implemented in the pythonServer
nickjillings@1446 407 %Nick? already implemented in the PHP?
nickjillings@1446 408 % Needs to be implemented in PHP and automated better, will complete soon
b@1435 409
b@1435 410
b@1435 411 \subsubsection{Randomsation of page order}
nickjillings@1446 412 The page order randomisation is set by the \texttt{<setup>} node attribute \texttt{randomise-order}, for example \texttt{<setup ... randomise-order="true">...</setup>} will randomise the test page order. When not set, the default is to \textbf{not} randomise the test page order.
b@1435 413
b@1435 414 \subsubsection{Randomisation of axis order}
b@1435 415
b@1435 416 \subsubsection{Randomisation of fragment order}
nickjillings@1446 417 The audio fragment randomisation is set by the \texttt{<audioholder>} node attribute \texttt{randomise-order}, for example \texttt{<audioholder ... randomise-order="true">...</audioholder>} will randomise the test page order. When not set, the default is to \textbf{not} randomise the test page order.
b@1435 418
b@1435 419 \subsubsection{Randomisation of initial slider position}
nickjillings@1446 420 By default slider values are randomised on start. The MUSHRA interface supports setting the initial values of all sliders throught the \texttt{<audioholder>} attribute \texttt{initial-position}. This takes an integer between 0 and 100 to signify the slider position.
b@1435 421 % /subsubsection{Randomisation of survey question order}
b@1435 422 % should be an attribute of the individual 'pretest' and 'posttest' elements
b@1435 423 % uncomment once we have it
b@1435 424
b@1435 425 \subsection{Looping}
nickjillings@1363 426 \label{sec:looping}
nickjillings@1363 427 Looping enables the fragments to loop until stopped by the user. Looping is synchronous so all fragments start at the same time on each loop.
b@2103 428 Individual test pages can have their playback looped by the \texttt{<page>} attribute \texttt{loop} with a value of ``true'' or ``false''.
b@1435 429 If the fragments are not of equal length initially, they are padded with zeros so that they are equal length, to enable looping without the fragments going out of sync relative to each other.
b@1435 430
nickjillings@1363 431 Note that fragments cannot be played until all page fragments are loaded when in looped mode, as the engine needs to know the length of each fragment to calculate the padding.
b@1435 432
b@1435 433 \subsection{Sample rate}
nickjillings@1363 434 \label{sec:samplerate}
nickjillings@1363 435 If you require the test to be conducted at a certain sample rate (i.e. you do not tolerate resampling of the elements to correspond with the system's sample rate), add \texttt{sampleRate="96000"} - where ``96000'' can be any support sample rate (in Hz) - so that a warning message is shown alerting the subject that their system's sample rate is different from this enforced sample rate. This is checked immediately after parsing and stops the page loading any other elements if this check has failed.
b@1435 436
b@1435 437 \subsection{Metrics}
nickjillings@1446 438 The \texttt{Metric} node, which contains the metrics to be tracked during the complete test, is a child of the \texttt{setup} node, and it could look as follows.
b@1435 439
b@1435 440 \begin{lstlisting}
b@1435 441 <Metric>
b@1435 442 <metricEnable>testTimer</metricEnable>
b@1435 443 <metricEnable>elementTimer</metricEnable>
b@1435 444 <metricEnable>elementInitialPosition</metricEnable>
b@1435 445 <metricEnable>elementTracker</metricEnable>
b@1435 446 <metricEnable>elementFlagListenedTo</metricEnable>
b@1435 447 <metricEnable>elementFlagMoved</metricEnable>
b@1435 448 <metricEnable>elementListenTracker</metricEnable>
b@1435 449 </Metric>
b@1435 450 \end{lstlisting}
b@1435 451
nickjillings@1365 452 When in doubt, err on the inclusive side, as one never knows which information is needed in the future. Most of these metrics are necessary for post-processing scripts such as timeline\_view\_movement.py. % Brecht: should perhaps list somewhere what metrics are required for which analysis scripts.
b@1435 453
b@1435 454 \subsubsection{Time test duration}
b@1435 455 \texttt{testTimer}\\
nickjillings@1446 456 One per test page. Presents the total test time from the first playback on the test page to the submission of the test page (exculding test time of the pre-/post- test surveys). This is presented in the results as \texttt{<metricresult id="testTime"> 8.60299319727892 </metricresult>}. The time is in seconds.
b@1435 457
b@1435 458 \subsubsection{Time fragment playback}
b@1435 459 \texttt{elementTimer}\\
nickjillings@1446 460 One per audio fragment per test page. This totals up the entire time the audio fragment has been listened to in this test and presented \texttt{<metricresult name="enableElementTimer"> 1.0042630385487428 </metricresult>}. The time is in seconds.
b@1435 461
b@1435 462 \subsubsection{Initial positions}
b@1435 463 \texttt{elementInitialPosition}\\
nickjillings@1446 464 One per audio fragment per test page. Tracks the initial position of the sliders, especially relevant when these are randomised. Example result \texttt{<metricresult name="elementInitialPosition"> 0.8395522388059702 </metricresult>}.
b@1435 465
b@1435 466 \subsubsection{Track movements}
nickjillings@1446 467 \texttt{elementTracker}\\
nickjillings@1446 468 One per audio fragment per test page. Tracks the movement of each interface object. Each movement event has the time it occured at and the new value.
nickjillings@1446 469 \subsubsection{Which fragments listened to}
nickjillings@1446 470 \texttt{elementFlagListenedTo}\\
nickjillings@1446 471 One per audio fragment per test page. Boolean response, set to true if listened to.
nickjillings@1446 472 \subsubsection{Which fragments moved}
nickjillings@1446 473 \texttt{elementFlagMoved}\\
nickjillings@1446 474 One per audio fragment per test page. Binary check whether or not a the marker corresponding with a particular fragment was moved at all throughout the experiment.
b@1435 475
nickjillings@1446 476 \subsubsection{elementListenTracker}
nickjillings@1446 477 \texttt{elementListenTracker}\\
nickjillings@1446 478 One per audio fragment per test page. Tracks the playback events of each audio element pairing both the time in the test when playback started and when it stopped, it also gives the buffertime positions.
b@1435 479
b@1435 480 \subsection{References and anchors}
nickjillings@1363 481 \label{sec:referencesandanchors}
nickjillings@1446 482 The audio elements, \texttt{<audioelement>} have the attribute \texttt{type}, which defaults to normal. Setting this to one of the following will have the following effects.
nickjillings@1446 483 \subsubsection{Outside Reference}
b@2103 484 Set type to `outside-reference'. This will place the object in a separate playback element clearly labelled as an outside reference. This is exempt of any movement checks but will still be included in any listening checks.
b@1435 485 \subsubsection{Hidden reference}
b@2103 486 Set type to `reference'. The element will still be randomised as normal (if selected) and presented to the user. However the element will have the `reference' type in the results to quickly find it. The reference can be forced to be below a value before completing the test page by setting the attribute `marker' to be a value between 0 and 100 representing the integer value position it must be equal to or above.
b@1435 487 \subsubsection{Hidden anchor}
b@2103 488 Set type to `anchor'. The element will still be randomised as normal (if selected) and presented to the user. However the element will have the `anchor' type in the results to quickly find it. The anchor can be forced to be below a value before completing the test page by setting the attribute `marker' to be a value between 0 and 100 representing the integer value position it must be equal to or below.
b@1435 489
b@1435 490 \subsection{Checks}
b@1435 491 \label{sec:checks}
b@1435 492
b@1435 493 %blabla
b@1435 494 These checks are enabled in the \texttt{interface} node, which is a child of the \texttt{setup} node.
b@1435 495 \subsubsection{Playback checks}
b@1435 496 % what it does/is
b@1435 497 Enforce playing each sample at least once, for at least a little bit (e.g. this test is satisfied even if you only play a tiny portion of the file), by alerting the user to which samples have not been played upon clicking `Submit'. When enabled, one cannot proceed to the next page, answer a survey question, or finish the test, before clicking each sample at least once.
b@1435 498 % how to enable/disable
b@1435 499
b@1435 500 Alternatively, one can check whether the \emph{entire} fragment was listened to at least once.
b@1435 501 % how to enable
b@1435 502
b@1435 503 Add \texttt{<check name="fragmentPlayed"/>} to the \texttt{interface} node.
b@1435 504
b@1435 505
b@1435 506 \subsubsection{Movement check}
b@1435 507 Enforce moving each sample at least once, for at least a little bit (e.g. this test is satisfied even if you only play a tiny portion of the file), by alerting the user to which samples have not been played upon clicking `Submit'. When enabled, one cannot proceed to the next page, answer a survey question, or finish the test, before clicking each sample at least once.
b@1435 508 If there are several axes, the warning will specify which samples have to be moved on which axis.
b@1435 509
b@1435 510 Add \texttt{<check name="fragmentMoved"/>} to the \texttt{interface} node.
b@1435 511
b@1435 512 \subsubsection{Comment check}
b@1435 513 % How to enable/disable?
b@1435 514
b@1435 515 Enforce commenting, by alerting the user to which samples have not been commented on upon clicking `Submit'. When enabled, one cannot proceed to the next page, answer a survey question, or finish the test, before putting at least one character in each comment box.
b@1435 516
b@1435 517 Note that this does not apply to any extra (text, radio button, checkbox) elements, unless these have the `mandatory' option enabled. %Nick? is this extra 'mandatory' option implemented?
b@1435 518
b@1435 519 Add \texttt{<check name="fragmentComments"/>} to the \texttt{interface} node.
b@1435 520
b@1435 521 %ADD: how to add a custom comment box
b@1435 522
b@1435 523 \subsubsection{Scale use check}
b@1435 524 It is possible to enforce a certain usage of the scale, meaning that at least one slider needs to be below and/or above a certain percentage of the slider.
b@1435 525
b@1435 526 Add \texttt{<check name="scalerange" min="25" max="75"/>} to the \texttt{interface} node.
b@1435 527
b@1435 528 \subsubsection{Note on the use of multiple rating axes}
b@1435 529 I.e. what if more than one axis? How to specify which axis the checks relate to? %Nick? to add?
b@1435 530
b@1435 531 \subsection{Platform information}
b@1435 532 % what does it do, what does it look like
b@1435 533 % limitations?
b@1447 534 For troubleshooting and usage statistics purposes, information about the browser and the operating system is logged in the results XML file. This is especially useful in the case of remote tests, when it is not certain which operating system, browser and/or browser were used. Note that this information is not always available and/or accurate, e.g. when the subject has taken steps to be more anonymous, so it should be treated as a guide only.
b@1447 535
b@1447 536 Example:
b@1447 537 \begin{lstlisting}
b@1447 538 <navigator>
b@1447 539 <platform>MacIntel</platform>
b@1447 540 <vendor>Google Inc.</vendor>
nickjillings@1363 541 <uagent>Mozilla/5.0 ... </uagent>
nickjillings@1365 542 <screen innerHeight="1900px" innerWidth="1920px"/>
b@1447 543 </navigator>
b@1447 544 \end{lstlisting}
b@1435 545
b@1435 546 \subsection{Gain}
b@1435 547 It is possible to set the gain (in decibel) applied to the different audioelements, as an attribute of the \texttt{audioelement} nodes in the configuration XML file:
b@1435 548
nickjillings@1446 549 \texttt{<audioElements url="sample-01.wav" gain="-6" id="sample01quieter" />}\\
nickjillings@1365 550 Please note, there are no checks on this to detect if accidentaly typed in linear. This gain is applied \emph{after} any loudness normalisation.
b@1435 551
b@1435 552 \subsection{Loudness}
nickjillings@1363 553 \label{sec:loudness}
b@1435 554 % automatic loudness equalisation
b@1435 555 % guide to loudness.js
nickjillings@1363 556 Each audio fragment on loading has its loudness calculated. The tool uses the EBU R 128 recommendation following the ITU-R BS.1770-4 loduness calculations to return the integreated LUFS loudness. The attribute \texttt{loudness} will set the loudness from the scope it is applied in. Applying it in the \texttt{<setup>} node will set the loudness for all test pages. Applying it in the \texttt{<page>} node will set the loudness for that page. Applying it in the \texttt{<audioelement>} node will set the loudness for that fragment. The scope is set locally, so if there is a loudness on both the \texttt{<page>} and \texttt{<setup>} nodes, that test page will take the value associated with the \texttt{<page>}. The loudness attribute is set in LUFS
nickjillings@1365 557
nickjillings@1365 558 \subsection{Comment Boxes}
nickjillings@1365 559 \label{sec:commentboxes}
b@2103 560 There are two types of comment boxes which can be presented, those linked to the audio fragments on the page and those which pose a general question. The audio fragment boxes are shown by setting the attribute \texttt{showElementComments} to true of the page in question. This will then show a comment box below the main interface for every fragment on the page. There is some customisation around the text that accompanies the box, by default the text will read ``Comment on fragment'' followed by the fragment identifier (the number / letter shown by the interface). This `prefix' can be modified using the page node \texttt{<commentboxprefix>}, see \ref{sec:page} for where to place this node in the document. The comment box prefix node takes no attribute and the text contained by the node represents to the prefix. For instance if we have a node \texttt{<commentboxprefix> Describe fragment </commentboxprefix>}, then the interface will show ``Describe fragment'' followed by the identifier.
nickjillings@1365 561
nickjillings@1365 562 The second type of comment box is slightly more complex because it can handle different types of response data. These are called comment questions because they are located in the comment section of the test but pose a specific question.
b@1435 563
b@1435 564 \clearpage
b@1435 565
b@1402 566
b@1402 567 \section{Using the test create tool}
b@1402 568 We provide a test creation tool, available in the directory test\_create. This tool is a self-contained web page, so doubling clicking will launch the page in your system default browser.
b@1402 569
b@1402 570 The test creation tool can help you build a simple test very quickly. By simply selecting your interface and clicking check-boxes you can build a test in minutes.
b@1402 571
b@1402 572 Include audio by dragging and dropping the stimuli you wish to include.
b@1402 573
b@1402 574 The tool examines your XML before exporting to ensure you do not export an invalid XML structure which would crash the test.
b@1402 575
b@1402 576 This guide will help you to construct your own interface on top of the WAET (Web Audio Evaluation Tool) engine. The WAET engine resides in the core.js file, this contains prototype objects to handle most of the test creation, operation and data collection. The interface simply has to link into this at the correct points.
nickjillings@1446 577
nickjillings@1446 578 \section{Building your own interface}
b@1402 579
b@1402 580 \subsection{Nodes to familiarise}
b@1402 581 Core.js handles several very important nodes which you should become familiar with. The first is the Audio Engine, initialised and stored in variable `AudioEngineContext'. This handles the playback of the web audio nodes as well as storing the `AudioObjects'. The `AudioObjects' are custom nodes which hold the audio fragments for playback. These nodes also have a link to two interface objects, the comment box if enabled and the interface providing the ranking. On creation of an `AudioObject' the interface link will be nulled, it is up to the interface to link these correctly.
b@1402 582
b@1402 583 The specification document will be decoded and parsed into an object called `specification'. This will hold all of the specifications various nodes. The test pages and any pre/post test objects are processed by a test state which will proceed through the test when called to by the interface. Any checks (such as playback or movement checks) are to be completed by the interface before instructing the test state to proceed. The test state will call the interface on each page load with the page specification node.
b@1402 584
b@1402 585 \subsection{Modifying \texttt{core.js}}
b@1402 586 Whilst there is very little code actually needed, you do need to instruct core.js to load your interface file when called for from a specification node. There is a function called `loadProjectSpecCallback' which handles the decoding of the specification and setting any external items (such as metric collection). At the very end of this function there is an if statement, add to this list with your interface string to link to the source. There is an example in there for both the APE and MUSHRA tests already included. Note: Any updates to core.js in future work will most likely overwrite your changes to this file, so remember to check your interface is still here after any update that interferes with core.js.
b@1402 587 Any further files can be loaded here as well, such as css styling files. jQuery is already included.
b@1402 588
b@1402 589 \subsection{Building the Interface}
b@1402 590 Your interface file will get loaded automatically when the `interface' attribute of the setup node matches the string in the `loadProjectSpecCallback' function. The following functions must be defined in your interface file.
b@1402 591 \begin{itemize}
b@1402 592 \item \texttt{loadInterface} - Called once when the document is parsed. This creates any necessary bindings, such as to the metric collection classes and any check commands. Here you can also start the structure for your test such as placing in any common nodes (such as the title and empty divs to drop content into later).
b@1402 593 \item \texttt{loadTest(audioHolderObject)} - Called for each page load. The audioHolderObject contains a specification node holding effectively one of the audioHolder nodes.
b@1402 594 \item \texttt{resizeWindow(event)} - Handle for any window resizing. Simply scale your interface accordingly. This function must be here, but can me an empty function call.
b@1402 595 \end{itemize}
b@1402 596
b@1402 597 \subsubsection{loadInterface}
b@1402 598 This function is called by the interface once the document has been parsed since some browsers may parse files asynchronously. The best method is simply to put `loadInterface()' at the top of your interface file, therefore when the JavaScript engine is ready the function is called.
b@1402 599
b@1402 600 By default the HTML file has an element with id ``topLevelBody'' where you can build your interface. Make sure you blank the contents of that object. This function is the perfect time to build any fixed items, such as the page title, session titles, interface buttons (Start, Stop, Submit) and any holding and structure elements for later on.
b@1402 601
b@1402 602 At the end of the function, insert these two function calls: testState.initialise() and testState.advanceState();. This will actually begin the test sequence, including the pre-test options (if any are included in the specification document).
b@1402 603
b@1402 604 \subsubsection{loadTest(audioHolderObject)}
b@1402 605 This function is called on each new test page. It is this functions job to clear out the previous test and set up the new page. Use the function audioEngineContext.newTestPage(); to instruct the audio engine to prepare for a new page. ``audioEngineContext.audioObjects = [];'' will delete any audioObjects, interfaceContext.deleteCommentBoxes(); will delete any comment boxes and interfaceContext.deleteCommentQuestions(); will delete any extra comment boxes specified by commentQuestion nodes.
b@1402 606
b@1402 607 This function will need to instruct the audio engine to build each fragment. Just passing the constructor each element from the audioHolderObject will build the track, audioEngineContext.newTrack(element) (where element is the audioHolderObject audio element). This will return a reference to the constructed audioObject. Decoding of the audio will happen asynchronously.
b@1402 608
b@1402 609 You also need to link audioObject.interfaceDOM with your interface object for that audioObject. The interfaceDOM object has a few default methods. Firstly it must start disabled and become enabled once the audioObject has decoded the audio (function call: enable()). Next it must have a function exportXMLDOM(), this will return the xml node for your interface, however the default is for it to return a value node, with textContent equal to the normalised value. You can perform other functions, but our scripts may not work if something different is specified (as it will breach our results specifications). Finally it must also have a method getValue, which returns the normalised value.
b@1402 610
b@1402 611 It is also the job the interfaceDOM to call any metric collection functions necessary, however some functions may be better placed outside (for example, the APE interface uses drag and drop, therefore the best way was to call the metric functions from the dragEnd function, which is called when the interface object is dropped). Metrics based upon listening are handled by the audioObject. The interfaceDOM object must manage any movement metrics. For a list of valid metrics and their behaviours, look at the project specification document included in the repository/docs location. The same goes for any checks required when pressing the submit button, or any other method to proceed the test state.
b@1402 612
b@1435 613 \clearpage
b@1435 614 \section{Analysis and diagnostics}
b@1435 615 \subsection{In the browser}
b@1435 616 See `analysis.html' in the main folder: immediate visualisation of (by default) all results in the `saves/' folder.
b@1435 617
b@1435 618 \subsection{Python scripts}
b@1435 619 The package includes Python (2.7) scripts (in `scripts/') to extract ratings and comments, generate visualisations of ratings and timelines, and produce a fully fledged report.
b@1435 620
b@1435 621 Visualisation requires the free matplotlib toolbox (http://matplotlib.org), numpy and scipy.
b@1435 622 By default, the scripts can be run from the `scripts' folder, with the result files in the `saves' folder (the default location where result XMLs are stored). Each script takes the XML file folder as an argument, along with other arguments in some cases.
b@1435 623 Note: to avoid all kinds of problems, please avoid using spaces in file and folder names (this may work on some systems, but others don't like it).
b@1435 624
b@1435 625 \subsubsection{comment\_parser.py}
b@1435 626 Extracts comments from the output XML files corresponding with the different subjects found in `saves/'. It creates a folder per `audioholder'/page it finds, and stores a CSV file with comments for every `audioelement'/fragment within these respective `audioholders'/pages. In this CSV file, every line corresponds with a subject/output XML file. Depending on the settings, the first column containing the name of the corresponding XML file can be omitted (for anonymisation).
b@1435 627 Beware of Excel: sometimes the UTF-8 is not properly imported, leading to problems with special characters in the comments (particularly cumbersome for foreign languages).
b@1435 628
b@1435 629 \subsubsection{evaluation\_stats.py}
b@1435 630 Shows a few statistics of tests in the `saves/' folder so far, mainly for checking for errors. Shows the number of files that are there, the audioholder IDs that were tested (and how many of each separate ID), the duration of each page, the duration of each complete test, the average duration per page, and the average duration in function of the page number.
b@1435 631
b@1435 632 \subsubsection{generate\_report.py}
b@1435 633 Similar to `evaluation\_stats.py', but generates a PDF report based on the output files in the `saves/' folder - or any folder specified as command line argument. Uses pdflatex to write a LaTeX document, then convert to a PDF.
b@1435 634
b@1435 635 \subsubsection{score\_parser.py}
b@1435 636 Extracts rating values from the XML to CSV - necessary for running visualisation of ratings. Creates the folder `saves/ratings/' if not yet created, to which it writes a separate file for every `audioholder'/page in any of the output XMLs it finds in `saves/'. Within each file, rows represent different subjects (output XML file names) and columns represent different `audioelements'/fragments.
b@1435 637
b@1435 638 \subsubsection{score\_plot.py}
b@1435 639 Plots the ratings as stored in the CSVs created by score\_parser.py
b@1435 640 Depending on the settings, it displays and/or saves (in `saves/ratings/') a boxplot, confidence interval plot, scatter plot, or a combination of the aforementioned.
b@1435 641 Requires the free matplotlib library.
b@1435 642 At this point, more than one subjects are needed for this script to work.
b@1435 643
b@1435 644 \subsubsection{timeline\_view\_movement.py}
b@1435 645 Creates a timeline for every subject, for every `audioholder'/page, corresponding with any of the output XML files found in `saves/'. It shows the marker movements of the different fragments, along with when each fragment was played (red regions). Automatically takes fragment names, rating axis title, rating axis labels, and audioholder name from the XML file (if available).
b@1435 646
b@1435 647 \subsubsection{timeline\_view.py} % should be omitted or absorbed by the above soon
b@1435 648 Creates a timeline for every subject, for every `audioholder'/page, corresponding with any of the output XML files found in `saves/'. It shows when and for how long the subject listened to each of the fragments.
b@1435 649
b@1402 650
b@1402 651
b@1402 652 \clearpage
b@1402 653 \section{Troubleshooting} \label{sec:troubleshooting}
b@1435 654 \subsection{Reporting bugs and requesting features}
b@1435 655 Thanks to feedback from using the interface in experiments by the authors and others, many bugs have been caught and fatal crashes due to the interface seem to be a thing of the past entirely.
b@1402 656
b@1435 657 We continually develop this tool to fix issues and implement features useful to us or our user base. See \url{https://code.soundsoftware.ac.uk/projects/webaudioevaluationtool/issues} for a list of feature requests and bug reports, and their status.
b@1402 658
b@1435 659 Please contact the authors if you experience any bugs, if you would like additional functionality, if you spot any errors or gaps in the documentation, if you have questions about using the interface, or if you would like to give any feedback (even positive!) about the interface. We look forward to learning how the tool has (not) been useful to you.
b@1402 660
b@1402 661
b@1435 662 \subsection{First aid}
b@1435 663 Meanwhile, if things do go wrong or the test needs to be interrupted for whatever reason, all data is not lost. In a normal scenario, the test needs to be completed until the end (the final `Submit'), at which point the output XML is stored in the \texttt{saves/}. If this stage is not reached, open the JavaScript Console (see below for how to find it) and type
b@1402 664
b@1435 665 \texttt{createProjectSave()}
b@1402 666
b@1435 667 to present the result XML file on the client side, or
b@1402 668
b@1435 669 \texttt{createProjectSave(specification.projectReturn)}
b@1402 670
b@1435 671 to try to store it to the specified location, e.g. the `saves/' folder on the web server or the local machine (on failure the result XML should be presented directly in the web browser instead)
b@1402 672
b@1435 673 and hit enter. This will open a pop-up window with a hyperlink that reads `Save File'; click it and an XML file with results until that point should be stored in your download folder.
b@1435 674
b@1435 675 Alternatively, a lot of data can be read from the same console, in which the tool prints a lot of debug information. Specifically:
b@1435 676 \begin{itemize}
b@1435 677 \item the randomisation of pages and fragments are logged;
b@1435 678 \item any time a slider is played, its ID and the time stamp (in seconds since the start of the test) are displayed;
b@1435 679 \item any time a slider is dragged and dropped, the location where it is dropped including the time stamp are shown;
b@1435 680 \item any comments and pre- or post-test questions and their answers are logged as well.
b@1435 681 \end{itemize}
b@1402 682
b@1435 683 You can select all this and save into a text file, so that none of this data is lost. You may to choose to do this even when a test was successful as an extra precaution.
b@1402 684
b@1435 685 If you encounter any issue which you believe to be caused by any aspect of the tool, and/or which the documentation does not mention, please do let us know!
b@1402 686
b@1435 687 \subsubsection*{Opening the JavaScript Console}
b@1435 688 \begin{itemize}
b@1435 689 \item In Google Chrome, the JavaScript Console can be found in \textbf{View$>$Developer$>$JavaScript Console}, or via the keyboard shortcut Cmd + Alt + J (Mac OS X).
b@1435 690 \item In Safari, the JavaScript Console can be found in \textbf{Develop$>$Show Error Console}, or via the keyboard shortcut Cmd + Alt + C (Mac OS X). Note that for the Developer menu to be visible, you have to go to Preferences (Cmd + ,) and enable `Show Develop menu in menu bar' in the `Advanced' tab. \textbf{Note that as long as the Developer menu is not visible, nothing is logged to the console, i.e. you will only be able to see diagnostic information from when you switched on the Developer tools onwards.}
b@1435 691 \item In Firefox, go to \textbf{Tools$>$Web Developer$>$Web Console}, or hit Cmd + Alt + K.
b@1435 692 \end{itemize}
b@1402 693
b@1435 694 \subsection{Known issues and limitations}
b@1435 695 \label{sec:knownissues}
b@1435 696
b@1435 697 The following is a non-exhaustive list of problems and limitations you may experience using this tool, due to not being supported yet by us, or by the Web Audio API and/or (some) browsers.
b@1435 698
b@1435 699 \begin{itemize}
b@1435 700 \item Issue \href{https://code.soundsoftware.ac.uk/issues/1463}{\textbf{\#1463}}: \textbf{Firefox} only supports 8 bit and 16 bit WAV files. Pending automatic requantisation (which deteriorates the audio signal's dynamic range to some extent), WAV format stimuli need to adhere to these limitations in order for the test to be compatible with Firefox.
b@1435 701 \item Issues \href{https://code.soundsoftware.ac.uk/issues/1474}{\textbf{\#1474}} and \href{https://code.soundsoftware.ac.uk/issues/1462}{\textbf{\#1462}}: On occasions, audio is not working - or only a continuous `beep' can be heard - notably in \textbf{Safari}. Refreshing, quitting the browser and even enabling Developer tools in Safari's Preferences pane (`Advanced' tab: ``Show `Develop' menu in menu bar'') has helped resolve this. If no (high quality) audio can be heard, make sure your entire playback system's settings are all correct.
b@1435 702 \end{itemize}
b@1402 703
b@1402 704 \clearpage
b@1402 705 \bibliographystyle{ieeetr}
b@1402 706 \bibliography{Instructions}{}
b@1402 707
b@1402 708
b@1402 709 \clearpage
b@1402 710 \appendix
b@1402 711
b@1435 712 \section{Legacy}
b@1435 713 The APE interface and most of the functionality of the first WAET editions are inspired by the APE toolbox for MATLAB \cite{ape}. See \url{https://code.soundsoftware.ac.uk/projects/ape} for the source code and \url{http://brechtdeman.com/publications/aes136.pdf} for the corresponding paper.
b@1435 714
b@1435 715 \clearpage
b@1435 716
b@1402 717 \section{Listening test instructions example}
b@1402 718
b@1402 719 Before each test, show the instructions below or similar and make sure it is available to the subject throughout the test. Make sure to ask whether the participant has any questions upon seeing and/or reading the instructions.
b@1402 720
b@1402 721 \begin{itemize}
b@1402 722 \item You will be asked for your name (``John Smith'') and location (room identifier).
b@1402 723 \item An interface will appear, where you are asked to
b@1402 724 \begin{itemize}
b@1402 725 \item click green markers to play the different mixes;
b@1402 726 \item drag the markers on a scale to reflect your preference for the mixes;
b@1402 727 \item comment on these mixes, using text boxes with corresponding numbers (in your \textbf{native language});
b@1402 728 \item optionally comment on all mixes together, or on the song, in `General comments'.
b@1402 729 \end{itemize}
b@1402 730 \item You are asked for your personal, honest opinion. Feel free to use the full range of the scale to convey your opinion of the various mixes. Don?t be afraid to be harsh and direct.
b@1402 731 \item The markers appear at random positions at first (which means some markers may hide behind others).
b@1402 732 \item The interface can take a few seconds to start playback, but switching between mixes should be instantaneous.
b@1402 733 \item This is a research experiment, so please forgive us if things go wrong. Let us know immediately and we will fix it or restart the test.
b@1402 734 \item When the test is finished (after all songs have been evaluated), just call the experimenter, do NOT close the window.
b@1402 735 \item After the test, please fill out our survey about your background, experience and feedback on the test.
b@1402 736 \item By participating, you consent to us using all collected data for research. Unless asked explicitly, all data will be anonymised when shared.
b@1402 737 \end{itemize}
b@1402 738
b@1402 739 \clearpage
b@1402 740
b@1390 741 \section{Terminology} % just to keep track of what exactly we call things. Don't use terms that are too different, to avoid confusion.
b@1390 742 As a guide to better understand the Instructions, and to expand them later, here is a list of terms that may be unclear or ambiguous unless properly defined.
b@1435 743 \begin{description}
b@1435 744 \item[Subject] The word we use for a participant, user, ... of the test, i.e. not the experimenter who designs the test but the person who evaluates the audio under test as part of an experiment (or the preparation of one).
b@1390 745 \item[User] The person who uses the tool to configure, run and analyse the test - i.e. the experimenter, most likely a researcher - or at least
b@1435 746 \item[Page] A screen in a test; corresponds with an \texttt{audioholder}
b@1447 747 \item[Fragment] An element, stimulus or sample in a test; corresponds with an \texttt{audioelement}
b@1435 748 \item[Test] A complete test which can consist of several pages; corresponds with an entire configuration XML file
b@1435 749 \item[Configuration XML file] The XML file containing the necessary information on interface, samples, survey questions, configurations, ... which the JavaScript modules read to produce the desired test.
b@1435 750 \item[Results XML file] The output of a successful test, including ratings, comments, survey responses, timing information, and the complete configuration XML file with which the test was generated in the first place.
b@1435 751 \end{description}
b@1435 752
b@1435 753 \clearpage
b@1435 754
b@1435 755 \setcounter{secnumdepth}{0} % don't number this last bit
b@1435 756 \section{Contact details} % maybe add web pages, Twitter accounts, whatever you like
b@1402 757 \label{sec:contact}
b@1402 758
b@1402 759 \begin{itemize}
b@1402 760 \item Nicholas Jillings: \texttt{nicholas.jillings@mail.bcu.ac.uk}
b@1402 761 \item Brecht De Man: \texttt{b.deman@qmul.ac.uk}
b@1402 762 \item David Moffat: \texttt{d.j.moffat@qmul.ac.uk}
b@1402 763 \end{itemize}
b@1402 764
b@1402 765 \end{document}