coqui-ai / TTS

🐸💬 - a deep learning toolkit for Text-to-Speech, battle-tested in research and production
http://coqui.ai
Mozilla Public License 2.0
33.52k stars 4.08k forks source link

[Bug] Tortoise inference not functional #3005

Closed BuffMcBigHuge closed 11 months ago

BuffMcBigHuge commented 11 months ago

Describe the bug

I can't seem to use tortoise tts_models/en/multi-dataset/tortoise-v2.

File ".../python3.10/site-packages/TTS/tts/layers/tortoise/tokenizer.py", line 24, in encode
    return self.tokenizer.encode(txt).ids
AttributeError: 'NoneType' object has no attribute 'encode'

To Reproduce

tts --model_name  tts_models/en/multi-dataset/tortoise-v2 \
--text "This is an example." \
--out_path "output.wav" \
--progress_bar True

Expected behavior

No response

Logs

No response

Environment

TTS == 0.17.5

Additional context

No response

swatsw commented 11 months ago

Same issue on

TTS == 0.17.4

It seems that tokenizer initialization is expecting a vocab_file or vocab_str as input but is not getting it thus remains None: https://github.com/coqui-ai/TTS/blob/f829bf50f8cd261a2ef23356cb83f0ac6c3ff6a8/TTS/tts/models/tortoise.py#L339

Lenos500 commented 11 months ago

Same issue on

TTS == 0.17.4

It seems that tokenizer initialization is expecting a vocab_file or vocab_str as input but is not getting it thus remains None:

https://github.com/coqui-ai/TTS/blob/f829bf50f8cd261a2ef23356cb83f0ac6c3ff6a8/TTS/tts/models/tortoise.py#L339

I'm gettig an Attribute error for Voicebpetokenizer related to preprocess object, I tried to modify the tokenizer.py for xtts_v1 and it gave the encode error, I'm using the latest tts version.

jlouis commented 11 months ago

I got hit by the same problem. Started digging backward through the versions. v0.16.6 seems to work, but v0.17.0 does not. So the change is likely one that happened between those two versions. In principle, this is now set up for a git bisect.

Lenos500 commented 11 months ago

I got hit by the same problem. Started digging backward through the versions. v0.16.6 seems to work, but v0.17.0 does not. So the change is likely one that happened between those two versions. In principle, this is now set up for a git bisect.

Does version 0.16.6 support the new XTTS model? Plus the new versions include cpu fixes for that model which didn't exist before v 0.17.2 so this doesn't really help much.

jlouis commented 11 months ago

Does version 0.16.6 support the new XTTS model? Plus the new versions include cpu fixes for that model which didn't exist before v 0.17.2 so this doesn't really help much.

The purpose of finding a good version in the past isn't to suggest you'd use it. It is for narrowing down where the regression happened, making it easier to debug and fix. The presence of the XTTS model is of less interest here, because it doesn't pertain directly to this issue, though it might do so indirectly.

The idea of git bisect is that you automate the process. You generate a small snippet which passes on good versions and fails on bad versions. Bisect then picks a commit in the middle between the versions, and depending on outcome, updates the window in which the regression happened. Over a couple of runs, CI permitted, it will find the exact commit for the regression.

However, if you have knowledge of the code base, you can often intuit where the regression is, and you don't need a mechanical tool. Still, knowing "it was ok here" is a nice hint to have when trying to figure out what went wrong.

Lenos500 commented 11 months ago

Does version 0.16.6 support the new XTTS model? Plus the new versions include cpu fixes for that model which didn't exist before v 0.17.2 so this doesn't really help much.

The purpose of finding a good version in the past isn't to suggest you'd use it. It is for narrowing down where the regression happened, making it easier to debug and fix. The presence of the XTTS model is of less interest here, because it doesn't pertain directly to this issue, though it might do so indirectly.

The idea of git bisect is that you automate the process. You generate a small snippet which passes on good versions and fails on bad versions. Bisect then picks a commit in the middle between the versions, and depending on outcome, updates the window in which the regression happened. Over a couple of runs, CI permitted, it will find the exact commit for the regression.

However, if you have knowledge of the code base, you can often intuit where the regression is, and you don't need a mechanical tool. Still, knowing "it was ok here" is a nice hint to have when trying to figure out what went wrong.

Yeah but sometimes you spend hours trying to fix the code and you get the same error over and over again or new ones. So it's better to have the people who made it fix it because it's their job.