First-Shot Unsupervised Anomalous Sound Detection for Machine Condition Monitoring

Coordinators

 Kota Dohi Hitachi, Ltd. Keisuke Imoto Doshisha University Yuma Koizumi Google, Inc. Noboru Harada Daisuke Niizumi Tomoya Nishida Hitachi, Ltd. Harsh Purohit Hitachi, Ltd. Ryo Tanabe Hitachi, Ltd. Takashi Endo Hitachi, Ltd. Yohei Kawaguchi Hitachi, Ltd.
Due to errors, the test data in the development dataset for fan, gearbox, bearing, slide rail, and valve have been updated in March 29th. If you have downloaded the development dataset before March 29th, please download the dataset again and replace the test data with the new version.
Development dataset (2.2 GB)
version 1.0

Description

Anomalous sound detection (ASD) is the task of identifying whether the sound emitted from a target machine is normal or anomalous. Automatic detection of mechanical failure is an essential technology in the fourth industrial revolution, which involves artificial-intelligence-based factory automation. Prompt detection of machine anomalies by observing sounds is useful for monitoring the condition of machines. Figure 1 shows an overview of the detection system.

This task is the follow-up from DCASE 2020 Task 2 to DCASE 2022 Task 2. The task this year is to develop an ASD system that meets the following four requirements.

1. Train a model using only normal sound (unsupervised learning scenario)
Because anomalies rarely occur and are highly diverse in real-world factories, it can be difficult to collect exhaustive patterns of anomalous sounds. Therefore, the system must detect unknown types of anomalous sounds that are not provided in the training data. This is the same requirement as in the previous tasks.

2. Detect anomalies regardless of domain shifts (domain generalization task)
In real-world cases, the operational states of a machine or the environmental noise can change to cause domain shifts. Domain-generalization techniques can be useful for handling domain shifts that occur frequently or are hard-to-notice. In this task, the system is required to use domain-generalization techniques for handling these domain shifts. This requirement is the same as in DCASE 2022 Task 2.

3. Train a model for a completely new machine type
For a completely new machine type, hyperparameters of the trained model cannot be tuned. Therefore, the system should have the ability to train models without additional hyperparameter tuning.

4. Train a model using only one machine from its machine type
While sounds from multiple machines of the same machine type can be used to enhance detection performance, it is often the case that sound data from only one machine are available for a machine type. In such a case, the system should be able to train models using only one machine from a machine type.

The last two requirements are newly introduced in DCASE 2023 Task2 as the "first-shot problem".

This year’s task is focused on the first-shot problem. We explain the practical conditions that were not considered in the previous tasks and how these conditions, defined as the first-shot problem, are reflected in this year’s task.

First, tuning hyperparameters using test data can be infeasible for a new machine type. In the previous tasks, the development and evaluation datasets had the same set of machine types, which enabled participants to tune the hyperparameter for each machine type using test data in the development dataset. For example, the valve- sound data in the development dataset can be used for tuning hyperparameters for model ensembling so that the detection performance for the valve-sound data in the evaluation dataset can be improved. However, in real-world applications, this approach is often infeasible because the machine type can be completely new or the amount of test data can be insufficient for tuning hyperparameters. This problem motivated the organizers to set the third requirement described above and prepare a completely different set of machine types between the development and evaluation datasets.

Second, there can be only one machine available for a machine type. In the previous tasks, multiple different machines were provided for each machine type. Although this feature has led to the development of outlier exposure approaches that use sound clips from different machines as anomalies, in many practical cases, only one machine can be available for a machine type. This is because the customers may not have multiple machines or may first plan to install the system for one machine. Considering these cases, the organizers set the fourth requirement and prepared only one machine for each machine type.

In summary, we considered the first-shot problem as the main updates from the previous tasks. The main features in this year’s task are: (1) the set of machine types in the development dataset and evaluation dataset are completely different and (2) each machine type contain sounds from only one machine.

Schedule

Based on the DCASE Challenge 2023 schedule, the task important days will be as follows.

• Task open: 1st of March 2023
• Additional training dataset release: 15th of April 2023
• Evaluation dataset release: 1st of May 2023
• External resource list lock: 1st of May 2023
• Challenge deadline: 15th of May 2023
• Challenge results: 31st of May 2023

External resources on the "List of external datasets and models allowed" can be used (cf. external data resource section). List of external datasets and models allowed will be updated upon request. Any external resource which are freely accessed before 15th of April 2023 can be added. Please send a request email to the task organizers. The list will be locked after the release date of evaluation dataset (1st of May 2023). To avoid developing new external resources using machine information in the evaluation dataset, we will release the additional training dataset after 15th of April 2023. Note that the additional training dataset contains matching training data of machines used in the evaluation dataset (cf. dataset section).

Audio datasets

Dataset overview

Three datasets (development, additional training, and evaluation) are provided for this task.

The development dataset consists of normal/anomalous operating sounds of seven types of machines. Each recording is a single-channel 10-sec-long audio clip that includes both the sounds of the target machine and environmental sounds. The following seven types of machines are used:

• Toy car
• Toy train
• Fan
• Gearbox
• Bearing
• Slide rail
• Valve

The additional training and evaluation datasets also consist of normal/anomalous operating sounds of machines, but the sets of machine types are completely different from the development dataset.

Figure 2 shows an overview of the datasets for development, additional training, and evaluation. Each dataset consists of several types of machines, and each type of machine consists of one “section”.

Definition

We first define the key terms in this task: "machine type," "section," "source domain," "target domain," and "attributes."

• "Machine type" indicates the type of machine, which in the development dataset is one of seven: fan, gearbox, bearing, slide rail, valve, ToyCar, and ToyTrain.
• A section is defined as a subset of the dataset for calculating performance metrics.
• The source domain is the domain under which most of the training data and some of the test data were recorded, and the target domain is a different set of domains under which some of the training data and some of the test data were recorded. There are differences between the source and target domains in terms of operating speed, machine load, viscosity, heating temperature, type of environmental noise, signal-to-noise ratio, etc.
• Attributes are parameters that define states of machines or types of noise.

Development, additional training, and evaluation datasets

Our entire dataset consists of three datasets:

1. Development dataset: This dataset consists of seven machine types. For each machine type, one section is provided, and the section is a complete set of training and test data. For each section, this dataset provides (i) 990 clips of normal sounds in the source domain for training, (ii) ten clips of normal sounds in the target domain for training, and (iii) 100 clips each of normal and anomalous sounds for the test. The source/target domain of each sample is provided. Additionally, the attributes of each sample in the training and test data are provided in the file names and attribute csv files.

2. Additional training dataset: This dataset also consists of several machine types, but the set of machine types are completely different from the development dataset. This dataset also provides one section for each machine type. Each section consists of (i) 990 clips of normal sounds in the source domain for training and (ii) ten clips of normal sounds in a target domain for training. The domain of each sample and attributes are provide. Participants may also use this dataset for training. The additional training dataset will be open on April 15th.

3. Evaluation dataset: This dataset provides test clips for the sections in the additional training dataset. Each section has 200 test clips, none of which have a condition label (i.e., normal or anomaly) or information about the domain to which it belongs (i.e., source or target). Attributes are not provided. The additional training dataset will be open on May 1st.

File names and attribute csv files

File names and attribute csv files provide reference labels for each clip. The given reference labels for each training/test clip include machine type, section index, normal/anomaly information, and attributes regarding the condition other than normal/anomaly. The machine type is given by the directory name. The section index is given by their respective file names. For the datasets other than the evaluation dataset, the normal/anomaly information and the attributes are given by their respective file names. Attribute csv files are for easy access to attributes that cause domain shifts. In these files, the file names, name of parameters that cause domain shifts (domain shift parameter, dp), and the value or type of these parameters (domain shift value, dv) are listed. Each row takes the following format:

[filename (string)], [d1p (string)], [d1v (int | float | string)], [d2p], [d2v]...


Recording procedure

Normal/anomalous operating sounds of machines and its related equipment are recorded. Anomalous sounds were collected by deliberately damaging target machines. For simplifying the task, we use only the first channel of multi-channel recordings; all recordings are regarded as single-channel recordings of a fixed microphone. We mixed a target machine sound with environmental noise, and only noisy recordings are provided as training/test data. The environmental noise samples were recorded in several real factory environments. We will publish papers on the dataset to explain the details of the recording procedure by the submission deadline.

Short description of each section in the development dataset

Short descriptions of each section in the development dataset and the attribute format in the file names of their training data are as follows:

 Machine type Section Description Attribute format in file names of training data ToyCar 00 Car model, speed, and mic variations between domains. car__spd(speed)__mic_ ToyTrain 00 Train model, speed, and mic variations between domains. car__spd(speed)__mic_ Fan 00 Mixing of different machine sound between domains. m-n(machine-noise)_ Gearbox 00 Different operation voltage and weight attached to the box between domains. volt(voltage)__wt(weight)_ Bearing 00 Different rotation velocity and location of the microphonebetween domains. vel(velocity)__loc(location of the microphone)_ Slide rail 00 Different operation velocity and acceleration between domains. vel(velocity)_ac(acceleration)_ Valve 00 Open/close operation patterns varies between domains. pat(pattern)_

External data resources

Based on the past DCASE's external data resource policy, we allow the use of external datasets and trained models under the following conditions:

1. Any test data in both development and evaluation datasets shall not be used for training.
2. Any data in ToyADMOS, ToyADMOS2, MIMII Dataset, MIMII DUE Dataset, MIMII DG Dataset, the dataset of DCASE 2020 Challenge Task 2 , the dataset of DCASE 2021 Challenge Task 2 , and the dataset of DCASE 2022 Challenge Task 2 shall not be used.
3. Datasets, pre-trained models, and pre-trained parameters on the "List of external data resources allowed" can be used. The list will be updated upon request. Datasets, pre-trained models, and pre-trained parameters, which are freely accessible by any other research group before 15th of April 2023, can be added to the list.
4. To add sources of external datasets, pre-trained models, or pre-trained parameters to the list, send a request to the organizers by the evaluation set publishing date. To give an equal opportunity to use them for all competitors, we will update the "list of external data resources allowed" on the web page accordingly.
5. Once the evaluation set is published, no further external sources will be added. The list will be locked after 1st of May 2023.

List of external data resources allowed:

IDMT-ISA-ELECTRIC-ENGINE audio 15.03.2022 https://www.idmt.fraunhofer.de/en/publications/isa-electric-engine.html
VGGish model 15.03.2022 https://github.com/tensorflow/models/tree/master/research/audioset/vggish
PANNs model 15.03.2022 https://zenodo.org/record/3576403/
PyTorch Image Models (including tens of pre-trained models) model 15.03.2022 https://github.com/rwightman/pytorch-image-models
torchvision.models (including tens of pre-trained models) model 15.03.2022 https://pytorch.org/vision/stable/models.html

Development dataset (2.2 GB)
version 1.0

Participants are required to submit both an anomaly score and a normal/anomaly decision result for each test clip. The anomaly score for each test clip will be used to calculate the area under the receiver operating characteristic (ROC) curve (AUC) and partial-AUC (pAUC) scores, which are used to calculate an official score and a final ranking. The normal/anomaly decision result for each test clip is used to calculate the precision, recall, and F1 scores, which will also be published when the challenge results are open. The method of evaluation is described in the Evaluation section.

The anomaly score takes a large value when the input signal seems to be anomalous, and vice versa. To calculate the anomaly score, participants need to train an anomaly score calculator $$\mathcal{A}$$ with parameter $$\theta$$. The input of $$\mathcal{A}$$ is a machine's operating sound $$x \in \mathbb{R}^L$$ and its machine information including machine type, section index, and other attribute information, and $$\mathcal{A}$$ outputs one anomaly score for the whole audio clip $$x$$ as $$\mathcal{A}_\theta (x) \in \mathbb{R}$$. Then, $$x$$ is determined to be anomalous when the anomaly score exceeds a pre-defined threshold value. Thus, $$\mathcal{A}$$ needs to be trained so that $$\mathcal{A}_\theta(x)$$ will be a large value both when the whole audio clip $$x$$ is anomalous and when a part of $$x$$ is anomalous, such as with collision anomalous sounds.

Figure 3 shows the overview of this task, where the example is a procedure for calculating the anomaly scores of the test clips of (fan, section 00, target domain). First, the participants train an anomaly score calculator $$\mathcal{A}$$ using training data both in the source and target domains and optional external data resources. Then, by using $$\mathcal{A}$$, participants calculate anomaly scores of all the test clips of (fan, section 00, target domain). By repeating this procedure, participants calculate the anomaly score of all the test clips of all the machine types, sections, and domains.

Arbitral numbers of an anomaly score calculator $$\mathcal{A}$$ can be used to calculate the anomaly scores of test clips. The simplest strategy is to use a single $$\mathcal{A}$$ to calculate the anomaly scores for a single section (e.g., section 00). In this case, $$\mathcal{A}$$ is specialized to a single section, so users of such a system are required to train $$\mathcal{A}$$ for each machine type, each product, and each condition. A more challenging strategy is to use a single $$\mathcal{A}$$ to calculate the anomaly scores of all the test clips of all the machine types and sections. The advantage of this strategy is that participants can use all the training clips provided; however, they need to consider the generalization of the model. Another typical scenario that can be inspired by real-world applications is where you train a general model only with the source-domain data. The task organizers do not impose this constraint but would appreciate participants’ efforts to impose constraints on themselves based on various real-world applications.

All training data with arbitrary splitting can be used to train an anomaly score calculator. For example, to train $$\mathcal{A}$$ to calculate the anomaly score of (valve, section 00, source domain), participants can opt to use training data only in (valve, section 00, source domain), training data in both the source domain and target domains, training data of all sections of valves, all provided training data, and/or other strategies. Of course, normal/anomalous clips in test data cannot be used for training; however, simulating anomalous samples using the listed external data resources is allowed.

Changing the model (model/architecture/hyperparameters) between machine types within a single submission is allowed. However, we expect participants to develop a simple ASD system, (i.e. keep the model and hyperparameters fixed and only change the training data to adapt to each machine type).

Submission

The official challenge submission consists of:

• System output for the evaluation data
• Meta information files

System output should be presented as a text-file that corresponds to each machine type, section index. Its file name should be:

• Anomaly score file: anomaly_score_<machine_type>_section_<section_index>.csv
• Detection result file: decision_result_<machine_type>_section_<section_index>.csv

The anomaly score file (in CSV format, without header row) contains the anomaly score for each audio file in the test data of the evaluation dataset. Result items can be in any order. All rows must be in the following format:

[filename (string)],[anomaly score (real value)]


Anomaly scores in the second column can take a negative value. For example, typical auto-encoder-based anomaly score calculators use the squared reconstruction error, which takes a non-negative value, while statistical model-based methods (such as GMM) use the negative log-likelihood as the anomaly score, which can take both positive and negative values.

The decision result file (in CSV format, without header row) contains the normal/anomaly decision result for each audio file in the test data of the evaluation dataset. Result items can be in any order. All rows must be the following format:

[filename (string)],[decision result (0: normal, 1: anomaly)]


We allow up to four system output submissions per participant/team. For each system, meta information should be provided in a separate file that contains the task-specific information. All files should be packaged into a zip file for submission. Detailed information on the submission process can be found on the Submission page.

Evaluation

Metrics

This task is evaluated with the AUC and the pAUC. The pAUC is an AUC calculated from a portion of the ROC curve over the pre-specified range of interest.

Because the anomaly detector is expected to work with the same threshold regardless of the domain, data from both domains in a section are used to calculate the AUC and pAUC. Also, in order to evaluate the detection performance for each domain, the AUC is calculated for each domain. The AUC for each machine type, section, and domain (source/target) and the pAUC for each machine type and section are defined as

$${\rm AUC}_{m, n, d} = \frac{1}{N^{-}_{d}N^{+}_{n}} \sum_{i=1}^{N^{-}_{d}} \sum_{j=1}^{N^{+}_{n}} \mathcal{H} (\mathcal{A}_{\theta} (x_{j}^{+}) - \mathcal{A}_{\theta} (x_{i}^{-})),$$
$${\rm pAUC}_{m, n} = \frac{1}{\lfloor p N^{-}_{n} \rfloor N^{+}_{n}} \sum_{i=1}^{\lfloor p N^{-}_{n} \rfloor} \sum_{j=1}^{N^{+}_{n}} \mathcal{H} (\mathcal{A}_{\theta} (x_{j}^{+}) - \mathcal{A}_{\theta} (x_{i}^{-}))$$

where $$m$$ represents the index of a machine type, $$n$$ represents the index of a section, $$d = \{ {\rm source}, {\rm target} \}$$ represents a domain, $$\lfloor \cdot \rfloor$$ is the flooring function, and $$\mathcal{H} (x)$$ returns 1 when $$x$$ > 0 and 0 otherwise. Here, $$\{x_{i}^{−}\}_{i=1}^{N^{-}_{d}}$$ is normal test clips in the domain $$d$$ in the section $$n$$ in the machine type $$m$$ and $$\{x_{j}^{+}\}_{j=1}^{N^{+}_{n}}$$ is anomalous test clips in the section $$n$$ in the machine type $$m$$, respectively, and they have been sorted so that their anomaly scores are in descending order. Here, $$N^{-}_{d}$$ is the number of normal test clips in the domain $$d$$ in the section $$n$$ in the machine type $$m$$, $$N^{-}_{n}$$ are the number of normal test clips in the section $$n$$ in the machine type $$m$$, and $$N^{+}_{n}$$ is the number of anomalous test clips in the section $$n$$ in the machine type $$m$$, respectively.

In our metric, the pAUC is calculated as the AUC over a low false-positive-rate (FPR) range $$[0, p]$$. The reason for the additional use of the pAUC is based on practical requirements. If an ASD system frequently gives false alarms, we cannot trust it. Therefore, it is especially important to increase the true-positive-rate under low FPR conditions. In this task, we will use $$p=0.1$$.

The official score $$\Omega$$ for each submitted system is given by the harmonic mean of the AUC and pAUC scores over all the machine types, sections, and domains as follows:

$$\Omega = h \left\{ {\rm AUC}_{m, n, d}, \ {\rm pAUC}_{m, n} \quad | \quad m \in \mathcal{M}, \ n \in \mathcal{S}(m), \ d \in \{ {\rm source}, {\rm target} \} \right\},$$

where $$h\left\{\cdot\right\}$$ represents the harmonic mean (over all machine types, sections, and domains), $$\mathcal{M}$$ represents the set of the machine types, and $$\mathcal{S}(m)$$ represents the set of the sections for the machine type $$m$$.

As the equations above show, a threshold value does not need to be determined to calculate AUC, pAUC, or the official score because the threshold value is the anomaly scores of normal test clips. However, in real applications, the threshold value must be determined, and a decision must be made as to whether it is normal or anomalous. Therefore, participants are also required to submit the normal/anomaly decision results. The organizers will publish the AUC, pAUC, and official scores as well as the precision, recall, and F1-scores calculated for the normal/anomaly decision results.

Note: The submitted normal/anomaly decision results will not be used for the final ranking because the task organizers do not want to encourage participants to use a forbidden approach (i.e., threshold tuning based on the distribution in the evaluation dataset). Do not use other test clips to determine anomalies for each test clip.

Ranking

The final ranking will be decided by sorting based on the official score $$\Omega$$.

Baseline system

The task organizers provide two baseline systems that give a reasonable performance in the dataset of Task 2. They are good starting points, especially for entry-level researchers who want to get familiar with the ASD task.

Autoencoder-based baseline with two operating modes

The baseline system is based on the Autoencoder of DCASE 2022 Challenge Task 2. It is an example of the inlier modeling (IM)-based detector that models the distribution of inlier samples. However, the DCASE2023T2 baseline has two different operating modes:

+ Simple autoencoder mode
+ Selective Mahalanobis mode


For the details, see https://arxiv.org/abs/2303.00455.

Simple Autoencoder mode

The anomaly score is calculated as the reconstruction error of the observed sound. To obtain small anomaly scores for normal sounds, the AE is trained to minimize the reconstruction error of the normal training data. This method is based on the assumption that the AE cannot reconstruct sounds that are not used in training, that is unknown anomalous sounds.

In the baseline system, we first calculate the log-mel-spectrogram of the input $$X = \{X_t\}_{t = 1}^T$$ where $$X_t \in \mathbb{R}^F$$, and $$F$$ and $$T$$ are the number of mel-filters and time-frames, respectively. Then, the acoustic feature at $$t$$ is obtained by concatenating consecutive frames of the log-mel-spectrogram as $$\psi_t = (X_t, \cdots, X_{t + P - 1}) \in \mathbb{R}^D$$, where $$D = P \times F$$, and $$P$$ is the number of frames of the context window. The anomaly score is calculated as:

$$A_{\theta}(X) = \frac{1}{DT} \sum_{t = 1}^T \| \psi_t - r_{\theta}(\psi_t) \|_{2}^{2},$$

where $$r_{\theta}$$ is the vector reconstructed by the autoencoder, and $$\| \cdot \|_2$$ is $$\ell_2$$ norm.

To determine the anomaly detection threshold, we assume that $$A_{\theta}$$ follows a gamma distribution. The parameters of the gamma distribution are estimated from the histogram of $$A_{\theta}$$, and the anomaly detection threshold is determined as the 90th percentile of the gamma distribution. If $$A_{\theta}$$ for each test clip is greater than this threshold, the clip is judged to be abnormal; if it is smaller, it is judged to be normal.

Selective Mahalanobis mode

The anomaly score is calculated as the reconstruction error of the observed sound in the Mahalanobis metric with the covariance matrixes calculated after the last epoch of the training phase.

Parameters

The basic architecture and parameters are the same for both modes, simple autoencoder mode and selective Mahalanobis mode.

Acoustic features

• The frame size for STFT is 64 ms (50 % hop size)
• Log-mel energies for 128 ($$= F$$) bands
• 5 ($$= P$$) consecutive frames are concatenated.
• 640 ($$= D = P \times F$$) dimensions are input to the autoencoder.

Network Architecture

• Input shape: 640
• Architecture:
• Dense layer #1
• Dense layer (units: 128)
• Batch Normalization
• Activation (ReLU)
• Dense layer #2
• Dense layer (units: 128)
• Batch Normalization
• Activation (ReLU)
• Dense layer #3
• Dense layer (units: 128)
• Batch Normalization
• Activation (ReLU)
• Dense layer #4
• Dense layer (units: 128)
• Batch Normalization
• Activation (ReLU)
• Bottleneck layer
• Dense layer (units: 8)
• Batch Normalization
• Activation (ReLU)
• Dense layer #5
• Dense layer (units: 128)
• Batch Normalization
• Activation (ReLU)
• Dense layer #6
• Dense layer (units: 128)
• Batch Normalization
• Activation (ReLU)
• Dense layer #7
• Dense layer (units: 128)
• Batch Normalization
• Activation (ReLU)
• Dense layer #8
• Dense layer (units: 128)
• Batch Normalization
• Activation (ReLU)
• Output layer
• Dense layer (units: 640)
• Learning (epochs: 100, batch size: 256, data shuffling between epochs)
• Optimizer: Adam (learning rate: 0.001)

Repository

Detailed information can be found in the GitHub repository. The directory structure is briefly described here as a reference for label information. When you unzip the files downloaded from the GitHub repository and Zenodo, you can see the following directory structure. As described in the Dataset section, the machine type information is given by directory name, and the section index, domain, and condition information are given by file name, as:

• datasets/
• networks/
• results/
• tools/
• 01_train.sh
• 02a_test.sh
• 03_summarize_results.sh
• baseline.yaml
• common.py
• LISENCE.py
• requirements.txt
• test_ae.sh
• train_ae.sh
• train.py
• data/dcase2023t2/dev_data/raw/
• fan/
• train (only normal clips)
• section_00_source_train_normal_0000_.wav
• ...
• section_00_source_train_normal_0989_.wav
• section_00_target_train_normal_0000_.wav
• ...
• section_00_target_train_normal_0009_.wav
• test/
• section_00_source_test_normal_0000_.wav
• ...
• section_00_source_test_normal_0049_.wav
• section_00_source_test_anomaly_0000_.wav
• ...
• section_00_source_test_anomaly_0049_.wav
• section_00_target_test_normal_0000_.wav
• ...
• section_00_target_test_normal_0049_.wav
• section_00_target_test_anomaly_0000_.wav
• ...
• section_00_target_test_anomaly_0049_.wav
• attributes_00.csv (attributes csv for section 00)
• gearbox/ (The other machine types have the same directory structure as fan.)
• data/dcase2023t2/eval_data/raw/
• /
• train/ (after launch of the additional training dataset)
• section_00_source_train_normal_0000_.wav
• ...
• section_00_source_train_normal_0989_.wav
• section_00_target_train_normal_0000_.wav
• ...
• section_00_target_train_normal_0009_.wav
• test/
• section_00_source_test_normal_0000_.wav
• ...
• section_00_source_test_normal_0049_.wav
• section_00_source_test_anomaly_0000_.wav
• ...
• section_00_source_test_anomaly_0049_.wav
• section_00_target_test_normal_0000_.wav
• ...
• section_00_target_test_normal_0049_.wav
• section_00_target_test_anomaly_0000_.wav
• ...
• section_00_target_test_anomaly_0049_.wav
• test/ (after launch of the evaluation dataset)
• section_00_test_0000.wav
• ...
• section_00_test_0199.wav
• attributes_00.csv (attributes csv for section 00)
• / (The other machine types have the same directory structure as /.)

Results with the development dataset

We evaluated the AUC and pAUC on the development dataset using several types of GPUs (RTX 2080, etc.). Because the results produced with a GPU are generally non-deterministic, the average and standard deviations from these five independent trials (training and testing) are shown in the following table.

 ToyCarMSEMAHALA AUC_source (Ave.)70.1 %74.53 % AUC_source (Std.)0.46 %1.55 % AUC_target (Ave.)46.89 %43.42 % AUC_target (Std.)2.67 %2.53 % pAUC (Ave.)52.47 %49.18 % pAUC (Std.)1.28 %0.49 % ToyTrainMSEMAHALA AUC_source (Ave.)57.93 %55.98 % AUC_source (Std.)2.12 %2.41 % AUC_target (Ave.)57.02 %42.45 % AUC_target (Std.)0.79 %1.06 % pAUC (Ave.)48.57 %48.13 % pAUC (Std.)0.32 %0.17 % bearingMSEMAHALA AUC_source (Ave.)65.92 %65.16 % AUC_source (Std.)0.73 %0.76 % AUC_target (Ave.)55.75 %55.28 % AUC_target (Std.)0.76 %0.57 % pAUC (Ave.)50.42 %51.37 % pAUC (Std.)0.79 %0.81 % fanMSEMAHALA AUC_source (Ave.)80.19 %87.1 % AUC_source (Std.)2.43 %2.2 % AUC_target (Ave.)36.18 %45.98 % AUC_target (Std.)3.71 %4.43 % pAUC (Ave.)59.04 %59.33 % pAUC (Std.)1.24 %0.9 % gearboxMSEMAHALA AUC_source (Ave.)60.31 %71.88 % AUC_source (Std.)0.56 %0.66 % AUC_target (Ave.)60.69 %70.78 % AUC_target (Std.)0.63 %0.62 % pAUC (Ave.)53.22 %54.34 % pAUC (Std.)0.6 %0.3 % sliderMSEMAHALA AUC_source (Ave.)70.31 %84.02 % AUC_source (Std.)0.2 %1.1 % AUC_target (Ave.)48.77 %73.29 % AUC_target (Std.)0.12 %0.6 % pAUC (Ave.)56.37 %54.72 % pAUC (Std.)0.31 %0.25 % valveMSEMAHALA AUC_source (Ave.)55.35 %56.31 % AUC_source (Std.)1.18 %1.38 % AUC_target (Ave.)50.69 %51.4 % AUC_target (Std.)1.12 %0.4 % pAUC (Ave.)51.18 %51.08 % pAUC (Std.)0.35 %0.13 %

Citation

If you are participating in this task or using the MIMII DG and ToyADMOS2, and baseline code, please cite the following three papers:

Publication

Noboru Harada, Daisuke Niizumi, Daiki Takeuchi, Yasunori Ohishi, Masahiro Yasuda, and Shoichiro Saito. ToyADMOS2: another dataset of miniature-machine operating sounds for anomalous sound detection under domain shift conditions. In Proceedings of the Detection and Classification of Acoustic Scenes and Events Workshop (DCASE), 1–5. Barcelona, Spain, November 2021.

ToyADMOS2: Another Dataset of Miniature-Machine Operating Sounds for Anomalous Sound Detection under Domain Shift Conditions

Abstract

This paper proposes a new large-scale dataset called “ToyADMOS” for anomaly detection in machine operating sounds (ADMOS). As with our previous ToyADMOS dataset, we collected a large number of operating sounds of miniature machines (toys) under normal and anomaly conditions by deliberately damaging them, but extended them in this case by providing a controlled depth of damages in the anomaly samples. Since typical application scenarios of ADMOS require robust performance under domain-shift conditions, the ToyADMOS2 dataset is designed for evaluating systems under such conditions. The released dataset consists of two sub-datasets for machine-condition inspection: fault diagnosis of machines with geometrically fixed tasks and fault diagnosis of machines with moving tasks. Domain shifts are represented by introducing several differences in operating conditions, such as the use of the same machine type but with different models and parts configurations, operating speeds, microphone arrangements, etc. Each subdataset contains over 27 k samples of normal machine-operating sounds and over 8 k samples of anomalous sounds recorded with five to eight microphones. The dataset is freely available for download at https://github.com/nttcslab/ToyADMOS2-dataset and https://doi.org/10.5281/zenodo.4580270.

Publication

Kota Dohi, Tomoya Nishida, Harsh Purohit, Ryo Tanabe, Takashi Endo, Masaaki Yamamoto, Yuki Nikaido, and Yohei Kawaguchi. Mimii dg: sound dataset for malfunctioning industrial machine investigation and inspection for domain ggeneralization task. In Proceedings of the 7th Detection and Classification of Acoustic Scenes and Events 2022 Workshop (DCASE2022). Nancy, France, November 2022.

MIMII DG: Sound Dataset for Malfunctioning Industrial Machine Investigation and Inspection for Domain Ggeneralization Task

Abstract

We present a machine sound dataset to benchmark domain generalization techniques for anomalous sound detection (ASD). Domain shifts are differences in data distributions that can degrade the detection performance, and handling them is a major issue for the application of ASD systems. While currently available datasets for ASD tasks assume that occurrences of domain shifts are known, in practice, they can be difficult to detect. To handle such domain shifts, domain generalization techniques that perform well regardless of the domains should be investigated. In this paper, we present the first ASD dataset for the domain generalization techniques, called MIMII DG. The dataset consists of five machine types and three domain shift scenarios for each machine type. The dataset is dedicated to the domain generalization task with features such as multiple different values for parameters that cause domain shifts and introduction of domain shifts that can be difficult to detect, such as shifts in the background noise. Experimental results using two baseline systems indicate that the dataset reproduces domain shift scenarios and is useful for benchmarking domain generalization techniques.

Publication

Noboru Harada, Daisuke Niizumi, Daiki Takeuchi, Yasunori Ohishi, and Masahiro Yasuda. First-shot anomaly detection for machine condition monitoring: a domain generalization baseline. In arXiv e-prints: 2303.00455, 2023.