RVC v2

RVC v2 is the existing tasarim.ai name for the v2 voice-conversion workflow documented in the official Retrieval-based-Voice-Conversion-WebUI repository. It takes an existing voice performance and converts its vocal character with a target voice checkpoint, with an optional retrieval index and pitch extraction in the surrounding workflow. It is suitable for a controlled local evaluation when you have permission for every recording and model involved. It is not a text-to-speech system, a permission to imitate someone, or a guarantee of real-time performance on untested hardware.

This is a source-based evaluation of official repository commit 81eed5e8f68b6bed1789f682fe78cdd324495afc. No environment was installed, no model or audio was downloaded, no voice was trained or converted, and no latency or listening result was measured. The steps and worksheet below are a proposed evaluation with blank results.

Define the voice-conversion task before choosing RVC

Begin with the signal you already have and the output you actually need. RVC converts an existing performance rather than generating new speech from text. The source recording supplies timing, words, phrasing and pitch movement; the target checkpoint and related controls shape the converted voice. If your job begins with a script and needs speech that was never recorded, evaluate a text-to-speech workflow instead of treating voice conversion as a substitute.

Write a narrow intended use before collecting files. One defensible example is converting a short, authorized studio phrase into a second authorized voice for a private production test. Decide which properties must survive, such as understandable words, phrase timing and deliberate pitch movement, and which properties may change. Do not define success as “sounds exactly like this person.” That framing confuses a listening preference with identity, consent and provenance.

The repository describes training and inference WebUI paths plus a separate real-time voice-changing interface. Those are related operating modes, but success in offline conversion does not prove a live audio route will meet its latency or stability target. Keep offline quality, training effort and real-time routing as separate decisions.

Do not use a conversion to authenticate a speaker, establish that a person said something, or promise anonymity. A transformed voice can retain recognizable traits or introduce new artifacts, and this review has not measured identifiability. If the task requires evidentiary certainty or dependable de-identification, RVC output is not sufficient proof.

Separate repository code, voice weights, index and media

The official repository provides code and interfaces, not one self-contained voice model. Its current layout expects HuBERT assets for feature extraction, an RMVPE file for pitch extraction, project pretraining assets for v1/v2 training, user .pth voice weights under assets/weights/, and user .index files under assets/indices/. Optional pymss/MSST weights belong to a separate vocal-separation path. Official current setup and directory layout.

Treat each artifact as an independent provenance record. A voice checkpoint should be tied to its creator or authorized distributor, intended use, model version and checksum. If a retrieval index accompanies it, preserve the checkpoint-to-index pairing instead of assuming that any similarly named .index file is compatible. File names are convenient labels, not evidence of source or permission.

Input media needs its own record. Keep the target training recordings, source performance and converted result in distinct locations. Record who supplied each item, what processing and sharing are allowed, and whether the performance contains music or other protected material. Repository access does not answer those questions.

The README links a Hugging Face model repository and gives download commands that use --revision main. A moving branch name identifies an acquisition route, not an immutable binary. For an actual evaluation, record the resolved revision when exposed and calculate local checksums after download. This source review did not download or inspect any of those model files.

Prepare the current hardware-specific environment

At the reviewed commit, the official English instructions target Python 3.12 x64. They recommend Ubuntu 24.04 x86_64 and provide a Windows virtual-environment path. Installation depends on hardware: CPU, AMD and Intel use requirments_cpu_py312.txt; RTX 50-series systems use a two-stage CUDA 12.8 Torch installation followed by requirments_cu128_py312.txt; earlier NVIDIA hardware uses the documented CUDA 11.8 pair and requirments_cu118_py312.txt. The filename spelling requirments is the repository's literal name. Official environment instructions.

Choose one dependency path from the machine you will actually use. Do not combine CPU, CUDA 11.8 and CUDA 12.8 files or copy an older guide whose assets and Python version differ. The current README places HuBERT files inside the assets/hubert_base/ directory, which differs from older instructions that may describe a single file elsewhere. Verify the current tree and exact paths before diagnosing the model.

Create an isolated environment and keep a setup log. Record operating system, architecture, Python, Torch, torchaudio, dependency file, package indexes, GPU and driver details. The repository permits replacing mirror indexes with official indexes while retaining pinned package versions, CUDA suffixes and installation order. That is supply-path guidance, not a compatibility guarantee.

Before opening the WebUI, check that the required assets exist at the documented paths and that Torch reports the intended CUDA status. The README starts the interface with python webui.py, or python webui.py --noautoopen on a headless Ubuntu server, and identifies port 7865 as the default. These are source instructions, not commands executed for this article.

Treat training guidance as a starting condition

The maintainers recommend collecting at least 10 minutes of low-noise speech. That is a recommendation in the README, not a minimum that guarantees a useful model or a claim that training finishes in ten minutes. Recording content, noise, clipping, speaker consistency, pitch range and the intended source material can all change what a listening test reveals. This review does not establish an ideal duration.

Use only recordings you may process for the intended purpose. Keep an untouched copy, then document any separation, trimming or preprocessing before training. If vocal separation is necessary, the repository can call pymss/MSST models, but that optional path requires separate weights and introduces another transformation to inspect. Do not attribute an artifact to RVC until you have compared the preprocessed material with the source.

The v2 training download path includes pretrained_v2/* plus shared assets and silence samples under logs/mute/. Record whether the experiment uses v1 or v2 resources and avoid mixing them silently. Save training configuration, log directory, exported inference checkpoint and matching index as separate artifacts. A file saved during training should not be assumed to be the final inference artifact without verifying the export path and format.

Reserve one permitted phrase or clip for evaluation rather than using every recording to prepare the target model. A held-out sample does not turn this proposed workflow into a scientific benchmark, but it helps prevent a favorable training example from becoming the only evidence considered.

Run a bounded source-based evaluation

The proposed trial uses one target checkpoint with its recorded provenance, its matching index if retrieval is enabled, and two permitted source clips. Clip A should be clean and representative of the intended use. Clip B should expose one relevant challenge, such as a wider pitch movement or mild background contamination, without introducing several uncontrolled problems at once. No clip or result exists in this candidate.

First produce an offline conversion with the selected environment and exact current assets. Record the interface mode, checkpoint, index, pitch extraction choice, transposition or pitch setting, retrieval-related control, input path, output path and every other changed control. Keep the unconverted source beside the output. If the interface generates logs, preserve the full log rather than copying only a success line.

Create a second candidate by changing one factor. A useful first comparison is retrieval disabled versus enabled with the matching index, while every other setting stays fixed. Another valid comparison changes the pitch extraction path, but it belongs in a separate pair. Do not change the index, pitch method, source clip and output level together, because the result cannot identify which choice mattered.

Before producing that pair, identify the slider in the offline WebUI’s single-file conversion panel whose English label begins “Search feature ratio”. In the reviewed source, it passes index_rate to the conversion pipeline. A value of 0 skips index retrieval. For the second run, keep the same valid, matching index path and choose a recorded value above 0 and at most 1. The interface default is 0.75; it is a default, not a quality recommendation. Keep the source clip, checkpoint and all other controls unchanged.

A nonzero value only attempts retrieval: the pipeline must also find and load the index. If loading fails, the reviewed code prints a traceback and continues without the index. Save the terminal log and settings, resolve any index error, and do not count an uncertain run as the retrieval-enabled member of the pair. The output's index filename is not proof of successful retrieval because that status text checks file existence only. This mapping comes from the pinned pipeline source, not an audio test. Another revision or the separate real-time interface needs its own mapping.

Normalize neither candidate after the fact unless the same documented operation is applied to both. Loudness differences can bias preference. Listen through the intended monitoring route, note obvious clipping or dropouts, and preserve rejected outputs. This plan does not assume that one setting is universally better.

Apply task-specific listening and provenance checks

This proposed table joins listening checks with provenance and stop conditions for the studio phrase. It contains no ratings or test results. Fill each row with saved audio, settings and observations before describing the conversion as useful.

Acceptance should depend on the destination. A rough private character study may tolerate an artifact that would block a published vocal stem. Conversely, an attractive result must still be rejected if it changes words, violates permission or cannot be traced to its checkpoint and settings.

Set a correction budget before expanding a dataset or batch. Include recording cleanup, separation, environment setup, training, export, repeated inference, listening, editing and rights review. A code download can be free while the complete job remains expensive in labor or compute.

Measure real-time behavior on the actual audio route

The official root README reports 170 ms end-to-end latency and 90 ms with ASIO input and output devices, while warning that the latter depends heavily on hardware driver support. These are maintainer observations, not measurements reproduced here and not promises for every operating system, device, buffer or voice model. Official real-time observation.

For a live trial, measure the complete route from captured input to monitored output. Record interface, audio device, driver mode, sample rate, buffer settings, hardware, model/index choice and concurrent load. A model inference timer alone does not include capture, buffering, resampling, routing and playback. Report repeated observations and dropouts, not only the best reading.

Run offline quality acceptance before optimizing live latency. A low delay number is not useful if words become unclear, pitch breaks or the route is unstable. If changing the buffer improves delay but causes dropouts, keep the tradeoff visible instead of presenting one number as a final capability.

Do not infer DAW, OBS, Discord or streaming-platform integration from the existence of a real-time GUI. A verified production route requires its own audio-device and routing test. This candidate deliberately makes no integration claim.

Diagnose the earliest stage that fails

When an output is unusable, locate the first inconsistent artifact before increasing training time or changing many parameters. The table gives diagnostic hypotheses, not measured failure rates.

Do not label every metallic sound a retrieval failure or every dropout a model failure. Separation, resampling, clipping, an incompatible checkpoint/index pair, pitch extraction and live routing can each contribute. Saved intermediate files and a single-variable comparison make the next decision explainable.

Stop when all candidates fail a required criterion or the correction budget is exceeded. More epochs, more recordings or a different index are experiments, not automatic fixes. A documented rejection is a useful result because it prevents a weak configuration from being scaled.

Resolve code, model and voice rights separately

The repository LICENSE is MIT. It permits broad use, modification and distribution of the software, subject to retaining the copyright and permission notice, and supplies the software without warranty. This supports an open-source classification for the reviewed repository code. Official MIT License.

That license does not establish rights in third-party voice checkpoints, training recordings, source performances, songs, optional model weights or a hosted service's processing terms. A checkpoint shared publicly can still lack adequate provenance or permission for your intended use. Paying for a wrapper likewise does not grant rights in the voice or underlying assets.

For any person-specific voice, obtain and record the authorization appropriate to the proposed training, conversion, disclosure, sharing and commercial context. Do not market a transformed sample as the person's real speech or imply endorsement. If permission is limited to a private test, keep the checkpoint and outputs out of public model libraries and releases.

Optional dependencies and downloaded assets keep their own terms. Before redistribution, review those terms and the notices that accompany each component. This page summarizes the repository code license and operational boundaries; it does not provide legal clearance for a voice or production.

Decide whether to train, route live or stop

If offline conversion meets the worksheet and provenance requirements, preserve the environment record, checkpoint/index pair, controls, source and accepted output together. Only then decide whether the task needs a repeatable batch, a training revision or a live audio route. Each expansion needs its own workload and acceptance evidence.

If the target voice does not require training for the actual task, a permitted text-to-speech or zero-shot workflow may be more appropriate, but this review does not validate a named alternative. If you need only pitch correction, noise repair or vocal separation, use a narrower audio process and avoid introducing a person-specific voice conversion. If live latency fails but offline audio is acceptable, keep the workflow offline instead of treating the real-time interface as mandatory.

If rights are unresolved, stop before downloading or sharing additional voice models. If quality fails only after separation or resampling, repair that input path before retraining. If the converted voice remains unstable across representative clips, a different permitted target dataset or another method may be required. This candidate does not rank RVC against another system.

Use the model directory after the missing capability is clear. Before a public or customer-facing use, verify current source and dependency revisions, run the exact permitted workload, document the measured result, and obtain the necessary voice and media permissions. Repository popularity, an output file and a low latency claim do not complete that decision.