annotate docs/SMC15/smc2015template.tex @ 1986:dc72cd2b8325

SMC Paper: Adding XML file examples and edits to intro and main seciton of paper.
author Dave Moffat <me@davemoffat.com>
date Fri, 24 Apr 2015 02:02:58 +0100
parents b78148108626
children 43b5c8f95bcb
rev   line source
b@1693 1 % -----------------------------------------------
b@1693 2 % Template for SMC 2012
b@1693 3 % adapted from the template for SMC 2011, which was adapted from that of SMC 2010
b@1693 4 % -----------------------------------------------
b@1693 5
b@1693 6 \documentclass{article}
b@1693 7 \usepackage{smc2015}
b@1693 8 \usepackage{times}
b@1693 9 \usepackage{ifpdf}
b@1693 10 \usepackage[english]{babel}
b@1693 11 \usepackage{cite}
b@1693 12
b@1672 13 \hyphenation{Java-script}
b@1672 14
b@1693 15 %%%%%%%%%%%%%%%%%%%%%%%% Some useful packages %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
b@1693 16 %%%%%%%%%%%%%%%%%%%%%%%% See related documentation %%%%%%%%%%%%%%%%%%%%%%%%%%
b@1693 17 %\usepackage{amsmath} % popular packages from Am. Math. Soc. Please use the
b@1693 18 %\usepackage{amssymb} % related math environments (split, subequation, cases,
b@1693 19 %\usepackage{amsfonts}% multline, etc.)
b@1693 20 %\usepackage{bm} % Bold Math package, defines the command \bf{}
b@1693 21 %\usepackage{paralist}% extended list environments
b@1693 22 %%subfig.sty is the modern replacement for subfigure.sty. However, subfig.sty
b@1693 23 %%requires and automatically loads caption.sty which overrides class handling
b@1693 24 %%of captions. To prevent this problem, preload caption.sty with caption=false
b@1693 25 %\usepackage[caption=false]{caption}
b@1693 26 %\usepackage[font=footnotesize]{subfig}
b@1693 27
b@1693 28
b@1693 29 %user defined variables
b@1669 30 \def\papertitle{WEB AUDIO EVALUATION TOOL: A BROWSER-BASED LISTENING TEST ENVIRONMENT} %?
b@1698 31 \def\firstauthor{Nicholas Jillings}
b@1698 32 \def\secondauthor{Brecht De Man}
b@1693 33 \def\thirdauthor{David Moffat}
b@1693 34 \def\fourthauthor{Joshua D. Reiss}
b@1693 35
b@1693 36 % adds the automatic
b@1693 37 % Saves a lot of ouptut space in PDF... after conversion with the distiller
b@1693 38 % Delete if you cannot get PS fonts working on your system.
b@1693 39
b@1693 40 % pdf-tex settings: detect automatically if run by latex or pdflatex
b@1693 41 \newif\ifpdf
b@1693 42 \ifx\pdfoutput\relax
b@1693 43 \else
b@1693 44 \ifcase\pdfoutput
b@1693 45 \pdffalse
b@1693 46 \else
b@1693 47 \pdftrue
b@1693 48 \fi
b@1693 49
b@1693 50 \ifpdf % compiling with pdflatex
b@1693 51 \usepackage[pdftex,
b@1693 52 pdftitle={\papertitle},
b@1693 53 pdfauthor={\firstauthor, \secondauthor, \thirdauthor},
b@1693 54 bookmarksnumbered, % use section numbers with bookmarks
b@1693 55 pdfstartview=XYZ % start with zoom=100% instead of full screen;
b@1693 56 % especially useful if working with a big screen :-)
b@1693 57 ]{hyperref}
b@1693 58 %\pdfcompresslevel=9
b@1693 59
b@1693 60 \usepackage[pdftex]{graphicx}
b@1693 61 % declare the path(s) where your graphic files are and their extensions so
b@1693 62 %you won't have to specify these with every instance of \includegraphics
b@1693 63 \graphicspath{{./figures/}}
b@1693 64 \DeclareGraphicsExtensions{.pdf,.jpeg,.png}
b@1693 65
b@1693 66 \usepackage[figure,table]{hypcap}
b@1693 67
b@1693 68 \else % compiling with latex
b@1693 69 \usepackage[dvips,
b@1693 70 bookmarksnumbered, % use section numbers with bookmarks
b@1693 71 pdfstartview=XYZ % start with zoom=100% instead of full screen
b@1693 72 ]{hyperref} % hyperrefs are active in the pdf file after conversion
b@1693 73
b@1693 74 \usepackage[dvips]{epsfig,graphicx}
b@1693 75 % declare the path(s) where your graphic files are and their extensions so
b@1693 76 %you won't have to specify these with every instance of \includegraphics
b@1693 77 \graphicspath{{./figures/}}
b@1693 78 \DeclareGraphicsExtensions{.eps}
b@1693 79
b@1693 80 \usepackage[figure,table]{hypcap}
b@1693 81 \fi
b@1693 82
b@1693 83 %setup the hyperref package - make the links black without a surrounding frame
b@1693 84 \hypersetup{
b@1693 85 colorlinks,%
b@1693 86 citecolor=black,%
b@1693 87 filecolor=black,%
b@1693 88 linkcolor=black,%
b@1693 89 urlcolor=black
b@1693 90 }
b@1693 91
b@1693 92
b@1693 93 % Title.
b@1693 94 % ------
b@1693 95 \title{\papertitle}
b@1693 96
b@1693 97 % Authors
b@1693 98 % Please note that submissions are NOT anonymous, therefore
b@1693 99 % authors' names have to be VISIBLE in your manuscript.
b@1693 100 %
b@1693 101 % Single address
b@1693 102 % To use with only one author or several with the same address
b@1693 103 % ---------------
b@1693 104 %\oneauthor
b@1693 105 % {\firstauthor} {Affiliation1 \\ %
b@1693 106 % {\tt \href{mailto:author1@smcnetwork.org}{author1@smcnetwork.org}}}
b@1693 107
b@1693 108 %Two addresses
b@1693 109 %--------------
b@1693 110 % \twoauthors
b@1693 111 % {\firstauthor} {Affiliation1 \\ %
b@1693 112 % {\tt \href{mailto:author1@smcnetwork.org}{author1@smcnetwork.org}}}
b@1693 113 % {\secondauthor} {Affiliation2 \\ %
b@1693 114 % {\tt \href{mailto:author2@smcnetwork.org}{author2@smcnetwork.org}}}
b@1693 115
b@1698 116
b@1698 117
b@1698 118 % FIX!!!
b@1693 119 \fourauthors
b@1693 120 {\firstauthor} {%Affiliation1 \\
b@1698 121 {\tt \href{mailto:b.deman@qmul.ac.uk}{n.g.r.jillings@se14.qmul.ac.uk, }}}
b@1693 122 {\secondauthor} {%Affiliation2\\ %
b@1698 123 {\tt \href{mailto:n.g.r.jillings@se14.qmul.ac.uk}{\{b.deman,}}}
b@1693 124 {\thirdauthor} {%Affiliation3\\ %
b@1698 125 {\tt \href{mailto:d.j.moffat@qmul.ac.uk}{d.j.moffat, }}}
b@1693 126 {\fourthauthor} {%Affiliation4\\ %
b@1698 127 {\tt \href{mailto:joshua.reiss@qmul.ac.uk}{joshua.reiss\}@qmul.ac.uk}}}
b@1693 128
b@1693 129 % ***************************************** the document starts here ***************
b@1693 130 \begin{document}
b@1693 131 %
b@1693 132 \capstartfalse
b@1693 133 \maketitle
b@1693 134 \capstarttrue
b@1693 135 %
b@1693 136 \begin{abstract}
b@1669 137 New functionality in HTML5, notably its Web Audio API, allow for increasingly powerful applications in the browser. % is this true?
b@1669 138 Perceptual evaluation tests for audio, where the subject assesses certain qualities of different audio fragments through a graphical user interface and/or text boxes, require playback of audio and rapid switching between different files. % what else?
b@1669 139 The advantage of a web application is easy deployment on any platform, without requiring any other application or library, easy storing of results on a server.
b@1669 140 [...]
b@1669 141 %Place your abstract at the top left column on the first page.
b@1669 142 %Please write about 150-200 words that specifically highlight the purpose of your work,
b@1669 143 %its context, and provide a brief synopsis of your results.
b@1669 144 %Avoid equations in this part.\\
b@1669 145
b@1693 146 \end{abstract}
b@1977 147
b@1977 148 % TOTAL PAPER: Minimum 4 pages, 6 preferred, max. 8 (6 for demos/posters)\\
b@1693 149
b@1693 150 \section{Introduction}\label{sec:introduction}
b@1693 151
nickjillings@1676 152 %NICK: examples of what kind of audio applications HTML5 has made possible, with references to publications (or website)\\
nickjillings@1676 153
b@1981 154 Perceptual evaluation of audio plays an important role in a wide range of research including audio effect design \cite{}, sound synthesis \cite{de2013real}, source separation \cite{}, codec design \cite{}, general perception of audio \cite{schoeffler2013impact}, and many others \cite{friberg2011comparison}. \\ % EXPAND
b@1981 155
b@1977 156 The Web Audio API is a high-level JavaScript API designed for real-time processing audio inside the browser through various processing nodes \cite{webaudioapi}. Various web sites have used the Web Audio API for either creative purposes, such as drum machines and score creation tools \cite{webaudiodemo}, %http://webaudio.github.io/demo-list/
nickjillings@1676 157 others from the list show real-time captured audio processing such as room reverberation tools and a phase vocoder from the system microphone. The BBC Radiophonic Workshop shows effects used on famous TV shows such as Doctor Who, being simulated inside the browser \cite{bbcradiophonics}. %http://webaudio.prototyping.bbc.co.uk/
b@1981 158 Another example is the BBC R\&D automatic compressor which applies a dynamic range compressor on a radio station which dynamically adjusts the compressor settings to match the listener's environment \cite{mason2015compression}.\\ % The paper for this has not been released yet by AES...
b@1977 159
b@1981 160 This work is based in part on the APE audio perceptual evaluation interface for MATLAB \cite{deman2014b}. An important drawback of this toolbox is the need to have MATLAB to create a test and even to run (barring the use of an executable generated by MATLAB), and limited compatibility with both earlier and newer versions of MATLAB, which makes it hard to maintain. On the other hand, a web application generally has the advantage of running in most browsers on most applications, and we present a tool that requires no specialised software or even programming knowledge to set up.
b@1979 161
b@1984 162 [TO ADD: other interfaces for perceptual evaluation of audio, browser-based or not!] % IMPORTANT
b@1984 163
b@1984 164 We present a browser-based perceptual evaluation tool from which any kind of multiple stimulus audio evaluation tool where subjects need to rank, rate, select, or comment on different audio samples can be built.
b@1984 165 We also include an example of the multiple stimulus user interface included with the APE tool \cite{deman2014b}, which presents the subject with a number of axes on which a number of markers, corresponding with audio samples, can be moved to reflect any subjective quality, as well as corresponding comment boxes.
b@1984 166 However, other graphical user interfaces can be put on top of the engine that we provide with minimal or no modifications. Examples of this are the MUSHRA test \cite{mushra}, single or multiple stimulus evaluation with a two-dimensional interface (such as valence and arousal dimensions), or simple annotation (using free-form text, check boxes, radio buttons or drop-down menus) of one or more audio samples at a time.
b@1984 167 In case of for instance method of adjustment, where the audio is processed by the user \cite{bech}, or of AB test, where the interface does not show all audio samples to be evaluated at once, the back end of the tool needs to be modified as well.
b@1984 168
me@1985 169 There are a number of advantages to building a web audio based listening test environment. The ability to easily deploy a flexible and scalable testing environment that requires no proprietary software to run makes the web audio evaluation tool a very flexible testing tool. The ability to host a single test server and create multiple clients not only allows multiple participants to be involved in a trial simultaneously, but also permits participants to be located anywhere in the world. There are limited user experience issues, as all users should have some experience with using existing web technologies.
b@1979 170
me@1985 171
b@1984 172 [TO ADD: in the following sections, we describe the interface in more detail, discuss the implementation, and go over design considerations and flexibility ... ]
b@1698 173
b@1698 174
b@1981 175 \section{Interface}\label{sec:interface}
b@1698 176
b@1984 177 At this point, we have implemented the interface of the MATLAB-based APE Perceptual Evaluation for Audio toolbox \cite{deman2014b}, which shows one marker for each simultaneously evaluated audio fragment on one or more horizontal axes, that can be moved to rate or rank the respective fragments in terms of any subjective quality, as well as a comment box for every marker, and any extra text boxes for extra comments. See \ref{fig:interface} for an example of the interface, with eleven fragments and one axis. %? change if a new interface is shown
b@1984 178
b@1984 179 However, the back end of this test environment allows for many more established and novel interfaces for listening tests, particularly ones where the subject only assesses audio without manipulating it (i.e. method of adjustment, which would require additional features to be implemented).
b@1641 180
me@1986 181 \begin{figure*}[ht]
b@1979 182 \begin{center}
b@1979 183 \includegraphics[width=0.9\textwidth]{interface.png}
me@1980 184 \caption{Example of interface, with 1 axis and 11 fragments}
b@1979 185 \label{fig:interface}
b@1979 186 \end{center}
b@1979 187 \end{figure*}
me@1986 188
me@1986 189
me@1986 190 ************
me@1986 191
me@1986 192 [DAVE to make new picture] - Apologies but I am having a few troubles being able to get a good looking example of the interface - The text boxes keep rolling out of bounds - and the resolution on my laptop being far from ideal. Can someone else please make a quick mockup test and take a screenshot.
me@1986 193
me@1986 194 ************
b@1641 195
b@1981 196 [BRECHT to expand]
b@1669 197
nickjillings@1700 198
b@1981 199
b@1981 200 \section{Architecture}\label{sec:architecture} % or implementation?
b@1981 201
nickjillings@1679 202 The tool runs entirely inside the browser through the new HTML5 Web Audio API and is supported by most major web browsers (with the exception of Internet Explorer). The API allows for constructing audio processing elements and connecting them together to produce a high quality, real time signal process to manipulate audio streams. The API supports multi-channel processing and has an accurate playback timer for precise scheduled playback control. The API is controlled through the browser JavaScript engine and is therefore highly configurable. Processing is all performed in a separate, low latency thread to the main JavaScript thread, meaning there is no blocking due to real time processing.
nickjillings@1700 203
nickjillings@1700 204 The web tool itself is split into several files to operate:
nickjillings@1700 205 \begin{itemize}
nickjillings@1679 206 \item \texttt{index.html}: The main index file to load the scripts, this is the file the browser must request to load.
nickjillings@1679 207 \item \texttt{core.js}: Contains functions and objects to define the audio objects, audio playback engine and loading media files
b@1669 208 \item \texttt{ape.js}: Parses setup files to create the interface as instructed, following the same style chain as the MATLAB APE Tool \cite{deman2014b}.
nickjillings@1700 209 \end{itemize}
nickjillings@1700 210
nickjillings@1676 211 The HTML file loads the \texttt{core.js} file along with a few other ancillary files (such as the jQuery JavaScript extensions)% should we cite jQuery.... https://jquery.com/
nickjillings@1679 212 , at which point the browser JavaScript begins to execute the on-page instructions, which gives the URL of the test setup XML document (outlined in Section \ref{sec:setupresultsformats}). \texttt{core.js} parses this document and executes the function in \texttt{ape.js} to build the web page with the given audio files. The reason for separating these two files is to allow for further interface designs (such as MUSHRA \cite{mushra} or A-B tests \cite{bech}) to be used, which would still require the same underlying core functions outlined in \texttt{core.js}, see also Section \ref{sec:interface}.
nickjillings@1700 213
nickjillings@1679 214 The \texttt{ape.js} file has several main functions but the most important are \textit{loadInterface(xmlDoc)}, \textit{loadTest(id)}, \textit{pageXMLSave(testId)} and \textit{interfaceXMLSave()}. \textit{loadInterface(xmlDoc)} is called to decode the supplied project document in respect for the interface specified and define any global structures (such as the slider interface). It also identifies the number of pages in the test and randomises the order, if specified to do so. This is the only madatory function in any of the interface files as this is called by \texttt{core.js} when the document is ready. The design style is such that \texttt{core.js} cannot 'see' any interface specific functions and therefore cannot assume any are available. Therefore the \textit{loadInterface(xmlDoc)} is very important to setup the entire test environment. It can be assumed that the interface files can `see' the \texttt{core.js} file and can therefore not only interact with it, but also modify it.
b@1984 215
nickjillings@1679 216 Each test page is loaded using \textit{loadTest(id)} which performs two major tasks: to populate the interface with the slider elements and comment boxes; and secondly to instruct the \textit{audioEngine} to load the audio fragments and construct the backend audio graph. The markers on the slider at the top of the page are positioned randomly, to minimise the bias that may be introduced when the initial positions are near the beginning, end or middle of the slider. While another approach is to place the markers outside of the slider bar at first and have the subject drag them in, the authors believe this doesn't encourage careful consideration and comparison of the different fragments as the implicit goal of the test becomes to audition and drag each fragment in just once, rather than to compare all fragments rigorously.
b@1984 217
b@1984 218 \textit{loadTest(id)} in \texttt{ape.js} also instructs the audio engine in \texttt{core.js} to create the \textit{audioObject} These are custom audio nodes, one representing each audio element specified in each page.
nickjillings@1679 219 They consist of a \textit{bufferSourceNode} (a node which holds a buffer of audio samples for playback) and a \textit{gainNode}. There are various functions applied depending on metric collection which record the interaction with the audio element. These nodes are then connected to the \textit{audioEngine} (itself a custom web audio node) containing a \textit{gainNode} (where the various \textit{audioObject} connect to) for summation before passing the output to the \textit{destinationNode}, a permanent fixed node of the Web Audio API created as the master output where the browser then passes the audio information to the system sound device. % Does this now make sense?
nickjillings@1679 220 % audio object/audioObject/Audio Object: -- should always be audioObject if talking about the JavaScript object, otherwise should say audio element or audio fragment.
b@1984 221
nickjillings@1679 222 When an \textit{audioObject} is created, it is given the URL of the audio sample to load. This is downloaded into the browser asynchronously using the \textit{XMLHttpRequest} object. This downloads any file into the JavaScript environment for further processing which is particularly useful for the Web Audio API because it supports downloading of files in their binary form for decoding. Once downloaded the file is decoded using the Web Audio API offline decoder. This uses the browser available decoding schemes to decode the audio files into raw float32 arrays, which are in turn passed to the relevant \textit{audioObject} for playback.
nickjillings@1679 223
nickjillings@1679 224 Once each page of the test is completed, identified by pressing the Submit button, the \textit{pageXMLSave(testId)} is called to store all of the collected data until all pages of the test are completed. After the final test and any post-test questions are completed, the \textit{interfaceXMLSave()} function is called. This function generates the final XML file for submission as outlined in Section \ref{sec:setupresultsformats}.
nickjillings@1679 225
nickjillings@1679 226 Browsers support various audio file formats and are not consistent in any format. Currently the Web Audio API is best supported in Chrome, Firefox, Opera and Safari. All of these support the use of the uncompressed WAV format. Although not a compact, web friendly format, most transport systems are of a high enough bandwidth this should not be a problem. Ogg Vorbis is another well supported format across the 4 supported major desktop browsers, as well as MP3 (although Firefox may not support all MP3 types) \cite{mozdevSupportedMedia}. %https://developer.mozilla.org/en-US/docs/Web/HTML/Supported_media_formats
nickjillings@1679 227 One issue of the Web Audio API is that the sample rate is assigned by the system sound device, rather than requested and does not have the ability to request a different one. % Does this make sense? The problem is across all audio files.
nickjillings@1679 228 Therefore, the default operation when an audio file is loaded with a different sample rate to that of the system is to convert the sample rate. To provide a check for this, the desired sample rate can be supplied with the setup XML and checked against. If the sample rates do not match, a browser alert window is shown asking for the sample rate to be correctly adjusted.
b@1984 229 As this happens before any loading or decoding of audio files, the system will only fetch files as soon as the system's sample rate meets any requirements, avoiding requests for large files until they are actually needed.
b@1984 230
b@1984 231 %During playback, the playback nodes loop indefinitely until playback is stopped. The gain nodes in the \textit{audioObject}s enable dynamic muting of nodes. When a bar in the sliding ranking is clicked, the audio engine mutes all \textit{audioObject}s and un-mutes the clicked one. Therefore, if the audio samples are perfectly aligned up and of the same sample length, they will remain perfectly aligned with each other.
b@1984 232 % Don't think this is relevant anymore
b@1984 233
b@1984 234 \section{Setup and results formats}\label{sec:setupresultsformats}
b@1984 235
b@1984 236 [DAVE: somewhere add input file]
b@1984 237
me@1986 238 Setup and the results both use the common XML document format to outline the various parameters. The setup file determines which interface to use, the location of audio files, how many pages and other general setup rules to define the testing environment. Having one document to modify allows for quick manipulation in a `human readable' form to create new tests, or adjust current ones, without needing to edit multiple web files. An example of this XML document is presented in Figure~\ref{fig:xmlIn}% I mean the .js and .html files, though not sure if any better.
b@1984 239
me@1986 240 \begin{figure}[ht]
me@1986 241 \begin{center}
me@1986 242 \includegraphics[width=0.5\textwidth]{XMLInput.png}
me@1986 243 \caption{An Example Input XML File}
me@1986 244 \label{fig:xmlIn}
me@1986 245 \end{center}
me@1986 246 \end{figure}
b@1984 247
me@1986 248 The setup document has several defined nodes and structure which are documented with the source code. For example there is a section for general setup options where the pre-test and post-test questions and statements are set up and from the example in Figure~\ref{fig:xmlIn}, it can be seen that a question box should be generated, with the id 'location' and it is mandatory to answer. The question is in the PreTest node meaning it will appear before any testing will begin. When the result for the entire test is shown, then this will appear in the PreTest node of the response with the id 'location' allowing it to be found easily. This outlines the importance of having clear and meaningful ID values. Pre- and post-test dialog boxes allow for comments or questions to be presented before or after the test, to convey listening test instructions, gather information about the subject, listening environment, and overall experience of the test.
b@1984 249
b@1984 250 [BRECHT to say we try to cater to as many audiences as possible, simple yet tweakable]
b@1984 251
b@1984 252 Further options in the setup file are:
b@1984 253
me@1986 254 \begin{itemize} %Should have used a description list for this.
b@1984 255 \item \textbf{Snap to corresponding position}: When this is enabled, and a fragment is playing, the playhead skips to the same position in the next fragment that is clicked. If it is not enabled, every fragment is played from the start.
b@1984 256 \item \textbf{Loop fragments}: Repeat current fragment when end is reached, until the `Stop audio' or `Submit' button is clicked.
b@1984 257 \item \textbf{Comments}: Displays a separate comment box for each fragment in the page.
b@1984 258 \item \textbf{General comment}: One comment box, additional to the individual comment boxes, to comment on the test or a feature that some or all of the fragments share.
b@1984 259 \item \textbf{Resampling}: When this is enabled, tracks are resampled to match the subject's system's sample rate (a default feature of the Web Audio API). When it is not, an error is shown when the system does not match the requested sample rate.
b@1984 260 \item \textbf{Randomise page order}: Randomises the order in which different `pages' are presented. % are we calling this 'pages'?
b@1984 261 \item \textbf{Randomise fragment order}: Randomises the order and numbering of the markers and comment boxes corresponding with the fragments. This permutation is stored as well, to be able to interpret references to the numbers in the comments (such as `this is much [brighter] then 4').
b@1984 262 \item \textbf{Require playback}: Require that each fragment has been played at least once, if not in full.
b@1984 263 \item \textbf{Require full playback}: If `Require playback' is active, require that each fragment has been played in full.
b@1984 264 \item \textbf{Require moving}: Require that each marker is moved (dragged) at least once.
b@1984 265 \item \textbf{Require comments}: This option allows requiring the subject to require a comment for each track.
nickjillings@1679 266 \item \textbf{Repeat test}: Number of times test should be repeated (none by default), to allow familiarisation with the content and experiment, and to investigate consistency of user and variability due to familiarity. In the setup, each 'page' can be given a repeat count. These are all gathered before shuffling the order so repeated tests are not back-to-back if possible.
b@1984 267 \item \textbf{Returning to previous pages}: Indicates whether it is possible to go back to a previous `page' in the test.
b@1984 268 \item \textbf{Lowest rating below [value]}: To enforce a certain use of the rating scale, it can be required to rate at least one sample below a specified value.
b@1984 269 \item \textbf{Highest rating above [value]}: To enforce a certain use of the rating scale, it can be required to rate at least one sample above a specified value.
b@1984 270 \item \textbf{Reference}: Allows for a separate sample (outside of the axis) to be the `reference', which the subject can play back during the test to help with the task at hand \cite{mushra}.
b@1984 271 \item \textbf{Hidden reference}: Whether or not an explicit `reference' is provided, the `hidden reference' should be rated above a certain value \cite{mushra} - this can be enforced.
b@1984 272 \item \textbf{Hidden anchor}: The `hidden anchor' should be rated lower than a certain value \cite{mushra} - this can be enforced.
b@1984 273
b@1984 274 \end{itemize}
b@1984 275
b@1984 276 When one of these options is not included in the setup file, they assume a default value.
b@1984 277
b@1984 278 % loop, snap to corresponding position, comments, 'general' comment, require same sampling rate, different types of randomisation
b@1984 279
me@1986 280 The results file is dynamically generated by the interface upon clicking the `Submit' button. This also executes checks, depending on the setup file, to ensure that all tracks have been played back, rated and commented on. The XML output returned contains a node per audioObject and contains both the corresponding marker's position and any comments written in the associated comment box. The rating returned is normalised to be a value between 0 and 1, normalising the pixel representation of different browser windows. An example output file is presented in Figure~\ref{fig:xmlOut}
me@1986 281
me@1986 282 \begin{figure}[ht]
me@1986 283 \begin{center}
me@1986 284 \includegraphics[width=0.5\textwidth]{XMLOutput.png}
me@1986 285 \caption{An Example Output XML File}
me@1986 286 \label{fig:xmlOut}
me@1986 287 \end{center}
me@1986 288 \end{figure}
b@1984 289
b@1984 290 The results will also contain information collected by any defined pre/post questions. These are referenced against the setup XML by using the same ID so readable responses can be obtained. Taking from the earlier example of setting up a pre-test question, an example reponse would be shown as the following.
b@1984 291
b@1984 292 \texttt{<comment id="location"> Queen Mary \\University of London </comment>}
b@1984 293
b@1984 294 Each page of testing is returned with the results of the entire page included in the structure. One `audioElement' node is created per audio fragment per page, along with its ID. This includes several child nodes including the value holding the rating between 0 and 1, and any metrics collected. These include how long the element was listened for, the initial position, boolean flags if the element was listened to, if the element was moved and if the element comment box had any comment. Furthermore, each user action (manipulation of any interface element, such as playback or moving a marker) is logged along with a the corresponding time code and stored or sent along with the results.
b@1984 295
b@1984 296 Future development will also evolve to include any session data, such as the browser the tool was used in. Currently the results files are downloaded on the user side of the browser as a .xml file to be manually returned. However the end goal is to allow the XML files to be submitted over the web to a receiving server to store them, allowing for automated collection.
b@1984 297
me@1986 298 *********************
me@1986 299
me@1986 300 Do we want to discuss this in the future of present tense - as it will be a working feature by the time we are published (July at the earliest?) So this can be present tense - as in 'this work has already been done' or should this go into further work?
me@1986 301
me@1986 302 *********************
me@1986 303
b@1984 304 % right?
b@1984 305
b@1984 306 %Here is an example of the setup XML and the results XML: % perhaps best to refer to each XML after each section (setup <> results)
b@1984 307 % Should we include an Example of the input and output XML structure?? --> Sure.
b@1984 308
me@1986 309 %An example of the returned \textit{audioElement} node in the results XML file is as follows.
me@1986 310 %
me@1986 311 %\texttt{<audioelement id="8"> \\
me@1986 312 %<comment> \\
me@1986 313 %<question>Comment on track 0</question> \\
me@1986 314 %<response> The drums were punchy </response> \\
me@1986 315 %</comment> \\
me@1986 316 %<value> 0.25169491525423726 </value> \\
me@1986 317 %<metric> \\
me@1986 318 %<metricresult id="elementTimer"> \\ 2.3278004535147385< /metricresult> \\
me@1986 319 %<metricresult id="elementTrackerFull"> \\
me@1986 320 %<timepos id="0"> \\
me@1986 321 %<time>1.7937414965986385</time> \\
me@1986 322 %<position>0.41694915254237286</position> \\
me@1986 323 %</timepos> \\
me@1986 324 %<timepos id="1"> \\
me@1986 325 %<time>2.6993197278911563</time> \\
me@1986 326 %<position>0.45847457627118643</position> \\
me@1986 327 %</timepos> \\</metricresult> \\
me@1986 328 %<metricresult id="elementInitialPosition"> 0.47796610169491527 </metricresult> \\
me@1986 329 %<metricresult id="elementFlagListenedTo"> true< /metricresult> \\
me@1986 330 %<metricresult id="elementFlagMoved"> true </metricresult> \\
me@1986 331 %</metric> \\
me@1986 332 %</audioelement>}
b@1984 333
me@1986 334 As can be seen from Figure~\ref{fig:xmlOut}, the parent tag \texttt{audioelement} holds the id of the element passed in from the setup document. The first child element is \texttt{comment} and holds both the question shown and the response from the comment box inside.
b@1984 335 The child element \texttt{value} holds the normalised ranking value. Next comes the metric node structure, there is one \texttt{metricresult} node per metric event collected. The id of the node identifies the type of data it contains. For example, the first holds the id \textit{elementTimer} and the data contained represents how long, in seconds, the audio element was listened to. The next holds the id \textit{elementTrackerFull} and contains a pair of elements per entry. This represents the entire movement of the elements' slider giving the time the event took place in seconds from when the current test page started, and the new position. In our example there are three \texttt{timepos} children with their id representing their order. There is one of these \texttt{audioelement} tags per audio element outlined on each test page.
b@1984 336
b@1984 337 \section{Conclusions and future work}\label{sec:conclusions}
b@1984 338
b@1984 339 In this paper we have presented an approach to creating a browser-based listening test environment that can be used for a variety of types of perceptual evaluation of audio.
b@1984 340 Specifically, we discussed the use of the toolbox in the context of assessment of preference for different production practices, with identical source material.
b@1984 341 The purpose of this paper is to outline the design of this tool, to describe our implementation using basic HTML5 functionality, and to discuss design challenges and limitations of our approach. % or something
b@1984 342
b@1984 343 % future work
b@1984 344 Further work may include the development of other common test designs, such as MUSHRA \cite{mushra}, AB, ABX and method of adjustment tests.
b@1984 345 In addition, [...].
b@1984 346 [BRECHT to correct and expand]
b@1984 347
b@1984 348 from community
b@1984 349
b@1984 350 %\begin{itemize}
b@1984 351 %\item Options for MUSHRA style experiment with vertical slide per track
b@1984 352 %\item APE style experiment where all tracks are on a single horizontal axis % isn't that what we're doing now?
b@1984 353 %\item AB test
b@1984 354 %\item ABX test
b@1984 355 %\item Method of adjustment tests
b@1984 356 %\end{itemize}
b@1984 357
b@1984 358
b@1984 359 The source code of this tool can be found on \url{code.soundsoftware.ac.uk/projects/webaudioevaluationtool}.
b@1984 360
b@1984 361
b@1984 362 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
b@1984 363 %bibliography here
b@1984 364 \bibliography{smc2015template}
b@1984 365
b@1984 366
b@1984 367
b@1984 368 \end{document}
b@1984 369
b@1984 370
b@1984 371
b@1984 372 % RUBBISH
b@1984 373
b@1984 374 %\subsection{Equations}
b@1984 375 %Equations of importance,
b@1984 376 %or to which you refer later,
b@1984 377 %should be placed on separated lines and numbered.
b@1984 378 %The number should be on the right side, in parentheses.
b@1984 379 %\begin{equation}
b@1984 380 %E=mc^{2+\delta}.
b@1984 381 %\label{eq:Emc2}
b@1984 382 %\end{equation}
b@1984 383 %Refer to equations like so:
b@1984 384 %As (\ref{eq:Emc2}) shows,
b@1984 385 %I do not completely trust Special Relativity.
b@1984 386 %
b@1984 387 %\subsection{Figures, Tables and Captions}
b@1984 388 %\begin{table}[t]
b@1984 389 % \begin{center}
b@1984 390 % \begin{tabular}{|l|l|}
b@1984 391 % \hline
b@1984 392 % String value & Numeric value \\
b@1984 393 % \hline
b@1984 394 % Hej SMC & 2015 \\
b@1984 395 % \hline
b@1984 396 % \end{tabular}
b@1984 397 %\end{center}
b@1984 398 % \caption{Table captions should be placed below the table, exactly like this,
b@1984 399 % but using words different from these.}
b@1984 400 % \label{tab:example}
b@1984 401 %\end{table}
b@1984 402
b@1984 403 %\begin{figure}[t]
b@1984 404 %\figbox{
b@1984 405 %\subfloat[][]{\includegraphics[width=60mm]{figure}\label{fig:subfigex_a}}\\
b@1984 406 %\subfloat[][]{\includegraphics[width=80mm]{figure}\label{fig:subfigex_b}}
b@1984 407 %}
b@1984 408 %\caption{Here's an example using the subfig package.\label{fig:subfigex} }
b@1984 409 %\end{figure}
b@1984 410
b@1984 411
b@1984 412
b@1984 413
b@1984 414
b@1984 415 %\begin{acknowledgments}
b@1984 416 %You may acknowledge people, projects,
b@1984 417 %funding agencies, etc.
b@1984 418 %which can be included after the second-level heading
b@1984 419 %``Acknowledgments'' (with no numbering).
b@1984 420 %\end{acknowledgments}
b@1984 421