THERMALITY OF THE ZERO–POINT LENGTH
AND GRAVITATIONAL SELFDUALITY

P. Fernández de Córdoba1, J.M. Isidro2 and Rudranil Roy3
Instituto Universitario de Matemática Pura y Aplicada,
Universitat Politècnica de València, Valencia 46022, Spain
<EMAIL_ADDRESS><EMAIL_ADDRESS>
<EMAIL_ADDRESS>
###### Contents

  1. 1 Introduction
  2. 2 Thermality of the zero–point length
    1. 2.1 Oscillators as a model for virtual dimensions
    2. 2.2 The complete oscillator
      1. 2.2.1 Thermal density matrices
      2. 2.2.2 A thermally induced quantum of length
    3. 2.3 The truncated oscillator
      1. 2.3.1 Thermal density matrices
      2. 2.3.2 A thermally induced quantum of length
  3. 3 Gravitational selfduality
  4. 4 Discussion
  5. 5 Appendix
    1. 5.1 Computation of $\varrho_{d}^{\rm even/odd}(q;\beta)$
    2. 5.2 Computation of $\left(Q^{2}\right)_{d}^{\rm even/odd}$

Abstract It has been argued that the existence of a zero–point length is the
hallmark of quantum gravity. In this letter we suggest a thermal mechanism
whereby this quantum of length arises in flat, Euclidean spacetime
$\mathbb{R}^{d}$. For this we consider the infinite sequence of all flat,
Euclidean spacetimes $\mathbb{R}^{d^{\prime}}$ with $d^{\prime}\geq d$, and
postulate a probability distribution for each $d^{\prime}$ to occur. The
distribution considered is that of a canonical ensemble at temperature $T$,
the energy levels those of a 1–dimensional harmonic oscillator. Since both the
harmonic energy levels and the spacetime dimensions are evenly spaced, one can
identify the canonical distribution of harmonic–oscillator eigenvalues with
that of dimensions $d^{\prime}$. The state describing this statistical
ensemble has a mean square deviation in the position operator, that can be
interpreted as a quantum of length. Thus placing an oscillator in thermal
equilibrium with a bath provides a thermal mechanism whereby a zero–point
length is generated. The quantum–gravitational implications of this
construction are then discussed. In particular, a model is presented that
realises a conjectured duality between a weakly gravitational, strongly
quantum system and a weakly quantum, strongly gravitational system.

##  1 Introduction

It has been argued that first–order quantum–gravity effects manifest
themselves through the existence of a quantum of length $L$ [8, 11, 22]. Under
first–order effects one understands such as can be observed mesoscopically,
without the need for a complete theory of quantum gravity—a theory still under
development from a number of different perspectives; for a sample see e.g.
[12] and refs. therein.

The effects of a zero–point length have been extensively studied in the
setting provided by a free, massive, relativistic particle propagating in
Euclidean spacetime $\mathbb{R}^{d}$ [14, 15, 18]. Let ${\cal S}({\bf
x})=\int^{\bf x}{\rm d}s$ be the classical action functional for the particle
when $m=1$. Let $G^{d}_{(L=0)}$ be the Feynman propagator for the particle in
the absence of a quantum of length $L$, and let $G^{d}_{(L)}$ denote the same
propagator in the presence of a quantum of length $L$:

$\displaystyle G^{d}_{(L=0)}({\bf x})$ $\displaystyle=$
$\displaystyle\sum_{\rm paths}\exp\left[-m\,{\cal S}({\bf x})\right],$ (1)
$\displaystyle G^{d}_{(L)}({\bf x})$ $\displaystyle=$ $\displaystyle\sum_{\rm
paths}\exp\left\\{-m\left[{\cal S}({\bf x})+\frac{L^{2}}{{\cal S}({\bf
x})}\right]\right\\}.$ (2)

One can regard the propagator $G^{d}_{(L)}$ as the UV completion of the
propagator $G^{d}_{(L=0)}$ because $G^{d}_{(L)}$ is duality invariant, i.e.,
invariant under the exchange of ${\cal S}$ and $L^{2}/{\cal S}$.

Now in ref. [3] the decomposition

$G^{d}_{(L)}=\sum_{n=0}^{\infty}\frac{(-\pi)^{n}}{n!}G^{d+2n}_{(L=0)}$ (3)

has been established. It expresses the quantum–gravity corrected propagator in
$d$ dimensions as an infinite sum of quantum–gravity free propagators in all
virtual dimensions $d+2n$, with $n\in\mathbb{N}$. This fact seems to cast some
doubt on the notion of a sharply defined dimension for quantum spacetimes, at
least in the mesoscopic regime.

Let us now Wick rotate Euclidean spacetime $\mathbb{R}^{d}$ into Minkowski
spacetime: $t\rightarrow{\rm i}\tau$. Let ${\cal G}_{M}$ (resp. ${\cal
G}_{R}$) denote the Feynman propagator for a real scalar field $\phi$ in the
Minkowski vacuum (resp. Rindler vacuum). Then ${\cal G}_{M}$ can be thought of
as a thermalised version of ${\cal G}_{R}$, in the sense that [17, 20]

${\cal G}_{M}({\rm i}\tau)=\sum_{n=-\infty}^{\infty}{\cal G}_{R}({\rm
i}\tau+2{\rm i}\pi n).$ (4)

Despite the fact that Eq. (3) refers to a particle while (4) refers to a
field, the analogy between them is inspiring: given the thermality of the
Rindler frame, it suggests a possible thermal origin for the quantum of length
$L$.

It is one goal of this letter to establish that, indeed, the quantum of length
$L$ implementing UV completeness can be interpreted as having a thermal
origin. In proving this statement we will achieve a complementary goal.
Namely, we will provide a specific example of the UV/IR duality between the
weakly gravitational, strongly quantum regime of a system and the weakly
quantum, strongly gravitational regime of a dual system conjectured in ref.
[21].

In order to achieve these two goals we will first identify a canonical
ensemble in equilibrium with a thermal bath at temperature $T$, in such a way
that it mimics the quantum–gravity corrected, Euclidean spacetime
$\mathbb{R}^{d}_{(L)}$. This ensemble is immediately suggested by the
right–hand side of Eq. (3): an infinite collection of quantum–gravity free,
Euclidean spacetimes $\mathbb{R}^{d+2n}_{(L=0)}$, one for each value of
$n\in\mathbb{N}$. The following hints provide further clues:
i) associated with a harmonic oscillator there is a natural length scale,
namely

$\lambda_{0}=\sqrt{\frac{\hbar}{m\omega}};$ (5)

ii) spacetime dimensions are evenly spaced in the same way as the energy
eigenvalues of the 1–dimensional harmonic oscillator;
iii) the sum over virtual dimensions (3) is such that only those virtual
dimensions are summed over that have the same parity as $d$; also this is
reminiscent of the well–defined parity of harmonic eigenstates.

These hints suggest that the sought–for canonical ensemble might be given by
the infinite collection of excited energy levels $n=d,d+2,d+4,\ldots$ of a
1–dimensional harmonic oscillator. The oscillator groundstate $n=0$ is mapped
into the spacetime dimension $d=0$; although the latter is meaningless as a
dimension, meaningful physical quantities will be attached to the value $d=0$.
This oscillator will be placed in thermal equilibrium with an energy reservoir
at temperature $T$. Probabilities will be distributed according to the
Boltzmann law: an energy $\varepsilon_{n}=(n+1/2)\hbar\omega$ will be weighted
by $w_{n}=\exp(-\varepsilon_{n}/k_{B}T)$, and the partition function will be
given by $Z=\sum_{n}w_{n}$.

The mass $m$ of the harmonic oscillator will be taken to equal that of the
particle, and the frequency $\omega$ will be its Compton frequency. The
coordinate along which this oscillator moves will be denoted by $q$; the
corresponding quantum operator will be $Q$. As usual we will have
$H|n\rangle=(n+1/2)\hbar\omega|n\rangle$, where $H$ is the harmonic
Hamiltonian and the $|n\rangle$, $n=0,1,\ldots$ are normalised energy
eigenstates. This completes our identification of the quantum–mechanical,
1–dimensional harmonic oscillator that is necessary for our construction. What
remains is to prove that $L$ actually arises as the thermal average of a
certain quantity at a certain temperature; a point that we develop next.

##  2 Thermality of the zero–point length

###  2.1 Oscillators as a model for virtual dimensions

Let us begin with the canonical partition function $Z_{\rm ho}(\beta)$ for the
quantum, 1–dimensional harmonic oscillator in thermal equilibrium with an
energy reservoir at temperature $T$:

$Z_{\rm ho}(\beta)=\sum_{n=0}^{\infty}{\rm
e}^{-(n+1/2)\beta\hbar\omega}=\frac{1}{2}\,{\rm
csch}\left(\frac{\beta\hbar\omega}{2}\right).$ (6)

We will also need the partition functions with a defined parity

$Z_{\rm ho}^{\rm even/odd}(\beta)=\sum_{n=0\atop{\rm
n\,even/odd}}^{\infty}{\rm e}^{-(n+1/2)\beta\hbar\omega}=\frac{1}{2}\,{\rm
e}^{\pm\beta\hbar\omega/2}{\rm csch}\left(\beta\hbar\omega\right),$ (7)

the positive (resp. negative) sign corresponding to the even (resp. odd)
parity.

Moreover, we would like to construct a partition function appropriate to the
sum over virtual dimensions (3). This is readily done: given a value of $d\geq
0$, consider the object $Z_{d}(\beta)$ defined as

$Z_{d}(\beta)=\sum_{n=0}^{\infty}{\rm
e}^{-(d+2n+1/2)\beta\hbar\omega}=\frac{1}{2}\,{\rm
e}^{-(d-1/2)\beta\hbar\omega}\,{\rm csch}\left(\beta\hbar\omega\right).$ (8)

We will refer to the ensemble of oscillator states described by the partition
function (8) as the truncated oscillator. Truncation means that one sums only
over those excited oscillator states $|n\rangle$ such that $n\geq d$, and then
only over those carrying the same parity as $d$ (as dictated by the sum over
virtual dimensions (3)). By contrast we will refer to the ensemble of
oscillator states described by the partition function (6) as the complete
oscillator, completeness here meaning that one sums over all states $n\geq 0$,
and also regardless of parity.

###  2.2 The complete oscillator

####  2.2.1 Thermal density matrices

The thermal density matrix for the complete harmonic oscillator is defined by

$\varrho_{\rm ho}(\beta)=\sum_{n=0}^{\infty}|n\rangle{\rm
e}^{-(n+1/2)\beta\hbar\omega}\langle n|.$ (9)

We will also need some related sums. One of them is the alternating sum

$\varrho_{\rm ho}^{\rm alt}(\beta)=\sum_{n=0}^{\infty}(-1)^{n}|n\rangle{\rm
e}^{-(n+1/2)\beta\hbar\omega}\langle n|,$ (10)

that one can readily evaluate:

$\varrho_{\rm ho}^{\rm alt}(\beta)={\rm i}\,\varrho_{\rm
ho}\left(\beta+\frac{{\rm i}\pi}{\hbar\omega}\right).$ (11)

Also necessary are the sums over all even/odd states

$\varrho_{\rm ho}^{\rm even/odd}(\beta)=\sum_{n=0\atop{\rm
n\;even/odd}}^{\infty}|n\rangle{\rm e}^{-(n+1/2)\beta\hbar\omega}\langle n|.$
(12)

Now $\varrho_{\rm ho}^{\rm even}(\beta)$ is best evaluated by inserting the
projector $(1+(-1)^{n})/2$ and then applying Eq. (11), while $\varrho_{\rm
ho}^{\rm odd}(\beta)=\varrho_{\rm ho}(\beta)-\varrho_{\rm ho}^{\rm
even}(\beta)$. We thus arrive at

$\varrho_{\rm ho}^{\rm even/odd}(\beta)=\frac{1}{2}\,\varrho_{\rm
ho}(\beta)\pm\frac{{\rm i}}{2}\,\varrho_{\rm ho}\left(\beta+\frac{{\rm
i}\pi}{\hbar\omega}\right),$ (13)

the even (resp. odd) sum corresponding to the plus (resp. minus) sign.

We can now express all the above density matrices in the position
representation. Let the matrix elements $\langle q|\varrho_{\rm
ho}(\beta)|q^{\prime}\rangle$ be denoted by $\varrho_{\rm
ho}(q,q^{\prime};\beta)$. It is known that [4]

$\varrho_{\rm ho}(q,q^{\prime};\beta)$ (14)
$=\frac{1}{\lambda_{0}}\frac{1}{\sqrt{2\pi\sinh(\beta\hbar\omega)}}\exp\left\\{\frac{-1}{2\lambda_{0}^{2}\sinh(\beta\hbar\omega)}\left[(q^{2}+{q^{\prime}}^{2})\cosh(\beta\hbar\omega)-2qq^{\prime}\right]\right\\}.$

Specifically we will need the diagonal matrix element $\langle q|\varrho_{\rm
ho}(\beta)|q\rangle$, also denoted by $\varrho_{\rm ho}(q;\beta)$:

$\varrho_{\rm
ho}(q;\beta)=\frac{1}{\lambda_{0}}\frac{1}{\sqrt{2\pi\sinh(\beta\hbar\omega)}}\exp\left[-\tanh\left(\frac{\beta\hbar\omega}{2}\right)\frac{q^{2}}{\lambda_{0}^{2}}\right].$
(15)

Using Eqs. (11) and (15), the diagonal of $\varrho_{\rm ho}^{\rm alt}(\beta)$
turns out to be

$\varrho_{\rm ho}^{\rm
alt}(q;\beta)=\frac{1}{\lambda_{0}}\frac{1}{\sqrt{2\pi\sinh(\beta\hbar\omega)}}\exp\left[-\coth\left(\frac{\beta\hbar\omega}{2}\right)\frac{q^{2}}{\lambda_{0}^{2}}\right],$
(16)

while for the density matrices (13) one finds

$\varrho_{\rm ho}^{\rm
even/odd}(q;\beta)=\frac{1}{2\lambda_{0}}\frac{1}{\sqrt{2\pi\sinh(\beta\hbar\omega)}}$
(17)
$\times\left\\{\exp\left[-\tanh\left(\frac{\beta\hbar\omega}{2}\right)\frac{q^{2}}{\lambda_{0}^{2}}\right]\pm\exp\left[-\coth\left(\frac{\beta\hbar\omega}{2}\right)\frac{q^{2}}{\lambda_{0}^{2}}\right]\right\\},$

the positive (resp. negative) sign corresponding to the even (resp. odd)
parity.

Finally, upon integration over $q\in\mathbb{R}$ we obtain the partition
functions

$Z_{\rm ho}^{\rm even/odd}(\beta)=\int_{-\infty}^{\infty}{\rm
d}q\,\varrho_{\rm ho}^{\rm even/odd}(q;\beta)=\frac{1}{4}\,{\rm
csch}\left(\frac{\beta\hbar\omega}{2}\right)\pm\frac{1}{4}\,{\rm
sech}\left(\frac{\beta\hbar\omega}{2}\right),$ (18)

in perfect agreement with their previous values in Eq. (7).

####  2.2.2 A thermally induced quantum of length

It is convenient to reexpress the diagonal matrix elements (15) as

$\varrho_{\rm
ho}(q;\beta)=\frac{1}{\lambda_{0}\sqrt{2\pi\sinh(\beta\hbar\omega)}}\exp\left[-\frac{q^{2}}{\lambda^{2}(\beta)}\right],$
(19)

where the temperature–dependent Gaussian width $\lambda(\beta)$ is the
following function:

$\lambda(\beta)=\lambda_{0}\sqrt{\coth\left(\frac{\beta\hbar\omega}{2}\right)}.$
(20)

Thus $\lambda(\beta)$ is a temperature–dependent length scale analogous to
(5), to which it reduces in the zero–temperature limit since
$\lim_{\beta\to\infty}\lambda(\beta)=\lambda_{0}$. Once properly normalised,
the Gaussian (19) gives the probability for finding the system at $Q=q$. One
finds

$\int_{-\infty}^{\infty}{\rm d}q\,\varrho_{\rm ho}(q;\beta)=Z_{\rm ho}(\beta)$
(21)

in nice agreement with the partition function (6). Thus averages within this
thermal ensemble will be computed with respect to the normalised distribution
$Z^{-1}_{\rm ho}(\beta)\varrho_{\rm ho}(q;\beta)$.

For the position operator $Q$ and its square $Q^{2}$ we find111We denote
thermal averages by round brackets.

$\left(Q\right)_{\rm ho}=\frac{1}{Z_{\rm
ho}(\beta)}\int_{-\infty}^{\infty}{\rm d}q\,q\varrho_{\rm ho}(q;\beta)=0$ (22)

and

$\left(Q^{2}\right)_{\rm ho}=\frac{1}{Z_{\rm
ho}(\beta)}\int_{-\infty}^{\infty}{\rm d}q\,q^{2}\varrho_{\rm
ho}(q;\beta)=\frac{1}{2}\lambda^{2}(\beta).$ (23)

Then the mean square deviation $\left(\Delta Q\right)_{\rm ho}^{2}$ reads

$\left(\Delta Q\right)_{\rm ho}^{2}=\left(Q^{2}\right)_{\rm
ho}-\left(Q\right)_{\rm ho}^{2}=\frac{1}{2}\lambda^{2}(\beta).$ (24)

It is meaningful to identify the above mean square deviation with one half the
square $L^{2}$ of the quantum of length for the complete oscillator:

$\left(\Delta Q\right)_{\rm ho}^{2}=\frac{1}{2}L^{2}.$ (25)

This allows one to solve neatly for the inverse temperature:222The notation
$\coth^{-1}(x)$, sometimes also written ${\rm arccoth}(x)$, stands for the
function inverse to $\coth(x)$.

$\beta_{\rm
ho}=\frac{2}{\hbar\omega}\coth^{-1}\left(\frac{L^{2}}{\lambda^{2}_{0}}\right).$
(26)

We should bear in mind that the averages (22) and (23) are thermal in nature,
because they are computed with respect to the thermal probability distribution
function $Z_{\rm ho}^{-1}(\beta)\varrho_{\rm ho}(q;\beta)$. This
notwithstanding, is it instructive to compare them to the quantum averages

$\langle n|Q|n\rangle=0,\qquad\langle
n|Q^{2}|n\rangle=\left(n+\frac{1}{2}\right)\lambda_{0}^{2}$ (27)

corresponding to the harmonic eigenstates $|n\rangle$: they match exactly when
$n=0$, with the sole replacement of the zero–temperature length scale
$\lambda_{0}$ with its thermal counterpart $\lambda(\beta)$.

Summarising: a zero–point length $L$ defines the temperature of the thermal
bath through Eq. (26). Conversely, one can intrepret the latter equation as
meaning that a thermal bath induces a quantum of length, as claimed. Instead
of string fluctuations as in ref. [7], here we have thermal fluctuations as
the origin of the zero–point length.

###  2.3 The truncated oscillator

So far we have only considered the complete oscillator. In the this section we
perform a similar analysis for the truncated oscillator.

####  2.3.1 Thermal density matrices

As suggested by the sum over dimensions (3), here the relevant thermal density
matrix to consider is

$\varrho_{d}(\beta)=\sum_{n=0}^{\infty}|d+2n\rangle{\rm
e}^{-(d+2n+1/2)\beta\hbar\omega}\langle d+2n|,$ (28)

which we conveniently reexpress as

$\varrho_{d}(\beta)=\sum_{n=0\atop{n=d\,{\rm mod}2}}^{\infty}|n\rangle{\rm
e}^{-(n+1/2)\beta\hbar\omega}\langle n|-\sum_{n=0\atop{n=d\,{\rm
mod}2}}^{d-1}|n\rangle{\rm e}^{-(n+1/2)\beta\hbar\omega}\langle n|.$ (29)

Above, the parity of the $n$’s summed over is the same as that of $d$.

As before we will denote the diagonal matrix elements $\langle
q|\varrho_{d}(\beta)|q\rangle$ by $\varrho_{d}(q;\beta)$. While the integral
$\int_{-\infty}^{\infty}{\rm d}q\varrho_{d}(q;\beta)$ must equal the partition
function $Z_{d}(\beta)$ already known by Eq. (8), the integrand
$\varrho_{d}(q;\beta)$ is so far unknown, and must be computed as the diagonal
of the density operator (29). In the end,
$Z_{d}^{-1}(\beta)\varrho_{d}(q;\beta)$ will provide us with the normalised
probability distribution function necessary to compute thermal averages in
this ensemble.

It turns out that the sought–for distribution function reads (see Eqs. (47)
and (54) of the Appendix)

$\frac{1}{Z_{d}(\beta)}\varrho^{\rm
even/odd}_{d}(q;\beta)=\frac{1}{Z_{d}(\beta)}\left[\varrho_{\rm ho}^{\rm
even/odd}(q;\beta)-f_{d}^{\rm even/odd}(q;\beta)\right],$ (30)

where “even/odd” in $\varrho^{\rm even/odd}_{d}(q;\beta)$ refers to the parity
of $d$. Above, $Z_{d}(\beta)$ is given by Eq. (8) regardless of parity,
$\varrho_{\rm ho}^{\rm even/odd}(q;\beta)$ is known by Eq. (17), and the
functions $f_{d}^{\rm even/odd}(q;\beta)$ are given by (see Eqs. (46) and (53)
of the Appendix)

$f_{d}^{\rm even/odd}(q;\beta)=\sum_{n=0\atop{n\,{\rm even/odd}}}^{d-1}{\rm
e}^{-(n+1/2)\beta\hbar\omega}\,|\langle n|q\rangle|^{2}.$ (31)

In (31), the parity of the $n$’s summed over is the same as that of $d$.

The thermal probability distribution functions (30) differ from their partner
(19) in one important respect, namely, by the terms $f^{\rm
even/odd}_{d}(q;\beta)$. The latter arise from the fact that the lowest–lying
energy eigenstate for the truncated oscillator is no longer the (Gaussian)
oscillator groundstate $|0\rangle$, but the excited eigenstate $|d\rangle$
instead. The finite sums $f_{d}^{\rm even/odd}(q;\beta)$ are nothing but the
thermal probability distributions associated with the oscillator eigenstates
lying below the state $|d\rangle$, with due care being taken of parity.

####  2.3.2 A thermally induced quantum of length

We will evaluate the thermal averages

$\left(Q\right)_{d}^{\rm
even/odd}=\frac{1}{Z_{d}(\beta)}\int_{-\infty}^{\infty}{\rm
d}q\,q\varrho_{d}^{\rm even/odd}(q;\beta)$ (32)

and

$\left(Q^{2}\right)_{d}^{\rm
even/odd}=\frac{1}{Z_{d}(\beta)}\int_{-\infty}^{\infty}{\rm
d}q\,q^{2}\varrho_{d}^{\rm even/odd}(q;\beta).$ (33)

As before, a (squared) quantum of length $L^{2}$ will be defined as (twice)
the mean square deviation of the position operator $Q$:

$\left(\left(\Delta Q\right)_{d}^{\rm
even/odd}\right)^{2}=\left(Q^{2}\right)_{d}^{\rm
even/odd}-\left(\left(Q\right)_{d}^{\rm
even/odd}\right)^{2}=\frac{1}{2}L^{2}.$ (34)

Use of Eqs. (17) and (27) immediately yields

$\left(Q\right)_{d}^{\rm even/odd}=0.$ (35)

However, the evaluation of $\left(Q^{2}\right)_{d}^{\rm even/odd}$ is
lengthier, and details have been relegated to the Appendix. The final result
is Eq. (62):

$\left(\left(\Delta Q\right)_{d}^{\rm
even/odd}\right)^{2}=\left(Q^{2}\right)_{d}^{\rm
even/odd}=\left[\lambda(2\beta)\right]^{2}+\lambda_{0}^{2}\left(d-\frac{1}{2}\right).$
(36)

As was the case for the complete harmonic oscillator, one can interpret the
quantum of length $L$ as possessing a thermal origin.

Two features of the above are worth mentioning. First, the
temperature–dependent Gaussian width of Eq. (20) appears evaluated at $2\beta$
rather than $\beta$. Moreover, there appears a temperature–independent
contribution proportional to $(d-1/2)$. These two features arise as
consequences of the truncation of the oscillator. The sum over dimensions (3)
starts at the value $d$, and it contains all higher dimensions of the same
parity as $d$. This parity requirement amounts to doubling the frequency
$\omega$ or, equivalently, the inverse temperature $\beta$.

##  3 Gravitational selfduality

In ref. [21] it has been conjectured that a strongly quantum, weakly
gravitational system must be dual to a weakly quantum, strongly gravitational
system.333A related proposal was put forward in ref. [9]. We claim that an
instance of this duality symmetry is provided by the following example.

For the complete oscillator of previous sections to implement the weakly
gravitational, strongly quantum regime, it suffices to impose two additional
requirements:
i) the mass $m$ is very small;
ii) the quantum number $n$ is low enough.

We will construct a dual system that is weakly quantum but strongly
gravitational. Consider the quantum system whose (dimensionless) Hamiltonian
$\tilde{H}$ is given by

$\tilde{H}=\left(\frac{H}{\hbar\omega}\right)^{-1},$ (37)

where $H$ is the harmonic Hamiltonian satisfying
$H|n\rangle=(n+1/2)\hbar\omega|n\rangle$. The (dimensionless) energy levels
$\tilde{E}_{n}$ of $\tilde{H}$ are

$\tilde{H}|n\rangle=\tilde{E}_{n}|n\rangle,\qquad\tilde{E}_{n}=\frac{1}{n+1/2},\qquad
n\in\mathbb{N}.$ (38)

Now $n$ was assumed small to guarantee the strongly quantum regime of the
initial oscillator; hence the dual system governed by $\tilde{H}$ implements
the weakly quantum behaviour. More precisely: small values of $n$ correspond
to eigenvalues of $H$ that are comparable to the oscillator vacuum energy;
this may be called the IR regime of the original oscillator. In the dual
system governed by $\tilde{H}$, the same small values of $n$ correspond to
high energies (as compared to the rest of the spectrum (38)); this may be
called the UV regime of the dual system. In this sense, the map (37) between
these two dual systems implements UV/IR duality.

Let the mass of this dual system be $\tilde{m}$. We need it to be large so
gravitational effects will also be large. Thus requiring

$m\tilde{m}=M_{P}^{2},$ (39)

where $M_{P}$ is the Planck mass, ensures the desired behaviour.

We can further elaborate on the gravitational aspects of the dual system (38).
The area operator defined as

$\tilde{A}=L^{2}\tilde{H},$ (40)

where $L$ is the quantum of length, has the quantised area levels

$\tilde{A}|n\rangle=\tilde{A}_{n}|n\rangle,\qquad\tilde{A}_{n}=\frac{L^{2}}{n+1/2},\qquad
n\in\mathbb{N}.$ (41)

We can place this dual system described by the area operator $\tilde{A}$ in
contact with an entropy reservoir at a constant value of the area; ideally
this reservoir would be a black hole with horizon area $A_{BH}$ and entropy

$S_{BH}=kA_{BH},\qquad k=\frac{k_{B}c^{3}}{4\hbar G}.$ (42)

Then the dual system can exchange quanta of entropy $k\tilde{A}_{n}$ with the
entropy reservoir. This is analogous to the oscillator exchanging energy
quanta $\hbar\omega$ with the thermal bath. Probabilities are distributed
among the different area levels according to the Boltzmann law
$\exp\left(-\tilde{A}_{n}/A_{BH}\right)$. Furthermore, upon multiplication by
$k$ as in Eq. (42), the area operator $\tilde{A}$ becomes the entropy operator
$\tilde{S}=k\tilde{A}$. Then the eigenvalue equation

$\tilde{S}|n\rangle=\tilde{S}_{n}|n\rangle,\qquad\tilde{S}_{n}=k\tilde{A}_{n}$
(43)

provides an instance of the entropic picture of quantum mechanics first
postulated in ref. [1]. The duality presented here can also be regarded as an
instance of that analysed in ref. [13].

##  4 Discussion

Gravity has been argued to be selfdual. Indeed gravity escapes the usual
pattern of an effective theory (in the Wilsonian sense). Any such theory at
low energy holds all the way up to a certain energy scale, beyond which it
breaks down and must be replaced by a more fundamental theory. Beginning now
with classical gravity at low energy, gravity turns quantum as energy is
increased until a certain characteristic scale is reached. Surprisingly,
however, gravity becomes once again classical beyond this scale; this is the
meaning of selfduality.

In relation to UV completeness [2], in ref. [21] it has been argued that a
UV/IR duality transformation must exist such that it will map the strongly
quantum, weakly gravitational regime of a given system into the strongly
gravitational, weakly quantum regime of a dual system. In this article we have
presented an explicit example of two systems exhibiting this UV/IR duality
property.

Our starting point was Eq. (3), which states that quantum–gravity properties
are conferred upon the $d$–dimensional propagator $G^{d}_{(L)}$ by an infinite
sum of propagators $G^{d+2n}_{(L=0)}$ in virtual dimensions; the latter are
all classical in the sense that they all carry $L=0$. This has led us to
interpret the zero–point length, the hallmark of quantum gravity, as a thermal
phenomenon. Novel attempts at unification [5, 6, 19, 23] also take the quantum
of length into account. Moreover, thermality should not surprise us given that
thermodynamics is central to a number of modern approaches to gravity [10, 16,
24, 25]. Reinterpreted from a thermal point of view, the duality invariance of
the quantum–mechanical propagator (3) is perfectly natural: the infinite sum
is over all propagators with a given parity. Definite parity implies duality
invariance; undefined parity does not.

We have found that, while zero–temperature dimensions are sharply defined,
thermal dimensions become averages over a statistical ensemble of virtual
dimensions of classical spacetimes. Transitions between different virtual
dimensions are induced by thermal fluctuations. Thus virtual dimensions
fluctuate, as they should in any quantum theory. We have modelled virtual
dimensions on the quantum number of a 1–dimensional harmonic oscillator.
However we have not altered the notion of a smooth spacetime manifold in any
other way: as stated in section 1, our analysis centers around the mesoscopics
of quantum gravity, where all quantum effects can be ascribed to a
nonvanishing quantum of length. The theory developed here is not of quantum
spacetime, but of the dimension of quantum spacetime in the mesoscopic regime.
The microscopic constituents, or atoms, of the dimension of a quantum–gravity
corrected spacetime $\mathbb{R}^{d}_{(L)}$ are the virtual dimensions $d+2n$
of all quantum–gravity free spacetimes $\mathbb{R}^{d+2n}_{(L=0)}$ for
$n\in\mathbb{N}$. A model for these virtual dimensions has been provided by
the energy levels of a truncated oscillator.

Altogether, we can view the thermality of the zero–point length as yet another
argument in favour of an atomistic, or granular, nature of quantum spacetime.

Acknowledgments Work funded by FEDER/MCIN under grant PID2021-128676OB-I00.

##  5 Appendix

###  5.1 Computation of $\varrho_{d}^{\rm even/odd}(q;\beta)$

Here we derive Eq. (30), analysing the cases $d=2k$ and $d=2k+1$ separately.

i) $d=2k$. Then the density matrix (29) becomes

$\varrho_{d=2k}(\beta)=\sum_{n=0\atop{n\,{\rm even}}}^{\infty}|n\rangle{\rm
e}^{-(n+1/2)\beta\hbar\omega}\langle n|-\sum_{n=0\atop{n\,{\rm
even}}}^{d-1}|n\rangle{\rm e}^{-(n+1/2)\beta\hbar\omega}\langle n|.$ (44)

The first sum equals the density operator $\varrho_{\rm ho}^{\rm even}(\beta)$
of Eq. (12), the corresponding diagonal being given in Eq. (17). Therefore the
diagonal entries of (44) read

$\varrho_{d=2k}(q;\beta)=\varrho_{\rm ho}^{\rm
even}(q;\beta)-\sum_{n=0\atop{n\,{\rm even}}}^{d-1}{\rm
e}^{-(n+1/2)\beta\hbar\omega}\,|\langle n|q\rangle|^{2}.$ (45)

Finally defining

$f_{d=2k}^{\rm even}(q;\beta)=\sum_{n=0\atop{n\,{\rm even}}}^{d-1}{\rm
e}^{-(n+1/2)\beta\hbar\omega}\,|\langle n|q\rangle|^{2},$ (46)

the sought–for diagonal matrix element is

$\varrho_{d=2k}(q;\beta)=\varrho_{\rm ho}^{\rm even}(q;\beta)-f^{\rm
even}_{d=2k}(q;\beta),$ (47)

where the right–hand side is explicitly known by Eqs. (17) and (46). As a
consistency check, integration over $q\in\mathbb{R}$ should produce the
partition function $Z_{d=2k}(\beta)$. Indeed:

$Z_{d=2k}(\beta)=Z_{\rm ho}^{\rm even}(\beta)-\sum_{n=0\atop{n\,{\rm
even}}}^{d-1}{\rm e}^{-(n+1/2)\beta\hbar\omega},$ (48)

on account of Eq. (18) and of the $|n\rangle$ being normalised eigenstates.
Now the finite geometric sum can be readily computed,

$\sum_{n=0\atop n\,{\rm even}}^{d-1}{\rm
e}^{-(n+1/2)\beta\hbar\omega}=\frac{1}{2}\left[{\rm
e}^{\beta\hbar\omega/2}-{\rm e}^{-(d-1/2)\beta\hbar\omega}\right]{\rm
csch}(\beta\hbar\omega),$ (49)

and Eqs. (18) and (49) yield the partition function $Z_{d=2k}(\beta)$

$Z_{d=2k}(\beta)=\frac{1}{2}\,{\rm e}^{-(d-1/2)\beta\hbar\omega}{\rm
csch}(\beta\hbar\omega),$ (50)

in happy agreement with its previous evaluation in Eq. (8).

ii) $d=2k+1$. Here the density matrix (29) becomes

$\varrho_{d=2k+1}(\beta)=\sum_{n=0\atop{n\,{\rm odd}}}^{\infty}|n\rangle{\rm
e}^{-(n+1/2)\beta\hbar\omega}\langle n|-\sum_{n=0\atop{n\,{\rm
odd}}}^{d-1}|n\rangle{\rm e}^{-(n+1/2)\beta\hbar\omega}\langle n|.$ (51)

The first sum equals the density operator $\varrho_{\rm ho}^{\rm odd}(\beta)$,
the corresponding diagonal being given in Eq. (17). Therefore the diagonal
entries of (51) read

$\varrho_{d=2k+1}(q;\beta)=\varrho_{\rm ho}^{\rm
odd}(q;\beta)-\sum_{n=0\atop{n\,{\rm odd}}}^{d-1}{\rm
e}^{-(n+1/2)\beta\hbar\omega}\,|\langle n|q\rangle|^{2},$ (52)

so defining

$f^{\rm odd}_{d=2k+1}(q;\beta)=\sum_{n=0\atop{n\,{\rm odd}}}^{d-1}{\rm
e}^{-(n+1/2)\beta\hbar\omega}\,|\langle n|q\rangle|^{2},$ (53)

the sought–for diagonal matrix element will be

$\varrho_{d=2k+1}(q;\beta)=\varrho_{\rm ho}^{\rm odd}(q;\beta)-f^{\rm
odd}_{d=2k+1}(q;\beta),$ (54)

where the right–hand side is known by Eqs. (17) and (53). As a check,
integration over $q\in\mathbb{R}$ should produce the partition function
$Z_{d=2k+1}(\beta)$. This is indeed the case:

$Z_{d=2k+1}(\beta)=Z_{\rm ho}^{\rm odd}(\beta)-\sum_{n=0\atop{n\,{\rm
odd}}}^{d-1}{\rm e}^{-(n+1/2)\beta\hbar\omega},$ (55)

again on account of Eq. (18) and of the normalisation of the $|n\rangle$.
Moreover,

$\sum_{n=0\atop n\,{\rm odd}}^{d-1}{\rm
e}^{-(n+1/2)\beta\hbar\omega}=\frac{1}{2}\left[{\rm
e}^{-\beta\hbar\omega/2}-{\rm e}^{-(d-1/2)\beta\hbar\omega}\right]{\rm
csch}(\beta\hbar\omega).$ (56)

Thus Eqs. (18) and (56) yield the partition function $Z_{d=2k+1}(\beta)$:

$Z_{d=2k+1}(\beta)=\frac{1}{2}\,{\rm e}^{-(d-1/2)\beta\hbar\omega}{\rm
csch}(\beta\hbar\omega),$ (57)

again in beautiful agreement with Eq. (8).

###  5.2 Computation of $\left(Q^{2}\right)_{d}^{\rm even/odd}$

By Eq. (30),

$\int_{-\infty}^{\infty}{\rm d}q\,q^{2}\varrho_{d}^{\rm
even/odd}(q;\beta)=\int_{-\infty}^{\infty}{\rm d}q\,q^{2}\varrho_{\rm ho}^{\rm
even/odd}(q;\beta)-\int_{-\infty}^{\infty}{\rm d}q\,q^{2}f_{d}^{\rm
even/odd}(q;\beta).$ (58)

Terms to evaluate are

$\int_{-\infty}^{\infty}{\rm d}q\,q^{2}\,\varrho_{\rm ho}^{\rm
even/odd}(q;\beta)$ (59)
$=\frac{\lambda_{0}^{2}}{8}\left[\coth\left(\frac{\beta\hbar\omega}{2}\right){\rm
csch}\left(\frac{\beta\hbar\omega}{2}\right)\pm\tanh\left(\frac{\beta\hbar\omega}{2}\right){\rm
sech}\left(\frac{\beta\hbar\omega}{2}\right)\right]$

where Eq. (17) has been applied, and

$\int_{-\infty}^{\infty}{\rm d}q\,q^{2}f_{d}^{\rm
even/odd}(q;\beta)=\lambda_{0}^{2}\sum_{n=0\atop{\rm
n\;even/odd}}^{d-1}\left(n+\frac{1}{2}\right){\rm
e}^{-(n+1/2)\beta\hbar\omega}$ (60)

after using Eqs. (27), (31). The finite geometric sums are straightforward to
evaluate as the derivatives, with respect to $\beta\hbar\omega$, of the sums
(49) and (56). Then adding together Eqs. (60) and (59) produces, after some
algebra,

$\int_{-\infty}^{\infty}{\rm d}q\;q^{2}\varrho_{d}^{\rm
even/odd}(q;\beta)=\frac{\lambda_{0}^{2}}{4}\,{\rm
e}^{-(d-1/2)\beta\hbar\omega}{\rm csch}(\beta\hbar\omega)\left[2d+2\,{\rm
coth}(\beta\hbar\omega)-1\right].$ (61)

Finally using Eq. (20) we conclude

$\left(Q^{2}\right)_{d}^{\rm
even/odd}=Z_{d}(\beta)^{-1}\int_{-\infty}^{\infty}{\rm
d}q\;q^{2}\varrho_{d}^{\rm even/odd}(q;\beta)$
$=\frac{\lambda_{0}^{2}}{2}\left[2d-1+2\,{\rm
coth}(\beta\hbar\omega)\right]=\left[\lambda(2\beta)\right]^{2}+\lambda_{0}^{2}\left(d-\frac{1}{2}\right).$
(62)

## References

  * [1] D. Acosta, P. Fernández de Córdoba, J.M. Isidro and J. Santander, An Entropic Picture of Emergent Quantum Mechanics, Int. J. Geom. Meth. Mod. Phys. 9 (2012) 1250048, arXiv:1107.1898 [hep-th]
  * [2] K. Crowther and N. Linnemann, Renormalizability, Fundamentality and a Final Theory: the Role of UV–Completion in the Search for Quantum Gravity, Brit. J. Phil. Sci. 70 (2019) 377, arXiv:1705.06777 [physics.hist-ph].
  * [3] E. Curiel, F. Finster and J.M. Isidro, Summing over Spacetime Dimensions in Quantum Gravity, Symmetry 12 (2020) 138, arXiv:1910.11209 [gr-qc].
  * [4] W. Dittrich and M. Reuter, Classical and Quantum Dynamics, Springer (Berlin) (2020).
  * [5] F. Finster and M. Jokel, Causal Fermion Systems: an Elementary Introduction to Physical Ideas and Mathematical Concepts, in Progress and Visions in Quantum Theory in View of Gravity (F. Finster, D. Giulini, J. Kleiner, J. Tolksdorf, eds.), Birkhäuser, Basel (2020), arXiv:1908.08451 [math-ph].
  * [6] F. Finster, M. Jokel and C. Paganini, A Mechanism of Baryogenesis for Causal Fermion Systems, Class. Quant. Grav. 39 (2022) 165005, arXiv:2111.05556 [gr-qc].
  * [7] M. Fontanini, E. Spallucci and T. Padmanabhan, Zero–Point Length from String Fluctuations, Phys. Lett. B633 (2006) 627, arXiv:hep-th/0509090.
  * [8] L. Garay, Quantum Gravity and Minimum Length, Int. J. Mod. Phys. A10 (1995) 145, arXiv:gr-qc/9403008.
  * [9] J.M. Isidro, Semiclassical Expansions, the Strong Quantum Limit, and Duality, Mod. Phys. Lett. A20 (2005) 2913, arXiv:quant-ph/0502018.
  * [10] T. Jacobson, Thermodynamics of Spacetime: the Einstein Equation of State, Phys. Rev. Lett. 75 (1995) 1260, arXiv:gr-qc/9504004.
  * [11] C. Kiefer, Quantum Gravity, Oxford University Press (2012).
  * [12] C. Kiefer, Quantum Gravity—an Unfinished Revolution, arXiv:2302.13047 [gr-qc].
  * [13] V. Mondal, Duality Principle of the Zero–Point Length of Spacetime and Generalized Uncertainty Principle, Eur. Phys. Lett. 132 (2020) 10005.
  * [14] T. Padmanabhan, Duality and Zero–Point Length of Spacetime, Phys. Rev. Lett. 78 (1997) 1854, arXiv:hep-th/9608182.
  * [15] T. Padmanabhan, Hypothesis of Path Integral Duality. I. Quantum Gravitational Corrections to the Propagator, Phys. Rev. D57 (1998) 6206.
  * [16] T. Padmanabhan, Gravity and/is Thermodynamics, Current Science 109 (2015) 2236, arXiv:1512.06546 [gr-qc].
  * [17] T. Padmanabhan, Thermality of the Rindler Horizon: a Simple Derivation from the Structure of the Inertial Propagator, Phys. Rev. D100 (2019) 045024, arXiv:1905.08263 [gr-qc].
  * [18] T. Padmanabhan, World–Line Path Integral for the Propagator Expressed as an Ordinary Integral: Concept and Applications, Found. Phys. 51 (2021) 35, arXiv:2104.07041 [gr-qc].
  * [19] S. Raj and T. Singh, A Lagrangian with $E_{8}\times E_{8}$ Symmetry for the Standard Model and Pre–Gravitation I. —The Bosonic Lagrangian, and a Theoretical Derivation of the Weak Mixing Angle, arXiv:2208.09811 [hep-ph].
  * [20] K. Rajeev and T. Padmanabhan, Exploring the Rindler Vacuum and the Euclidean Plane, J. Math. Phys. 61 (2020) 062302, arXiv:1906.09278 [gr-qc].
  * [21] T. Singh, Noncommutative Gravity, a ‘No Strings Attached’ Quantum–Classical Duality, and the Cosmological Constant Puzzle, Gen. Rel. Grav. 40 (2008) 2037, arXiv:0805.2124 [gr-qc].
  * [22] T. Singh, Quantum Gravity, Minimum Length, and Holography, Pramana 95 (2021) 1, arXiv:1910.06350 [gr-qc].
  * [23] T. Singh, Why Do Elementary Particles Have Such Strange Mass Ratios?—The Importance of Quantum Gravity at Low Energies, MDPI Physics 4 (2022) 948, arXiv:2209.03205 [physics.gen-ph].
  * [24] E. Verlinde, On the Origin of Gravity and the Laws of Newton, JHEP 04 (2011) 029, arXiv:1001.0785 [hep-th].
  * [25] E. Verlinde, Emergent Gravity and the Dark Universe, SciPost Phys. 2 (2017) 016, arXiv:1611.02269 [hep-th].


[allpages,color=gray!50,angle=45,scale=2,xpos=0,ypos=0]Preprint

#  Restats: A Test Coverage Tool for RESTful APIs

Davide Corradini1, Amedeo Zampieri2, Michele Pasqua3 and Mariano Ceccato4
Department of Computer Science
University of Verona – Verona, Italy
Email<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>
###### Abstract

Test coverage is a standard measure used to evaluate the completeness of a
test suite. Coverage is typically computed on source code, by assessing the
extent of source code entities (e.g., statements, data dependencies, control
dependencies) that are exercised when running test cases. When considering
REST APIs, an alternative perspective to assess test suite completeness is
with respect to the service definition.

This paper presents Restats, a test coverage tool for REST APIs that supports
eight state-of-the-art test coverage metrics with a black-box perspective,
i.e., only relying on the OpenAPI interface specification of the REST API
under test. In fact, metrics are computed by only observing the HTTP requests
and responses occurring at testing time, and no access to source/compiled code
of the REST API is required.

These coverage metrics come in handy for: (i) developers and test engineers
working at development and maintenance tasks; (ii) stakeholders and customers
who want to evaluate the completeness of acceptance tests; (iii) researches
interested in comparing different automated test case generation strategies.

Restats GitHub repository: https://github.com/SeUniVr/restats

Restats demo video: https://smarturl.it/restats-demo

###### Index Terms:

REST API, Test coverage, Software testing

Paper accepted for publication in the proceedings of:_37 ${}^{\text{th}}$ IEEE
International Conference on Software Maintenance and Evolution (ICSME
2021)_The present document is the preliminary version of the work prior to
peer-review. The final version can be found on the publisher website.

##  I Introduction

A RESTful API (or REST API for short) is an API that respects the REST
(REpresentational State Transfer) architectural style [1]. REST APIs provide a
uniform interface to create, read, update and delete (CRUD) a resource. A
resource is generally identified by an HTTP URI, and CRUD operations are
usually mapped to the HTTP methods POST, GET, PUT and DELETE to the resource
URI.

REST APIs are becoming a de-facto industrial standard to interconnect
different computer systems. They are used in a quite wide set of contexts,
e.g., when exchanging data with the cloud [2], when connecting smartphone apps
to their corresponding server [3], for identity provisioning [4] and when
inter-operating different banks [5].

The correct integration among computer systems, potentially carried out by
different parties, is a critical point. To monitor correct integrations and
promptly reveal implementation defects, several tools are available for
testing computer systems through their REST APIs. These tools include not just
extensions to general purpose testing frameworks (e.g., REST-Assured [6], that
extends the popular JUnit testing framework with REST API specific features),
but also brand-new tools, explicitly developed to test REST APIs (e.g.,
Postman [7] and SoapUI [8]). However, they still require developers to spend
valuable time in manually coding test cases. Additionally, to mitigate the
cost of manually writing all the test cases, the research community proposed
several approaches to automatically generate test cases for REST APIs (e.g.,
QuickREST [9], RESTler [10] and RestTestGen [11]).

Despite several approaches being available, either to generate and run test
cases on REST APIs, to the best of our knowledge no tool is available to
measure test coverage, i.e., to quantify the extent of a REST API that has
been subject to testing and what part of it still requires more tests. To fill
this gap, we propose Restats, a tool meant to monitor the whole REST API
testing process and compute the corresponding comprehensive coverage report.

Restats is meant to be helpful in many contexts.

  * •

Supporting software developers when developing and/or evolving software
systems that expose a REST API. In fact, before publishing an update, a REST
API should be carefully assessed and its tests should meet an adequate level
of coverage.

  * •

Supporting stakeholders and customers in evaluating REST APIs delivered by
contractors or by third parties, before fully committing and adopting them. In
fact, stakeholders might be interested in assessing the coverage of their
acceptance tests before accepting a product.

  * •

Supporting researchers in conducting experimental surveys, when comparing
different tools and alternative strategies to automatically generate test
cases for REST APIs. In fact, an approach that delivers test cases with higher
coverage might have potentially higher chances of exposing defects in the
implementation of a REST API.

Despite theoretical metrics have been proposed to measure REST APIs test
coverage [12], no implementation is available to actually compute them. So,
although theoretically sound, in practice REST APIs test coverage metrics
convey limited value to developers and practitioners. To the best of our
knowledge, Restats is the first tool that computes coverage metrics for REST
API test suites.

This paper is organized as follows. In Section II we present the architecture
of Restats and the implemented coverage metrics. In Section III we show how to
use Restats on a case study, reporting the output of the tool (i.e., the
computed coverage metrics) for the REST API under test. Section IV presents
related work and, finally, Section V closes the paper.

##  II Architecture

Restats computes REST API test coverage metrics based on the theoretical
measurement framework proposed by Martin-Lopez et al. [12]. An overview of the
architecture of Restats is shown in Figure 1. The tool requires as input the
REST API definition file (called OpenAPI specification or Swagger) and a
network log containing the HTTP messages exchanged between the API and the
testing tool. An external Network logger is in charge of collecting these
messages. In particular, we used the HTTP proxy offered by the Burp Suite
[13].

The network log is consumed by the _Data Collection module_ , in which raw
inputs are rearranged, processed and written to a database. Eventually, the
_Metrics Computation module_ computes the coverage metrics using data from the
database and fills in a final coverage report.

Figure 1: Restats architecture overview.

###  II-A Network Logger

To collect testing input and output, we use the _Burp Suite_ [13]. It works as
a proxy and collects all the HTTP messages exchanged between the testing tool
and the REST API under test. Then, using the _burp-dump_ [14] extension, we
dump all HTTP requests and HTTP responses as plain text. Note that Restats is
not dependent on the Burp Suite; any alternative tool that can emit a plain-
text log of HTTP messages is fine. The user can choose an alternative
component that best fits his/her needs to gather request/response samples, as
long as they can be dumped as text file(s). HTTP messages dumps are expected
to follow a naming convention to pair requests and responses in the form
$(\text{\emph{n-request.txt}},\text{\emph{n-response.txt}})$, with a
progressive identifier _n_.

###  II-B Data Collection Module

This module is used to parse network dumps. Given the textual HTTP dumps as
input, it extracts all the information needed for the coverage computation
(e.g., request paths, HTTP methods, response status codes). Then, it populates
a SQLite database.

To this aim, HTTP requests and responses are parsed with the following
strategies.

HTTP requests and responses might contain arbitrary content types in their
body, either text (e.g., JSON, XML) or binary (e.g., JPEG, MP4), leading to
possible message body parsing failures. Therefore, message body is safely
parsed as a binary content. A second parser is called for the message body,
depending on the content type declared in the message header. At the moment,
only JSON payloads are supported. Hence, if a different format is found in the
header, the payload is ignored.

Not all HTTP requests match a corresponding HTTP response. In fact, some
requests could have been ignored due to a too high server load or a server
crash. Even if unpaired, these orphan requests are still recorded in the
database. Indeed, they are used for the computation of input coverage metrics,
which do not require a matching response.

The OpenAPI standard allows path templating, i.e., they allow to specify input
data as part of the called URL. Therefore, Restats has to be able to group and
recognize HTTP requests belonging to the same path template. This task is
challenging to carry out in the case of OpenAPI specifications with colliding
paths. For instance, /users/{id} (where {id} is a placeholder for any string)
and /users/auth seems referring to the same path, and auth could be
interpreted as both a specific path and a user id.

All the fields of HTTP requests and responses are then saved in the database
to be quickly accessed by the subsequent module. We decided to use a SQLite
database because of its performance, portability and configuration-less
features.

###  II-C Metrics Computation Module

This module takes the database populated by the Data Collection module and the
OpenAPI specification as input. The database is used to recognize which
elements of the REST API have been tested, while the OpenAPI is used to list
all the potentially testable elements. The metrics are computed as the ratio
of the number of tested elements to the total number of elements documented in
the OpenAPI specification.

Following the approach of Martin-Lopez et al. [12], metrics are divided into
input and output metrics. Input metrics are computed based on the observed
HTTP requests sent to the REST API under test, and comprise the following.

  * •

Path coverage: ratio of the number of tested paths to the total number of
paths documented in the OpenAPI specification.

  * •

Operation coverage: ratio of the number of tested operations to the total
number of operations.

  * •

Parameter coverage: ratio of the number of input parameters used by test cases
to the total number of parameters.

  * •

Parameter value coverage: ratio of the number of the exercised parameter
values to the total number of possible values that parameters can assume. This
metric applies, at the moment, only to domain-limited parameters such as
boolean and enum types.

  * •

Request content-type coverage: ratio of the number of tested content-types to
the total number of accepted content-types. This metric is computed only when
operations content-types have no wildcard (e.g., application/*), because
otherwise the number of accepted content-types would be unbounded.

Similarly, the following output metrics are computed based on the observed
HTTP responses, emitted by the REST API under test.

  * •

Status code class coverage: a test suite reaches 100% status code class
coverage when it is able to trigger both correct status code (i.e., the 2XX
class) and erroneous status codes (i.e., 4XX and 5XX classes).

  * •

Status code coverage: the ratio of the number of obtained status codes to the
total number of status codes documented in the OpenAPI specification.

  * •

Response content-type coverage: the ratio of the number of obtained content-
types to the total number of response content-types documented in the OpenAPI
specification. As for the input case, this metric is computed only when
specific content-types are defined with no wildcard.

Restats also automatically computes Test Coverage Levels (TCLs), as defined in
Martin-Lopez et al. [12]. The TCL is a summary coverage indicator, ranking
test suites based on the score they obtain for the defined metrics. TCLs are
incremental: to achieve a TCL, the test suite also has to satisfy the
requirements for the lower levels. In particular:

is the base level, with no coverage requirements;

requires the path coverage to be 100%;

requires the operation coverage to be 100%;

requires both request and response content-type coverages to be 100%;

requires parameters and status code classes coverages to be 100%;

requires the status code coverage to be 100%;

requires the body properties coverage to be 100%;

requires the operation flow coverage to be 100%.

##  III Running Example

To better understand the use of Restats, we now present a running example
involving a REST API and its (manually written) test suite, for which Restats
will compute coverage metrics.

###  III-A The Pet Store and Its Test Suite

The case study REST API is Pet Store, a service to manage a collection of
pets. The specification of the API describes the following 7 operations,
arranged in 4 endpoints:

to enter data of a new pet;

to retrieve a list of all stored pets;

to update data of a pet;

to search pets by status;

to search pets by tag;

to retrieve a specific pet;

to delete all the data for a specific pet.

We have manually prepared an example test suite for the Pet Store API
consisting of five test cases based on the business logic of the API, one of
which is reported in Listing 1. They are five HTTP requests that can be
executed, for instance, by means of Postman [7].

The OpenAPI specification of the Pet Store and the dump of the HTTP
requests/responses generated by the test suite are available in the example
folder of the Restats repository.

⬇

POST /v2/pet HTTP/1.1

Host: localhost:8080

Accept: application/json

Content-Type: application/json

Content-Length: 76

{

"name": "doggie",

"photoUrls": ["myphoto.com/doggie"]

}

Listing 1: A test case of our test suite.

The first two tests exercise the GET  /pet operation. They obtain a
successful response (200 status code). The third and fourth tests exercise the
POST  /pet operation, and they obtain a 200 and 500 status code,
respectively. The 500 internal server error is caused by a request (in Listing
1) that misses the category mandatory parameter. This erroneous request is not
properly handled by the Pet Store API, that throws an exception. Finally, a
fifth request to the PATCH  /pet operation obtains a 405 status code because
such endpoint does not actually support the PATCH method: the test engineer
would have wanted to use the PUT method instead, that operates similarly.

###  III-B Configuring and Launching Restats

The five requests of our test suite, and the five related responses, have been
recorded by the Burp proxy. Using the burp-dump plugin we exported the plain-
text dumps to the dumps folder. Afterwards, we configured Restats with the
following JSON configuration file (config.json):

⬇

{

"modules": "all",

"specification": "/path/to/petstore.json",

"dumpsDir": "/path/to/dumps",

"reportsDir": "/path/to/reports",

"dbPath": "/path/to/database.sqlite"

}

We configured the tool with the modules to run (modules); where it can find
the OpenAPI specification of the REST API under test (specification); where we
have stored the dumps exported from Burp (dumpsDir111Absolute paths should be
preferred for higher compatibility.); where we want the output reports to be
stored (reportsDir); and where to place the SQLite database (dbPath).

With the modules parameter set to all, we chose to run all the Restats
modules. It is possible to run individually either the data collection module
(with dataCollection), or the metrics computation module (with statistics).

Eventually, we have launched the tool from the folder restats, with the
command: python3  app.py.

###  III-C Restats Reports

Once the execution of Restats is complete, its output is available in the
chosen report folder as a collection of nine report JSON files. The file
stats.json summarizes the computed statistics for all the coverage metrics and
the TCL of the test suite. The other eight files, named after the eight
coverage metrics, describe in detail the output for each metric.

⬇

{

...

"operationCoverage": {

"raw": {

"documented": 7,

"documentedAndTested": 2,

"totalTested": 3

},

"rate": 0.2857142857142857

},

...

"TCL": 0

}

Listing 2: Part of stats.json regarding the operation coverage metric.

Listing 2 shows a fragment of stats.json with the operation coverage metric
and the computed TCL. The remaining metrics are not shown for space reasons,
however, they have the same structure.Observing Listing 2, we can note that
two operations, out of the seven documented in the specification, have been
tested. Indeed, the computed rate is $0.2857$, that corresponds to
$\frac{2}{7}$. In particular, the documented field reports the number of
operations documented in the specification. The documentedAndTested field
reports the number of operations that have been tested among those documented
in the specification. Finally, the totalTested field reports the total number
of tested operations, including those that are _not_ documented in the
specification. This last field was included to reveal test cases that operate
(knowingly or unknowingly) beyond what is documented.

Listing 3 shows the content of one of the eight detailed reports
(specifically, the operation coverage metric report) that Restats emits for
each coverage metric. The documentedAndTested section reports what operations
have been tested, among those documented in the specification. The
documentedAndNotTested section reports what operations, among those documented
in the specification, have not been tested. Finally, undocumented operations
that were tested, if any, will be reported in the notDocumentedAndTested
section.

###  III-D How Are These Reports Useful?

The reports computed by Restats come in handy in a number of ways. By looking
at Listing 2, we could easily identify that not all the available operations
in the REST API have been properly tested. Only two operations out of seven
have been tested, which prevents the test suite to be considered complete.
This should motivate a developer to write more test cases to test, at least
once, all the documented operations.

Moreover, the notDocumentedAndTested section in Listing 3 indicates that the
developer inappropriately used the PATCH method with the /pet endpoint in a
test case.

⬇

{

"documentedAndTested": {

"/pet": ["get", "post"]

},

"documentedAndNotTested": {

"/pet": ["put"],

"/pet/findByStatus": ["get"],

"/pet/findByTags": ["get"],

"/pet/{petId}": ["get", "delete"]

},

"notDocumentedAndTested": {

"/pet": ["patch"]

}

}

Listing 3: The detailed output for the operation coverage metric.

##  IV Related Work

In literature, several tools have been presented to measure test coverage for
specific domains, like Java programs (the JaCoCo library [15]) or Android apps
(ACVTool [16] and COSMO [17]). However, to the best of our knowledge, no tool
has been presented for assessing the coverage of REST APIs test cases. This
might be due to the fact that, often, coverage tools rely on _code coverage_ ,
which is not always applicable in the context of REST APIs. Indeed, API source
code analysis might be complex, e.g., when a micro-service architecture
includes many dynamically allocated components possibly from different
vendors; or not feasible, e.g., in the case of closed-source APIs. The only
work dealing with test coverage of REST APIs is the theoretical framework of
Martin-Lopez et al. [12], (presented as background in Section II), but it does
not come with a usable implementation.

Concerning REST API testing, we can find semi-automatic tools (like REST-
Assured [6], SoapUI [8], Postman [7]), but they do not provide a measure for
assessing test case coverage. Similarly, automatic test case generation tools
for REST APIs (like QuickREST [9], RESTler [10] RestTestGen [11]), report what
operations could be tested and what status code have been observed in the
responses, but in a tool-specific way that does not follow a common formal
definition of test coverage.

##  V Conclusion

In conclusion, the present paper introduce Restats, a tool that implements the
test coverage metrics originally proposed by Martin-Lopez et al. [12]. Restats
computes the coverage metrics of the REST API under test adopting a black-box
perspective, namely relying only on the OpenAPI specification of the REST API
under test. In particular, Restats computes the coverage metrics based on the
network log that contains the plain-text HTTP requests and responses exchanged
when running test cases. This makes our tool easily adaptable to multiple
contexts, supporting services written in any programming language, and any
testing technology and tool.

Restats can be used to measure test case coverage in multiple adoption
scenarios, either by programmers at development time or by stakeholders before
deployment in production. Finally, Restats can help researchers in assessing
automated test case generation techniques, highlighting strengths and
weaknesses of the adopted generative approach. Indeed, Restats has been used
in [18] to compare four state-of-the-art black-box REST APIs testing tools.

## References

  * [1] R. T. Fielding, _Architectural styles and the design of network-based software architectures_. University of California, Irvine Doctoral dissertation, 2000, vol. 7.
  * [2] F. Petrillo, P. Merle, N. Moha, and Y.-G. Guéhéneuc, “Are rest apis for cloud computing well-designed? an exploratory study,” in _Service-Oriented Computing_ , Q. Z. Sheng, E. Stroulia, S. Tata, and S. Bhiri, Eds. Cham: Springer International Publishing, 2016, pp. 157–170.
  * [3] A. Belkhir, M. Abdellatif, R. Tighilt, N. Moha, Y.-G. Guéhéneuc, and E. Beaudry, “An observational study on the state of rest api uses in android mobile applications,” in _2019 IEEE/ACM 6th International Conference on Mobile Software Engineering and Systems (MOBILESoft)_ , 2019, pp. 66–75.
  * [4] simplecloud.info. SCIM. [Online]. Available: http://www.simplecloud.info/
  * [5] Open Bank Project. OBP Middleware. [Online]. Available: https://www.openbankproject.com/openbankingmiddleware/
  * [6] J. Haleby. REST Assured. [Online]. Available: http://rest-assured.io/
  * [7] Postman Inc. Postman. [Online]. Available: https://www.getpostman.com/
  * [8] SmartBear Software. SoapUI. [Online]. Available: https://www.soapui.org/
  * [9] S. Karlsson, A. Čaušević, and D. Sundmark, “QuickREST: Property-based test generation of OpenAPI-described RESTful APIs,” in _2020 IEEE 13th International Conference on Software Testing, Validation and Verification (ICST)_ , 2020, pp. 131–141.
  * [10] V. Atlidakis, P. Godefroid, and M. Polishchuk, “Restler: Stateful rest api fuzzing,” _2019 IEEE/ACM 41st International Conference on Software Engineering (ICSE)_ , pp. 748–758, 2019.
  * [11] E. Viglianisi, M. Dallago, and M. Ceccato, “Resttestgen: Automated black-box testing of restful apis,” _2020 IEEE 13th International Conference on Software Testing, Validation and Verification (ICST)_ , pp. 142–152, 2020.
  * [12] A. Martin-Lopez, S. Segura, and A. Ruiz-Cortés, “Test coverage criteria for restful web apis,” in _Proceedings of the 10th ACM SIGSOFT International Workshop on Automating TEST Case Design, Selection, and Evaluation_ , 2019, pp. 15–21.
  * [13] PortSWigger. Burp suite. [Online]. Available: https://portswigger.net/burp
  * [14] crashgrindrips. Burp-Dump. [Online]. Available: https://github.com/crashgrindrips/burp-dump
  * [15] EclEmma. JaCoCo code coverage library. [Online]. Available: https://www.eclemma.org/jacoco/
  * [16] A. Pilgun, O. Gadyatskaya, S. Dashevskyi, Y. Zhauniarovich, and A. Kushniarou, “An effective android code coverage tool,” in _Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security_ , ser. CCS ’18. New York, NY, USA: Association for Computing Machinery, 2018, pp. 2189–2191. [Online]. Available: https://doi.org/10.1145/3243734.3278484
  * [17] A. Romdhana, M. Ceccato, G. C. Georgiu, A. Merlo, and P. Tonella, “COSMO: code coverage made easier for android,” in _14th IEEE Conference on Software Testing, Verification and Validation, ICST 2021, Porto de Galinhas, Brazil, April 12-16, 2021_. IEEE, 2021, pp. 417–423. [Online]. Available: https://doi.org/10.1109/ICST49551.2021.00053
  * [18] D. Corradini, A. Zampieri, M. Pasqua, and M. Ceccato, “Empirical comparison of black-box test case generation tools for RESTful APIs,” in _21st IEEE International Working Conference on Source Code Analysis and Manipulation, SCAM 2021, Luxembourg City, Luxembourg, September 27 - September 28_ , 2021.


# MoisesDB: A Dataset for Source Separation beyond 4-Stems

###### Abstract

In this paper, we introduce the MoisesDB dataset for musical source
separation. It consists of 240 tracks from 45 artists, covering twelve musical
genres. For each song, we provide its individual audio sources, organized in a
two-level hierarchical taxonomy of stems. This will facilitate building and
evaluating fine-grained source separation systems that go beyond the
limitation of using four stems (drums, bass, other, and vocals) due to lack of
data. To facilitate the adoption of this dataset, we publish an easy-to-use
Python library to download, process and use MoisesDB. Alongside a thorough
documentation and analysis of the dataset contents, this work provides
baseline results for open-source separation models for varying separation
granularities (four, five, and six stems), and discuss their results.

##  1 Introduction

Source separation is the task of splitting an audio signal into separate
signals for each signal source. For music, the signal sources are the
instruments that appear in the track, e.g.: guitar, bass, piano, drums, and
vocals.

Music source separation is a relevant task within music information retrieval.
While it can be used as a pre-processing step for other tasks (e.g. voice
separation for f0 tracking), source separation enables diverse applications on
arbitrary music tracks that would need manual creation of stems otherwise. For
example, in the context of music education, the creation of play-along tracks
for students, facilitating by-ear transcription of relevant instruments, or
automatic creation of karaoke backing tracks. Such applications are relevant
for industry, as demonstrated by initiatives like the demixing
challenges111https://www.aicrowd.com/challenges/music-demixing-challenge-
ismir-2021/sound-demixing-challenge-2023.

State-of-the-art source separation systems are usually built using neural-
network-based machine learning systems, trained in a supervised way [1, 2, 3].
In order to train these systems, a large amount of training data is required.
For supervised approaches, the training data is represented by pairs of i. a
mixed audio track and ii. a set of so-called stems that, when combined,
recreate the audio track. Stems are audio signals containing only one (or a
group of related) sources, i.e. instruments. A pair of one mixed track and its
corresponding stems constitutes one training example.

Besides the large amount of manual work involved in any large-scale dataset
creation, this kind of data is especially hard to come by for several reasons.
Whenever dealing with music audio data, legal issues may arise by collecting
and sharing a dataset. The copy and distribution rights for most music are
held by music publishers and record labels and are enforced rigorously.
Obtaining the audio recordings for the individual instruments (stems) along
with the final mix may expose recording, mixing, and mastering techniques of
the recording studios, responsible for producing a track, which is why
recording studios may oppose the publishing of stems in order to keep their
trade secrets. Finally, processing, exporting, and organizing stems from
recording projects (often from a digital audio workstation) is a considerable
task. Usually, these recording projects are created without considering the
requirement of exporting instrument stems. All these factors hinder the
creation and release of multitrack and stem datasets.

Dataset | Year | No. of Tracks | Stems / Multitracks
---|---|---|---
MedleyDB [4] | 2014 | 122 | Multitracks
MedyleyDB-V2 [5] | 2016 | 196 | Multitracks
DSD100 [6] | 2015 | 100 | 4 Stems
MUSDB18 [7] | 2017 | 150 | 4 Stems
MUSDB18-HQ [8] | 2019 | 150 | 4 Stems
MoisesDB | 2023 | 240 | Multitracks
Table 1: Overview of publicly released datasets for music source separation.
The datasets are grouped according to the set of tracks they contain. For
example, DSD100 is a subset of MUSDB18. Additionally, 46 songs from MedleyDB
are also used in MUSDB18. Figure 1: Artist distribution of MoisesDB. Figure 2:
Genre distribution of MoisesDB.

While there exist source separation datasets aimed at a specific task, like
vocal separation [9, 10], these are only of limited relevance for the more
general task of splitting audio tracks up into stems. A majority of the
existing stem datasets [6, 8] use a limited taxonomy of four stems, namely:
vocals, drums, bass, and other. While this has become a de-facto standard for
works on source separation [1, 2, 3] due to the availability of data and
comparability of results, this is a strong limitation of the resulting models.
For many practical applications, separation of other, widely used instruments
may be relevant: e.g. guitars, keys, strings, etc.

Datasets featuring individually recorded tracks (multitrack, e.g. [5]), as
well as other collections of multitrack recordings, like _Open Multitrack
Testbed_ [11], do exist. However, these are not prepared to be used for source
separation, out of the box, and may come with license restrictions. Looking at
recent source separation publications, we see that non-public data usually
represents the bulk of training data (e.g. Bean dataset [12] in [1]; 800
tracks of undisclosed source in [3]). This hints that by only using publicly
available data, it is not possible to train competitive source separation
models. Thus, there is a need for more free data featuring a more detailed
taxonomy, in order to be able to successfully train and test robust source
separation models with the capability to separated more stems.

To improve the current situation, we introduce MoisesDB, a multitrack dataset
featuring track annotations and a taxonomy to group individual tracks into
stems. This dataset is offered free of charge for non-commercial research use
only. It consists of 240 music tracks from different artists and genres with a
total duration of over 14 hours. Along with the dataset, we provide baseline
performance values for state-of-the-art source separation systems.

The remainder of this work is structured as follows: Section 2 covers related
work and contrasts it with the dataset presented here. Section 3 discusses the
details of MoisesDB. Section 4 introduces baseline performance evaluation
statistics using freely available source separation models. Finally, Section 5
provides concluding remarks.

Stem |  Track
---|---
Bass |  Bass Guitar, Bass Synthesizer, Contrabass
Bowed Strings |  Cello, Cello Section, Other Strings, String Section, Viola Section, Viola Solo
Drums |  Cymbals, Drum Machine, Full Acoustic Drumkit, Hi-Hat, Kick Drum, Overheads, Snare Drum, Toms
Guitar |  Acoustic Guitar, Clean Electric Guitar, Distorted Electric Guitar
Other |  Fx
Other Keys |  Organ, Electric Organ, Other Sounds, Synth Lead, Synth Pad
Other Plucked |  Banjo/Mandolin/Ukulele/Harp
Percussion |  A-Tonal Percussion, Pitched Percussion
Piano |  Electric Piano, Grand Piano
Vocals |  Background Vocals, Lead Female Singer, Lead Male Singer, Other
Wind |  Brass, Flutes, Other Wind, Reeds
Table 2: MoisesDB stem-track taxonomy used to organize individual tracks into
stems. Figure 3: Number of stems per track in MoisesDB.

##  2 Related Work

In the past, several multitrack and stem datasets have been published by the
community (see Tab. 1). This section will discuss their properties and set the
context for the dataset presented in this work. Since the main focus of this
work is source separation into as many stems as possible, single stem focused
datasets (e.g. voice separation datasets [9, 10]) will be mainly ignored.

In 2014, Bittner et al. released the _MedleyDB_ dataset [4], which comprises
122 songs in multitrack format. It was extended by 74 songs (totalling 196
songs) in 2016, and published as _MedleyDB 2.0_ [5]. The dataset provides
audio files in a hierarchical structure, where the final mix is split into
multiple stems, each containing numerous raw audio sources (multitracks).
Besides the multitrack data, the MedleyDB dataset provides an extensive list
of metadata, such as artist, track name, origin, genre, and producer, amongst
others. Additionally it provides multiple annotations, such as instrument
activation, melody, and pitch.

Figure 4: Distribution of stems in MoisesDB.

    from moisesdb.dataset import MoisesDB

    db = MoisesDB(data_path=’./moises-db-data’)
    n_songs = len(db)
    track = db[0]
    # mix multitracks to stems
    stems = track.stems
    # stems = {
    #   ’vocals’: np.ndarray (stem audio data),
    #   ’bass’: np.ndarray (stem audio data),
    #   ...}
    # mixture: np.ndarray
    mixture = track.audio
    # save mixed stems
    track.save_stems(’./stems/track_0’)

Figure 5: Usage of the MoisesDB Python package. Figure 6: Loudness and Dynamic
Range distribution of tracks in MoisesDB. For a comparison with commercially
mixed and mastered songs, we sampled 240 tracks from the HarmonixSet [13].

The annotations in MedleyDB make it useful for many MIR tasks, including the
source separation of diverse instruments. However, the shortcoming of MedleyDB
for music source separation is the way it organizes tracks into stems. While
it provides instrument information for each of them, and functional
annotations for stems (such as “melody” or “bass”), stems are not meaningfully
labelled, only numbered. As a result, stem 01 of one song may be the drum kit,
while stem 01 of a another mix is the bassoon. Furthermore, instruments—and
thus tracks—are grouped according to how they physically produce their sound,
rather than their role in the mix of a song. For example, the “drum machine”
falls into the same category as “electric piano”, namely
“electric$\rightarrow$electronic”. These shortcomings make it cumbersome to
use for music source separation out of the box and significant work has to be
done in order to use it for this task.

In 2016, Liutkus et al. released the _DSD100_ [6] dataset as part of the 2016
signal separation evaluation campaign to develop and benchmark source
separation models. It contains 100 songs and uses the the four-stems taxonomy
(vocals, drums, bass, and other). Later, in 2017, Rafii et al. extended DSD100
to 150 songs by adding 46 pieces from MedleyDB, and including four previously
unreleased recordings from commercial providers. This dataset became known as
the _MUSDB18_ [7] dataset, and was used for the the 2018 signal separation
evaluation campaign. In 2019, Z. Rafii et al. released an uncompressed version
of the MUSDB18 dataset, MUSDB18-HQ [8]. As its predecessor DSD100, this
dataset provides four stems—vocals, drums, bass, and other—as well as linear
mixes. MUSDB18 is widely used to train and benchmark source separation models,
but the limited number of stems prevents researchers from building more
granular source separation systems.

In summary, data for training granular source separation systems is scarce:
the 150 tracks from MUSDB18 are ready to use, but offer only four stems to
separate; the 140 remaining tracks from MedleyDB (46 of the originally 196 are
already part of MUSDB18) are not organized in a way that easily supports
source separation research. This issue is also reflected in the fact that
state-of-the-art source separation models often use larger, non-public
datasets for training [1, 3], or have to resort to synthetic training data
(e.g.[14, 15]). Other works find that MUSDB18’s _"source groupings remain
overly coarse for many real-world remixing applications."_ [16]. To address
these issues and to foster more research in music source separation, we
created the MoisesDB dataset.

MoisesDB comprises the largest publicly available set of multitrack audio
recordings—240 previously unreleased songs—organized in a taxonomy that
reflects the needs of source separation systems (as detailed in Sec. 3.1). The
large number of songs, the diverse types of stems and tracks, and their
organization in a source-separation-focused taxonomy will allow researchers to
build their own stems according to their own requirements, and thus develop
more granular source separation systems.

Figure 7: Distribution of tracks in MoisesDB.

##  3 Dataset

MoisesDB consists of 240 songs by 47 artists that span twelve high-level
genres. Both artists and genres follow a power-law-like distribution, where
the majority of songs belong to few genres and are performed by few
artists—see Fig. 1 and 2. The total duration of the dataset is 14 hours, 24
minutes and 46 seconds, where the average recording is 3:36 seconds, with a
standard deviation of 66 seconds.

###  3.1 Stem Taxonomy

Modern song recordings consist of multiple recorded _tracks_ , which can be
grouped and down-mixed into a smaller number of _stems_. For example, the
“drums” stem might comprise tracks for the snare drum, the bass drum, hi-hat,
cymbals, and so on. MoisesDB provides all individual tracks for each song,
grouped into stems by the taxonomy shown in Table 2. This taxonomy reflects
the recording & mixing process, and thus facilitates its reversal—music source
separation—by grouping the raw tracks into semantically labeled stems. This
also means that songs may consist of different numbers of stems, as shown in
Fig. 3. MoisesDB thus facilitates many future research directions: source
separation models for a larger number of stems, data augmentation through
mixing stems on-the-fly from their tracks, or separation of individual tracks
from a stem, to name a few.

Given the genres of the songs in MoisesDB, certain stems are more common in
the dataset than others: “vocals”, “drums”, and “bass” appear on virtually
every song, while “wind” is rare. Similarly, certain tracks appear much more
frequently than others, both within stems (“bass guitar” vs. “contrabass”) and
between stems (“snare drum” vs. “cello”). Figs. 4 and 7 show the distributions
of stems and sources, respectively.

We anticipate that this imbalance will present a challenge in training source
separation models for underrepresented stems, as it is likely that certain
tracks, such as “other plucked” tracks, will still be difficult to distinguish
from “guitar” tracks if trained solely on MoisesDB. However, the available
data provides an opportunity for researchers to better identify and
characterize errors made by their models. For instance, instead of simply
observing that the separated “other” stem bleeds into “guitar,” MoisesDB
enables researchers to pinpoint this issue to tracks where “other” includes
plucked instruments.

Figure 8: SDR values of each group of sources, for IBM, IRM, MWF, Demucs, and
Spleeter source separation methods. 4 stems (N = 235)
---
| HT-Demucs | Spleeter | IBM | IRM | MWF
| Mean $\pm$ Std | Mdn | Mean $\pm$ Std | Mdn | Mean $\pm$ Std | Mdn | Mean $\pm$ Std | Mdn | Mean $\pm$ Std | Mdn
vocals | 10.05 $\pm$ 2.48 | 9.62 | 7.61 $\pm$ 2.45 | 7.27 | 9.02 $\pm$ 2.13 | 8.67 | 10.72 $\pm$ 2.03 | 10.37 | 10.72 $\pm$ 2.11 | 10.27
bass | 11.64 $\pm$ 3.35 | 11.99 | 6.46 $\pm$ 2.26 | 6.57 | 6.46 $\pm$ 2.08 | 6.31 | 8.43 $\pm$ 2.03 | 8.20 | 8.68 $\pm$ 2.07 | 8.38
drums | 10.94 $\pm$ 2.30 | 10.91 | 6.65 $\pm$ 1.72 | 6.64 | 7.33 $\pm$ 1.77 | 7.30 | 8.98 $\pm$ 1.68 | 8.92 | 9.01 $\pm$ 1.67 | 8.83
other | 7.00 $\pm$ 2.76 | 7.30 | 4.45 $\pm$ 2.26 | 4.69 | 5.77 $\pm$ 1.72 | 5.61 | 7.74 $\pm$ 1.65 | 7.57 | 7.90 $\pm$ 1.65 | 7.79
_overall_ | 9.91 $\pm$ 3.27 | 9.69 | 6.29 $\pm$ 2.47 | 6.24 | 7.14 $\pm$ 2.28 | 6.99 | 8.97 $\pm$ 2.16 | 8.81 | 9.08 $\pm$ 2.15 | 8.87
5 stems (N = 104)
vocals |  |  | 6.99 $\pm$ 1.97 | 6.74 | 8.29 $\pm$ 1.66 | 8.08 | 9.94 $\pm$ 1.59 | 9.75 | 10.01 $\pm$ 1.71 | 9.68
bass |  |  | 6.26 $\pm$ 2.27 | 6.28 | 6.13 $\pm$ 2.15 | 5.86 | 8.02 $\pm$ 2.07 | 7.82 | 8.32 $\pm$ 2.08 | 8.03
drums |  |  | 6.89 $\pm$ 1.88 | 6.97 | 7.67 $\pm$ 1.94 | 7.87 | 9.29 $\pm$ 1.84 | 9.34 | 9.32 $\pm$ 1.84 | 9.36
other |  |  | 1.97 $\pm$ 1.76 | 2.09 | 4.04 $\pm$ 1.47 | 4.13 | 6.00 $\pm$ 1.44 | 6.01 | 6.10 $\pm$ 1.48 | 6.19
piano |  |  | 1.17 $\pm$ 1.86 | 0.75 | 3.04 $\pm$ 2.37 | 2.55 | 4.99 $\pm$ 2.32 | 4.60 | 5.30 $\pm$ 2.46 | 4.79
_overall_ |  |  | 4.66 $\pm$ 3.20 | 5.02 | 5.12 $\pm$ 2.81 | 4.87 | 7.65 $\pm$ 2.66 | 7.60 | 7.81 $\pm$ 2.66 | 7.83
6 stems (N = 88)
vocals | 9.55 $\pm$ 1.87 | 9.39 |  |  | 8.09 $\pm$ 1.51 | 7.98 | 9.73 $\pm$ 1.46 | 9.61 | 9.81 $\pm$ 1.49 | 9.61
bass | 11.93 $\pm$ 2.87 | 12.13 |  |  | 6.04 $\pm$ 1.98 | 5.83 | 7.92 $\pm$ 1.93 | 7.73 | 8.24 $\pm$ 1.96 | 8.03
drums | 11.02 $\pm$ 2.44 | 11.28 |  |  | 7.58 $\pm$ 1.96 | 7.79 | 9.19 $\pm$ 1.86 | 9.21 | 9.23 $\pm$ 1.85 | 9.25
other | 0.28 $\pm$ 1.84 | 0.39 |  |  | 2.85 $\pm$ 1.76 | 2.74 | 4.67 $\pm$ 1.76 | 4.57 | 4.72 $\pm$ 1.82 | 4.55
piano | 1.60 $\pm$ 1.68 | 1.64 |  |  | 2.78 $\pm$ 1.61 | 2.49 | 4.71 $\pm$ 1.61 | 4.47 | 4.97 $\pm$ 1.74 | 4.70
guitar | 3.07 $\pm$ 1.81 | 3.16 |  |  | 3.35 $\pm$ 1.54 | 3.44 | 5.28 $\pm$ 1.54 | 5.36 | 5.41 $\pm$ 1.65 | 5.46
_overall_ | 6.24 $\pm$ 5.17 | 6.05 |  |  | 5.12 $\pm$ 2.81 | 4.87 | 6.91 $\pm$ 2.70 | 6.69 | 7.06 $\pm$ 2.73 | 6.89
Table 3: Mean, standard deviation (Std), and median (Mdn) of the SDR in dB for
each Model/Method and stem type. The varying number of available tracks is
denoted by N. _Overall_ indicates performance over all tracks regardless of
stem group. Best results are marked in bold.

###  3.2 Recording and Mastering

The songs in MoisesDB are professionally recorded in stereo. The individual
tracks are combined additively to create stems, which are then mixed together
to produce the final version of the song. Due to technical limitations during
recording, minuscule bleeding from other stems may be present for some of the
tracks. No compression, equalization, or other effects are used during the
mixing process, and the songs are not subjected to mastering. As a result, the
song mixes have a lower loudness and a higher dynamic range than
professionally mastered commercial songs. This raises concerns about the
distributional shift between un-mastered training data and commercial
recordings. Indeed, Jeon and Lee [17] have found that training separation
models using mastered mixes can improve separation quality. However, providing
un-mastered mixes is common in existing datasets such as MUSDB18, and models
such as HT-Demucs [3] generalize reasonably well to mastered recordings, even
if trained on un-mastered data.

Figure 6 shows the loudness and dynamic range distributions for the dataset,
where loudness is measured in LUFS (Loudness Units relative to Full Scale)
[18], and Dynamic Range is computed based on the definitions of the
“Pleasurize Music Foundation” as implemented in the “DR14 T.meter”
software222https://github.com/simon-r/dr14˙t.meter.

###  3.3 Python Library

With MoisesDB comes a Python library that facilitates working with the dataset
by parsing metadata and automatically building stems and mixes. Figure 5 shows
an example usage of the library. The code shown there initializes the library,
retrieves the number of tracks, creates the stems and the full mix, and saves
the individual stems to a directory. For a detailed and up-to-date
documentation, we refer the reader to the GitHub
repository333https://github.com/moises-ai/moises-db.

##  4 Benchmarking

In order to establish reference values for each track of the MoisesDB dataset,
we computed the Source to Distortion Ratio (SDR) [19] scores for Ideal Binary
Mask (IBM) [20], Ideal Ratio Mask (IRM) [21], and Multichannel Wiener Filter
(MWF) [22] oracle separation methods. Additionally, we assessed SDR scores for
two popular public available and open-source architectures: Hybrid Transformer
Demucs (HT-DEMUCS) [3] and Spleeter [1]. The SDR scores were calculated for
three different groups of sources: four, five, and six stems. Given the
architecture of the open-source models, results for Spleeter are available for
four and five stems, and for HT-DEMUCS for four and six stems.

The SDR measure [19] represents how much of the energy in a true source signal
is preserved in an estimated source signal after applying a separation
algorithm. The equation can be defined as

$\displaystyle\mathrm{SDR}=10\log_{10}\frac{\sum_{n}\left|s(n)\right|^{2}+\epsilon}{\sum_{n}\left|s(n)-\hat{s}(n)\right|^{2}+\epsilon},$
(1)

where $s(n)$ represents the true source signal at time $n$, $\hat{s}(n)$
represents the estimated source signal at time $n$, and the result is given in
decibels (dB).

Table 3 shows the SDR values in dB for each group of stems (4, 5, and 6)
evaluated in this benchmark. For a better comparison, we chose the stems
available in the open-source models: vocals, bass, drums, other, guitar, and
piano. We also pick tracks containing at least all the stems chosen for each
group, which explains the distinct number of tracks in Table 3. Songs with
more individual tracks than the ones specified for each group were merged into
the “other” stem using a linear sum strategy.

Figure 8 depicts boxplots representing the distribution of the SDR metric for
both oracle and separation methods, calculated for each group of tracks
comprising 4, 5, and 6 stems. The groups of stems evaluated were vocal, bass,
drums, other, piano, and guitar. Detailed results for every track and each
stem are provided in the GitHub3 repository.

The first fact that calls our attention can be seen in Figure 8, where the SDR
results of IRM and MWF oracle methods did not show a significant difference
for all groups of stems. The striking fact is the performance of HT-DEMUCS
architecture, which outperforms the oracle methods for bass and drums stems,
for the groups of 4 and 6 stems tracks, as we can see in Figures 8 A and C,
respectively. Those results contrast with the slightly worse performance of
HT-DEMUCS for other, piano, and guitar stems, compared with oracle methods, as
seen in Figure 8 C.

##  5 Conclusion

In this work, we introduced MoisesDB, a multitrack dataset with a hierarchical
taxonomy aimed at more-than-four-stems source separation. We set the context
by analysing the current landscape of source separation datasets and presented
a comparison with other relevant datasets along with a detailed analysis of
MoisesDB. Specifically, we discussed the organizational taxonomy focused on
source separation, the distribution over track duration, the distribution over
genres, and the number of songs for each stem and source available in the
dataset.

Moreover, we include performance results for two publicly available source
separation methods: HT-Demucs, which has the best overall SDR score evaluated
on the MUSDB18 test set, and Spleeter, which was one of the first source
separation models released and adopted by the general public. We also added
results for a few masking-based oracle methods: IBM, IRM, and MWF, which
indicate the theoretical performance limits for mask-based source separation
models. Additionally, we provide an easy-to-use Python library to access the
data which allows fast integration with machine learning libraries.

Overall, this paper represents a detailed report on the MoisesDB dataset,
which will hopefully prove to be a great resource for the source separation
community in the future. This work aims at facilitating the development of
better and extended source separation models as well as providing
opportunities to be applied for other use cases, such as automatic mixing and
generative accompaniment systems, among others.

## References

  * [1] R. Hennequin, A. Khlif, F. Voituret, and M. Moussallam, “Spleeter: A fast and efficient music source separation tool with pre-trained models,” _Journal of Open Source Software_ , vol. 5, no. 50, p. 2154, Jun. 2020.
  * [2] Q. Kong, Y. Cao, H. Liu, K. Choi, and Y. Wang, “Decoupling magnitude and phase estimation with deep ResUNet for music source separation,” _arXiv:2109.05418 [cs, eess]_ , Sep. 2021.
  * [3] S. Rouard, F. Massa, and A. Défossez, “Hybrid transformers for music source separation,” _arXiv:2211.08553 [cs, eess]_ , Nov. 2022.
  * [4] R. Bittner, J. Salamon, M. Tierney, M. Mauch, C. Cannam, and J. Bello, “MedleyDB: A multitrack dataset for annotation-intensive MIR research,” in _Proceedings of the 15th International Society for Music Information Retrieval Conference (ISMIR)_ , Taipei, Taiwan, Oct. 2014, pp. 155–160.
  * [5] R. Bittner, J. Wilkins, H. Yip, and J. P. Bello, “MedleyDB 2.0: New data and a system for sustainable data collection,” in _Late Breaking Demo of the 16th International Society for Music Information Retrieval Conference (ISMIR)_ , New York, USA, Aug. 2016.
  * [6] A. Liutkus, F.-R. Stöter, Z. Rafii, D. Kitamura, B. Rivet, N. Ito, N. Ono, and J. Fontecave, “The 2016 signal separation evaluation campaign,” in _Proceedings of the 13th International Conference on Latent Variable Analysis and Signal Separation (LVA/ICA)_ , Grenoble, France, Feb. 2017, pp. 323–332.
  * [7] Z. Rafii, A. Liutkus, F.-R. Stöter, S. I. Mimilakis, and R. Bittner, “The MUSDB18 corpus for music separation,” Dec. 2017. [Online]. Available: https://doi.org/10.5281/zenodo.1117372
  * [8] ——, “MUSDB18-HQ - an uncompressed version of MUSDB18,” Dec. 2019. [Online]. Available: https://doi.org/10.5281/zenodo.3338373
  * [9] T.-S. Chan, T.-C. Yeh, Z.-C. Fan, H.-W. Chen, L. Su, Y.-H. Yang, and R. Jang, “Vocal activity informed singing voice separation with the ikala dataset,” in _Proceedings of the 40th IEEE International Conference on Acoustics, Speech and Signal Processing (ICASSP)_ , South Brisbane, QLD, Australia, Apr. 2015, pp. 718–722.
  * [10] C.-L. Hsu and J.-S. R. Jang, “On the improvement of singing voice separation for monaural recordings using the mir-1k dataset,” _IEEE Transactions on Audio, Speech, and Language Processing_ , vol. 18, no. 2, pp. 310–319, 2010\.
  * [11] B. De Man, M. Mora-Mcginity, G. Fazekas, and J. D. Reiss, “The open multitrack testbed,” in _Proceedings of the 137th Audio Engineering Society Convention_. Los Angeles, CA, USA: Audio Engineering Society, Oct. 2014.
  * [12] L. Prétet, R. Hennequin, J. Royo-Letelier, and A. Vaglio, “Singing voice separation: A study on training data,” in _Proceedings of the IEEE International Conference on Acoustics, Speech and Signal Processing (ICASSP)_. Brighton, UK: IEEE, May 2019, pp. 506–510.
  * [13] O. Nieto, M. McCallum, M. E. P. Davies, A. Robertson, A. Stark, and E. Egozy, “The HARMONIX set: Beats, downbeats, and functional segment annotations of western popular music,” in _Proceedings of the 20th International Society for Music Information Retrieval Conference (ISMIR)_ , pp. 565–572.
  * [14] Y. Özer and M. Müller, “Source separation of piano concertos with test-time adaptation,” in _Proceedings of the 23rd International Society for Music Information Retrieval Conference (ISMIR)_ , Bengaluru, India, Dec. 2022, pp. 493–500.
  * [15] E. Manilow, G. Wichern, P. Seetharaman, and J. Le Roux, “Cutting music source separation some slakh: A dataset to study the impact of training data quality and quantity,” in _IEEE Workshop on Applications of Signal Processing to Audio and Acoustics (WASPAA)_. IEEE, Oct. 2019, pp. 45–49.
  * [16] E. Manilow, G. Wichern, and J. Le Roux, “Hierarchical musical instrument separation.” in _Proceedings of the 21st International Society for Music Information Retrieval Conference (ISMIR)_ , Virtual Conference, Oct 2020, pp. 376–383.
  * [17] C.-B. Jeon and K. Lee, “Towards robust music source separation on loud commercial music,” in _Proceedings of the 23rd International Society for Music Information Retrieval Conference (ISMIR)_ , Bengaluru, India, Dec. 2022, pp. 575–582.
  * [18] ITU-R, “Algorithms to measure audio programme loudness and true-peak audio level,” International Telecommunication Union, Recommendation BS.1770-4, Oct. 2015.
  * [19] E. Vincent, R. Gribonval, and C. Fevotte, “Performance measurement in blind audio source separation,” _IEEE Transactions on Audio, Speech, and Language Processing_ , vol. 14, no. 4, pp. 1462–1469, Jul. 2006.
  * [20] E. Vincent, H. Sawada, P. Bofill, S. Makino, and J. P. Rosca, “First stereo audio source separation evaluation campaign: Data, algorithms and results,” in _Proceedings of the 7th International Conference on Independent Component Analysis and Signal Separation (ICA)_ , London, UK, Sep. 2007, pp. 552–559.
  * [21] A. Liutkus and R. Badeau, “Generalized Wiener filtering with fractional power spectrograms,” in _Proceedings of the IEEE International Conference on Acoustics, Speech and Signal Processing (ICASSP)_ , South Brisbane, Australia, Apr. 2015, pp. 266–270.
  * [22] N. Q. K. Duong, E. Vincent, and R. Gribonval, “Under-determined reverberant audio source separation using a full-rank spatial covariance model,” _IEEE Transactions on Audio, Speech, and Language Processing_ , vol. 18, no. 7, pp. 1830–1840, Sep. 2010.