comparison docs/SMC15/smc2015template.tex @ 1672:b572136b9ac1

Remove some redundancies from paper

 \usepackage{smc2015}
 \usepackage{times}
 \usepackage{ifpdf}
 \usepackage[english]{babel}
 \usepackage{cite}
+
+\hyphenation{Java-script}
 
 %%%%%%%%%%%%%%%%%%%%%%%% Some useful packages %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 %%%%%%%%%%%%%%%%%%%%%%%% See related documentation %%%%%%%%%%%%%%%%%%%%%%%%%%
 %\usepackage{amsmath} % popular packages from Am. Math. Soc. Please use the 
 %\usepackage{amssymb} % related math environments (split, subequation, cases,

 \end{abstract}
 %
 
 \section{Introduction}\label{sec:introduction}
 
-tiny mock change
-
 TOTAL PAPER: Minimum 4 pages, 6 preferred, max. 8 (6 for demos/posters)\\ 
 
 NICK: examples of what kind of audio applications HTML5 has made possible, with references to publications (or website)\\
 
 background (types of research where this type of perceptual evaluation of audio is relevant)\\

 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.
 
 
 \subsection{Setup and results formats}\label{sec:setupresultsformats}
 
-[somewhere: check all fragments are played]
-
-Setup and the results both use the common XML document format to outline the various parameters. The setup file contains all the information needed to initialise a test session. Several Nodes % capital letter? 
- can be defined to outline the audio samples to use, questions to be asked and any pre- or post-test questions or instructions. 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 which web files. % 'which web files'?
-
-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 100, normalising the pixel representation of different browser windows. 
+Setup and the results both use the common XML document format to outline the various parameters. The setup file contains all the information needed to initialise a test session. Several nodes can be defined to outline the audio samples to use, questions to be asked and any pre- or post-test questions or instructions. 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 which web files. % 'which web files'?
+
+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. 
 
 Pre- and post-test dialog boxes allow for comments or questions to be presented before or after the test, to convey listening test instructions, and gather information about the subject, listening environment, and overall experience of the test. These are automatically generated from the setup XML and allow nearly any form of question and comment to be included in a window on its own. Questions are stored and presented in the response section labelled `pretest' and `posttest', along with the question ID and its response, and can be made mandatory. 
 Further options in the setup file are: 
 
 \begin{itemize}

 \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'). 
 \item \textbf{Require playback}: Require that each fragment has been played at least once, if not in full. 
 \item \textbf{Require full playback}: If `Require playback' is active, require that each fragment has been played in full. 
 \item \textbf{Require moving}: Require that each marker is moved (dragged) at least once. 
 \item \textbf{Require comments}: This option allows requiring the subject to require a comment for each track. 
+\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.
 % explanation on how this is implemented? 
 \end{itemize}
 
 When one of these options is not included in the setup file, they assume a default value. 
 

 
 
 
 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 as well as printing in the same question, so readable responses can be obtained. Future development will also evolve to include any session data, such as the browser the tool was used in, how long the test took and any other metrics. 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.
 
-Furthermore, each user action (manipulation of any interface element, such as playback, moving a marker, or typing a comment) is logged along with a the corresponding time code and stored or sent along with the results. % right? 
+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. % right? 
 
 %Here is an example of the setup XML and the results XML: % perhaps best to refer to each XML after each section (setup <> results)
 % Should we include an Example of the input and output XML structure?? --> Sure. 
 
 ADD XML STRUCTURE EXAMPLE
-
-\section{Applications}\label{sec:applications} %?
-discussion of use of this toolbox (possibly based on a quick mock test using my research data, to be repeated with a large number of participants and more data later)\\
-
-\subsection{Listening environment standardisation}
-
-In order to reduce the impact of having a non-standardised listening environment and unobservable participants, a series of pre-test standard questions have been put together to ask every participant. The first part of this is that every participant is asked to carry out the test, wherever possible, with a pair of quality headphones.
-
-% I think the following should be different for every type of test, so I think it looks better to say any type of question (with text box, or radio buttons, or dropdown menu?) is possible to add. 
-%\begin{itemize}
-%\item Name (text box)
-%%\item I am happy for name to be used in an academic publication (check box) % never really necessary, as far as I'm concerned
-%\item First language (text box)
-%\item Location: country, city (text box)
-%\item Playback system (ratio box: headphone or speaker)
-%\item Make and Model of Playback System (text box)
-%\item Listening environment (text box)
-%%\item Please assess how good you believe your hearing to be, where 1 is deaf, 10 is professional critical listener (Dropdown box 1-10 ) % not sure
-%\end{itemize}
-
-
-There are also a series of considerations that have been made towards ensuring there is a standardised listening environment, so it is possible to
-\begin{itemize}
-\item Begin with standardised listening test - to confirm listening experience
-\item Perform loudness equalisation on all tracks 
-\\** OR THIS SHOULD BE DONE BEFORE THE EXPERIMENT
-\item Randomise order of tests
-\item Randomise order of tracks in each test
-\item Repeat each experiment a number of times 
-\\** TO REMOVE THE FAMILIARISATION WITH EXPERIMENT VARIABLE 
-\\** TO ENSURE CONSISTENCY OF USER
-\item Track all user interactions with system
-\end{itemize}
-
-
-
-[Regarding randomisation: keep the randomisation 'vector' so you can keep track of what subjects are referring to in comment fields]
 
 
 \section{Conclusions and future work}\label{sec:conclusions}
 
 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. 

 %\item ABX test
 %\item Method of adjustment tests
 %\end{itemize}
 
 
-The source code of this tool can be found on \url{code.soundsoftware.ac.uk/projects/webaudioevaluationtool}. % FIX
+The source code of this tool can be found on \url{code.soundsoftware.ac.uk/projects/webaudioevaluationtool}. The repository includes an issue tracker, where bug reports and feature requests can inform further development. 
 
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 %bibliography here
 \bibliography{smc2015template}