Error: middle_length is greater than the length of the audio file

[GennadiiSherstiuk]

We have a problem ('STEP 8 (compute alignment level 2) FAILURE') with multipass-based audio alignment of relatively small fragments of text.

Part of the log:
[CRIT] ExecuteTask: STEP 8 (compute alignment level 2) FAILURE
[CRIT] ExecuteTask: Unexpected error while executing task
[CRIT] ExecuteTask: interval.end is after self.end
[ERRO] CLI: An unexpected error occurred while executing the task:
[ERRO] An unexpected error occurred while executing the task:
[ERRO] CLI: Unexpected error while executing task : interval.end is after self.end
[ERRO] Unexpected error while executing task : interval.end is after self.end
[DEBU] CLI: Execution completed with code 1

The following are:
https://www.dropbox.com/s/1ft6b2d2ax3twfg/audio.wav?dl=0 - audio file;
https://www.dropbox.com/s/j6ph20dycf0tgub/text.txt?dl=0 - text file;
https://www.dropbox.com/s/qj0s8xn0fi821tb/cmdAeneas.txt?dl=0 - call aeneas by command;
https://www.dropbox.com/s/r60ge28l71z6hq8/log.txt?dl=0 - full log.

A large fragment containing the same text passed normally.

[readbeyond]

Hi, thank you for your report. From the log, I see you are running aeneas v1.7.1. A few days ago I published v1.7.2, with a fix for a bug that looked similar to what I see in your log. Would you mind updating to v1.7.2, run aeneas again, and report whether the issue is solved or still present? Thank you, AP

…

On 03/15/2017 02:51 PM, GennadiiSherstiuk wrote: We have a problem ('STEP 8 (compute alignment level 2) FAILURE') with multipass-based audio alignment of relatively small fragments of text. Part of the log: [CRIT] ExecuteTask: STEP 8 (compute alignment level 2) FAILURE [CRIT] ExecuteTask: Unexpected error while executing task [CRIT] ExecuteTask: interval.end is after self.end [ERRO] CLI: An unexpected error occurred while executing the task: [ERRO] An unexpected error occurred while executing the task: [ERRO] CLI: Unexpected error while executing task : interval.end is after self.end [ERRO] Unexpected error while executing task : interval.end is after self.end [DEBU] CLI: Execution completed with code 1 The following are: https://www.dropbox.com/s/1ft6b2d2ax3twfg/audio.wav?dl=0 - audio file; https://www.dropbox.com/s/j6ph20dycf0tgub/text.txt?dl=0 - text file; https://www.dropbox.com/s/qj0s8xn0fi821tb/cmdAeneas.txt?dl=0 - call aeneas by command; https://www.dropbox.com/s/r60ge28l71z6hq8/log.txt?dl=0 - full log. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#168>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFEodn_0h3Qfaeb6kkS5UgDw8mPTq4IPks5rl-zHgaJpZM4Md9xb>.

[GennadiiSherstiuk]

Hi. Thank you for fast answer. We have updated aeneas to v 1.7.2 and run again with same parameters and get error [CRIT] ExecuteTask: STEP 9 (compute alignment level 3) FAILURE. I updated issue. Part of the log: [CRIT] ExecuteTask: STEP 9 (compute alignment level 3) FAILURE [CRIT] ExecuteTask: Unexpected error while executing task [CRIT] ExecuteTask: middle_length is greater than the length of the audio file [ERRO] CLI: An unexpected error occurred while executing the task: [ERRO] An unexpected error occurred while executing the task: [ERRO] CLI: Unexpected error while executing task : middle_length is greater than the length of the audio file [ERRO] Unexpected error while executing task : middle_length is greater than the length of the audio file [DEBU] CLI: Execution completed with code 1 https://www.dropbox.com/s/90tk1wqblvytt9n/log2.txt?dl=0 - full log.

[readbeyond]

Hi, thank you for testing with v1.7.2. The fact that now the issue is in step 9 implies that indeed the bug in v1.7.1, fixed in v1.7.2, was triggered in the first place. The bad news is that now there seems to be a different bug, and this is more puzzling. By just looking at the log, I cannot find anything blatantly out of place. I cannot investigate the issue further right now, but I will try to have a look at it tonight after dinner. Thanks a lot for providing the files and the command line, which I downloaded. I will comment in the GitHub issue tracker when I find the culprit. AP

…

On 03/15/2017 05:32 PM, GennadiiSherstiuk wrote: Hi. Thank you for fast answer. We have updated aeneas to v 1.7.2 and run again same parameters and get error [CRIT] ExecuteTask: STEP 9 (compute alignment level 3) FAILURE. I updated issue on github.

[readbeyond]

Hi,

I have just pushed on the devel/ branch a fix which should solve the issue.

The problem was here:

b22b3a0#diff-9bcb44f3905b7921ec0fa793a802bad3

Basically, that division TimeValue(self.__samples_length / self.audio_sample_rate) produced 5.6 (float) as a result. However, the TimeValue( ... / ... ) created a TimeValue(5.5999999...) instead of TimeValue(5.6), and this made the check in audiofilemfcc.py to fail when comparing 5.6 < 5.59999... .

I am a bit puzzled by the fact that this issue never occurred before --- but of course the fact that your audio file was exactly 5.600 s long (i.e., 89600 samples at 16000 Hz) is a bit peculiar.

I am leaving this issue open until I release a new version on master/ and on PyPI, which will happen in the next days, after adding a new test for this case, and running the full tests. If you want to fetch this fix, just git clone and switch to the devel/ branch.

Thank you for reporting the issue and providing the files to reproduce the issue.

[GennadiiSherstiuk]

Hi. Thank you for your quick reply. We have updated aeneas to version 1.7.3 and all works fine.

[readbeyond]

You are welcome. Thank you for letting me know the fix looks good. I have just added a regression test, so it should not happen again in the future. A comment: I kept thinking why this issue was never triggered before. Putting aside the fact that only an audio file with a number of samples such that, once divided by 16000, would trigger the float/TimeValue conversion error, my first thought was that ``munparsed`` had something to do with it. However, that's not really the (only) case. Even using ``plain`` or ``unparsed`` (or the other "flat" input text formats) could potentially trigger this issue, if, for example, head/tail has been set. However, it still has not happened to me personally (and I use aeneas a lot...) nor to users of the aeneas Web App (or perhaps they got the error and never reported it, who knows). Anyway, I have just launched my tests, I hope to release on master/ and on PyPI v1.7.3 later today. Thanks, AP

…

On 03/16/2017 10:44 AM, GennadiiSherstiuk wrote: Hi. Thank you for your quick reply. We have updated aeneas to version 1.7.3 and all works fine.

[readbeyond]

Merged into master. Closing.