Kaldi export of lhotse supervisions manifest is incorrect

[ngoel17]

It appears to me that the kaldi export of lhotse supervisions has a bug.
Consider the fisher supervisions manifest below.

{"id": "fe_03_00001-000", "recording_id": "fe_03_00001", "start": 3.76, "duration": 1.78, "channel": 0, "text": "and i generally prefer", "language": "English", "speaker": "2602"}

wav.scp encodes the channel as
fe_03_00001_0

The channel 0 should be appended to the segments file so that the output is like
fe_03_00001-000 fe_03_00001_0 3.76 5.54

but the actual output is
fe_03_00001-000 fe_03_00001 3.76 5.54

[pzelasko]

Oh, good point, I don't think this particular case was tested against multi-channel exports. @jtrmal would you be interested to help with this one?

[ngoel17]

# segments
save_kaldi_text_mapping(
data={
sup.id: f"{sup.recording_id}_{sup.channel} {sup.start} {sup.end}"
for sup in supervisions
},
path=output_dir / "segments",

Something like this OK in kaldi.py?

[ngoel17]

If one were trying to use the kaldi format data, there turns out to be one more issue. the segment-id's are not in the correct format - prefixed by speaker ID, so fix_data_dir.sh will keep complaining that utt2spk is not sorted. I fixed this manually but in general I don't know if its worthwhile fixing.

[jtrmal]

Yeah i will check it out Y.

…

On Wed, Sep 14, 2022 at 23:07 Nagendra Goel ***@***.***> wrote: If one were trying to use the kaldi format data, there turns out to be one more issue. the segment-id's are not in the correct format - prefixed by speaker ID, so fix_data_dir.sh will keep complaining that utt2spk is not sorted. I fixed this manually but in general I don't know if its worthwhile fixing. — Reply to this email directly, view it on GitHub <#811 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACUKYX7WXJOLDGBO5INLOV3V6I5AJANCNFSM6AAAAAAQMX3544> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[jtrmal]

Sorry for the delay, I had some family stuff happening. I'm on it.

[jtrmal]

I have a feeling this change was already once reverted in the past, because IIRC Piotr was saying their infrastructure relies on the formatting as it already was?

[pzelasko]

Oh yeah the comment was about being able to export and re import with the same IDs. How about we make the new behavior optional but enabled by default? This way it does the right thing for everybody.

[jtrmal]

one option might be implement/reimplement the custom formatters I have the PR on
another option is to start adding options/switches, I guess

[pzelasko]

I am OK with both options, up to you

[jtrmal]

this is being addressed in #831 and I apologize @ngoel17 and everyone else I didn't read the report carefully enough -- I discovered this on my own and realized only later on its a dupe

[jtrmal]

resolved via #831