mfcc_flow not creating output port "features" if normalize is True

[mattiadg]

https://github.com/rwth-i6/i6_core/blob/d27320747b0d7ebe40b8fec6a96cdacb7a961aa5/features/mfcc.py#L104 When normalize is True, the output of this network is connected to network:features but it is never defined.

[michelwi]

Do we have the same / similar problems with the other flow types?

[curufinwe]

Probably. The problem here is that when you enable the cache manager the check for output ports goes away. This is why some flows might not have the appropriate outputs defined. The problem with fixing this is that it changes the hash of the flow network.

[curufinwe]

@JackTemaki @christophmluscher could you guys check if for example your preextracted librispeech features at i6 are affected by this?

[curufinwe]

i.e. if the flow file used there lacks the features port (because then adding it here would break those hashes).

[JackTemaki]

I am not sure about the details, but this is the flow for my first Hybrid setup with the new pipeline:

<?xml version="1.0" ?>
<network name="network">
  <out name="features"/>
  <param name="TASK"/>
  <param name="end-time"/>
  <param name="id"/>
  <param name="input-file"/>
  <param name="start-time"/>
  <param name="track"/>
  <node end-time="$(end-time)" file="$(input-file)" filter="audio-input-file-wav" name="samples" start-time="$(start-time)"/>
  <node filter="generic-vector-s16-demultiplex" name="demultiplex" track="$(track)"/>
  <link from="samples" to="demultiplex"/>
  <node filter="generic-convert-vector-s16-to-vector-f32" name="convert"/>
  <link from="demultiplex" to="convert"/>
  <node filter="signal-dc-detection" max-dc-increment="0.9" min-dc-length="0.01" min-non-dc-segment-length="0.021" name="dc-detection"/>
  <link from="convert" to="dc-detection"/>
  <node alpha="1.0" filter="signal-preemphasis" name="preemphasis"/>
  <link from="dc-detection" to="preemphasis"/>
  <node filter="signal-window" length="0.025" name="window" shift="0.01" type="hamming"/>
  <link from="preemphasis" to="window"/>
  <node filter="signal-real-fast-fourier-transform" maximum-input-size="0.025" name="fft"/>
  <link from="window" to="fft"/>
  <node filter="signal-vector-alternating-complex-f32-amplitude" name="amplitude-spectrum"/>
  <link from="fft" to="amplitude-spectrum"/>
  <node filter="signal-filterbank" filter-width="258.1839133371199" name="filterbank" warping-function="mel"/>
  <link from="amplitude-spectrum" to="filterbank"/>
  <node filter="generic-vector-f32-log" name="nonlinear"/>
  <link from="filterbank" to="nonlinear"/>
  <node filter="signal-cosine-transform" name="cepstrum" nr-outputs="16"/>
  <link from="nonlinear" to="cepstrum"/>
  <node filter="signal-normalization" length="infinity" name="mfcc-normalization" right="infinity" type="mean-and-variance"/>
  <link from="cepstrum" to="mfcc-normalization"/>
  <node filter="generic-cache" id="$(id)" name="feature-cache-mfcc" path="mfcc.cache.$(TASK)"/>
  <link from="mfcc-normalization" to="feature-cache-mfcc"/>
  <link from="feature-cache-mfcc" to="network:features"/>
</network>

[curufinwe]

OK, here you already have the features output port. I guess you added it by hand?

[JackTemaki]

No I checked the code. It is added within the FeatureExtraction Job, so when adding it outside the hashes will indeed break.

[curufinwe]

Oh, that's good news. The in-/output ports are sets. So if we add the features output port already in the mfcc_flow function the feature extraction jobs should not break. @JackTemaki could you check that for your setup by adding net.add_output("features") after line 104 in features.mfcc.py (I don't have a setup at hand for that)? Thanks!

[JackTemaki]

As I said, the hashes will break, because this is added AFTER hashing inside the FeatureExtraction job. I tested this, and the hashes DO break.

[curufinwe]

OK. @mattiadg then we have to fix it via a flag to the flow (with default to keep the old behavior).