LJspeech recipe error: exceeded the bounds of its corresponding recording

The prepare_ljspeech recipe on version lhotse==0.4.0 fails with the following error:

Traceback (most recent call last):
  File "examples/prepare_ljspeech.py", line 9, in <module>
    ljspeech = prepare_ljspeech("LJSpeech-1.1", "manifests")
  File "/home/jan/aligntts/venv/lib/python3.8/site-packages/lhotse/recipes/ljspeech.py", line 96, in prepare_ljspeech
    validate_recordings_and_supervisions(recording_set, supervision_set)
  File "/home/jan/aligntts/venv/lib/python3.8/site-packages/lhotse/qa.py", line 52, in validate_recordings_and_supervisions
    assert 0 <= s.start <= s.end <= r.duration, \
AssertionError: Supervision LJ001-0001: exceeded the bounds of its corresponding recording (supervision spans [0.0, 9.65501134]; recording spans [0, 9.65501133786848])

It runs fine on lhotse==0.3.0. There seems to be related a issue #201 - there is also a rounding problem. I am looking into it now, but not sure where is the problem.

Edit: It seems like the duration of a Recording does not do the same rounding that happens in Supervision.

Supervision:

   @property
   def end(self) -> Seconds:
       return round(self.start + self.duration, ndigits=8)

Recording:

Recording(
            id=recording_id if recording_id is not None else sph_path.stem,
            sampling_rate=sphf.format['sample_rate'],
            num_samples=sphf.format['sample_count'],
            duration=sphf.format['sample_count'] / sphf.format['sample_rate'],
            sources=[
                AudioSource(
                    type='file',
                    channels=list(range(sphf.format['channel_count'])),
                    source=(
                        '/'.join(sph_path.parts[-relative_path_depth:])
                        if relative_path_depth is not None and relative_path_depth > 0
                        else str(sph_path)
                    )
                )
            ]
        )

Is it possible that there should also be rounding in the Recording? I cam make a PR for this 😃

[pzelasko]

I thought about it but I haven’t analyzed yet how that would impact serialization/deserialization, overall speed and memory load (especially with a lot of objects around), and user experience. It could be a long-term solution though.

[pzelasko]

Yeah, as you can see this float rounding stuff is really delicate. Your suggestion sounds good to me.