Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug] Tortoise inference not functional #3005

Closed
BuffMcBigHuge opened this issue Sep 27, 2023 · 6 comments · Fixed by #3010
Closed

[Bug] Tortoise inference not functional #3005

BuffMcBigHuge opened this issue Sep 27, 2023 · 6 comments · Fixed by #3010
Labels
bug Something isn't working

Comments

@BuffMcBigHuge
Copy link

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

@BuffMcBigHuge BuffMcBigHuge added the bug Something isn't working label Sep 27, 2023
@BuffMcBigHuge BuffMcBigHuge changed the title [Bug] [Bug] Tortoise inference not functional Sep 27, 2023
@swatsw
Copy link

swatsw commented Sep 27, 2023

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:

self.tokenizer = VoiceBpeTokenizer()

@Lenos500
Copy link

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:

self.tokenizer = VoiceBpeTokenizer()

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
Copy link

jlouis commented Sep 27, 2023

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
Copy link

Lenos500 commented Sep 28, 2023

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
Copy link

jlouis commented Sep 28, 2023

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
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants