dataesr/scientific-paragraphs-categorization huggingface dataset:
In 2017  [26] , MLSA vocoder parameters were obtained from surface electromyographic (sEMG) signals, where a predicted F0 activation gave improved intelligibility compared to white noise input. In a 2019 experiment  [27] , ECoG brain implant signals recorded during speech were used to predict spectral quantities transformed into speech with an MLSA vocoder, producing short sentences with, in some cases, encouraging similarity to ground truth sentences. Concerning lip reading, most recent experiments have made use of the GRID corpus  [28] , which constructs simply structured sentences from a limited set of words. In  [29] , syntheses performed using the STRAIGHT vocoder  [30]  with a noise activation gave about 50% word accuracy in listening tests. Increased performance on the same dataset, about 80%, was reported in  [31]  using CNN to produce features from lip images, and a noise-activated source/filter model.
III. DATASETS AND PRE-PROCESSING The dataset used consisted of 5 traditional Latin and Corsican songs of 2 to 5 minutes each, for a total duration of 19 minutes  [40]. The data were acquired as part of the i-Treasures project  [41]  that proposed new technologies for conserving intangible cultural heritage, such as rare singing styles. Singers were instrumented with a special helmet including, besides a standard microphone: an ultrasound probe beneath the chin to record tongue movement; a camera before the mouth to capture lip movement; an electroglottograph at the neck sensitive to glottal activity; accelerometers at the bridge of the nose to measure nasality; as well as a special belt on the torso to log the respiration rate. In addition to archiving this rare cultural heritage, the data recorded by i-Treasures sensors are useful for creating models of articulation in different singing styles  [42] , and have also served as input to the i-Treasures Text-to-Song synthesis platform  [41].
The DAE learns the high-level representations from raw pixels. A classification approach in which the LSF values are first binned into 100 discrete levels was found to give superior performance compared to predicting LSF values directly. In the case of F0 and U/V, the Encoder and Predictor in with regression output and binary classification output, respectively, are used for training to gain better performance. Training was done using Tensorflow in Python. In Convolutional and Pooling layers, parameters are listed in the form of: channels @ kernel × kernel. By default, activation function and strides are set to RELU and 1, respectively. Denoising dropout is set to 0. 2. Here we use Batchnorm and Dropout techniques together because of the limited small dataset and the difficult learning task.
In train mode, we use Adam optimizer  [44]  with learning rate 1e-4, Glorot Uniform  [45]  weights initialization, batch size 512 for LSF, F0 and U/V predictions. LSF prediction uses weighted sum of MSE loss on reconstructed lips and tongues (the weights is 1e-2 for both lips and tongues) and cross entropy loss on discrete LSF levels (the weights is 1 for each LSF coefficient). Then it is trained with 50 epochs. F0 and U/V predictions use MSE loss and cross entropy loss, respectively. Both F0 and U/V are trained with early stopping on a 5% validation dataset to avoid overfitting. More details can be found at: https://github. com/TjuJianyu/SSI_DL.
2) CNN RESULTS The performance results for prediction of the LSF, F0, and U/V flag are given in Table  1. Performance of the LSF prediction is measured in dB of Spectral Distortion, defined as the root mean square of the FIGURE 3. Real and predicted F0 versus frame number. Unvoiced frames, where F0 is not defined, do not appear in the plot. differences in dB, at a fixed set of frequencies, between the LPC polynomials derived from the original and the learned LSF values  [14]. In the LSF entry of Table  1 , a comparison is made between the present work and  [11] , where DAE features were selected manually for saliency before being used to train a multilayer perceptron (MLP). The train and test datasets and pre-processing procedure used in  [11]  and this work were identical. An improvement of 0.
The activation functions are RELU except the last layer with a linear activation function. In train mode, we use Adam optimizer with learning rate 1e-4, batch size 512, Glorot Uniform weights initialization, and 5000 epochs to train the neural network. More details of the neural network and the training process can be found at: https://github. com/TjuJianyu/SSI_DL. In test mode, the predicted LSF, F0, and U/V flags are used to create the raw waveform. Signal phase at this point is of course unknown, but is not relevant perceptually, as long as phase continuity is assured at frame boundaries.
Both adversarial loss and distortion loss can be applied based on different definitions of salience. As mentioned in section II, however, we prefer not to test generative architectures at this point. These techniques require very big datasets and significant parameter tuning to use. Based on the small  silent speech dataset, WaveNet for example could not be well trained and thus we do not compare with it in this project. Figure  5  shows the comparison of CNN vocoder, MELP-MLSA, MELP-LPC and ground truth on four frames. In unvoiced frames (e. g. Frame No. 500), the methods are almost identical, while in voiced frames, the CNN vocoder waveform appears to most nearly resemble ground truth, on phones /a:/ in Frame No. 2500 and No. 3000, and /i:/ in Frame No. 4000. We note that the predicted waveforms' glottal pulses, being derived from predicted F0, should not be expected to align perfectly with ground truth.
Acknowledgements The author wants to thank his collaborators  Pierre Degond ,  Sara Merino-Aceituno ,  Ariane Trescases  and  Antoine Diez  for all the work done together on body-attitude coordination models [ DFMA17 , DFMAT18 , DFMAT19 , DDFMA20 , Die20 ], which inspired the talk given at [ !NδA ] in November 2019, and finally led to the present paper. This work has been supported by the Project  EFI ANR-17-CE40-0030  of the.
Autonomous Driving (AD) systems are heavily reliant on supervised models. In these approaches, a model is trained to detect only a predefined number of obstacles. However, for applications like railway obstacle detection, the training dataset is limited and not all possible obstacle classes are known beforehand. For such safety-critical applications, this situation is problematic and could limit the performance of obstacle detection in autonomous trains. In this paper, we propose an exploratory study using unsupervised models based on a large set of generated convolutional autoencoder models to detect obstacles on railway's track level. The study was conducted based on three components: loss functions, activations and optimizers. Existing works rely on fixing thresholds to judge the performance of the model.
This choice is driven by three factors: First, as aforementioned, a scarcity of works exploiting unsupervised methods in railway obstacle detection is noticeable with the only exception of the recently published  [8]. Second, the use of supervised methods requires previous knowledge about the obstacles, hence enumerating all possible obstacles that we may encounter and labeling them to create classes which is nearly impossible in a real-life scenario. Third, to the best of the authors knowledge, railway-oriented datasets describing real-world obstacles are few to non-existent, but on the other hand, normal data without obstacles are available. We propose in this paper an exploratory study using convolutional autoencoder to discriminate, at frame level, between normal and anomalous images using reconstruction score.
The training process was conducted using a subset of RailSem19  [11]  consisting of Regions of Interest (RoI) of track levels. In order to rank all the models on gap-scores, we use a testing dataset consisting of normal images and the same images with obstacles. Lastly the evaluation process of the 240 generated models was conducted using the Technique for Order of Preference by Similarity to Ideal Solution (TOPSIS)  [12]  an MCDM algorithm. The used criteria are the average gap-score on all normal images and the number of positive gap-scores for each normal image. By doing so, we avoid relying on arbitrary thresholds to judge an input whether it is anomalous or not. The best resulting model was tested on a real world scenario describing a real obstacle with convincing results where the gap-score is considerably high on frames where the obstacle is present and considerably low on normal ones as described in section VI.
Moreover the specific use of unsupervised learning methods is still unexploited for railway obstacle detection. The closest work to the work we present here is a recently published in  [8]. In this paper, the author propose a framework to detect obstacles in night-time using a convolutional autoencoder by producing absolute and gradient differences of the reconstructed image. The framework is consisting of a convolutional autoencoder, a CNN to predict on the frame level whether the image is anomalous or not. The CNN is also used to extract the corresponding heatmap to locate the anomaly. They use a pre-trained CNN on their own dataset entitled vesuvio  [8]  to predict the classes and evaluate the localisation of the obstacles. An initial version of the same work by the same authors can be found in  [9].
B. Respected Criteria We denote by background image the normal image without obstacles. We also denote by inlaid image the same normal image with inlaid obstacles. Let X = {x 1 , x 2 , x 3 ,. , x n } be the dataset of background images containing N images and X = {x 1,1 , x1,2 , x2,1 , x2,2 ,. , xn,m } the dataset of inlaid images containing M images with M ≥ N. Each background image x i can have at least one or many inlaid counterparts x i,1 , x i,2. x i,m. A good model is a model that maximizes the following two criteria: • For every background image and its generated inlaid counterparts, the model should maximize the average of the the gap-score between every inlaid image and its original background: s i = d(x i , x ′ i ), ∀x i ∈ X (2) s i,j = d( x i,j , x ′ i,j ), ∀x i ∈ X, ∀x j ∈ X (3) C 1 = 1 N n i=1 m j=1 s i,j -s i s i (4) Where x i and x ′ i are respectively a normal image and its reconstruction by a given convolutional autoencoder model using a unique metric d.
For each layer of the decoder part, we use Upsampling instead of transposed convolution and filters ranging from 128 to 32 with kernels of size 3x3 (figure architecture). The aim of this part is to get the adequate architecture depending on the used training dataset to initiate our exploratory study. Using the same architecture, we generate each time a model following a combination of the aforementioned components of our exploratory study. In terms of the activation functions' hyperparamters, MSE  [26] , MAE  [26]  and PSNR  [27]  are without parameters. Only SSIM  [28]  and MS-SIM  [28]  are concerned. We set their parameters to the default parameters recommended in their original papers. Every activation function is paired with uniform glorot initialization  [40]  except for selu  [35] , which is paired with normal lecun initialization  [35].
B. Training Dataset The used dataset in training the convolutional autoencoders is a subset of RailSem19  [11]  where rail tracks are extracted as regions of interest. The original dataset is processed beforehand where we omit unexploitable and tramway scene images leaving only the railway images. Then, we generate the corresponding masks for each region of interest by connecting the polygons in the corresponding json file for each image scene instead of working with the corresponding predefined masks of each image. By doing so, we can individually extract each rail track present on the scene. By applying the extracted mask for each scene, we generate a dataset consisting only of regions of interest. Each region is then cropped and resized to a resolution of 256x256 pixels. Figure  2  shows a preview of the extracted dataset.
C. Test Dataset In order to calculate the gap-score and due to the lack of a railway-driven dataset describing real world obstacles over rails, we generate our test dataset using Gaussian-Poisson Fig. 2. Preview of our dataset of RoIs using RailSem19  [11]. Generative Adversarial Network (GP-GAN)  [10]  which is a generative model capable of blending images with highresolution and generating realistic blends to inlay obstacles synthetically on RailSem19  [11]  images. The dataset consists of 19 background images where no obstacle is inlaid, this represent our reference in order to calculate the gap-score. Then for each background, we inlay on it obstacles by means of GP-GAN  [10]  in order to create inlaid counterparts. Each background have an average of 10 inlaid counterparts. The resulting dataset consists of 19 regions of interest for the background and 181 regions of interests for the inlaid counterparts.
With regard to Gap-scores, all models have scores ranging from 52. 97% to 68. 17%. In terms of average positive scores of the test dataset, none of the 240 generated models reaches a perfect score of 19 positive backgrounds with the maximum reached is 18 of 19. The corresponding weights of TOPSIS  [12]  method are of equal importance for both criteria i. e w 1 = 0. 5, w 2 = 0. 5. With that, the method tries to find the best models that respect an equal trade-off between maximized gapscores and positive scores respectively. Finally we observed a variety of activation functions for every model such as mila  [38] , relu  [33] , mish  [36] , elu  [34] , selu  [35]  and tanh  [32]. However, for the second table II, by giving much importance to positive scores, i. e w 1 = 0. 1, w 2 = 0. 9, we observe the emergence of new models having different combinations such as the pairing of RAdam  [29]  with MS-SSIM  [28]  and swish  [37] , the pairing of RAdam  [29]  with SSIM  [28]  and as well as the pairing of Novograd  [31]  and MSE  [26].
A major spur to progress has been the development of high-speed I/O frameworks (e. g. , DPDK  [1] , PF RING ZC  [2] , and netmap  [3] ) that employ acceleration techniques, like kernel-bypassing, polling, buffer pre-allocation, and batch processing, to achieve performance comparable to that of proprietary hardware appliances. Furthermore, modern COTS servers are equipped with multiple cores to promote parallelization and Non-Uniform Memory Access (NUMA) awareness to enhance memory access efficiency. Software switches have largely benefited from the combined use of these acceleration techniques. They are thus widely employed by NFV platforms as their data plane to flexibly steer traffic through various components. For example, Metron  [4] , SplitBox  [5] , and MiddleClick  [6]  incorporate FastClick  [7]  for traffic steering.
Our methodology aims to provide a fair comparison of a broad range of state-of-the-art software switches in a set of representative yet straightforward test scenarios. Such a methodology must take into account the different design choices that guided the switch designs. For instance, Open vSwitch (OVS)  [22]  was tailored to support match/action semantics; VPP was constructed as a full-fledged software router; while other solutions such as Snabb, FastClick, and BESS embraced modular design to compose complex network services. The contribution of our work is summarized as follows: • We propose an experimental methodology to thoroughly evaluate the performance of software switches in the context of NFV. • We apply our methodology to compare the performance of 7 state-of-the-art software switches, namely Open vSwitch DPDK (OVS-DPDK)  [10] , FastClick  [7] , Berkeley Extensible Software Switch (BESS)  [13] , VALE  [16, 23] , Snabb  [21] , t4p4s  [24, 25] , and FD.
Since the Linux kernel stack imposes non-negligible overhead for both VM and container networking  [36, 37] , we further incorporate a set of VNF I/O techniques (e. g. , vhost-user backend, virtiouser frontend, netmap's ptnet/veth) for different virtualized environments. To facilitate reproducibility, all the scripts and instructions of our experiments have been released on GitHub  [38]. We strongly encourage researchers and developers to use them to repeat the same set of experiments on their servers and to build on this basis to gain further understanding. The paper is organized as follows. In Sec. 2, we review related literature on software switches and their performance comparison. Then, in Sec. 3, we explore the design space of the 7 considered software switches and highlight their specificities.
We highlight in bold the software switches relevant to our comparison study, as explained in Sec. 2. 1. 2. "Bare-metal" refers to the case of configuring software switches to forward packets between two physical NICs, "Inter-VNF forwarding" refers to traffic forwarding between two VNFs. "SFC" refers to the service function chaining scenario with a varied number of sequential VNFs, "Uni. " refers to unidirectional throughput test, "Bi. " refers to bidirectional throughput test. ( ) Only OVS (and not OVS-DPDK) was evaluated with containerized VNFs in  [71]. Ref. Software switches under test Bare-metal VNF environment Inter-VNF SFC Throughput Latency VM Container forwarding Uni. Bi. [34] BESS  [71]  OVS, OVS-DPDK ( )  [72]  Linux bridge, VALE  [73]  ClickOS, BESS  [19]  Linux bridge, OVS, OVS-DPDK  [25]  OVS, PISCES, t4p4s  [74, 75]  OVS-DPDK, VPP  [18]  BESS, VPP, OVS-DPDK  [76]  OVS-DPDK, Snabb, VALE  [21]  Snabb, OVS, OVS-DPDK, Linux bridge  [77, 30]  OVS Some prior performance comparison works are particularly relevant to ours.
Furthermore, in our comparison, all VMs were based on the KVM hypervisor, avoiding the uncertainty arising when one system uses KVM and the other Xen. Besides, none of the aforementioned works considered the throughput test with bidirectional traffic, which, based on private communication with Cisco engineers, is another critical factor. Therefore, we evaluate the throughput of software switches with both unidirectional and bidirectional traffic. In general, our work provides a more comprehensive performance comparison for software switches in NFV. As highlighted in Table  1 , our work considers a more complete set of state-of-the-art software switches and compares them in more test scenarios with different virtualization techniques and performance metrics. In contrast to the existing literature, in addition to providing measurement results, our work seeks to define a comparison methodology.
Software Switch Settings For each tested software switch, we used the latest functional version/commit available at the time of writing, namely: FastClick (commit 9d5e9c6); BESS ("Haswell" archive, specifically built for Haswell CPU architecture); OVS-DPDK (version 2. 11. 90); Snabb (commit 24c9a67); VALE (netmap commit 42270fc); t4p4s (commit b1161b2); and VPP (version 19. 04). Moreover, as detailed in  [18] , each software switch requires a specialized parameter setting to render the optimal performance with different input traffic and application contexts. However, given the huge number of system and application parameters ranging from GRUB settings to internal packet buffer sizes, it is impossible to exhaustively test and find the most suitable set of values for all the test scenarios.
For other switches, we run pktgen-DPDK in the first VM/container as a traffic generator and FloWatcher-DPDK on the second VM/container to measure unidirectional throughput. To generate bidirectional traffic, we deploy an instance of pktgen-DPDK in each VM/container to transmit packets at maximum rate and measure the aggregated throughput, for software switches other than VALE. For the VALE switch, we instead need two pkt-gen instances in each VM/container to transmit and receive simultaneously. Similar to the p2v bidirectional test, for VM deployment, we attach both pkt-gen instances in each VM to a netmap virtual interface, which is attached to the ptnet virtual interface through a VALE instance. For the container deployment, we directly attach both pkt-gen instances to the veth interface in each container.
Loopback scenario -We instantiate a chain of VNFs, with four cores and a pair of virtual interfaces allocated to each VNF. Each software switch transfers traffic across the VNFs in sequence, forming a linear service chain. By default, a single instance of each VNF is deployed in a VM or container. Fig. 3-(d ) illustrates the setup. For VALE, we configure two ptnet virtual interfaces for each VM in which we run a VALE instance as a VNF. This VALE instance cross-connects the pair of ptnet ports. Each VM is linked to its successor through a VALE instance. The first and last VM also need to link the physical ports with two additional VALE instances. Similarly, for container configuration, two pairs of veth interfaces are created, each of which has one end attached to VALE and the other end attached to a container hosting a new VALE instance as VNF.
In all, we need (N + 1) VALE instances for a service chain of N VNFs. For the other software switches, we configure two virtio interfaces with vhost-user backend for each VM, in which we run an instance of the DPDK testpmd sample application that cross-connects interfaces and updates the destination MAC addresses. On NUMA node 1, we start MoonGen to generate 10 Gbps traffic through one port and measure throughput for different packet sizes from the other port. For bidirectional traffic, MoonGen is configured to generate 10 Gbps traffic from both its physical ports and to measure the aggregated throughput. The software switch is configured to transfer packets between MoonGen and the service chain. We vary the number of VNFs from 1 to 5 to test the throughput of each switch with increasing service chain length.
For bidirectional traffic, as illustrated in Figs. 7-(b ), (d) and (f), all the tested software switches present decreasing throughput as the service chain length grows, as for the unidirectional traffic case. In particular, VALE experiences significant perfor-mance degradation, especially for 64B and 256B traffic. For 1024B traffic, its performance begins to drop when the service chain length is greater than 2. This is mainly due to the doubled packet copying overhead between the neighboring ports of sequential VALE instances. In general, all the switches follow the same trend as the VM case and their throughput decreases as the chain length grows due to the accumulating processing and forwarding overhead. In particular, VALE fails to achieve the same efficiency as in the VM case and is outperformed by other switches in most cases.
This result demonstrates that veth, though it works in a zero-copy manner, is not as efficient as ptnet on service chains. As VALE achieved similar throughput with veth and ptnet interfaces in the p2v and v2v scenarios, we speculate that the bottleneck comes from the VALE instance inside each container since interconnecting two veth interfaces imposes non-negligible switching overhead. All the other switches achieve comparable throughput to that in their corresponding VM scenario. Thus, we conclude that most of the software switches considered in our study can achieve similar throughput networking VNFs inside either QEMU-based VMs or Docker containers.
In the interest of reproducibility, the paper describes the experimental setup in detail, including specifications of tested software and hardware versions and the packet generation and monitoring tools used. In our evaluation, all the VNFs are hosted in two most popular virtualized environments, namely virtual machines (QEMU/KVM) and containers (Docker). The measurement results reveal that no single switch prevails in all scenarios. Such a result was expected, given the different design objectives of the considered software switches, but is a useful reminder that the best switch choice depends significantly on the intended NFV context. The presented results and related discussion enable a more informed choice and should guide the design of potential enhancements to relieve identified bottlenecks.