RVC v2

RVC v2 ist bei tasarim.ai die Bezeichnung für den im offiziellen Repository Retrieval-based-Voice-Conversion-WebUI dokumentierten v2-Workflow zur Stimmumwandlung. Er übernimmt eine vorhandene Sprach- oder Gesangsaufnahme und verändert deren Stimmcharakter mithilfe eines Zielstimmen-Checkpoints. Der umgebende Ablauf kann zusätzlich einen Retrieval-Index und eine Tonhöhenextraktion einsetzen. Für eine kontrollierte lokale Prüfung kommt das Verfahren nur infrage, wenn sämtliche Aufnahmen und Modelle für den vorgesehenen Zweck verwendet werden dürfen. Es ist weder ein Text-to-Speech-System noch eine Erlaubnis zur Nachahmung einer Person oder eine Garantie für Echtzeitbetrieb auf ungeprüfter Hardware.

Diese Bewertung stützt sich auf den offiziellen Repository-Commit 81eed5e8f68b6bed1789f682fe78cdd324495afc. Es wurde keine Umgebung installiert, kein Modell und keine Audiodatei heruntergeladen, keine Stimme trainiert oder umgewandelt und weder Latenz noch Hörqualität gemessen. Die folgenden Schritte und Prüftabellen beschreiben einen vorgeschlagenen Versuch mit noch leeren Ergebnissen.

Die Aufgabe zur Stimmumwandlung vor der Wahl von RVC festlegen

Beginne mit dem Signal, das bereits vorliegt, und dem tatsächlich benötigten Ergebnis. RVC wandelt eine vorhandene Darbietung um, statt neue Sprache aus Text zu erzeugen. Die Quellaufnahme liefert Timing, Wörter, Phrasierung und Tonhöhenverlauf. Der Ziel-Checkpoint und die zugehörigen Regler prägen die umgewandelte Stimme. Wenn die Aufgabe mit einem Skript beginnt und nie eingesprochene Sätze benötigt, sollte ein Text-to-Speech-Ablauf geprüft werden. Stimmumwandlung ist dafür kein Ersatz.

Formuliere vor dem Sammeln von Dateien einen engen, zulässigen Zweck. Ein vertretbares Beispiel wäre, eine kurze autorisierte Studiophrase für einen privaten Produktionstest in eine zweite, ebenfalls autorisierte Stimme umzuwandeln. Lege fest, was erhalten bleiben muss, etwa verständliche Wörter, Phrasentiming und absichtliche Tonhöhenbewegung, und was sich ändern darf. „Klingt genau wie diese Person“ ist kein geeignetes Erfolgskriterium. Es vermischt eine Hörpräferenz mit Identität, Einwilligung und Herkunft.

Das Repository beschreibt WebUI-Wege für Training und Inferenz sowie eine getrennte Oberfläche zur Echtzeitumwandlung. Diese Betriebsarten gehören zum selben Projekt, doch ein gutes Offline-Ergebnis beweist nicht, dass eine Live-Audiokette ihr Latenz- oder Stabilitätsziel erreicht. Offline-Qualität, Trainingsaufwand und Live-Routing müssen getrennt entschieden werden.

Eine Umwandlung darf nicht zur Sprecher-Authentifizierung, als Beleg dafür, dass jemand etwas gesagt hat, oder als Anonymitätsgarantie dienen. Eine veränderte Stimme kann erkennbare Merkmale behalten oder neue Artefakte erzeugen. Diese Bewertung hat die Identifizierbarkeit nicht gemessen. Wenn beweissichere Zuordnung oder zuverlässige De-Identifizierung erforderlich ist, reicht eine RVC-Ausgabe dafür nicht aus.

Repository-Code, Stimmgewichte, Index und Medien trennen

Das offizielle Repository enthält Code und Oberflächen, aber kein einzelnes, abgeschlossenes Stimmenmodell. Die aktuelle Struktur erwartet HuBERT-Dateien für die Merkmalsextraktion, eine RMVPE-Datei für die Tonhöhenextraktion, Vortrainingsdateien für v1/v2, eigene .pth-Stimmgewichte unter assets/weights/ und eigene .index-Dateien unter assets/indices/. Optionale pymss/MSST-Gewichte gehören zu einem separaten Weg der Stimmtrennung. Offizielle aktuelle Einrichtung und Verzeichnisstruktur.

Behandle jedes Artefakt als eigenen Herkunftsdatensatz. Ein Stimmen-Checkpoint muss mit Urheber oder autorisierter Bezugsquelle, erlaubtem Zweck, Modellversion und Prüfsumme verbunden sein. Wenn ein Retrieval-Index dazugehört, bewahre die Paarung von Checkpoint und Index. Eine ähnlich benannte .index-Datei ist nicht automatisch kompatibel. Dateinamen sind Bezeichner, keine Nachweise für Herkunft oder Erlaubnis.

Auch die Eingabemedien benötigen eigene Einträge. Halte Zielaufnahmen für das Training, Quelldarbietung und umgewandeltes Ergebnis an getrennten Orten. Dokumentiere, wer jedes Element bereitgestellt hat, welche Verarbeitung und Weitergabe zulässig sind und ob die Darbietung Musik oder anderes geschütztes Material enthält. Der Zugriff auf das Repository beantwortet diese Fragen nicht.

Die README verweist auf ein Hugging-Face-Modellrepository und verwendet in Downloadbefehlen --revision main. Ein beweglicher Branch benennt einen Bezugsweg, aber keine unveränderliche Binärversion. Für einen echten Versuch sind die aufgelöste Revision und lokal berechnete Prüfsummen festzuhalten. In dieser Quellenprüfung wurden die Modelldateien weder heruntergeladen noch untersucht.

Die aktuelle hardwarespezifische Umgebung vorbereiten

Am geprüften Commit zielt die englische Anleitung auf Python 3.12 x64. Sie empfiehlt Ubuntu 24.04 x86_64 und beschreibt außerdem einen virtuellen Windows-Umgebungsweg. Die Installation hängt von der Hardware ab: CPU, AMD und Intel verwenden requirments_cpu_py312.txt; RTX-50-Systeme installieren Torch für CUDA 12.8 in zwei Schritten und danach requirments_cu128_py312.txt; frühere NVIDIA-Hardware nutzt das dokumentierte CUDA-11.8-Paar und requirments_cu118_py312.txt. Die Schreibweise requirments ist der tatsächliche Dateiname im Repository. Offizielle Umgebungsanleitung.

Wähle genau den Abhängigkeitspfad, der zur eingesetzten Maschine gehört. Kombiniere nicht CPU-, CUDA-11.8- und CUDA-12.8-Dateien und übernimm keine ältere Anleitung mit anderen Assets oder einer anderen Python-Version. Die aktuelle README legt HuBERT-Dateien unter assets/hubert_base/ ab. Das kann von älteren Beschreibungen abweichen. Prüfe daher Baum und Pfade, bevor ein Fehler dem Modell zugeschrieben wird.

Lege eine isolierte Umgebung und ein Einrichtungsprotokoll an. Notiere Betriebssystem, Architektur, Python, Torch, torchaudio, verwendete Abhängigkeitsdatei, Paketindizes, GPU und Treiberdaten. Das Repository erlaubt den Austausch von Spiegel-Indizes gegen offizielle Indizes, verlangt dabei aber unveränderte Paketversionen, CUDA-Suffixe und Installationsreihenfolge. Das ist ein Hinweis zum Bezugsweg und keine Kompatibilitätszusage.

Prüfe vor dem Start der WebUI, ob alle benötigten Assets an den dokumentierten Pfaden liegen und ob Torch den vorgesehenen CUDA-Status meldet. Laut README startet die Oberfläche mit python webui.py, auf einem Ubuntu-Server ohne grafische Oberfläche mit python webui.py --noautoopen; Standardport ist 7865. Diese Befehle stammen aus der Quelle und wurden für diesen Text nicht ausgeführt.

Trainingshinweise als Ausgangsbedingung behandeln

Die Maintainer empfehlen mindestens zehn Minuten rauscharmer Sprache. Das ist eine Empfehlung, kein garantierter Mindestumfang und keine Aussage, dass das Training in zehn Minuten abgeschlossen ist. Inhalt, Rauschen, Clipping, Konsistenz der sprechenden Person, Tonhöhenumfang und geplantes Quellmaterial beeinflussen, was ein Hörtest zeigt. Diese Bewertung bestimmt keine ideale Dauer.

Verwende nur Aufnahmen, die für den geplanten Zweck verarbeitet werden dürfen. Bewahre eine unveränderte Kopie und dokumentiere Trennung, Schnitt und sonstige Vorverarbeitung. Wenn eine Stimmtrennung erforderlich ist, kann das Repository pymss/MSST-Modelle aufrufen. Dieser optionale Weg benötigt eigene Gewichte und fügt eine weitere zu prüfende Transformation hinzu. Schreibe ein Artefakt nicht RVC zu, bevor das vorverarbeitete Material mit der Quelle verglichen wurde.

Der Downloadweg für v2-Training umfasst pretrained_v2/*, gemeinsame Assets und Stille-Beispiele unter logs/mute/. Halte fest, ob v1- oder v2-Ressourcen verwendet werden, und vermische sie nicht unbemerkt. Speichere Trainingskonfiguration, Log-Verzeichnis, exportierten Inferenz-Checkpoint und passenden Index als getrennte Artefakte. Eine während des Trainings gespeicherte Datei ist nicht automatisch das endgültige Inferenzartefakt; Exportweg und Format müssen geprüft werden.

Reserviere eine zulässige Phrase oder einen Clip für die Auswertung, statt jede Aufnahme zur Vorbereitung des Zielmodells zu verwenden. Ein zurückgehaltener Clip macht den vorgeschlagenen Ablauf nicht zu einem wissenschaftlichen Benchmark. Er verhindert jedoch, dass nur ein günstiges Trainingsbeispiel als Nachweis dient.

Eine begrenzte quellenbasierte Auswertung durchführen

Der vorgeschlagene Versuch verwendet einen Ziel-Checkpoint mit dokumentierter Herkunft, seinen passenden Index, falls Retrieval aktiv ist, und zwei zulässige Quellclips. Clip A sollte sauber und für den Verwendungszweck repräsentativ sein. Clip B sollte genau eine wichtige Schwierigkeit zeigen, etwa einen größeren Tonhöhenverlauf oder leichte Hintergrundgeräusche, ohne mehrere unkontrollierte Probleme zu vermischen. In diesem Kandidaten existieren weder Clips noch Resultate.

Erzeuge zunächst eine Offline-Umwandlung mit der gewählten Umgebung und den aktuellen Assets. Notiere Oberflächenmodus, Checkpoint, Index, Tonhöhenextraktion, Transpositions- oder Tonhöheneinstellung, Retrieval-Regler, Ein- und Ausgabepfad sowie jede weitere veränderte Einstellung. Bewahre die unveränderte Quelle neben der Ausgabe. Wenn die Oberfläche Logs erzeugt, speichere das vollständige Protokoll statt nur einer Erfolgsmeldung.

Erzeuge einen zweiten Kandidaten, indem genau ein Faktor geändert wird. Eine sinnvolle erste Paarung vergleicht deaktiviertes Retrieval mit aktiviertem Retrieval und passendem Index, während alle anderen Einstellungen gleich bleiben. Ein weiterer gültiger Vergleich wechselt den Weg der Tonhöhenextraktion, gehört aber in ein separates Paar. Ändere nicht gleichzeitig Index, Tonhöhenmethode, Quellclip und Ausgangspegel, da sich sonst keine Ursache zuordnen lässt.

Suche vor dem Vergleich im Bereich für die Konvertierung einer einzelnen Datei der Offline-WebUI den Regler, dessen englische Beschriftung mit „Search feature ratio“ beginnt. In der untersuchten Revision übergibt er index_rate an die Verarbeitung. Bei 0 wird die Indexsuche übersprungen. Behalte für den zweiten Lauf denselben vorhandenen, zum Checkpoint passenden Indexpfad bei und notiere einen gewählten Wert über 0 bis einschließlich 1. Der voreingestellte Wert 0.75 ist keine Qualitätsempfehlung. Quellclip, Checkpoint und alle übrigen Einstellungen bleiben gleich.

Ein Wert über null löst nur einen Suchversuch aus: Der Index muss auch gefunden und geladen werden. Schlägt das Laden fehl, schreibt der untersuchte Code einen Fehlerbericht ins Terminal und arbeitet ohne Index weiter. Sichere Einstellungen und Terminalprotokoll, behebe Indexfehler und werte einen unklaren Lauf nicht als Variante mit aktiviertem Retrieval. Der Indexdateiname in der Ergebnismeldung beweist keine erfolgreiche Suche, denn diese Anzeige prüft nur, ob die Datei existiert. Die Zuordnung stammt aus dem festgehaltenen Quellcode, nicht aus einem Hörtest. Andere Revisionen und die separate Echtzeitoberfläche erfordern eine eigene Prüfung.

Normalisiere keinen Kandidaten nachträglich, außer derselbe dokumentierte Vorgang wird auf beide angewendet. Lautstärkeunterschiede können die Präferenz verzerren. Höre über den vorgesehenen Kontrollweg, notiere Clipping und Aussetzer und bewahre abgelehnte Ausgaben. Der Plan setzt nicht voraus, dass eine Einstellung allgemein besser ist.

Aufgabenbezogene Hör- und Herkunftsprüfungen anwenden

Die folgende vorgeschlagene Tabelle verbindet Hörkontrollen mit Herkunft und Abbruchbedingungen für die Studiophrase. Sie enthält weder Wertungen noch Testergebnisse. Fülle jede Zeile mit gespeicherter Audiodatei, Einstellungen und Beobachtungen, bevor die Umwandlung als brauchbar bezeichnet wird.

Die Annahme hängt vom Ziel ab. Eine grobe private Charakterstudie kann ein Artefakt tolerieren, das einen veröffentlichten Gesangsstem sperren würde. Umgekehrt muss auch eine attraktive Ausgabe abgelehnt werden, wenn sie Wörter verändert, Rechte verletzt oder nicht zu Checkpoint und Einstellungen zurückverfolgt werden kann.

Lege vor der Erweiterung von Datensatz oder Batch ein Korrekturbudget fest. Berücksichtige Aufnahmebereinigung, Trennung, Einrichtung, Training, Export, wiederholte Inferenz, Hören, Bearbeitung und Rechteprüfung. Der Code kann kostenlos heruntergeladen werden, während die vollständige Aufgabe erhebliche Arbeits- oder Rechenkosten verursacht.

Echtzeitverhalten auf der tatsächlichen Audiokette messen

Die offizielle Root-README nennt 170 ms Ende-zu-Ende-Latenz und 90 ms mit ASIO-Ein- und Ausgabegeräten. Zugleich warnt sie, dass der ASIO-Wert stark von der Hardwaretreiber-Unterstützung abhängt. Das sind Beobachtungen der Maintainer, keine hier reproduzierten Messungen und keine Zusagen für jedes Betriebssystem, Gerät, jeden Puffer oder jedes Stimmenmodell. Offizielle Echtzeitbeobachtung.

Messe bei einem Live-Versuch den vollständigen Weg von der Aufnahme bis zur überwachten Ausgabe. Notiere Oberfläche, Audiogerät, Treibermodus, Abtastrate, Puffer, Hardware, Modell/Index und gleichzeitige Last. Ein reiner Inferenz-Timer enthält Aufnahme, Pufferung, Resampling, Routing und Wiedergabe nicht. Berichte wiederholte Beobachtungen und Aussetzer, nicht nur den besten Wert.

Prüfe Offline-Qualität, bevor die Live-Latenz optimiert wird. Ein niedriger Verzögerungswert ist wertlos, wenn Wörter unklar werden, Tonhöhen brechen oder die Route instabil ist. Verbessert ein kleinerer Puffer die Verzögerung, erzeugt aber Aussetzer, muss dieser Zielkonflikt sichtbar bleiben.

Leite aus einer Echtzeitoberfläche keine Integration mit DAW, OBS, Discord oder Streaming-Plattformen ab. Ein geprüfter Produktionsweg benötigt einen eigenen Audio-Geräte- und Routingtest. Dieser Kandidat behauptet ausdrücklich keine solche Integration.

Die früheste fehlerhafte Stufe diagnostizieren

Wenn eine Ausgabe unbrauchbar ist, suche zuerst das früheste inkonsistente Artefakt, bevor Trainingszeit erhöht oder mehrere Parameter geändert werden. Die Tabelle enthält Diagnosehypothesen, keine gemessenen Fehlerraten.

Nicht jedes metallische Geräusch ist ein Retrieval-Fehler und nicht jeder Aussetzer ein Modellfehler. Trennung, Resampling, Clipping, eine unpassende Checkpoint/Index-Paarung, Tonhöhenextraktion und Live-Routing können jeweils beitragen. Gespeicherte Zwischenprodukte und Ein-Faktor-Vergleiche machen den nächsten Schritt nachvollziehbar.

Beende den Versuch, wenn alle Kandidaten ein Pflichtkriterium verfehlen oder das Korrekturbudget überschritten ist. Mehr Epochen, mehr Aufnahmen oder ein anderer Index sind Experimente, keine automatischen Lösungen. Eine dokumentierte Ablehnung ist nützlich, weil sie verhindert, dass eine schwache Konfiguration skaliert wird.

Rechte an Code, Modell und Stimme getrennt klären

Die LICENSE-Datei des Repositorys verwendet MIT. Sie erlaubt eine breite Nutzung, Änderung und Verteilung der Software, sofern Urheberrechts- und Erlaubnishinweis erhalten bleiben, und liefert die Software ohne Gewährleistung. Damit kann der geprüfte Repository-Code als Open Source eingeordnet werden. Offizielle MIT-Lizenz.

Diese Lizenz klärt keine Rechte an fremden Stimmen-Checkpoints, Trainingsaufnahmen, Quelldarbietungen, Liedern, optionalen Modellgewichten oder Verarbeitungsbedingungen eines gehosteten Dienstes. Auch ein öffentlich geteilter Checkpoint kann für den geplanten Zweck unzureichende Herkunft oder Erlaubnis besitzen. Die Bezahlung einer Oberfläche überträgt ebenfalls keine Rechte an Stimme oder zugrunde liegenden Assets.

Für eine personenbezogene Stimme ist die für Training, Umwandlung, Kennzeichnung, Weitergabe und kommerziellen Kontext erforderliche Erlaubnis einzuholen und zu dokumentieren. Vermarkte eine veränderte Aufnahme nicht als echte Aussage der Person und erwecke keinen Eindruck ihrer Unterstützung. Gilt die Erlaubnis nur für einen privaten Test, gehören Checkpoint und Ausgaben nicht in öffentliche Modellbibliotheken oder Veröffentlichungen.

Optionale Abhängigkeiten und heruntergeladene Assets behalten ihre eigenen Bedingungen. Vor einer Weitergabe sind diese Bedingungen und die Hinweise jeder Komponente zu prüfen. Diese Seite fasst die Codelizenz und Betriebsgrenzen zusammen; sie erteilt keine rechtliche Freigabe für eine Stimme oder Produktion.

Zwischen Training, Live-Routing und Abbruch entscheiden

Erfüllt die Offline-Umwandlung die Tabelle und Herkunftsanforderungen, bewahre Umgebungsnachweis, Checkpoint/Index-Paar, Regler, Quelle und akzeptierte Ausgabe zusammen auf. Entscheide erst danach, ob ein wiederholbarer Batch, eine Trainingsrevision oder eine Live-Audiokette erforderlich ist. Jede Erweiterung braucht eigene Aufwands- und Abnahmenachweise.

Wenn die Aufgabe kein Training der Zielstimme erfordert, kann ein zulässiger Text-to-Speech- oder Zero-Shot-Ablauf geeigneter sein. Diese Bewertung validiert jedoch keine benannte Alternative. Wenn nur Tonhöhenkorrektur, Rauschreparatur oder Stimmtrennung benötigt wird, wähle einen engeren Audioprozess und füge keine personenbezogene Stimmumwandlung hinzu. Scheitert die Live-Latenz, während Offline-Audio akzeptabel ist, bleibe offline, statt Echtzeitbetrieb als Pflicht zu behandeln.

Sind Rechte ungeklärt, stoppe vor dem Download oder der Weitergabe weiterer Stimmenmodelle. Scheitert die Qualität erst nach Trennung oder Resampling, repariere diesen Eingabeweg vor einem neuen Training. Bleibt die Stimme über repräsentative Clips instabil, können andere zulässige Zieldaten oder ein anderes Verfahren nötig sein. Dieser Kandidat erstellt keine Rangliste von RVC und anderen Systemen.

Nutze nach der Klärung der fehlenden Fähigkeit das Modellverzeichnis. Vor öffentlicher oder kundenbezogener Nutzung müssen aktuelle Quellen- und Abhängigkeitsrevisionen geprüft, die exakte zulässige Aufgabe ausgeführt, das gemessene Ergebnis dokumentiert und alle erforderlichen Stimm- und Medienrechte eingeholt werden. Repository-Popularität, eine Ausgabedatei oder eine niedrige Latenzangabe schließen diese Entscheidung nicht ab.