Text capacity with Fast Koko?

[RBEmerson970]

Using Fast Koko to read back a short story, I found it seems to max out at about 15 minutes of text. After that I get fragments of the text.

What's the upper bound on what Fast Koko will accept?

[remsky]

I've run it on a few hours worth without issue, and listened through. What route are you using? Through the WebUI, or API?

[RBEmerson970]

I'm using the web access.

Updated to 0.2.2 and the problem persists I've attached the full log, from installation to starting to speak, along with a grab of the UI.. Note the play time is given as 13:55 which is much too short fo 50k characters. At somewhere around 13:15-:20 the playback skips through the remaining text, reading some chunks, but skipping others.

The text, in PDF form, can be collected here: https://drive.google.com/file/d/1j8ktSuWqgm8w3tWPB1csP8Dvf_qmHAM-/view?usp=drive_link
When using Fast Koko I do CTRL-A, CTRL-C, paste into the Fast Koko text window. I don't use formatting (which compresses the text into a block (makes problems when following in the manuscript).

Install+Run.txt

[RBEmerson970]

BUMP. Any progress?

[remsky]

Sent a request to access the text, will check it out

[remsky]

I'll add in a fix for the 'format' compressing it to block as well.

[RBEmerson970]

[/2 thumbs up]
Link sent.

[RBEmerson970]

BUMP
I'm still hitting a point where the speech goes from linear "word for word" to the beginning of subsequent chunks. This happens +/- 13 minutes into a text.
In my particular case, I read text that I'm writing for a novel, and listening for tense errors, missing or duplicated words, etc.. Using small clips to wade through 50K+ words... not a winner.

[RBEmerson970]

BUMP
This problem persists - any text beyond 10:12 is not spoken by FastKoko. All text does, however, show up correctly in saved audio files (MP3|WAV)..

While I've built Docker containers recently, only the Odd Gods of the Universe know what version I'm really running. I sure as heck don't! >:-(

[RBEmerson970]

Still present after shredding all prior Korkoro-FastAPI containers and directories, and building a fresh V0.2.4.

[BronnEdward]

Maybe helpful... I am running Kokoro-FastAPI container. I was experiencing a same/similar problem where when I would feed it a very long text I would get a maximum of about 10-11 minutes of audio which would have artifacts and skip a lot of text. I found that if I enabled 'Auto-play' in the GUI it would bork the container. Once I tried to generate audio with 'Auto-play' enabled, all subsequent operations would have this truncated audio with artifacts. If I rebuild the container from image and disable 'Auto-play' first, then all text to audio is generated full length without artifacts.

[RBEmerson970]

@BronnEdward
What you're reporting is my experience as well: audio output {MP3|WAV} plays back cleanly regardless of length. FastKoko AutoPlay fails at around 10 minutes 12 seconds , although output to a file works as expected. FWIW, I generated a 3 hours 45 minutes file that played back as expected - outside of FastKoko.

Watching log files as long passages are processed, there's no obvious seam around 10:12. Things just stop working as they should.

Under V0.2.4, once AutoPlay is is disabled, playback through FastKoko (clicking on Play) no longers works, period. Considering prior to 0.2.4 this was not always the case, it's another regression.

This is Koko-FastAPI V0.2.4, under Docker, under Win 11, on an i9 (64 Gb) w/ RTX4090 (16 Gb).

[RBEmerson970]

FastKoko built from a fresh git of master at 1900 EST 13 Dec 25 (same VERSION, 0.2.4, as a fresh build from 15 Oct. 25) has the same problem. FastKoko playback fails at about 10:09. Text fragments are played back instead of full text. In short, new build, old problem.

EDIT: Corrected ToD to include time zone

[RBEmerson970]

Good news, bad news: under V 0.4.0, using AutoPlay, playback stops completely at 10:20.

The good news is what's heard directly simply stops; no chopped up speech or noise after 10:20 (as reported above).

The bad news is the audio file contains the full amount of speech. For example 13,419 characters stops playing back at 10:20 while the .MP3 contains 12:01 of material, which plays back (with VLC) correctly.

So, the nature of the problem (no usable AutoPlay speech past 10:20) remains, but at least the failure isn't audio garbage.

[remsky]

Most of a fix should be in master (unreleased), merged via #471

Played back 30 minutes fine on mp3 and saved full multi-hour file fine, resolved some of the animation lag build up. Will try to add scrub/seek on pause (transition from stream to file playback) if it works out cleanly in another patch. But WAV etc/ works for direct file playback on completion without streaming. If it is built up, let me know if other issues show up.

[RBEmerson970]

The statement of the problem has blurred a bit over time. From the top:
As an example, if I give 15K characters of text to FastKoko, it will read back the first 10 minutes and 10 to 14 seconds of the text. As of V0.4.0 the readback stops completely (i.e., as if reaching end of text), even though not all of the text has been read back. I'm describing the "Auto Play" immediate playback behavior.

I can save the output, from processing the 15K characters, to a file, and the total run time will be in excess of 10:13, and the complete text is in the MP3, WAV, etc.

Or, using FastKoko, Auto Play won't play back past about 10:13, file saving will.

Additionally, total run time, when the text is long enough to trigger the problem, will show 10:21 in the web display (note this is greater than the actual 10:13 played back) even though a downloaded file might contain much more material (i.e., greater than 10:13 or 10:21).

Logs from using FastKoko don't show a problem around 10:13.

Somewhat related, I'll mention the file name issue (see #338) remains uncorrected under V 0.4.0

[RBEmerson970]

Just built V 0.4.1 rc 1 (bless you for keeping the rev numbers going!) - the playback slider and actual/total runtime display are broken.
The slider doesn't move during playback, and can't be moved to skip through the playback. The actual time updates during playback, but the total time is frozen at 0:00

[RBEmerson970]

Sigh... poor testing methodology on my part. What I reported above, regarding the slider and total time, is only true with text in excess of about 10:13 (definitely not 10:00 exactly). The variation is tied to the voice and playback rate. For example, am-Adam is faster than am-Michael even though the playback speed multiplier is held at 1.0. That is, am-Adam can get out more text in a unit of time than am-Michael.

Anyway, when the playback time is less than 10:13, the slider and total time work correctly. Playback_time > ~10:13 == fail.

[remsky]

The streaming in webui crash, assorted bugfixes, scrub/seek issues should be resolved as of #475.

It will stream-only (no slider) on autoplay while generating until complete. Once complete, pausing playback hotswaps the audio source to the completed file, allowing scrub/seek. With the way the buffer is set up in the current web ui, allowing the slider to work during streaming would be a little more involved.

Not sure I follow the voice timing issue mentioned. Feel free to open an issue for it specifically if still occurring.

[RBEmerson970]

Under V 0.5.0 I input about 57K characters via FastKoko, and the readback went well past the (accursed?) 10:13 mark without a hitch. The saved MP3 and (eventually) the FastKoko web UI agree on a run time of about 63 minutes, which is plausible. Or, reading back for more than about 10:13 is no longer a problem. Yea!

But... in FastKoko total run time only shows up after hitting "Pause". Not a problem, per se, but after being used to seeing the run time show up "automagically", seeing 0:00 is slightly unsettling. I suggest putting the total run time up when generation is complete - if possible.